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 auf, 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

Melden Sie sich für bevorstehende Amazon EKS-Workshops an.

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.

  • SELinux-Volume-Labeling-Änderungen (GA): Faster SELinux-Volume Labeling verwendet in Kubernetes 1.36 jetzt standardmäßig alle Volumes und verwendet statt rekursiver Dateiumbenennung. mount -o context Die gemeinsame Nutzung eines Volumes zwischen Pods mit und ohne Zugriffsrechte auf demselben Knoten kann zu Problemen führen. Zukünftige Kubernetes-Versionen könnten weitere wichtige Änderungen im Zusammenhang mit dieser Funktion beinhalten.

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

    • Maßnahme erforderlich: Überprüfen Sie Manifeste, Helm-Diagramme und Automatisierung auf IP-Adressen, die führende Nullen oder eine nicht-kanonische CIDR-Notation enthalten. Aktualisieren Sie sie vor dem Upgrade so, dass sie kanonische Formate verwenden. Weitere Informationen finden Sie unter KEP-4858.

  • Benutzernamespaces (stabil): User Namespaces bietet umfassenden Schutz, indem es den Root-Benutzer eines Containers einem nicht privilegierten Benutzer auf dem Host zuordnet und so sicherstellt, dass ein Container-Breakout keine Administratorrechte über den Knoten gewährt.

    • Weitere Informationen finden Sie im Kubernetes-Blog unter Benutzernamespaces in Kubernetes sind endlich allgemein verfügbar.

  • Ressourcenintegritätsstatus (Beta): Meldet den Zustand pro Gerät im Pod-Status, sodass Bediener feststellen können, ob eine Absturzschleife eher auf einen fehlerhaften oder unbekannten Gerätestatus als auf Anwendungsprobleme zurückzuführen ist. Funktioniert sowohl mit Geräte-Plug-ins als auch mit dynamischer Ressourcenzuweisung.

    • Weitere Informationen finden Sie unter KEP-4680.

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

  • Veraltungshinweis — Service ExternalIps: Das externalIPs Feld in Service ist in Kubernetes 1.36 veraltet. .spec Wenn Sie Dienste erstellen oder aktualisieren, die dieses Feld verwenden, werden Ihnen Warnungen zu veralteten Diensten angezeigt. Die vollständige Entfernung ist für Kubernetes 1.43 geplant. Kunden, die die API 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 verbietet die cgroup v1-Unterstützung, was bedeutet, dass das Kubelet sich standardmäßig weigert, auf Knoten zu starten, die cgroup v1 verwenden.

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

      • Maßnahme erforderlich: Kunden, die AL2023 manuell für die Verwendung von cgroup v1 konfiguriert haben, müssen entweder zu cgroups v2 migrieren oder die Kubelet-Konfiguration manuell einrichtenfailCgroupV1: false.

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

    • Fargate: Fargate verwendet weiterhin cgroup v1.

  • Ende des Support 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 kritische Infrastrukturkomponente für viele Kubernetes-Umgebungen, außer Dienst stellen.

  • In-Place Pod-Ressourcen-Updates (stabil): Mit In-Place Pod-Ressourcen-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 Workloads 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 Steuerung des Datenverkehrs zu ermöglichen. Es wurde eine neue Option eingeführtPreferSameNode, mit der Dienste Endpunkte auf dem lokalen Knoten strikt priorisieren können, sofern verfügbar, und andernfalls auf entfernte Endpunkte zurückgreifen können. Durch diese Änderung wird in der API deutlicher, dass Verkehr innerhalb des aktuellen Knotens bevorzugt wird.

  • StatefulSet MaxUnavailable (Beta): Diese Funktion ermöglicht parallel 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 Einzelupdates, wodurch die Wartungsfenster erheblich reduziert werden.

  • Windows Server 2025-Unterstützung: EKS 1.35 fügt Support für Windows Server 2025 hinzu.

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

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

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

  • AppArmor ist in Kubernetes 1.34 veraltet.

  • VolumeAttributesClass (VAC) wechselt in Kubernetes 1.34 zu 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 (von CSI Components in der ECR-Galerie) verwenden, funktioniert die Volumenänderung weiterhin problemlos auf EKS 1.31-1.33-Clustern. AWS wird die Sidecars bis zum Ende der Standardunterstützung für EKS 1.33 (29. Juli 2026) so patchen, dass sie Beta-VAC-APIs unterstützen.

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

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

  • External JWT Signer for Service Account Tokens wird in die Beta-Version hochgestuft. Bei der Verwendung externer Unterzeichner wird das Flag --service-account-extend-token-expiration nicht mehr vollständig berücksichtigt. 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) mit dynamischer 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.

  • Projizierte ServiceAccount Tokens für 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 verringert und die allgemeine Sicherheitslage Ihrer Cluster gestärkt.

  • Pod-level Ressourcenanforderungen und Grenzwerte (Beta): Diese Funktion vereinfacht die Ressourcenverwaltung, indem sie gemeinsam genutzte Ressourcenpools für Pods mit mehreren Containern ermöglicht und so eine effizientere Ressourcenzuweisung und -nutzung für komplexe Anwendungen mit mehreren Containern ermöglicht.

  • Mutable CSI Node Allocatable Count (Beta): Das MutableCSINodeAllocatableCount Feature-Gate ist in EKS 1.34 standardmäßig aktiviert, wodurch das CSInode-Attribut max attachable volume count veränderbar wird und ein Mechanismus eingeführt wird, um es dynamisch auf der Grundlage der Benutzerkonfiguration auf der CSI-Treiberebene zu aktualisieren. Diese Updates können entweder durch regelmäßige Intervalle oder durch Fehlererkennung ausgelöst werden. Dadurch wird die Zuverlässigkeit des Stateful-Pod-Schedulings erhöht, indem Diskrepanzen zwischen der gemeldeten und der tatsächlichen Verbindungskapazität auf den Knoten behoben werden.

  • Veraltungshinweis — Cgroup-Treiberkonfiguration: Die manuelle Konfiguration des Cgroup-Treibers wird zugunsten der automatischen Erkennung eingestellt.

    • Auswirkung auf Kunden: Wenn Sie das --cgroup-driver Flag derzeit in Ihrer Kubelet-Konfiguration manuell setzen, sollten Sie sich darauf vorbereiten, diese Konfiguration zu entfernen.

    • Erforderliche Maßnahme: Planen Sie die Aktualisierung von Knoten-Bootstrap-Skripten und benutzerdefinierten AMI-Konfigurationen, um manuelle Cgroup-Treibereinstellungen zu entfernen, bevor die Funktion in einer future Kubernetes-Version entfernt wird.

    • Weitere Informationen finden Sie in der Dokumentation zum Cgroup-Treiber.

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

Kubernetes 1.33

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

Wichtig
  • Die beta-Version der Kubernetes-API für die dynamische Ressourcenzuweisung ist aktiviert.

    • Diese Beta-API verbessert die Erfahrung bei der Planung und Überwachung von Workloads, die Ressourcen wie GPUs erfordern.

    • Die Beta-API wird von der Kubernetes-Community definiert und kann sich in zukünftigen Versionen von Kubernetes ändern.

    • Lesen Sie die Feature-Phasen in der Kubernetes-Dokumentation sorgfältig durch, um die Auswirkungen der Verwendung von Beta-APIs zu verstehen.

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

  • In-Place Größe der Pod-Ressource ändern (Beta): In-place Die Größenänderung von Ressourcen wurde zur Beta-Version hochgestuft, sodass dynamische Aktualisierungen der CPU- und Speicherressourcen für bestehende Pods ohne Neustarts möglich sind. Dies ermöglicht die vertikale Skalierung von statusbehafteten Workloads ohne Ausfallzeiten und nahtlose Ressourcenanpassungen auf der Grundlage von Verkehrsmustern.

  • Sidecar-Container jetzt stabil: Sidecar-Container sind nun stabil und implementieren Sidecars als spezielle Init-Container mit restartPolicy: Always, die vor Anwendungs-Containern gestartet werden, während des gesamten Pod-Lebenszyklus ausgeführt werden und Muster zur Signalisierung des Betriebszustands unterstützen.

    • Weitere Informationen finden Sie unter Sidecar-Container in der Kubernetes-Dokumentation.

  • Veraltete Endpunkt-API: Die Endpoint-API ist jetzt offiziell veraltet und gibt beim Zugriff Warnungen zurück. Migrieren Sie Workloads und Skripts, um stattdessen die EndpointSlices API zu verwenden, die moderne Funktionen wie Dual-Stack-Netzwerke unterstützt und mehrere EndpointSlices pro Service verarbeitet.

    • Weitere Informationen finden Sie im Kubernetes-Blog unter Kubernetes v1.33: Fortsetzung des Übergangs von Endpoints zu. EndpointSlice

  • Support für Elastic Fabric Adapter: Die Standardsicherheitsgruppe für Amazon-EKS-Cluster unterstützt nun Datenverkehr für Elastic Fabric Adapter (EFA). Die Standardsicherheitsgruppe verfügt über eine neue Ausgangsregel, die EFA-Datenverkehr mit dem Ziel derselben Sicherheitsgruppe zulässt. Dadurch wird EFA-Datenverkehr innerhalb des Clusters ermöglicht.

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