Durch die Nutzung von AWS re:Post stimmt du den AWS re:Post Nutzungsbedingungen
AWS re:Postre:Post

Wie plane ich eine Upgrade-Strategie für einen Amazon EKS-Cluster?

Lesedauer: 8 Minute
0

Wenn ich meinen Amazon Elastic Kubernetes Service (Amazon EKS)-Cluster aktualisiere, möchte ich die bewährten Methoden befolgen.

Kurzbeschreibung

Neue Kubernetes-Versionen können erhebliche Änderungen an Ihrem Amazon EKS-Cluster mit sich bringen. Nach dem Upgrade eines Clusters können Sie Ihren Cluster nicht mehr herabstufen. Wenn Sie auf eine neuere Kubernetes-Version aktualisieren, können Sie zu neuen Clustern migrieren, anstatt direkte Cluster-Upgrades durchzuführen. Wenn Sie sich für die Migration zu neuen Clustern entscheiden, können Ihnen Tools zur Sicherung und Wiederherstellung von Clustern wie Velero von VMware bei der Migration helfen. Weitere Informationen finden Sie unter Valero auf der GitHub-Website.

Aktuelle und frühere Versionen von Kubernetes, die für Amazon EKS verfügbar sind, finden Sie im Amazon EKS-Kubernetes-Veröffentlichungskalender.

Behebung

Vorbereitung auf ein Upgrade

Bevor Sie mit dem ClusterUpgrade beginnen, beachten Sie die folgenden Anforderungen:

  • Amazon EKS benötigt bis zu fünf verfügbare IP-Adressen aus den Subnetzen, die Sie bei der Erstellung Ihres Clusters angegeben haben.
  • Die Rolle und Sicherheitsgruppe für AWS Identity and Access Management (IAM) des Clusters müssen in Ihrem AWS-Konto vorhanden sein.
  • Wenn Sie die Verschlüsselung von Geheimnissen aktivieren, muss die Cluster-IAM-Rolle über Schlüsselberechtigungen für AWS Key Management Service (AWS KMS) verfügen.

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

Prüfen Sie alle dokumentierten Änderungen für die Upgrade-Version 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.

In den folgenden Ressourcen finden Sie wichtige Updates für Amazon EKS-Cluster-Plattformversionen und Kubernetes-Versionen:

Weitere Informationen zu Kubernetes-Upstream-Versionen und wichtigen Updates finden Sie in der folgenden Dokumentation:

Verstehen Sie die Kubernetes-Verfallsrichtlinie

Wenn eine API aktualisiert wird, ist die frühere API veraltet und wird schließlich entfernt. Um zu verstehen, warum APIs in einer neueren Version von Kubernetes möglicherweise veraltet sind, lesen Sie die Verfallsrichtlinie auf der Kubernetes-Website.

Um zu überprüfen, ob Sie veraltete API-Versionen in Ihrem Cluster verwenden, verwenden Sie Kube No Trouble (kubent) auf der GitHub-Website. Wenn Sie veraltete API-Versionen verwenden, aktualisieren Sie Ihre Workloads, bevor Sie Ihr Kubernetes Cluster aktualisieren.

Verwenden Sie das Plugin kubectl convert, um Kubernetes-Manifestdateien zwischen verschiedenen API-Versionen zu konvertieren. Weitere Informationen finden Sie unter Installieren des Kubectl Convert-Plugins auf der Kubernetes-Website.

Was Sie bei einem Kubernetes-Upgrade erwartet

Wenn Sie Ihren Cluster aktualisieren, startet Amazon EKS neue API-Serverknoten mit der aktualisierten Kubernetes-Version, um die vorhandenen Knoten zu ersetzen. Wenn eine dieser Prüfungen fehlschlägt, setzt Amazon EKS die Infrastrukturbereitstellung zurück und Ihr Cluster verbleibt auf der vorherigen Kubernetes-Version. Dieses Rollback wirkt sich jedoch nicht auf laufende Anwendungen aus, und Sie können bei Bedarf alle Cluster wiederherstellen. Während des Upgrade-Vorgangs kann es zu geringfügigen Betriebsunterbrechungen kommen.

Rüsten Sie die Steuerungsebene und die Datenebene auf

Um einen Amazon EKS-Cluster zu aktualisieren, müssen Sie zwei Hauptkomponenten aktualisieren: die Steuerungsebene und die Datenebene. Beachten Sie beim Upgrade dieser Komponenten die folgenden Überlegungen.

Direkte Amazon EKS-Cluster-Upgrades

Für direkte Upgrades können Sie nur auf die nächsthöhere Kubernetes-Nebenversion aktualisieren. Wenn es mehrere Versionen zwischen Ihrer aktuellen Cluster-Version und der Zielversion gibt, müssen Sie nacheinander auf jede Version aktualisieren. Führen Sie für jedes direkte Kubernetes-Cluster-Upgrade die folgenden Aufgaben aus:

  • Aktualisieren Sie Ihre Kubernetes-Manifeste und aktualisieren Sie nach Bedarf veraltete oder entfernte APIs.
  • Aktualisieren Sie die Cluster-Steuerungsebene.
  • Aktualisieren Sie die Knoten in Ihrem Cluster.
  • Aktualisieren Sie Ihre Kubernetes-Add-Ons und benutzerdefinierten Controller nach Bedarf.

Weitere Informationen finden Sie unter Planung und Ausführung von Kubernetes-Versionsupgrades in Amazon EKS unter Planung von Kubernetes-Upgrades mit Amazon EKS. Weitere Informationen finden Sie auf der GitHub Website unter Bewährte Methoden für Cluster Upgrades.

Migration von Amazon EKS-Clustern in Blau/Grün oder Canary

Eine Upgrade-Strategie in Blau/Grün oder Canary kann komplexer sein, aber die Strategie ermöglicht Upgrades mit einfacher Rollback-Funktion und ohne Ausfallzeiten. Informationen zu einem Blau/Grün- oder Canary-Upgrade finden Sie unter Migration von Amazon EKS-Clustern in Blau/Grün oder Canary für zustandslose ArgoCD-Workloads.

**Aktualisieren Sie die von Amazon EKS verwalteten Knotengruppen **

Wichtig: Das Kubelet eines Knotens kann nicht neuer als kube-apiserver sein. Außerdem können es nicht mehr als zwei Nebenversionen vor kube-apiserver sein. Nehmen wir zum Beispiel an, kube-apiserver hat Version 1.24. In diesem Fall wird ein Kubelet nur in den Versionen 1.24, 1.23 und 1.22 unterstützt.

Gehen Sie wie folgt vor, um Ihre verwalteten Knotengruppen vollständig zu aktualisieren:

  1. Aktualisieren Sie die Komponenten der Cluster-Steuerungsebene von Amazon EKS auf die neueste Version.
  2. Aktualisieren Sie Ihre Knoten in der verwalteten Knotengruppe.

Migrieren Sie zu von Amazon EKS verwalteten Knotengruppen

Wenn Sie selbstverwaltete Knotengruppen verwenden, können Sie Ihre Workload ohne Ausfallzeiten auf von Amazon EKS verwaltete Knotengruppen migrieren. Weitere Informationen finden Sie unter Nahtloses Migrieren von Workloads von einer selbstverwalteten EKS-Knotengruppe zu EKS-verwalteten Knotengruppen.

Identifizieren und aktualisieren Sie Downstream-Abhängigkeiten (Add-Ons)

Cluster enthalten häufig externe Produkte wie Eingangskontrollen, Continuous-Delivery-Systeme, Überwachungstools und andere Workflows. Wenn Sie Ihren Amazon EKS-Cluster aktualisieren, müssen Sie auch die Add-Ons und Tools von Drittanbietern aktualisieren. Vergewissern Sie sich, dass Sie verstehen, wie Add-Ons mit Ihrem Cluster funktionieren und wie sie aktualisiert werden.

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

Sehen Sie sich die folgenden Beispiele gängiger Add-Ons und die entsprechende Upgrade-Dokumentation an:

Aktualisieren der AWS Fargate-Knoten

Um einen Fargate-Knoten zu aktualisieren, löschen Sie den Pod, den der Knoten repräsentiert. Stellen Sie dann, nachdem Sie Ihre Steuerungsebene aktualisiert haben, den Pod erneut bereit. Alle neuen Pods, die Sie auf Fargate starten, haben eine Kubelet-Version, die Ihrer Cluster-Version entspricht. Bestehende Fargate-Pods werden nicht geändert.

Hinweis: Um die Sicherheit der Fargate-Pods zu gewährleisten, muss Amazon EKS sie regelmäßig patchen. Amazon EKS versucht, die Pods so zu aktualisieren, dass die Auswirkungen minimiert werden. Wenn Pods jedoch nicht erfolgreich entfernt werden können, löscht Amazon EKS sie. Informationen zur Minimierung von Unterbrechungen finden Sie unter Fargate OS-Patching.

Aktualisieren gruppenloser Knoten, die Karpenter erstellt

Wenn Sie einen Wert für TTLSecondsUntilExpired festlegen, aktiviert dieser Wert den Verfall des Knotens. Nachdem Knoten das definierte Alter in Sekunden erreicht haben, löscht Amazon EKS sie. Dieses Löschen erfolgt auch dann, wenn die Knoten verwendet werden. Dieser Prozess ermöglicht es Ihnen, Knoten durch neu bereitgestellte Instances zu ersetzen und sie daher zu aktualisieren. Wenn ein Knoten ersetzt wird, verwendet Karpenter die neuesten für Amazon EKS optimierten AMIs. Weitere Informationen finden Sie unter Unterbrechungen 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 diesem Wert nicht automatisch Jitter hinzu. Wenn Sie in kurzer Zeit mehrere Instances erstellen, laufen die Instances fast zur gleichen Zeit ab. Um übermäßige Workload-Unterbrechungen zu vermeiden, definieren Sie ein Budget für Pod-Unterbrechungen. Weitere Informationen finden Sie auf der Kubernetes-Website unter Angeben eines Unterbrechungsbudgets für Ihre Anwendung.

Themen
Behälter
Tags
Amazon Elastic Kubernetes Service
Sprache
Deutsch
AWS OFFICIAL
AWS OFFICIALAktualisiert vor 3 Monaten

Relevanter Inhalt