Containerisierung: Kubernetes 1.23 stabilisiert Betrieb mit zwei Netzwerk-Stacks

Neben dem Parallelbetrieb von IPv4 und IPv6 gelten generische Ephemeral Volumes im aktuellen Release der Container-Orchestirerung als stabil.

In Pocket speichern vorlesen Druckansicht

(Bild: Travel mania/Shutterstock.com)

Lesezeit: 3 Min.
Von
  • Rainald Menge-Sonnentag
Inhaltsverzeichnis

Mit Kubernetes 1.23 ist das dritte und letzte Release der Container-Orchestrierung in diesem Jahr erschienen. Es stabilisiert unter anderem den Dual-Stack-Betrieb im Cluster, den horizontalen Pod-Autoscaler und generische Ephemeral Volumes. Bei den neuen, zunächst als Alpha eingeführten Funktionen ist die serverseitige Validierung von Feldern und die Anbindung an die OpenAPI v3 nennenswert.

Insgesamt spricht der Blogbeitrag zum Release von elf stabilisierten und 19 neuen Funktionen. 17 nehmen in der aktuellen Version den Schritt von der Alpha- zur Betaphase. Dafür gilt der FlexVolume-Treiber nun als überholt (deprecated) und sollte durch das Container Storage Interface (CSI) ersetzt werden. Auch einige klog-spezifische Logging-Flags sind als überholt markiert und werden demnächst verschwinden.

Kubernetes 1.23 erlaubt nun nativ den in Version 1.20 als Alpha eingeführten Dual-Stack-Betrieb in einem Cluster. Damit können beliebige Pods und Dienste sowohl IPv4- als auch IPv6-Adressen erhalten. Mit der Stabilisierung entfällt das Feature-Gate IPv6DualStack. Auch wenn die Cluster im Dual-Stack-Betrieb laufen, arbeiten die einzelnen Pods und Service standardmäßig mit nur einem Protokoll.

Für Pods gibt das CNI-Plug-in (Container Network Interface) die Betriebsart vor. Um Services mit IPv4 und IPv6 parallel zu nutzen, muss das Feld .spec.ipFamilyPolicy entweder auf PreferDualStack oder auf RequireDualStack gesetzt sein. Trotz der Stabilisierung ist der Dual-Stack-Betrieb nicht verpflichtend, sondern weiterhin optional. Da er von diversen Faktoren wie den CNI-Interfaces abhängt, kann es laut einem Blogbeitrag durchaus sein, dass einzelne Kubernetes-Distributionen keine vollständige Integration bieten.

Die generischen Ephemeral Volumes gelten im aktuellen Release ebenfalls als stabil. Damit lassen sich Storage-Treiber dynamische Volumes für einzelne Pods erstellen. Im Gegensatz zu den Persistent Volumes ist ihre Lebensdauer an die zugehörigen Pods gebunden und somit flüchtig oder kurzlebig (ephemeral).

Kubernetes bietet unterschiedliche Arten von flüchtigen Volumes von einem zum Start leeren emptyDir über CSI Ephemeral Volumes bis zu den nun stabilisierten generischen Ephemeral Volumes. Dabei handelt es sich um eine Erweiterung von emptyDir-Volumes, die unter anderem eine feste Größe aufweisen und wahlweise lokal oder im Netzwerk existieren können. Außerdem erlauben sie im Vergleich zu emptyDir zusätzliche Funktionen wie Snapshots, Klonen, Größenänderungen und ein Tracking der Storage-Kapazität.

Bei den weiteren stabilisierten Funktionen ist der HorizontalPodAuocaler v2 interessant. Er skaliert automatisch die Anzahl der Pods eines Replication Controller, Deployments oder Replika-Set auf der Basis von vorgegebenen Metriken beziehungsweise jeweiligen CPU-Auslastung.

Den Weg von der Alpha- in die Betaphase haben unter anderem die PodSecurity zum Definieren von Isolationsstufen für Pods und das strukturierte Logging genommen.

Das Logo für Version 1.23 spielt auf Star Trek: New Frontier an

(Bild: Kubernetes.io)

Bei den Neuzugängen, die zunächst Alphastatus haben, ist die Anbindung an OpenAPI v3 nennenswert, die sich über das Feature Gate OpenAPIV3 aktivieren lässt. Ist das ebenfalls neue Feature Gate ServerSideFieldValidation aktiviert, gibt der Server Warnungen zurück, wenn Kubernetes-Objekte unbekannte oder doppelte Felder enthalten.

Zusätzlich neu und als Alpha markiert ist das Validieren von Custom Resource Definitions (CRD) mit der Common Expression Language (CEL).

Weitere Neuerungen in Kubernetes 1.23 lassen sich der Ankündigung im Kubernetes-Blog entnehmen.

(rme)