Eigentlich ist ja alles unter https://www.opendesk.eu/en/blog/opendesk-on-k3s beschrieben nur dass es dann halt doch nicht so funktioniert, weil

  1. Die Minimum Requirements sind tatsächlich einzuhalten – ich bin mit 10 Cores gescheitert weil er dann einen Pod nicht schedulen konnte. Vielleicht Zufall/Pech aber mit 12 hatte ich konsistent keine Probleme.
    32 GB RAM sind machbar – am Ende sind ca. 20 GB in use – aber am Weg gehen 40 GB für Cache drauf – pendelt sich dann auch weit nach unten (10 GB) ein aber langsamer wirds damit sicher nicht.
  2. Mit irgendeiner OpenProject Version ist sticky bit Support beim Kubernetes Storage Provider Voraussetzung geworden, das Deployment bleibt mit dem Default local-path Provider dann hängen.
    (Fußnote 2 auf https://docs.opendesk.eu/operations/requirements/)
  3. Bei mir hat Helm nur bis 3.17.x funktioniert.
    (Fußnote 1 auf https://docs.opendesk.eu/operations/requirements/)
  4. Helm diff Plugin hat bei mir auch nur mit 3.12.4 funktioniert.
  5. Helmfile hat bei mir auch nur mit 1.2.2 funktioniert.

Weil wir anderes Storage brauchen auf Longhorn gewechselt, das hat aber Single Node auch spezielle Herausforderungen weil in der Defaultinstallation das Setup nach einem Reboot vom Host sonst kaputt ist.

Vorgehen:

  1. Das longhorn.yaml aus dem Setup nur runterladen aber nicht gleich applyen.
  2. Das Deployment für longhorn-driver-deployer um folgende Environmentvariablen erweitern damit nur jeweils ein Pod für Attacher/Provisioner/Resizer/Snapshotter erzeugt wird:
    - name: CSI_ATTACHER_REPLICA_COUNT
    value: "1"
    - name: CSI_PROVISIONER_REPLICA_COUNT
    value: "1"
    - name: CSI_RESIZER_REPLICA_COUNT
    value: "1"
    - name: CSI_SNAPSHOTTER_REPLICA_COUNT
    value: "1"
  3. ConfigMap longhorn-default-setting bei data/default-setting.yaml um folgende Settings erweitern (default-data-path natürlich optional, ich hatte zweite Disk eingehängt):
    default-data-path: "/longhorn"
    default-replica-count: 1
    node-drain-policy: "always-allow"
    auto-salvage: true
  4. ConfigMap longhorn-storageClass den parameter „numberOfReplicas“ von „3“ auf „1“ ändern
    numberOfReplicas: "1"
  5. Im Deployment longhorn-ui die Replicas von 2 auf 1 stellen
    replicas: 1
  6. Im values.yaml.gotmpl fürs openDesk deployment (Punkt 3.2 in der Anleitung „Customizing the environment“) Storage umstellen:
    persistence:
    storageClassNames:
    RWO: "longhorn"

Da die Wahrscheinlichkeit dass alle Longhorn Volumes nach einem Reboot korrupt sind bei annähernd 100% liegt sollte man vor so einem Reboot alle Deployments und Statefulsets im openDesk Namespace auf 0 setzen und danach wieder zurück auf 1.

Vorher:
kubectl scale deployment -n <openDesk-namespace> --replicas=0 --all
kubectl scale statefulset -n <openDesk-namespace> --replicas=0 --all

….warten bis alle Longhorn Volumes detached sind….

….Reboot….

Nachher:
kubectl scale deployment -n <openDesk-namespace> --replicas=1 --all
kubectl scale statefulset -n <openDesk-namespace> --replicas=1 --all

( Und ja das ist sicher gegen 2000 Kubernetes Gesetze und der Fahndungszettel für mich hängt schon überall aber für mich funktionierts 😀 )