Migrieren zu einer neuen Worker-Knoten-Gruppe - Amazon EKS

Migrieren zu einer neuen Worker-Knoten-Gruppe

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

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

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

eksctl version

Weitere Informationen zur Installation oder zum Upgrade von eksctl finden Sie im Abschnitt Installieren oder Aktualisieren von eksctl.

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>(einschließlich<>) durch Ihren Clusternamen.

    eksctl get nodegroups --cluster=<my-cluster>

    Ausgabe:

    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 miteksctlErsetzen Sie das durch den folgenden Befehl<example values>(einschließlich<>) durch eigene Werte. Die Versionsnummer darf nicht höher sein als die Kubernetes-Version Ihrer Steuerungsebene und darf nicht mehr als zwei Nebenversionen vor der Kubernetes-Version Ihrer Steuerungsebene sein. Es wird jedoch empfohlen, dieselbe Version wie Ihre Steuerungsebene zu verwenden. Wenn Sie planen, IAM-Rollen allen Kubernetes-Dienstkonten zuzuweisen, sodass Pods nur über die erforderlichen Mindestberechtigungen verfügen und keine Pods im Cluster aus anderen Gründen Zugriff auf den Amazon EC2 Instance-Metadatendienst (IMDS) benötigen, z. B. das Abrufen der aktuellen Region, empfehlen wir Ihnen, Blockieren des Pod-Zugriffs auf IMDS. Weitere Informationen erhalten Sie unter IAM-Rollen für Servicekonten und Einschränken des Zugriffs auf die Anmeldeinformationen des IMDS- und Amazon EC2-Instance-Profils. Wenn Sie den Pod-Zugriff auf IMDS blockieren möchten, fügen Sie dann das--disable-pod-imdsauf den folgenden Befehl.

    Anmerkung

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

    eksctl create nodegroup \ --cluster <my-cluster> \ --version <1.21> \ --name <standard-nodes-new> \ --node-type <t3.medium> \ --nodes <3> \ --nodes-min <1> \ --nodes-max <4> \ --node-ami auto
  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 dabei <example values> (einschließlich <>) durch Ihrem Cluster und Ihren Knotengruppe Namen:

    eksctl delete nodegroup --cluster <my-cluster> --name <standard-nodes>

So migrieren Sie Ihre Anwendungen mit zu einer neuen Knoten-Gruppe mit AWS Management Console und AWS CLI

  1. Starten Sie eine neue Worker-Knoten-Gruppe, indem Sie die unter Starten selbstverwalteter 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 die NodeInstanceRole fü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 (um beispielsweise Berechtigungen für den Kubernetes-Cluster Autoscaler hinzuzufügen), 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.

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

    1. Notieren Sie die Sicherheitsgruppen-IDs beider Worker-Knoten-Gruppen. Sie werden als Wert für NodeSecurityGroup in den AWS CloudFormation-Stack-Ausgaben angezeigt.

      Sie können zum Anfordern der Sicherheitsgruppen-IDs anhand der Stack-Namen die folgenden AWS CLI-Befehle verwenden. In diesen Befehlen ist oldNodes der AWS CloudFormation-Stack-Name für den älteren Worker-Knoten-Stack, und newNodes ist der Name des Stacks, zu dem migriert werden soll. Ersetzen Sie die<example values>(einschließlich<>) mit Ihren eigenen.

      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 zu jeder Sicherheitsgruppe, die Datenverkehr mit allen Protokolle von der anderen Sicherheitsgruppe zulässt, Regeln für eingehenden Datenverkehr hinzu. Auf diese Weise können Pods in jeder Worker-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 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 den Ausschnitt <ARN of instance role (not instance profile)><ARN of instance role (not instance profile)> durch den Wert von NodeInstanceRole, den Sie unter notiert haben. Speichern und schließen Sie dann die Datei, um die aktualisierte configmap zu übernehmen.

  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 0 Replikate, um Konflikte zwischen Skalierungsaktionen zu vermeiden.

    kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system
  8. Tainten Sie jeden Knoten, den Sie entfernen möchten, mit NoSchedule (sodass auf den zu ersetzenden Knoten keine neuen Pods geplant oder erneut geplant werden), indem Sie den folgenden Befehl verwenden:

    kubectl taint nodes <node_name> key=value:NoSchedule

    Wenn Sie Ihre Worker-Knoten auf eine neue Kubernetes-Version aktualisieren, können Sie alle Knoten einer bestimmten Kubernetes-Version (in diesem Fall ) mit dem folgenden Codeausschnitt identifizieren und tainten. Die Versionsnummer darf nicht höher sein als die Kubernetes-Version Ihrer Steuerungsebene und darf nicht mehr als zwei Nebenversionen vor der Kubernetes-Version Ihrer Steuerungsebene sein. Es wird jedoch empfohlen, dieselbe Version wie Ihre Steuerungsebene zu verwenden.

    K8S_VERSION=<1.19> 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. Bestimmen Sie den DNS-Anbieter Ihres Clusters.

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

    Geben Sie Folgendes aus (dieser Cluster verwendet für die DNS-Auflösung coredns, Ihr Cluster kann stattdessen jedoch kube-dns 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.19) mit dem folgenden Codeausschnitt identifizieren und sperren.

    K8S_VERSION=<1.19> 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 Ihre alten Worker-Knoten gesperrt wurden, widerrufen Sie die Regeln für eingehenden Datenverkehr der Sicherheitsgruppe, die Sie zuvor autorisiert haben, und löschen Sie den AWS CloudFormation-Stack, um die Instances zu beenden.

    Anmerkung

    Wenn Sie der IAM-Rolle Ihrer alten Knotengruppen zusätzliche IAM-Richtlinien angefügt haben (um beispielsweise Berechtigungen für den Kubernetes-Cluster Autoscaler hinzuzufügen), dann müssen Sie diese zusätzlichen Richtlinien zuerst von der Rolle trennen, bevor Sie den AWS CloudFormation-Stack löschen können.

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

      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 Actions (Aktionen) und danach Delete Stack (Stack löschen).

  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/<YOUR CLUSTER NAME>) 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 -CNI-Plugins für Kubernetes verwenden. Möglicherweise müssen Sie Ihre CNI-Version aktualisieren, um die Vorteile der neuesten unterstützten Instance-Typen zu nutzen. Weitere Informationen finden Sie unter Aktualisieren des selbstverwalteten Amazon-VPC-CNI-Add-ons.

  16. Wenn Ihr Cluster für die DNS-Auflösung kube-dns verwendet (siehe voriger Schritt), skalieren Sie in der kube-dns-Bereitstellung auf ein Replikat.

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