Kubernetes-Upgrade auf Kapsule ohne Schrecken

Kubernetes-Upgrades haben einen schlechten Ruf, den sie aus der Zeit der selbst gebauten Cluster mitbringen. Auf einem Managed-Angebot wie Kapsule ist ein Upgrade ein Klick und zwanzig Minuten Warten. Der Schrecken kommt nicht vom Upgrade selbst, sondern von dem, was man davor nicht geprüft hat.

Was übernimmt Scaleway beim Upgrade und was nicht?

Kapsule aktualisiert die Steuerungsebene auf Wunsch automatisch, aber nur Patch-Versionen innerhalb eines Wartungsfensters. Von 1.31.2 auf 1.31.4 passiert nachts von allein. Von 1.31 auf 1.32 passiert nur, wenn jemand es auslöst. Und es geht nur ein Minor pro Schritt: Wer auf 1.30 steht und 1.33 will, macht drei Upgrades.

Die Node-Pools werden beim Upgrade der Steuerungsebene nicht automatisch mitgezogen, es sei denn, man wählt es. Ein Cluster mit Steuerungsebene 1.32 und Nodes auf 1.31 läuft, Kubernetes erlaubt den Kubelets einige Minor-Versionen Rückstand. Aber er läuft mit einem Wartungsrückstand, der beim nächsten Upgrade zum Blocker wird.

Was prüfen Sie vor dem Klick auf „Upgrade“?

1. Zielversion ansehen. Nur die nächste Minor-Version und neuere Patches der aktuellen sind erreichbar. Die Kapsule-API listet sie; wer sie nicht sieht, steht vielleicht auf einer Version, die Scaleway nicht mehr unterstützt, und muss zuerst dorthin.
2. Add-ons prüfen. Jedes Helm-Chart hat einen kubeVersion-Bereich. Ein ingress-nginx, dessen Chart die Zielversion ausschließt, läuft nach dem Upgrade vielleicht weiter, lässt sich aber nicht mehr aktualisieren. cert-manager und der Reflector genauso. Erst Add-ons auf eine Version bringen, die beide Kubernetes-Versionen abdeckt, dann Kubernetes.
3. Entfernte APIs suchen. Jede Minor-Version entfernt veraltete API-Gruppen. Ein Manifest, das noch policy/v1beta1 nutzt, gilt nach dem Upgrade nicht mehr. Der Deprecation-Guide von Kubernetes listet sie pro Version.
4. PodDisruptionBudgets und Replikas. Beim Nachziehen eines Pools werden Nodes entleert. Ein Deployment mit einer Replika ist dabei kurz weg. Zwei Replikas oder ein Wartungsfenster, in dem das egal ist.
5. Volumes. Ein Pod mit ReadWriteOnce-Volume kann nur auf einem Node laufen. Beim Entleeren wandert er, das dauert, solange der Datenträger umgehängt wird. Einplanen, nicht wundern.

Der Ablauf

Erst die Steuerungsebene. Kapsule tauscht sie im Hintergrund, die API ist für einige Sekunden nicht erreichbar, laufende Pods merken nichts. Dann die Pools, einer nach dem anderen: Neue Nodes mit der neuen Version kommen hoch, alte werden entleert und entfernt. Für einen Pool mit drei Nodes sind das etwa zehn Minuten, für den ganzen Cluster zwanzig bis dreißig.

Was man in dieser Zeit sieht: Nodes mit unterschiedlichen Kubelet-Versionen, Pods, die umziehen, kurz einen Node mehr als sonst. Was man nicht tun sollte: währenddessen deployen oder ein Add-on aktualisieren. Ein Upgrade zur Zeit.

Nach dem Upgrade

• Stehen alle Nodes auf der Zielversion? Ein Node, der beim Entleeren hing, bleibt sonst zurück.
• Laufen alle Pods, die vorher liefen? Ein Pod, der auf einem veralteten API-Objekt hing, kommt nicht wieder.
• Sind die Add-ons noch aktuell für die neue Version, oder steht jetzt ein Add-on-Upgrade an?

Danach ist Ruhe bis zum nächsten Quartal. Das ist der eigentliche Trick: ein Upgrade pro Quartal, klein, langweilig, statt eines pro zwei Jahre, das alles auf einmal ändert. Regelmäßige Upgrades sind zugleich einer der Belege, die ein Prüfer unter NIS2 sehen will, siehe Audit & NIS2 und NIS2 im Kubernetes-Betrieb.

Gibt es einen Weg zurück?

Kubernetes-Upgrades sind nicht umkehrbar. Es gibt kein Downgrade der Steuerungsebene. Der Rückweg ist ein neuer Cluster auf der alten Version und ein Umzug der Workloads, was auf Kapsule mit einem zweiten Cluster im selben privaten Netz machbar, aber kein Knopfdruck ist. Deshalb die Checkliste, deshalb Staging zuerst.

Ein Upgrade, Schritt für Schritt

So sieht ein Quartals-Upgrade eines kleinen Produktionsclusters mit zwei Pools aus, wie wir es regelmäßig durchführen:

1. Montag, Staging. Add-ons prüfen, Zielversion wählen, Upgrade mit Pools auslösen. Zwanzig Minuten warten, Anwendungen testen. Auffälligkeiten notieren.
2. Mittwoch, Produktion, außerhalb der Kernzeit. Add-ons, die auf Staging aktualisiert werden mussten, zuerst auf Produktion aktualisieren. Dann das Kubernetes-Upgrade mit Pools.
3. Während des Laufs. Nichts deployen. Die Cluster-Seite zeigt Nodes mit zwei Versionen, Pods, die umziehen, und den Fortschritt pro Pool.
4. Danach. Alle Nodes auf Zielversion, alle Pods laufen, Add-ons auf der neuen Version noch kompatibel. Notiz im Betriebsprotokoll, fertig.

Das Ganze dauert eine Stunde Aufmerksamkeit pro Quartal. Ein Upgrade über vier Minor-Versionen nach zwei Jahren dauert einen Tag, mit Überraschungen.

Die drei Überraschungen, die wir erlebt haben

• Ein Chart, das die neue Version ausschließt. Der Ingress-Controller lief nach dem Upgrade weiter, ließ sich aber nicht mehr per Helm aktualisieren, weil sein Chart die Kubernetes-Version nicht kannte. Seitdem: Add-ons zuerst.
• Ein Pod mit Volume, der beim Entleeren minutenlang hing. Der Datenträger musste vom alten Node gelöst und am neuen angehängt werden. Kein Fehler, nur Geduld. Seitdem steht es in der Checkliste.
• Ein Node, der beim Entleeren blieb. Ein PodDisruptionBudget mit minAvailable: 1 bei einem Deployment mit einer Replika. Das Budget kann nie erfüllt werden, der Node wird nie leer. Entweder zwei Replikas oder kein Budget.

Automatische Patches: ja, aber

Das Wartungsfenster für automatische Patch-Upgrades sollte an sein. Patches beheben Sicherheitslücken und ändern kein Verhalten. Aber legen Sie das Fenster in eine Zeit, in der jemand am nächsten Morgen auf den Cluster schaut, und nicht in die Nacht vor einem Feiertag.

Wie Clusterward das begleitet

Die Versionskarte zeigt nur Zielversionen, die Kapsule von hier aus erreicht. Das Upgrade verlangt den eingetippten Cluster-Namen, zieht die Pools auf Wunsch mit, wird im Hintergrund bis zum Ende überwacht und als Benachrichtigung gemeldet. Add-ons zeigen ihre Kompatibilität mit der Zielversion vorher an, und ein Add-on-Upgrade ist während eines Kubernetes-Upgrades gesperrt. Details unter Cluster-Updates.

Fazit

Ein Kapsule-Upgrade ist ein kleiner Vorgang, wenn Add-ons und APIs vorher stimmen. Machen Sie es pro Quartal, auf Staging zuerst, mit Pools nachgezogen. Der Schrecken ist nicht das Upgrade. Der Schrecken ist das Upgrade, das zwei Jahre gewartet hat.

Das nächste Kapsule-Upgrade vorbereiten? Schreiben Sie uns Ihre Kubernetes-Version und Ihre Add-ons. Wir sagen Ihnen, was vor dem Upgrade zu prüfen ist. Frage zum Upgrade stellen →

Quellen und weiterführende Links

• Kubernetes: Release-Zyklus (englisch)
• Scaleway: Kubernetes-Version eines Kapsule-Clusters aktualisieren (englisch)
• Kubernetes: Leitfaden zu veralteten APIs (englisch)
• Helm-Dokumentation: Charts (Feld kubeVersion) (englisch)