View a markdown version of this page

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

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.37

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

Wichtig
  • SELinux Mount Labeling standardmäßig aktiviert (GA): In Kubernetes 1.37 ist die Funktion standardmäßig aktiviert. SELinuxMount Wenn ein Pod eingerichtet seLinuxOptions und der CSI-Treiber seines Volumes eingerichtet wird, mountet das Kubelet das Volume mitseLinuxMount: true, anstatt jede Datei neu zu beschriften. mount -o context=<label> Ein Mount kann nur ein SELinux-Label tragen. Ein Pod bleibt also drin, ContainerCreating wenn ein anderer Pod auf demselben Knoten bereits dasselbe Volume mit einem anderen SELinux-Label, einer anderen oder einer anderen Rechtestufe verwendet. seLinuxChangePolicy Knoten, auf denen SELinux nicht aktiviert ist, sind nicht betroffen.

    • Aktion erforderlich: Führen Sie vor dem Upgrade den Befehl aus, kubectl get csidriver -o custom-columns=NAME:.metadata.name,SELINUXMOUNT:.spec.seLinuxMount um Treiber mit zu finden. seLinuxMount: true Suchen Sie nach Volumes, die von diesen Treibern stammen, nach Pods, die ein Volume einrichten seLinuxOptions und gemeinsam nutzen. Pods, die sich ein Volume teilen, müssen dasselbe seLinuxOptions.level und verwendenseLinuxChangePolicy. Wenn sich ein privilegierter Pod und ein nicht privilegierter Pod ein Volume teilen, stellen Sie es spec.securityContext.seLinuxChangePolicy: Recursive auf dem nicht privilegierten Pod ein. Recursivebehält das vorherige Umbenennungsverhalten bei; wendet es auf alle Pods an, die das Volume gemeinsam nutzen. Weitere Informationen finden Sie unter SELinux Volume Label Changes goes GA (und wahrscheinliche Auswirkungen in v1.37) und. KEP-1710

  • EKS-Standardeinstellung für die automatische Moduskonsolidierung: Ab Kubernetes 1.37 gibt es den neuen EKS-Automatikmodus, bei dem NodePools die Standardeinstellung „statt“ nicht angegeben ist. consolidationPolicy Balanced WhenEmptyOrUnderutilized Balancedführt in der Regel zu weniger Pod-Räumungen bei ungefähr den gleichen Kosten. Die integrierten general-purpose und system NodePools auch die verwendetenBalanced, und du kannst diese Einstellung bei ihnen nicht ändern. Einzelheiten finden Sie in den Versionshinweisen zu EKS Auto Mode.

    • Aktion erforderlich: Um ein bestimmtes Konsolidierungsverhalten beizubehalten, legen Sie es consolidationPolicy explizit selbst fest NodePools. Wenn ein Workload das vorherige Verhalten benötigt, legen Sie als Ziel einen NodePool Wert festconsolidationPolicy: WhenEmptyOrUnderutilized.

  • Device Taints and Tolerations (Dynamic Resource Allocation, DRA) (Stabil): DRA-Treiber und Clusteradministratoren können Geräte wie GPUs verunreinigen, sodass der Scheduler sie nicht Pods zuweist, die die Verunreinigung nicht tolerieren. Die Verwendung von DRA auf EKS erfordert die Installation eines DRA-Treibers, den EKS nicht installiert. Der NVIDIA DRA-Treiber wird mit statischer Kapazität von Karpenter, von EKS verwalteten Knotengruppen und selbstverwalteten Knoten unterstützt. Er wird im EKS-Automatikmodus nicht unterstützt. Verwenden Sie im EKS-Automatikmodus oder bei der dynamischen Kapazitätsbereitstellung von Karpenter das NVIDIA-Geräte-Plugin.

  • Horizontale konfigurierbare Toleranz für Pod Autoscaler (stabil): Sie können eine Toleranz pro HPA festlegen, getrennt für das Hoch- und Herunterskalieren, anstatt sich nur auf den clusterweiten Standardwert von 10% zu verlassen.

  • Horizontal Pod Autoscaler Scale to Zero (Beta): Das HPAScaleToZero Feature Gate ist in Kubernetes 1.37 standardmäßig aktiviert. Ein HPA, das anhand von Objekt- oder externen Metriken skaliert, kann so eingestellt minReplicas: 0 werden, dass Pods im Leerlauf auf Null skaliert werden und bei erneuter Nachfrage wieder hochgefahren werden. Für Objekt- und externe Metriken ist ein Metrikadapter erforderlich, den EKS nicht installiert.

  • Änderungen an der Kubelet-Konfiguration: Das Kubelet startet nicht mehr, wenn ein veraltetes CAdvisor-Flag gesetzt ist (Ausnahme--housekeeping-interval), löscht die container_cpu_load_average_10s container_tasks_state Metriken und und behandelt es als kein Limit. container_cpu_load_d_average_10s eventRecordQPS: 0 Zuvor wurde ein Limit von eventRecordQPS: 0 5 Ereignissen pro Sekunde angewendet. EKS-optimized AMIs setzen die veralteten CAdvisor-Flags nichteventRecordQPS, daher bleiben ihr Kubelet-Start und ihr Ratenlimit unverändert. Die entfernten Metriken wirken sich auf jeden aus, der sie scrapt, und zwar auf jedem AMI.

    • Aktion erforderlich: Wenn Sie benutzerdefinierte AMIs oder zusätzliche Kubelet-Argumente verwenden, entfernen Sie die veralteten CAdvisor-Flags. Falls Sie diese festlegen, ändern Sie sie soeventRecordQPS: 0, dass das vorherige Ratenlimit beibehalten 5 wird. Aktualisieren Sie alle Dashboards oder Alerts, die die entfernten Metriken verwenden. Weitere Informationen finden Sie in der Referenz zur Kubelet-Konfiguration (v1beta1).

  • Kubelet protokolliert seine Konfiguration beim Start: Das Kubelet protokolliert jetzt seine volle effektive Konfiguration beim Start. Stellen Sie sicher, dass nur vertrauenswürdige Benutzer die Knotenprotokolle lesen können. Weitere Informationen finden Sie unter kubernetes/kubernetes #139837.

  • NVIDIA-Treiber 595 für Amazon EC2 G7-Instances: Für G7-Instances ist der NVIDIA-Treiber 595 erforderlich. Die EKS-optimized Amazon Linux 2023 NVIDIA-AMIs enthalten den Treiber 595 auf allen unterstützten Versionen; die Bottlerocket-NVIDIA-AMIs enthalten ihn auf Kubernetes 1.37 und höher.

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

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): In Kubernetes 1.36 werden für schnellere SELinux-Volume-Labels standardmäßig alle Volumes verwendet, statt rekursiver Dateiumbeschriftungen. mount -o context Die gemeinsame Nutzung eines Volumes auf demselben Knoten zwischen privilegierten und unprivilegierten Pods oder zwischen Pods mit unterschiedlichen SELinux-Labels kann zu Problemen führen. Das entsprechende SELinuxMount Verhalten, das einen Pod aufnehmen kann, ContainerCreating ist in Kubernetes 1.37 standardmäßig aktiviert, nicht in 1.36. Lesen Sie vor dem Upgrade den Abschnitt Kubernetes 1.37.

  • 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.

  • Ressourcenintegritätsstatus (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 einer zukünftigen Kubernetes-Version entfernt. Migrieren Sie in den Nftables-Modus. Weitere Informationen finden Sie unter Kube-Proxy im Nftables-Modus ausführen.

Das vollständige Kubernetes-Changelog finden Sie unter 1.35 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