View a markdown version of this page

Versionshinweise für Kubernetes-Versionen mit Standard-Support anzeigen - Amazon EKS
Kubernetes 1.36Kubernetes 1.35Kubernetes 1.34

Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten unter, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Versionshinweise für Kubernetes-Versionen mit Standard-Support anzeigen

Tipp

Registrieren Sie sich für bevorstehende Amazon EKS-Workshops.

Dieses Thema enthält wichtige Änderungen, die Sie für jede Kubernetes-Version im Standard-Support beachten sollten. Überprüfen Sie beim Upgrade sorgfältig die Änderungen, die zwischen der alten und der neuen Version für Ihren Cluster vorgenommen wurden.

Kubernetes 1.36

Kubernetes 1.36 ist jetzt in Amazon EKS verfügbar. Weitere Informationen zu Kubernetes 1.36 finden Sie in der offiziellen Versionsankündigung.

Wichtig

  • Entfernung des GitRepo-Volumes: Der gitRepo Volume-Typ ist in Kubernetes 1.36 dauerhaft deaktiviert und kann nicht erneut aktiviert werden. Die Kubernetes-API akzeptiert weiterhin Pods mit gitRepo Volumes, aber das Kubelet weigert sich, sie auszuführen, und gibt einen Fehler zurück.

    • Aktion erforderlich: Migrieren Sie zu Init-Containern oder Git-Sync-Sidecar-Containern, bevor Sie auf 1.36 aktualisieren. Weitere Informationen finden Sie unter KEP-5040.

  • SELinux Volume Labeling Changes (GA): Schnellere SELinux-Volume-Labeling ist jetzt standardmäßig für alle Volumes in Kubernetes 1.36 verfügbar und verwendet statt rekursiver Dateiumbenennungen. mount -o context Die gemeinsame Nutzung eines Volumes zwischen privilegierten und unprivilegierten Pods auf demselben Knoten kann zu Problemen führen. In zukünftigen Kubernetes-Versionen werden möglicherweise weitere wichtige Änderungen im Zusammenhang mit dieser Funktion eingeführt.

  • Strikte IP/CIDR Validierung standardmäßig aktiviert: Das StrictIPCIDRValidation Feature Gate ist jetzt standardmäßig für integrierte API-Arten aktiviert. API-Felder akzeptieren keine IP- oder CIDR-Werte mit überflüssigen führenden Nullen (z. B. 010.000.000.005 anstelle von10.0.0.5) oder CIDR-Werte mit mehrdeutiger Semantik (z. B. anstelle von) mehr. 192.168.0.5/24 192.168.0.0/24 Bestehende gespeicherte Objekte werden durch Validierungsratcheting beibehalten, aber Neuerstellungen und Aktualisierungen werden abgelehnt. Dies gilt nicht für benutzerdefinierte Ressourcentypen.

    • Aktion erforderlich: Überprüfen Sie Manifeste, Helm-Diagramme und die Automatisierung auf IP-Adressen, die führende Nullen oder eine nicht kanonische CIDR-Notation enthalten. Aktualisieren Sie sie, damit sie kanonische Formate verwenden, bevor Sie das Upgrade durchführen. Weitere Informationen finden Sie unter KEP-4858.

  • Benutzernamespaces (Stabil): Benutzer-Namespaces bieten umfassenden Schutz, indem sie den Root-Benutzer eines Containers einem Benutzer ohne Privilegien auf dem Host zuordnen und so sicherstellen, dass ein Container-Breakout keine Administratorrechte über den Knoten gewährt.

  • Integritätsstatus der Ressource (Beta): Meldet den Zustand pro Gerät im Pod-Status, sodass Bediener feststellen können, ob eine Absturzschleife auf den Status „Ungesund“ oder „Unbekannt“ des Geräts zurückzuführen ist und nicht auf Anwendungsprobleme. Funktioniert sowohl mit Geräte-Plug-ins als auch mit dynamischer Ressourcenzuweisung.

    • Weitere Informationen finden Sie unter KEP-4680.

  • Funktionen zur dynamischen Ressourcenzuweisung (Beta): Mehrere DRA-Funktionen sind jetzt standardmäßig aktiviert: Partitionierbare Geräte und verbrauchbare Kapazität für eine detailliertere gemeinsame Nutzung von Geräten wie GPUs sowie Gerätebindungsbedingungen für gründliche Überprüfungen der Gerätebereitschaft vor der Planung.

  • Veraltungshinweis — Service ExternalIps: Das externalIPs Feld in Service ist in Kubernetes 1.36 veraltet. .spec Wenn du Dienste erstellst oder aktualisierst, die dieses Feld verwenden, wirst du Warnmeldungen über veraltete Versionen sehen. Für Kubernetes 1.43 ist eine vollständige Entfernung geplant. Kunden, die dies verwenden, externalIPs sollten auf LoadBalancer Services oder Gateway API NodePort migrieren. Weitere Informationen finden Sie unter KEP-5707.

Das vollständige 1.36 Kubernetes-Changelog finden Sie unter https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.36.md

Kubernetes 1.35

Kubernetes 1.35 ist jetzt in Amazon EKS verfügbar. Weitere Informationen zu Kubernetes 1.35 finden Sie in der offiziellen Versionsankündigung.

Wichtig

  • Cgroup v1-Unterstützung entfernt: Kubernetes 1.35 stellt die Unterstützung für cgroup v1 ein, was bedeutet, dass das Kubelet auf Knoten, die cgroup v1 verwenden, standardmäßig den Start verweigert.

    • AL2023: AL2023 verwendet standardmäßig cgroup v2 und entspricht dem Upstream-Verhalten von Kubernetes.

    • Bottlerocket: Bottlerocket 1.35 verwendet standardmäßig cgroup v2, setzt es jedoch in der Kubelet-Konfiguration ein, wobei die Abwärtskompatibilität gewahrt bleibt. failCgroupV1: false

    • Fargate: Fargate verwendet weiterhin cgroup v1.

  • Ende der Unterstützung für Containerd 1.x: Kubernetes 1.35 ist die letzte Version, die Containerd 1.x unterstützt. Sie müssen zu containerd 2.0 oder höher wechseln, bevor Sie auf die nächste Kubernetes-Version aktualisieren.

  • Im März 2026 wird das Upstream-Kubernetes-Projekt Ingress NGINX, eine wichtige Infrastrukturkomponente für viele Kubernetes-Umgebungen, außer Betrieb nehmen.

    • Handlungsbedarf: EKS-Kunden sollten prüfen, ob sie sich auf Ingress NGINX verlassen, und mit der Planung der Migration zu Alternativen wie der Gateway-API oder Ingress-Controllern von Drittanbietern beginnen, da es nach der Außerbetriebnahme keine weiteren Veröffentlichungen für Bugfixes, Sicherheitspatches oder Updates geben wird. Bestehende Bereitstellungen funktionieren weiterhin, aber wenn Sie Ingress NGINX nach der Außerbetriebnahme weiterhin verwenden, ist Ihre Umgebung anfällig für Sicherheitsrisiken, da keine der verfügbaren Alternativen ein direkter Ersatz ist und Planungs- und Engineering-Zeit erfordert. Weitere Informationen zu dieser Kubernetes-Ankündigung finden Sie in der offiziellen Stellungnahme der Kubernetes Steering and Security Response Committees zur Einstellung von Ingress NGINX. https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/

  • In-Place Pod-Ressourcenaktualisierungen (stabil): Mit In-Place Pod Resource Updates können Benutzer CPU- und Speicherressourcen anpassen, ohne Pods oder Container neu starten zu müssen. Bisher erforderten solche Änderungen die Neuerstellung von Pods, was die Arbeitslast stören konnte, insbesondere bei Stateful-Anwendungen oder Batch-Anwendungen. Die neue In-Place-Funktionalität ermöglicht eine reibungslosere, unterbrechungsfreie vertikale Skalierung, verbessert die Effizienz und kann auch die Entwicklung vereinfachen.

  • PreferSameNode Verkehrsverteilung (Stabil): Das trafficDistribution Feld für Dienste wurde aktualisiert, um eine explizitere Kontrolle über das Traffic-Routing zu ermöglichen. Eine neue Option,PreferSameNode, wurde eingeführt, mit der Dienste Endpunkte auf dem lokalen Knoten strikt priorisieren können, sofern verfügbar, und andernfalls auf entfernte Endpunkte zurückgreifen. Diese Änderung macht die API expliziter, was die Bevorzugung des Datenverkehrs innerhalb des aktuellen Knotens anbelangt.

  • StatefulSet MaxUnavailable (Beta): Diese Funktion ermöglicht parallele Pod-Updates durch Einstellung maxUnavailable (z. B. 3 oder 10%), sodass statusbehaftete Anwendungen wie Datenbankcluster bis zu 60% schneller aktualisiert werden können als sequentielle Updates, die einzeln aktualisiert werden, wodurch die Wartungsfenster erheblich reduziert werden.

  • Windows Server 2025-Unterstützung: EKS 1.35 fügt Unterstützung für Windows Server 2025 hinzu. https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-windows-ami.html

  • Entfernung der Kubelet-Flagge: Die --pod-infra-container-image Flagge wurde aus Kubelet entfernt. Benutzerdefinierte AMI-Benutzer müssen dieses Flag vor dem Upgrade auf 1.35 aus der Kubelet-Konfiguration entfernen.

  • Hinweis zur Veralterung — IPVS-Modus: Der IPVS-Modus in Kube-Proxy ist veraltet und wird in Kubernetes 1.36 entfernt.

Das vollständige 1.35 Kubernetes-Changelog finden Sie unter https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.35.md

Kubernetes 1.34

Kubernetes 1.34 ist jetzt in Amazon EKS verfügbar. Weitere Informationen zu Kubernetes 1.34 finden Sie in der offiziellen Versionsankündigung.

Wichtig

  • Containerd wurde in Version 1.34 zum Start auf 2.1 aktualisiert.

    • Wenn Sie nach dem Upgrade auf Probleme stoßen, lesen Sie die Versionshinweise zu Containerd 2.1.

  • AWS veröffentlicht kein EKS-optimized Amazon Linux 2-AMI für Kubernetes 1.34.

  • AppArmor ist in Kubernetes 1.34 veraltet.

  • VolumeAttributesClass (VAC) macht seinen Abschluss in Kubernetes 1.34 auf GA und migriert von der Beta-API (storage.k8s.io/v1beta1) zur stabilen API (). storage.k8s.io/v1

    • Wenn Sie den EBS-CSI-Treiber mit AWS-verwalteten Sidecar-Containern verwenden (von CSI Components in der ECR-Galerie), funktioniert die Volumenänderung auf EKS 1.31-1.33-Clustern weiterhin problemlos. AWS wird die Sidecars patchen, um Beta-VAC-APIs bis zum Ende der EKS 1.33-Standardunterstützung (29. Juli 2026) zu unterstützen.

    • Wenn Sie Ihre CSI-Sidecar-Container selbst verwalten, müssen Sie möglicherweise ältere Sidecar-Versionen auf Clustern vor 1.34 anbinden, um die VAC-Funktionalität aufrechtzuerhalten.

    • Um VolumeAttributesClass GA-Funktionen (z. B. Modifikations-Rollback) nutzen zu können, führen Sie ein Upgrade auf EKS 1.34 oder höher durch.

  • Der externe JWT-Signer für Service Account Tokens wird in die Betaversion hochgestuft. Wenn externe Unterzeichner verwendet werden, wird das Flag --service-account-extend-token-expiration nicht mehr vollständig respektiert. Der API-Server erzwingt den Mindestablauf zwischen der gewünschten Verlängerung (1 Jahr) und dem Limit für externe Unterzeichner (24 Stunden).

  • Kern-APIs (GA) für dynamische Ressourcenzuweisung (DRA): Die dynamische Ressourcenzuweisung ist inzwischen stabil und ermöglicht eine effiziente Verwaltung spezialisierter Hardware wie GPUs über standardisierte Zuweisungsschnittstellen. Dadurch wird das Ressourcenmanagement für Hardwarebeschleuniger vereinfacht und die Nutzung spezialisierter Ressourcen verbessert.

  • Projected ServiceAccount Tokens for Kubelet (Beta): Diese Erweiterung verbessert die Sicherheit, indem kurzlebige Anmeldeinformationen für Container-Image-Pulls anstelle von langlebigen Geheimnissen verwendet werden. Dadurch wird das Risiko der Offenlegung von Anmeldeinformationen reduziert und die allgemeine Sicherheitslage Ihrer Cluster gestärkt.

  • Pod-level Resource Requests and Limits (Beta): Diese Funktion vereinfacht die Ressourcenverwaltung, indem sie gemeinsame Ressourcenpools für Pods mit mehreren Containern ermöglicht. Dies ermöglicht eine effizientere Ressourcenzuweisung und -nutzung für komplexe Anwendungen mit mehreren Containern.

  • Mutable CSI Node Allocatable Count (Beta): Das MutableCSINodeAllocatableCount Feature Gate ist in EKS 1.34 standardmäßig aktiviert, wodurch das Attribut CSINode max Attachable Volume Count veränderbar wird und ein Mechanismus eingeführt wird, um es basierend auf der Benutzerkonfiguration auf der CSI-Treiberebene dynamisch zu aktualisieren. Diese Aktualisierungen können entweder in regelmäßigen Intervallen oder durch Fehlererkennung ausgelöst werden. Dadurch wird die Zuverlässigkeit der statusbehafteten Pod-Planung erhöht, indem Diskrepanzen zwischen der gemeldeten und der tatsächlichen Verbindungskapazität auf den Knoten behoben werden.

  • Veraltungshinweis — Cgroup-Treiberkonfiguration: Die manuelle Cgroup-Treiberkonfiguration ist zugunsten der automatischen Erkennung veraltet.

    • Auswirkung für den Kunden: Wenn Sie das --cgroup-driver Kennzeichen derzeit manuell in Ihrer Kubelet-Konfiguration setzen, sollten Sie sich darauf vorbereiten, diese Konfiguration zu entfernen.

    • Erforderliche Maßnahme: Planen Sie, Node-Bootstrap-Skripte und benutzerdefinierte AMI-Konfigurationen zu aktualisieren, um manuelle Cgroup-Treibereinstellungen zu entfernen, bevor die Funktion in einer zukünftigen Kubernetes-Version entfernt wird.

    • Weitere Informationen finden Sie in der Cgroup-Treiberdokumentation.

Das vollständige 1.34 Kubernetes-Changelog finden Sie unter https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.34.md