Was ist neu in Kubernetes v1.23?

0
150
Piotr Swat/Shutterstock.com< /figure>

Kubernetes v1.23 ist die letzte Hauptversion des Jahres 2021. Das neueste Update der führenden Container-Orchestrierungsplattform befördert 11 Funktionen in den stabilen Kanal und markiert sie als für den allgemeinen Gebrauch geeignet. Folgendes müssen Sie vor dem Upgrade wissen.

Dual-Stack-IPv4/IPv6-Netzwerk

Dual-Stack-IPv4 /IPv6-Netzwerke sind in v1.23 allgemein verfügbar. Die Funktion ermöglicht es, einem Pod oder Dienst sowohl IPv4- als auch IPv6-Adressen zuzuweisen. Sie benötigen Dual-Stack-Netzwerkschnittstellen auf Ihren Knoten und ein unterstützendes CNI-Netzwerk-Plugin, damit dies funktioniert.

Das Feld .spec.ipFamilyPolicy definiert, ob ein Pod oder Dienst eine Single- oder Dual-Stack-Schnittstelle empfängt. Setzen Sie es auf PreferDualStack oder RequireDualStack, um die Dual-Stack-Unterstützung zu aktivieren. Die Standardeinstellung ist SingleStack.

Spezifikation: ipFamilyPolicy: RequireDualStack

Dual-Stack-Modi weisen Service-Cluster-IPs sowohl aus dem IPv4- als auch aus dem IPv6-Adressraum zu. Sie können die Stack-Präferenzreihenfolge mit dem .spec.ipFamilies-Feld festlegen. Dadurch kann auch entweder IPv4 oder IPv6 als Familie für den SingleStack-Modus angegeben werden.

Ephemeral Volumes

Ephemere Bände sind eine weitere Abstufung zum GA-Status. Ein kurzlebiges Volume ist an einen Pod gebunden und wird gelöscht, wenn der Pod beendet wird. Es funktioniert mit allen vorhandenen Speichertreibern, die die dynamische Bereitstellung unterstützen.

Werbung

Vorläufige Volumes werden erstellt, indem eine volumeClaimTemplate unter einem neuen kurzlebigen Feld im Volume-Abschnitt einer Pod-Spezifikation verschachtelt wird. Das volumeClaimTemplate sollte einem normalen PersistentVolumeClaim ähneln.

spec: volume: – name: ephemeral-volume ephemeral: volumeClaimTemplate: Metadaten: Labels: Typ: Beispiel-Volume-Typ spec: accessModes: ["ReadWriteOnce"] storageClassName: example-storage-class Ressourcen: Anfragen: Speicher: 1Gi

Während eine “ephemere” Lautstärke mag zunächst seltsam klingen, es gibt mehrere Anwendungsfälle für diese Funktionalität. Volumes werden häufig verwendet, um einem Pod-Prozess Erstausführungskonfigurationswerte bereitzustellen, auf die nur einmal zugegriffen wird. In diesem Szenario ist ein kurzlebiger Pod ideal, da er gelöscht wird, wenn der Pod stoppt, anstatt erneut an zukünftige Pods angehängt zu werden, die die Daten nie verwenden. Ein anderer möglicher Fall sind Prozesse, die große Datenmengen zwischenspeichern, aber nicht zwischen einzelnen Pod-Beendigungen beibehalten werden müssen.

Horizontal Pod Autoscaler v2< /h2>

Nach fünf Jahren ist v2 der Horizontal Pod Autoscaler API stabil. Mit Autoscaling kann Kubernetes die Replikatanzahl Ihrer Deployments, ReplicaSets und StatefulSets automatisch anpassen, um auf Änderungen der Echtzeitmetriken zu reagieren.

Diese Promotion wirkt sich derzeit nicht auf die ursprüngliche Autoscaling-Implementierung aus. Die v1-API bleibt verwendbar und wird nicht eingestellt. Die neue Autoscaling/v2-API ersetzt Autoscaling/v2beta2 früherer Kubernetes-Versionen.

Die Verwendung der v2-API ist vorteilhaft, da Sie Autoscaling-Entscheidungen basierend auf benutzerdefinierten Messwerten definieren können. Der Autoscaling-Controller führt beliebige API-Abfragen durch, um Änderungen an Replikaten mitzuteilen, anstatt Sie auf die CPU- und Speicherbedingungen des Knotens zu beschränken.

Überspringen von Volume-Ownership-Änderungen beim Pod-Start

Die Verwendung des fsGroup-Felds auf einem Volume zum Definieren seiner Eigentümerschaft führt derzeit dazu, dass Kubernetes rekursiv Führen Sie chown() und chmod() für den Inhalt des Volumes jedes Mal aus, wenn es in einen Pod gemountet wird. Dies kann ein erhebliches Leistungsproblem darstellen, wenn Sie mit großen Volumes arbeiten, die hauptsächlich aus kleinen Dateien bestehen. Der Pod startet erst, wenn die Berechtigungen geändert wurden.

Werbung

Kubernetes unterstützt ein fsGroupChangePolicy-Feld, mit dem Sie dieses Verhalten überschreiben können. Es ist jetzt allgemein über das securityContext-Feld eines Pods verfügbar. Wenn Sie die Änderungsrichtlinie auf OnRootMismatch setzen, wird chown() nur aufgerufen, wenn das Root des Volumes falsche Berechtigungen hat. Dies beschleunigt den Pod-Start, wenn die Berechtigungen bereits mit der fsGroup-Deklaration kompatibel sind.

securityContext: fsGroupChangePolicy: OnRootMismatch

Andere Highlights

Es gibt einige bemerkenswerte Ergänzungen zu den Alpha- und Beta-APIs. Der Beta-Kanal umfasst jetzt:

  • Strukturierte Protokollierung – Weitere Komponenten unterstützen das Protokollierungsformat für strukturierten Text, das eine JSON-Ausgabe erzeugt. Strukturierte Protokolle können von externen Tools leichter geparst werden, was vereinfachte Protokollaufnahme- und Abfrageprozesse vereinfacht.
  • PodSecurity API– PodSecurity ersetzt den älteren Zugangscontroller PodSecurityPolicy, mit dem Sie Sicherheitsregeln auf Namespace-Ebene erzwingen können. PodSecurity bietet einen Mechanismus, um festzulegen, dass Pods nicht in einem Namespace existieren können, wenn ihnen bestimmte Schutzmaßnahmen für den Sicherheitskontext fehlen.
  • Unterstützung für CSI-Migration– Diese Funktion bietet eine nahtlose Möglichkeit, von einem In-Tree-Speichertreiber, der Teil der Kubernetes-API ist, wie z. B. kubernetes.io/aws-ebs, zu einem bereitgestellten CSI-Treiber zu wechseln. Benutzer sollten nach Abschluss der Migration keine Änderungen an ihrem Speicher bemerken. Diese Funktionalität ist jetzt Beta für AWS EBS, Azure Disk und GCE PD. Es ist für Ceph RBD und Portworx als Alpha gekennzeichnet.

Im Alphakanal gibt es einige zusätzliche Funktionen, die ihr Debüt geben:

  • < strong>Serverseitige Feldvalidierung– Die serverseitige Feldvalidierung sendet Warnungen vom Server, wenn ein Client versucht, Ressourcen zu erstellen, die unbekannte oder duplizierte Felder enthalten. Kubernetes hat diese Felder in der Vergangenheit verworfen, was möglicherweise zu verwirrendem Verhalten führte. Das Aktivieren des ServerSideFeatureValidation-Feature-Gates bietet eine Möglichkeit, dies zu beheben.
  • Ausdruckssprachenvalidierung für CRDs – Eine neue Inline-Ausdruckssprache erleichtert die Validierung von benutzerdefinierten Ressourcendefinitionen (CRDs). Dies trägt dazu bei, den abstrakten Charakter von CRDs anzugehen, bei denen derzeit nicht garantiert werden kann, dass benutzerdefinierte Ressourcen die Anforderungen vorhandener Controller und Clientanwendungen erfüllen.
  • OpenAPI v3-Unterstützung– OpenAPI v3 wurde hinter einem Feature Gate (OpenAPIV3) hinzugefügt. Wenn diese Option aktiviert ist, können Sie die OpenAPI v3.0-Spezifikation für jeden der Kubernetes-Objekttypen anfordern und so Ressourcen programmgesteuert über offene API-Standards erkennen und durchlaufen.

Schlussfolgerung

Kubernetes v1.23 stabilisiert mehrere wichtige Funktionen, darunter Dual-Stack-Netzwerke, den neuen anpassbaren Horizontal Pod Autoscaler und kurzlebige Volumes für die Arbeit mit nicht kritischen Daten. Neben zwei veralteten Funktionen gibt es Dutzende weiterer Änderungen: die FlexVolume-Speichertreiberschnittstelle, die älter als CSI ist, und mehrere Protokollierungsflags, die in Zukunft entfernt werden.

Insgesamt 11 vorhandene Funktionen wurden auf . hochgestuft GA-Status. 17 weitere Funktionen sind jetzt als Beta markiert, während weitere 19 völlig neue Funktionen sind, die in der Alpha landen. Die Veröffentlichungsstrategie von Kubernetes konzentriert sich auf die frühzeitige Auslieferung der Funktionalität, ermöglicht es der Community, ihre Entwicklung zu steuern und API-Implementierungen zu rationalisieren. Während Alpha- oder Beta-Funktionen normalerweise in den stabilen Zustand übergehen, ist dies nicht garantiert. APIs können sich während des Entwicklungsprozesses erheblich ändern oder ganz entfernt werden.

Sie können die vollständigen Versionshinweise zu Version 1.23 auf GitHub lesen. Downloads sind auf der Release-Seite verfügbar. Sie können einen vorhandenen Cluster aktualisieren, der mit Kubeadm erstellt wurde, indem Sie die Anleitung in der Dokumentation befolgen. Der Prozess unterscheidet sich für Benutzer von Managed Cloud-Angeboten und Kubernetes-Distributionen von Drittanbietern.