Ein Kubernetes-Cluster läuft monatelang ohne Eingriff. Dann steht ein Upgrade an, und es zeigt sich, wie viele Teile daran hängen.
Wer eine solche Umgebung betreibt, kennt beide Zustände. Im Alltag verlangt der Cluster wenig Aufmerksamkeit. Pods starten neu, Nodes kommen dazu oder fallen weg, und das System gleicht das selbst aus.
Genau diese Ruhe führt zur Fehleinschätzung, der Betrieb sei die kleinere Aufgabe. Er ist nur selten sichtbar.
Ein Cluster besteht aus vielen Komponenten
Was als der Cluster bezeichnet wird, ist eine Zusammenstellung: Control Plane mit etcd, ein CNI-Plugin für das Netzwerk, ein Ingress-Controller, CSI-Treiber für den Storage, dazu je nach Umgebung Cert-Manager, Metrics-Server und ein Monitoring-Stack.
Jede dieser Komponenten hat einen eigenen Releaseplan und einen eigenen unterstützten Versionsbereich. Keiner dieser Pläne richtet sich nach den anderen.
Mindestens zwei Kubernetes-Upgrades pro Jahr
Kubernetes erscheint dreimal pro Jahr in einer neuen Minor-Version. Eine Version wird anschliessend rund vierzehn Monate lang mit Patches versorgt, wovon zwölf Monate als Standardzeitraum gelten.
Wer im unterstützten Bereich bleiben möchte, führt also mindestens zwei Upgrades pro Jahr durch.
Was ein Upgrade mitzieht
Ein Upgrade bleibt nicht bei der Control Plane. Es zieht die Komponenten daneben mit, weil deren unterstützte Versionsbereiche sich mitverschieben.
Und es betrifft die eigenen Manifeste, denn API-Versionen werden zuerst als veraltet markiert und fallen einige Versionen später weg.
Betrieben wird deshalb keine einzelne Software, sondern eine Matrix aus Versionen, in der jedes Teil zu jedem anderen passen muss. Diese Matrix verschiebt sich von selbst, auch wenn niemand etwas anfasst.
Der Aufwand kommt in Schüben
Zwischen den Upgrades ist der Aufwand klein. An den Upgradeterminen ist er gross und zugleich schlecht abschätzbar, weil erst die Vorbereitung zeigt, welches Teil nicht mitkommt.
Ein Ingress-Controller, der zwei Jahre unverändert lief, kann ein Upgrade aufhalten, weil seine unterstützte Version den Sprung nicht mitmacht.
Was unter den Applikationen liegt
Die Sicherung von etcd ist schnell eingerichtet, der geprobte Restore ist die eigentliche Arbeit.
Die Verfügbarkeit der Control Plane entscheidet sich daran, ob ein Controller oder mehrere über getrennte Zonen laufen. Zertifikate haben eine Laufzeit und melden sich nicht, bevor sie ablaufen.
Ein ruhiges Jahr beweist nichts
Ein Cluster, der ein Jahr lang problemlos lief, belegt nicht, dass der Betrieb sitzt. Er belegt, dass in diesem Jahr nichts fällig wurde, was die Matrix in Bewegung gebracht hätte.
Die Frage ist die Besetzung, nicht das Können
Technisch ist an diesen Aufgaben nichts Aussergewöhnliches. Ein Team, das Kubernetes eingeführt hat, kann sie auch ausführen. Die schwierigere Frage ist eine andere. Lässt sich das nötige Wissen dauerhaft vorhalten für etwas, das zweimal im Jahr gebraucht wird?
Zwischen zwei Upgrades liegen Monate. Personen wechseln die Aufgabe oder das Unternehmen, und die Erfahrung aus dem letzten Durchgang ist nur noch teilweise abrufbar. Wer diese Arbeit auf eine einzelne Person stützt, hat kein Wissensproblem, sondern ein Verfügbarkeitsproblem.
Die Gegenmittel sind bekannt: Dokumentation, ein zweiter Kopf im Thema, ein Testcluster für den Probelauf. Alle drei kosten laufend etwas für einen Nutzen, der zweimal im Jahr eintritt.
Wann Selbstbetrieb passt
Er passt, wenn die Plattform selbst Teil des eigenen Produkts ist oder wenn die Anforderungen Kontrolle über jede Schicht verlangen. Er passt weniger, wenn der Cluster die Grundlage für Applikationen ist und sonst nichts.
Wo sich die Plattformebene abgeben lässt
Control Plane, Kubernetes-Version und Upgrades, Betriebssystem und Patching der Nodes, Netzwerk und Storage lassen sich betreiben lassen, während die Applikationsebene im eigenen Haus bleibt. Namespaces, Deployments, Images, Ressourcen und Berechtigungen ändern dabei den Besitzer nicht.
Die Matrix verschwindet nicht, aber sie wird zur Aufgabe einer anderen Stelle.
Wo diese Grenze bei Netstream verläuft und was ein eigener Cluster auf Schweizer Infrastruktur kostet, finden Sie auf der Seite Managed Kubernetes.
