Was ist neu in Kubernetes, und wofür ich aktualisiere

Kubernetes veröffentlicht ungefähr dreimal im Jahr eine neue Nebenversion. Jede Version enthält einen langen Changelog, einen Blogbeitrag voller Verbesserungsnummern und eine Liste von Funktionen, die von Alpha über Beta zu stabil wechseln. Es ist leicht, es zu übersehen und weiterzumachen.

Aber ein paar Änderungen in jeder Version wirken sich wirklich auf die Art und Weise aus, wie wir Cluster betreiben. Und einige von ihnen, die Umzüge, können Dinge am Upgrade-Tag kaputt machen. So lese ich eine Pressemitteilung, und die jüngsten Änderungen sind für mich am wichtigsten.

Wie ich eine Kubernetes-Version lese

Ich sehe vier Dinge an, in dieser Reihenfolge:

1. Absetzungen und Abbauungen. Was wird kaputt, wenn ich ein Upgrade mache? Das ist der einzige Abschnitt, der dir wehtun kann.
2. Die Eigenschaften sind stabil. Diese sind sicher zu verlassen und bedeuten normalerweise, dass ich eine Umgehungsmethode oder ein Add-on fallen lassen kann.
3. Funktionen gehen in Beta. Das ist jetzt oft standardmäßig aktiviert, das ist eine Prüfung wert.
4. Alles andere. Interessant, aber selten dringend.

Neueste Highlights, die es wert sind, zu erfahren

In den letzten Versionen sind einige lang erwartete Features stabil geworden. Das sind die, die ich sehe, die einen echten Unterschied machen:

Einheimische Sidecar-Container. Sidecars (Log-Sendern, Stellvertretern, Agenten) waren früher normale Container ohne garantierte Start- oder Stopp-Reihenfolge. Jetzt können Sie sie als init-Container mit restartPolicy: Always: sie beginnen vor dem Hauptbehälter und halten danach an. Das löst eine ganze Familie von lästigen Fehlern, wie Jobs, die nie zu Ende gehen, weil der Seitenwagen läuft.

- Die Ressource in der Pod-Platzgröße ändern. Sie können die CPU und Speicherwünsche und -limits einer laufenden Kapsel ändern, ohne sie neu zu starten. Perfekt für Workloads, die mehr Ressourcen beim Start benötigen, oder für vertikale Autoskalierung ohne Unterbrechung.

Dynamische Ressourcenzuteilung (DRA). Eine flexible Möglichkeit, spezielle Hardware, insbesondere GPUs, mit mehr Details als einer einfachen Zählung anzufordern. Wichtig für jeden, der KI-Workloads betreibt.

Die API-Reife des Gateways. Nicht Teil der Kernversionen von Kubernetes, aber in der Praxis mit ihnen verbunden. Mit der Einstellung von ingress-nginx ist die Gateway API nun der Standardweg, um den Traffic in einen Cluster zu bringen. Ich schrieb über diese Migration in Tschüss Ingress-nginx, hallo Gateway API.

Entfernung alter Grundlagen. Die Abkehr von cgroup v1 und älteren Container-Runtime-Versionen hat sich fortgesetzt. Wenn Ihre Knoten eine alte Linux-Distribution oder einen alten Container ausführen, überprüfen Sie die Release-Notes sorgfältig, bevor Sie ein Upgrade durchführen.

Ein Kubernetes-Upgrade bricht selten wegen neuer Funktionen. Es bricht wegen des alten Dinges, das du vergessen hast, dass du es noch benutzt.

Meine Checkliste für Upgrades

Was auch immer die Veröffentlichung ist, meine Routine ist die gleiche:

1. Lesen Sie die Abbau- und Verlegungsanweisungen. Alle, auch wenn es langweilig ist.
2. Scannen nach veralteten APIs in den Cluster und in Ihren Manifests mit Tools wie Pluto oder Kürbchen:

pluto detect-all-in-cluster
pluto detect-files -d ./manifests

3. Überprüfen Sie Ihre Add-ons. Eintritts- oder Gateway-Controller, CNI, CSI-Treiber, Zertifikatsmanager, Überwachungsbeauftragte, Service-Mesh. Jeder hat seine eigenen unterstützten Kubernetes-Versionen.
4. Erst ein nichtproduktives Cluster aufwerten und lassen Sie es eine Weile laufen.
5. Aktualisieren Sie die Steuerungsebene, dann Knotenpools, eine kleine Version nach der anderen. Kubernetes unterstützt nicht das Überspringen von Nebenversionen für die Steuerung.
6. Schauen Sie sich PodDisruptionBudgets an. Eine PDB, die keine Störungen zulässt, wird Knotenabflüsse blockieren.
7. Haben Sie einen Rückschaltplan für Knoten. Kontrollplätze können normalerweise nicht heruntergestuft werden, aber Knotenpools können neu erstellt werden.

Wie oft soll man das Upgrade durchführen?

Jede Nebenversion von Kubernetes erhält etwa ein Jahr Patch-Support vorne. Managed Services wie EKS, AKS und GKE haben eigene Fenster und einige berechnen zusätzlich für erweiterten Support älterer Versionen.

Meine Regel: Bleiben Sie innerhalb von ein oder zwei Versionen der neuesten. Regelmäßige Upgrades in kleinen Schritten sind viel weniger schmerzhaft als ein großer Sprung alle zwei Jahre, wenn alles auf einmal veraltet wird.

Ist es jetzt das Upgraden wert?

Normalerweise ja, sobald die erste Patch-Veröffentlichung (x.y.1 oder x.y.2) erscheint und Ihr Managed Provider sie unterstützt. Stabile Funktionen wie native Sidecars und die Stellgrößenänderung sind es wert, und wenn man aktuell bleibt, kommen immer wieder Sicherheitsfixes.

Meine Meinung: Lesen Sie zuerst die Entfernungen, testen Sie auf einem Cluster, den Sie nicht mögen, und aktualisieren Sie oft genug, damit es nie ein Projekt wird.

Desly