Kubernetes 1.31 - Elli

Mithilfe von AppArmor könnt ihr eure Container schützen. Dafür müsst ihr nur das Attribut appArmorProfile.type innerhalb des securityContext eurer Container setzen. Vor Kubernetes 1.30 wurde AppArmor über Annotations konfiguriert und mit der Version 1.30 wurde die Konfiguration über das Attribut appArmorProfile.type eingeführt. Hier wird empfohlen die migration von den Annotations auf die Attribute vorzunehmen.

Mehr über AppArmor erfahrt ihr in dem AppArmor Tutorial.

Kube-proxy verbesserte Ingress-Konnektivitätszuverlässigkeit ist in der Version 1.31 stable. Eines der häufigsten Probleme bei Load Balancern in Kubernetes ist die Synchronisierung zwischen den verschiedenen Komponenten, um einen Datenverkehrsverlust zu vermeiden.

Dieses Feature implementiert einen Mechanismus im Kube-Proxy der es Load Balancern ermöglicht ein Connection Draining für Nodes durchzuführen, wenn der Load Balancer durch einen Service vom Typen LoadBalancer mit der Konfiguration externalTrafficPolicy: Cluster angelegt wurde. Außerdem werden auch Best Practices für Cloud-Anbieter und die Implementierung von Kubernetes-Load-Balancern festgelegt.

Um dieses Feature zu nutzen, muss Kube-Proxy als Default Service-Proxy im Cluster ausgeführt werden und der Load Balancer muss Connection Draining unterstützen. Es sind keine speziellen Änderungen erforderlich, da es seit Version 1.30 standardmäßig im Kube-Proxy aktiviert und in Version 1.31 auf den Status stable gestellt wurde.

Weitere Informationen findet ihr in dieser Dokumentation über Virtuelle IPs und Service Proxies.

Das Feature „Letzter Phasenübergangszeitpunkt für Persistent Volumes“ wurde in Version 1.31 auf den GA-Status (General Availability) angehoben. Dieses Feature fügt ein neues Feld PersistentVolumeStatus hinzu, wann ein Persistent Volume zuletzt in eine andere Phase übergegangen ist. Mit diesem Feature wird jedes PersistentVolume ein neues Feld .status.lastTransitionTime haben, das den Zeitpunkt des letzten Phasenübergangs speichert.

Diese Änderung tritt nicht sofort ein, sondern wird nur dann angewendet, wenn ein Persistent Volume aktualisiert wird und zum ersten Mal nach dem Upgrade auf Kubernetes v1.31 zwischen den Phasen (Pending, Bound oder Released) wechselt. Dadurch kann die Zeit gemessen werden, die ein Persistent Volume benötigt, um von Pending zu Bound zu wechseln.

Weitere Informationen findet ihr in der Dokumentation der Persistent Volumes.

Die nftables API ist der Nachfolger der iptables API und wurde entwickelt, um eine bessere Leistung und Skalierbarkeit als die iptables zu bieten. Der nftables-Proxy-Modus kann Änderungen an den Service-Endpunkten schneller und effizienter verarbeiten als der iptables-Modus und ermöglicht auch eine effizientere Verarbeitung von Paketen im Kernel (erst in Clustern mit Zehntausenden von Services merkbar).

Dieser Modus ist nur für Linux Nodes mit einer Kernel Version 5.13 oder neuer verfügbar und möglicherweise noch nicht mit allen Networking-Plugins kompatibel. Vor der Umstellung solltet ihr euch diesen Migrations-Guide anschauen.

Das Always Honor PersistentVolume(PV) Reclaim Policy Feature ist jetzt in der Beta Phase. Durch diese Anpassung wird sichergestellt, dass die Reclaim-Policy der PVs immer eingehalten wird, auch nachdem das PersistentVolumeClaim(PVC) gelöscht wurde.

Vor diesem Feature konnte die Reclaim-Policy eines PV unter bestimmten Bedingungen ignoriert werden, je nachdem ob das PV oder das PVC zuerst gelöscht wurde. Dadurch konnten potenzielle Inkonsistenzen und Ressourcenlecks auftreten, indem die entsprechende Speicherressource in den externen Infrastrukturen nicht gelöscht wurde.

Mit der Einführung dieses Features garantiert Kubernetes nun, dass die Reclaim Policy "Löschen" durchgesetzt wird. Dadurch wird sichergestellt, dass das zugrunde liegende Speicherobjekt von der externen Infrastruktur gelöscht wird, unabhängig davon, ob das PV oder das PVC zuerst gelöscht wird.

Das ServiceAccountTokenNodeBinding Feature ermöglicht es einen Token anzufragen, der nur an eine Node gebunden ist und nicht an einen Pod. Dabei sind Nodeinformationen in den Claims des Tokens. Außerdem wird bei der Verwendung des Tokens validiert, ob die entsprechende Node existiert. Weitere Informationen find ihr hier.

Die IP-Bereiche für Nodes und Pods können dynamisch geändert werden, da sie jeweils von der Infrastruktur oder dem Netzwerk-Plugin abhängen. Allerdings werden die IP-Bereiche für Services während der Cluster-Erstellung als fest codierte Option im kube-apiserver festgelegt.

Das Problem der IP-Erschöpfung war besonders bei langlebigen oder großen Clustern ein Thema, da Administratoren gezwungen waren, den zugewiesenen Service-CIDR-Bereich zu erweitern, zu verkleinern oder sogar vollständig zu ersetzen. Diese Vorgänge wurden nicht nativ unterstützt und erforderten komplexe und riskante Wartungsarbeiten, die oft zu Ausfallzeiten führten. Dieses neue Feature ermöglicht es Nutzern und Cluster-Administratoren, die Service-CIDR-Bereiche dynamisch und ohne Ausfallzeiten zu ändern.

Die weitere Dokumentation zu diesem Thema findet ihr unter der Dokumentationsseite der Virtual IPs and Service Proxies.

Die Verteilung des Netzwerkverkehrs ist ab der Version 1.31 in der Beta und standardmäßig aktiviert.

Nach mehreren Iterationen zur Optimierung der user experience und der Verkehrssteuerungsmöglichkeiten für das Service-Netzwerk wurde das Feld trafficDistribution in der Service-Spezifikation implementiert. Dieses Feld dient als Richtlinie für die zugrunde liegende Implementierung, um Routing-Entscheidungen zu treffen. Es ermöglicht eine präzisere Steuerung des Datenverkehrs und trägt dazu bei, die Effizienz und Flexibilität der Netzwerkverkehrsverteilung innerhalb von Kubernetes-Services zu verbessern.

Die Dokumentation und weitere Details zu diesem Feature findet ihr unter der Service Dokumentation.

Kubernetes arbeitet konstant daran die Voraussetzungen von Künstlicher Intelligenz und Machine Learning Use Cases zu erfüllen.

Eine dieser Voraussetzungen ist die Unterstützung von Open Container Initiative (OCI) Kompatiblen Images und Artefakten als Native Volume Quelle. Dadurch können die User sich auf den neuen OCI Standard fokussieren und die erstellten Artefakte in einer OCI Registry aufbewahren.

In Version 1.31 wurde ein neues Alpha-Feature hinzugefügt, das die Verwendung eines OCI-Images als Volume in einem Pod ermöglicht. Mit diesem Feature können Benutzer eine Image-Referenz als Volume in einem Pod angeben und dieses Volume dann innerhalb von Containern als Mount verwenden. Um dieses Feature auszuprobieren, müssen Sie das ImageVolume-Feature-Gate aktivieren. Weitere Details findet ihr hier.

Bei Aktivierung dieses Alpha-Features wird das Feld allocatedResourcesStatus zu jedem Container-Status innerhalb jedes Pods hinzugefügt. Darin enthalten findet man die Geräteinformationen, auf dem dieser Pod ausgeführt wird.

Mithilfe des Features AnonymousAuthConfigurableEndpoints kann man innerhalb der Authenticationskonfiguration festlegen, welche Endpunkte der API über anonyme Anfragen erreichbar sind. Dies ermöglicht es Nutzern, sich vor RBAC-Fehlkonfigurationen zu schützen, die anonymen Benutzern umfassenden Zugriff auf den Cluster gewähren könnten.

Alle weiteren Änderungen aus diesem Release findest du in dem offiziellen Beitrag auf der Kubernetes Webseite.

Quellen

https://kubernetes.io/blog/2024/08/13/kubernetes-v1-31-release/