Amazon-EKS-Kubernetes-Versionen - Amazon EKS

Amazon-EKS-Kubernetes-Versionen

Das Kubernetes-Projekt integriert ständig neue Funktionen, Design-Updates und Fehlerbehebungen. Die Community veröffentlicht etwa alle drei Monate neue Kubernetes-Nebenversionen wie 1.21, die allgemein verfügbar sind. Jede Nebenversion wird nach ihrer ersten Veröffentlichung ungefähr zwölf Monate lang unterstützt.

Amazon-EKS-Kubernetes-Versionen

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

  • 1.21.2

  • 1.20.7

  • 1.19.8

  • 1.18.16

  • 1.17.17

  • 1.16.15

Außer wenn Ihre Anwendung eine bestimmte Version von Kubernetes benötigt, empfehlen wir, dass Sie die neueste verfügbare Kubernetes-Version wählen, 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 eines Clusters. Weitere Informationen zu Kubernetes-Releases finden Sie unter Amazon-EKS-Kubernetes-Veröffentlichungskalender und Amazon-EKS-Versionssupport und häufig gestellte Fragen.

Kubernetes 1.21

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

Important

  • Die Unterstützung von Dual-Stack-Netzwerken (IPv4- und IPv6-Adressen) auf Pods, Services und Knoten hat den Beta-Status erreicht. Allerdings unterstützen Amazon EKS und Amazon VPC CNI derzeit kein Dual-Stack-Netzwerk.

  • 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-v1.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 Funktionen werden jetzt in Kubernetes 1.21 Amazon EKS 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-Annotation 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.

Important

Die folgenden 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. EKS wird zu gegebener Zeit zu containerd als Laufzeit für das 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 Pods auf seinen Fully Qualified Domain Name (FQDN) festzulegen, wodurch das Hostnamenfeld des Kernels auf den FQDN eines Pods 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.

Important

  • 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 AWS-Lastenverteilungs-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 Überlegungen zur Cluster-VPC.

    • Subnetz-Tags werden auf vorhandenen Clustern, die auf 1.19 aktualisiert wurden, nicht geändert.

    • Der AWS Lastenverteilungs-Controller Version v2.1.1 und früher erforderte das <cluster-name>-Subnetz-Tag. In Version v2.1.2 und höher können Sie das Tag angeben, um die Subnetzerkennung zu verfeinern, dies ist jedoch nicht erforderlich. Weitere Informationen zum AWS-Lastenverteilungs-Controller finden Sie unter AWS-Lastenverteilungs-Controller. Weitere Informationen zum Subnetz-Tagging bei Verwendung eines Load Balancers finden Sie unter Anwendungslastenverteilung auf Amazon EKS und Netzwerklastenausgleich auf Amazon EKS.

  • 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 Dienstkonten 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.

  • 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-on.

  • Amazon-EKS-optimierte Amazon Linux-2-AMIs enthalten die Linux-Kernel-Version 5.4 für 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 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 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, sodass Sie die Toleranzen nicht manuell hinzufügen müssen. 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-Annotation unter Andere ELB-Annotationen 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 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 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 Steuern von Topologieverwaltungsrichtlinien auf einem Knoten in der Kubernetes-Dokumentation.

  • Das serverseitige Apply wird mit einer neuen Betaversion aktualisiert. Diese Funktion verfolgt und verwaltet Änderungen an Feldern aller neuen Kubernetes-Objekte, sodass Sie wissen, was Ihre Ressourcen wann geändert haben. Weitere Informationen finden Sie unter Was ist serverseitiges Anwenden? 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-Lastenverteilungs-Controller (früher als ALB Ingress Controller bezeichnet) unterstützt. Weitere Informationen finden Sie unter Verbesserungen der Ingress-API in Kubernetes 1.18 in der Kubernetes-Dokumentation.

  • Konfigurierbares horizontales Pod-Auto-Scaling-Verhalten. Weitere Informationen finden Sie unter 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 Dienstkonten 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.

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

Kubernetes 1.17

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

Wichtig
  • EKS hat das CSIMigrationAWS-Funktions-Flag nicht aktiviert. Dies wird in einer zukünftigen Version zusammen mit detaillierten Migrationsanweisungen aktiviert. Weitere Informationen zur CSI-Migration finden Sie im Kubernetes-Blog.

  • Das Aktualisieren eines Clusters von 1.16 auf 1.17 schlägt fehl, wenn einer Ihrer AWS-Fargate-Pods eine kubelet-Nebenversion vor 1.16 hat. Bevor Sie Ihren Cluster von 1.16 auf 1.17 aktualisieren, müssen Sie Ihre Fargate-Pods recyceln, sodass ihr kubelet 1.16 ist, bevor Sie versuchen, den Cluster auf 1.17 zu aktualisieren. Verwenden Sie den folgenden Befehl, um eine Kubernetes-Bereitstellung auf einem Cluster der Version 1.15 oder höher zu recyceln.

    kubectl rollout restart deployment <deployment-name>

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

  • Cloud-Anbieter-Markierungen sind allgemein verfügbar. Wenn Sie die Beta-Labels in Ihren Pod-Spezifikationen für Funktionen wie Knotenaffinität oder in benutzerdefinierten Controllern verwenden, empfehlen wir Ihnen, mit der Migration zu den neuen GA-Markierungen zu beginnen. Informationen zu den neuen Labels finden Sie in der folgenden Kubernetes-Dokumentation:

  • Die Funktion ResourceQuotaScopeSelectors wurde auf allgemein verfügbar erweitert. Sie können diese Funktion verwenden, um die Anzahl der Ressourcen, die ein Kontingent unterstützt, auf die Ressourcen zu beschränken, die zum Bereich gehören.

  • Die TaintNodesByCondition-Funktion wurde auf allgemein verfügbar erweitert. Diese Funktion ermöglicht es Ihnen, Knoten mit Bedingungen wie hoher Festplatten- oder Speicherauslastung zu vergiften.

  • Die CSI-Topologie-Funktion ist mittlerweile allgemein verfügbar und wird vom EBS-CSI-Treiber vollständig unterstützt. Sie können die Topologie verwenden, um die Availability Zone einzuschränken, in der ein Volume bereitgestellt wird.

  • Finalizer-Schutz für Services vom Typ LoadBalancer wurde auf allgemein verfügbar abgestuft. Diese Funktion stellt sicher, dass eine Dienstressource nicht vollständig gelöscht wird, bis der zugehörige Lastenverteilung ebenfalls gelöscht wird.

  • Benutzerdefinierte Ressourcen unterstützen jetzt Standardwerte. Sie geben Werte in einem OpenAPI-v3-Validierungsschema an.

  • Die Funktion Windows-Container RunAsUsername befindet sich jetzt in der Betaphase. Sie können damit Windows-Anwendungen in einem Container unter einem anderen Benutzernamen als dem Standard ausführen.

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

Kubernetes 1.16

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

Wichtig
  • Kubernetes 1.16 entfernt eine Reihe eingestellter APIs. Möglicherweise sind Änderungen an Ihren Anwendungen erforderlich, bevor Sie Ihren Cluster auf 1.16 aktualisieren. Befolgen Sie vor dem Update die Voraussetzungen für das Update 1.16.

  • Ab Version 1.16 akzeptiert die Amazon-EKS-Zertifizierungsstelle Zertifikatsignierungsanforderungen mit SAN-X.509-Erweiterungen. Dadurch wird die Funktionsanfrage EKS-Zertifizierungsstelle soll SAN x509-Erweiterung anerkennen von GitHub gelöst.

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

  • Die Volume-Erweiterung in der CSI-Spezifikation wurde in die Beta-Phase verschoben. Auf diese Weise kann die Größe jedes CSI-Spezifikations-Volumes-Plug-Ins geändert werden. Weitere Informationen finden Sie unter Volume Expansion in der Kubernetes CSI-Dokumentation. Die neueste Version des EBS-CSI-Treibers unterstützt die Volume-Erweiterung, wenn sie auf einem Amazon EKS 1.16-Cluster ausgeführt wird.

  • Windows GMSA-Unterstützung wurde von Alpha auf Beta heraufgestuft und wird jetzt von Amazon EKS unterstützt. Weitere Informationen finden Sie unter Konfigurieren von GMSA für Windows-Pods und -Containern in der Kubernetes-Dokumentation.

  • Eine neue Anmerkung: service.beta.kubernetes.io/aws-load-balancer-eip-allocations steht unter dem Servicetyp LoadBalancer zur Verfügung, um Network Load Balancers elastische IP-Adressen zuzuweisen. Weitere Informationen finden Sie unter dem GitHub-Problem Unterstützung von EIP-Zuweisungen unter AWS NLB.

  • Der Finalizer-Schutz für Service Load Balancer ist jetzt in der Beta und standardmäßig aktiviert. Der Finalizer-Schutz für die Service-Lastenverteilung stellt sicher, dass alle Lastenverteilungs-Ressourcen, die einem Kubernetes Service-Objekt zugewiesen sind, wie z. B. Netzwerklastenverteilung, beim Löschen des Service zerstört oder freigegeben werden. Weitere Informationen finden Sie unter Garbage Collecting Load Balancers in der Kubernetes-Dokumentation.

  • Die Kubernetes-Erweiterbarkeitsmechanismen zu benutzerdefinierten Ressourcendefinitionen und Zugang-Webhooks haben beide allgemeine Verfügbarkeit erreicht. Weitere Informationen finden Sie unter Benutzerdefinierte Ressourcen und dynamische Zugangssteuerung in der Kubernetes-Dokumentation.

  • Die serverseitige Anwenden-Funktion hat den Beta-Status erreicht und ist standardmäßig aktiviert. Weitere Informationen finden Sie unter Serverseitiges Anwenden in der Kubernetes-Dokumentation.

  • Die CustomResourceDefaulting-Funktion wird auf Beta hochgestuft und standardmäßig aktiviert. Standardwerte könnten in Strukturschemas über die apiextensions.k8s.io/v1-API angegeben werden. Weitere Informationen finden Sie unter Angeben eines strukturellen Schemas in der Kubernetes-Dokumentation.

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

Amazon-EKS-Kubernetes-Veröffentlichungskalender

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.16 8. September 2019 30. April 2020 27. September 2021
1,17 9. 2019. Dezember 2019 10. Juli 2020 2. November 2021
1.18 23. März 2020 13. Oktober 2020 18. Februar 2022
1.19 26. August 2020 16. Februar 2021 April 2022
1.20 8. Dezember 2020 18. Mai 2021 Juli 2022
1.21 8. April 2021 19. Juli 2021 September 2022

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 Freigabeprozesses 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 vollständig 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 AWS Personal 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 So aktualisieren Sie die Kubernetes-Version für Ihren-Amazon EKS-Cluster .

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, proaktive Maßnahmen zu ergreifen und Ihre Steuerebene zu aktualisieren, ohne sich auf den automatischen Aktualisierungsprozess von Amazon EKS zu verlassen. Weitere Informationen finden Sie unter Aktualisieren eines Clusters.

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

A: Nein, Cloud-Sicherheit bei AWS hat höchste Priorität. Amazon EKS lässt 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 allgemeinen Verfügbarkeitsfunktionen der Kubernetes-API sowie standardmäßig aktivierte Betafunktionen. 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. Wenn Amazon EKS Ihre Steuerungsebene automatisch aktualisiert, ist die Kubernetes-Version in Ihrer verwalteten Knotengruppe möglicherweise mehr als eine Version älter als Ihre Steuerebene. Wenn 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, hat die Knotengruppe ein Integritätsproblem im Abschnitt Knotengruppen der Registerkarte Computing auf der Registerkarte Konfiguration Ihres Clusters in der Konsole. Wenn für eine Knotengruppe ein verfügbares Versionsupdate verfügbar ist, wird neben der Knotengruppe in der Konsole Jetzt aktualisieren angezeigt. Weitere Informationen finden Sie unter Aktualisieren einer verwalteten Knotengruppe. Wir empfehlen, dieselbe Kubernetes-Version auf Ihrer Steuerungsebene 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 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.19-Knoten funktionieren beispielsweise weiterhin, wenn sie von einer 1.21-Steuerungsebene 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 in der Kubernetes-Dokumentation. Wir empfehlen, dieselbe Kubernetes-Version auf Ihrer Steuerungsebene 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 Die Bereinigungs-API in der Kubernetes-Dokumentation. Wenn ein Pod nicht entfernt werden kann, gibt Amazon EKS einen Kubernetes delete pod-Befehl aus. Wir empfehlen dringend, Fargate-Pods als Teil eines Replikationscontrollers wie einer Kubernetes-Bereitstellung auszuführen, damit ein Pod nach dem Löschen automatisch neu geplant wird. Weitere Informationen finden Sie unter Bereitstellungen in der Kubernetes-Dokumentation. Die neue Version des Fargate-Pods wird mit einer kubelet-Version bereitgestellt, die dieselbe Version wie Ihre aktualisierte Version der Cluster-Steuerungsebene ist.

Wichtig

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