Mit der Mission, Freude zu verbreiten: Kubernetes 1.30 alias Uwubernetes

Das neue Kubernetes-Release schließt die Refaktorierung des Volume Managers ab und schaltet das effizientere Bereitstellen von Pods im Cluster frei.

In Pocket speichern vorlesen Druckansicht 6 Kommentare lesen
Macro,Shot,Of,Silicon,Wafer,During,Production,At,Advanced,Semiconductor

(Bild: Pasuwan/shutterstock.com)

Lesezeit: 3 Min.

Mit Version 1.30 der Container-Orchestrierungsplattform legt das Kubernetes-Entwicklungsteam unter Führung von Kat Cosgrove das nach eigener Aussage bisher „niedlichste Release“ vor: Uwubernetes. Im Zeichen von UwU – einem Katzen-Emoticon, das für Glück und Niedlichkeit steht – verspricht Kubernetes 1.30 einen Schwung von insgesamt 45 Verbesserungen. Darunter finden sich etwa die Planungsbereitschaft (Scheduling Readiness) von Pods sowie von der Special Interest Group (SIG) Storage beigesteuerte Refaktorierungen rund um den Volume Manager, die nun offiziell als stabilisierte Features gelten.

Kubernetes v1.30: Uwubernetes

(Bild: kubernetes.io)

Um nach einem Rechner- oder Kubelet-Neustart eine zuverlässigere Bereinigung von Volumes gewährleisten zu können, hatte das Entwicklungsteam den Volume Manager schon in früheren Releases überarbeitet. Die zunächst als Beta verfügbaren Änderungen verschaffen Kubelet bereits beim Start zusätzliche detaillierte Informationen über das Mounten bestehender Volumes. Laut Ankündigung im Kubernetes-Blog sollen sich dadurch für Benutzer- oder Cluster-Administratoren keinerlei Änderungen ergeben. Im Fall etwaige Probleme ließ sich jedoch via NewVolumeManagerReconstruction auf das ursprüngliche Verhalten zurücksetzen. Nun, da das Feature mit Freigabe von Kubernetes 1.30 jedoch generell verfügbar ist, ist auch das Feature Gate gesperrt und lässt sich nicht mehr deaktivieren.

Eine weitere von der SIG Storage beigesteuerte Neuerung, die nun offiziell als stabil gilt, betrifft unbefugte Änderungen an Volume-Modi, während ein Snapshot in ein PersistentVolume wiederhergestellt wird. Die Controlplane von Kubernetes 1.30 verhindert solche Änderungen nun grundsätzlich. Wollen Cluster-Admins Änderungen während der Wiederherstellung dennoch zulassen, müssen sie den betreffenden Auftraggebern – beispielsweise ServiceAccounts – die erforderlichen Berechtigungen explizit zuweisen. Zu beachten ist in diesem Zusammenhang außerdem ein dringender Upgrade-Hinweis des Entwicklungsteams den external-provisioner 4.0.0 sowie den external-snapshotter 7.0.0 betreffend. In beiden ist das Feature Flag prevent-volume-mode-conversion nämlich standardmäßig aktiviert und verhindert Modi-Änderungen.

Die in Version 1.27 als Betafunktion eingeführte Planungsbereitschaft von Pods (Pod Scheduling Readiness) gilt mit dem neuen Kubernetes-Release ebenfalls als stabil und damit generell verfügbar. Anhand der .spec.schedulingGates eines Pods lässt sich festlegen, ob und wann er für die Planung berücksichtigt werden soll. Ansonsten würde Kubernetes für bereits definierte Pods immer wieder versuchen sie einzuplanen, auch wenn der Cluster noch gar keine Ressourcen provisioniert hat, um den Pod an einen Node zu binden. Insbesondere bei aktiviertem Cluster Autoscaling trägt der Einsatz der Scheduling Gates dazu bei, den Scheduler zu entlasten und Kosten zu sparen.

Unter den Änderungen, die den Status eines Beta-Features erreicht haben, finden sich die strukturierte Autorisierungs- und strukturierte Authentifizierungskonfiguration sowie kontextbezogene Protokollierung. Einen Überblick zu den wichtigsten Neuerungen in Kubernetes 1.30 können sich Interessierte im Blogbeitrag zum Uwubernetes-Release verschaffen. Eine komplette Liste aller Änderungen liefert das Change-Log im GitHub-Repo.

(map)