Was ist Kubernetes?
Kubernetes betreibt Container über eine Gruppe von Maschinen hinweg und hält sie am Laufen. Du beschreibst, was existieren soll: wie viele Instanzen eines Dienstes, wie viel Speicher jede bekommt, welchen Storage sie einbindet, wie Verkehr sie erreicht. Kubernetes arbeitet dann fortlaufend daran, die Realität dieser Beschreibung anzugleichen. Fällt eine Maschine aus, wandern die Workloads. Stürzt ein Container ab, wird er neu gestartet. Verlangst du eine neue Version, wird sie schrittweise ausgerollt.
Der Fachbegriff dafür ist deklarativ: Du schreibst den Zielzustand auf, nicht den Weg dorthin. Das ist die ganze Idee, und das meiste, was an Kubernetes verwirrt, folgt daraus, dass sie ernst gemeint ist.
Was es bewusst nicht tut
Diese Hälfte der Antwort ist die nützlichere, weil hier die Überraschungen liegen.
Kubernetes ist keine Anwendungsplattform. Ab Werk baut es deinen Code nicht, speichert deine Container-Images nicht, liefert keine URL mit gültigem Zertifikat, sammelt keine Logs, überwacht nichts und sichert keine Datenbank. Jedes dieser Teile ist eine eigene Komponente, die jemand auswählt, installiert, konfiguriert, absichert und aktualisiert.
Die nächstliegende Parallele ist Linux. Du kannst den Kernel herunterladen und übersetzen und hast danach etwas, das bootet und fast nichts kann, was du brauchst. Was Leute tatsächlich betreiben, ist eine Distribution: Ubuntu, Debian, Red Hat Enterprise Linux. Der Kernel ist überall derselbe; die Distribution ist die Paketverwaltung, das Init-System, die Verzeichnisstruktur, die Sicherheitsrichtlinie, der Update-Kanal und der Supportvertrag, ausgewählt und aufeinander abgestimmt von jemandem.
Kubernetes steht in diesem Vergleich am Kernel-Ende. Es ist eine offene Basis, auf der andere Werkzeuge die konkreten Probleme lösen, und es löst sie nicht selbst. Diese Werkzeuge muss weiterhin jemand auswählen und zusammenbringen: dein Plattformteam, eine Kubernetes-Distribution wie OpenShift oder ein Anbieter, den du beauftragst.
Das ist eine Entwurfsentscheidung und keine Lücke. Genau darum läuft Kubernetes unter so unterschiedlichen Voraussetzungen gleich gut. Und genau darum ist «wir gehen auf Kubernetes» ein grösseres Vorhaben, als es klingt: Der Cluster ist der Anfang der Plattform, nicht die Plattform.
Wann eine Organisation es wirklich braucht
Mehrere Teams, die unabhängig deployen. Kubernetes gibt jedem Team eine Grenze mit eigenen Quotas und Rechten auf gemeinsamer Infrastruktur. Das anders herzustellen ist mühsam.
Workloads mit schwankender Nachfrage. Skalierung nach Last ist eingebaut. Ist dein Verkehr konstant, gilt dieses Argument für dich nicht.
Portabilität, die belastbar sein muss. Dieselben Manifeste laufen bei einem Schweizer Anbieter, bei einem Hyperscaler und auf eigener Hardware. Für Organisationen, deren Anforderungen an die Jurisdiktion sich ändern können, ist das ein konkreter Wert.
Eine einheitliche Form für viele Dienste. Ist ein Dienst einmal in Kubernetes-Begriffen beschrieben, folgt der fünfzigste demselben Muster. Der Nutzen wächst mit der Anzahl Dienste, weshalb er am Anfang eben noch nicht da ist.
Wann nicht
Eine Handvoll Dienste mit gleichmässigem Verkehr läuft auf virtuellen Maschinen oder einer verwalteten Anwendungsplattform günstiger und ruhiger. Diese Auskunft kostet uns Beratungsgeschäft und stimmt trotzdem.
Wenn niemand zuständig ist. Ein Cluster ist Infrastruktur mit Lebenszyklus. Steht das in keiner Stellenbeschreibung, betreibt ihn die Person, die am schlechtesten Nein sagen kann, und er driftet.
Wenn die Frist in Wochen gemessen wird. Die Lernkurve ist real. Kubernetes unter Zeitdruck einzuführen ergibt einen Cluster, der läuft und den niemand versteht.
Die Verpflichtung, die in keinem Pitch steht
Kubernetes pflegt Release-Branches für die drei jüngsten Minor-Versionen, und eine Version erhält rund ein Jahr Patch-Support. Praktisch heisst das: mehrmals im Jahr ein Upgrade, dauerhaft, nach fremdem Kalender.
Jedes Upgrade berührt Control Plane, Nodes, das Betriebssystem darunter und die Add-ons für Netzwerk, Storage und Ingress, jedes mit eigener Kompatibilitätsmatrix. Veraltete APIs verschwinden nach veröffentlichtem Fahrplan, weshalb ein Upgrade auch Änderungen an Anwendungsmanifesten verlangen kann und nicht nur an der Infrastruktur.
Das ist der grösste Unterschied zwischen einem Kubernetes-Proof-of-Concept und Kubernetes im Betrieb. Das eine ist ein Nachmittag. Das andere ist eine stehende Verpflichtung, und sie wird meist erst nach der Entscheidung entdeckt.
Verwaltet oder selbst betrieben
Grob gibt es drei Varianten, und sie unterscheiden sich darin, wo die Verantwortungsgrenze verläuft.
Der verwaltete Dienst eines Hyperscalers betreibt die Control Plane für dich. Nodes, Add-ons, deren Upgrades und die Jurisdiktionsfrage bleiben bei dir.
Der eigene Cluster gibt dir volle Kontrolle über Version, Konfiguration und Ort und die volle Verantwortung für die oben beschriebene Tretmühle.
Eine betriebene Plattform heisst, dass jemand den gesamten Lebenszyklus übernimmt, Control Plane, Nodes, Betriebssystem und Add-ons, gegen ein SLA, auf Infrastruktur deiner Wahl.
Eine allgemein richtige Antwort gibt es nicht. Es gibt eine Antwort, die dazu passt, wie viel Plattform-Kapazität deine Organisation tatsächlich hat. Das ist eine andere Frage als die, wie viel sie gerne hätte.
Wo VSHN hineinpasst
VSHN ist der erste Kubernetes Certified Service Provider der Schweiz und betreibt Kubernetes seit 2016 produktiv. Wir entwerfen und betreiben Cluster auf Cloudscale und Exoscale, auf AWS, Google Cloud und Azure sowie auf Private Cloud und On-Premises-Infrastruktur, mit Support bis zu einem SLA von 99.99%.
Das wertvollste Gespräch findet meist statt, bevor der Cluster existiert: ob Kubernetes für deine Workloads überhaupt die richtige Form ist und, falls ja, was der Betrieb von deinem Team verlangen wird.