Hallo zusammen,
ich wollte kurz teilen, woran wir bei uns rund um openDesk gerade arbeiten, weil ich vermute, dass andere in eine ähnliche Richtung denken oder schon ähnliche Erfahrungen gemacht haben.
Wir betreiben openDesk nicht als permanent laufenden “klassischen” Kubernetes-Stack, sondern experimentieren mit einem cold-rebuild-fähigen Setup auf GKE. Die Idee ist: teure Runtime-Ressourcen können geplant schlafen gehen und bei Bedarf wieder hochfahren, während der relevante Zustand über retained Disks, Snapshots und definierte Wiederherstellungsschritte erhalten bleibt.
Was wir inzwischen aufgebaut haben:
- Terraform erstellt/zerstört die Runtime-Infrastruktur gezielt.
- Retained Storage bleibt über Sleep/Wake-Zyklen erhalten.
- openDesk wird nach dem Wake per Helmfile/Helm wieder ausgerollt.
- Vor dem Sleep werden wichtige Zustände/Snapshots gesichert.
- Nach dem Wake laufen Smoke- und Validierungschecks, bevor der Stack als “ready” gilt.
- Ein Wake-Controller steuert geplante Wake/Sleep-Zyklen.
- Grafana/Prometheus/Loki beobachten den Zustand und alarmieren bei Fehlern.
- Fehlerhafte Wake-Versuche werden jetzt retry-fähig und besser diagnostizierbar gemacht.
Der wichtigste Lerneffekt bisher: Die Helmcharts sind notwendig, aber sie sind nicht der vollständige Betriebsvertrag.
Ein Chart kann Ressourcen installieren. Aber im realen Betrieb bleiben viele Fragen außerhalb des Charts:
- Welche Daten müssen retained sein?
- Welche PVCs dürfen neu entstehen, welche nicht?
- Wie wird geprüft, ob AppSuite, Mail, Matrix, Nextcloud, Keycloak usw. wirklich benutzbar sind?
- Was passiert, wenn ein Wake mitten im Terraform/GKE/Helm-Bootstrap scheitert?
- Wie verhindert man, dass ein geplanter Sleep eine Fehlersituation verdeckt?
- Welche Logs/Metriken braucht man, damit der nächste Fehler nicht nur “failed” heißt?
- Wie hält man Kosten niedrig, ohne Recovery und Diagnose zu opfern?
Wir haben gerade einen Fall gehabt, bei dem der geplante Wake zunächst vor der Validierungsphase scheiterte, ein späterer Wake aber erfolgreich war. Das war ein gutes Beispiel dafür, dass man neben “deploy chart” auch robuste Zustandsmaschinen, Retry-Logik und strukturierte Diagnostik braucht.
Mich würde interessieren:
- Betreibt jemand openDesk ebenfalls in Richtung cold rebuild, scheduled shutdown oder kostenoptimierter Runtime?
- Wie trennt ihr Chart-Deployment von Betriebs-/Recovery-Logik?
- Welche Checks nutzt ihr, um “ready” wirklich fachlich zu validieren?
- Gibt es Interesse, solche Betriebsbausteine rund um openDesk gemeinschaftlich zu dokumentieren oder zu standardisieren?
Ich teile gern mehr Details zu unserem Setup, wenn das für andere hilfreich ist. Mir geht es vor allem darum, Erfahrungen auszutauschen: openDesk per Helm auszurollen ist der Anfang, aber der spannende Teil ist aus meiner Sicht der reproduzierbare, beobachtbare und fehlertolerante Betrieb danach.