**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.
# Verständnis des Kubernetes-Versionslebenszyklus auf EKS
**Tipp**
[Melden Sie sich](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) für bevorstehende Amazon EKS-Workshops an.
Kubernetes entwickelt sich durch neue Features, Design-Aktualisierungen und Fehlerbehebungen schnell weiter. Die Community veröffentlicht im Durchschnitt alle vier Monate neue Kubernetes-Nebenversionen (z. B. `1.35`). Amazon EKS folgt für Nebenversionen dem Upstream-Release- und Einstellungszyklus. Sobald neue Kubernetes-Versionen in Amazon EKS verfügbar werden, empfehlen wir Ihnen, Ihre Cluster proaktiv auf die neueste verfügbare Version zu aktualisieren.
Eine Nebenversion wird in den ersten 14 Monaten nach ihrer Veröffentlichung standardmäßig in Amazon EKS unterstützt. Sobald eine Version das Ende des Standard-Supportdatums überschritten hat, wird für die folgenden 12 Monate ein erweiterter Support angeboten. Mit dem erweiterten Support können Sie gegen Aufpreis pro Cluster-Stunde länger bei einer bestimmten Kubernetes-Version bleiben. Wenn Sie Ihren Cluster vor Ablauf des verlängerten Supportzeitraums nicht aktualisiert haben, wird Ihr Cluster automatisch auf die älteste derzeit unterstützte erweiterte Version aktualisiert.
Der erweiterte Support ist standardmäßig aktiviert. Informationen zum Deaktivieren finden Sie unter [Erweiterten EKS-Support deaktivieren](https://docs.aws.amazon.com/eks/latest/userguide/disable-extended-support.html).
Wir empfehlen, dass Sie Ihren Cluster mit der neuesten verfügbaren Kubernetes-Version erstellen, die von Amazon EKS unterstützt wird. Wenn Ihre Anwendung eine bestimmte Version von Kubernetes benötigt, können Sie auch ältere Versionen auswählen. Sie können neue Amazon-EKS-Cluster auf jeder Version erstellen, die mit Standard- oder verlängertem Support angeboten wird.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/_dJdAZ_J_jw?rel=0)
## Verfügbare Versionen mit Standard-Support
Die folgenden Kubernetes-Versionen sind derzeit mit Amazon-EKS-Standard-Support verfügbar:
+ `1.35`
+ `1.34`
+ `1.33`
+ `1.32`
Wichtige Änderungen, die Sie für jede Version des Standard-Supports beachten sollten, finden Sie unter [Standard-Support für Kubernetes-Versionen](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions-standard.html).
## Verfügbare Versionen mit verlängertem Support
Die folgenden Kubernetes-Versionen sind derzeit mit erweitertem Support für Amazon EKS verfügbar:
+ `1.31`
+ `1.30`
+ `1.29`
Wichtige Änderungen, die Sie bei jeder Version im erweiterten Support beachten sollten, finden Sie unter [Erweiterter Support für Kubernetes-Versionen](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions-extended.html).
## Amazon-EKS-Kubernetes-Veröffentlichungskalender
Die folgende Tabelle zeigt wichtige Veröffentlichungs- und Support-Daten, die für jede -Version zu berücksichtigen sind. Fakturierung für den erweiterten Support beginnt zu Beginn des Tages, an dem die Version das Ende des Standard-Supports erreicht, in der Zeitzone UTC\$10. Die Daten in der folgenden Tabelle basieren auf der Zeitzone UTC\$10.
**Anmerkung**
Daten mit nur einem Monat und einem Jahr sind ungefähre Angaben und werden mit einem genauen Datum aktualisiert, wenn es bekannt ist.
Um Benachrichtigungen über alle Änderungen an den Quelldateien dieser spezifischen Dokumentationsseite zu erhalten, können Sie die folgende URL mit einem RSS-Reader abonnieren:
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/versioning/kubernetes-versions.adoc.atom
```
| Kubernetes-Version | Upstream-Release | Amazon-EKS-Version | Ende des Standard-Supports | Ende des verlängerten Supports |
| --- | --- | --- | --- | --- |
| `1.35` | 17. Dezember 2025 | 27. Januar 2026 | 27. März 2027 | 27. März 2028 |
| `1.34` | 27. August 2025 | 2. Oktober 2025 | 2. Dezember 2026 | 2. Dezember 2027 |
| `1.33` | 23. April 2025 | 29. Mai 2025 | 29. Juli 2026 | 29. Juli 2027 |
| `1.32` | 11. Dezember 2024 | 23. Januar 2025 | 23. März 2026 | 23. März 2027 |
| `1.31` | 13. August 2024 | 26. September 2024 | 26. November 2025 | 26. November 2026 |
| `1.30` | 17. April 2024 | 23. Mai 2024 | 23. Juli 2025 | 23. Juli 2026 |
| `1.29` | 13. Dezember 2023 | 23. Januar 2024 | 23. März 2025 | 23. März 2026 |
## Versionsinformationen mit AWS CLI abrufen
Sie können die AWS CLI verwenden, um Informationen zu den auf EKS verfügbaren Kubernetes-Versionen abzurufen, z. B. das Enddatum des Standardsupports.
### So rufen Sie mithilfe der CLI Informationen zu verfügbaren Kubernetes-Versionen auf EKS ab AWS
1. Öffnen Sie Ihr Terminal.
1. Stellen Sie sicher, dass die AWS CLI installiert und konfiguriert ist. Weitere Informationen finden Sie unter [Installation oder Aktualisierung auf die neueste Version der CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Führen Sie den folgenden Befehl aus:
```
aws eks describe-cluster-versions
```
1. Der Befehl gibt eine JSON-Ausgabe mit Details zu den verfügbaren Cluster-Versionen zurück. Nachfolgend finden Sie ein Beispiel für die Ausgabe:
```
{
"clusterVersions": [
{
"clusterVersion": "1.31",
"clusterType": "eks",
"defaultPlatformVersion": "eks.21",
"defaultVersion": true,
"releaseDate": "2024-09-25T17:00:00-07:00",
"endOfStandardSupportDate": "2025-11-25T16:00:00-08:00",
"endOfExtendedSupportDate": "2026-11-25T16:00:00-08:00",
"status": "STANDARD_SUPPORT",
"kubernetesPatchVersion": "1.31.3"
}
]
}
```
**Die Ausgabe liefert für jede Cluster-Version die folgenden Informationen:**
+ `clusterVersion`: Die Kubernetes-Version des EKS-Clusters
+ `clusterType`: Der Cluster-Typ (z. B. „eks“)
+ `defaultPlatformVersion`: Die Standardversion der EKS-Plattform
+ `defaultVersion`: Ob es sich um die Standardversion handelt
+ `releaseDate`: Das Datum, an dem diese Version veröffentlicht wurde
+ `endOfStandardSupportDate`: Das Datum, an dem der Standard-Support endet
+ `endOfExtendedSupportDate`: Das Datum, an dem der erweiterte Support endet
+ `status`: Der aktuelle Support-Status der Version, z. B. `STANDARD_SUPPORT` oder `EXTENDED_SUPPORT`
+ `kubernetesPatchVersion`: Die spezifische Kubernetes-Patch-Version
## Amazon EKS-Version FAQs
**Wie viele Kubernetes-Versionen sind mit Standard-Support verfügbar?**
Im Einklang mit der Unterstützung der Kubernetes-Community für Kubernetes-Versionen verpflichtet sich Amazon EKS, jederzeit Unterstützung für mindestens drei Kubernetes-Versionen anzubieten. Wir geben das Ende des Standard-Supports für eine bestimmte Kubernetes-Nebenversion mindestens 60 Tage im Voraus bekannt. Aufgrund des Amazon-EKS-Qualifizierungs- und Freigabeprozesses für neue Kubernetes-Versionen endet der Standard-Support für eine Kubernetes-Version in Amazon EKS nach dem Datum, an dem das Kubernetes-Projekt den Upstream-Support für die Version einstellt.
**Wie lange erhält ein Kubernetes-Standard-Support von Amazon EKS?**
Eine Kubernetes-Version wird ab der ersten Verfügbarkeit in Amazon EKS 14 Monate lang unterstützt. Dies gilt auch dann, wenn Kubernetes eine in Amazon EKS verfügbare Version nicht mehr unterstützt. Wir portieren Sicherheits-Patches, die für die in Amazon EKS unterstützten Kubernetes-Versionen relevant sind, zurück.
**Werde ich benachrichtigt, wenn der Standard-Support für eine Kubernetes-Version in Amazon EKS endet?**
Ja. Wenn auf Clustern in Ihrem Konto die Version ausgeführt wird, die sich dem Ende des Supports nähert, sendet Amazon EKS etwa 12 Monate nach der Veröffentlichung der Kubernetes-Version auf Amazon EKS eine Benachrichtigung über das AWS Health Dashboard. Die Mitteilung enthält das Datum des Support-Laufzeitendes. Dies ist mindestens 60 Tage ab dem Datum der Benachrichtigung.
**Welche Kubernetes-Feature werden von Amazon EKS unterstützt?**
Amazon EKS unterstützt alle allgemein verfügbaren (GA) Feature der Kubernetes-API. Neue Betaversionen APIs sind in Clustern standardmäßig nicht aktiviert. Zuvor vorhandene Betaversionen APIs und neue Versionen vorhandener Betaversionen sind jedoch APIs weiterhin standardmäßig aktiviert. Alpha-Features werden nicht unterstützt.
**Werden von Amazon EKS verwaltete Knotengruppen automatisch zusammen mit der Version der Cluster-Kontrollebene aktualisiert?**
Nein, eine verwaltete Knotengruppe erstellt Amazon-EC2-Instances in Ihrem Konto. Diese Instances werden nicht automatisch aktualisiert, wenn Sie oder Amazon EKS Ihre Steuerebene aktualisieren. Weitere Informationen finden Sie unter [Eine verwaltete Knotengruppe für Ihren Cluster aktualisieren](update-managed-node-group.md). Wir empfehlen, dieselbe Kubernetes-Version auf Ihrer Steuerungsebene und Ihren Knoten beizubehalten.
**Werden selbstverwaltete Knotengruppen automatisch zusammen mit der Version der Cluster-Kontrollebene aktualisiert?**
Nein, eine selbstverwaltete Knotengruppe umfasst Amazon-EC2-Instances in Ihrem Konto. Diese Instances werden nicht automatisch aktualisiert, wenn Sie oder Amazon EKS die Version der Steuerebene in Ihrem Namen aktualisieren. Für eine selbstverwaltete Knotengruppe gibt es in der Konsole keinen Hinweis darauf, dass sie aktualisiert werden muss. Sie können die auf einem Knoten installierte `kubelet`-Version anzeigen, indem Sie den Knoten in der Liste **Knoten** auf der Registerkarte **Übersicht** Ihres Clusters auswählen, um zu bestimmen, welche Knoten aktualisiert werden müssen. Sie müssen die Knoten manuell aktualisieren. Weitere Informationen finden Sie unter [Selbstverwaltete Knoten für Ihren Cluster aktualisieren](update-workers.md).
Das Kubernetes-Projekt überprüft die Kompatibilität zwischen der Steuerebene und den Knoten für bis zu drei Nebenversionen. `1.32`-Knoten funktionieren beispielsweise weiterhin, wenn sie von einer `1.35`-Steuerebene orchestriert werden. Es wird jedoch nicht empfohlen, einen Cluster mit Knoten auszuführen, die sich dauerhaft drei Nebenversionen hinter der Steuerebene befinden. Weitere Informationen finden Sie unter [Kubernetes Version and Version Skew Support Policy](https://kubernetes.io/docs/setup/version-skew-policy/) in der Kubernetes-Dokumentation. Wir empfehlen, dieselbe Kubernetes-Version auf Ihrer Steuerungsebene und Ihren Knoten beizubehalten.
**Werden Pods, die in Fargate ausgeführt werden, automatisch mit einem automatischen Upgrade der Cluster-Steuerebenen-Version aktualisiert?**
Nein. Wir empfehlen dringend, Fargate-Pods als Teil eines Replikations-Controllers wie einer Kubernetes-Bereitstellung auszuführen. Führen Sie anschließend einen fortlaufenden Neustart aller Fargate-Pods durch. Die neue Version des Fargate-Pods wird mit einer `kubelet`-Version bereitgestellt, die dieselbe Version wie Ihre aktualisierte Version der Cluster-Steuerebene ist. Weitere Informationen finden Sie unter [Bereitstellungen](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) in der Kubernetes-Dokumentation.
Wenn Sie die Steuerebene aktualisieren, müssen Sie die Fargate-Knoten nach wie vor selbst aktualisieren. Um Fargate-Knoten zu aktualisieren, löschen Sie den Fargate-Pod, der durch den Knoten repräsentiert wird, und stellen Sie den Pod erneut bereit. Der neue Pod wird mit einer `kubelet`-Version bereitgestellt, die der Version Ihres Clusters entspricht.
**Welche Kubernetes-Versionen werden für Hybridknoten unterstützt?**
Amazon EKS Hybrid Nodes unterstützt dieselben Kubernetes-Versionen wie Amazon-EKS-Cluster mit anderen Knoten-Rechentypen, einschließlich Support für Standard- und erweiterte Kubernetes-Versionen. Hybridknoten werden bei einer Aktualisierung Ihrer Steuerebenen-Version nicht automatisch aktualisiert. Sie sind für die Aktualisierung Ihrer Hybridknoten verantwortlich. Weitere Informationen finden Sie unter [Aktualisierung von Hybridknoten für Ihren Cluster](hybrid-nodes-upgrade.md).
## Erweiterter Support für Amazon EKS FAQs
**Die Begriffe Standard-Support und erweiterter Support sind mir neu. Was bedeuten diese Begriffe?**
Der Standard-Support für eine Kubernetes-Version in Amazon EKS beginnt mit der Veröffentlichung einer Kubernetes-Version in Amazon EKS und endet 14 Monate nach dem Veröffentlichungsdatum. Der erweiterte Support für eine Kubernetes-Version beginnt unmittelbar nach dem Ende des Standard-Supports und endet nach 12 Monaten. Beispielsweise endet der Standard-Support für die Version `1.23` in Amazon EKS am 11. Oktober 2023. Der erweiterte Support für die Version `1.23` beginnt am 12. Oktober 2023 und endet am 11. Oktober 2024.
**Was muss ich tun, um erweiterten Support für Amazon-EKS-Cluster zu erhalten?**
Sie müssen den erweiterten Support (siehe [Erweiterter EKS-Support](https://docs.aws.amazon.com/eks/latest/userguide/enable-extended-support.html)) für Ihren Cluster aktivieren, indem Sie die Cluster-Upgrade-Richtlinie auf EXTENDED ändern. Standardmäßig ist die Upgrade-Richtlinie für alle neuen und vorhandenen Cluster auf EXTENDED festgelegt, sofern nicht anders angegeben. Die Upgrade-Richtlinie für Ihren Cluster finden Sie unter [Cluster-Upgrade-Richtlinie](https://docs.aws.amazon.com/eks/latest/userguide/view-upgrade-policy.html). Der Standard-Support beginnt mit der Veröffentlichung einer Kubernetes-Version in Amazon EKS und endet 14 Monate nach dem Veröffentlichungsdatum. Der erweiterte Support für eine Kubernetes-Version beginnt unmittelbar nach dem Ende des Standard-Supports und endet nach 12 Monaten.
**Für welche Kubernetes-Versionen kann ich erweiterten Support erhalten?**
Sie können Cluster auf jeder Version bis zu 12 Monate nach dem Ende des Standard-Supports für diese Version ausführen. Das bedeutet, dass jede Version 26 Monate lang in Amazon EKS unterstützt wird (14 Monate Standard-Support plus 12 Monate verlängerter Support).
**Was ist, wenn ich den erweiterten Support nicht nutzen möchte?**
Wenn Sie nicht automatisch für den erweiterten Support angemeldet werden möchten, können Sie Ihren Cluster auf eine Kubernetes-Version aktualisieren, die im Standard-Amazon-EKS-Support enthalten ist. Informationen zum Deaktivieren des erweiterten Supports finden Sie unter [Erweiterten EKS-Support deaktivieren](https://docs.aws.amazon.com/eks/latest/userguide/disable-extended-support.html). Hinweis: Wenn Sie den erweiterten Support deaktivieren, wird Ihr Cluster am Ende des Standard-Supports automatisch aktualisiert.
**Was passiert nach Ablauf des 12-monatigen erweiterten Supports?**
Cluster, die in einer Kubernetes-Version ausgeführt werden, deren 26-monatiger Lebenszyklus (14 Monate Standard-Support plus 12 Monate erweiterter Support) abgelaufen ist, werden automatisch auf die nächste Version aktualisiert. Die automatische Aktualisierung umfasst ausschließlich die Kubernetes-Steuerebene. Wenn Sie über Knoten von EKS Auto Mode verfügen, werden diese möglicherweise automatisch aktualisiert. Selbstverwaltete Knoten und von EKS verwaltete Knotengruppen bleiben auf der vorherigen Version.
Nach Ablauf des verlängerten Supports können Sie mit der nicht unterstützten Version keine neuen Amazon-EKS-Cluster mehr erstellen. Vorhandene Steuerebenen werden von Amazon EKS durch einen schrittweisen Bereitstellungsprozess nach dem Datum des Support-Laufzeitendes automatisch auf die älteste unterstützte Version aktualisiert. Nach der automatischen Aktualisierung der Steuerebene müssen Sie Cluster-Add-ons und Amazon-EC2-Knoten manuell aktualisieren. Weitere Informationen finden Sie unter [Aktualisierung des vorhandenen Clusters auf die neue Kubernetes-Version](update-cluster.md).
**Wann genau wird meine Steuerebene nach Ablauf des erweiterten Supports automatisch aktualisiert?**
Amazon EKS kann keine spezifischen Zeitrahmen bereitstellen. Automatische Updates können jederzeit nach Ablauf des verlängerten Supports erfolgen. Sie erhalten vor der Aktualisierung keine Benachrichtigung. Wir empfehlen Ihnen, dass Sie Ihre Steuerebene proaktiv aktualisieren, ohne sich auf den automatischen Aktualisierungsprozess von Amazon EKS zu verlassen. Weitere Informationen finden Sie unter [Aktualisierung des vorhandenen Clusters auf die neue Kubernetes-Version](update-cluster.md).
**Kann ich meine Steuerebene auf unbestimmte Zeit auf einer Kubernetes-Version belassen?**
Nein. Cloud-Sicherheit AWS hat höchste Priorität. Ab einem bestimmten Zeitpunkt (normalerweise nach einem Jahr) veröffentlicht die Kubernetes-Community keine Patches mehr für allgemeine Schwachstellen und Risiken (CVE) und rät von der Einreichung von CVEs für nicht unterstützte Versionen ab. Dies bedeutet, dass Schwachstellen, die speziell für eine ältere Version von Kubernetes gelten, möglicherweise nicht gemeldet werden. Daher können Cluster im Falle einer Schwachstelle ohne Vorankündigung und ohne Behebungsoptionen offengelegt werden. Amazon EKS lässt daher nicht zu, dass Steuerebenen auf einer Version verbleiben, die das Ende des erweiterten Supports erreicht hat.
**Fallen zusätzliche Kosten für den erweiterten Support an?**
Ja, für Amazon-EKS-Cluster, die im erweiterten Support ausgeführt werden, fallen zusätzliche Kosten an. Preisinformationen finden Sie im AWS Blog oder auf unserer [Preisseite](https://aws.amazon.com/eks/pricing/) unter [Preise für die erweiterte Unterstützung für Kubernetes-Versionen von Amazon EKS](https://aws.amazon.com/blogs/containers/amazon-eks-extended-support-for-kubernetes-versions-pricing).
**Was ist im erweiterten Support enthalten?**
Amazon-EKS-Cluster im verlängerten Support erhalten fortlaufend Sicherheits-Patches für die Kubernetes-Steuerebene. Darüber hinaus wird Amazon EKS Patches für Amazon VPC CNI, `kube-proxy` und CoreDNS-Add-Ons für erweiterte Support-Versionen veröffentlichen. Amazon EKS wird auch Patches für AWS veröffentlichte Amazon EKS veröffentlichen, die AMIs für Amazon Linux, Bottlerocket und Windows optimiert sind, sowie für Amazon EKS Fargate-Knoten für diese Versionen. Alle Cluster im erweiterten Support erhalten weiterhin Zugriff auf technischen Support von AWS.
**Gibt es im Rahmen des verlängerten Supports Einschränkungen bei Patches für Komponenten, die keine Kubernetes-Komponenten sind?**
Extended Support deckt zwar alle Kubernetes-spezifischen Komponenten von ab AWS, bietet aber jederzeit nur Support für Amazon EKS, AWS das AMIs für Amazon Linux, Bottlerocket und Windows optimiert ist. Das bedeutet, dass Sie möglicherweise neuere Komponenten (wie Betriebssystem oder Kernel) auf Ihrem für Amazon EKS optimierten AMI haben werden, während Sie den verlängerten Support verwenden. Sobald Amazon Linux 2 beispielsweise [2025 das Ende seines Lebenszyklus](https://aws.amazon.com/amazon-linux-2/faqs/) erreicht, AMIs wird das für Amazon EKS optimierte Amazon Linux mit einem neueren Amazon Linux-Betriebssystem erstellt. Amazon EKS wird wichtige Abweichungen im Support-Lebenszyklus wie diese für jede Kubernetes-Version bekannt geben und dokumentieren.
**Kann ich mit einer Version mit erweitertem Support neue Cluster erstellen?**
Ja.
# Versionshinweise für Kubernetes-Versionen mit Standard-Support anzeigen
**Tipp**
[Melden Sie sich](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) 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.35
Kubernetes `1.35` ist jetzt in Amazon EKS verfügbar. Weitere Informationen zu Kubernetes `1.35` finden Sie in der [offiziellen Versionsankündigung](https://kubernetes.io/blog/2025/12/17/kubernetes-v1-35-release/).
**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 die Verwendung von cgroup v1 manuell konfiguriert haben, müssen entweder AL2023 [zu cgroups v2 migrieren](https://kubernetes.io/docs/concepts/architecture/cgroups/) 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.](https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/)
+ **In-Place-Updates für Pod-Ressourcen (stabil):** Mit In-Place-Updates für Pod-Ressourcen 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 unter [Kubernetes 1.35: In-Place Pod Resize](https://kubernetes.io/blog/2025/12/19/kubernetes-v1-35-in-place-pod-resize-ga/) Graduates to Stable im Kubernetes-Blog.*
+ **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ührt`PreferSameNode`, 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 one-at-a-time Updates, wodurch die Wartungsfenster erheblich reduziert werden.
+ **Windows Server 2025-Unterstützung:** EKS 1.35 fügt Support für [Windows Server 2025](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-windows-ami.html) 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 Kubernetes-Changelog finden Sie unter -1.35.md `1.35` https://github.com/kubernetes/ kubernetes/blob/master/CHANGELOG/CHANGELOG
## 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](https://kubernetes.io/blog/2025/08/27/kubernetes-v1-34-release/).
**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](https://github.com/containerd/containerd/releases/tag/v2.1.0).
AWS veröffentlicht kein EKS-optimiertes 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](al2023.md).
Weitere Informationen finden Sie unter [Veraltung von Amazon Linux 2 AMI](#al2-ami-deprecation).
AppArmor ist in Kubernetes 1.34 veraltet.
[https://kubernetes.io/docs/tutorials/security/seccomp/](https://kubernetes.io/docs/tutorials/security/seccomp/)
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](https://gallery.ecr.aws/csi-components) in der ECR-Galerie) verwenden, funktioniert die Volumenänderung weiterhin problemlos auf EKS 1.31-1.33-Clustern. AWS wird die Sidecars so patchen, dass sie APIs bis zum Ende der Standardunterstützung für EKS 1.33 (29. Juli 2026) Beta VAC 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 service-account-extend-token Ablaufkennzeichen -- nicht mehr vollständig eingehalten. 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](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-tokens), die automatisch von Kubernetes bereitgestellt und rotiert werden.
+ **Dynamic Resource Allocation (DRA) Core APIs (GA):** Die dynamische Ressourcenzuweisung ist inzwischen stabil und ermöglicht eine effiziente Verwaltung spezialisierter Hardware, z. B. 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.
+ **Ressourcenanforderungen und Grenzwerte auf Pod-Ebene (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 Attribut CSINode Max Attachable Volume Count veränderbar ist und ein Mechanismus eingeführt wird, mit dem es dynamisch auf der Grundlage der Benutzerkonfiguration auf CSI-Treiberebene aktualisiert werden kann. 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](https://kubernetes.io/blog/2025/09/11/kubernetes-v1-34-mutable-csi-node-allocatable-count/) 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-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.](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)
Das vollständige `1.34` Kubernetes-Changelog finden Sie unter -1.34.md https://github.com/kubernetes/ kubernetes/blob/master/CHANGELOG/CHANGELOG
## 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](https://kubernetes.io/blog/2025/04/23/kubernetes-v1-33-release/).
**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 erfordern, wie z. GPUs
Die Beta-API wird von der Kubernetes-Community definiert und kann sich in zukünftigen Versionen von Kubernetes ändern.
Lesen Sie die [Feature-Phasen](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#feature-stages) in der Kubernetes-Dokumentation sorgfältig durch, um die Auswirkungen der Beta-Version zu verstehen. APIs
AWS veröffentlicht kein EKS-optimiertes 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](al2023.md).
Weitere Informationen finden Sie unter [Veraltung von Amazon Linux 2 AMI](#al2-ami-deprecation).
+ **Pod-Ressourcenanpassung vor Ort (Beta):** Die Ressourcenanpassung vor Ort wurde in die Beta-Phase hochgestuft, sodass CPU- und Speicherressourcen für vorhandene Pods ohne Neustart dynamisch aktualisiert werden können. Dies ermöglicht die vertikale Skalierung von zustandsbehafteten Workloads ohne Ausfallzeiten und eine nahtlose Ressourcenanpassung basierend auf Datenverkehrsmustern.
+ **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](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/) 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 pro Service verarbeitet. EndpointSlices
+ *Weitere Informationen finden Sie im Kubernetes-Blog unter [Kubernetes v1.33:](https://kubernetes.io/blog/2025/04/24/endpoints-deprecation/) 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html) im Amazon Elastic Compute Cloud-Benutzerhandbuch.
Das vollständige `1.33` Kubernetes-Changelog finden Sie unter -1.33.md https://github.com/kubernetes/ kubernetes/blob/master/CHANGELOG/CHANGELOG
## Kubernetes 1.32
Kubernetes `1.32` ist jetzt in Amazon EKS verfügbar. Weitere Informationen zu Kubernetes `1.32` finden Sie in der [offiziellen Versionsankündigung](https://kubernetes.io/blog/2024/12/11/kubernetes-v1-32-release/).
**Wichtig**
Die `flowcontrol.apiserver.k8s.io/v1beta3` API-Version von FlowSchema und PriorityLevelConfiguration wurde in Version entfernt. `1.32` Wenn Sie diese verwenden APIs, müssen Sie Ihre Konfigurationen aktualisieren, um die neueste unterstützte Version zu verwenden, bevor Sie das Upgrade durchführen.
ServiceAccount `metadata.annotations[kubernetes.io/enforce-mountable-secrets]`ist in der Version veraltet `1.32` und wird in einer future Kubernetes-Nebenversion entfernt. Es wird empfohlen, separate Namespaces zu verwenden, um den Zugriff auf eingebundene Geheimnisse zu isolieren.
Die Kubernetes-Version `1.32` ist die letzte Version, für die Amazon EKS Amazon Linux 2 () AL2 veröffentlichen wird. AMIs `1.33`Ab der Version wird Amazon EKS weiterhin Amazon Linux 2023 (AL2023) und Bottlerocket-basierte Versionen veröffentlichen. AMIs
+ Das Memory-Manager-Feature hat in Kubernetes Version `1.32` den Status „Generally Available“ (GA) erreicht. Diese Verbesserung ermöglicht eine effizientere und besser vorhersehbare Speicherzuweisung für containerisierte Anwendungen. Dies ist besonders vorteilhaft für Workloads mit spezifischen Speicheranforderungen.
+ PersistentVolumeClaims (PVCs), die StatefulSets inzwischen erstellt wurden, enthalten automatische Bereinigungsfunktionen. Wenn sie nicht mehr benötigt PVCs werden, werden sie automatisch gelöscht, wobei die Datenpersistenz bei StatefulSet Updates und Knotenwartungsvorgängen erhalten bleibt. Diese Funktion vereinfacht die Speicherverwaltung und verhindert, dass PVCs in Ihrem Cluster verwaiste Speicher entstehen.
+ Es wurde die Funktion „Benutzerdefinierte Ressourcenfeldauswahl“ eingeführt, mit der Entwickler Feldauswahlfunktionen zu benutzerdefinierten Ressourcen hinzufügen können. Dieses Feature bietet dieselben Filterfunktionen, die für integrierte Kubernetes-Objekte verfügbar sind, auch für benutzerdefinierte Ressourcen. Dadurch wird eine präzisere und effizientere Ressourcenfilterung ermöglicht und ein besseres API-Design gefördert.
Das vollständige `1.32` Kubernetes-Changelog finden Sie unter -1.32.md https://github.com/kubernetes/ kubernetes/blob/master/CHANGELOG/CHANGELOG
### Änderungen bei der anonymen Authentifizierung
Beim Einstieg mit Amazon EKS `1.32` ist die anonyme Authentifizierung auf die folgenden Endpunkte für die Zustandsprüfung des API-Serverstatus beschränkt:
+ `/healthz`
+ `/livez`
+ `/readyz`
Anfragen an andere Endpunkte, die den `system:unauthenticated`-Benutzer verwenden, erhalten eine `401 Unauthorized`-HTTP-Antwort. Diese Sicherheitsverbesserung trägt dazu bei, unbeabsichtigten Cluster-Zugriff zu verhindern, der aufgrund falsch konfigurierter RBAC-Richtlinien auftreten könnte.
**Anmerkung**
Die `public-info-viewer`-RBAC-Rolle gilt weiterhin für die oben aufgeführten Endpunkte der Zustandsprüfung.
### Veraltung von Amazon Linux 2 AMI
Die Kubernetes-Version `1.32` ist die letzte Version, für die Amazon EKS veröffentlicht wurde. AL2 AMIs `1.33`Ab der Version wird Amazon EKS weiterhin veröffentlicht AL2023 und auf Bottlerocket basieren. AMIs Weitere Informationen finden Sie unter [Leitfaden zu den Funktionen von EKS AL2 und AL2 -Accelerated AMIs Transition](eks-ami-deprecation-faqs.md).
# Versionshinweise für Kubernetes-Versionen mit erweitertem Support anzeigen
Amazon EKS unterstützt Kubernetes-Versionen länger als Upstream-Versionen, mit Standard-Support für Kubernetes-Nebenversionen für 14 Monate ab dem Zeitpunkt ihrer Veröffentlichung in Amazon EKS und erweitertem Support für Kubernetes-Nebenversionen für weitere 12 Monate Support (insgesamt 26 Monate pro Version).
Dieses Thema erläutert wichtige Änderungen, die Sie für jede Kubernetes-Version des verlängerten Supports 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.31
Kubernetes `1.31` ist jetzt in Amazon EKS verfügbar. Weitere Informationen zu Kubernetes `1.31` finden Sie in der [offiziellen Versionsankündigung](https://kubernetes.io/blog/2024/08/13/kubernetes-v1-31-release/).
**Wichtig**
Das seit 2017 veraltete Kubelet-Flag `--keep-terminated-pod-volumes` wurde im Rahmen der Veröffentlichung der Version `1.31` entfernt. Diese Änderung wirkt sich darauf aus, wie gekündigte Pod-Volumes vom Kubelet verarbeitet werden. Wenn Sie dieses Flag in Ihren Knotenkonfigurationen verwenden, müssen Sie Ihre Bootstrap-Skripte und Startvorlagen aktualisieren, um es vor der Aktualisierung zu entfernen.
+ Das Beta-Feature Gate `VolumeAttributesClass` und die API-Ressource sind in der Amazon-EKS-Version `1.31` aktiviert. Mit dieser Funktion können Cluster-Betreiber veränderbare Eigenschaften von Persistent Volumes (PVs) ändern, die von kompatiblen CSI-Treibern verwaltet werden, einschließlich des Amazon EBS CSI-Treibers. Um dieses Feature nutzen zu können, stellen Sie sicher, dass Ihr CSI-Treiber das `VolumeAttributesClass`-Feature unterstützt (für den Amazon-EBS-CSI-Treiber führen Sie ein Upgrade auf Version `1.35.0` oder höher durch, um das Feature automatisch zu aktivieren). Sie können `VolumeAttributesClass` Objekte erstellen, um die gewünschten Volumenattribute wie Volume-Typ und Durchsatz zu definieren und sie Ihren Persistent Volume Claims () PVCs zuzuordnen. Weitere Informationen finden Sie in der [offiziellen Kubernetes-Dokumentation](https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/) sowie in der Dokumentation Ihres CSI-Treibers.
+ Weitere Informationen zum Amazon-EBS-CSI-Treiber finden Sie unter [Kubernetes-Volume-Speicher mit Amazon EBS verwenden](ebs-csi.md).
+ Die Kubernetes-Unterstützung für [AppArmor](https://apparmor.net/)wurde auf Stable umgestellt und ist nun allgemein für die öffentliche Nutzung verfügbar. Mit dieser Funktion können Sie Ihre Container schützen, AppArmor indem Sie das `appArmorProfile.type` Feld in den Containern festlegen. `securityContext` Vor der Kubernetes-Version AppArmor wurde `1.30` es durch Anmerkungen gesteuert. Ab Version `1.30` erfolgt die Steuerung über Felder. Um dieses Feature optimal zu nutzen, empfehlen wir, Annotationen zu migrieren und das `appArmorProfile.type`-Feld zu verwenden, um die Kompatibilität Ihrer Workloads sicherzustellen.
+ Die Funktion zur Übergangszeit in der PersistentVolume letzten Phase wurde auf Stable umgestellt und ist nun in der Kubernetes-Version allgemein für den öffentlichen Gebrauch verfügbar. `1.31` Mit dieser Funktion wird ein neues Feld eingeführt,`.status.lastTransitionTime`, in dem ein Zeitstempel angegeben wird PersistentVolumeStatus, wann das PersistentVolume letzte Mal in eine andere Phase übergegangen ist. Diese Erweiterung ermöglicht eine bessere Nachverfolgung und Verwaltung von PersistentVolumes, insbesondere in Szenarien, in denen es wichtig ist, den Lebenszyklus von Volumen zu verstehen.
Das vollständige `1.31` Kubernetes-Changelog finden Sie unter -1.31.md https://github.com/kubernetes/ kubernetes/blob/master/CHANGELOG/CHANGELOG
## Kubernetes 1.30
Kubernetes `1.30` ist jetzt in Amazon EKS verfügbar. Weitere Informationen zu Kubernetes `1.30` finden Sie in der [offiziellen Versionsankündigung](https://kubernetes.io/blog/2024/04/17/kubernetes-v1-30-release/).
+ Ab der Amazon EKS-Version `1.30` oder neuer verwenden alle neu erstellten verwalteten Knotengruppen automatisch standardmäßig Amazon Linux 2023 (AL2023) als Knotenbetriebssystem. Weitere Informationen zum Festlegen des Betriebssystems für eine verwaltete Knotengruppe finden Sie unter [Eine verwaltete Knotengruppe für Ihren Cluster erstellen](create-managed-node-group.md).
+ Mit Amazon EKS `1.30` wird das `topology.k8s.aws/zone-id`-Label den Worker-Knoten hinzugefügt. Sie können die Availability Zone IDs (AZ IDs) verwenden, um den Standort von Ressourcen in einem Konto im Verhältnis zu den Ressourcen in einem anderen Konto zu bestimmen. Weitere Informationen finden Sie im * AWS RAM-Benutzerhandbuch* unter [Availability Zone IDs für Ihre AWS Ressourcen](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html).
+ Ab Version `1.30` enthält Amazon EKS keine `default`-Annotation mehr zu den `gp2 StorageClass`-Ressourcen, die auf neu erstellte Cluster angewendet werden. Dies hat keine Auswirkungen, wenn Sie namentlich auf diese Speicherklasse verweisen. Sie müssen Maßnahmen ergreifen, wenn Sie sich darauf verlassen, dass im Cluster ein Standard-`StorageClass` vorhanden ist. Sie sollten auf `StorageClass` mit dem Namen `gp2` verweisen. Alternativ können Sie die von Amazon EBS empfohlene Standardspeicherklasse bereitstellen, indem Sie den `defaultStorageClass.enabled`-Parameter bei der Installation von Version `1.31.0` oder höher von `aws-ebs-csi-driver add-on` auf „true“ setzen.
+ Die erforderliche Mindest-IAM-Richtlinie für die IAM-Rolle des Amazon-EKS-Clusters wurde geändert. Die Aktion `ec2:DescribeAvailabilityZones` ist erforderlich. Weitere Informationen finden Sie unter [Amazon-EKS-Cluster-IAM-Rolle](cluster-iam-role.md).
Das vollständige `1.30` Kubernetes-Changelog finden Sie unter -1.30.md. https://github.com/kubernetes/ kubernetes/blob/master/CHANGELOG/CHANGELOG
## Kubernetes 1.29
Kubernetes `1.29` ist jetzt in Amazon EKS verfügbar. Weitere Informationen zu Kubernetes `1.29` finden Sie in der [offiziellen Versionsankündigung](https://kubernetes.io/blog/2023/12/13/kubernetes-v1-29-release/).
**Wichtig**
Die veralteten `flowcontrol.apiserver.k8s.io/v1beta2`-API-Versionen `FlowSchema` und `PriorityLevelConfiguration` werden in Kubernetes Version `1.29` nicht mehr bereitgestellt. Falls Sie über Manifeste oder Clientsoftware verfügen, welche die veraltete Beta-API-Gruppe verwenden, sollten Sie diese vor der Aktualisierung auf Version `1.29` ändern.
+ Das `.status.kubeProxyVersion`-Feld für Knotenobjekte ist nun veraltet, und das Kubernetes-Projekt schlägt vor, dieses Feld in einer zukünftigen Version zu entfernen. Das veraltete Feld ist nicht korrekt und wurde in der Vergangenheit von `kubelet` verwaltet, das weder die `kube-proxy`-Version kennt noch weiß, ob `kube-proxy` ausgeführt wird. Wenn Sie dieses Feld in Ihrer Clientsoftware verwendet haben, sollten Sie dies unterlassen, da die Informationen nicht zuverlässig sind und das Feld nun veraltet ist.
+ Um die potenzielle Angriffsfläche in Kubernetes `1.29` zu reduzieren, kennzeichnet das `LegacyServiceAccountTokenCleanUp`-Feature automatisch generierte geheime Tokens als ungültig, wenn sie längere Zeit (standardmäßig 1 Jahr) nicht verwendet wurden, und entfernt sie automatisch, wenn nach der Kennzeichnung als ungültig (standardmäßig 1 weiteres Jahr) längere Zeit keine Verwendung erfolgt. Um solche Tokens zu identifizieren, können Sie folgenden Befehl ausführen:
```
kubectl get cm kube-apiserver-legacy-service-account-token-tracking -n kube-system
```
Das vollständige `1.29` Kubernetes-Changelog finden Sie unter -1.29.md\$1 1280. https://github.com/kubernetes/ kubernetes/blob/master/CHANGELOG/CHANGELOG changelog-since-v
# Aktuellen Cluster-Supportzeitraum anzeigen
Der Abschnitt **Cluster-Supportzeitraum** der AWS-Konsole zeigt an, ob Ihr Cluster *derzeit* Standard- oder erweiterten Support erhält. Wenn es sich bei Ihrem Cluster-Supportzeitraum um **Erweiterter Support** handelt, wird Ihnen der erweiterte EKS-Support in Rechnung gestellt.
Weitere Informationen zu Standard- und erweitertem Support finden Sie unter [Informationen zum Lebenszyklus der Kubernetes-Version in EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
1. Navigieren Sie zur Seite **Cluster** im Abschnitt „EKS“ der AWS-Konsole. Vergewissern Sie sich, dass die AWS-Konsole auf dieselbe Region eingestellt ist wie der Cluster, den Sie überprüfen möchten.
1. Überprüfen Sie die Spalte **Supportzeitraum**. Wenn der Wert **Standard-Support bis …** lautet, fallen für Sie derzeit keine Kosten für den erweiterten Support an. Sie befinden sich innerhalb des Standard-Supportzeitraums. Wenn der Wert **Erweiterter Support …** lautet, fallen für diesen Cluster derzeit Kosten für den erweiterten Support an.
**Anmerkung**
Der **Supportzeitraum** kann nicht über die AWS-API oder CLI abgerufen werden.
# Aktuelle Cluster-Upgrade-Richtlinie anzeigen
Die **Cluster-Upgrade-Richtlinie** bestimmt, was mit Ihrem Cluster passiert, wenn der Standard-Supportzeitraum endet. Wenn Ihre Upgrade-Richtlinie `EXTENDED` lautet, wird der Cluster nicht automatisch aktualisiert und erhält erweiterten Support. Wenn Ihre Upgrade-Richtlinie `STANDARD` lautet, wird er automatisch aktualisiert.
Mit den Amazon-EKS-Steuerelementen für die Kubernetes-Versionsrichtlinie können Sie das Ende des Standard-Supports für Ihre EKS-Cluster festlegen. Mit diesen Steuerelementen können Sie entscheiden, welche Cluster in den erweiterten Support übergehen und welche Cluster am Ende des Standard-Supports für eine Kubernetes-Version automatisch aktualisiert werden sollen.
Eine Nebenversion wird in den ersten 14 Monaten nach ihrer Veröffentlichung standardmäßig in Amazon EKS unterstützt. Sobald eine Version das Ende des Standard-Supportdatums überschritten hat, wird für die folgenden 12 Monate ein erweiterter Support angeboten. Mit dem erweiterten Support können Sie gegen Aufpreis pro Cluster-Stunde länger bei einer bestimmten Kubernetes-Version bleiben. Sie können den erweiterten Support für einen EKS-Cluster aktivieren oder deaktivieren. Wenn Sie den erweiterten Support deaktivieren, aktualisiert AWS Ihren Cluster am Ende des Standard-Supports automatisch auf die nächste Version. Wenn Sie den erweiterten Support aktivieren, können Sie gegen eine zusätzliche Gebühr für einen begrenzten Zeitraum bei der aktuellen Version bleiben. Planen Sie regelmäßige Upgrades Ihres Kubernetes-Clusters ein, auch wenn Sie den erweiterten Support nutzen.
Sie können die Versionsrichtlinie für neue und bestehende Cluster mithilfe der `supportType`-Eigenschaft festlegen. Zur Festlegung der Richtlinie für die Versionsunterstützung stehen zwei Optionen zur Verfügung:
+ ` STANDARD ` – Ihr EKS-Cluster ist am Ende des Standard-Supports für ein automatisches Upgrade berechtigt. Mit dieser Einstellung fallen keine zusätzlichen Supportkosten an, jedoch wird Ihr EKS-Cluster automatisch auf die nächste unterstützte Kubernetes-Version im Standard-Support aktualisiert.
+ ` EXTENDED ` – Ihr EKS-Cluster wird in den erweiterten Support übergehen, sobald die Kubernetes-Version das Ende des Standard-Supports erreicht. Bei dieser Einstellung fallen zusätzliche Support-Gebühren an. Sie können Ihren Cluster auf eine standardmäßig unterstützte Kubernetes-Version aktualisieren, um die erweiterten Support-Gebühren zu vermeiden. Cluster, die mit erweitertem Support ausgeführt werden, können am Ende des erweiterten Supports automatisch aktualisiert werden.
Der erweiterte Support ist standardmäßig für neue Cluster und vorhandene Cluster aktiviert. Sie können überprüfen, ob der erweiterte Support für ein Cluster aktiviert ist, indem Sie die AWS-Managementkonsole aufrufen oder die AWS CLI verwenden.
**Wichtig**
Wenn Sie möchten, dass Ihr Cluster die aktuelle Kubernetes-Version beibehält, um die Vorteile des erweiterten Supportzeitraums zu nutzen, müssen Sie die Upgrade-Richtlinie für den erweiterten Support vor dem Ende des Standard-Supportzeitraums aktivieren.
Sie können die Richtlinie zur Versionsunterstützung für Ihre Cluster nur festlegen, wenn diese unter Kubernetes-Version im Standard-Support ausgeführt werden. Sie diese Einstellung nicht mehr ändern, bis Sie wieder unter einer Version im Standard-Support ausgeführt werden.
Wenn Sie beispielsweise Ihre Richtlinie zur Versionsunterstützung auf `standard` festgelegt haben, können Sie diese Einstellung nicht mehr ändern, nachdem die auf Ihrem Cluster ausgeführte Kubernetes-Version das Ende des Standard-Supports erreicht hat. Wenn Sie Ihre Richtlinie zur Versionsunterstützung auf `extended` festgelegt haben, können Sie diese Einstellung nicht mehr ändern, nachdem die auf Ihrem Cluster ausgeführte Kubernetes-Version das Ende des Standard-Supports erreicht hat. Um die Einstellung für die Richtlinie zur Versionsunterstützung zu ändern, muss Ihr Cluster in einer standardmäßig unterstützten Kubernetes-Version ausgeführt werden.
## Cluster-Upgrade-Richtlinie anzeigen (AWS-Konsole)
1. Navigieren Sie zur Seite **Cluster** im Abschnitt „EKS“ der AWS-Konsole. Vergewissern Sie sich, dass die AWS-Konsole auf dieselbe Region eingestellt ist wie der Cluster, den Sie überprüfen möchten.
1. Überprüfen Sie die Spalte **Upgrade-Richtlinie**. Wenn der Wert **Standard-Support** lautet, wird Ihr Cluster nicht in den erweiterten Support aufgenommen. Wenn der Wert **Erweiterter Support** lautet, wird Ihr Cluster in den erweiterten Support übernommen.
## Cluster-Upgrade-Richtlinie anzeigen (AWS-CLI)
1. Überprüfen Sie, ob die AWS-CLI installiert ist und Sie angemeldet sind. [Erfahren Sie, wie Sie die AWS-CLI aktualisieren und installieren.](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
1. Bestimmen Sie den Namen Ihres EKS-Clusters. Legen Sie die CLI auf dieselbe AWS-Region wie Ihren EKS-Cluster fest.
1. Führen Sie den folgenden Befehl aus:
```
aws eks describe-cluster \
--name \
--query "cluster.upgradePolicy.supportType"
```
1. Wenn der Wert `STANDARD` lautet, wird Ihr Cluster nicht in den erweiterten Support aufgenommen. Wenn der Wert `EXTENDED` lautet, wird Ihr Cluster in den erweiterten Support versetzt.
# Erhöhen der Flexibilität bei der Planung von Kubernetes-Versions-Upgrades durch die Aktivierung der erweiterten EKS-Unterstützung
In diesem Thema wird beschrieben, wie Sie die *Upgrade-Richtlinie* eines EKS-Clusters festlegen, um erweiterten Support zu aktivieren. Die Upgrade-Richtlinie eines EKS-Clusters bestimmt, was geschieht, wenn ein Cluster das Ende der Standard-*Supportzeitraum* erreicht. Wenn für eine Cluster-Upgrade-Richtlinie erweiterter Support aktiviert ist, beginnt die erweiterte Support-Phase nach Ablauf der Standard-Support-Phase. Der Cluster wird nach Ablauf der Standard-Support-Phase nicht automatisch aktualisiert.
Cluster, die sich tatsächlich in der *erweiterten Support-Phase* befinden, verursachen höhere Kosten. Wenn für einen Cluster lediglich die Upgrade-Richtlinie zur Aktivierung des erweiterten Supports festgelegt ist und er sich ansonsten im *Standard-Support-Phase* befindet, fallen Standardkosten an.
Wenn Sie einen Cluster in der AWS-Konsole erstellen, ist die Upgrade-Richtlinie für diesen Cluster so festgelegt, dass der erweiterte Support deaktiviert wird. Wenn Sie einen Cluster auf andere Weise erstellen, ist die Upgrade-Richtlinie so festgelegt, dass der erweiterte Support aktiviert ist. Beispielsweise ist für mit der AWS API erstellte Cluster der erweiterte Support aktiviert.
Weitere Informationen zu Upgrade-Richtlinien finden Sie unter [Cluster-Upgrade-Richtlinie](https://docs.aws.amazon.com/eks/latest/userguide/view-upgrade-policy.html).
**Wichtig**
Wenn Sie möchten, dass Ihr Cluster die aktuelle Kubernetes-Version beibehält, um die Vorteile des erweiterten Supportzeitraums zu nutzen, müssen Sie die Upgrade-Richtlinie für den erweiterten Support vor dem Ende des Standard-Supportzeitraums aktivieren.
Wenn Sie den erweiterten Support nicht aktivieren, wird Ihr Cluster automatisch aktualisiert.
## Erweiterten Support für EKS aktivieren (AWS-Konsole)
1. Navigieren Sie in der AWS-Konsole zu Ihrem EKS-Cluster. Wählen Sie auf der Seite **Cluster-Informationen** die Registerkarte **Übersicht** aus.
1. Wählen Sie im Abschnitt **Kubernetes-Versionseinstellungen** die Option **Verwalten** aus.
1. Wählen Sie **Erweiterter Support** und dann **Änderungen speichern** aus.
## Erweiterten Support für EKS aktivieren (AWS-CLI)
1. Überprüfen Sie, ob die AWS-CLI installiert ist und Sie angemeldet sind. [Erfahren Sie, wie Sie die AWS-CLI aktualisieren und installieren.](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
1. Bestimmen Sie den Namen Ihres EKS-Clusters.
1. Führen Sie den folgenden Befehl aus:
```
aws eks update-cluster-config \
--name \
--upgrade-policy supportType=EXTENDED
```
# Verhindern Sie erhöhte Cluster-Kosten, indem Sie den erweiterten Support für EKS deaktivieren.
In diesem Thema wird beschrieben, wie Sie die *Upgrade-Richtlinie* eines EKS-Clusters festlegen, um den erweiterten Support zu deaktivieren. Die Upgrade-Richtlinie eines EKS-Clusters bestimmt, was geschieht, wenn ein Cluster das Ende der Standard-*Supportzeitraum* erreicht. Wenn für eine Cluster-Upgrade-Richtlinie der erweiterte Support deaktiviert ist, wird automatisch ein Upgrade auf die nächste Kubernetes-Version durchgeführt.
Weitere Informationen zu Upgrade-Richtlinien finden Sie unter [Cluster-Upgrade-Richtlinie](https://docs.aws.amazon.com/eks/latest/userguide/view-upgrade-policy.html).
**Wichtig**
Sobald Ihr Cluster in den erweiterten Support eingetreten ist, können Sie diesen nicht mehr deaktivieren. Sie können den erweiterten Support nur für Cluster deaktivieren, die sich im Standard-Support befinden.
AWS empfiehlt, Ihren Cluster auf eine Version innerhalb des Standard-Supportzeitraums zu aktualisieren.
## Erweiterten EKS-Support deaktivieren (AWS-Konsole)
1. Navigieren Sie in der AWS-Konsole zu Ihrem EKS-Cluster. Wählen Sie auf der Seite **Cluster-Informationen** die Registerkarte **Übersicht** aus.
1. Wählen Sie im Abschnitt **Kubernetes-Versionseinstellungen** die Option **Verwalten**.
1. Wählen Sie **Standard-Support** und anschließend **Änderungen speichern**.
## Erweiterten Support für EKS deaktivieren (AWS-CLI)
1. Überprüfen Sie, ob die AWS-CLI installiert ist und Sie angemeldet sind. [Erfahren Sie, wie Sie die AWS-CLI aktualisieren und installieren.](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
1. Bestimmen Sie den Namen Ihres EKS-Clusters.
1. Führen Sie den folgenden Befehl aus:
```
aws eks update-cluster-config \
--name \
--upgrade-policy supportType=STANDARD
```