Kubernetes? Helm?

Da ich mich ganz am Anfang der openSource/openDesk Reise befinde, muss ich mich erstmal mit den Grundlagen beschäftigen. Meine größte Stärke: Es fällt mir wahnsinnig leicht, mich blöd zu stellen. 😉

Daher habe ich diverse KIs gebeten, mir die absoluten Basics wie Kubernetes, Helm-Charts, etc. mal anhand eines realen Beispiels zu erklären. Ich finde das Ergebnis so gelungen, dass ich es hier einmal wiedergeben möchte.

Kubernetes & Helm: Das automatisierte Frachtschiff

1. Die Fracht: Container

Früher hat man Software wie ein Haus gebaut – fest verwurzelt auf einem einzelnen Server. Wenn der Server abstürzte, war alles weg.

Heute verpackt man Programme (wie Nextcloud, Open-Xchange oder Matrix) in genormte Schiffscontainer. In jedem Container steckt eine einzelne Anwendung inklusive aller Einstellungen und Abhängigkeiten, die sie zum Laufen braucht.

Der Vorteil: Einem Container ist es völlig egal, auf welchem Server er steht. Er läuft überall exakt gleich.

2. Der Kapitän: Kubernetes

Wenn Du ein komplexes System wie openDesk betreiben willst, hast Du nicht nur einen Container, sondern Dutzende (für Websites, Datenbanken, Mail-Dienste, Chat-Server).

Kubernetes ist der automatisierte Schiffs-Kapitän. Du sagst dem Kapitän nicht wie er seine Arbeit machen soll, sondern gibst ihm nur den gewünschten Zielzustand (Soll-Zustand):

„Kapitän, ich will, dass von unserem Mail-Dienst immer genau drei Container laufen. Und wenn einer abstürzt, ersetze ihn sofort!“

Kubernetes übernimmt die Steuerung vollautomatisch:

• Selbstheilung (Self-Healing): Säuft ein Container/Pod ab oder hängt sich auf, wirft Kubernetes ihn über Bord und stellt in Sekundenbruchteilen einen identischen, frischen Container an dieselbe Stelle.
• Skalierung (Auto-Scaling): Ist viel los, stellt der Kapitän automatisch zusätzliche Container bereit. Sinkt die Last, löscht er sie wieder, um Ressourcen zu sparen.
• Lastverteilung (Load Balancing): Kubernetes verteilt die Anfragen der Benutzer gleichmäßig auf alle funktionierenden Container.

3. Der Bauplan für Frachtdecks: Helm Chart

Ein einzelnes Programm besteht selten aus nur einem Container. Oft brauchst du für eine Anwendung (z. B. Nextcloud) die App selbst, eine Datenbank, Netzwerkregeln und Speicherplatz.

Ein Helm Chart ist der fertige, gedruckte Bauplan für ein zusammengehöriges Frachtdeck. In diesem Bauplan ist exakt aufgezeichnet, welche Container dazugehören, wie sie miteinander verkabelt werden müssen und welche Ressourcen sie benötigen.

4. Der Wunschzettel: ⁠values.yaml⁠

Auf dem gedruckten Bauplan (Helm Chart) gibt es Felder, die individuell ausgefüllt werden müssen. Das ist die ⁠values.yaml⁠:

"Ziel-Domain: ⁠meine-organisation.de⁠"

"Maximaler Speicherplatz: 500 GB"

"Passwort: ⁠Geheim123!⁠"

Der technische Bauplan bleibt immer gleich, aber über die ⁠values.yaml⁠ passt du das Frachtdeck exakt an die Bedürfnisse deiner Organisation an, ohne den komplexen Code verändern zu müssen.

5. Das fertige Deck: Release

Wenn der Kapitän und seine Mannschaft das Frachtdeck nach deinem Bauplan (Chart) und deinen Einstellungen (⁠values.yaml⁠) auf dem Schiff montiert haben, entsteht ein Release.

Benötigst du eine zweite, unabhängige Instanz (z. B. eine Testumgebung), nimmst du denselben Bauplan (Chart), füllst einen neuen Zettel (⁠values.yaml⁠) aus und erhältst ein zweites Release auf demselben Schiff.

6. Der Master-Beladeplan: Helmfile

openDesk ist kein einzelnes Frachtdeck, sondern ein Verband aus vielen Spezial-Decks (Mail, Dokumente, Chat, Wiki, Benutzerverwaltung).

Damit du nicht 15 Baupläne manuell beim Kapitän einreichen musst, gibt es Helmfile. Helmfile ist der Master-Beladeplan des Hafendirektors.

In diesem Master-Beladeplan steht geschrieben:

1. Welche Frachtdecks (Helm Charts) benötigt werden.
2. In welcher Reihenfolge sie aufgebaut werden müssen (z. B. „Baue die Benutzerverwaltung vor dem Mail-Deck auf“).
3. Welche zentralen Einstellungen für alle Decks gleichzeitig gelten.

Ein einziger Befehl an den Kapitän (⁠helmfile apply⁠) genügt, und das gesamte openDesk-Schiff wird geordnet und vollautomatisch beladen.

7. Kurzübersicht

Begriff	Metapher	Funktion
Container	Frachtkiste	Die verpackte Anwendung mit allem, was sie braucht
Kubernetes	Kapitän	Steuert, überwacht, repariert und skaliert die Pods/Container
Helm	Der Hafen-Architekt	Das Werkzeug, das Baupläne verarbeitet, an Kubernetes übergibt und die Installation verwaltet. Helm speichert außerdem Versionsstände der Installationen und ermöglicht Upgrades oder Rollbacks.
Helm Chart	Bauplan für ein Frachtdeck	Standardisiertes Paket aus mehreren zusammengehörigen Containern
values.yaml	Ausgefüllter Frachtzettel	Enthält die individuellen Einstellungen für die Installation
Release	Fertiges Frachtdeck	Die tatsächlich installierte Instanz des Helm Charts
Helmfile	Master-Beladeplan	Orchestriert alle einzelnen Helm-Charts der Software