Kubernetes 1.26 - Electrifying
 "Kubernetes 1.26 - Electrifying")
Wichtige Neuerungen
Änderung in der Container-Image-Registry
In der vorherigen Version änderte Kubernetes die Container Registry und ermöglichte die Verteilung der Last auf mehrere Cloud-Provider und Regionen, eine Änderung, die die Abhängigkeit von einer einzigen Registry verringert und damit schnellere Downloads der Kubernetes Core Komponenten erlaubt.
Diese Version von Kubernetes ist die erste, die ausschließlich in der neuen Container Image Registry registry.k8s.io veröffentlicht wird. In der (nun veralteten) k8s.gcr.io Image Registry werden keine Container Image Tags für v1.26 veröffentlicht, und nur Tags von Versionen vor v1.26 werden weiterhin aktualisiert. Unter registry.k8s.io findet ihr weitere Informationen über die Motivation, die Vorteile und die Auswirkungen dieser Änderung.
CRI v1alpha2 entfernt
Mit der Einführung des Container Runtime Interface (CRI) und der Entfernung von dockershim in v1.24 ist ab sofort das CRI in der Version v1 die einzige unterstützte und dokumentierte Methode, über die Kubernetes mit verschiedenen Container Engines interagiert.
In der vorherigen Version empfahl das Kubernetes-Projekt die Verwendung von CRI Version v1, aber der kubelet konnte immer noch das CRI in der Version v1alpha2 nutzen.
Mit Kubernetes v1.26 wird die Unterstützung für das CRI v1alpha2 eingestellt. Diese Entfernung führt dazu, dass der kubelet den Knoten nicht registriert, wenn die Container-Laufzeitumgebung in Version v1 nicht unterstützt wird. Im Umkehrschluss bedeutet dies, dass die Minor Version von containerd 1.5.0 und ältere in k8s 1.26 nicht mehr unterstützt werden können; wenn ihr containerd verwendet, müsst ihr auf containerd Version 1.6.0 oder höher aktualisieren, bevor ihr die Nodes auf Kubernetes v1.26 aktualisieren könnt. Dies gilt auch für alle anderen Container-Laufzeiten, die nur v1alpha2 unterstützen.
Storage Verbesserungen
Seit Einführung der CSI-Migration (Container Storage Interface) in der vorherigen Version von Kubernetes ist die Migration ein fortlaufendes Projekt, an dem K8s seit einigen Versionen arbeitet. In dieser Version werden weitere Funktionen hinzugefügt (und entfernt), die für die Migration alter Storageclasses erforderlich sind.
Die CSI-Migration für Azure File und vSphere wurde auf stable eingestuft
Passend zum Thema CSI-Migration hat sowohl die vSphere als auch die Azure In-Tree-Migration zu CSI den Status "Stable" erreicht. Weitere Informationen findet ihr in den Repositories für des vSphere-CSI-Treibers und des Azurefile-CSI-Treibers.
Übergabe der fsGroup an den CSI-Treiber ist nun stable
Diese Funktion ermöglicht es Kubernetes, die fsGroup des Pods an den CSI-Treiber zu übermitteln, wenn ein Volume gemountet wird, sodass der entsprechende Storage Treiber die Mount-Optionen zur Steuerung der Volume-Berechtigungen verwenden kann. Bisher hat der kubelet immer die fsGroup Ownership und die Berechtigungsänderung auf Dateien im Volume gemäß der im Feld .spec.securityContext.fsGroupChangePolicy des Pods angegebenen Richtlinie angewendet. Ab dieser Version haben CSI-Treiber die Möglichkeit, die fsGroup Einstellungen während des mountens der Volumes dynamisch anzupassen.
Entfernung des In-Tree GlusterFS-Treibers
Der In-Tree GlusterFS-Treiber, der bereits in der Version v1.25 veraltet war, wurde in dieser Version entfernt.
Entfernung des In-Tree OpenStack Cinder-Treibers
In dieser Version wurde der veraltete In-Tree Storage für OpenStack (Cinder) entfernt. Ihr solltet stattdessen zu einem externen Cloud-Anbieter und dem CSI-Treiber von https://github.com/kubernetes/cloud-provider-openstack migrieren. Für weitere Informationen besucht: Cinder in-tree to CSI driver migration.
Signieren von Kubernetes-Release-Artefakten geht in die Betaphase
Diese Funktion wurde in Kubernetes v1.24 eingeführt und ist ein wichtiger Meilenstein bei der Verbesserung der Sicherheit des Kubernetes-Release-Prozesses. Alle Release-Artefakte werden mittels cosign schlüssellos signiert, und sowohl binäre Artefakte als auch Images können ab sofort verifiziert werden.
Unterstützung für Windows-privileged Container wird stable
Die Unterstützung von privilegierten Containern ermöglicht die Ausführung von Containern mit ähnlichem Zugriff auf den Host wie Prozesse, die direkt auf dem Host laufen. Die Unterstützung für diese Funktion in Windows-Nodes, HostProcess-Container genannt, wird nun in Stable übergehen und den Zugriff auf Host-Ressourcen (einschließlich Netzwerkressourcen) durch privilegierte Container ermöglichen.
Verbesserungen der Kubernetes-Metriken
Metrics framework extension erreicht den Alpha Status
Die Erweiterung des Metrics-Frameworks geht in die Alpha-Phase über und die Dokumentation wird nun für jede Metrik in der Kubernetes-Codebasis veröffentlicht. Diese Verbesserung fügt den Kubernetes-Metriken zwei zusätzliche Metadaten hinzu: Internal und Beta, welche die Unterscheidung von internen bzw. sich in der Beta befindlichen Metriken ermöglichen.
Component Health Service Level Indicators erreichen die Alphaphase
Die Möglichkeit, Kubernetes-Metriken zu nutzen, wurde ebenfalls verbessert. Die Service-Level-Indikatoren (SLIs) für die Komponenten wurden in die Alpha-Version aufgenommen: Durch die Aktivierung des ComponentSLIs Feature-Flags steht ein zusätzlicher Metrics-Endpunkt zur Verfügung, der die Berechnung von Service-Level-Objectives (SLOs) aus ins Metrics-Format konvertierten Healthcheck-Daten ermöglicht.
Feature Metrics sind jetzt verfügbar
Feature-Metriken sind jetzt für jede Kubernetes-Komponente verfügbar, sodass es möglich wird, einzusehen, welches Feature-Gates gerade aktiviert ist. Die entsprechende Metrik findet ihr unter kubernetes_feature_enabled.
Dynamische Ressourcenzuweisung wird in die Alphaversion übernommen
Die dynamische Ressourcenzuweisung ist eine neue Funktion, die die Ressourcenplanung in die Hände von Drittentwicklern legt: Sie bietet eine Alternative zur begrenzten "zählbaren" Schnittstelle für die Anforderung des Zugriffs auf Ressourcen (z. B. nvidia.com/gpu: 2) und stellt eine API bereit, die eher der von persistenten Volumes ähnelt. Im Hintergrund verwendet diese Funktion das Container Device Interface (CDI), um die entsprechenden Devices an die Container zu hängen. Diese Funktion kann durch das Feature Flag DynamicResourceAllocation aktiviert werden.
Verbesserungen beim Pod-Scheduling
PodSchedulingReadiness ist nun in der Alpha
Diese Funktion führt ein .spec.schedulingGates Feld in die Pod-API ein, welches angibt, ob der Pod gescheduled werden darf oder nicht. Externe User/Controller können dieses Feld verwenden, um einen Pod aufgrund ihrer Richtlinien und Bedürfnisse vom Scheduling auszuschließen. Spannend wird dieses Feature vor allem dadurch, dass es nun möglich ist, über individuelle Applikationen / Controller programmatisch entscheiden zu können, ob ein Pod starten kann oder nicht.
Auch sind über dieses Feature erweiterte Readiness Checks denkbar (Beispiel: Starte das Backend erst, wenn die erforderliche Datenbank gestartet ist).
NodeInclusionPolicy sowie InPodTopologySpread geht in die Betaphase
Durch Angabe einer nodeInclusionPolicy in topologySpreadConstraints könnt ihr steuern, ob Taints/Tolerations bei der Berechnung der Pod Topology Spread berücksichtigt werden sollen.