Anwendungen auf eine neue Knotengruppe migrieren - Amazon EKS

Helfen Sie mit, diese Seite zu verbessern

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.

Möchten Sie zu diesem Benutzerhandbuch beitragen? Wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet. Ihre Beiträge werden dazu beitragen, dass unser Benutzerhandbuch für alle besser wird.

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.

Anwendungen auf eine neue Knotengruppe migrieren

Dieses Thema beschreibt Hinweise zum Erstellen einer neuen Knoten-Gruppe, zum ordnungsgemäßen Migrieren Ihrer vorhandenen Anwendungen zur neuen Gruppe und zum Entfernen der alten Knoten-Gruppe aus Ihrem Cluster. Sie können zu einer neuen Knotengruppe migrieren, indem Sie eksctl oder AWS Management Console benutzen.

eksctl

Migrieren Sie Ihre Anwendungen auf eine neue Knotengruppe mit eksctl

Weitere Informationen zur Verwendung von eksctl für die Migration finden Sie in der Dokumentation unter Unmanaged Nodegroups. eksctl

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

eksctl version

Eine Installations- und Upgrade-Anleitung für eksctl finden Sie in der Dokumentation zu eksctl unter Installation.

Anmerkung

Dieses Verfahren funktioniert nur für Cluster, die mit eksctl erstellt wurden.

  1. Rufen Sie den Namen Ihrer vorhandenen Knotengruppen ab und ersetzen Sie my-cluster durch Ihren Clusternamen.

    eksctl get nodegroups --cluster=my-cluster

    Eine Beispielausgabe sieht wie folgt aus.

    CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID default standard-nodes 2019-05-01T22:26:58Z 1 4 3 t3.medium ami-05a71d034119ffc12
  2. Starten Sie eine neue Knotengruppe mit eksctl mit dem folgenden Befehl. Ersetzen Sie im Befehl jedes example value durch Ihre eigenen Werte. Die Versionsnummer darf nicht später sein als Kubernetes Version für Ihre Steuerungsebene. Außerdem können nicht mehr als zwei Nebenversionen vor der Kubernetes Version für Ihre Steuerebene. Es wird empfohlen, dieselbe Version wie die Steuerebene zu verwenden.

    Wir empfehlen das Blockieren Pod Zugriff auf IMDS, wenn die folgenden Bedingungen zutreffen:

    • Sie planen, all Ihren IAM-Rollen zuzuweisen Kubernetes Dienstkonten, sodass Pods haben nur die Mindestberechtigungen, die sie benötigen.

    • Nein Pods im Cluster benötigen aus anderen Gründen Zugriff auf den Amazon EC2 Instance Metadata Service (IMDS), z. B. zum Abrufen der aktuellen AWS Region.

      Weitere Informationen finden Sie unter Beschränken Sie den Zugriff auf das Instance-Profil, das dem Worker-Knoten zugewiesen ist.

      Um zu blockieren Pod Fügen Sie dem folgenden Befehl die --disable-pod-imds Option hinzu, um Zugriff auf IMDS zu erhalten.

      Anmerkung

      Weitere verfügbare Flags und deren Beschreibungen finden Sie unterhttps://eksctl.io/.

    eksctl create nodegroup \ --cluster my-cluster \ --version 1.31 \ --name standard-nodes-new \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false
  3. Wenn der vorherige Befehl abgeschlossen ist, bestätigen Sie mit folgendem Befehl, dass alle Ihre Worker-Knoten den Ready-Status erreicht haben:

    kubectl get nodes
  4. Löschen Sie die ursprüngliche Knotengruppe mit dem folgenden Befehl. Ersetzen Sie im Befehl alle example value mit Ihren Cluster- und Knotengruppennamen:

    eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old

AWS Management Console und AWS CLI

Migrieren Sie Ihre Anwendungen mit der AWS Management Console und AWS CLI auf eine neue Knotengruppe

  1. Starten Sie eine neue Knotengruppe, indem Sie die unter Selbstverwalteten Amazon Linux-Knoten erstellen beschriebenen Schritte ausführen.

  2. Wenn Ihr Stack fertig erstellt wurde, wählen Sie ihn in der Konsole aus und klicken Sie auf Outputs (Ausgaben).

  3. Notieren Sie das NodeInstanceRolefür die Knotengruppe, die erstellt wurde. Sie benötigen diese Informationen zum Hinzufügen der neuen Amazon EKS-Knoten zu Ihrem Cluster.

    Anmerkung

    Wenn Sie der IAM-Rolle Ihrer alten Knotengruppen zusätzliche IAM-Richtlinien angefügt haben, dann sollten Sie die gleichen Richtlinien auch der IAM-Rolle Ihrer neuen Knotengruppe zuweisen, um diese Funktionalität für die neue Gruppe zu erhalten. Dies gilt für Sie, wenn Sie beispielsweise Berechtigungen für den Kubernetes Cluster Autoscaler hinzugefügt haben.

  4. Aktualisieren Sie die Sicherheitsgruppen für beide Worker-Knoten-Gruppen, sodass sie miteinander kommunizieren können. Weitere Informationen finden Sie unter Amazon EKS-Sicherheitsgruppenanforderungen für Cluster anzeigen.

    1. Notieren Sie die Sicherheitsgruppe IDs für beide Knotengruppen. Dies wird als NodeSecurityGroupWert in den AWS CloudFormation Stack-Ausgaben angezeigt.

      Sie können die folgenden AWS CLI-Befehle verwenden, um die Sicherheitsgruppe IDs aus den Stack-Namen abzurufen. In diesen Befehlen oldNodes steht der AWS CloudFormation Stack-Name für Ihren älteren Knoten-Stack und newNodes der Name des Stacks, zu dem Sie migrieren. Ersetzen Sie jede example value durch Ihre eigenen Werte.

      oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text)
    2. Fügen Sie Regeln für eingehenden Datenverkehr für jede Worker-Knoten-Sicherheitsgruppe hinzu, sodass sie voneinander Datenverkehr annehmen können.

      Die folgenden AWS CLI-Befehle fügen jeder Sicherheitsgruppe Regeln für eingehenden Datenverkehr hinzu, die den gesamten Datenverkehr auf allen Protokollen der anderen Sicherheitsgruppe zulassen. Diese Konfiguration ermöglicht Pods in jeder Knotengruppe, um miteinander zu kommunizieren, während Sie Ihre Arbeitslast in die neue Gruppe migrieren.

      aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 authorize-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1
  5. Bearbeiten Sie die aws-auth-configmap, um die neue Worker-Knoten-Instance-Rolle in RBAC zuzuordnen.

    kubectl edit configmap -n kube-system aws-auth

    Fügen Sie einen neuen mapRoles-Eintrag für die neue Worker-Knoten-Gruppe hinzu.

    apiVersion: v1 data: mapRoles: | - rolearn: ARN of instance role (not instance profile) username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> - rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes

    Ersetzen Sie das ARN of instance role (not instance profile) Snippet durch den NodeInstanceRoleWert, den Sie in einem vorherigen Schritt aufgezeichnet haben. Speichern und schließen Sie dann die Datei, um die aktualisierte configmap anzuwenden.

  6. Achten Sie auf den Status Ihrer Knoten und warten Sie, bis Ihre neuen Worker-Knoten Ihrem Cluster beigetreten sind und den Status Ready angenommen haben.

    kubectl get nodes --watch
  7. (Optional) Wenn Sie den Kubernetes Cluster Autoscaler verwenden, skalieren Sie die Bereitstellung auf Null (0) Replikate, um widersprüchliche Skalierungsaktionen zu vermeiden.

    kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system
  8. Verwenden Sie den folgenden Befehl, um jeden der Knoten, die Sie mit NoSchedule entfernen möchten, mit einem Taint zu versehen. Das ist so neu Pods wurden auf den Knoten, die Sie ersetzen, weder geplant noch neu geplant. Weitere Informationen finden Sie unter Taints and Tolerations in der Kubernetes -Dokumentation.

    kubectl taint nodes node_name key=value:NoSchedule

    Wenn Sie Ihre Knoten auf ein neues aktualisieren Kubernetes Mit dieser Version können Sie alle Knoten einer bestimmten Version identifizieren und manipulieren Kubernetes Version (in diesem Fall1.30) mit dem folgenden Codeausschnitt. Die Versionsnummer darf nicht später sein als Kubernetes Version Ihrer Steuerungsebene. Es können auch nicht mehr als zwei Nebenversionen vor der Version sein Kubernetes Version Ihrer Steuerebene. Es wird empfohlen, dieselbe Version wie die Steuerebene zu verwenden.

    K8S_VERSION=1.30 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Tainting $node" kubectl taint nodes $node key=value:NoSchedule done
  9. Ermitteln Sie den DNS-Anbieter Ihres Clusters.

    kubectl get deployments -l k8s-app=kube-dns -n kube-system

    Eine Beispielausgabe sieht wie folgt aus. Dieser Cluster verwendet CoreDNS für die DNS-Auflösung, aber Ihr Cluster kann kube-dns stattdessen zurückkehren):

    NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m
  10. Wenn Ihre aktuelle Bereitstellung weniger als zwei Replikate ausführt, skalieren die Bereitstellung auf zwei Replikate. Ersetzen Sie kubedns durch coredns, falls Ihre vorherige Befehlsausgabe dies stattdessen zurückgegeben hat.

    kubectl scale deployments/coredns --replicas=2 -n kube-system
  11. Lassen Sie die einzelnen Knoten, die Sie aus Ihrem Cluster entfernen möchten, mit dem folgenden Befehl sperren:

    kubectl drain node_name --ignore-daemonsets --delete-local-data

    Wenn Sie Ihre Knoten auf ein neues aktualisieren Kubernetes Version, identifiziere und lösche alle Knoten einer bestimmten Kubernetes Version (in diesem Fall1.30) mit dem folgenden Codeausschnitt.

    K8S_VERSION=1.30 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-local-data done
  12. Nachdem die alten Knoten entladen wurden, widerrufen Sie die Regeln für eingehenden Datenverkehr für Sicherheitsgruppen, die Sie zuvor autorisiert haben. Löschen Sie anschließend den AWS CloudFormation Stack, um die Instanzen zu beenden.

    Anmerkung

    Wenn Sie Ihrer alten Knotengruppen-IAM-Rolle zusätzliche IAM-Richtlinien hinzugefügt haben, z. B. das Hinzufügen von Berechtigungen für den Kubernetes Cluster Autoscaler, trennen Sie diese zusätzlichen Richtlinien von der Rolle, bevor Sie Ihren Stack löschen können. AWS CloudFormation

    1. Heben Sie die Regeln für eingehenden Datenverkehr auf, die Sie zuvor für die Knoten-Sicherheitsgruppen erstellt haben. In diesen Befehlen oldNodes steht der AWS CloudFormation Stack-Name für Ihren älteren Knoten-Stack und newNodes der Name des Stacks, zu dem Sie migrieren.

      oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 revoke-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1
    2. Öffnen Sie die AWS CloudFormation -Konsole.

    3. Wählen Sie Ihren alten Worker-Knoten-Stack aus.

    4. Wählen Sie Delete (Löschen).

    5. Wählen Sie im Bestätigungsdialogfeld Stack löschen Stack löschen aus.

  13. Bearbeiten Sie die aws-auth-configmap, um die alten Worker-Knoten-Instance-Rolle aus RBAC zu entfernen.

    kubectl edit configmap -n kube-system aws-auth

    Löschen Sie den mapRoles-Eintrag für die alte Worker-Knoten-Gruppe.

    apiVersion: v1 data: mapRoles: | - rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: arn:aws: iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes>

    Speichern und schließen Sie die Datei, um die aktualisierte configmap anzuwenden.

  14. (Optional) Wenn Sie den Kubernetes-Cluster Autoscaler verwenden, skalieren Sie die Bereitstellung wieder auf ein Replikat.

    Anmerkung

    Außerdem müssen Sie Ihre neue Auto-Scaling-Gruppe (z. B. k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster) mit einem Tag versehen und den Befehl für die Cluster-Autoscaler-Bereitstellung so aktualisieren, dass er auf die neu getaggte Auto-Scaling-Gruppe verweist. Weitere Informationen finden Sie unter Cluster Autoscaler on. AWS

    kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system
  15. (Optional) Stellen Sie sicher, dass Sie die neueste Version des Amazon VPC CNI-Plug-ins für Kubernetes verwenden. Möglicherweise müssen Sie Ihre CNI-Version aktualisieren, um die neuesten unterstützten Instance-Typen zu nutzen. Weitere Informationen finden Sie unter Zuweisen IPs zu Pods mit dem Amazon VPC CNI.

  16. Wenn Ihr Cluster die DNS-Auflösung kube-dns verwendet (siehe[migrate-determine-dns-step]), skalieren Sie die kube-dns Bereitstellung auf ein Replikat.

    kubectl scale deployments/kube-dns --replicas=1 -n kube-system