Kubernetes-Versionen für Amazon EKS - Amazon EKS

Kubernetes-Versionen für Amazon EKS

Das Kubernetes-Projekt integriert ständig neue Funktionen, Design-Updates und Fehlerbehebungen. Die Community veröffentlicht neue Kubernetes-Nebenversionen, z. B. 1.22. 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.22.10

  • 1.21.13

  • 1.20.15

  • 1.19.16

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

Beginnend mit der Veröffentlichung der Version 1.24 von Kubernetes enthalten offiziell von Amazon EKS veröffentlichte AMIs containerd als einzige Laufzeit. Die Kubernetes-Versionen 1.18-1.23 verwendet Docker als Standard-Laufzeit. Diese Versionen verfügen jedoch ü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 beendet den Support für Dockershim.

Kubernetes 1.22

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

  • Kubernetes 1.22 entfernt eine Reihe von APIs, die nicht mehr verfügbar sind. Möglicherweise müssen Sie Änderungen an Ihrer Anwendung vornehmen, bevor Sie ein Upgrade auf die Amazon-EKS-Version 1.22 durchführen. Befolgen Sie die Kubernetes-Version 1.22-Voraussetzungen genau, bevor Sie Ihr Cluster aktualisieren.

  • Wichtig

    BoundServiceAccountTokenVolume hat jetzt einen stabilen Status und ist standardmäßig in der Kubernetes-Version 1.22 aktiviert. Die Funktion verbessert die Sicherheit von Servicekonto-Tokens. Sie ermöglicht es auf Kubernetes ausgeführten Workloads, JSON-Web-Tokens, die an Zielgruppen, Zeit und Schlüssel gebunden sind, anzufordern. Die Ablaufzeit für Servicekonto-Tokens beträgt jetzt eine Stunde. In früheren Kubernetes-Versionen gab es keine Ablaufzeit. Clients, die diese Tokens verwenden, müssen die Tokens nun also innerhalb einer Stunde aktualisieren. Die folgenden Kubernetes-Client-SKDs aktualisieren Tokens automatisch im erforderlichen Zeitrahmen:

    • Go-Version 0.15.7 und höher

    • Python-Version 12.0.0 und höher

    • Java-Version 9.0.0 und höher

    • JavaScript-Version 0.10.3 und höher

    • Ruby master-Branch

    • Haskell-Version 0.3.0.0

    • C#-Version 7.0.5 und höher

    Wenn Ihr Workload eine ältere Client-Version verwendet, ist eine Aktualisierung erforderlich. Um Clients reibungslos zu neueren zeitlich begrenzten Servicekonto-Tokens zu migrieren, ermöglicht die Kubernetes-Version 1.22 eine verlängerte Ablaufzeit für Servicekonto-Tokens, die die standardmäßige Stunde übersteigt. Für Amazon-EKS-Cluster gilt eine verlängerte Ablaufzeit von 90 Tagen. Der Kubernetes-API-Server Ihres Amazon-EKS-Clusters lehnt Anfragen mit Tokens ab, die älter als 90 Tage sind. Wir empfehlen Ihnen, Ihre Anwendungen und ihre Abhängigkeiten zu überprüfen, um sicherzustellen, dass die Kubernetes-Client-SDKs mit den oben aufgeführten Versionen identisch oder höher sind. Anweisungen zur Identifizierung von pods, die veraltete Tokens verwenden, finden Sie unter Kubernetes-Servicekonten.

  • Die Ingress-API-Versionen extensions/v1beta1 und networking.k8s.io/v1beta1 wurden in Kubernetes 1.22 entfernt. Wenn Sie den AWS Load Balancer Controller verwenden, müssen Sie mindestens ein Upgrade auf die Version 2.4.1 vornehmen, bevor Sie Ihre Amazon-EKS-Cluster auf Version 1.22 upgraden. Zudem müssen Sie die Ingress-Manifeste ändern, um die apiVersion networking.k8s.io/v1 zu verwenden. Diese ist seit Kubernetes-Version 1.19 verfügbar. Weitere Informationen zu Änderungen zwischen Ingress v1beta1 und v1 finden Sie in der Kubernetes-Dokumentation. Das Beispiel-Manifest für den AWS Load Balancer Controller Controller verwendet die v1-Spezifikation.

  • Die Legacy-Windows-Support-Controller in Amazon EKS verwenden die admissionregistration.k8s.io/v1beta1-API, die in Kubernetes 1.22 entfernt wurden. Wenn Sie Windows-Workloads ausführen, müssen Sie den Windows-Support entfernen und den Windows-Support aktivieren, bevor Sie zur Amazon-EKS-Version 1.22 upgraden.

  • Die CertificateSigningRequest (CSR)-API-Version certificates.k8s.io/v1beta1 wurde in der Kubernetes-Version 1.22 entfernt. Sie müssen Manifeste und API-Clients migrieren, um die certificates.k8s.io/v1-CSR-API zu verwenden. Diese API ist seit Version 1.19 verfügbar. Anweisungen zur Verwendung von CSR in Amazon EKS finden Sie unter Zertifikatsignierung.

  • Die CustomResourceDefinition-API-Version apiextensions.k8s.io/v1beta1 wurde in Kubernetes 1.22 entfernt. Stellen Sie sicher, dass alle benutzerdefinierten Ressourcendefinitionen in Ihrem Cluster aktualisiert auf v1 aktualisiert wurden. Für benutzerdefinierte Ressourcendefinitionen der API-Version v1 muss eine Open-API-v3-Schemavalidierung definiert sein. Weitere Informationen finden Sie in der Kubernetes-Dokumentation.

  • Wenn Sie App Mesh verwenden, müssen Sie ein Upgrade auf den App-Mesh-Controller v1.4.3 oder höher durchführen, bevor Sie zu Amazon-EKS-Version 1.22 upgraden. Ältere Versionen des App-Mesh-Controllers verwenden die API-Version v1beta1 CustomResourceDefinition und sind nicht mit der Kubernetes-Version 1.22 oder höher kompatibel.

  • In der Amazon-EKS-Version 1.22 ist die Funktion EndpointSliceTerminatingCondition standardmäßig aktiviert. Diese umfasst pods im Beenden-Status innerhalb von EndpointSlices. Wenn Sie enableEndpointSlices im AWS Load Balancer Controller auf True festlegen (standardmäßig deaktiviert), müssen Sie mindestens auf die AWS Load Balancer Controller-Version 2.4.1+ upgraden, bevor Sie ein Upgrade auf die Amazon-EKS-Version 1.22 durchführen.

  • Ab Amazon-EKS-Version 1.22 ist kube-proxy standardmäßig konfiguriert, um Prometheus-Metriken außerhalb des pod verfügbar zu machen. Diese Verhaltensänderung bezieht sich auf die Anfrage, die im Container-Roadmap-Problem Nr. 657 gestellt wurde.

  • Die erste Veröffentlichung der Amazon-EKS-Version 1.22 verwendet die etcd-Version 3.4 als Backend und ist nicht von der möglichen Datenbeschädigung in der etcd-Version 3.5 betroffen.

  • Ab Amazon-EKS-Version 1.22 entkoppelt Amazon EKS die cloudspezifische Steuerlogik von AWS vom zentralen Code der Steuerebene zum externen Cloud Controller Manager von AWS Kubernetes. Dies entspricht der Upstream-Empfehlung von Kubernetes. Durch Entkopplung der Interoperabilitätslogik zwischen Kubernetes und der zugrunde liegenden Cloud-Infrastruktur können Cloud-Anbieter mit der cloud-controller-manager-Komponente Funktionen in einem anderen Tempo als das des Kubernetes-Hauptprojekts veröffentlichen. Diese Änderung ist transparent und erfordert keine Maßnahmen. Allerdings wird bei Aktivierung jetzt ein neuer Protokollstream mit Namen cloud-controller-manager unter dem ControllerManager-Protokolltyp angezeigt. Weitere Informationen finden Sie unter Amazon-EKS-Steuerebenen-Protokollierung.

  • Ab Amazon EKS 1.22 ändert Amazon EKS den Standard-Endpunkt für den AWS Security Token Service, der von IAM-Rollen Servicekonten (IRSA) verwendet wird, vom globalen zum regionalen Endpunkt. Das reduziert die Latenz und verbessert die Zuverlässigkeit. Unter Zuordnen einer IAM-Rolle zu einem Servicekonto erfahren Sie, wie Sie optional festlegen können, dass IRSA den globalen Endpunkt verwendet.

Die folgenden Kubernetes-Funktionen werden jetzt in Kubernetes-1.22-Amazon-EKS-Clustern unterstützt:

  • Server-side Apply ist jetzt allgemein verfügbar – Server-side Apply hilft Nutzern und Controllern, ihre Ressourcen über deklarative Konfigurationen zu verwalten. Es unterstützt sie dabei, Objekte deklarativ zu erstellen oder zu modifizieren, indem ihre gesamte angegebene Absicht gesendet wird. Nach einigen Releases in der Beta-Version ist Server-side Apply jetzt allgemein verfügbar.

  • Warnmechanismus für die Nutzung veralteter APIs – Die Verwendung veralteter APIs erzeugt Warnmeldungen für API-Kunden und Metriken für Cluster-Administratoren.

Das vollständige Änderungsprotokoll für Kubernetes 1.22 finden Sie unter https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md#changelog-since-v1210.

Kubernetes 1.21

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

  • Wichtig

    BoundServiceAccountTokenVolume ist jetzt in der Beta-Version und standardmäßig in der Kubernetes-Version 1.21 aktiviert. Die Funktion verbessert die Sicherheit von Servicekonto-Tokens, indem sie es auf Kubernetes ausgeführten Workloads ermöglicht, JSON-Web-Tokens, die an Zielgruppen, Zeit und Schlüssel gebunden sind, anzufordern. Die Ablaufzeit für Servicekonto-Tokens beträgt jetzt eine Stunde. In früheren Kubernetes-Versionen gab es keine Ablaufzeit. Clients, die diese Tokens verwenden, müssen die Tokens nun also innerhalb einer Stunde aktualisieren. Die folgenden Kubernetes-Client-SKDs aktualisieren Tokens automatisch im erforderlichen Zeitrahmen:

    • Go-Version 0.15.7 und höher

    • Python-Version 12.0.0 und höher

    • Java-Version 9.0.0 und höher

    • JavaScript-Version 0.10.3 und höher

    • Ruby master-Branch

    • Haskell-Version 0.3.0.0

    • C#-Version 7.0.5 und höher

    Wenn Ihr Workload eine ältere Client-Version verwendet, ist eine Aktualisierung erforderlich. Um Clients reibungslos zu neueren zeitlich begrenzten Servicekonto-Tokens zu migrieren, ermöglicht die Kubernetes-Version 1.21 eine verlängerte Ablaufzeit für Servicekonto-Tokens, die die standardmäßige Stunde übersteigt. Für Amazon-EKS-Cluster gilt eine verlängerte Ablaufzeit von 90 Tagen. Der Kubernetes-API-Server Ihres Amazon-EKS-Clusters lehnt Anfragen mit Tokens ab, die älter als 90 Tage sind. Wir empfehlen Ihnen, Ihre Anwendungen und ihre Abhängigkeiten zu überprüfen, um sicherzustellen, dass die Kubernetes-Client-SDKs mit den oben aufgeführten Versionen identisch oder höher sind. Anweisungen zur Identifizierung von pods, die veraltete Tokens verwenden, finden Sie unter Kubernetes-Servicekonten.

  • Die Dual-Stack-Networking-Unterstützung (IPv4- und IPv6-Adressen) auf pods, Services und Knoten hat den Beta-Status erreicht. Allerdings unterstützen Amazon EKS und das Amazon VPC CNI plugin for Kubernetes derzeit kein Dual-Stack-Networking.

  • Das Amazon EKS Optimized Amazon Linux 2 AMI enthält jetzt ein Bootstrap-Flag, um die containerd-Laufzeit als Docker-Alternative zu aktivieren. Dieses Flag ermöglicht die Vorbereitung auf die Entfernung von Docker als unterstützte Laufzeit im nächsten Kubernetes-Release. Weitere Informationen finden Sie unter Aktivieren der containerd-Laufzeit-Bootstrap-Flag. Dies kann über die Container-Roadmap auf Github verfolgt werden.

  • Unterstützung für verwaltete Knotengruppen für die Prioritätserweiterung von Cluster Autoscaler.

    Neu erstellte verwaltete Knotengruppen in Amazon-EKS-Version-1.21-Clustern verwenden das folgende Format für den zugrunde liegenden Auto-Scaling-Gruppennamen:

    eks-<managed-node-group-name>-<uuid>

    Dies ermöglicht die Verwendung der Prioritätserweiterungs-Funktion von Cluster Autoscaler, um Knotengruppen basierend auf benutzerdefinierten Prioritäten zu skalieren. Ein häufiger Anwendungsfall besteht darin, die Skalierung von Spot-Knotengruppen gegenüber On-demand-Gruppen zu bevorzugen. Diese Verhaltensänderung behebt das Container-Roadmap-Problem Nr. 1304.

Die folgenden Kubernetes-Funktionen werden jetzt in Amazon-EKS-1.21-Clustern unterstützt:

  • CronJobs (ehemals ScheduledJobs) haben nun einen stabilen Status. Mit dieser Änderung führen Benutzer regelmäßig geplante Aktionen wie Backups und Berichterstellung durch.

  • Unveränderliche Secrets und ConfigMaps sind jetzt stabil. Diesen Objekten wurde ein neues, unveränderliches Feld hinzugefügt, um Änderungen abzulehnen. Diese Ablehnung schützt den Cluster vor Updates, die die Anwendungen unbeabsichtigt beschädigen können. Da diese Ressourcen unveränderlich sind, überwacht kubelet keine Änderungen und fragt sie nicht ab. Dies reduziert die kube-apiserver-Last und verbessert die Skalierbarkeit und Leistung.

  • Korrektes Herunterfahren von Knoten hat jetzt den Beta-Status erreicht. Mit diesem Update erkennt das kubelet das Herunterfahren des Knotens und kann die pods dieses Knotens ordnungsgemäß beenden. Vor diesem Update folgten beim Herunterfahren eines Knotens seine pods nicht dem erwarteten Beendigungslebenszyklus. Dies führte zu Workload-Problemen. Jetzt kann das kubelet über systemd ein bevorstehendes Herunterfahren des Systems erkennen und laufende pods informieren, damit sie korrekt beendet werden.

  • Pods mit mehreren Containern können jetzt die kubectl.kubernetes.io/default-container-Anmerkung verwenden, um einen Container für kubectl-Befehle vorausgewählt zu haben.

  • PodSecurityPolicy wird eingestellt. PodSecurityPolicy wird gemäß den Kubernetes-Richtlinien für veraltete Versionen noch für mehrere weitere Releases funktionsfähig sein. Weitere Informationen finden Sie unter PodSecurityPolicy veraltet: Vergangenheit, Gegenwart und Zukunft und im AWS-Blog.

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

Kubernetes 1.20

Weitere Informationen zu Kubernetes 1.20 finden Sie in der offiziellen Versionsankündigung.

Die folgenden Kubernetes-Funktionen werden jetzt in Kubernetes-1.20-Amazon-EKS-Clustern unterstützt:

  • API-Priorität and Fairness hat den Beta-Status erreicht und ist standardmäßig aktiviert. Dadurch kann kube-apiserver eingehende Anfragen nach Prioritätsstufen kategorisieren.

  • RuntimeClass hat den stabilen Status erreicht. Die RuntimeClass-Ressource bietet einen Mechanismus zum Unterstützen mehrerer Laufzeiten in einem Cluster und übermittelt Informationen über diese Container-Laufzeit an die Steuerebene.

  • Prozess-ID-Limits ist jetzt allgemein verfügbar.

  • kubectl debug hat den Beta-Status erreicht. kubectl debug bietet Unterstützung für gängige Debugging-Workflows direkt von kubectl aus.

  • Die Docker-Container-Laufzeitumgebung wurde eingestellt. Die Kubernetes-Community hat hierzu einen ausführlichen Blog-Beitrag mit einer eigenen Seite für häufig gestellte Fragen verfasst. Von Docker erstellte Images können weiterhin verwendet werden und funktionieren wie immer. Sie können die Warnmeldung zur Veralterung von Dockershim, die in den kubelet-Startprotokollen gedruckt wird, getrost ignorieren. Amazon EKS wird zu gegebener Zeit zu containerd als Laufzeit für das Amazon-EKS-optimierte Amazon Linux 2 AMI wechseln. Weitere Details finden Sie unter Problem mit der Container-Roadmap.

  • Pod-Hostname als FQDN hat den Beta-Status erreicht. Diese Funktion ermöglicht es, den Hostnamen eines pod auf seinen Fully Qualified Domain Name (FQDN) festzulegen, wodurch das Hostnamenfeld des Kernels auf den FQDN eines pod gesetzt werden kann.

  • Die client-go Anmeldeinformations-Plug-Ins können nun in den aktuellen Clusterinformationen über die KUBERNETES_EXEC_INFO-Umgebungsvariable übergeben werden. Diese Verbesserung ermöglicht es Go-Clients, sich mit externen Anmeldeinformationsanbietern wie einem Schlüsselverwaltungssystem (KMS) zu authentifizieren.

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

Kubernetes 1.19

Weitere Informationen zu Kubernetes 1.19 finden Sie in der offiziellen Versionsankündigung.

  • Ab Version 1.19 fügt Amazon EKS das Tag kubernetes.io/cluster/cluster-name nicht mehr zu Subnetzen hinzu, die beim Erstellen von Clustern übergeben werden. Dieses Subnetz-Tag ist nur erforderlich, wenn Sie beeinflussen möchten, wo der Kubernetes Service Controller oder der AWS Load Balancer Controller Elastic Load Balancer platziert. Weitere Informationen zu den Anforderungen von Subnetzen, die während der Clustererstellung an Amazon EKS übergeben werden, finden Sie unter Aktualisierungen von Amazon EKS: VPC- und Subnetz-Anforderungen und -Überlegungen.

  • Sie müssen keinen Sicherheitskontext mehr für Nicht-Root-Container bereitstellen, die auf die Webidentitäts-Tokendatei zur Verwendung mit IAM-Rollen für Servicekonten zugreifen müssen. Weitere Informationen finden Sie unter IAM-Rollen für Servicekonten und Vorschlag für die Handhabung von Dateiberechtigungen im prognostizierten Dienstkontovolumen auf GitHub.

  • Der pod-Identitäts-Webhook wurde aktualisiert, um das GitHub-Problem mit fehlenden Starttests zu beheben. Der Webhook unterstützt jetzt auch eine Anmerkung zur Steuerung des Tokenablaufs. Weitere Informationen finden Sie in der GitHub-Pull-Anforderung.

  • Die CoreDNS-Version 1.8.0 ist die empfohlene Version für Amazon-EKS-1.19-Cluster. Diese Version wird standardmäßig in neuen Amazon-EKS-1.19-Clustern installiert. Weitere Informationen finden Sie unter Verwalten des CoreDNS-Add-ons.

  • Amazon-EKS-optimierte Amazon-Linux-2-AMIs enthalten die Linux-Kernel-Version 5.4 für die Kubernetes-Version 1.19. Weitere Informationen finden Sie unter Amazon-EKS-optimierte Amazon Linux-AMI.

  • Das CertificateSigningRequest API wurde mit den folgenden Änderungen zu einem stabilen certificates.k8s.io/v1 hochgestuft:

    • spec.signerName ist jetzt erforderlich. Sie können mit der kubernetes.io/legacy-unknown-API keine Anfragen für certificates.k8s.io/v1 erstellen.

    • Sie können weiterhin CSRs mit dem kubernetes.io/legacy-unknown-Signernamen mit der certificates.k8s.io/v1beta1-API erstellen.

    • Sie können weiterhin anfordern, dass ein CSR für ein Nicht-Knotenserver-Zertifikat, Webhooks (z. B. mit der certificates.k8s.io/v1beta1-API) signiert wird. Diese CSRs werden nicht automatisch genehmigt.

    • Um Zertifikate zu genehmigen, benötigt ein privilegierter Benutzer kubectl 1.18.8 oder höher.

    Weitere Informationen zur Certificate-v1-API finden Sie unter Certificate Signing Requests (Zertifikatsignieranforderungen) in der Kubernetes-Dokumentation.

Die folgenden Amazon-EKS-Kubernetes-Ressourcen sind für die Funktion der Kubernetes-Steuerebene von entscheidender Bedeutung. Wir empfehlen Ihnen, sie nicht zu löschen oder zu bearbeiten.

Berechtigung Art Namespace Grund
eks:certificate-controller Rolebinding kube-system Beeinflusst die Funktionen von Unterzeichnern und Genehmigern in der Steuerungsebene.
eks:certificate-controller Role kube-system Beeinflusst die Funktionen von Unterzeichnern und Genehmigern in der Steuerungsebene.
eks:certificate-controller ClusterRolebinding Alle Beeinträchtigt die Fähigkeit von kubelet, Serverzertifikate anzufordern, was sich auf bestimmte Clusterfunktionen wie kubectl exec und kubectl logs auswirkt.

Die folgenden Kubernetes-Funktionen werden jetzt in Kubernetes-1.19-Amazon-EKS-Clustern unterstützt:

  • Der ExtendedResourceToleration-Zugangscontroller ist aktiviert. Dieser Zugangscontroller fügt pods, die erweiterte Ressourcen wie GPUs anfordern, automatisch Toleranzen für Taints hinzu. So müssen Sie die Toleranzen nicht manuell hinzufügen. Weitere Informationen finden Sie unter ExtendedResourceToleration in der Kubernetes-Dokumentation.

  • Elastic Load Balancer (CLB und NLB), die vom In-Tree-Kubernetes-Service-Controller bereitgestellt werden, unterstützen das Filtern der als Instance-Ziele enthaltenen Knoten. Dadurch kann verhindert werden, dass Zielgruppengrenzen in großen Clustern erreicht werden. Weitere Informationen finden Sie im zugehörigen GitHub-Problem und in der service.beta.kubernetes.io/aws-load-balancer-target-node-labels-Anmerkung unter Other ELB annotations (Sonstige ELB-Anmerkungen) in der Kubernetes-Dokumentation.

  • Die Pod-Topologie-Verteilung hat einen stabilen Status erreicht. Sie können Topologieverteilungseinschränkungen verwenden, um zu steuern, wie pods in Ihrem Cluster auf Fehlerdomänen wie Regionen, Zonen, Knoten und andere benutzerdefinierte Topologiedomänen verteilt werden. Dies kann dazu beitragen, eine hohe Verfügbarkeit sowie eine effiziente Ressourcennutzung zu erreichen. Weitere Informationen finden Sie unter Pod Topology Spread Constraints (Einschränkungen bei der Verteilung der Pod-Topologie) in der Kubernetes-Dokumentation.

  • Die Ingress-API ist nun allgemein verfügbar. Weitere Informationen finden Sie unter Ingress in der Kubernetes-Dokumentation.

  • EndpointSlices sind standardmäßig aktiviert. EndpointSlices sind eine neue API, die eine skalierbarere und erweiterbare Alternative zur Endpunkt-API zum Verfolgen von IP-Adressen, Ports, Bereitschaft und Topologieinformationen für Pods bietet, die einen Dienst unterstützen. Weitere Informationen finden Sie unter Skalieren von Kubernetes-Netzwerken mit EndpointSlices im Kubernetes-Blog.

  • Secret- und ConfigMap-Volumes können jetzt als unveränderlich markiert werden. Dadurch wird die Belastung des API-Servers erheblich reduziert, wenn viele Secret- und ConfigMap-Volumes im Cluster vorhanden sind. Weitere Informationen finden Sie unter ConfigMap und Secret in der Kubernetes-Dokumentation.

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

Kubernetes 1.18

Weitere Informationen zu Kubernetes 1.18 finden Sie in der offiziellen Versionsankündigung.

Die folgenden Kubernetes-Funktionen werden jetzt in Kubernetes-1.18-Amazon-EKS-Clustern unterstützt:

  • Der Topologie-Manager hat den Beta-Status erreicht. Diese Funktion ermöglicht es dem CPU- und Geräte-Manager, Entscheidungen zur Ressourcenzuweisung zu koordinieren und so eine geringe Latenz bei Machine-Learning- und -Analyseworkloads zu optimieren. Weitere Informationen finden Sie unter Control Topology Management Policies on a node (Steuern von Topologieverwaltungsrichtlinien auf einem Knoten) in der Kubernetes-Dokumentation.

  • Server-side Apply wird mit einer neuen Betaversion aktualisiert. Die Funktion verfolgt und verwaltet Änderungen an Felder aller neuer Kubernetes-Objekte. So verstehen Sie besser, was ihre Ressourcen wann geändert hat. Weitere Informationen finden Sie unter Was ist Server-side Apply? (Was ist Server-side Apply?) in der Kubernetes-Dokumentation.

  • Der Ingress-Spezifikation wurden ein neues pathType-Feld und eine neue IngressClass-Ressource hinzugefügt. Diese Funktionen erleichtern die Anpassung der Ingress-Konfiguration und werden vom AWS Load Balancer Controller (früher als ALB Ingress Controller bezeichnet) unterstützt. Weitere Informationen finden Sie unter Improvements to the Ingress API in Kubernetes1.18 (Verbesserungen an der Ingress-API in ) in der Kubernetes-Dokumentation.

  • Konfigurierbares horizontales pod-Auto-Scaling-Verhalten. Weitere Informationen finden Sie unter Support for configurable scaling behavior (Unterstützung für konfigurierbares Skalierungsverhalten) in der Kubernetes-Dokumentation.

  • In 1.18-Clustern müssen Sie die AWS_DEFAULT_REGION=region-code-Umgebungsvariable nicht mehr in pods einschließen, wenn Sie IAM-Rollen für Servicekonten in China-Regionen verwenden, unabhängig davon, ob Sie den mutierenden Web-Hook verwenden oder die Umgebungsvariablen manuell konfigurieren. Sie müssen die Variable weiterhin für alle pods in früheren Versionen einschließen.

  • Neue Cluster enthalten aktualisierte Standardwerte in externalTrafficPolicy. HealthyThresholdCount und UnhealthyThresholdCount sind jeweils zwei und HealthCheckIntervalSeconds wird auf zehn Sekunden reduziert. Cluster, die in älteren Versionen erstellt und aktualisiert wurden, behalten die alten Werte bei.

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

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.18 23. März 2020 13. Oktober 2020 31. März 2022
1.19 26. August 2020 16. Februar 2021 1. August 2022
1.20 08. Dezember 2020 18. Mai 2021 1. November 2022
1.21 8. April 2021 19. Juli 2021 Februar 2023
1.22 4. August 2021 4. April 2022 Mai 2023
1.23 7. Dezember 2021 August 2022 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. 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 zu veröffentlichen, und rät von der CVE-Einreichung für veraltete 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-Funktionen werden von Amazon EKS unterstützt?

A: Amazon EKS unterstützt alle generell verfügbaren Funktionen der Kubernetes-API. Standardmäßig aktivierte Betafunktionen werden ebenfalls unterstützt. Alphafunktionen 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 hat ein Zustandsproblem im Abschnitt Node Group (Knotengruppe) der Registerkarte Compute (Datenverarbeitung) Ihres Clusters in der Konsole. 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.20-Knoten funktionieren beispielsweise weiterhin, wenn sie von einer 1.22-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 and version skew support policy (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?

Ja, Fargate-pods werden auf der Infrastruktur in AWS-eigenen Konten auf der Amazon-EKS-Seite des Modells mit geteilter Verantwortung ausgeführt. Amazon EKS verwendet die Kubernetes-Bereinigungs-API, um zu versuchen, pods, die auf Fargate ausgeführt werden, ordnungsgemäß zu leeren. Weitere Informationen finden Sie unter The Eviction API (Die Bereinigungs-API) in der Kubernetes-Dokumentation. Wenn ein pod nicht bereinigt werden kann, gibt Amazon EKS einen Kubernetes-delete podBefehl aus. Wir empfehlen dringend, Fargate-pods als Teil eines Replikationscontrollers wie einer Kubernetes-Bereitstellung auszuführen. Auf diese Weise wird ein pod nach dem Löschen automatisch neu geplant. Weitere Informationen finden Sie unter Deployments (Bereitstellungen) in der Kubernetes-Dokumentation. Die neue Version des Fargate-pod wird mit einer kubelet-Version bereitgestellt, die dieselbe Version wie Ihre aktualisierte Version der Cluster-Steuerebene ist.

Wichtig

Wenn Sie die Steuerebene aktualisieren, müssen Sie die Fargate-Knoten weiterhin 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.