Direkt zum Inhalt
Durch die Nutzung von AWS re:Post stimmt du den AWS re:Post Nutzungsbedingungen
AWS re:Postre:Post
Über re:Post

Wie plane ich ein Upgrade für meinen Amazon EKS-Cluster?

Lesedauer: 7 Minute
0

Ich möchte beim Upgrade meines Amazon Elastic Kubernetes Service (Amazon EKS)-Clusters die bewährten Methoden befolgen.

Lösung

Auswirkungen eines Upgrades verstehen

Neue Kubernetes-Versionen können erhebliche Änderungen an deinem Amazon EKS-Cluster mit sich bringen. Nach dem Upgrade deines Clusters kannst du deinen Cluster nicht mehr herabstufen.

Wenn du auf eine neuere Kubernetes-Version aktualisierst, musst du kein direktes Cluster-Upgrade durchführen. Stattdessen kannst du zu einem neuen Cluster migrieren. Wenn du zu einem neuen Cluster migrierst, empfiehlt es sich, Tools zum Sichern und Wiederherstellen von Clustern wie Velero zu verwenden. Weitere Informationen findest du unter Valero auf der GitHub-Website.

Aktuelle und frühere Versionen von Kubernetes findest du im Amazon EKS Kubernetes-Freigabekalender.

Upgrade-Anforderungen erfüllen

Um deinen Cluster zu aktualisieren, musst du die folgenden Anforderungen erfüllen:

  • Du musst über bis zu fünf verfügbare IP-Adressen aus den Subnetzen verfügen, die du bei der Erstellung deines Clusters angegeben hast.
  • Die Rolle und Sicherheitsgruppe für AWS Identity and Access Management (IAM) deines Clusters müssen in deinem AWS-Konto vorhanden sein.
  • Wenn du die Verschlüsselung von Geheimnissen aktivierst, muss die Cluster-IAM-Rolle über Berechtigungen für den AWS Key Management Service (AWS KMS)-Schlüssel verfügen.

Überprüfe die wichtigsten Updates für Amazon EKS und Kubernetes

Ergreife die folgenden Maßnahmen:

  • Prüfe alle dokumentierten Änderungen für die Upgrade-Version und notiere dir dann die erforderlichen Upgrade-Schritte.
  • Prüfe die Anforderungen oder Verfahren, die für von Amazon EKS verwaltete Cluster spezifisch sind.

Informationen zu wichtigen Updates der Plattformversionen von Amazon EKS-Clustern und Kubernetes-Versionen findest du in der folgenden Dokumentation:

Informationen zu Kubernetes-Upstream-Versionen und wichtigen Updates findest du in der folgenden Dokumentation:

APIs verstehen und nach nicht mehr verfügbaren APIs suchen

Wenn Kubernetes eine API aktualisiert, entfernt Kubernetes auch die vorherige API.

Gehe wie folgt vor, um eingestellte APIs zu verwalten:

  • Um zu verstehen, wie Kubernetes APIs in einer späteren Version von Kubernetes einstellt, lies die Kubernetes-Verfallsrichtlinie auf der Kubernetes-Website.
  • Verwende das Tool Kube No Trouble (kubent), um in deinem Cluster nach eingestellten API-Versionen zu suchen. Weitere Informationen findest du unter kube-no-trouble auf der GitHub-Website. Wenn du nicht mehr verfügbare API-Versionen verwendest, aktualisiere deine Workloads, bevor du dein Kubernetes-Cluster aktualisierest.
  • Verwende das Plugin kubectl convert, um Kubernetes-Manifestdateien zwischen verschiedenen API-Versionen zu konvertieren. Weitere Informationen findest du unter Installieren des Kubectl Convert-Plugins auf der Kubernetes-Website.

Verstehen, was dich bei einem Kubernetes-Upgrade erwartet

Wenn du deinen Cluster aktualisierst, startet Amazon EKS neue API-Serverknoten mit der aktualisierten Kubernetes-Version, um die vorhandenen Knoten zu ersetzen. Amazon EKS führt auch eine Reihe interner Prüfungen durch. Wenn eine Prüfung fehlschlägt, setzt Amazon EKS die Infrastrukturbereitstellung zurück und dein Cluster verbleibt auf der vorherigen Kubernetes-Version. Das Rollback wirkt sich nicht auf laufende Anwendungen aus und du kannst die Cluster wiederherstellen.

Hinweis: Während des Upgrade-Vorgangs kann es zu geringfügigen Betriebsunterbrechungen kommen.

Rüste die Steuerungsebene und die Datenebene auf

Um einen Cluster zu aktualisieren, musst du die Steuerungsebene und die Datenebene aktualisieren.

Wähle eine der folgenden Methoden aus, um die Ebenen zu aktualisieren:

  • Lokales Cluster-Upgrade
  • Blau/Grün- oder Canary-Upgrade
  • Upgrade einer verwalteten Knotengruppe

Lokales Cluster-Upgrade

Wichtig: Für direkte Upgrades kannst du nur auf die neueste Nebenversion von Kubernetes aktualisieren. Wenn es mehrere Versionen zwischen deiner aktuellen Cluster-Version und der Zielversion gibt, musst du nacheinander auf jede Version aktualisieren.

Führe für jedes direkte Kubernetes-Cluster-Upgrade die folgenden Schritte aus:

  1. Aktualisiere deine Kubernetes-Manifeste und die eingestellten APIs.
  2. Aktualisiere die Cluster-Steuerungsebene.
  3. Aktualisiere die Knoten in deinem Cluster.
  4. Aktualisiere deine Kubernetes-Add-Ons und benutzerdefinierten Controller.

Weitere Informationen findest du im Abschnitt Planung und Ausführung von Kubernetes-Versionsupgrades in Amazon EKS unter Planung von Kubernetes-Upgrades mit Amazon EKS. Weitere Informationen findest du unter Bewährte Methoden für Cluster-Upgrades.

Blau/Grün- oder Canary-Upgrade

Informationen zum Abschließen eines Blau/Grün- oder Canary-Upgrades findest du unter Migration von Amazon EKS-Clustern in Blau/Grün oder Canary für zustandslose ArgoCD-Workloads.

Upgrade einer verwalteten Knotengruppe

Wichtig: Das Kubelet eines Knotens kann nicht aktueller als kube-apiserver sein. Außerdem darf das Kubelet nicht mehr als zwei Nebenversionen älter als kube-apiserver sein. Wenn kube-apiserver beispielsweise Version 1.24 hat, unterstützt Amazon EKS ein Kubelet nur in den Versionen 1.24, 1.23 und 1.22.

Um eine verwaltete Knotengruppe zu aktualisieren, aktualisiere deine Knoten in der verwalteten Knotengruppe.

Zu einer von Amazon EKS verwalteten Knotengruppe migrieren

Wenn du selbstverwaltete Knotengruppen verwendest, kannst du deine Workload ohne Ausfallzeiten auf von Amazon EKS verwaltete Knotengruppen migrieren.

Downstream-Abhängigkeiten (Add-Ons) identifizieren und aktualisieren

Cluster können Add-Ons und Tools von Drittanbietern enthalten, z. B. Eingangskontrollen, Continuous-Delivery-Systeme, Überwachungstools und andere Workflows. Wenn du deinen Cluster aktualisierst, musst du auch die Add-Ons und Tools von Drittanbietern aktualisieren. Vergewissere dich, dass du verstehst, wie Add-Ons mit deinem Cluster funktionieren und wie Add-Ons aktualisiert werden.

Hinweis: Es hat sich bewährt, verwaltete Add-Ons anstelle von selbstverwalteten Add-Ons zu verwenden.

Sieh dir die folgenden Beispiele gängiger Add-Ons und die Upgrade-Dokumentation an:

Fargate-Knoten aktualisieren

Gehe wie folgt vor, um einen AWS Fargate-Knoten zu aktualisieren:

  1. Lösche den Pod, den dein Knoten repräsentiert.
  2. Aktualisiere deine Steuerebene.
  3. Stelle den Pod erneut bereit.

Neuen Pods, die du auf Fargate startest, haben eine Kubelet-Version, die deiner Cluster-Version entspricht. Dein Upgrade wirkt sich nicht auf bestehende Fargate-Pods aus.

Hinweis: Amazon EKS muss Fargate Pods regelmäßig patchen, um die Sicherheit der Pods zu gewährleisten. Bei der Aktualisierung der Pods minimiert Amazon EKS die Auswirkungen des Patches. Wenn Amazon EKS Pods nicht entfernen kann, löscht Amazon EKS die Pods. Informationen zur Minimierung von Unterbrechungen findest du unter Aktionen für Patch-Ereignisse im AWS Fargate-Betriebssystem festlegen.

Nicht verwaltete Knoten, die Karpenter erstellt, aktualisieren

Der Wert, den du für ttlSecondsUntilExpired festlegst, aktiviert den Ablauf des Knotens. Nachdem Knoten das festgelegte Alter in Sekunden erreicht haben, löscht Amazon EKS die Knoten. Die Löschung erfolgt auch dann, wenn Amazon EKS-Workloads oder -Anwendungen die Knoten verwenden. Verwende ttlSecondsUntilExpired, um Knoten durch neu bereitgestellte Instances zu ersetzen, sodass du die Instances aktualisieren kannst. Karpenter verwendet die neuesten Amazon EKS-optimierten Amazon Machine Images (AMIs) für ersetzte Knoten. Weitere Informationen darüber, wie Karpenter Knoten unterbricht, findest du unter Unterbrechung auf der Karpenter-Website.

Das folgende Beispiel zeigt einen Knoten, für den die Bereitstellung mit ttlSecondsUntilExpired aufgehoben und dann durch eine aktualisierte Instance ersetzt wurde:

apiVersion: karpenter.sh/v1alpha5kind: Provisioner
metadata:
  name: default
spec:
  requirements:
    - key: karpenter.sh/capacity-type         # optional, set to on-demand by default, spot if both are listed
      operator: In
      values: ["spot"]
  limits:
    resources:
      cpu: 1000                               # optional, recommended to limit total provisioned CPUs
      memory: 1000Gi
  ttlSecondsAfterEmpty: 30                    # optional, but never scales down if not set
  ttlSecondsUntilExpired: 2592000             # optional, nodes are recycled after 30 days but never expires if not set
  provider:
        subnetSelector:
      karpenter.sh/discovery/CLUSTER_NAME: '*'
    securityGroupSelector:
      kubernetes.io/cluster/CLUSTER_NAME: '*'

Hinweis: Karpenter fügt dem ttlSecondsUntilExpired-Wert nicht automatisch Jitter hinzu. Wenn du in kurzer Zeit mehrere Instances erstellst, laufen die Instances gleichzeitig ab. Um übermäßige Arbeitsausfälle zu vermeiden, lege ein Budget für Pod-Unterbrechungen fest. Weitere Informationen findest du auf der Kubernetes-Website unter Angeben eines Unterbrechungsbudgets für deine Anwendung.

Themen
Containers
Tags
Amazon Elastic Kubernetes Service
Sprache
Deutsch
AWS OFFICIALAktualisiert vor 3 Monaten

Relevanter Inhalt