Lesen Sie die Versionshinweise für Kubernetes Versionen mit erweitertem Support - Amazon EKS
Kubernetes1.27Kubernetes1.26Kubernetes1.25Kubernetes1.24Kubernetes1.23

Hilf mit, diese Seite zu verbessern

Möchten Sie zu diesem Benutzerhandbuch beitragen? Scrollen Sie zum Ende dieser Seite und wählen Sie Diese Seite bearbeiten am aus GitHub. Ihre Beiträge werden dazu beitragen, unser Benutzerhandbuch für alle zu verbessern.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Lesen Sie die Versionshinweise für Kubernetes Versionen mit erweitertem Support

Dieses Thema erläutert wichtige Änderungen, die Sie für jede Kubernetes-Version des verlängerten Supports beachten sollten. Überprüfen Sie beim Upgrade sorgfältig die Änderungen, die zwischen der alten und der neuen Version für Ihren Cluster vorgenommen wurden.

Kubernetes1.27

Kubernetes1.27ist jetzt bei Amazon erhältlichEKS. 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. EKScontainerdSeitdem ist die Standard-Container-Laufzeit für Amazon gültig1.24, sodass die Container-Laufzeit nicht mehr angegeben werden muss. Von 1.27 nun an ignoriert Amazon EKS das --container-runtime Argument, das an alle 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. Diese Verbesserungen ermöglichen es, ein höheres Volumen an API Anfragen kubelet zu verarbeiten und so die Antwortzeiten und die Leistung zu verbessern. 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-chanceOption im Kubernetes API Server verhindert, dass HTTP/2 Client-Verbindungen auf einer einzelnen API Serverinstanz hängen bleiben, indem eine Verbindung nach dem Zufallsprinzip geschlossen wird. Wenn die Verbindung geschlossen wird, versucht der Client, die Verbindung wiederherzustellen, und landet aufgrund des Lastenausgleichs wahrscheinlich auf einem anderen API Server. EKSDie Amazon-Version 1.27 hat goaway-chance Flag aktiviert. Wenn Ihr Workload, der auf dem EKS Amazon-Cluster ausgeführt wird, einen Client verwendet, der nicht kompatibel ist HTTP GOAWAY, empfehlen wir Ihnen, Ihren Client so zu aktualisieren, dass er GOAWAY bei Verbindungsabbruch erneut eine Verbindung herstellt.

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

Kubernetes1.26

Kubernetes1.26ist jetzt bei Amazon erhältlichEKS. 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 Amazon Linux und Bottlerocket AMIs inkludiert die Container-Version1.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 Zuweisen IPs zu Pods mit dem Amazon VPC CNI.

  • Die goaway-chanceOption im Kubernetes API Server verhindert, dass HTTP/2 Client-Verbindungen auf einer einzelnen API Serverinstanz hängen bleiben, indem eine Verbindung nach dem Zufallsprinzip geschlossen wird. Wenn die Verbindung geschlossen wird, versucht der Client, die Verbindung wiederherzustellen, und landet aufgrund des Lastenausgleichs wahrscheinlich auf einem anderen API Server. EKSDie Amazon-Version 1.26 hat goaway-chance Flag aktiviert. Wenn Ihr Workload, der auf dem EKS Amazon-Cluster ausgeführt wird, einen Client verwendet, der nicht kompatibel ist HTTP GOAWAY, empfehlen wir Ihnen, Ihren Client so zu aktualisieren, dass er GOAWAY bei Verbindungsabbruch erneut eine Verbindung herstellt.

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

Kubernetes1.25

Kubernetes1.25ist jetzt bei Amazon erhältlichEKS. Weitere Informationen zu Kubernetes 1.25 finden Sie in der offiziellen Versionsankündigung.

Wichtig

  • Ab Kubernetes Version 1.25 können Sie EC2 P2 Amazon-Instances nicht mehr standardmäßig mit dem EKS für Amazon optimierten beschleunigten Amazon Linux AMIs verwenden. Diese Kubernetes Versionen AMIs für Versionen 1.25 oder höher unterstützen Treiber der NVIDIA 525 Serien oder neuer, die mit den P2 Instances nicht kompatibel sind. Treiber der NVIDIA 525 Serie oder neuer sind jedoch mit den P5 Instanzen P3P4, und kompatibel, sodass Sie diese Instanzen mit der Kubernetes Version AMIs for 1.25 oder höher verwenden können. Bevor Ihre EKS Amazon-Cluster auf Version aktualisiert werden1.25, migrieren Sie alle P2 Instances zu P3P4, und P5 Instances. Sie sollten Ihre Anwendungen auch proaktiv aktualisieren, damit sie mit der NVIDIA 525-Serie oder höher funktionieren. Wir planen, die Treiber der neueren NVIDIA 525 Serie oder neuer auf Kubernetes Versionen 1.23 und 1.24 Ende Januar 2024 zurück zu portieren.

  • PodSecurityPolicy(PSP) wurde entfernt in Kubernetes1.25. PSPswerden durch Pod Security Admission (PSA) und Pod Security Standards ersetzt(PSS). PSAist ein integrierter Zugangscontroller, der die in der beschriebenen Sicherheitskontrollen implementiert PSS. PSAund PSS sind auf Stable In abgestuft Kubernetes 1.25 und sind EKS standardmäßig in Amazon aktiviert. Wenn Sie bereits PSPs in Ihrem Cluster sind, stellen Sie sicher, dass Sie von PSP der integrierten Version Kubernetes PSS oder zu einer policy-as-code Lösung migrieren, bevor Sie Ihren Cluster auf Version aktualisieren1.25. Wenn Sie nicht von migrierenPSP, kann es zu Unterbrechungen Ihrer Workloads kommen. Weitere Informationen hierzu finden Sie unter Migrieren Sie von älteren Pod-Sicherheitsrichtlinien (PSP).

  • Kubernetes1.25Diese Version enthält Änderungen, die das Verhalten einer bestehenden Funktion ändern, die als API Priority and Fairness () bekannt ist. APF APFdient dazu, den API Server vor potenzieller Überlastung in Zeiten erhöhten Anforderungsvolumens 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 Server überfordern. API Weitere Informationen finden Sie unter APIPriorität und Fairness in der Kubernetes Dokumentation oder unter APIPriorität und Fairness im Best Practices-Leitfaden. EKS

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

    Beim Upgrade auf EKS Amazon-Version 1.25 oder höher kann dieses aktualisierte Verhalten dazu führen, dass bei Workloads mit hohen LIST Anforderungen (die zuvor problemlos funktionierten) Ratenbegrenzungen auftreten. 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 für nicht wichtige Anfragen zugewiesene Kapazität zu reduzieren. Weitere Informationen zu diesen Risikominderungstechniken finden Sie unter Vermeidung verworfener Anfragen im EKS Best Practices-Leitfaden.

  • Amazon EKS 1.25 bietet Verbesserungen an 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 die aws-auth ConfigMap in Amazon v0.6.3 EKS 1.25 korrekt analysiert.

  • Die API Betaversion (discovery.k8s.io/v1beta1) von EndpointSlice war veraltet Kubernetes 1.21 und wird ab sofort nicht mehr bereitgestellt. Kubernetes 1.25 Dies API wurde aktualisiert auf. discovery.k8s.io/v1 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 verwendenAWS Load Balancer Controller, müssen Sie ein Upgrade auf durchführen, AWS Load Balancer Controller v2.4.7 bevor Sie Ihr EKS Amazon-Cluster auf aktualisieren1.25. 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 Internetverkehr mit AWS Load Balancer Controller weiterleiten.

  • Die API Betaversion (autoscaling/v2beta1) von HorizontalPodAutoscaler wird nicht mehr als 1.25 Kubernetes bereitgestellt. Dies API war in der Version veraltet. 1.23 Migrieren Sie Manifeste und API Clients, um die Version zu verwenden. autoscaling/v2 HorizontalPodAutoscaler API Weitere Informationen finden Sie in der Kubernetes-Dokumentation.

  • 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 RuntimeDefaultseccomp -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 dieses Flag verfügbar ist, aktiviert Amazon dieses Flag standardmäßig EKS nicht, sodass EKS das Verhalten von Amazon 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.

  • Die Support für das Container Runtime Interface (CRI) für Docker (auch bekannt alsdockershim) wurde ab Kubernetes 1.24 und später entfernt. Die einzige Container-Laufzeit in Amazon, AMIs die EKS offiziell für Cluster Kubernetes 1.24 und spätere Versionen istcontainerd. Entfernen Sie vor dem Upgrade auf Amazon EKS 1.24 oder später alle Verweise auf Bootstrap-Skript-Flags, die nicht mehr unterstützt werden. Weitere Informationen finden Sie unter Migrieren von dockershim zu containerd.

  • 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-chanceOption 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, die Verbindung wiederherzustellen, und landet aufgrund des Lastenausgleichs wahrscheinlich auf einem anderen API Server. EKSDie Amazon-Version 1.25 hat goaway-chance Flag aktiviert. Wenn Ihr Workload, der auf dem EKS Amazon-Cluster ausgeführt wird, einen Client verwendet, der nicht kompatibel ist HTTP GOAWAY, empfehlen wir Ihnen, Ihren Client so zu aktualisieren, dass er GOAWAY bei Verbindungsabbruch erneut eine Verbindung herstellt.

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.

Kubernetes1.24

Kubernetes1.24ist jetzt bei Amazon erhältlichEKS. Weitere Informationen zu Kubernetes 1.24 finden Sie in der offiziellen Versionsankündigung.

Wichtig

  • Ab sind neue APIs Betaversionen standardmäßig nicht in Clustern aktiviert. Kubernetes 1.24 Standardmäßig sind bestehende Betaversionen APIs und neue Versionen vorhandener Betaversionen APIs weiterhin aktiviert. Amazon EKS folgt dem gleichen Verhalten wie Upstream Kubernetes1.24. Die Feature-Gates, die neue Funktionen 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 ausgeschaltet. GitHub

  • Die Support für Container Runtime Interface (CRI) für Docker (auch bekannt alsdockershim) wurde von entfernt Kubernetes1.24. Amazon AMIs hat es EKS offiziell 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 Migrieren von dockershim zu containerd.

  • 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 Format analysieren. JSON Im dockerd Gegensatz dazu enthält die containerd Container-Laufzeit Protokollnachrichten, die nicht formatiert JSON sind. 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 Fluent BitSo einrichten, dass Logs DaemonSet an Logs gesendet werden CloudWatch .

  • In Kubernetes 1.23 und früheren Versionen werden kubelet Serverzertifikate mit nicht verifizierbaren IP-Adressen und alternativen DNS Betreffnamen (SANs) automatisch mit nicht verifizierbaren Zertifikaten ausgestellt. SANs Diese nicht überprüfbaren Daten SANs werden im bereitgestellten Zertifikat nicht berücksichtigt. In Clustern der Version 1.24 und neueren Versionen werden kubelet keine Serverzertifikate ausgestellt, wenn keine verifiziert SAN werden können. Dadurch wird verhindert, dass die Befehle kubectl-exec und kubectl-logs funktionieren. Weitere Informationen finden Sie unter Überlegungen zur Zertifikatsignierung vor dem Upgrade Ihres Clusters auf Kubernetes 1.24.

  • Wenn Sie ein Upgrade eines EKS 1.23 Amazon-Clusters durchführenFluent Bit, das verwendet, müssen Sie sicherstellen, dass er ausgeführt wird k8s/1.3.12 oder später. Sie können dies tun, indem Sie die neueste zutreffende Fluent Bit YAML Datei von GitHub erneut anwenden. Weitere Informationen finden Sie unter Einrichtung Fluent Bit im CloudWatch Amazon-Benutzerhandbuch.

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

  • Das PodSecurityPolicy (PSP) soll voraussichtlich in Kubernetes 1.25 entfernt werden. PSPswerden durch Pod Security Admission (PSA) ersetzt. PSAist ein integrierter Zugangscontroller, der die in den Pod Security Standards (PSS) beschriebenen Sicherheitskontrollen verwendet. PSAund PSS sind beide Beta-Funktionen und sind EKS standardmäßig in Amazon aktiviert. Um das Entfernen von PSP In-Version zu 1.25 beheben, empfehlen wir die Implementierung PSS in AmazonEKS. Weitere Informationen finden Sie im AWS Blog unter Implementierung von Pod-Sicherheitsstandards in EKS Amazon.

  • Das client.authentication.k8s.io/v1alpha1 ExecCredential ist entfernt in Kubernetes1.24. Das ExecCredential API war allgemein verfügbar in Kubernetes1.22. Wenn Sie ein Plug-in für Client-Go-Anmeldeinformationen verwenden, das auf dem basiert, wenden Sie sich an den Händler Ihres Plugins v1alpha1API, um zu erfahren, wie Sie auf das migrieren können. v1 API

  • Denn Kubernetes 1.24 wir haben eine Funktion zum Upstream-Projekt Cluster Autoscaler beigetragen, die die Skalierung von von Amazon EKS verwalteten Knotengruppen auf und von Nullknoten vereinfacht. Bisher mussten Sie, damit der Cluster Autoscaler die Ressourcen, Labels und Schwächen einer verwalteten Knotengruppe, die auf null Knoten skaliert wurde, verstehen, die zugrunde liegende Amazon EC2 Auto Scaling Scaling-Gruppe mit den Details der Knoten kennzeichnen, für die sie verantwortlich war. Wenn es nun keine laufenden Knoten in der verwalteten Knotengruppe gibt, ruft der Cluster Autoscaler den EKS DescribeNodegroup API Amazon-Vorgang auf. Dieser API Vorgang liefert die Informationen, die der Cluster Autoscaler über die Ressourcen, Labels und Fehler der verwalteten Knotengruppe benötigt. Für diese Funktion müssen Sie die eks:DescribeNodegroup entsprechende Berechtigung zur Cluster-Autoscaler-Dienstkontorichtlinie hinzufügen. IAM 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 Scaling-Gruppen-Tags. Auf diese Weise können Sie Werte nach Bedarf überschreiben. Weitere Informationen finden Sie unter Skalieren Sie Cluster-Computing mit Karpenter und Cluster Autoscaler.

  • Wenn Sie beabsichtigen, unsere Trainium Instance-Typen mit Amazon zu verwenden Inferentia EKS1.24, müssen Sie ein Upgrade auf die AWS Neuron Geräte-Plug-in-Version 1.9.3.0 oder höher durchführen. Weitere Informationen finden Sie in der Dokumentation unter Neuron K8-Version [1.9.3.0]. AWS Neuron

  • 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-chanceOption im Kubernetes API Server verhindert, dass HTTP/2 Client-Verbindungen auf einer einzelnen API Serverinstanz hängen bleiben, indem eine Verbindung nach dem Zufallsprinzip geschlossen wird. Wenn die Verbindung geschlossen wird, versucht der Client, die Verbindung wiederherzustellen, und landet aufgrund des Lastenausgleichs wahrscheinlich auf einem anderen API Server. EKSDie Amazon-Version 1.24 hat goaway-chance Flag aktiviert. Wenn Ihr Workload, der auf dem EKS Amazon-Cluster ausgeführt wird, einen Client verwendet, der nicht kompatibel ist HTTP GOAWAY, empfehlen wir Ihnen, Ihren Client so zu aktualisieren, dass er GOAWAY bei Verbindungsabbruch erneut eine Verbindung herstellt.

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.

Kubernetes1.23

Kubernetes1.23ist jetzt bei Amazon erhältlichEKS. Weitere Informationen zu Kubernetes 1.23 finden Sie in der offiziellen Versionsankündigung.

Wichtig

  • Die Kubernetes Funktion zur Volumenmigration zwischen Baum und Container Storage Interface (CSI) ist aktiviert. Diese Funktion ermöglicht den Ersatz vorhandener Kubernetes In-Tree-Speicher-Plugins für Amazon EBS durch einen entsprechenden EBS CSI Amazon-Treiber. Weitere Informationen finden Sie im Blog unter Kubernetes1.17 Feature: Kubernetes In-Tree to CSI Volume Migration Moves to Beta. Kubernetes

    Die Funktion übersetzt In-Tree in Äquivalent CSI APIs und delegiert Operationen APIs an einen Ersatztreiber. CSI 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. Die Funktion ermöglicht esKubernetes, alle Speicherverwaltungsvorgänge vom In-Tree-Plugin an den Treiber zu delegieren. CSI Wenn Sie EBS Amazon-Volumes in einem vorhandenen Cluster verwenden, installieren Sie den EBS CSI Amazon-Treiber in Ihrem Cluster, bevor Sie Ihren Cluster auf Version aktualisieren1.23. 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 EBS Amazon-Volumes in einem neuen 1.23 Cluster verwenden, installieren Sie den EBS CSI Amazon-Treiber in Ihrem Cluster, bevor Sie die Workloads in Ihrem Cluster bereitstellen. Anweisungen zur Installation des EBS CSI Amazon-Treibers auf Ihrem Cluster finden Sie unterSpeichern Kubernetes Volumen mit Amazon EBS. Häufig gestellte Fragen zum Migrationsfeature finden Sie unter Häufig gestellte Fragen EBS CSI zur Amazon-Migration.

  • Erweiterter Support für Amazon EKS Optimized WindowsAMIs, veröffentlicht von, AWS ist nicht für Kubernetes Version, 1.23 aber für Kubernetes Version 1.24 und höher verfügbar.

  • 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 den Support für den dockershim Start in der EKS Amazon-Version beenden1.24. Ab der EKS Amazon-Version 1.24 AMIs wird Amazon EKS Official containerd die einzige Laufzeit haben.

    Auch wenn die EKS Amazon-Version 1.23 weiterhin unterstützt wirddockershim, empfehlen wir Ihnen, Ihre Anwendungen jetzt zu testen, um Docker Abhängigkeiten zu identifizieren 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 Migrieren von dockershim zu containerd.

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

  • Kuberneteshat die Funktion Pod Security Admission (PSA) auf Betaversion umgestellt. Das Feature ist standardmäßig aktiviert. Weitere Informationen finden Sie unter Pod Security Admission in der Kubernetes-Dokumentation. PSAersetzt den Pod Security Policy (PSP) -Zugangscontroller. Der PSP Zugangscontroller wird nicht unterstützt und soll in der Kubernetes Version entfernt 1.25 werden.

    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 finden Sie unter Pod-Sicherheitsstandards (PSS) und Pod-Sicherheitszulassung (PSA) im EKS Amazon-Best-Practices-Leitfaden.

  • Das mit Clustern bereitgestellte kube-proxy Image ist jetzt das minimale Basis-Image, das von Amazon EKS Distro (EKS-D) verwaltet wird. 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.

  • Kuberneteshat den HorizontalPodAutoscaler autoscaling/v2 Stable auf allgemeine Verfügbarkeit API umgestellt. Das HorizontalPodAutoscaler autoscaling/v2beta2 API ist veraltet. Es wird in 1.26 nicht verfügbar sein.

  • Die goaway-chanceOption im Kubernetes API Server verhindert, dass HTTP/2 Client-Verbindungen auf einer einzelnen API Serverinstanz hängen bleiben, indem eine Verbindung nach dem Zufallsprinzip geschlossen wird. Wenn die Verbindung geschlossen wird, versucht der Client, die Verbindung wiederherzustellen, und landet aufgrund des Lastenausgleichs wahrscheinlich auf einem anderen API Server. EKSDie Amazon-Version 1.23 hat goaway-chance Flag aktiviert. Wenn Ihr Workload, der auf dem EKS Amazon-Cluster ausgeführt wird, einen Client verwendet, der nicht kompatibel ist HTTP GOAWAY, empfehlen wir Ihnen, Ihren Client so zu aktualisieren, dass er GOAWAY bei Verbindungsabbruch erneut eine Verbindung herstellt.

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.