Anwendungen auf eine neue Knotengruppe migrieren

So migrieren Sie Ihre Anwendungen mit eksctl zu einer neuen Worker-Knoten-Gruppe

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.189.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.

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 alle Beispielwert mit deinen eigenen Werten. Die Versionsnummer darf nicht höher als die Kubernetes-Version für Ihre Steuerebene sein. Außerdem darf sie nicht mehr als zwei Nebenversionen älter sein als die Kubernetes-Version für Ihre Steuerebene. Es wird empfohlen, dieselbe Version wie die Steuerebene zu verwenden.

   Wir empfehlen, Pod den Zugriff zu sperren, IMDS wenn die folgenden Bedingungen zutreffen:

   • Sie planen, all Ihren Kubernetes Dienstkonten IAM Rollen zuzuweisen, sodass sie Pods nur über die Mindestberechtigungen verfügen, die sie benötigen.

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

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

   Um den Pod Zugriff auf zu blockierenIMDS, fügen Sie dem folgenden Befehl die --disable-pod-imds Option hinzu.

   Anmerkung

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

   eksctl create nodegroup \
     --cluster my-cluster \
     --version 1.30 \
     --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
   

Um Ihre Anwendungen mit dem AWS Management Console und in eine neue Knotengruppe zu migrieren AWS CLI

1. Starten Sie eine neue Knoten-Gruppe, indem Sie die unter Erstellen Sie selbstverwaltete Amazon Linux-Knoten beschriebenen Schritte ausführen.

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

3. Notieren Sie das NodeInstanceRolefür die Knotengruppe, die erstellt wurde. Sie benötigen dies, um die neuen EKS Amazon-Knoten zu Ihrem Cluster hinzuzufügen.

   Anmerkung

   Wenn Sie Ihrer alten IAM Knotengruppenrolle zusätzliche IAM Richtlinien angehängt haben, fügen Sie dieselben Richtlinien Ihrer neuen IAM Knotengruppenrolle hinzu, um diese Funktionalität in der neuen Gruppe beizubehalten. 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 EKSAmazon-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 Knotenstapel 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.

      Mit den folgenden AWS CLI Befehlen werden jeder Sicherheitsgruppe Regeln für eingehenden Datenverkehr hinzugefügt, die den gesamten Datenverkehr über alle Protokolle der anderen Sicherheitsgruppe zulassen. Auf diese Weise können Pods in jeder Knoten-Gruppe miteinander kommunizieren, während Sie Ihr Workload zur neuen 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 Knoteninstanzrolle zuzuordnen. RBAC

   kubectl edit configmap -n kube-system aws-auth
   

   Fügen Sie einen neuen mapRoles-Eintrag für die neue Worker-Knoten-Gruppe hinzu. Wenn sich Ihr Cluster in den Ländern AWS GovCloud (USA-Ost) oder AWS GovCloud (US-West) befindet AWS-Regionen, ersetzen Sie ihn durch. arn:aws: arn:aws-us-gov:

   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 nach unten auf null (0) Replikate, um Konflikte zwischen 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. Auf diese Weise werden neue Pods auf den Knoten, die Sie ersetzen, nicht geplant oder neu geplant. Weitere Informationen zu finden Sie unter Taints and Tolerations (Taints und Toleranzen) in der Kubernetes-Dokumentation.

   kubectl taint nodes node_name key=value:NoSchedule
   

   Wenn Sie Ihre Knoten auf eine neue Kubernetes-Version aktualisieren, können Sie alle Knoten einer bestimmten Kubernetes-Version (in diesem Fall 1.28) mit dem folgenden Codeausschnitt identifizieren und mit einem Taint versehen. Die Versionsnummer darf nicht höher als die Kubernetes-Version Ihrer Steuerebene sein. Sie darf auch nicht mehr als zwei Nebenversionen älter sein als die Kubernetes-Version Ihrer Steuerebene. Es wird empfohlen, dieselbe Version wie die Steuerebene zu verwenden.

   K8S_VERSION=1.28
   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 Anbieter Ihres Clusters. DNS

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

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

   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 eine neue Kubernetes-Version aktualisieren, können Sie alle Knoten einer bestimmten Kubernetes-Version (in diesem Fall 1.28) mit dem folgenden Codeausschnitt identifizieren und leeren.

    K8S_VERSION=1.28
    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 IAM Knotengruppenrolle 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 unter https://console.aws.amazon.com/cloudformation.

    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 alte Knoteninstanzrolle aus zu entfernen. RBAC

    kubectl edit configmap -n kube-system aws-auth
    

    Löschen Sie den mapRoles-Eintrag für die alte Worker-Knoten-Gruppe. Wenn sich Ihr Cluster in den Ländern AWS GovCloud (USA-Ost) oder AWS GovCloud (US-West) befindet AWS-Regionen, ersetzen Sie ihn durch. arn:aws: arn:aws-us-gov:

    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) Vergewissern Sie sich, dass Sie die neueste Version des VPCCNIAmazon-Plug-ins für Kubernetes verwenden. Möglicherweise müssen Sie Ihre CNI Version aktualisieren, um die neuesten unterstützten Instance-Typen zu verwenden. Weitere Informationen finden Sie unter IPsDem Pods Amazon zuordnen VPC CNI.

16. Wenn Ihr Cluster kube-dns zur DNS Auflösung verwendet (siehe vorherigen Schritt), skalieren Sie die kube-dns Bereitstellung auf ein Replikat.

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