Kubernetes 1.33 stabilisiert 24 Features und bringt zahlreiche Neuerungen
Kubernetes 1.33 stabilisiert 24 Features und bringt zahlreiche Neuerungen
Allgemein verfügbar: backoffLimit, –subresource und .spec.successPolicy
Neue Alpha- und Beta-Funktionen
Abschied von der ursprünglichen Endpoints-API•
Kubernetes 1.33 stabilisiert 24 Features und bringt zahlreiche Neuerungen
Allgemein verfügbar: backoffLimit, –subresource und .spec.successPolicy
Neue Alpha- und Beta-Funktionen
Abschied von der ursprünglichen Endpoints-API
Allgemein verfügbar: backoffLimit, –subresource und .spec.successPolicy
Neue Alpha- und Beta-Funktionen
Abschied von der ursprünglichen Endpoints-API•
Allgemein verfügbar: backoffLimit, –subresource und .spec.successPolicy
•
Neue Alpha- und Beta-Funktionen
•
Abschied von der ursprünglichen Endpoints-API
Kubernetes liegt nun in Version 1.33 vor, die planmäßig das erste Minor Release in diesem Jahr darstellt. Die Container-Orchestrierung präsentiert darin 24 bestehende Features als stabil, während die Alpha- und Beta-Funktionen Zuwachs erhalten haben. Allerdings beginnt mit dieser Version auch der Abschied von einigen veralteten Features, darunter die Endpoints-API. Das Theme lautet diesmal „Octarine: The Color of Magic“, inspiriert von Terry Pratchetts „Scheibenwelt“-Romanreihe.Allgemein verfügbar: backoffLimit, –subresource und .spec.successPolicyDer Parameter backoffLimit in Kubernetes-Jobs dient dazu, die Anzahl erneuter Versuche festzulegen, bevor ein gesamter Job als fehlgeschlagen gilt. Als stabiles Feature lassen sich nun die Backoff Limits je nach Index für indizierte Jobs festlegen. Das bedeutet, jeder Index innerhalb eines indizierten Jobs darf seine eigene Backoff-Grenze besitzen, was Entwicklerinnen und Entwicklern eine feiner abgestufte Kontrolle ermöglicht. Das Fehlschlagen eines spezifischen Indizes führt dann nicht zu einem frühzeitigen Fehlschlagen des gesamten Jobs.„`
backoffLimit
„`Ein weiteres jetzt allgemein verfügbares Feature ist .spec.successPolicy. Damit lässt sich definieren, welche Pod-Indizes erfolgreich sein müssen (succeededIndexes), wie viele Pods erfolgreich sein müssen (succeededCount) oder eine Kombination aus beidem. Das soll unterschiedlichen Workloads zugutekommen, inklusive Simulationen, in denen eine partielle Fertigstellung ausreicht.„`
.spec.successPolicy
„„„
succeededIndexes
„„„
succeededCount
„`Neben weiteren Features hat ab sofort auch –subresource den stabilen Status erreicht. Es handelt sich dabei um ein Argument für kubectl-Unterbefehle wie get, patch, edit, apply oder replace, um Unterressourcen für alle Ressourcen, die sie unterstützen, abzurufen und zu aktualisieren.„`
–subresource
„„„
get
„„„
patch
„„„
edit
„„„
apply
„„„
replace
„`Neue Alpha- und Beta-FunktionenIn Kubernetes 1.14, im Jahr 2019 eingeführt, ist der Support für Direct Service Return (DSR) unter Windows in die Beta-Phase übergegangen. Dieses Feature dient der Performance-Optimierung: Return Traffic, der durch den Load Balancer geroutet wird, kann durch DSR den Load Balancer umgehen und dem Client direkt antworten. Das reduziert die Last auf dem Load Balancer und verringert die Gesamtlatenz.Etwas neuer ist die SupplementalGroupsPolicy: Seit Kubernetes 1.31 vorhanden, hat sie nun die Beta-Phase erreicht und ist standardmäßig aktiviert. Die Funktion soll dazu beitragen, dass implizite Gruppenmitgliedschaften von Container-Images nicht zu unbeabsichtigten Dateizugriffsberechtigungen führen und Policy-Steuerungen umgehen können.„`
SupplementalGroupsPolicy
„`Zu den neuen Alpha-Features zählt eine konfigurierbare Toleranz für HorizontalPodAutoscalers. Das soll Skalierungsreaktionen auf kleine metrische Variationen abmildern. Darüber hinaus stehen Node-Topology-Label mittels Downward-API bereit. Diese Alpha-Funktion soll die Art und Weise vereinfachen, wie Workloads auf Node-Topologie-Informationen zugreifen.„`
HorizontalPodAutoscalers
„`Abschied von der ursprünglichen Endpoints-APIIm aktuellen Kubernetes-Release gelten einige Funktionen als veraltet (deprecated) oder entfallen gänzlich. Viele dieser Änderungen wurden bereits im Vorfeld auf dem Kubernetes-Blog behandelt. Dabei folgt das Kubernetes-Team einigen Regeln: Unter anderem markiert es stabile APIs nur dann als veraltet, sobald eine neuere, stabile Version bereitsteht. Bis zu ihrer Entfernung funktioniert eine veraltete API weiterhin, allerdings erscheint ein Warnhinweis.In Version 1.33 betrifft das unter anderem die Endpoints-API. Als Ersatz steht die neuere EndpointSlices-API bereit, die seit Kubernetes 1.21 stabil ist und zusätzliche Funktionen wie Dual-Stack-Networking bietet. Dabei soll diese Deprecation nur solche Entwicklerinnen und Entwickler betreffen, die die Endpoints-API direkt aus Workloads oder Scripts verwenden. Sie sind dazu angehalten, nun zur EndpointsSlices-API zu migrieren.Gänzlich entfällt status.nodeInfo.kubeProxyVersion. Der Wert dieses Feldes – die Versionsinformation zu kube-proxy im Node-Status – wurde von kubelet gesetzt, war jedoch nicht konsistent akkurat. Bereits mit Kubernetes 1.31 wurde es als veraltet markiert und war seitdem standardmäßig deaktiviert. Zudem entfällt der Host-Netzwerk-Support für Windows-Pods – ein Feature, das auf unerwartete Schwierigkeiten mit containerd gestoßen war und nie den stabilen Status erreicht hatte. Der Verlauf lässt sich im GitHub-Issue nachverfolgen.„`
status.nodeInfo.kubeProxyVersion
„`Weitere Informationen bieten die Ankündigung zu Version 1.33 auf dem Kubernetes-Blog sowie der Changelog auf GitHub.(mai)