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.
Bewährte Methoden für Cluster-Upgrades
In diesem Handbuch erfahren Clusteradministratoren, wie sie ihre EKS Amazon-Upgrade-Strategie planen und ausführen können. Außerdem wird beschrieben, wie selbstverwaltete Knoten, verwaltete Knotengruppen, Karpenter-Knoten und Fargate-Knoten aktualisiert werden. Es beinhaltet keine Anleitungen zu EKS Anywhere, selbstverwaltetem Kubernetes, AWS Outposts oder Local Zones. AWS
Übersicht
Eine Kubernetes-Version umfasst sowohl die Steuerungsebene als auch die Datenebene. Um einen reibungslosen Betrieb zu gewährleisten, sollten sowohl auf der Steuerungsebene als auch auf der Datenebene dieselbe Kubernetes-Nebenversion
-
Kontrollebene — Die Version der Kontrollebene wird vom API Kubernetes-Server bestimmt. Kümmert sich in EKS Amazon-Clustern um die Verwaltung dieser Komponente. AWS Upgrades der Steuerungsebene können über den initiiert werden AWSAPI.
-
Datenebene — Die Datenebenenversion ist den Kubelet-Versionen zugeordnet, die auf Ihren einzelnen Knoten ausgeführt werden. Es ist möglich, dass Knoten im selben Cluster unterschiedliche Versionen ausführen. Sie können die Versionen aller Knoten überprüfen, indem Sie Folgendes ausführen
kubectl get nodes.
Vor dem Upgrade
Wenn Sie planen, Ihre Kubernetes-Version bei Amazon zu aktualisierenEKS, sollten Sie einige wichtige Richtlinien, Tools und Verfahren einrichten, bevor Sie mit einem Upgrade beginnen.
-
Verstehen Sie die Richtlinien für veraltete Versionen — Verschaffen Sie sich ein tiefes Verständnis dafür, wie die Kubernetes-Richtlinie
für veraltete Produkte funktioniert. Seien Sie sich aller bevorstehenden Änderungen bewusst, die sich auf Ihre bestehenden Anwendungen auswirken könnten. In neueren Versionen von Kubernetes werden bestimmte APIs Funktionen häufig schrittweise eingestellt, was möglicherweise zu Problemen bei der Ausführung von Anwendungen führen kann. -
Kubernetes-Änderungsprotokoll überprüfen — Prüfen Sie das Kubernetes-Änderungsprotokoll zusammen mit den Amazon EKS Kubernetes-Versionen
gründlich, um mögliche Auswirkungen auf Ihren Cluster zu verstehen, z. B. wichtige Änderungen, die sich auf Ihre Workloads auswirken könnten. -
Beurteilen Sie die Kompatibilität von Cluster-Add-Ons — Amazon aktualisiert ein Add-on EKS nicht automatisch, wenn neue Versionen veröffentlicht werden oder nachdem Sie Ihren Cluster auf eine neue Kubernetes-Nebenversion aktualisiert haben. Weitere Informationen zur Kompatibilität vorhandener Cluster-Add-Ons mit der Cluster-Version, auf die Sie ein Upgrade durchführen möchten, finden Sie unter Aktualisierung eines Add-ons.
-
Protokollierung auf Kontrollebene aktivieren — Aktivieren Sie die Protokollierung auf der Kontrollebene, um Protokolle, Fehler oder Probleme aufzuzeichnen, die während des Upgrade-Vorgangs auftreten können. Erwägen Sie, diese Protokolle auf etwaige Anomalien zu überprüfen. Testen Sie Cluster-Upgrades in einer Nicht-Produktionsumgebung oder integrieren Sie automatisierte Tests in Ihren kontinuierlichen Integrations-Workflow, um die Versionskompatibilität mit Ihren Anwendungen, Controllern und benutzerdefinierten Integrationen zu bewerten.
-
Entdecken Sie eksctl für Clustermanagement — Erwägen Sie, eksctl
für die Verwaltung Ihres Clusters zu verwenden. EKS Es bietet Ihnen die Möglichkeit, die Steuerungsebene zu aktualisieren, Add-Ons zu verwalten und Worker-Node-Updates durchzuführen. out-of-the-box -
Entscheiden Sie sich für Managed Node Groups oder EKS auf Fargate — Optimieren und automatisieren Sie Worker-Node-Upgrades mithilfe von EKSManaged Node Groups oder EKSauf Fargate. Diese Optionen vereinfachen den Prozess und reduzieren die Anzahl manueller Eingriffe.
-
Verwenden Sie das kubectl Convert Plugin — Nutzen Sie das kubectl convert-Plugin
, um die Konvertierung von Kubernetes-Manifestdateien zwischen verschiedenen Versionen zu erleichtern. API Dadurch kann sichergestellt werden, dass Ihre Konfigurationen mit der neuen Kubernetes-Version kompatibel bleiben.
Behalten Sie Ihren Cluster up-to-date
Für eine sichere und effiziente EKS Umgebung ist es von größter Bedeutung, über Kubernetes-Updates auf dem Laufenden zu bleiben. Dies spiegelt das Modell der gemeinsamen Verantwortung bei Amazon wider. EKS Indem Sie diese Strategien in Ihren betrieblichen Arbeitsablauf integrieren, positionieren Sie sich in der Lage up-to-date, sichere Cluster aufrechtzuerhalten, die die neuesten Funktionen und Verbesserungen in vollem Umfang nutzen. Taktiken:
-
Richtlinie für unterstützte Versionen — In Abstimmung mit der Kubernetes-Community bietet Amazon EKS in der Regel drei aktive Kubernetes-Versionen an. Eine Kubernetes-Nebenversion wird in den ersten 14 Monaten nach ihrer Veröffentlichung standardmäßig von Amazon EKS unterstützt. Sobald das Ende des Standard-Supportdatums für eine Version überschritten ist, gilt für sie der erweiterte Support für die nächsten 12 Monate. Benachrichtigungen über veraltete Versionen werden mindestens 60 Tage vor Ablauf des Standard-Supportdatums veröffentlicht. Weitere Informationen finden Sie in den Dokumenten zum EKSVersionslebenszyklus.
-
Richtlinie für automatische Upgrades — Wir empfehlen dringend, mit den Kubernetes-Updates in Ihrem Cluster auf dem Laufenden zu bleiben. EKS Cluster, die auf einer Kubernetes-Version laufen, die ihren 26-monatigen Lebenszyklus (14 Monate Standardsupport plus 12 Monate erweiterter Support) abgeschlossen hat, werden automatisch auf die nächste Version aktualisiert. Beachten Sie, dass Sie den erweiterten Support deaktivieren können. Wenn Sie vor einer Version nicht proaktiv ein Upgrade durchführen, end-of-life wird ein automatisches Upgrade ausgelöst, wodurch Ihre Workloads und Systeme gestört werden könnten. Weitere Informationen finden Sie in der Version. EKS FAQs
-
Upgrade-Runbooks erstellen — Richten Sie einen gut dokumentierten Prozess für die Verwaltung von Upgrades ein. Entwickeln Sie im Rahmen Ihres proaktiven Ansatzes Runbooks und spezielle Tools, die auf Ihren Upgrade-Prozess zugeschnitten sind. Dadurch sind Sie nicht nur besser vorbereitet, sondern auch komplexe Umstellungen werden vereinfacht. Machen Sie es sich zur Standardpraxis, Ihre Cluster mindestens einmal pro Jahr zu aktualisieren. Diese Vorgehensweise passt Sie an den laufenden technologischen Fortschritt an und erhöht so die Effizienz und Sicherheit Ihrer Umgebung.
Sehen Sie sich den Veröffentlichungskalender an EKS
Im EKS Kubernetes-Veröffentlichungskalender erfahren Sie, wann neue Versionen verfügbar sind und wann der Support für bestimmte Versionen endet. In der Regel werden jährlich drei Nebenversionen von Kubernetes EKS veröffentlicht, und jede Nebenversion wird etwa 14 Monate lang unterstützt.
Lesen Sie außerdem die Upstream-Versionsinformationen von Kubernetes
Erfahren Sie, wie das Modell der gemeinsamen Verantwortung für Cluster-Upgrades gilt
Sie sind dafür verantwortlich, das Upgrade sowohl für die Clustersteuerungsebene als auch für die Datenebene zu initiieren. Erfahren Sie, wie Sie ein Upgrade initiieren. Wenn Sie ein Cluster-Upgrade initiieren, AWS verwaltet es das Upgrade der Cluster-Steuerebene. Sie sind für die Aktualisierung der Datenebene verantwortlich, einschließlich der Fargate-Pods und -Addons. Sie müssen Upgrades für Workloads, die auf Ihrem Cluster ausgeführt werden, validieren und planen, um sicherzustellen, dass deren Verfügbarkeit und Betrieb nach dem Cluster-Upgrade nicht beeinträchtigt werden
Führen Sie ein direktes Upgrade der Cluster durch
EKSunterstützt eine Strategie für ein direktes Cluster-Upgrade. Dadurch werden die Clusterressourcen beibehalten und die Clusterkonfiguration konsistent gehalten (z. B. API Endpunkt,, OIDCENIs, Load Balancer). Dies ist weniger störend für Cluster-Benutzer und nutzt die vorhandenen Workloads und Ressourcen im Cluster, ohne dass Sie Workloads erneut bereitstellen oder externe Ressourcen (z. B. Speicher) migrieren müssen. DNS
Bei der Durchführung eines direkten Cluster-Upgrades ist zu beachten, dass jeweils nur ein kleineres Versionsupgrade ausgeführt werden kann (z. B. von 1.24 auf 1.25).
Das bedeutet, dass, wenn Sie mehrere Versionen aktualisieren müssen, eine Reihe von aufeinanderfolgenden Upgrades erforderlich sind. Die Planung sequentieller Upgrades ist komplizierter und birgt ein höheres Ausfallrisiko. In dieser Situation finden Sie weitere Informationen unterEvaluieren Sie Blue/Green-Cluster als Alternative zu direkten Cluster-Upgrades.
Rüsten Sie Ihre Steuerungsebene und Datenebene nacheinander auf
Um einen Cluster zu aktualisieren, müssen Sie die folgenden Maßnahmen ergreifen:
-
Erstellen Sie eine Sicherungskopie des Clusters. (fakultativ)
-
Identifizieren und korrigieren Sie veraltete und entfernte API Nutzungen in Ihren Workloads.
-
Stellen Sie sicher, dass sich Managed Node Groups, sofern sie verwendet werden, auf derselben Kubernetes-Version wie die Steuerungsebene befinden. EKSverwaltete Knotengruppen und Knoten, die von EKS Fargate Profiles erstellt wurden, unterstützen zwei geringfügige Versionsunterschiede zwischen der Steuerungsebene und der Datenebene für Kubernetes Version 1.27 und niedriger. Ab Version 1.28 unterstützen EKS verwaltete Knotengruppen und Knoten, die von EKS Fargate Profiles erstellt wurden, drei kleinere Versionsunterschiede zwischen Steuerungsebene und Datenebene. Wenn Ihre EKS Steuerungsebenenversion beispielsweise 1.28 ist, können Sie problemlos Kubelet-Versionen verwenden, die so alt sind wie 1.25. Wenn Ihre EKS Version 1.27 ist, ist die älteste Kubelet-Version, die Sie verwenden können, 1.25.
-
Aktualisieren Sie die Cluster-Steuerebene mithilfe der AWS Konsole oder CLI.
-
Überprüfen Sie die Kompatibilität der Add-Ons. Aktualisieren Sie Ihre Kubernetes-Add-Ons und benutzerdefinierten Controller nach Bedarf.
-
Aktualisieren Sie die Cluster-Datenebene. Aktualisieren Sie Ihre Knoten auf dieselbe Kubernetes-Nebenversion wie Ihr aktualisiertes Cluster.
Verwenden Sie die EKS Dokumentation, um eine Upgrade-Checkliste zu erstellen
Die Dokumentation zur EKS Kubernetes-Version enthält eine detaillierte Liste der Änderungen für jede Version. Erstellen Sie für jedes Upgrade eine Checkliste.
Spezifische Anleitungen zum EKS Versionsupgrade finden Sie in der Dokumentation zu den wichtigsten Änderungen und Überlegungen zu den einzelnen Versionen.
Aktualisieren Sie Add-Ons und Komponenten mithilfe von Kubernetes API
Bevor Sie einen Cluster aktualisieren, sollten Sie wissen, welche Versionen der Kubernetes-Komponenten Sie verwenden. Inventarisieren Sie die Cluster-Komponenten und identifizieren Sie Komponenten, die API Kubernetes direkt verwenden. Dazu gehören wichtige Cluster-Komponenten wie Überwachungs- und Logging-Agenten, Cluster-Autoscaler, Container-Speichertreiber (z. B. EFSCSI) EBSCSI, Ingress-Controller und alle anderen Workloads oder Add-Ons, die direkt auf Kubernetes angewiesen sind. API
Tipp
Kritische Cluster-Komponenten werden häufig in einem Namespace installiert *-system
kubectl get ns | grep '-system'
Sobald Sie Komponenten identifiziert haben, die auf Kubernetes basierenAPI, überprüfen Sie deren Dokumentation auf Versionskompatibilität und Upgrade-Anforderungen. Informationen zur Versionskompatibilität finden Sie beispielsweise in der AWSLoad Balancer Controller-Dokumentation
Cluster enthalten oft viele Workloads, die Kubernetes verwenden API und für Workload-Funktionen wie Ingress-Controller, Continuous-Delivery-Systeme und Überwachungstools erforderlich sind. Wenn Sie einen EKS Cluster aktualisieren, müssen Sie auch Ihre Add-Ons und Tools von Drittanbietern aktualisieren, um sicherzustellen, dass sie kompatibel sind.
Sehen Sie sich die folgenden Beispiele für gängige Add-Ons und die entsprechende Upgrade-Dokumentation an:
-
Amazon VPCCNI: Die empfohlene Version des VPC CNI Amazon-Add-ons für jede Cluster-Version finden Sie unter Aktualisieren des VPC CNI Amazon-Plug-ins für das selbstverwaltete Kubernetes-Add-on. Wenn es als EKS Amazon-Add-on installiert wird, kann es jeweils nur für eine Nebenversion aktualisiert werden.
-
kube-proxy: Weitere Informationen finden Sie unter Aktualisierung des selbstverwalteten Kubernetes-Kube-Proxy-Add-ons.
-
CoreDNS: Siehe Aktualisierung des selbstverwalteten Core-Add-ons. DNS
-
AWSLoad Balancer Controller: Der Load AWS Balancer Controller muss mit der von Ihnen bereitgestellten EKS Version kompatibel sein. Weitere Informationen finden Sie in der Installationsanleitung.
-
Amazon Elastic Block Store (AmazonEBS) Container Storage Interface (CSI) -Treiber: Informationen zur Installation und zum Upgrade finden Sie unter Den EBS CSI Amazon-Treiber als EKS Amazon-Add-on verwalten.
-
Treiber für das Amazon Elastic File System (AmazonEFS) Container Storage Interface (CSI): Informationen zur Installation und zum Upgrade finden Sie unter EFSCSIAmazon-Treiber.
-
Kubernetes Metrics Server: Weitere Informationen finden Sie unter metrics-server
on. GitHub -
Kubernetes Cluster Autoscaler: Um die Version von Kubernetes Cluster Autoscaler zu aktualisieren, ändern Sie die Version des Images in der Bereitstellung. Der Cluster Autoscaler ist eng mit dem Kubernetes-Scheduler verbunden. Sie müssen ihn immer aktualisieren, wenn Sie den Cluster aktualisieren. Überprüfen Sie die GitHub Versionen
, um die Adresse der neuesten Version zu finden, die Ihrer Kubernetes-Nebenversion entspricht. -
Karpenter: Informationen zur Installation und zum Upgrade finden Sie in der Karpenter-Dokumentation.
Überprüfen Sie vor dem Upgrade die grundlegenden Anforderungen EKS
AWSbenötigt bestimmte Ressourcen in Ihrem Konto, um den Upgrade-Vorgang abzuschließen. Wenn diese Ressourcen nicht vorhanden sind, kann der Cluster nicht aktualisiert werden. Für ein Upgrade der Steuerungsebene sind die folgenden Ressourcen erforderlich:
-
Verfügbare IP-Adressen: Amazon EKS benötigt bis zu fünf verfügbare IP-Adressen aus den Subnetzen, die Sie bei der Erstellung des Clusters angegeben haben, um den Cluster zu aktualisieren. Falls nicht, aktualisieren Sie Ihre Cluster-Konfiguration, sodass sie neue Cluster-Subnetze enthält, bevor Sie das Versionsupdate durchführen.
-
EKSIAMRolle: Die IAM Rolle der Steuerungsebene ist immer noch im Konto vorhanden und verfügt über die erforderlichen Berechtigungen.
-
Wenn in Ihrem Cluster die geheime Verschlüsselung aktiviert ist, stellen Sie sicher, dass die IAM Clusterrolle berechtigt ist, den AWS Key Management Service (AWSKMS) -Schlüssel zu verwenden.
Überprüfen Sie die verfügbaren IP-Adressen
Um den Cluster zu aktualisieren, EKS benötigt Amazon bis zu fünf verfügbare IP-Adressen aus den Subnetzen, die Sie bei der Erstellung Ihres Clusters angegeben haben.
Um zu überprüfen, ob Ihre Subnetze über genügend IP-Adressen für ein Upgrade des Clusters verfügen, können Sie den folgenden Befehl ausführen:
CLUSTER=<cluster name> aws ec2 describe-subnets --subnet-ids \ $(aws eks describe-cluster --name ${CLUSTER} \ --query 'cluster.resourcesVpcConfig.subnetIds' \ --output text) \ --query 'Subnets[*].[SubnetId,AvailabilityZone,AvailableIpAddressCount]' \ --output table ---------------------------------------------------- | DescribeSubnets | +---------------------------+--------------+-------+ | subnet-067fa8ee8476abbd6 | us-east-1a | 8184 | | subnet-0056f7403b17d2b43 | us-east-1b | 8153 | | subnet-09586f8fb3addbc8c | us-east-1a | 8120 | | subnet-047f3d276a22c6bce | us-east-1b | 8184 | +---------------------------+--------------+-------+
Der VPCCNIMetrics Helper
-
gehören zu derselben Gruppe von AZs denen, die bei der Clustererstellung ausgewählt wurden.
-
gehören zu den gleichen, die bei der Clustererstellung VPC angegeben wurden
Bitte erwägen Sie, zusätzliche CIDR Blöcke zuzuordnen, falls die IP-Adressen im vorhandenen VPC CIDR Block aufgebraucht sind. AWSermöglicht die Zuordnung zusätzlicher CIDR Blöcke zu Ihrem vorhandenen ClusterVPC, wodurch Ihr IP-Adresspool effektiv erweitert wird. Diese Erweiterung kann durch die Einführung zusätzlicher privater IP-Bereiche (RFC1918) oder, falls erforderlich, öffentlicher IP-Bereiche (nicht RFC 1918) erreicht werden. Sie müssen neue VPC CIDR Blöcke hinzufügen und warten, bis die VPC Aktualisierung abgeschlossen ist, bevor Amazon die neuen verwenden EKS kannCIDR. Danach können Sie die Subnetze auf der Grundlage der neu eingerichteten CIDR Blöcke auf die VPC aktualisieren.
Überprüfen Sie die Rolle EKS IAM
Um zu überprüfen, ob die IAM Rolle verfügbar ist und in Ihrem Konto über die korrekte Richtlinie „Rolle annehmen“ verfügt, können Sie die folgenden Befehle ausführen:
CLUSTER=<cluster name> ROLE_ARN=$(aws eks describe-cluster --name ${CLUSTER} \ --query 'cluster.roleArn' --output text) aws iam get-role --role-name ${ROLE_ARN##*/} \ --query 'Role.AssumeRolePolicyDocument' { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
Migrieren Sie zu EKS Add-Ons
Amazon installiert EKS automatisch Add-Ons wie das VPC CNI Amazon-Plugin für Kubernetes und Core DNS für jeden Cluster. kube-proxy Add-Ons können selbst verwaltet oder als EKS Amazon-Add-Ons installiert werden. Amazon EKS Add-ons ist eine alternative Möglichkeit, Add-Ons mithilfe von zu verwalten EKSAPI.
Sie können Amazon EKS Add-ons verwenden, um Versionen mit einem einzigen Befehl zu aktualisieren. Beispiel:
aws eks update-addon —cluster-name my-cluster —addon-name vpc-cni —addon-version version-number \ --service-account-role-arn arn:aws:iam::111122223333:role/role-name —configuration-values '{}' —resolve-conflicts PRESERVE
Prüfen Sie, ob Sie irgendwelche EKS Add-Ons haben mit:
aws eks list-addons --cluster-name <cluster name>
Warnung
EKSAdd-Ons werden während eines Upgrades der Steuerungsebene nicht automatisch aktualisiert. Sie müssen EKS Add-On-Updates initiieren und die gewünschte Version auswählen.
-
Sie sind dafür verantwortlich, aus allen verfügbaren Versionen eine kompatible Version auszuwählen. Lesen Sie die Hinweise zur Kompatibilität von Add-On-Versionen.
-
Amazon EKS Add-ons können jeweils nur für eine Nebenversion aktualisiert werden.
Erfahren Sie, wie Sie einem EKS Add-on eine benutzerdefinierte Konfiguration zur Verfügung stellen.
Identifizieren und korrigieren Sie die fehlende API Nutzung, bevor Sie die Steuerungsebene aktualisieren
APIsBevor Sie Ihre EKS Steuerungsebene aufrüsten, sollten Sie die API Nutzung von removed ermitteln. Zu diesem Zweck empfehlen wir die Verwendung von Tools, die einen laufenden Cluster oder statische, gerenderte Kubernetes-Manifestdateien überprüfen können.
Die Prüfung anhand statischer Manifestdateien durchzuführen, ist im Allgemeinen genauer. Wenn diese Tools auf Live-Clustern ausgeführt werden, geben sie möglicherweise falsch positive Ergebnisse zurück.
Ein veraltetes Kubernetes API bedeutet nicht, dass es entfernt wurde. API Sie sollten sich die Richtlinien für veraltete Kubernetes-Versionen ansehen, um zu erfahren, wie sich die Entfernung auf Ihre Workloads auswirkt
Einblicke in Cluster
Cluster Insights ist eine Funktion, die Erkenntnisse zu Problemen liefert, die sich auf die Möglichkeit auswirken können, einen EKS Cluster auf neuere Versionen von Kubernetes zu aktualisieren. Diese Ergebnisse werden von Amazon kuratiert EKS und verwaltet und bieten Empfehlungen zu deren Behebung. Durch die Nutzung von Cluster Insights können Sie den Aufwand für ein Upgrade auf neuere Kubernetes-Versionen minimieren.
Um Einblicke in einen EKS Cluster zu erhalten, können Sie den folgenden Befehl ausführen:
aws eks list-insights --region <region-code> --cluster-name <my-cluster> { "insights": [ { "category": "UPGRADE_READINESS", "name": "Deprecated APIs removed in Kubernetes v1.29", "insightStatus": { "status": "PASSING", "reason": "No deprecated API usage detected within the last 30 days." }, "kubernetesVersion": "1.29", "lastTransitionTime": 1698774710.0, "lastRefreshTime": 1700157422.0, "id": "123e4567-e89b-42d3-a456-579642341238", "description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes v1.29. Upgrading your cluster before migrating to the updated APIs supported by v1.29 could cause application impact." } ] }
Für eine aussagekräftigere Ausgabe der erhaltenen Erkenntnisse können Sie den folgenden Befehl ausführen:
aws eks describe-insight --region <region-code> --id <insight-id> --cluster-name <my-cluster>
Sie haben auch die Möglichkeit, Einblicke in der EKSAmazon-Konsole einzusehenUpgrade Insights Registerkarte.
Wenn Sie einen Cluster-Einblick bei finden"status": ERROR, müssen Sie das Problem beheben, bevor Sie das Cluster-Upgrade durchführen. Führen Sie den aws eks describe-insight Befehl aus, der Ihnen die folgenden Hinweise zur Problembehebung enthält:
Betroffene Ressourcen:
"resources": [ { "insightStatus": { "status": "ERROR" }, "kubernetesResourceUri": "/apis/policy/v1beta1/podsecuritypolicies/null" } ]
APIsveraltet:
"deprecationDetails": [ { "usage": "/apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas", "replacedWith": "/apis/flowcontrol.apiserver.k8s.io/v1beta3/flowschemas", "stopServingVersion": "1.29", "clientStats": [], "startServingReplacementVersion": "1.26" } ]
Empfohlene Maßnahme:
"recommendation": "Update manifests and API clients to use newer Kubernetes APIs if applicable before upgrading to Kubernetes v1.26."
Nutzen Sie Cluster-Einblicke über die EKS Konsole oder CLI beschleunigen Sie den Prozess der erfolgreichen Aktualisierung von EKS Cluster-Versionen. Weitere Informationen finden Sie in den folgenden Ressourcen: * Offizielle EKS Dokumente * Blog zum Start von Cluster Insights
K ube-no-trouble
K ube-no-troublekubent. Wenn Sie es kubent ohne Argumente ausführen, verwendet es Ihren aktuellen KubeConfig Kontext, scannt den Cluster und druckt einen Bericht mit dem, was veraltet ist und entfernt APIs wird.
kubent 4:17PM INF >>> Kube No Trouble `kubent` <<< 4:17PM INF version 0.7.0 (git sha d1bb4e5fd6550b533b2013671aa8419d923ee042) 4:17PM INF Initializing collectors and retrieving data 4:17PM INF Target K8s version is 1.24.8-eks-ffeb93d 4:l INF Retrieved 93 resources from collector name=Cluster 4:17PM INF Retrieved 16 resources from collector name="Helm v3" 4:17PM INF Loaded ruleset name=custom.rego.tmpl 4:17PM INF Loaded ruleset name=deprecated-1-16.rego 4:17PM INF Loaded ruleset name=deprecated-1-22.rego 4:17PM INF Loaded ruleset name=deprecated-1-25.rego 4:17PM INF Loaded ruleset name=deprecated-1-26.rego 4:17PM INF Loaded ruleset name=deprecated-future.rego __________________________________________________________________________________________ >>> Deprecated APIs removed in 1.25 <<< ------------------------------------------------------------------------------------------ KIND NAMESPACE NAME API_VERSION REPLACE_WITH (SINCE) PodSecurityPolicy <undefined> eks.privileged policy/v1beta1 <removed> (1.21.0)
Es kann auch verwendet werden, um statische Manifestdateien und Helm-Pakete zu scannen. Es wird empfohlen, es im kubent Rahmen eines Continuous Integration (CI) -Prozesses zu verwenden, um Probleme zu identifizieren, bevor die Manifeste bereitgestellt werden. Das Scannen von Manifesten ist auch genauer als das Scannen von Live-Clustern.
Kube-no-trouble bietet ein Beispiel für ein Dienstkonto und eine Rolle
Pluto
Eine weitere Option ist Plutokubent weil es das Scannen eines Live-Clusters, von Manifestdateien und Helmdiagrammen unterstützt und über eine GitHub Aktion verfügt, die Sie in Ihren CI-Prozess aufnehmen können.
pluto detect-all-in-cluster NAME KIND VERSION REPLACEMENT REMOVED DEPRECATED REPL AVAIL eks.privileged PodSecurityPolicy policy/v1beta1 false true true
Ressourcen
Um APIs vor dem Upgrade sicherzustellen, dass Ihr Cluster keine veralteten Versionen verwendet, sollten Sie Folgendes überwachen:
-
Metrik
apiserver_requested_deprecated_apisseit Kubernetes v1.19:
kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis apiserver_requested_deprecated_apis{group="policy",removed_release="1.25",resource="podsecuritypolicies",subresource="",version="v1beta1"} 1
-
Ereignisse in den Audit-Logs mit
k8s.io/deprecatedfolgender Einstellung:true
CLUSTER="<cluster_name>" QUERY_ID=$(aws logs start-query \ --log-group-name /aws/eks/${CLUSTER}/cluster \ --start-time $(date -u --date="-30 minutes" "+%s") # or date -v-30M "+%s" on MacOS \ --end-time $(date "+%s") \ --query-string 'fields @message | filter `annotations.k8s.io/deprecated`="true"' \ --query queryId --output text) echo "Query started (query id: $QUERY_ID), please hold ..." && sleep 5 # give it some time to query aws logs get-query-results --query-id $QUERY_ID
Was gibt Zeilen aus, wenn sie verwendet werden, wenn sie veraltet APIs sind:
{ "results": [ [ { "field": "@message", "value": "{\"kind\":\"Event\",\"apiVersion\":\"audit.k8s.io/v1\",\"level\":\"Request\",\"auditID\":\"8f7883c6-b3d5-42d7-967a-1121c6f22f01\",\"stage\":\"ResponseComplete\",\"requestURI\":\"/apis/policy/v1beta1/podsecuritypolicies?allowWatchBookmarks=true\\u0026resourceVersion=4131\\u0026timeout=9m19s\\u0026timeoutSeconds=559\\u0026watch=true\",\"verb\":\"watch\",\"user\":{\"username\":\"system:apiserver\",\"uid\":\"8aabfade-da52-47da-83b4-46b16cab30fa\",\"groups\":[\"system:masters\"]},\"sourceIPs\":[\"::1\"],\"userAgent\":\"kube-apiserver/v1.24.16 (linux/amd64) kubernetes/af930c1\",\"objectRef\":{\"resource\":\"podsecuritypolicies\",\"apiGroup\":\"policy\",\"apiVersion\":\"v1beta1\"},\"responseStatus\":{\"metadata\":{},\"code\":200},\"requestReceivedTimestamp\":\"2023-10-04T12:36:11.849075Z\",\"stageTimestamp\":\"2023-10-04T12:45:30.850483Z\",\"annotations\":{\"authorization.k8s.io/decision\":\"allow\",\"authorization.k8s.io/reason\":\"\",\"k8s.io/deprecated\":\"true\",\"k8s.io/removed-release\":\"1.25\"}}" }, [...]
Aktualisieren Sie Kubernetes-Workloads. Verwenden Sie kubectl-convert, um Manifeste zu aktualisieren
Nachdem Sie festgestellt haben, welche Workloads und Manifeste aktualisiert werden müssen, müssen Sie möglicherweise den Ressourcentyp in Ihren Manifestdateien ändern (z. B. in). PodSecurityPolicies PodSecurityStandards Dies erfordert eine Aktualisierung der Ressourcenspezifikation und zusätzliche Nachforschungen, je nachdem, welche Ressource ersetzt wird.
Wenn der Ressourcentyp gleich bleibt, aber die API Version aktualisiert werden muss, können Sie den kubectl-convert Befehl verwenden, um Ihre Manifestdateien automatisch zu konvertieren. Zum Beispiel, um ein älteres Deployment zu zu konvertierenapps/v1. Weitere Informationen finden Sie unter Installieren des kubectl convert-Plugins
kubectl-convert -f <file> --output-version <group>/<version>
Konfigurieren Sie Ihre Workloads PodDisruptionBudgets und topologySpreadConstraints stellen Sie deren Verfügbarkeit sicher, während die Datenebene aktualisiert wird
Stellen Sie sicher, dass Ihre Workloads über die richtigen PodDisruptionBudgets
Wenn Sie sicherstellen, dass Workloads auf mehrere Availability Zones und auf mehrere Hosts mit Topologieverteilungen verteilt sind, können Sie sich darauf verlassen, dass Workloads automatisch und ohne Zwischenfälle auf die neue Datenebene migriert werden.
Hier ist ein Beispiel für einen Workload, bei dem immer 80% der Replikate verfügbar sind und die Replikate auf Zonen und Hosts verteilt sind
apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: myapp spec: minAvailable: "80%" selector: matchLabels: app: myapp --- apiVersion: apps/v1 kind: Deployment metadata: name: myapp spec: replicas: 10 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - image: public.ecr.aws/eks-distro/kubernetes/pause:3.2 name: myapp resources: requests: cpu: "1" memory: 256M topologySpreadConstraints: - labelSelector: matchLabels: app: host-zone-spread maxSkew: 2 topologyKey: kubernetes.io/hostname whenUnsatisfiable: DoNotSchedule - labelSelector: matchLabels: app: host-zone-spread maxSkew: 2 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule
AWSResilience Hub
Verwenden Sie Managed Node Groups oder Karpenter, um Upgrades auf Datenebene zu vereinfachen
Managed Node Groups und Karpenter vereinfachen beide Knoten-Upgrades, verfolgen jedoch unterschiedliche Ansätze.
Verwaltete Knotengruppen automatisieren die Bereitstellung und das Lebenszyklusmanagement von Knoten. Das bedeutet, dass Sie Knoten mit einem einzigen Vorgang erstellen, automatisch aktualisieren oder beenden können.
In der Standardkonfiguration erstellt Karpenter automatisch neue Knoten unter Verwendung der neuesten kompatiblen EKS Version von Optimized. AMI Wenn EKS Versionen aktualisiert wurden, EKS Optimized AMIs oder der Cluster aktualisiert wird, verwendet Karpenter automatisch diese Images. Karpenter implementiert auch Node Expiry, um Knoten zu aktualisieren.
Karpenter kann so konfiguriert werden, dass es benutzerdefiniert verwendet wird. AMIs
Bestätigen Sie die Versionskompatibilität mit vorhandenen Knoten und der Steuerungsebene
Bevor Sie mit einem Kubernetes-Upgrade in Amazon fortfahrenEKS, müssen Sie unbedingt die Kompatibilität zwischen Ihren verwalteten Knotengruppen, selbstverwalteten Knoten und der Kontrollebene sicherstellen. Die Kompatibilität hängt von der Kubernetes-Version ab, die Sie verwenden, und sie variiert je nach Szenario. Taktik:
-
Kubernetes v1.28+ — * * Ab Kubernetes Version 1.28 und höher gibt es eine mildere Versionsrichtlinie für Kernkomponenten. Insbesondere wurde der unterstützte Unterschied zwischen dem API Kubernetes-Server und dem Kubelet um eine Nebenversion erweitert, und zwar von n-2 auf n-3. Wenn Ihre EKS Control-Plane-Version beispielsweise 1.28 ist, können Sie problemlos Kubelet-Versionen verwenden, die so alt sind wie 1.25. Dieser Versionsversatz wird in AWSFargate, verwalteten Knotengruppen und selbstverwalteten Knoten unterstützt. Aus Sicherheitsgründen empfehlen wir dringend, Ihre Amazon Machine Image (AMI) up-to-date -Versionen beizubehalten. Ältere Kubelet-Versionen können aufgrund potenzieller allgemeiner Sicherheitslücken und Risiken (CVEs) Sicherheitsrisiken bergen, die die Vorteile der Verwendung älterer Kubelet-Versionen überwiegen könnten.
-
Kubernetes < v1.28 — Wenn Sie eine ältere Version als v1.28 verwenden, beträgt der unterstützte Unterschied zwischen dem Server und dem Kubelet n-2. API Wenn Ihre EKS Version beispielsweise 1.27 ist, ist die älteste Kubelet-Version, die Sie verwenden können, 1.25. Dieser Versionsunterschied gilt für AWSFargate, verwaltete Knotengruppen und selbstverwaltete Knoten.
Aktivieren Sie das Ablaufen von Knoten für von Karpenter verwaltete Knoten
Eine Möglichkeit, wie Karpenter Knoten-Upgrades implementiert, ist die Verwendung des Konzepts des Ablaufs von Knoten. Dadurch wird der Planungsaufwand für Knoten-Upgrades reduziert. Wenn Sie in Ihrem Provisioner einen Wert für ttlSecondsUntilAbgelaufen festlegen, wird dadurch das Ablaufen des Knotens aktiviert. Sobald Knoten innerhalb von Sekunden das definierte Alter erreicht haben, werden sie sicher entleert und gelöscht. Dies gilt auch dann, wenn sie verwendet werden, sodass Sie Knoten durch neu bereitgestellte, aktualisierte Instanzen ersetzen können. Wenn ein Knoten ersetzt wird, verwendet Karpenter den neuesten — optimierten. EKS AMIs Weitere Informationen finden Sie unter Deprovisioning
Karpenter fügt diesem Wert nicht automatisch Jitter hinzu. Um übermäßige Unterbrechungen der Arbeitslast zu vermeiden, definieren Sie ein Budget für Pod-Unterbrechungen
Wenn Sie ttlSecondsUntilExpired auf einem Provisioner konfigurieren, gilt dies für bestehende Knoten, die dem Provisioner zugeordnet sind.
Verwenden Sie die Drift-Funktion für von Karpenter verwaltete Knoten
Die Drift-Funktion von Karpenter
Nach Abschluss eines EKS Cluster-Upgrades erkennt die Drift-Funktion von Karpenter, dass die von Karpenter bereitgestellten Knoten EKS -Optimized AMIs für die vorherige Cluster-Version verwenden, und sperrt, entleert und ersetzt diese Knoten automatisch. Um die Migration von Pods auf neue Knoten zu unterstützen, folgen Sie den bewährten Methoden von Kubernetes, indem Sie entsprechende Pod-Ressourcenkontingente
Verwenden Sie eksctl, um Upgrades für selbstverwaltete Knotengruppen zu automatisieren
Selbstverwaltete Knotengruppen sind EC2 Instanzen, die in Ihrem Konto bereitgestellt und außerhalb des Dienstes an den Cluster angehängt wurden. EKS Diese werden in der Regel mithilfe von Automatisierungstools bereitgestellt und verwaltet. Informationen zum Upgrade von selbstverwalteten Knotengruppen finden Sie in der Dokumentation zu Ihren Tools.
eksctl unterstützt beispielsweise das Löschen und Entleeren
Zu den gängigen Tools gehören:
Backup den Cluster vor dem Upgrade
Neue Versionen von Kubernetes führen zu erheblichen Änderungen an Ihrem EKS Amazon-Cluster. Nachdem Sie einen Cluster aktualisiert haben, können Sie ihn nicht mehr herabstufen.
Velero
Beachten Sie, dass Sie nur neue Cluster für Kubernetes-Versionen erstellen können, die derzeit von unterstützt werden. EKS Wenn die Version, die Ihr Cluster derzeit ausführt, weiterhin unterstützt wird und ein Upgrade fehlschlägt, können Sie einen neuen Cluster mit der Originalversion erstellen und die Datenebene wiederherstellen. Beachten Sie, dass AWS Ressourcen, einschließlichIAM, nicht im Backup von Velero enthalten sind. Diese Ressourcen müssten neu erstellt werden.
Starten Sie die Fargate-Bereitstellungen nach dem Upgrade der Steuerungsebene neu
Um die Fargate-Datenebenenknoten zu aktualisieren, müssen Sie die Workloads erneut bereitstellen. Sie können feststellen, welche Workloads auf Fargate-Knoten ausgeführt werden, indem Sie alle Pods mit der Option auflisten. -o wide Jeder Knotenname, der mit fargate- beginnt, muss im Cluster erneut bereitgestellt werden.
Evaluieren Sie Blue/Green-Cluster als Alternative zu direkten Cluster-Upgrades
Einige Kunden bevorzugen eine blaue/grüne Upgrade-Strategie. Dies kann Vorteile haben, beinhaltet aber auch Nachteile, die berücksichtigt werden sollten.
Zu den Vorteilen gehören:
-
Es ist möglich, mehrere EKS Versionen gleichzeitig zu ändern (z. B. 1.23 auf 1.25)
-
Kann zum alten Cluster zurückkehren
-
Erzeugt einen neuen Cluster, der mit neueren Systemen (z. B. Terraform) verwaltet werden kann
-
Workloads können einzeln migriert werden
Zu den Nachteilen gehören:
-
APIEndpunkt und OIDC Änderung, für die die Benutzer aktualisiert werden müssen (z. B. kubectl und CI/CD)
-
Erfordert, dass während der Migration 2 Cluster parallel ausgeführt werden, was teuer sein und die Kapazität der Region einschränken kann
-
Wenn Workloads voneinander abhängen und gemeinsam migriert werden müssen, ist mehr Koordination erforderlich
-
Load Balancer und externe Dienste können sich DNS nicht einfach über mehrere Cluster erstrecken
Diese Strategie ist zwar möglich, aber sie ist teurer als ein Upgrade vor Ort und erfordert mehr Zeit für die Koordination und Workload-Migrationen. Sie kann in einigen Situationen erforderlich sein und sollte sorgfältig geplant werden.
Bei einem hohen Automatisierungsgrad und solchen GitOps deklarativen Systemen ist dies möglicherweise einfacher. Sie müssen zusätzliche Vorsichtsmaßnahmen für statusbehaftete Workloads treffen, sodass Daten gesichert und auf neue Cluster migriert werden.
Weitere Informationen finden Sie in diesen Blogbeiträgen:
Verfolgen Sie geplante größere Änderungen im Kubernetes-Projekt — denken Sie voraus
Schauen Sie sich nicht nur die nächste Version an. Überprüfen Sie neue Versionen von Kubernetes, sobald sie veröffentlicht werden, und identifizieren Sie wichtige Änderungen. Beispielsweise verwendeten einige Anwendungen den Docker direktAPI, und die Unterstützung für Container Runtime Interface (CRI) für Docker (auch bekannt als Dockershim) wurde in Kubernetes entfernt. 1.24 Diese Art von Änderung erfordert mehr Zeit, um sich darauf vorzubereiten.
Lesen Sie alle dokumentierten Änderungen für die Version, auf die Sie aktualisieren, und notieren Sie sich alle erforderlichen Upgrade-Schritte. Beachten Sie auch alle Anforderungen oder Verfahren, die für von Amazon EKS verwaltete Cluster spezifisch sind.
Spezifische Hinweise zum Entfernen von Funktionen
Entfernung von Dockershim in 1.25 — Detector für Docker Socket verwenden () DDS
EKSOptimized AMI for 1.25 beinhaltet keine Unterstützung mehr für Dockershim. Wenn Sie von Dockershim abhängig sind, z. B. wenn Sie den Docker-Socket mounten, müssen Sie diese Abhängigkeiten entfernen, bevor Sie Ihre Worker-Knoten auf 1.25 aktualisieren.
Suchen Sie nach Instanzen, in denen Sie vom Docker-Socket abhängig sind, bevor Sie auf 1.25 aktualisieren. Wir empfehlen die Verwendung von Detector for Docker Socket (DDS), einem
Entfernung von PodSecurityPolicy in 1.25 — Migration zu Pod-Sicherheitsstandards oder einer Lösung policy-as-code
PodSecurityPolicywar in Kubernetes 1.21 veraltet und wurde in Kubernetes 1.25
AWShat eine ausführliche in der Dokumentation veröffentlicht. FAQ EKS
Lesen Sie die bewährten Methoden für die Sicherheitsstandards für Pod (PSS) und die Zulassung von Pod Security (PSA)
Lesen Sie den Blogbeitrag PodSecurityPolicy Deprecation
Der In-Tree-Storage-Treiber in Version 1.23 ist veraltet — Migration zu Container-Storage-Interface-Treibern () CSI
Das Container Storage Interface (CSI) wurde entwickelt, um Kubernetes dabei zu unterstützen, seine bestehenden Treibermechanismen für In-Tree-Speicher zu ersetzen. Die Migrationsfunktion Amazon EBS Container Storage Interface (CSI) ist in Amazon EKS 1.23 und neueren Clustern standardmäßig aktiviert. Wenn Sie Pods auf einem Cluster der Version 1.22 oder einer früheren Version ausführen, müssen Sie den EBSCSIAmazon-Treiber installieren, bevor Sie Ihren Cluster auf Version aktualisieren, um Serviceunterbrechungen 1.23 zu vermeiden.
Lesen Sie die häufig gestellten Fragen zur EBS CSI Amazon-Migration.
Weitere Ressourcen
ClowdHaus EKSAnleitung zum Upgrade
ClowdHaus EKSDie Upgrade-Anleitung
GoNoGo
GoNoGo
📝 Bearbeiten Sie diese Seite auf GitHub
