Installation von CodiMD in einen K3D Cluster

CodiMD ist ein Webbasierter Editor für Markdown und Extensions. In diesem Artikel beschreibe ich kurz die Probleme die ich beim Deployment in einem K3D Cluster hatte, bevor ich die Anwendung lokal nutzen konnte.

Installation von CodiMD mit Helm

Bei der Installation von CodiMD sind insgesamt 2 Probleme aufgetaucht, die eine reibungslose Installation verhindert haben.

Docker Registry

Bei meinem Versucht die Installation durchzuführen, schlug immer das Downloaden des Images von CodiMD fehl. Erst die Änderung des Registry Eintrags in dem Helm Chart auf die standard Docker Hub Registry, vermag das Image hackmdio/hackmd zu pullen.

image:
  pullPolicy: Always
  pullSecrets: []
  registry: registry.hub.docker.com
  repository: hackmdio/hackmd
  tag: 2.1.0

Die Storage Class ist nicht gesetzt

PVC konnte nicht geclaimt werden. In der Default Einstellung steht Storage Class auf ‘-‘, was aber anscheinend nicht dem Default aus Kubernetes entspricht, sodass kein Claim gesteckt werden kann. Und somit fährt der CodiMD Container nie hoch. Erst das Setzen der Storage Class auf local-path schafft hier abhilfe.

  imageStorePersistentVolume:
    accessModes:
    - ReadWriteOnce
    enabled: true
    size: 10Gi
    storageClass: local-path
    volumeMode: Filesystem

K3D / K3S Storage class

K3S unterstützt OOTB die Kubernetes Storage Class local-path. Diese ist auch die default Einstellung in Kubernetes, was man mit kubectl get storagesclass leicht überprüfen kann.

k get storageclass
NAME                   PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
local-path (default)   rancher.io/local-path   Delete          WaitForFirstConsumer   false                  14d