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

Dieses Handbuch zeigt Cluster-Administratoren, wie sie ihre Amazon EKS-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 enthält keine Anleitungen zu EKS Anywhere, selbstverwaltetem Kubernetes, AWS-Außenposten oder lokalen AWS-Zonen.

-Ü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 wie 1.24 ausgeführt werden. Während AWS die Steuerungsebene verwaltet und aktualisiert, liegt die Aktualisierung der Worker-Knoten auf der Datenebene in Ihrer Verantwortung.

Vor dem Upgrade

Wenn Sie planen, Ihre Kubernetes-Version in Amazon EKS zu aktualisieren, sollten Sie einige wichtige Richtlinien, Tools und Verfahren einrichten, bevor Sie mit einem Upgrade beginnen.

Halten Sie Ihren Cluster auf dem neuesten Stand

Für eine sichere und effiziente EKS-Umgebung ist es von größter Bedeutung, über Kubernetes-Updates auf dem Laufenden zu bleiben, was das Modell der gemeinsamen Verantwortung in Amazon EKS widerspiegelt. Durch die Integration dieser Strategien in Ihren betrieblichen Arbeitsablauf sind Sie in der Lage, aktuelle, sichere Cluster zu verwalten, die die neuesten Funktionen und Verbesserungen voll ausschöpfen. Taktik:

Sehen Sie sich den EKS-Veröffentlichungskalender an

Lesen Sie den EKS Kubernetes-Veröffentlichungskalender, um zu erfahren, wann neue Versionen erscheinen und wann der Support für bestimmte Versionen endet. Im Allgemeinen veröffentlicht EKS jährlich drei Nebenversionen von Kubernetes, und jede Nebenversion wird etwa 14 Monate lang unterstützt.

Lesen Sie außerdem die Upstream-Kubernetes-Versionsinformationen.

Erfahren Sie, wie das Modell der gemeinsamen Verantwortung für Cluster-Upgrades gilt

Sie sind dafür verantwortlich, das Upgrade sowohl für die Cluster-Steuerungsebene als auch für die Datenebene zu initiieren. Erfahren Sie, wie Sie ein Upgrade einleiten. Wenn Sie ein Cluster-Upgrade initiieren, verwaltet AWS das Upgrade der Cluster-Steuerungsebene. Sie sind für die Aktualisierung der Datenebene verantwortlich, einschließlich der Fargate-Pods und Aktualisieren Sie Add-Ons und Komponenten mithilfe der Kubernetes-API -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

EKS unterstützt eine direkte Cluster-Upgrade-Strategie. Dadurch werden die Cluster-Ressourcen beibehalten und die Cluster-Konfiguration konsistent gehalten (z. B. API-Endpunkt, OIDC, ENIs, Load Balancer). Dies ist für Cluster-Benutzer weniger störend und nutzt die vorhandenen Workloads und Ressourcen im Cluster, ohne dass Sie Workloads erneut bereitstellen oder externe Ressourcen (z. B. DNS, Speicher) migrieren müssen.

Bei der Durchführung eines direkten Cluster-Upgrades ist zu beachten, dass jeweils nur ein Nebenversions-Upgrade 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 sequentiellen 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 nacheinander Ihre Steuerungsebene und Datenebene auf

Um einen Cluster zu aktualisieren, müssen Sie die folgenden Maßnahmen ergreifen:

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.

Anleitungen zur Aktualisierung bestimmter EKS-Versionen finden Sie in der Dokumentation für jede Version auf wichtige Änderungen und Überlegungen.

Aktualisieren Sie Add-Ons und Komponenten mithilfe der Kubernetes-API

Bevor Sie einen Cluster aktualisieren, sollten Sie wissen, welche Versionen der Kubernetes-Komponenten Sie verwenden. Inventarisieren Sie Cluster-Komponenten und identifizieren Sie Komponenten, die die Kubernetes-API direkt verwenden. Dazu gehören wichtige Cluster-Komponenten wie Überwachungs- und Logging-Agents, Cluster-Autoscaler, Container-Speichertreiber (z. B. EBS CSI, EFS CSI), Ingress-Controller und alle anderen Workloads oder Add-Ons, die direkt auf der Kubernetes-API basieren.

kubectl get ns | grep '-system'

Nachdem Sie Komponenten identifiziert haben, die die Kubernetes-API verwenden, überprüfen Sie deren Dokumentation auf Versionskompatibilität und Upgrade-Anforderungen. Informationen zur Versionskompatibilität finden Sie beispielsweise in der Dokumentation zum AWS Load Balancer Controller. Einige Komponenten müssen möglicherweise aktualisiert oder die Konfiguration geändert werden, bevor mit einem Cluster-Upgrade fortgefahren werden kann. Zu den wichtigsten Komponenten, die überprüft werden müssen, gehören CoreDNS, Kube-Proxy, VPC CNI und Speichertreiber.

Cluster enthalten oft viele Workloads, die die Kubernetes-API verwenden und für Workload-Funktionen wie Eingangskontrollen, 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 gängiger Add-Ons und die entsprechende Upgrade-Dokumentation an:

Überprüfen Sie vor dem Upgrade die grundlegenden EKS-Anforderungen

AWS benö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:

Überprüfen Sie die verfügbaren IP-Adressen

Um den Cluster zu aktualisieren, benötigt Amazon EKS bis zu fünf verfügbare IP-Adressen aus den Subnetzen, die beim Erstellen des Clusters bereitgestellt wurden.

Um zu überprüfen, ob Ihre Subnetze über genügend IP-Adressen verfügen, um den Cluster zu aktualisieren, 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 VPC CNI Metrics Helper kann verwendet werden, um ein CloudWatch Dashboard für VPC-Metriken zu erstellen. Amazon EKS empfiehlt, die Cluster-Subnetze vor Beginn eines Kubernetes-Versions-Upgrades mithilfe der API zu aktualisieren, wenn Ihnen die IP-Adressen in den Subnetzen ausgehen, die ursprünglich bei der Cluster-Erstellung angegeben wurden. UpdateClusterConfiguration Bitte stellen Sie sicher, dass die neuen Subnetze Ihnen zur Verfügung gestellt werden:

Bitte erwägen Sie, weitere CIDR-Blöcke zuzuordnen, falls die IP-Adressen im vorhandenen VPC-CIDR-Block aufgebraucht sind. AWS ermöglicht die Verknüpfung zusätzlicher CIDR-Blöcke mit Ihrer vorhandenen Cluster-VPC, wodurch Ihr IP-Adresspool effektiv erweitert wird. Diese Erweiterung kann durch die Einführung zusätzlicher privater IP-Bereiche (RFC 1918) oder, falls erforderlich, öffentlicher IP-Bereiche (nicht RFC 1918) erreicht werden. Sie müssen neue VPC-CIDR-Blöcke hinzufügen und zulassen, dass die VPC-Aktualisierung abgeschlossen ist, bevor Amazon EKS das neue CIDR verwenden kann. Danach können Sie die Subnetze auf der Grundlage der neu eingerichteten CIDR-Blöcke für die VPC aktualisieren.

Überprüfen Sie die EKS-IAM-Rolle

Um zu überprüfen, ob die IAM-Rolle verfügbar ist und in Ihrem Konto die richtige Richtlinie zum Annehmen der Rolle verwendet wird, 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 EKS installiert automatisch Add-Ons wie das Amazon VPC CNI-Plugin für Kubernetes und CoreDNS für jeden kube-proxy Cluster. Add-ons kann selbst verwaltet oder als Amazon EKS installiert werden. Add-ons Amazon EKS Add-ons ist eine alternative Methode zur Verwaltung von Add-Ons mithilfe der EKS-API.

Sie können Amazon EKS verwenden Add-ons , um Versionen mit einem einzigen Befehl zu aktualisieren. Zum 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 EKS haben Add-ons mit:

aws eks list-addons --cluster-name <cluster name>

Erfahren Sie mehr darüber Add-ons, welche Komponenten als EKS verfügbar sind und wie Sie loslegen können.

Erfahren Sie, wie Sie einem EKS eine benutzerdefinierte Konfiguration bereitstellen Add-on.

Identifizieren und korrigieren Sie die entfernte API-Nutzung, bevor Sie die Steuerungsebene aktualisieren

Sie sollten die API-Nutzung der entfernten APIs ermitteln, bevor Sie Ihre EKS-Steuerungsebene aktualisieren. Dazu empfehlen wir die Verwendung von Tools, die einen laufenden Cluster oder statische, gerenderte Kubernetes-Manifestdateien überprüfen können.

Die Überprüfung anhand statischer Manifestdateien ist im Allgemeinen genauer. Wenn diese Tools für Live-Cluster ausgeführt werden, geben sie möglicherweise falsch positive Ergebnisse zurück.

Eine veraltete Kubernetes-API bedeutet nicht, dass die API entfernt wurde. Sie sollten die Kubernetes-Deprecation Policy überprüfen, um zu verstehen, wie sich das Entfernen der API auf Ihre Workloads auswirkt.

Einblicke in Cluster-Umgebungen

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 EKS kuratiert und verwaltet und enthalten 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 anzuzeigen, 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 über die 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 Amazon EKS-Konsole anzuzeigen. Nachdem Sie Ihren Cluster aus der Cluster-Liste ausgewählt haben, befinden sich die Insight-Ergebnisse unter dem Upgrade Insights Tab.

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 die folgenden Hinweise zur Problembehebung enthält:

Betroffene Ressourcen:

"resources": [
      {
        "insightStatus": {
          "status": "ERROR"
        },
        "kubernetesResourceUri": "/apis/policy/v1beta1/podsecuritypolicies/null"
      }
]

APIs sind veraltet:

"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ßnahmen:

"recommendation": "Update manifests and API clients to use newer Kubernetes APIs if applicable before upgrading to Kubernetes v1.26."

Die Nutzung von Cluster-Erkenntnissen über die EKS-Konsole oder die CLI trägt dazu bei, den Prozess der erfolgreichen Aktualisierung von EKS-Cluster-Versionen zu beschleunigen. Erfahren Sie mehr mit den folgenden Ressourcen: * Offizielle EKS-Dokumente * Blog zur Einführung von Cluster Insights.

Kube-no-trouble

Kube-no-troubleist ein Open-Source-Befehlszeilenprogramm mit dem Befehlkubent. Wenn Sie es kubent ohne Argumente ausführen, verwendet es Ihren aktuellen KubeConfig Kontext und scannt den Cluster und druckt einen Bericht aus, in dem angegeben wird, welche APIs veraltet sind und entfernt werden.

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 Helmpakete zu scannen. Es wird empfohlen, ihn im kubent Rahmen eines CI-Prozesses (Continuous Integration) auszuführen, um Probleme zu identifizieren, bevor 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 mit den entsprechenden Berechtigungen zum Scannen des Clusters.

Pluto

Eine weitere Option ist Pluto, das ähnlich ist, kubent 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 einbeziehen 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 sicherzustellen, dass Ihr Cluster vor dem Upgrade keine veralteten APIs verwendet, sollten Sie Folgendes überwachen:

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

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

Dadurch werden Zeilen ausgegeben, wenn veraltete APIs verwendet werden:

{
    "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 die 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 Recherchen, je nachdem, welche Ressource ersetzt wird.

Wenn der Ressourcentyp unverändert bleibt, die API-Version jedoch aktualisiert werden muss, können Sie den kubectl-convert Befehl verwenden, um Ihre Manifestdateien automatisch zu konvertieren. Zum Beispiel, um ein älteres Deployment in zu konvertierenapps/v1. Weitere Informationen finden Sie unter Installieren des Kubectl-Convert-Plugins auf der Kubernetes-Website.

kubectl-convert -f <file> --output-version <group>/<version>

Konfigurieren Sie PodDisruptionBudgets eine TopologieSpreadConstraints , um die Verfügbarkeit Ihrer Workloads sicherzustellen, während die Datenebene aktualisiert wird

Stellen Sie sicher, dass Ihre Workloads über die richtige PodDisruptionBudgets Topologie verfügen SpreadConstraints, um die Verfügbarkeit Ihrer Workloads während des Upgrades der Datenebene sicherzustellen. Nicht jeder Workload erfordert das gleiche Verfügbarkeitsniveau, daher müssen Sie den Umfang und die Anforderungen Ihrer Workloads überprüfen.

Stellen Sie sicher, dass die Workloads auf mehrere Availability Zones und auf mehrere Hosts verteilt sind. Topologie-Spreads bieten ein höheres Maß an Sicherheit, 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 werden

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

AWS Resilience Hub hat Amazon Elastic Kubernetes Service (Amazon EKS) als unterstützte Ressource hinzugefügt. Resilience Hub bietet einen zentralen Ort, an dem Sie die Resilienz Ihrer Anwendungen definieren, validieren und verfolgen können, sodass Sie unnötige Ausfallzeiten aufgrund von Software-, Infrastruktur- oder Betriebsunterbrechungen vermeiden können.

Verwenden Sie Managed Node Groups oder Karpenter, um die Aktualisierung der Datenebene zu vereinfachen

Managed Node Groups und Karpenter vereinfachen beide Node-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 mit dem neuesten kompatiblen EKS-Optimized AMI. Wenn EKS aktualisierte EKS-optimierte AMIs veröffentlicht oder der Cluster aktualisiert wird, beginnt Karpenter automatisch, diese Images zu verwenden. Karpenter implementiert auch Node Expiry, um Knoten zu aktualisieren.

Karpenter kann so konfiguriert werden, dass benutzerdefinierte AMIs verwendet werden. Wenn Sie benutzerdefinierte AMIs mit Karpenter verwenden, sind Sie für die Version von Kubelet verantwortlich.

Bestätigen Sie die Versionskompatibilität mit vorhandenen Knoten und der Steuerungsebene

Bevor Sie mit einem Kubernetes-Upgrade in Amazon EKS fortfahren, müssen Sie unbedingt die Kompatibilität zwischen Ihren verwalteten Knotengruppen, selbstverwalteten Knoten und der Steuerungsebene sicherstellen. Die Kompatibilität hängt von der Kubernetes-Version ab, die Sie verwenden, und sie variiert je nach Szenario. Taktik:

Aktivieren Sie das Ablaufen von Knoten für von Karpenter verwaltete Knoten

Eine Möglichkeit, wie Karpenter Node-Upgrades implementiert, ist das Konzept des Ablaufs von Knoten. Dies reduziert den Planungsaufwand für Node-Upgrades. Wenn Sie SecondsUntilExpired in Ihrem Provisioner einen Wert für ttl festlegen, aktiviert dies das Ablaufen des Knotens. Sobald die Knoten innerhalb von Sekunden das definierte Alter erreicht haben, werden sie sicher geleert 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 die neuesten AMIs. EKS-optimized Weitere Informationen finden Sie unter Disruption auf der Karpenter-Website.

Karpenter fügt diesem Wert nicht automatisch Jitter hinzu. Um übermäßige Workload-Unterbrechungen zu vermeiden, definieren Sie ein Budget für Pod-Unterbrechungen, wie in der Kubernetes-Dokumentation dargestellt.

Wenn Sie ttl SecondsUntilExpired auf einem Provisioner konfigurieren, gilt dies für vorhandene Knoten, die dem Provisioner zugeordnet sind.

Verwenden Sie die Drift-Funktion für von Karpenter verwaltete Knoten

Mit der Drift-Funktion von Karpenter können die Karpenter-provisioned Knoten automatisch aktualisiert werden, sodass sie mit der EKS-Steuerungsebene synchron bleiben. Karpenter Drift muss derzeit mithilfe eines Feature-Gates aktiviert werden. https://karpenter.sh/docs/reference/settings/#feature-gates Die Standardkonfiguration von Karpenter verwendet das neueste EKS-Optimized AMI für dieselbe Haupt- und Nebenversion wie die Steuerungsebene des EKS-Clusters.

Nach Abschluss eines EKS-Cluster-Upgrades erkennt die Drift-Funktion von Karpenter, dass die Karpenter-provisioned Knoten EKS-Optimized AMIs für die vorherige Cluster-Version verwenden, und sperrt diese Knoten automatisch ab, entleert und ersetzt sie. Um die Migration von Pods auf neue Knoten zu unterstützen, folgen Sie den bewährten Methoden von Kubernetes, indem Sie angemessene Pod-Ressourcenkontingente festlegen und Pod-Disruption-Budgets (PDB) verwenden. Bei der Deprovisionierung durch Karpenter werden Ersatzknoten auf der Grundlage der Pod-Ressourcenanforderungen vorab eingerichtet und die PDBs werden bei der Deprovisionierung von Knoten berücksichtigt.

Verwenden Sie eksctl, um Upgrades für selbstverwaltete Knotengruppen zu automatisieren

Selbstverwaltete Knotengruppen sind EC2-Instances, die in Ihrem Konto bereitgestellt und außerhalb des EKS-Dienstes an den Cluster angehängt wurden. Diese werden normalerweise mit irgendwelchen Automatisierungstools bereitgestellt und verwaltet. Informationen zum Upgrade selbstverwalteter Knotengruppen finden Sie in der Dokumentation zu Ihren Tools.

Beispielsweise unterstützt eksctl das Löschen und Löschen selbstverwalteter Knoten.

Zu den gängigen Tools gehören:

Sichern Sie den Cluster vor dem Upgrade

Neue Versionen von Kubernetes führen erhebliche Änderungen an Ihrem Amazon EKS-Cluster ein. Sie können ein Upgrade innerhalb von 7 Tagen rückgängig machen. Wir empfehlen jedoch, dass Sie vor dem Upgrade ein Backup Ihres Clusters erstellen.

Sie können Ihren Cluster mit AWS Backup, einem vollständig verwalteten Service, sichern. Sie können auch Velero verwenden, ein von der Community unterstütztes Open-Source-Tool.

Beachten Sie, dass Sie nur neue Cluster für Kubernetes-Versionen erstellen können, die derzeit von EKS unterstützt werden. 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ßlich IAM, nicht in der Sicherung enthalten sind. Sie müssen diese Ressourcen neu erstellen.

Starten Sie die Fargate-Bereitstellungen neu, nachdem Sie die Steuerungsebene aktualisiert haben

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 blue/green Upgrade-Strategie. Dies kann Vorteile haben, beinhaltet aber auch Nachteile, die berücksichtigt werden sollten.

Zu den Vorteilen gehören:

Zu den Nachteilen gehören:

Diese Strategie ist zwar machbar, aber sie ist teurer als ein direktes Upgrade und erfordert mehr Zeit für Koordination und Workload-Migrationen. In manchen Situationen kann dies erforderlich sein und sollte sorgfältig geplant werden.

Bei einem hohen Automatisierungsgrad und ähnlichen GitOps deklarativen Systemen kann dies einfacher sein. Sie müssen zusätzliche Vorsichtsmaßnahmen für statusbehaftete Workloads treffen, sodass Daten gesichert und in neue Cluster migriert werden.

Weitere Informationen finden Sie in diesen Blogbeiträgen:

Verfolgen Sie geplante wichtige Änderungen im Kubernetes-Projekt — Denken Sie voraus

Schauen Sie sich nicht nur die nächste Version an. Sehen Sie sich neue Versionen von Kubernetes an, sobald sie veröffentlicht werden, und identifizieren Sie wichtige Änderungen. Einige Anwendungen nutzten beispielsweise direkt die Docker-API, und die Unterstützung für das Container Runtime Interface (CRI) für Docker (auch bekannt als Dockershim) wurde in Kubernetes entfernt. 1.24 Für diese Art von Änderung ist mehr Zeit erforderlich, um sich darauf vorzubereiten.

Prüfen Sie alle dokumentierten Änderungen für die Version, auf die Sie ein Upgrade durchführen, 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 Leitlinien zum Entfernen von Funktionen

Entfernung von Dockershim in 1.25 — Verwenden Sie den Detektor für Docker Socket (DDS)

Das EKS-optimierte AMI für 1.25 unterstützt Dockershim nicht mehr. Wenn Sie eine Abhängigkeit von Dockershim haben, 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 Kubectl-Plugin. .

Entfernung von Version PodSecurityPolicy 1.25 — Migrieren Sie zu Pod-Sicherheitsstandards oder einer Policy-as-Code-Lösung

PodSecurityPolicywar in Kubernetes 1.21 veraltet und wurde in Kubernetes 1.25 entfernt. Wenn Sie es PodSecurityPolicy in Ihrem Cluster verwenden, müssen Sie zu den integrierten Kubernetes Pod Security Standards (PSS) oder zu einer Policy-as-Code-Lösung migrieren, bevor Sie Ihren Cluster auf Version 1.25 aktualisieren, um Unterbrechungen Ihrer Workloads zu vermeiden.

AWS hat in der EKS-Dokumentation ausführliche häufig gestellte Fragen veröffentlicht. https://docs.aws.amazon.com/eks/latest/userguide/pod-security-policy-removal-faq.html

Lesen Sie die Best Practices für Pod Security Standards (PSS) und Pod Security Admission (PSA).

Lesen Sie den Blogbeitrag PodSecurityPolicy Deprecation auf der Kubernetes-Website.

Der In-Tree Speichertreiber in Version 1.23 ist veraltet — Migrieren Sie zu CSI-Treibern (Container Storage Interface)

Das Container Storage Interface (CSI) wurde entwickelt, um Kubernetes dabei zu unterstützen, seine bestehenden In-Tree-Speichertreibermechanismen zu ersetzen. Die Funktion zur Migration des Container Storage Interface (CSI) von Amazon EBS ist in Clustern von Amazon EKS 1.23 und höher standardmäßig aktiviert. Wenn Sie Pods auf einer Cluster-Version 1.22 oder einer früheren Version ausführen, müssen Sie den Amazon EBS-CSI-Treiber installieren, bevor Sie Ihren Cluster auf Version aktualisieren, um eine Dienstunterbrechung 1.23 zu vermeiden.

Lesen Sie die häufig gestellten Fragen zur Amazon EBS CSI-Migration.

Weitere Ressourcen

ClowdHaus Anleitung zum EKS-Upgrade

ClowdHaus EKS Upgrade Guidance ist eine CLI, die beim Upgrade von Amazon EKS-Clustern hilft. Es kann einen Cluster auf potenzielle Probleme analysieren, die vor dem Upgrade behoben werden müssen.

GoNoGo

GoNoGoist ein Alpha-Stufentool, mit dem Sie die Upgrade-Zuverlässigkeit Ihrer Cluster-Add-Ons ermitteln können.