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
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
gitRepoVolume-Typ ist in Kubernetes 1.36 dauerhaft deaktiviert und kann nicht erneut aktiviert werden. Die Kubernetes-API akzeptiert weiterhin Pods mitgitRepoVolumes, aber das Kubelet weigert sich, sie auszuführen, und gibt einen Fehler zurück.-
Maßnahme erforderlich: Migrieren Sie vor dem Upgrade auf 1.36 zu Init-Containern
oder Git-Sync-Sidecar-Containern . Weitere Informationen finden Sie unter KEP-5040 .
-
-
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 contextDie 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.-
Maßnahme erforderlich: Kunden, die SELinux-enforcing Systeme ausführen, sollten vor dem Upgrade Cluster prüfen und sicherstellen, dass die
seLinuxChangePolicyFeld- und SELinux-Volume-Labels auf den Pods korrekt gesetzt sind. Weitere Informationen finden Sie unter SELinux Volume Label Changes wird allgemein verfügbar (und mögliche Auswirkungen in Version 1.37).
-
-
Strikte IP/CIDR Validierung standardmäßig aktiviert: Das
StrictIPCIDRValidationFeature 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.005statt10.0.0.5) oder CIDR-Werte mit mehrdeutiger Semantik (z. B. statt) mehr.192.168.0.5/24192.168.0.0/24Bestehende 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.
-
Weitere Informationen finden Sie unter Kubernetes v1.36: Mehr Treiber, neue Funktionen und die nächste Ära von DRA im Kubernetes-Blog
.
-
-
Veraltungshinweis — Service ExternalIps: Das
externalIPsFeld in Service ist in Kubernetes 1.36 veraltet..specWenn 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,externalIPssollten 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 einrichten failCgroupV1: 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.
-
Handlungsbedarf: EKS-Kunden sollten prüfen, ob sie sich auf Ingress NGINX verlassen, und mit der Planung der Migration zu Alternativen wie Gateway-API oder Ingress-Controllern von Drittanbietern beginnen, da es nach der Außerbetriebnahme keine weiteren Versionen für Bugfixes, Sicherheitspatches oder Updates geben wird. Bestehende Implementierungen werden weiterhin funktionieren, aber wenn Sie nach der Außerbetriebnahme bei Ingress NGINX bleiben, ist Ihre Umgebung anfällig für Sicherheitsrisiken, da keine der verfügbaren Alternativen ein direkter Ersatz ist und Planungs- und Entwicklungszeit erfordert. Weitere Informationen zu dieser Ankündigung von Kubernetes finden Sie in der offiziellen Stellungnahme der Kubernetes Steering and Security Response Committees zur Einstellung von Ingress NGINX.
-
-
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.
-
Weitere Informationen finden Sie im Kubernetes-Blog unter Kubernetes 1.35: In-Place Pod Resize Graduates
to Stable.
-
-
PreferSameNode Verkehrsverteilung (stabil): Das
trafficDistributionFeld 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-imageFlagge 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.
-
Wenn nach dem Upgrade Probleme auftreten, lesen Sie die containerd Versionshinweise zu 2.1
.
-
-
AWS veröffentlicht kein EKS-optimized Amazon Linux 2-AMI für Kubernetes 1.34.
-
AWS fordert Sie auf, zu Amazon Linux 2023 zu migrieren. Weitere Informationen erhalten Sie unter Upgrade von Amazon Linux 2 zu Amazon Linux 2023.
-
Weitere Informationen finden Sie unter Veraltung von Amazon Linux 2 AMI.
-
-
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).
-
Wir empfehlen die Verwendung gebundener Dienstkonto-Tokens
, die automatisch von Kubernetes bereitgestellt und rotiert werden.
-
-
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
MutableCSINodeAllocatableCountFeature-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.-
Weitere Informationen finden Sie unter Kubernetes v1.34: Mutable CSI Node Allocatable
Count im Kubernetes-Blog.
-
-
Veraltungshinweis — Cgroup-Treiberkonfiguration: Die manuelle Konfiguration des Cgroup-Treibers wird zugunsten der automatischen Erkennung eingestellt.
-
Auswirkung auf Kunden: Wenn Sie das
--cgroup-driverFlag 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.
-
AWS fordert Sie auf, zu Amazon Linux 2023 zu migrieren. Weitere Informationen erhalten Sie unter Upgrade von Amazon Linux 2 zu Amazon Linux 2023.
-
Weitere Informationen finden Sie unter Veraltung von Amazon Linux 2 AMI.
-
-
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.
-
Weitere Informationen finden Sie unter Elastic Fabric Adapter für AI/ML und HPC-Workloads auf Amazon EC2 im Amazon Elastic Compute Cloud-Benutzerhandbuch.
-
Das vollständige 1.33 Kubernetes-Changelog finden Sie unter https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.33.md