Aktualisieren einer Amazon-EKS-Cluster-Kubernetes-Version

Wenn eine neue Kubernetes-Version in Amazon EKS verfügbar ist, können Sie Ihren Amazon-EKS-Cluster auf die neueste Version aktualisieren.

Wichtig

Es wird empfohlen, dass Sie vor dem Aktualisieren auf eine neue Kubernetes-Version die Informationen in Kubernetes-Versionen für Amazon EKS und in den Aktualisierungsschritten in diesem Thema sichten. Wenn Sie auf Version 1.22 aktualisieren, müssen Sie vor dem Update an Ihrem Cluster die in Kubernetes-Version 1.22-Voraussetzungen aufgeführten Änderungen vornehmen.

Neue Kubernetes-Versionen führen oft bedeutende Änderungen ein. Daher empfehlen wir Ihnen, das Verhalten Ihrer Anwendungen mit einer neuen Kubernetes-Version zu testen, bevor Sie Ihre Produktionscluster aktualisieren. Hierzu erstellen Sie einen kontinuierlichen Integrations-Workflow, um das Verhalten Ihrer Anwendungen zu testen, bevor Sie auf eine neue Kubernetes-Version aktualisieren.

Der Aktualisierungsprozess besteht darin, dass Amazon EKS neue API-Serverknoten mit der aktualisierten Kubernetes-Version startet, um die vorhandenen zu ersetzen. Amazon EKS führt auf diesen neuen Knoten standardmäßige Infrastruktur- und Bereitschaftszustandsprüfungen für den Netzwerkverkehr durch, um sicherzustellen, dass sie wie erwartet funktionieren. Wenn eine dieser Prüfungen fehlschlägt, macht Amazon EKS die Infrastruktur-Bereitstellung rückgängig und der Cluster verbleibt in der vorherigen Kubernetes-Version. Laufende Anwendungen sind davon nicht betroffen und Ihr Cluster befindet sich nie in einem nicht deterministischen oder nicht wiederherstellbaren Zustand. Amazon EKS sichert regelmäßig alle verwalteten Cluster, und es gibt Mechanismen, um Cluster bei Bedarf wiederherzustellen. Wir evaluieren und verbessern unsere Verwaltungsprozesse für die Kubernetes-Infrastruktur laufend.

Um den Cluster zu aktualisieren, benötigt Amazon EKS bis zu fünf freie IP-Adressen aus den Subnetzen, die beim Erstellen des Clusters bereitgestellt wurden. Amazon EKS erstellt in jedem der von Ihnen angegebenen Subnetze neue Elastic-Network-Schnittstellen für den Cluster (Netzwerkschnittstellen). Die Netzwerkschnittstellen können in anderen Subnetzen erstellt werden als Ihre vorhandenen Netzwerkschnittstellen. Stellen Sie daher sicher, dass Ihre Sicherheitsgruppenregeln die erforderliche Cluster-Kommunikation für jedes der Subnetze zulassen, die Sie bei der Erstellung Ihres Clusters angegeben haben. Wenn eines der Subnetze, die Sie bei der Erstellung des Clusters angegeben haben, nicht existiert, nicht genügend freie IP-Adressen hat oder nicht über Sicherheitsgruppenregeln verfügt, die die notwendige Clusterkommunikation zulassen, kann die Aktualisierung fehlschlagen.

Anmerkung

Obwohl Amazon EKS eine hochverfügbare Steuerebene ausführt, ist es möglich, dass während einer Aktualisierung geringfügige Service-Unterbrechungen auftreten. Angenommen, Sie versuchen, eine Verbindung zu einem API-Server herzustellen, als dieser gerade beendet und durch einen neuen API-Server ersetzt wird, auf dem die neue Version von Kubernetes läuft. Möglicherweise treten API-Aufruffehler oder Verbindungsprobleme auf. Wiederholen Sie in diesem Fall Ihre API-Operationen, bis sie erfolgreich sind.

Die Kubernetes-Version für Ihren-Amazon EKS-Cluster aktualisieren

Aktualisieren der Kubernetes-Version für Ihren Cluster

1. Vergleichen Sie die Kubernetes-Version Ihrer Cluster-Steuerebene mit der Kubernetes-Version Ihrer Knoten.

   • Rufen Sie die Kubernetes-Version Ihrer Cluster-Steuerebene mit dem Befehl kubectl version --short ab.

     kubectl version --short

   • Rufen Sie die Kubernetes-Version Ihrer Knoten mit dem Befehl kubectl get nodes ab. Dieser Befehl gibt alle selbstverwalteten und verwalteten Amazon-EC2- und Fargate-Knoten zurück. Jeder Fargate-pod wird als eigener Knoten aufgeführt.

     kubectl get nodes

   Bevor Sie eine Steuerebene auf eine neue Kubernetes-Version aktualisieren, muss die Kubernetes-Nebenversion der verwalteten und Fargate-Knoten in Ihrem Cluster mit der Version der aktuellen Version Ihrer Steuerebene übereinstimmen. Wenn auf der Steuerebene beispielsweise Version 1.21 läuft und auf einem Ihrer Knoten Version 1.20, dann müssen Sie Ihre Knoten auf Version 1.21 aktualisieren. Wir empfehlen außerdem, dass Sie Ihre selbstverwalteten Knoten auf dieselbe Version wie Ihre Steuerebene aktualisieren, bevor Sie die Steuerebene aktualisieren. Weitere Informationen finden Sie unter Aktualisieren einer verwalteten Knotengruppe und Aktualisierungen des selbstverwalteten Worker-Knotens. Um die Version eines Fargate-Knotens zu aktualisieren, löschen Sie zunächst den pod, der durch den Knoten repräsentiert wird. Aktualisieren Sie dann Ihre Steuerebene. Alle verbleibenden pods werden auf die neue Version aktualisiert, nachdem Sie sie neu bereitgestellt haben.

2. Der Zugangscontroller für die pod-Sicherheitsrichtlinie ist auf Amazon-EKS-Clustern standardmäßig aktiviert. Stellen Sie vor der Aktualisierung Ihres Clusters sicher, dass die richtigen pod-Sicherheitsrichtlinien vorhanden sind. Dies dient dazu, potenzielle Sicherheitsprobleme zu vermeiden. Sie können die Standardrichtlinie mit dem Befehl kubectl get psp eks.privileged überprüfen.

   kubectl get psp eks.privileged

   Wenn Sie die folgende Fehlermeldung erhalten, lesen Sie die Standard-pod-Sicherheitsrichtlinie, bevor Sie fortfahren.

   Error from server (NotFound): podsecuritypolicies.extensions "eks.privileged" not found

3. Wenn die Kubernetes-Version, mit der Sie Ihren Cluster ursprünglich eingerichtet haben, Kubernetes 1.18 oder eine neuere war, überspringen Sie diesen Schritt.

   Möglicherweise müssen Sie einen eingestellten Begriff aus Ihrem CoreDNS-Manifest entfernen.

   1. Überprüfen Sie, ob Ihr CoreDNS-Manifest eine Zeile enthält, die nur das Wort upstream enthält.

      kubectl get configmap coredns -n kube-system -o jsonpath='{$.data.Corefile}' | grep upstream

      Wenn keine Ausgabe zurückgegeben wird, bedeutet dies, dass Ihr Manifest die Zeile nicht enthält. In diesem Fall überspringen Sie den nächsten Schritt. Wenn das Wort upstream zurückgegeben wird, müssen Sie die Zeile entfernen.

   2. Entfernen Sie in der configmap-Datei die Zeile am oberen Rand der Datei, die nur das Wort upstream enthält. Ändern Sie sonst nichts in der Datei. Nachdem die Zeile entfernt wurde, speichern Sie die Änderungen.

      kubectl edit configmap coredns -n kube-system -o yaml

   Mehr anzeigenWeniger anzeigen

4. Aktualisieren Sie Ihren Cluster mit eksctl, AWS Management Console oder AWS CLI.

   Wichtig

   • Wenn Sie auf Version 1.22 aktualisieren, müssen Sie vor dem Update an Ihrem Cluster die in Kubernetes-Version 1.22-Voraussetzungen aufgeführten Änderungen vornehmen.

   • Da Amazon EKS eine hoch verfügbare Steuerebene ausführt, dürfen Sie jeweils nur um eine Unterversion aktualisieren. Weitere Informationen zu dieser Anforderung finden Sie unter Kubernetes-Version und Version-Skew-Supportrichtlinie. Angenommen, Ihre aktuelle Version ist 1.20 und Sie möchten auf 1.22 aktualisieren. In dem Fall müssen Sie zuerst Ihren Cluster auf 1.21 aktualisieren und dann von 1.21 auf 1.22.

   • Stellen Sie vor der Aktualisierung sicher, dass das kubelet auf Ihren verwalteten und Fargate-Knoten dieselbe Kubernetes-Version wie Ihre Steuerebene aufweist. Es wird empfohlen, die selbstverwalteten Knoten auf der gleichen Version wie die Steuerebene zu halten. Sie können nur bis zu einer Version unter der aktuellen Version der Steuerebene liegen.

   • Wenn Ihr Cluster mit einer Version des Amazon-VPC-CNI-Plugins vor 1.8.0 konfiguriert ist, sollten Sie das Plugin auf die Version 1.11.2 aktualisieren, bevor Sie den Cluster auf Version 1.21 oder höher aktualisieren. Weitere Informationen finden Sie unter Aktualisieren des Amazon VPC CNI plugin for Kubernetes-Add-ons oder Aktualisieren des selbstverwalteten Amazon VPC CNI plugin for Kubernetes-Add-ons.

   eksctl

   Für diesen Vorgang ist eksctl Version 0.105.0 oder höher erforderlich. Sie können Ihre -Version mit dem folgenden Befehl überprüfen:

   eksctl version

   Anweisungen zum Installieren und Aktualisieren von eksctl finden Sie unter .

   Aktualisieren Sie mit dem folgenden Befehl die Kubernetes-Version Ihrer Amazon-EKS-Steuerebene auf eine Nebenversion nach der aktuellen Version. Ersetzen Sie my-cluster mit Ihrem Clusternamen.

   eksctl upgrade cluster --name my-cluster --approve

   Die Aktualisierung dauert einige Minuten.

   AWS Management Console

   1. Öffnen Sie die Amazon-EKS-Konsole unter https://console.aws.amazon.com/eks/home#/clusters.

   2. Wählen Sie den Namen des zu aktualisierenden Amazon-EKS-Clusters aus und klicken Sie dann auf Cluster-Version aktualisieren.

   3. Wählen Sie für Kubernetes version (Kubernetes-Version) die Version aus, auf die Sie den Cluster aktualisieren möchten, und klicken Sie auf Update (Aktualisieren).

   4. Geben Sie als Cluster name (Clustername) den Namen Ihres Clusters ein und klicken Sie auf Confirm (Bestätigen).

      Die Aktualisierung dauert einige Minuten.

   AWS CLI

   1. Aktualisieren Sie Ihren Amazon-EKS-Cluster mit dem AWS CLI-Befehl. Ersetzen Sie das example-values durch Ihr eigenes.

      aws eks update-cluster-version \
       --region region-code \
       --name my-cluster \
       --kubernetes-version 1.22

      Die Beispielausgabe lautet wie folgt.

      {
          "update": {
              "id": "b5f0ba18-9a87-4450-b5a0-825e6e84496f",
              "status": "InProgress",
              "type": "VersionUpdate",
              "params": [
                  {
                      "type": "Version",
                      "value": "1.22"
                  },
                  {
                      "type": "PlatformVersion",
                      "value": "eks.1"
                  }
              ],
      ...
              "errors": []
          }
      }

   2. Überwachen Sie den Status Ihres Cluster-Updates mit dem folgenden Befehl. Verwenden Sie den Clusternamen und die Update-ID, die der vorherige Befehl zurückgegeben hat. Wenn der Status Successful angezeigt wird, ist das Update abgeschlossen. Die Aktualisierung dauert einige Minuten.

      aws eks describe-update \
        --region region-code \
        --name my-cluster \
        --update-id b5f0ba18-9a87-4450-b5a0-825e6e84496f

      Die Beispielausgabe lautet wie folgt.

      {
          "update": {
              "id": "b5f0ba18-9a87-4450-b5a0-825e6e84496f",
              "status": "Successful",
              "type": "VersionUpdate",
              "params": [
                  {
                      "type": "Version",
                      "value": "1.22"
                  },
                  {
                      "type": "PlatformVersion",
                      "value": "eks.1"
                  }
              ],
      ...
              "errors": []
          }
      }

5. Nachdem Ihre Cluster-Aktualisierung abgeschlossen wurde, aktualisieren Sie Ihre Knoten auf dieselbe Kubernetes-Nebenversion wie Ihr aktualisierter Cluster. Weitere Informationen finden Sie unter Aktualisierungen des selbstverwalteten Worker-Knotens und Aktualisieren einer verwalteten Knotengruppe. Alle neuen pods, die auf Fargate gestartet werden, verfügen über eine kubelet-Version, die Ihrer Cluster-Version entspricht. Bestehende Fargate-pods werden nicht geändert.

6. (Optional) Wenn Sie den Kubernetes Cluster Autoscaler in Ihrem Cluster bereitgestellt haben, bevor Sie den Cluster aktualisiert haben, aktualisieren Sie den Cluster Autoscaler auf die neueste Version, die der Kubernetes-Haupt- und Nebenversion entspricht, auf die Sie aktualisiert haben.

   1. Öffnen Sie die Seite Cluster Autoscaler releases in einem Webbrowser und suchen Sie die neuste Cluster Autoscaler-Version, die der Haupt- und Nebenversion Ihres Kubernetes-Clusters entspricht. Wenn beispielsweise die Kubernetes-Version Ihres Clusters 1.22 lautet, suchen Sie die neueste Cluster Autoscaler-Version, die mit 1.22 beginnt. Notieren Sie sich die semantische Versionsnummer (<1.22.n>) für diese Version, die Sie im nächsten Schritt benötigen.

   2. Legen Sie das Cluster Autoscaler-Abbild-Tag mit dem folgenden Befehl auf die Version fest, die Sie im vorherigen Schritt notiert haben. Ersetzen Sie ggf. 1.22.n durch Ihren eigenen Wert.

      kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=k8s.gcr.io/autoscaling/cluster-autoscaler:v1.22.n

7. (Nur Cluster mit GPU-Knoten) Wenn Ihr Cluster über Knoten-Gruppen mit GPU-Unterstützung (z. B. p3.2xlarge) verfügt, müssen Sie den Kubernetes NVIDIA-Geräte-Plug-in für DaemonSet auf Ihrem Cluster mit folgendem Befehl aktualisieren.

   kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.9.0/nvidia-device-plugin.yml

8. Aktualisieren Sie die Amazon VPC CNI plugin for Kubernetes, CoreDNS und kube-proxy Add-ons. Wenn Sie Ihren Cluster auf Version 1.21 oder neuer aktualisiert haben, empfehlen wir, die Add-ons auf die in Servicekonto-Token aufgeführten Mindestversionen zu aktualisieren.

   • Wenn Sie Ihren Cluster auf Version 1.18 aktualisiert haben, können Sie Amazon-EKS-Add-ons hinzufügen. Anweisungen finden Sie unter Hinzufügen des Amazon-VPC-CNI-Amazon-EKS-Add-ons, Hinzufügen des CoreDNS-Amazon-EKS-Add-ons und Hinzufügen des kube-proxy-Amazon-EKS-Add-ons. Weitere Informationen zu Amazon-EKS-Add-ons finden Sie unter Amazon-EKS-Add-ons.

   • Wenn Sie auf Version 1.19 oder höher aktualisiert haben und Amazon-EKS-Add-ons verwenden, wählen Sie in der Amazon-EKS-Konsole Clusters (Cluster) und dann im linken Navigationsbereich den Namen des Clusters aus, den Sie aktualisiert haben. In der Konsole werden Benachrichtigungen angezeigt. Sie informieren darüber, dass für jedes Add-on, für das ein Update verfügbar ist, eine neue Version verfügbar ist. Um ein Add-on zu aktualisieren, wählen Sie die Registerkarte Add-ons aus. Wählen Sie in einem der Felder für ein Add-on, für das eine Aktualisierung verfügbar ist, Jetzt aktualisieren aus, wählen Sie eine verfügbare Version aus, und wählen Sie dann Aktualisieren aus.

   • Alternativ können Sie die AWS CLI oder eksctl verwenden, um die Amazon VPC CNI plugin for Kubernetes, CoreDNS und kube-proxy Amazon-EKS-Add-ons zu aktualisieren.

Kubernetes-Version 1.22-Voraussetzungen

Eine Reihe veralteter Beta-APIs (v1beta1) wurden in Version 1.22 zugunsten der GA-Version (v1) der gleichen APIs entfernt. Wie in der Kubernetes-Version 1.22 im Blog zu entfernten APIs und Funktionen und im veralteten API-Migrationshandbuch erwähnt, sind vor der Aktualisierung eines Clusters auf Version 1.22 API-Änderungen für die folgenden bereitgestellten Ressourcen erforderlich.

Bevor Sie Ihren Cluster auf die Kubernetes-Version 1.22 aktualisieren, gehen Sie wie folgt vor:

• Bearbeiten Sie Ihre YAML-Manifestdateien und -Clients so, dass sie auf die neuen APIs verweisen.

• Aktualisieren Sie benutzerdefinierte Integrationen und Controller so, dass sie die neuen APIs aufrufen.

• Stellen Sie sicher, dass Sie die aktuellste Version von Drittanbietertools verwenden. Zu diesen Tools gehören Ingress-Controller, Service-Mesh-Controller, Systeme für die kontinuierliche Bereitstellung und andere Tools, die die neuen APIs aufrufen. Um Ihren Cluster auf die Verwendung nicht mehr verwendeter APIs zu überprüfen, aktivieren Sie das Prüfprotokoll für die Steuerebene und geben Sie v1beta als Ereignisfilter an. Ersatz-APIs sind in Kubernetes für verschiedene Versionen verfügbar.

• Wenn derzeit der AWS-Load-Balancer-Controller auf Ihrem Cluster bereitgestellt ist, müssen Sie ihn auf Version 2.4.1 aktualisieren, bevor Sie den Cluster auf Kubernetes-Version 1.22 aktualisieren.

Wichtig

Wenn Sie Ihre Cluster auf Version 1.22 aktualisieren, kann auf persistente Objekte über die neuen APIs zugegriffen werden. Sie müssen jedoch die Manifeste migrieren und die Clients aktualisieren, damit die neuen APIs verwendet werden können. Das Aktualisieren der Cluster verhindert potenzielle Workload-Fehler.

Die Kubernetes-Version 1.22 entfernt die Unterstützung der folgenden Beta-APIs. Migrieren Sie Ihre Manifeste und API-Clients basierend auf den folgenden Informationen:

Ressource	Betaversion	GA-Version	Hinweise
ValidatingWebhookConfiguration MutatingWebhookConfiguration	admissionregistration.k8s.io/v1beta1	admissionregistration.k8s.io/v1	webhooks[*].failurePolicy Standard von Ignore in Fail geändert für v1. webhooks[*].matchPolicy Standard von Exact in Equivalent geändert für v1. webhooks[*].timeoutSeconds Standard von 30s in 10s geändert für v1. webhooks[*].sideEffects Standardwert wird entfernt, das Feld ist ein Pflichtfeld, und nur None und NoneOnDryRun sind zulässig für v1. webhooks[*].admissionReviewVersions Standardwert wird entfernt und das Feld wird zum Pflichtfeld für v1 (unterstützte Versionen für AdmissionReview sind v1 und v1beta1).. webhooks[*].name muss in der Liste eindeutig sein für Objekte, die über admissionregistration.k8s.io/v1 erstellt wurden.
CustomResourceDefinition	apiextensions.k8s.io/v1beta1	apiextensions.k8s.io/v1	spec.scope wird nicht mehr standardmäßig auf Namespaced festgelegt und muss explizit angegeben werden. spec.version wird in v1 entfernt; verwenden Sie stattdessen spec.versions spec.validation wird in v1 entfernt; verwenden Sie stattdessen spec.versions[*].schema. spec.subresources wird in v1 entfernt; verwenden Sie stattdessen spec.versions[*].subresources. spec.additionalPrinterColumns wird in v1 entfernt; verwenden Sie stattdessen spec.versions[*].additionalPrinterColumns. spec.conversion.webhookClientConfig wird in v1 in spec.conversion.webhook.clientConfig verschoben. spec.conversion.conversionReviewVersions wird in v1 in spec.conversion.webhook.conversionReviewVersions verschoben. spec.versions[*].schema.openAPIV3Schema ist jetzt erforderlich, wenn Sie v1 CustomResourceDefinition Objekte erstellen, und muss ein Strukturschema sein. spec.preserveUnknownFields: true ist beim Erstellen von v1 CustomResourceDefinition Objekten nicht zulässig; muss in Schemadefinitionen als x-kubernetes-preserve-unknown-fields: true angegeben werden. In v1 wurde in additionalPrinterColumns Elementen das Feld JSONPath in jsonPath umbenannt (Behebung #66531).
APIService	apiregistration.k8s.io/v1beta1	apiregistration.k8s.io/v1	Keine
TokenReview	authentication.k8s.io/v1beta1	authentication.k8s.io/v1	Keine
SubjectAccessReview LocalSubjectAccessReview SelfSubjectAccessReview	authorization.k8s.io/v1beta1	authorization.k8s.io/v1	spec.group wurde in spec.groups umbenannt
CertificateSigningRequest	certificates.k8s.io/v1beta1	certificates.k8s.io/v1	Für API-Clients, die Zertifikate anfordern: spec.signerName ist jetzt erforderlich (siehe bekannte Kubernetes-Unterzeichner) und Anforderungen von kubernetes.io/legacy-unknown dürfen nicht über die API certificates.k8s.io/v1 erstellt werden. spec.usages ist jetzt erforderlich, darf keine doppelten Werte enthalten und darf nur bekannte Verwendungen enthalten Für API-Clients, die Zertifikate genehmigen oder signieren: status.conditions darf keine doppelten Typen enthalten status.conditions[*].status ist jetzt erforderlich status.certificate muss PEM-kodiert sein und darf nur CERTIFICATE-Blöcke enthalten
Lease	coordination.k8s.io/v1beta1	coordination.k8s.io/v1	Keine
Ingress	extensions/v1beta1 networking.k8s.io/v1beta1	networking.k8s.io/v1	spec.backend wurde in spec.defaultBackend umbenannt Das Backend-serviceName-Feld wurde in service.name umbenannt Numerische Backend-servicePort-Felder wurden in service.port.number umbenannt String-Backend-servicePort-Felder wurden in service.port.name umbenannt pathType ist jetzt für jeden angegebenen Pfad erforderlich. Die Optionen sind Prefix, Exact und ImplementationSpecific. Um ein nicht definiertes v1beta1-Verhalten abzubilden, verwenden Sie ImplementationSpecific
IngressClass	networking.k8s.io/v1beta1	networking.k8s.io/v1	Keine
RBAC	rbac.authorization.k8s.io/v1beta1	rbac.authorization.k8s.io/v1	Keine
PriorityClass	scheduling.k8s.io/v1beta1	scheduling.k8s.io/v1	Keine
CSIDriver CSINode StorageClass VolumeAttachment	storage.k8s.io/v1beta1	storage.k8s.io/v1	Keine

Weitere Informationen zur API-Entfernung finden Sie im Leitfaden zur Migration von veralteten APIs.