**Unterstützung für die Verbesserung dieser Seite beitragen** 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. Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link **Diese Seite bearbeiten auf**, der sich im rechten Bereich jeder Seite befindet. 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. # Selbstverwaltete Knoten für Ihren Cluster aktualisieren Wenn eine neue Amazon-EKS-optimierte AMI veröffentlicht wird, ziehen Sie in Betracht, die Knoten in Ihrer selbstverwalteten Knoten-Gruppe durch die neue AMI zu ersetzen. Ebenso gilt, dass Sie bei einer Aktualisierung der Kubernetes-Version für Ihren Amazon-EKS-Cluster auch die Worker-Knoten aktualisieren, um Knoten mit derselben Kubernetes-Version zu verwenden. **Wichtig** In diesem Thema werden Worker-Knotenaktualisierungen für selbstverwaltete Knotengruppen behandelt. Wenn Sie [verwaltete Knotengruppen](managed-node-groups.md) verwenden, lesen Sie [Eine verwaltete Knotengruppe für Ihren Cluster aktualisieren](update-managed-node-group.md). Es gibt zwei grundlegende Möglichkeiten, selbstverwaltete Knotengruppen in Ihren Clustern zu aktualisieren, um ein neues AMI zu verwenden: ** [Anwendungen zu einer neuen Knotengruppe migrieren](migrate-stack.md) ** Erstellen Sie eine neue Worker-Knotengruppe und migrieren Sie Ihre Pods zu dieser Gruppe. Die Migration zu einer neuen Knotengruppe ist sinnvoller als die Aktualisierung der AMI-ID in einem bestehenden AWS-CloudFormation-Stack. Dies liegt daran, dass der Migrationsprozess die alte Knotengruppe als `NoSchedule` [verunreinigt](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) und die Knoten leert, nachdem ein neuer Stack bereit ist, die vorhandene Pod-Workload zu akzeptieren. ** [AWS-CloudFormation-Knoten-Stack aktualisieren](update-stack.md) ** Aktualisieren Sie den AWS-CloudFormation-Stack für eine vorhandene Worker-Knotengruppe, um das neue AMI zu verwenden. Diese Methode wird nicht bei Knoten-Gruppen unterstützt, die mit `eksctl` erstellt wurden. # Anwendungen zu einer neuen 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-Managementkonsole benutzen. + [`eksctl`](#eksctl_migrate_apps) + [AWS-Managementkonsole und AWS CLI](#console_migrate_apps) ## `eksctl` **Migration Ihrer Anwendungen zu einer neuen Knotengruppe mit `eksctl` ** Weitere Informationen zur Verwendung von eksctl finden Sie unter [Upgrades von nicht verwalteten Knotengruppen](https://eksctl.io/usage/nodegroup-unmanaged/) in der `eksctl`-Dokumentation. Für diesen Vorgang ist `eksctl` Version `0.215.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](https://eksctl.io/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 ``` 1. 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 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, den Pod-Zugriff auf das IMDS zu blockieren, wenn die folgenden Bedingungen erfüllt sind: + Sie planen, allen Ihren Kubernetes-Servicekonten IAM-Rollen zuzuweisen, damit Pods nur die Mindestberechtigungen haben, die sie benötigen. + Keine Pods im Cluster benötigen aus anderen Gründen Zugriff auf den Amazon EC2 EC2-Instance-Metadaten-Service (IMDS), z. B. zum Abrufen der aktuellen Region. AWS Weitere Informationen finden Sie unter [Beschränken Sie den Zugriff auf das Instance-Profil, das dem Worker-Knoten zugewiesen ist](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). Um den Pod-Zugriff auf IMDS zu blockieren, fügen Sie dem folgenden Befehl die Option `--disable-pod-imds` hinzu. **Anmerkung** Weitere verfügbare Flags und deren Beschreibungen finden Sie unterhttps://eksctl.io/. ``` eksctl create nodegroup \ --cluster my-cluster \ --version 1.35 \ --name standard-nodes-new \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false ``` 1. 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 ``` 1. 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-Managementkonsole und AWS CLI **Migrieren Sie Ihre Anwendungen mit der AWS-Managementkonsole und AWS CLI auf eine neue Knotengruppe** 1. Starten Sie eine neue Knotengruppe, indem Sie die unter [Erstellen selbstverwalteter Amazon Linux-Knoten](launch-workers.md) beschriebenen Schritte befolgen. 1. Wenn Ihr Stack fertig erstellt wurde, wählen Sie ihn in der Konsole aus und klicken Sie auf **Outputs** (Ausgaben). 1. Notieren Sie das **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, 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](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) hinzugefügt haben. 1. Aktualisieren Sie die Sicherheitsgruppen für beide Worker-Knoten-Gruppen, sodass sie miteinander kommunizieren können. Weitere Informationen finden Sie unter [Anforderungen der Amazon-EKS-Sicherheitsgruppe für Cluster anzeigen](sec-group-reqs.md). 1. Notieren Sie die Sicherheitsgruppe IDs für beide Knotengruppen. Dies wird als **NodeSecurityGroup**Wert 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) ``` 1. 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. 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 ``` 1. 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 **NodeInstanceRole**Wert, den Sie in einem vorherigen Schritt aufgezeichnet haben.](#node-instance-role-step) Speichern und schließen Sie dann die Datei, um die aktualisierte configmap anzuwenden. 1. 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 ``` 1. (Optional) Wenn Sie [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/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 ``` 1. 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 finden Sie unter [Taints und Toleranzen](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) 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.33`) mit dem folgenden Code-Ausschnitt 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.33 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 ``` 1. Bestimmen 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 für die DNS-Auflösung, aber Ihr Cluster kann stattdessen `kube-dns` zurückgeben): ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. 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 ``` 1. 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, identifizieren und löschen Sie alle Knoten einer bestimmten Kubernetes-Version (in diesem Fall*1.33*) mit dem folgenden Codeausschnitt. ``` K8S_VERSION=1.33 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 ``` 1. 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 Stack, um die Instanzen zu beenden AWS CloudFormation . **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](https://github.com/kubernetes/autoscaler/tree/master/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 ``` 1. Öffnen Sie die [AWS CloudFormation -Konsole](https://console.aws.amazon.com/cloudformation/). 1. Wählen Sie Ihren alten Worker-Knoten-Stack aus. 1. Wählen Sie **Löschen** aus. 1. Wählen Sie im Bestätigungsdialogfeld **Stack löschen** **Stack löschen** aus. 1. 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. 1. (Optional) Wenn Sie den Kubernetes-[Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/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](https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws). AWS ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (Optional) Stellen Sie sicher, dass Sie die neueste Version des [Amazon-VPC-CNI-Plugins für Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) verwenden. Möglicherweise müssen Sie Ihre CNI-Version aktualisieren, um die neuesten unterstützten Instance-Typen zu nutzen. Weitere Informationen finden Sie unter [Pods mit dem Amazon VPC CNI zuweisen IPs](managing-vpc-cni.md). 1. Wenn Ihr Cluster `kube-dns` für die DNS-Auflösung verwendet (siehe [[migrate-determine-dns-step]](#migrate-determine-dns-step)), skalieren Sie in der `kube-dns`-Bereitstellung auf ein Replikat. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` # Einen AWS CloudFormation Knotenstapel aktualisieren In diesem Thema wird beschrieben, wie Sie einen vorhandenen AWS CloudFormation selbstverwalteten Knotenstapel mit einem neuen AMI aktualisieren können. Sie können diese Anleitung verwenden, um Ihre Knoten nach einer Cluster-Aktualisierung auf eine neue Version von Kubernetes zu aktualisieren. Andernfalls können Sie auf das neueste von Amazon EKS optimierte AMI für eine vorhandene Kubernetes-Version aktualisieren. **Wichtig** In diesem Thema werden Worker-Knotenaktualisierungen für selbstverwaltete Knotengruppen behandelt. Informationen zur Verwendung des [Vereinfachten Knoten-Lebenszyklus mit verwalteten Knotengruppen](managed-node-groups.md) finden Sie unter [Eine verwaltete Knotengruppe für Ihren Cluster aktualisieren](update-managed-node-group.md). Die neueste Amazon AWS CloudFormation EKS-Standardknotenvorlage ist so konfiguriert, dass eine Instance mit dem neuen AMI in Ihrem Cluster gestartet wird, bevor nacheinander eine alte entfernt wird. Diese Konfiguration stellt sicher, dass Sie immer über die gewünschte Anzahl der aktiven Instances Ihre Auto-Scaling-Gruppe in Ihrem Cluster verfügen, während die Aktualisierung durchgeführt wird. **Anmerkung** Diese Methode wird nicht bei Knoten-Gruppen unterstützt, die mit `eksctl` erstellt wurden. Wenn Sie Ihr Cluster oder Ihre Worker-Knoten-Gruppe Sie `eksctl` erstellt haben, finden Sie Informationen unter [Anwendungen zu einer neuen Knotengruppe migrieren](migrate-stack.md). 1. Bestimmen 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 stattdessen `kube-dns` zurückgeben. Ihre Ausgabe kann je nach verwendeter `kubectl`-Version anders aussehen. ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. Wenn Ihre aktuelle Bereitstellung weniger als zwei Replikate ausführt, skalieren die Bereitstellung auf zwei Replikate. Ersetzen Sie `kube-dns` durch *coredns*, falls Ihre vorherige Befehlsausgabe dies stattdessen zurückgegeben hat. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. (Optional) Wenn Sie Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) 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 ``` 1. Bestimmen Sie den gewünschten Instance-Typ und die gewünschte Anzahl von Instances Ihrer aktuellen Knotengruppe. Sie geben diese Werte später ein, wenn Sie die AWS CloudFormation Vorlage für die Gruppe aktualisieren. 1. Öffnen Sie die Amazon EC2 EC2-Konsole unter https://console.aws.amazon.com/ec2/. 1. Wählen Sie im linken Navigationsbereich **Launch Configurations** (Startkonfigurationen) aus und beachten Sie den Instance-Typ für die Startkonfiguration der vorhandenen Knoten. 1. Wählen Sie im linken Navigationsbereich **Auto Scaling Groups** (Auto-Scaling-Gruppen) aus und beachten Sie die **Desired** (gewünschte) Instance-Anzahl für die Auto-Scaling-Gruppe der vorhandenen Knoten. 1. Öffnen Sie die [AWS CloudFormation -Konsole](https://console.aws.amazon.com/cloudformation/). 1. Wählen Sie Ihren Workerknoten-Gruppen-Stack aus und klicken Sie dann auf **Update (Aktualisieren)**. 1. Wählen Sie **Replace current template (Aktuelle Vorlage ersetzen)** und dann **Amazon S3 URL (Amazon S3-URL)** aus. 1. Fügen Sie für **Amazon S3 S3-URL** die folgende URL in den Textbereich ein, um sicherzustellen, dass Sie die neueste Version der AWS CloudFormation Node-Vorlage verwenden. Klicken Sie dann auf **Next (Weiter)**: ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml ``` 1. Geben Sie auf der Seite **Specify stack details (Stack-Details angeben)** die folgenden Parameter ein und wählen Sie **Next (Weiter)** aus: + **NodeAutoScalingGroupDesiredCapacity**— Geben Sie die gewünschte Anzahl von Instanzen ein, die Sie in einem [vorherigen Schritt](#existing-worker-settings-step) aufgezeichnet haben. Oder geben Sie die neue gewünschte Anzahl von Knoten ein, auf die bei der Aktualisierung Ihres Stacks skaliert werden soll. + **NodeAutoScalingGroupMaxSize**— Geben Sie die maximale Anzahl von Knoten ein, auf die Ihre Node-Auto-Scaling-Gruppe skalieren kann. Dieser Wert muss mindestens einen Knoten größer sein als Ihre gewünschte Kapazität. Auf diese Weise können Sie eine fortlaufende Aktualisierung Ihrer Knoten durchführen, ohne die Knotenanzahl während der Aktualisierung zu reduzieren. + **NodeInstanceType**— Wählen Sie den Instance-Typ, den Sie in einem [vorherigen Schritt](#existing-worker-settings-step) aufgezeichnet haben. Wählen Sie alternativ einen anderen Instance-Typ für Ihre Knoten aus. Bevor Sie sich für einen anderen Instance-Typ entscheiden, lesen Sie den Abschnitt [Auswahl eines optimalen Knoten-Instance-Typs für Amazon EC2](choosing-instance-type.md). Jeder Amazon-EC2-Instance-Typ unterstützt eine maximale Anzahl von Elastic-Network-Interfaces (ENIs) und jedes ENI unterstützt eine maximale Anzahl von IP-Adressen. Da jedem Worker-Knoten und Pod eine eigene IP-Adresse zugewiesen wird, ist es wichtig, einen Instance-Typ auszuwählen, der die maximale Anzahl von Pods unterstützt, die Sie auf jedem Amazon-EC2-Knoten ausführen möchten. Eine Liste der Netzwerkschnittstellen und IP-Adressen, die von Instance-Typen unterstützt werden, finden Sie unter [IP-Adressen pro Netzwerkschnittstelle pro Instance-Typ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI). Der Instance–Typ `m5.large` unterstützt zum Beispiel maximal 30 IP-Adressen für den Worker-Knoten und die Pods. **Anmerkung** Die unterstützten Instance-Typen für die neueste Version des [Amazon-VPC-CNI-Plugins für Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) sind in [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) auf GitHub aufgeführt. Möglicherweise müssen Sie Ihr Amazon-VPC-CNI-Plugin für die Kubernetes-Version aktualisieren, um die neuesten unterstützten Instance-Typen zu verwenden. Weitere Informationen finden Sie unter [Pods mit dem Amazon VPC CNI zuweisen IPs](managing-vpc-cni.md). **Wichtig** Einige Instance-Typen sind möglicherweise nicht in allen AWS Regionen verfügbar. + **NodeImageIdSSMParam**— Der Amazon EC2 Systems Manager Manager-Parameter der AMI-ID, auf die Sie aktualisieren möchten. Der folgende Wert verwendet das neueste Amazon-EKS-optimierte AMI für Kubernetes-Version `1.35`. ``` /aws/service/eks/optimized-ami/1.35/amazon-linux-2/recommended/image_id ``` Sie können es durch eine [Plattformversion *1.35* ersetzen, die identisch](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) ist. Oder er sollte bis zu einer Version älter sein als die Kubernetes-Version, die auf Ihrer Steuerebene läuft. Es wird empfohlen, die Knoten auf der gleichen Version wie die Steuerungsebene zu halten. Sie können es auch *amazon-linux-2* durch einen anderen AMI-Typ ersetzen. Weitere Informationen finden Sie unter [Rufen Sie das empfohlene Amazon Linux AMI ab IDs](retrieve-ami-id.md). **Anmerkung** Mit dem Amazon-EC2-Systems-Manager-Parameter können Sie Ihre Worker-Knoten in Zukunft aktualisieren, ohne eine AMI-ID suchen und angeben zu müssen. Wenn Ihr AWS CloudFormation Stack diesen Wert verwendet, startet jedes Stack-Update immer das neueste empfohlene Amazon EKS-optimierte AMI für Ihre angegebene Kubernetes-Version. Dies ist auch dann der Fall, wenn Sie keine Werte in der Vorlage ändern. + **NodeImageId**— Um Ihr eigenes benutzerdefiniertes AMI zu verwenden, geben Sie die ID ein, die das AMI verwenden soll. **Wichtig** Dieser Wert überschreibt jeden Wert, der für **NodeImageIdSSMParam**angegeben wurde. Wenn Sie den **NodeImageIdSSMParam**Wert verwenden möchten, stellen Sie sicher, dass der Wert für leer **NodeImageId**ist. + **Deaktivieren IMDSv1** — Standardmäßig unterstützt jeder Knoten den Instanz-Metadatendienst Version 1 (IMDSv1) und IMDSv2. Sie können ihn jedoch deaktivieren IMDSv1. Wählen Sie **true** aus, wenn Sie nicht möchten, dass in der Knotengruppe geplante Knoten oder Pods verwendet IMDSv1 werden. Weitere Informationen finden Sie unter [Konfiguration des Instance-Metadatenservice](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Wenn Sie IAM-Rollen für Dienstkonten implementiert haben, weisen Sie allen Pods, die Zugriff auf AWS Dienste benötigen, die erforderlichen Berechtigungen direkt zu. Auf diese Weise benötigen keine Pods in Ihrem Cluster Zugriff auf IMDS aus anderen Gründen, z. B. zum Abrufen der aktuellen Region. AWS Anschließend können Sie den Zugriff auf auch IMDSv2 für Pods deaktivieren, die kein Host-Netzwerk verwenden. Weitere Informationen finden Sie unter [Beschränken Sie den Zugriff auf das Instance-Profil, das dem Worker-Knoten zugewiesen ist](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). 1. (Optional) Markieren Sie auf der Seite **Options (Optionen)** Ihre Stack-Ressourcen. Wählen Sie **Weiter** aus. 1. Überprüfen Sie Ihre Angaben auf der Seite **Review** (Überprüfen), bestätigen Sie, dass der Stack IAM-Ressourcen erstellen kann, und klicken Sie dann auf **Update stack** (Stack aktualisieren). **Anmerkung** Die Aktualisierung jedes Knotens im Cluster dauert mehrere Minuten. Warten Sie, bis die Aktualisierung aller Knoten abgeschlossen ist, bevor Sie die nächsten Schritte durchführen. 1. Wenn der DNS-Anbieter Ihres Clusters `kube-dns` ist, skalieren Sie die `kube-dns`-Bereitstellung auf ein Replikat. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` 1. (Optional) Wenn Sie den Kubernetes-[Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) verwenden, skalieren Sie die Bereitstellung zurück auf die gewünschte Zahl von Replikaten. ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (Optional) Stellen Sie sicher, dass Sie die neueste Version des [Amazon-VPC-CNI-Plugins für Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) verwenden. Möglicherweise müssen Sie Ihr Amazon-VPC-CNI-Plugin für die Kubernetes-Version aktualisieren, um die neuesten unterstützten Instance-Typen zu verwenden. Weitere Informationen finden Sie unter [Pods mit dem Amazon VPC CNI zuweisen IPs](managing-vpc-cni.md).