Kubernetes-Versionen für Amazon EKS - Amazon EKS
Verfügbare Kubernetes-Versionen für Amazon EKSKubernetes 1.27Kubernetes 1.26Kubernetes 1.25Kubernetes 1.24Kubernetes 1.23Amazon-EKS-Kubernetes-Release-KalenderAmazon-EKS-Versionssupport und häufig gestellte Fragen

Kubernetes-Versionen für Amazon EKS

Das Kubernetes-Projekt integriert ständig neue Features, Design-Updates und Fehlerbehebungen. Die Community veröffentlicht neue Kubernetes-Nebenversionen, z. B. 1.27. Es werden durchschnittlich alle drei Monate neue Versionsupdates veröffentlicht. Jede Nebenversion wird nach ihrer ersten Veröffentlichung ungefähr zwölf Monate lang unterstützt.

Verfügbare Kubernetes-Versionen für Amazon EKS

Die folgenden Kubernetes-Versionen sind derzeit für neue Amazon-EKS-Cluster verfügbar:

  • 1.27

  • 1.26

  • 1.25

  • 1.24

  • 1.23

Wenn Ihre Anwendung keine bestimmte Version von Kubernetes benötigt, empfehlen wir, dass Sie die neueste verfügbare Kubernetes-Version verwenden, die von Amazon EKS für Ihre Cluster unterstützt wird. Wenn neue Kubernetes-Versionen in Amazon EKS verfügbar werden, empfehlen wir Ihnen, Ihre Cluster proaktiv auf die neueste verfügbare Version zu aktualisieren. Anweisungen zum Aktualisieren Ihres Clusters finden Sie unter Aktualisieren einer Amazon-EKS-Cluster-Kubernetes-Version. Weitere Informationen zu Kubernetes-Releases finden Sie unter Amazon-EKS-Kubernetes-Release-Kalender und Amazon-EKS-Versionssupport und häufig gestellte Fragen.

Anmerkung

Ab Einführung der 1.24-Version enthalten die offiziell veröffentlichten Amazon-EKS-AMIs containerd als einzige Laufzeit. Kubernetes-Versionen, die älter sind als 1.24, verwenden Docker als Standard-Laufzeit. Diese Versionen verfügen über eine Bootstrap-Flag-Option, mit der Sie Ihre Workloads auf jedem unterstützten Cluster mit containerd testen können. Weitere Informationen finden Sie unter Amazon EKS hat die Unterstützung für Dockershim eingestellt.

Kubernetes 1.27

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

Wichtig

  • Die Unterstützung für die Alpha-seccomp-Anmerkungen und die Anmerkungen seccomp.security.alpha.kubernetes.io/pod und container.seccomp.security.alpha.kubernetes.io wurde entfernt. Die Alpha-seccomp-Anmerkungen sind seit 1.19 veraltet. Aufgrund ihrer Entfernung in 1.27 werden seccomp-Felder für Pods nicht mehr automatisch mit seccomp-Anmerkungen gefüllt. Verwenden Sie stattdessen das Feld securityContext.seccompProfile für Pods oder Container, um seccomp-Profile zu konfigurieren. Um zu überprüfen, ob Sie die veralteten Alpha-seccomp-Anmerkungen im Cluster verwenden, führen Sie den folgenden Befehl aus:

    kubectl get pods --all-namespaces -o json | grep -E 'seccomp.security.alpha.kubernetes.io/pod|container.seccomp.security.alpha.kubernetes.io'

  • Das Befehlszeilenargument --container-runtime für das kubelet wurde entfernt. Seit 1.24 ist containerd die standardmäßige Container-Laufzeit für Amazon EKS. Daher ist die Angabe der Container-Laufzeit nicht mehr erforderlich. Ab 1.27 ignoriert Amazon EKS das Argument --container-runtime, das an Bootstrap-Skripte übergeben wird. Um Fehler beim Bootstrap-Prozess von Knoten zu vermeiden, dürfen Sie dieses Argument auf keinen Fall an --kubelet-extra-args übergeben. Sie müssen das Argument --container-runtime aus allen Workflows und Build-Skripten zur Knotenerstellung entfernen.

  • Durch das kubelet in Kubernetes 1.27 wurde der Standardwert für kubeAPIQPS auf 50 und kubeAPIBurst auf 100 erhöht. Dank dieser Verbesserungen kann das kubelet eine größere Menge an API-Abfragen verarbeiten, wodurch die Antwortzeiten und die Leistung verbessert werden. Wenn der Bedarf an Pods aufgrund von Skalierungsanforderungen steigt, stellen die überarbeiteten Standardwerte sicher, dass das kubelet die höhere Workload effizient bewältigen kann. Infolgedessen sind Pod-Starts schneller und Clustervorgänge effektiver.

  • Zur Verteilung von Richtlinien wie minDomain können Sie eine detailliertere Pod-Topologie verwenden. Mit diesem Parameter können Sie die Mindestanzahl von Domains angeben, auf die die Pods verteilt werden sollen. nodeAffinityPolicy und nodeTaintPolicy ermöglichen ein zusätzliches Maß an Granularität bei der Steuerung der Pod-Verteilung. Dies entspricht den Knotenaffinitäten, den Taints und dem Feld matchLabelKeys in den topologySpreadConstraints der Spezifikation Ihres Pod's. Das ermöglicht die Auswahl von Pods für Verteilungsberechnungen nach einem fortlaufenden Upgrade.

  • Kubernetes 1.27 hat einen neuen Richtlinienmechanismus für StatefulSets, der die Lebensdauer der PersistentVolumeClaims (PVCs) steuert, zur Beta-Version hochgestuft. Mit der neuen PVC-Aufbewahrungsrichtlinie können Sie angeben, ob die anhand der Spezifikationsvorlage StatefulSet generierten PVCs automatisch gelöscht oder beibehalten werden, wenn das StatefulSet gelöscht wird oder die Replikate im StatefulSet herunterskaliert werden.

  • Die goaway-chance-Option im Kubernetes API-Server verhindert, dass HTTP/2 Client-Verbindungen auf einer einzelnen API-Server-Instance hängen bleiben, indem eine Verbindung nach dem Zufallsprinzip geschlossen wird. Wenn die Verbindung geschlossen wird, versucht der Client erneut, eine Verbindung herzustellen, und landet wahrscheinlich aufgrund des Load Balancers auf einem anderen API-Server. Die Amazon-EKS-Version 1.27 hat das goaway-chance-Flag aktiviert. Wenn Ihr auf dem Amazon-EKS-Cluster ausgeführter Workload einen Client verwendet, der mit HTTP GOAWAY inkompatibel ist, empfehlen wir, dass Sie Ihren Client entsprechend aktualisieren, die Verbindung nach Beendigung der Verbindung erneut herzustellen, indem GOAWAY richtig verarbeitet wird.

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

Kubernetes 1.26

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

Wichtig

Kubernetes 1.26 unterstützt CRI v1alpha2 nicht mehr. Dies führt dazu, dass das kubelet den Knoten nicht mehr registriert, wenn die Container-Laufzeit CRI v1 nicht unterstützt. Das bedeutet auch, dass Kubernetes 1.26 Containerd-Minor-Version 1.5 und frühere Versionen nicht unterstützt. Wenn Sie Containerd verwenden, müssen Sie ein Upgrade auf die Containerd-Version 1.6.0 oder eine neuere Version durchführen, bevor Sie Knoten auf Kubernetes 1.26 aktualisieren. Sie müssen auch alle anderen Container-Laufzeiten aktualisieren, die nur die v1alpha2 unterstützen. Weitere Informationen erhalten Sie beim Anbieter der Container-Laufzeit. Standardmäßig enthalten Amazon Linux- und Bottlerocket-AMIs die Containerd-Version 1.6.6.

  • Bevor Sie ein Upgrade auf Kubernetes 1.26 durchführen, aktualisieren Sie Ihre Version Amazon VPC CNI plugin for Kubernetes auf Version 1.12 oder höher. Wenn Sie kein Upgrade auf Amazon VPC CNI plugin for  Kubernetes-Version 1.12 oder höher durchführen, wird Amazon VPC CNI plugin for  Kubernetes abstürzen. Weitere Informationen finden Sie unter Arbeiten mit dem Add-on Amazon VPC CNI plugin for Kubernetes für Kubernetes Amazon EKS.

  • Die goaway-chance-Option im Kubernetes API-Server verhindert, dass HTTP/2 Client-Verbindungen auf einer einzelnen API-Server-Instance hängen bleiben, indem eine Verbindung nach dem Zufallsprinzip geschlossen wird. Wenn die Verbindung geschlossen wird, versucht der Client erneut, eine Verbindung herzustellen, und landet wahrscheinlich aufgrund des Load Balancers auf einem anderen API-Server. Die Amazon-EKS-Version 1.26 hat das goaway-chance-Flag aktiviert. Wenn Ihr auf dem Amazon-EKS-Cluster ausgeführter Workload einen Client verwendet, der mit HTTP GOAWAY inkompatibel ist, empfehlen wir, dass Sie Ihren Client entsprechend aktualisieren, die Verbindung nach Beendigung der Verbindung erneut herzustellen, indem GOAWAY richtig verarbeitet wird.

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

Kubernetes 1.25

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

Wichtig

  • Die PodSecurityPolicy (PSP) wird in Kubernetes 1.25 entfernt. PSPs werden durch Pod Security Admission (PSA) und Pod Security Standards ersetzt (PSS). PSA ist ein integrierter Zulassungscontroller, der die Sicherheitskontrollen verwendet, die in der PSS beschrieben sind. PSA und PSS sind in Kubernetes 1.25 auf stabil abgestuft und in Amazon EKS standardmäßig aktiviert. Wenn Sie PSPs in Ihrem Cluster haben, stellen Sie sicher, dass Sie von der PSP zur integrierten Kubernetes PSS oder zu einer Policy-as-Code-Lösung migrieren, bevor Sie Ihren Cluster auf Version 1.25 aktualisieren. Wenn Sie nicht von PSP migrieren, kann es zu Unterbrechungen Ihrer Workloads kommen. Weitere Informationen hierzu finden Sie unter Entfernen der Pod-Sicherheitsrichtlinie (PSP) – Häufig gestellte Fragen.

  • Kubernetes-Version 1.25 enthält Änderungen, die das Verhalten eines bestehenden Features ändern, das als API-Priorität und Fairness (APF) bekannt ist. APF dient dazu, den API-Server in Zeiten erhöhten Anforderungsvolumens vor einer möglichen Überlastung zu schützen. Dies geschieht, indem die Anzahl der gleichzeitigen Anfragen, die zu einem bestimmten Zeitpunkt bearbeitet werden können, begrenzt wird. Es wird durch die Anwendung unterschiedlicher Prioritätsstufen und Grenzwerte für Anfragen erreicht, die von verschiedenen Workloads oder Benutzern stammen. Dieser Ansatz stellt sicher, dass kritische Anwendungen oder Anfragen mit hoher Priorität bevorzugt behandelt werden, während gleichzeitig verhindert wird, dass Anfragen mit niedrigerer Priorität den API-Server überlasten. Weitere Informationen finden Sie unter API-Priorität und Fairness in der Kubernetes-Dokumentation oder API-Priorität und Fairness im EKS-Leitfaden für bewährte Methoden.

    Diese Updates wurden eingeführt in PR #10352 und PR #118601. Bisher behandelte APF alle Arten von Anfragen einheitlich, wobei jede Anfrage eine einzige Einheit des Limits für gleichzeitige Anfragen verbrauchte. Die APF-Verhaltensänderung weist LIST-Anforderungen höhere Parallelitätseinheiten zu, da der API-Server durch diese Anforderungen außergewöhnlich stark belastet wird. Der API-Server schätzt die Anzahl der Objekte, die bei einer LIST-Anforderung zurückgegeben werden. Er weist eine Parallelitätseinheit zu, die proportional zur Anzahl der zurückgegebenen Objekte ist.

    Nach dem Upgrade auf die Amazon-EKS-Version 1.25 oder höher, kann dieses aktualisierte Verhalten zu Workloads mit massiven LIST-Anfragen (die zuvor problemlos funktionierten) führen, die auf eine Ratenbegrenzung zu stoßen. Dies würde durch einen HTTP-429-Antwortcode angezeigt werden. Um mögliche Workloadunterbrechungen aufgrund von LIST zu vermeiden, da die Anzahl der Anfragen begrenzt ist, empfehlen wir Ihnen dringend, Ihre Workloads umzustrukturieren, um die Anzahl dieser Anfragen zu reduzieren. Alternativ können Sie dieses Problem beheben, indem Sie die APF-Einstellungen anpassen, um mehr Kapazität für wichtige Anfragen zuzuweisen und gleichzeitig die Kapazität für nicht wichtige Anfragen zu reduzieren. Weitere Informationen zu diesen Risikominderungstechniken finden Sie unter Verhinderung verworfener Anfragen im EKS-Leitfaden für bewährte Methoden.

  • Amazon EKS 1.25 umfasst Verbesserungen der Cluster-Authentifizierung, die aktualisierte YAML-Bibliotheken enthalten. Wenn ein YAML-Wert in der aws-auth ConfigMap im kube-system-Namespace mit einem Makro beginnt, wobei das erste Zeichen eine geschweifte Klammer ist, sollten Sie Anführungszeichen (“ ”) vor und nach den geschweiften Klammern ({ }) hinzufügen. Dies ist erforderlich, um sicherzustellen, dass die aws-iam-authenticator-Version v0.6.3 präzise die aws-auth ConfigMap in Amazon EKS 1.25 analysiert.

  • Die Beta-API-Version (discovery.k8s.io/v1beta1) von EndpointSlice war veraltet in Kubernetes 1.21 und wird ab Kubernetes 1.25 nicht mehr bereitgestellt. Diese API wurde zu discovery.k8s.io/v1 aktualisiert. Weitere Informationen finden Sie unter EndpointSlice in der Kubernetes-Dokumentation. AWS Load Balancer Controller v2.4.6 und früher hat den v1beta1-Endpunkt verwendet, um mit EndpointSlices zu kommunizieren. Wenn Sie die EndpointSlices-Konfiguration für den AWS Load Balancer Controller verwenden, müssen Sie ein Upgrade auf AWS Load Balancer Controller v2.4.7 durchführen, bevor Sie Ihren Amazon-EKS-Cluster auf 1.25 aktualisieren. Wenn Sie ein Upgrade auf 1.25 durchführen, während Sie die EndpointSlices-Konfiguration für den AWS Load Balancer Controller verwenden, stürzt der Controller ab und es kommt zu Unterbrechungen Ihrer Workloads. Informationen zum Upgrade des Controllers finden Sie unter Installieren des AWS Load Balancer Controller-Add-ons.

  • SeccompDefault wird in Kubernetes 1.25 zur Betaversion hochgestuft. Wenn Sie die --seccomp-default-Markierung bei der Konfiguration von kubelet festlegen, verwendet die Container-Laufzeit ihr RuntimeDefault seccomp-Profil und nicht den Modus „uneingeschränkt“ (seccomp disabled). Die Standardprofile bieten eine Reihe starker Sicherheitsstandards und behalten gleichzeitig die Funktionalität des Workloads bei. Obwohl diese Markierung verfügbar ist, aktiviert Amazon EKS diese Markierung standardmäßig nicht, sodass das Verhalten von Amazon EKS praktisch unverändert bleibt. Wenn Sie möchten, können Sie damit beginnen, dies auf Ihren Knoten zu aktivieren. Weitere Informationen finden Sie im Tutorial Systemaufrufe mit Seccomp eines Containers beschränken in der Kubernetes-Dokumentation.

  • Der Support für das Container Runtime Interface (CRI) für Docker (auch bekannt als Dockershim) wurde ab Kubernetes 1.24 entfernt. Die einzige offizielle Container-Laufzeit in Amazon EKS AMIs für Kubernetes 1.24 und spätere Cluster ist containerd. Bevor Sie zu Amazon EKS 1.24 oder höher wechseln, müssen Sie alle Verweise auf Bootstrap-Skript-Flags entfernen, die nicht mehr unterstützt werden. Weitere Informationen finden Sie unter Amazon EKS hat die Unterstützung für Dockershim eingestellt.

  • Die Unterstützung für Platzhalterabfragen war in CoreDNS 1.8.7 veraltet und wurde in CoreDNS 1.9 entfernt. Dies wurde als Sicherheitsmaßnahme durchgeführt. Platzhalterabfragen funktionieren nicht mehr und geben NXDOMAIN anstelle einer IP-Adresse zurück.

  • Die goaway-chance-Option im Kubernetes API-Server verhindert, dass HTTP/2 Client-Verbindungen auf einer einzelnen API-Server-Instance hängen bleiben, indem eine Verbindung nach dem Zufallsprinzip geschlossen wird. Wenn die Verbindung geschlossen wird, versucht der Client erneut, eine Verbindung herzustellen, und landet wahrscheinlich aufgrund des Load Balancers auf einem anderen API-Server. Die Amazon-EKS-Version 1.25 hat das goaway-chance-Flag aktiviert. Wenn Ihr auf dem Amazon-EKS-Cluster ausgeführter Workload einen Client verwendet, der mit HTTP GOAWAY inkompatibel ist, empfehlen wir, dass Sie Ihren Client entsprechend aktualisieren, die Verbindung nach Beendigung der Verbindung erneut herzustellen, indem GOAWAY richtig verarbeitet wird.

Das vollständige Kubernetes 1.25-Änderungsprotokoll finden Sie unter https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.25.md#changelog-since-v1240.

Kubernetes 1.24

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

Wichtig

  • Ab Kubernetes 1.24 sind neue Beta-APIs standardmäßig nicht in Clustern aktiviert. Standardmäßig sind bestehende Beta-APIs und neue Versionen vorhandener Beta-APIs weiterhin aktiviert. Amazon EKS folgt demselben Verhalten wie Upstream Kubernetes 1.24. Die Feature-Gates, die neue Features sowohl für neue als auch für bestehende API-Operationen steuern, sind standardmäßig aktiviert. Dies entspricht dem Upstream Kubernetes. Weitere Informationen finden Sie unter KEP-3136: Beta-APIs sind standardmäßig deaktiviert auf GitHub.

  • Der Support für Container Runtime Interface (CRI) für Docker (auch bekannt als Dockershim) wurde von Kubernetes 1.24 entfernt. Offizielle Amazon-EKS-AMIs haben containerd als einzige Laufzeit. Bevor Sie zu Amazon EKS 1.24 oder höher wechseln, müssen Sie alle Verweise auf Bootstrap-Skript-Flags entfernen, die nicht mehr unterstützt werden. Sie müssen außerdem sicherstellen, dass die IP-Weiterleitung für Ihre Worker-Knoten aktiviert ist. Weitere Informationen finden Sie unter Amazon EKS hat die Unterstützung für Dockershim eingestellt.

  • Wenn Fluentd für Container Insights bereits konfiguriert ist, müssen Sie Fluentd zu Fluent Bit migrieren, bevor Sie Ihren Cluster aktualisieren. Die Fluentd-Parser sind so konfiguriert, dass sie nur Protokollnachrichten im JSON-Format analysieren. Im Gegensatz zu dockerd enthält die Container-Laufzeit containerd Protokollnachrichten, die sich nicht im JSON-Format befinden. Wenn Sie nicht zu Fluent Bit migrieren, erzeugen einige der konfigurierten Fluentd's-Parser eine große Anzahl von Fehlern im Container Fluentd. Weitere Informationen zur Migration finden Sie unter Einrichten von Fluent Bit als DaemonSet, um Protokolle an CloudWatch Logs zu senden.

  • In Kubernetes 1.23 und älter werden kubelet-Bereitstellungszertifikate mit nicht verifizierbaren IP- und DNS-Subject Alternative Names (SANs) automatisch mit nicht verifizierbaren SANs ausgestellt. Diese nicht verifizierbaren SANs werden im bereitgestellten Zertifikat weggelassen. In Clustern der Version 1.24 und höher werden keine kubelet-Bereitstellungszertifikate ausgestellt, wenn kein SAN verifiziert werden kann. Dadurch wird verhindert, dass die Befehle kubectl-exec und kubectl-logs funktionieren. Weitere Informationen finden Sie unter Überlegungen zur Zertifikatssignierung vor dem Upgrade Ihres Clusters auf Kubernetes 1.24.

  • Wenn Sie einen Amazon-EKS-1.23-Cluster aktualisieren, der Fluent Bit verwendet, müssen Sie sicherstellen, dass er unter k8s/1.3.12 oder neuer läuft. Sie können dies tun, indem Sie die neueste anwendbare Fluent Bit-YAML-Datei von GitHub erneut anwenden. Weitere Informationen finden Sie unter Einrichten von Fluent Bit im Benutzerhandbuch zu Amazon CloudWatch.

  • Sie können Topology Aware Hints verwenden, um anzugeben, dass Sie es vorziehen, den Datenverkehr in einer Zone zu halten, wenn Cluster-Worker-Knoten über mehrere Availability Zones bereitgestellt werden. Das Routing des Datenverkehrs innerhalb einer Zone kann dazu beitragen, die Kosten zu senken und die Netzwerkleistung zu verbessern. Standardmäßig sind Topology Aware Hints in Amazon EKS 1.24 aktiviert. Weitere Informationen finden Sie unter Topology Aware Hints in der Kubernetes-Dokumentation.

  • PodSecurityPolicy (PSP) soll in Kubernetes 1.25 entfernt werden. PSPs werden durch Pod Security Admission (PSA) ersetzt. PSA ist ein integrierter Zulassungscontroller, der die Sicherheitskontrollen verwendet, die in den Pod Security Standards beschrieben sind. PSA und PSS sind beide Beta-Features und in Amazon EKS standardmäßig aktiviert. Um das Entfernen von PSP in Version 1.25 anzugehen, empfehlen wir Ihnen, PSS in Amazon EKS zu implementieren. Weitere Informationen finden Sie unter Implementieren von Pod-Sicherheitsstandards in Amazon EKS im AWS-Blog.

  • Der client.authentication.k8s.io/v1alpha1 ExecCredential wurde in Kubernetes 1.24 entfernt. Die ExecCredential-API war allgemein in Kubernetes 1.22 verfügbar. Wenn Sie ein Plugin für Anmeldeinformationen verwenden, das auf der v1alpha1-API basiert, wenden Sie sich an den Vertreiber Ihres Plugins, um zu erfahren, wie Sie zur v1-API migrieren können.

  • Für Kubernetes 1.24 haben wir ein Feature zum Upstream-Cluster-Autoscaler-Projekt beigetragen, die das Skalieren von Amazon-EKS-verwalteten Knotengruppen auf und von null Knoten vereinfacht. Damit der Cluster-Autoscaler die Ressourcen, Labels und Taints einer verwalteten Knotengruppe, die auf null Knoten skaliert wurde, versteht, mussten Sie zuvor die zugrunde liegende Amazon-EC2-Auto-Scaling-Gruppe mit den Details der Knoten markieren, für die sie verantwortlich war. Wenn es keine ausgeführten Knoten in der verwalteten Knotengruppe gibt, ruft der Cluster-Autoscaler die DescribeNodegroup-API-Operation von Amazon EKS auf. Diese API-Operation stellt die Informationen bereit, die der Cluster-Autoscaler zu den Ressourcen, Labels und Taints der verwalteten Knotengruppe benötigt. Für dieses Feature müssen Sie die eks:DescribeNodegroup-Berechtigung zur IAM-Richtlinie des Cluster-Autoscaler-Servicekontos hinzufügen. Wenn der Wert eines Cluster-Autoscaler-Tags in der Auto-Scaling-Gruppe, die eine von Amazon EKS verwaltete Knotengruppe unterstützt, mit der Knotengruppe selbst in Konflikt steht, bevorzugt der Cluster-Autoscaler den Wert des Auto-Scaling-Gruppen-Tags. Auf diese Weise können Sie Werte nach Bedarf überschreiben. Weitere Informationen finden Sie unter Auto Scaling.

  • Wenn Sie beabsichtigen, Inferentia- oder Trainium-Instance-Typen mit Amazon EKS 1.24 zu verwenden, müssen Sie auf die AWS Neuron-Geräte-Plugin-Version 1.9.3.0 oder höher aktualisieren. Weitere Informationen finden Sie unter Neuron-K8-Version [1.9.3.0] in der AWS Neuron-Dokumentation.

  • Containerd hat IPv6 standardmäßig für Pods aktiviert. Es wendet die Knoten-Kernel-Einstellungen auf Pod-Netzwerk-Namespaces an. Aus diesem Grund binden Container in einem Pod sowohl an IPv4 (127.0.0.1) als auch an IPv6 (::1)-Loopback-Adressen an. IPv6 ist das Standardprotokoll für die Kommunikation. Bevor Sie Ihr Cluster auf Version 1.24 aktualisieren, empfehlen wir Ihnen, Ihre Multi-Container-Pods zu testen. Ändern Sie Apps so, dass sie an alle IP-Adressen auf Loopback-Schnittstellen gebunden werden können. Die meisten Bibliotheken ermöglichen das IPv6-Binden, das mit IPv4 abwärtskompatibel ist. Wenn es nicht möglich ist, Ihren Anwendungscode zu ändern, haben Sie zwei Möglichkeiten:

    • Führen Sie einen init-Container aus und setzen Sie disable ipv6 auf true (sysctl -w net.ipv6.conf.all.disable ipv6=1).

    • Konfigurieren Sie einen Webhook mit mutierendem Zugang, um einen init-Container neben Ihren Anwendungs-Pods einzufügen.

    Wenn Sie IPv6 für alle Pods auf allen Knoten blockieren müssen, müssen Sie möglicherweise IPv6 auf Ihren Instances deaktivieren.

  • Die goaway-chance-Option im Kubernetes API-Server verhindert, dass HTTP/2 Client-Verbindungen auf einer einzelnen API-Server-Instance hängen bleiben, indem eine Verbindung nach dem Zufallsprinzip geschlossen wird. Wenn die Verbindung geschlossen wird, versucht der Client erneut, eine Verbindung herzustellen, und landet wahrscheinlich aufgrund des Load Balancers auf einem anderen API-Server. Die Amazon-EKS-Version 1.24 hat das goaway-chance-Flag aktiviert. Wenn Ihr auf dem Amazon-EKS-Cluster ausgeführter Workload einen Client verwendet, der mit HTTP GOAWAY inkompatibel ist, empfehlen wir, dass Sie Ihren Client entsprechend aktualisieren, die Verbindung nach Beendigung der Verbindung erneut herzustellen, indem GOAWAY richtig verarbeitet wird.

Das vollständige Kubernetes 1.24-Änderungsprotokoll finden Sie unter https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#changelog-since-v1230.

Kubernetes 1.23

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

Wichtig

Das Volume-Migrationsfeature von Kubernetes In-Tree zu Container Storage Interface (CSI) ist aktiviert. Dieses Feature ermöglicht es, vorhandene Kubernetes-In-Tree-Speicher-Plugins für Amazon EBS durch einen entsprechenden CSI-Treiber von Amazon EBS zu ersetzen. Weitere Informationen finden Sie unter Kubernetes Feature 1.17: Kubernetes In-Tree to CSI Volume Migration Moves to Beta (Feature von 1.17: Migration von In-Tree- zu CSI-Volumes) im Kubernetes-Blog.

Das Feature übersetzt In-Tree-APIs in entsprechende CSI-APIs und delegiert Vorgänge an einen Ersatz-CSI-Treiber. Wenn Sie vorhandene StorageClass-, PersistentVolume- und PersistentVolumeClaim-Objekte verwenden, die zu diesen Workloads gehören, werden Sie bei Einsatz dieses Features kaum eine Veränderung feststellen. Das Feature ermöglicht Kubernetes die Delegierung aller Speicherverwaltungsvorgänge vom In-Tree-Plugin an den CSI-Treiber. Wenn Sie in einem vorhandenen Cluster Amazon-EBS-Volumes verwenden, installieren Sie den CSI-Treiber von Amazon EBS im Cluster, bevor Sie den Cluster auf die Version 1.23 aktualisieren. Wenn Sie den Treiber nicht vor der Aktualisierung eines vorhandenen Clusters installieren, kann es zu Unterbrechungen Ihrer Workloads kommen. Wenn Sie Workloads bereitstellen möchten, die Amazon EBS-Volumes in einem neuen 1.23-Cluster verwenden, installieren Sie den CSI-Treiber von Amazon EBS in Ihrem Cluster, bevor Sie die Workloads in Ihrem Cluster bereitstellen. Anweisungen zum Installieren des CSI-Treibers von Amazon EBS in Ihrem Cluster finden Sie unter Amazon-EBS-CSI-Treiber. Häufig gestellte Fragen zum Migrationsfeature finden Sie unter Häufig gestellte Fragen zur Migration des CSI von Amazon EBS.

  • Kubernetes hat die Unterstützung von dockershim in Version 1.20 eingestellt und dockershim in Version 1.24 entfernt. Weitere Informationen finden Sie unter Kubernetes verabschiedet sich von Dockershim: Verpflichtungen und nächste Schritte im Kubernetes-Blog. Amazon EKS wird die Unterstützung für dockershim ab der Amazon-EKS-Version 1.24 einstellen. Ab der Amazon-EKS-Version 1.24 werden offizielle AMIs von Amazon EKS containerd als einzige Laufzeit aufweisen.

    Auch wenn Amazon-EKS-Version 1.23 weiterhin dockershim unterstützt, empfehlen wir Ihnen, jetzt mit dem Testen Ihrer Anwendungen zu beginnen, um alle Docker-Abhängigkeiten zu ermitteln und zu entfernen. So sind Sie bereit, Ihren Cluster auf die Version 1.24 zu aktualisieren. Weitere Informationen über das Entfernen von dockershim finden Sie unter Amazon EKS hat die Unterstützung für Dockershim eingestellt.

  • Kubernetes hat IPv4/IPv6-Dual-Stack-Networking für Pods, Services und Knoten auf allgemeine Verfügbarkeit hochgestuft. Allerdings unterstützen Amazon EKS und das Amazon VPC CNI plugin for Kubernetes kein Dual-Stack-Networking. Ihre Cluster können IPv4- oder IPv6-Adressen zu Pods und Services zuweisen, aber nicht beide Adresstypen zuweisen.

  • Kubernetes hat das PSA-Feature (Pod Security Admission) auf Beta hochgestuft. Das Feature ist standardmäßig aktiviert. Weitere Informationen finden Sie unter Pod Security Admission in der Kubernetes-Dokumentation. PSA ersetzt den Pod Security Policy (PSP)-Zulassungscontroller. Der PSP-Zugangscontroller wird nicht unterstützt und wird laut Plan in der Kubernetes-Version 1.25 entfernt.

    Der PSP-Zulassungscontroller setzt Pod-Sicherheitsstandards für Pods in einem Namespace basierend auf bestimmten Namespace-Labels durch, die den Grad der Durchsetzung festlegen. Weitere Informationen hierzu finden Sie unter Pod Security Standards (PSS) und Pod Security Admission (PSA) im Leitfaden zu bewährten Methoden für Amazon EKS.

  • Das mit Clustern bereitgestellte kube-proxy-Image ist jetzt das von Amazon EKS Distro (EKS-D) verwaltete minimale Basis-Image. Das Image enthält nur minimale Pakete und verfügt über keine Shells oder Paketmanager.

  • Kubernetes hat flüchtige Container auf Beta hochgestuft. Flüchtige Container sind temporäre Container, die im gleichen Namespace wie ein vorhandener Pod ausgeführt werden. Mit ihrer Hilfe können Sie den Status von Pods und Containern zur Fehlerbehebung und zum Debuggen beobachten. Dies ist insbesondere für die interaktive Fehlerbehebung hilfreich, wenn kubectl exec unzureichend ist, weil entweder ein Container abgestürzt ist oder ein Container-Image keine Debugging-Hilfsprogramme enthält. Ein Beispiel für einen Container, der ein Debugging-Dienstprogramm enthält, sind „distroless“ Images. Weitere Informationen finden Sie unter Debugging with an ephemeral debug container (Debuggen mit einem flüchtigen Debug-Container) in der Kubernetes-Dokumentation.

  • Kubernetes hat die stabile autoscaling/v2-API von HorizontalPodAutoscaler auf allgemeine Verfügbarkeit hochgestuft. Die HorizontalPodAutoscaler autoscaling/v2beta2 API ist veraltet. Es wird in 1.26 nicht verfügbar sein.

  • Die goaway-chance-Option im Kubernetes API-Server verhindert, dass HTTP/2 Client-Verbindungen auf einer einzelnen API-Server-Instance hängen bleiben, indem eine Verbindung nach dem Zufallsprinzip geschlossen wird. Wenn die Verbindung geschlossen wird, versucht der Client erneut, eine Verbindung herzustellen, und landet wahrscheinlich aufgrund des Load Balancers auf einem anderen API-Server. Die Amazon-EKS-Version 1.23 hat das goaway-chance-Flag aktiviert. Wenn Ihr auf dem Amazon-EKS-Cluster ausgeführter Workload einen Client verwendet, der mit HTTP GOAWAY inkompatibel ist, empfehlen wir, dass Sie Ihren Client entsprechend aktualisieren, die Verbindung nach Beendigung der Verbindung erneut herzustellen, indem GOAWAY richtig verarbeitet wird.

Das vollständige Kubernetes 1.23-Änderungsprotokoll finden Sie unter https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.23.md#changelog-since-v1220.

Amazon-EKS-Kubernetes-Release-Kalender

Anmerkung

Daten mit nur einem Monat und einem Jahr sind ungefähre Angaben und werden mit einem genauen Datum aktualisiert, wenn es bekannt ist.

Kubernetes-Version Upstream-Release Amazon-EKS-Version Ende der Unterstützung für Amazon EKS
1.28 15. August 2023 September 2023 November 2024
1.27 11. April 2023 24. Mai 2023 Juli 2024
1.26 9. Dezember 2022 11. April 2023 Juni 2024
1.25 23. August 2022 22. Februar 2023 Mai 2024
1.24 3. Mai 2022 15. November 2022 31. Januar 2024
1.23 7. Dezember 2021 11. August 2022 11. Oktober 2023

Amazon-EKS-Versionssupport und häufig gestellte Fragen

Im Einklang mit dem Kubernetes-Community-Support für Kubernetes-Versionen verpflichtet sich Amazon EKS, mindestens vier produktionsbereite Versionen von Kubernetes gleichzeitig zu unterstützen. Wir kündigen das Datum für die Beendigung der Unterstützung einer bestimmten Kubernetes-Nebenversion mindestens 60 Tage vor dem Support-Beendigungsdatum an. Aufgrund des Amazon-EKS-Qualifizierungs- und Veröffentlichungsprozesses für neue Kubernetes-Versionen liegt das Supportende einer Kubernetes-Version auf Amazon EKS am oder nach dem Datum, an dem das Kubernetes-Projekt die Unterstützung des Versions-Upstreams eingestellt hat.

Häufig gestellte Fragen

F: Wie lange wird eine Kubernetes-Version von Amazon EKS unterstützt?

A: Eine Kubernetes-Version wird ab der ersten Verfügbarkeit auf Amazon EKS 14 Monate lang unterstützt. Dies gilt auch dann, wenn Kubernetes auf Upstream-Plattformen eine auf Amazon EKS verfügbare Version nicht mehr unterstützt. Wir rückportieren Sicherheitspatches, die für die Kubernetes-Versionen gelten, die auf Amazon EKS unterstützt werden.

F: Werde ich benachrichtigt, wenn der Support für eine Kubernetes-Version auf Amazon EKS endet?

A: Ja. Wenn Cluster in Ihrem Konto die Version ausführen, die sich dem Ende des Supports nähert, sendet Amazon EKS ungefähr 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.

F: Was passiert am Datum des Support-Laufzeitendes?

A: Am Datum des Support-Laufzeitendes 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 Die Kubernetes-Version für Ihren-Amazon EKS-Cluster aktualisieren .

F: Wann genau wird meine Steuerebene nach dem Datum des Support-Laufzeitendes automatisch aktualisiert?

A: Amazon EKS kann keine spezifischen Zeitrahmen bereitstellen. Automatische Updates können jederzeit nach dem Datum des Support-Laufzeitendes erfolgen. Sie erhalten vor dem Update 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 Aktualisieren einer Amazon-EKS-Cluster-Kubernetes-Version.

F: Kann ich meine Steuerebene auf unbestimmte Zeit auf einer Kubernetes-Version belassen?

A: Nein, Cloud-Sicherheit bei AWS hat höchste Priorität. Nach einem bestimmten Punkt (normalerweise einem Jahr) hört die Kubernetes-Community auf, CVE-Patches (Common Vulnerabilities and Exposures, häufige Schwachstellen und Risiken) zu veröffentlichen, und rät von der CVE-Einreichung für nicht unterstützte Versionen ab. Das bedeutet, dass Schwachstellen, die für eine ältere Version von Kubernetes spezifisch sind, möglicherweise nicht einmal 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 Supports erreicht hat.

F: Welche Kubernetes-Features werden von Amazon EKS unterstützt?

A: Amazon EKS unterstützt alle generell verfügbaren Features der Kubernetes-API. Standardmäßig aktivierte Beta-Features werden ebenfalls unterstützt. Alpha-Features werden nicht unterstützt.

F: Werden von Amazon EKS verwaltete Knotengruppen automatisch zusammen mit der Version der Cluster-Steuerebene aktualisiert?

A: 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. Nehmen Sie an, dass Amazon EKS Ihre Steuerebene automatisch aktualisiert. Die Kubernetes-Version in Ihrer verwalteten Knotengruppe ist aber möglicherweise mehr als eine Version älter als Ihre Steuerebene. Nehmen Sie dann an, dass eine verwaltete Knotengruppe Instances enthält, auf denen eine Version von Kubernetes ausgeführt wird, die mehr als eine Version älter als die der Steuerebene ist. Die Knotengruppe weist im Abschnitt Node groups (Knotengruppen der Registerkarte Compute (Datenverarbeitung) Ihres Clusters in der Konsole ein Zustandsproblem auf. Wenn für eine Knotengruppe schließlich ein verfügbares Versionsupdate verfügbar ist, wird neben der Knotengruppe in der Konsole Update now (Jetzt aktualisieren) angezeigt. Weitere Informationen finden Sie unter Aktualisieren einer verwalteten Knotengruppe. Wir empfehlen, dieselbe Kubernetes-Version auf Ihrer Steuerebene und Ihren Knoten beizubehalten.

F: Werden selbstverwaltete Knotengruppen automatisch zusammen mit der Version der Cluster-Steuerebene aktualisiert?

A: 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 Aktualisierungen des selbstverwalteten Worker-Knotens.

Das Kubernetes-Projekt testet die Kompatibilität zwischen der Steuerebene und den Knoten für bis zu zwei Nebenversionen. 1.25-Knoten funktionieren beispielsweise weiterhin, wenn sie von einer 1.27-Steuerebene orchestriert werden. Es wird jedoch nicht empfohlen, einen Cluster mit Knoten auszuführen, die sich dauerhaft zwei Nebenversionen hinter der Steuerebene befinden. Weitere Informationen finden Sie unter Kubernetes-Version und Richtlinie zur Unterstützung der Versionsverzerrung in der Kubernetes-Dokumentation. Wir empfehlen, dieselbe Kubernetes-Version auf Ihrer Steuerebene und Ihren Knoten beizubehalten.

F: Werden Pods, die auf Fargate ausgeführt werden, automatisch mit einem automatischen Upgrade der Cluster-Steuerebenenversion aktualisiert?

A: Nein. Wir empfehlen dringend, Fargate-Pods als Teil eines Replikationscontrollers wie einer Kubernetes-Bereitstellung auszuführen. Dann führen Sie einen rollenden Neustart aller Fargate-Pods durch. Die neue Version des Fargate-Pod wird mit einer kubelet-Version bereitgestellt, die dieselbe Version wie Ihre aktualisierte Version der Cluster-Steuerebene ist. Weitere Informationen finden Sie unter Deployments (Bereitstellungen) in der Kubernetes-Dokumentation.

Wichtig

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.