**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. # Knoten selbst mit selbstverwalteten Knoten verwalten Ein Cluster enthält einen oder mehrere Amazon-EC2-Knoten, auf denen Pods geplant sind. Amazon-EKS-Knoten werden in Ihrem AWS-Konto ausgeführt und stellen eine Verbindung zur Steuerebene Ihres Clusters über den Cluster-API-Server-Endpunkt her. Sie werden basierend auf Amazon-EC2-Preisen in Rechnung gestellt. Weitere Informationen dazu finden Sie unter [Amazon EC2 – Preise](https://aws.amazon.com/ec2/pricing/). Ein Cluster kann mehrere Knotengruppen enthalten. Jede Knotengruppe enthält eine oder mehrere Knoten, die in einer [Gruppe von Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html) bereitgestellt werden. Der Instance-Typ der Knoten innerhalb der Gruppe kann variieren, z. B. wenn die [attributbasierte Instance-Typauswahl](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) mit [Karpenter](https://karpenter.sh/) verwendet wird. Alle Instances in einer Knotengruppe müssen die [Amazon-EKS-Knoten-IAM-Rolle](create-node-role.md) verwenden. Amazon EKS bietet spezialisierte Amazon Machine Images (AMIs), die als für Amazon EKS optimierte AMIs bezeichnet werden. Die AMIs sind so konfiguriert, dass sie mit Amazon EKS funktionieren. Zu ihren Komponenten gehören `containerd`, `kubelet`, und der AWS-IAM-Authenticator. Das AMI enthält auch ein spezialisiertes [Bootstrap-Skript](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh), mit dem Sie die Steuerebene Ihres Clusters automatisch erkennen und eine Verbindung damit herstellen können. Wenn Sie den Zugriff auf den öffentlichen Endpunkt Ihres Clusters mithilfe von CIDR-Blöcken einschränken, empfehlen wir, dass Sie auch den privaten Endpunktzugriff aktivieren. Auf diese Weise können Knoten mit dem Cluster kommunizieren. Wenn der private Endpunkt nicht aktiviert ist, müssen die CIDR-Blöcke, die Sie für den öffentlichen Zugriff angeben, die Ausgangsquellen aus Ihrer VPC enthalten. Weitere Informationen finden Sie unter [Cluster-API-Server-Endpunkt](cluster-endpoint.md). Informationen zum Hinzufügen selbstverwalteter Knoten zu Ihrem Amazon-EKS-Cluster finden Sie in den folgenden Themen. Wenn Sie selbstverwaltete Knoten manuell starten, fügen Sie jedem Knoten das folgende Tag hinzu und stellen Sie sicher, dass `` ​​mit Ihrem Cluster übereinstimmt. Weitere Informationen dazu finden Sie unter [Hinzufügen und Löschen von Markierungen für einzelne Ressourcen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). Wenn Sie die Schritte in der Anleitung ausführen, wird die erforderliche Markierung für Sie zum Knoten hinzugefügt. | Schlüssel | Value (Wert) | | --- | --- | | `kubernetes.io/cluster/` | `owned` | **Wichtig** Tags im Amazon EC2 Instance Metadata Service (IMDS) sind nicht mit EKS-Knoten kompatibel. Wenn Instance Metadata Tags aktiviert sind, wird die Verwendung von Schrägstrichen („/“) in Tag-Werten verhindert. Diese Einschränkung kann zu Fehlern beim Starten von Instances führen, insbesondere bei der Verwendung von Knotenmanagement-Tools wie Karpenter oder Cluster Autoscaler, da diese Services für ihre ordnungsgemäße Funktion auf Tags mit Schrägstrichen angewiesen sind. Weitere Informationen zu Worker-Knoten aus einer allgemeinen Kubernetes-Perspektive finden Sie unter [Nodes](https://kubernetes.io/docs/concepts/architecture/nodes/) in der Kubernetes-Dokumentation. **Topics** + [Selbstverwaltete Amazon-Linux-Knoten erstellen](launch-workers.md) + [Selbstverwaltete Bottlerocket-Knoten erstellen](launch-node-bottlerocket.md) + [Selbstverwaltete Microsoft-Windows-Knoten erstellen](launch-windows-workers.md) + [Selbstverwaltete Ubuntu Linux-Knoten erstellen](launch-node-ubuntu.md) + [Selbstverwaltete Knoten für Ihren Cluster aktualisieren](update-workers.md) # Selbstverwaltete Amazon-Linux-Knoten erstellen Dieses Thema beschreibt Hinweise zum Starten von Auto-Scaling-Gruppen von Linux-Knoten, die mit Ihrem Amazon-EKS-Cluster registriert sind. Nachdem die Knoten dem Cluster beigetreten sind, können Sie Kubernetes-Anwendungen darin bereitstellen. Sie können auch selbstverwaltete Amazon Linux-Knoten mit `eksctl` oder dem AWS-Managementkonsole starten. Informationen dazu, wie Sie Knoten auf AWS Outposts starten müssen, finden Sie unter[Amazon Linux-Knoten auf AWS Outposts erstellen](eks-outposts-self-managed-nodes.md). + Ein vorhandener Amazon-EKS-Cluster. Informationen zum Bereitstellen finden Sie unter [Amazon-EKS-Cluster erstellen](create-cluster.md). Wenn Sie Subnetze in der AWS Region haben, in der Sie AWS Outposts, AWS Wavelength oder AWS Local Zones aktiviert haben, dürfen diese Subnetze bei der Erstellung Ihres Clusters nicht weitergegeben worden sein. + Eine vorhandene IAM-Rolle, die von den Knoten verwendet werden soll. Informationen zum Erstellen finden Sie unter [Amazon-EKS-Knoten-IAM-Rolle](create-node-role.md). Wenn diese Rolle keine der beiden Richtlinien für die VPC CNI enthält, ist die folgende separate Rolle für die VPC-CNI-Pods erforderlich. + (Optional, aber empfohlen) Das Amazon-VPC-CNI-Plugin für Kubernetes-Add-On, konfiguriert mit einer eigenen IAM-Rolle, der die erforderliche IAM-Richtlinie zugeordnet ist. Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md). + Vertrautheit mit den unter [Wählen Sie einen optimalen EC2 Amazon-Node-Instance-Typ](choosing-instance-type.md) aufgeführten Überlegungen. Je nachdem, welchen Instance-Typ Sie wählen, kann es zusätzliche Voraussetzungen für Ihren Cluster und Ihre VPC geben. Sie können selbstverwaltete Linux-Knoten mit einer der folgenden Optionen starten: + [`eksctl`](#eksctl_create_managed_amazon_linux) + [AWS-Managementkonsole](#console_create_managed_amazon_linux) ## `eksctl` **Selbstverwaltete Linux-Knoten mithilfe der `eksctl` starten ** 1. Installieren Sie Version `0.215.0` oder höher des auf Ihrem Gerät installierten `eksctl` Befehlszeilentools oder AWS CloudShell. Informationen zum Installieren und Aktualisieren von `eksctl` finden Sie in der Dokumentation zu `eksctl` unter [Installation](https://eksctl.io/installation). 1. (Optional) Wenn die verwaltete IAM-Richtlinie **AmazonEKS\$1CNI\$1Policy** Ihrer [IAM-Rolle des Amazon-EKS-Knoten](create-node-role.md) zugeordnet ist, empfehlen wir, sie stattdessen einer IAM-Rolle zuzuweisen, die Sie dem Kubernetes-Servicekonto `aws-node` zuordnen. Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md). 1. Der folgende Befehl erstellt eine Knotengruppe in einem bestehenden Cluster. Ersetzen Sie *al-nodes* durch einen Namen für Ihre Knotengruppe. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten. Ersetzen Sie *my-cluster* mit dem Namen Ihres Clusters. Der Name darf nur alphanumerische Zeichen (wobei die Groß- und Kleinschreibung beachtet werden muss) und Bindestriche enthalten. Es muss mit einem alphanumerischen Zeichen beginnen und darf nicht länger als 100 Zeichen sein. Der Name muss innerhalb der AWS Region und des AWS Kontos, in dem Sie den Cluster erstellen, eindeutig sein. Ersetzen Sie den Rest der *example value* durch Ihre eigenen Werte. Die Knoten werden standardmäßig mit derselben Kubernetes-Version wie die Steuerungsebene erstellt. Bevor Sie einen Wert für auswählen`--node-type`, lesen [Sie den Artikel Wählen Sie einen optimalen EC2 Amazon-Node-Instance-Typ](choosing-instance-type.md). *my-key*Ersetzen Sie es durch den Namen Ihres EC2 Amazon-Schlüsselpaars oder öffentlichen Schlüssels. Dieser Schlüssel wird für den SSH-Zugriff zu Ihren Knoten verwendet, nachdem diese gestartet wurden. Wenn Sie noch kein EC2 Amazon-Schlüsselpaar haben, können Sie eines in der erstellen AWS-Managementkonsole. Weitere Informationen finden Sie unter [ EC2 Amazon-Schlüsselpaare](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im * EC2 Amazon-Benutzerhandbuch*. Erstellen Sie Ihre Knoten-Gruppe mit dem folgenden Befehl. **Wichtig** Wenn Sie eine Knotengruppe in AWS Outposts-, Wavelength- oder Local Zone-Subnetzen bereitstellen möchten, gibt es zusätzliche Überlegungen: Die Subnetze dürfen beim Erstellen des Clusters nicht übergeben worden sein. Sie müssen die Knotengruppe mit einer Konfigurationsdatei erstellen, die die Subnetze und ` [volumeType](https://eksctl.io/usage/schema/#nodeGroups-volumeType): gp2` angibt. Weitere Informationen dazu finden Sie unter [Verwenden von Config-Dateien](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) und im [Config-Datei-Schema](https://eksctl.io/usage/schema/) in der `eksctl`-Dokumentation. ``` eksctl create nodegroup \ --cluster my-cluster \ --name al-nodes \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --ssh-access \ --managed=false \ --ssh-public-key my-key ``` Zum Bereitstellen einer Knotengruppe, die: + kann Pods eine deutlich höhere Anzahl von IP-Adressen zuweisen als die Standardkonfiguration, siehe [Zuweisung weiterer IP-Adressen mit Präfixen zu Amazon-EKS-Knoten](cni-increase-ip-addresses.md). + kann `IPv4`-Adressen an Pods aus einem anderen CIDR-Block als dem der Instance zuweisen, siehe [Bereitstellung von Pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk](cni-custom-network.md). + kann `IPv6`-Adressen an Pods und Services zuweisen, siehe [Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste](cni-ipv6.md). + hat keinen ausgehenden Internetzugriff, siehe [Bereitstellung privater Cluster mit eingeschränktem Internetzugang](private-clusters.md). Geben Sie den folgenden Befehl ein, um eine vollständige Liste aller verfügbaren Optionen und Standardwerte anzuzeigen. ``` eksctl create nodegroup --help ``` Sollten Knoten nicht in den Cluster aufgenommen werden können, finden Sie weitere Informationen unter [Knoten können nicht mit dem Cluster verknüpft werden](troubleshooting.md#worker-node-fail) im Kapitel zur Fehlerbehebung. Eine Beispielausgabe sieht wie folgt aus. Mehrere Zeilen werden ausgegeben, während die Knoten erstellt werden. Die letzte Ausgabezeile ähnelt der folgenden Beispielzeile. ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (Optional) [Eine Beispielanwendung in Linux bereitstellen](sample-deployment.md) Stellen Sie eine Beispielanwendung bereit, um Ihren Cluster und Ihre Linux-Worker-Knoten zu testen. 1. 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 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](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). ## AWS-Managementkonsole **Schritt 1: Selbstverwaltete Linux-Knoten mit AWS-Managementkonsole starten ** 1. Laden Sie die neueste Version der AWS CloudFormation Vorlage herunter. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-26/amazon-eks-nodegroup.yaml ``` 1. Warten Sie, bis der Status des Clusters als `ACTIVE` angezeigt wird. Wenn Sie Ihre Knoten starten, bevor der Cluster aktiv ist, werden die Knoten nicht mit dem Cluster registriert und Sie müssen sie neu starten. 1. Öffnen Sie die [AWS CloudFormation -Konsole](https://console.aws.amazon.com/cloudformation/). 1. Wählen Sie **Create stack** (Stack erstellen) und dann **With new resources (standard)** (Mit neuen Ressourcen [Standard]) aus. 1. Wählen Sie für **Specify template** (Vorlage festlegen) **Upload a template file** (Vorlagendatei hochladen) aus und wählen Sie dann **Choose file** (Datei wählen). 1. Wählen Sie die heruntergeladene `amazon-eks-nodegroup.yaml`-Datei aus. 1. Klicken Sie auf **Weiter**. 1. Geben Sie auf der Seite **Specify stack details** (Stack-Details angeben) die folgenden Parameter ein und klicken Sie dann auf **Next** (Weiter): + **Stack-Name**: Wählen Sie einen Stack-Namen für Ihren AWS CloudFormation Stack. Sie können ihn beispielsweise *my-cluster-nodes* nennen. Der Name darf nur alphanumerische Zeichen (wobei die Groß- und Kleinschreibung beachtet werden muss) und Bindestriche enthalten. Es muss mit einem alphanumerischen Zeichen beginnen und darf nicht länger als 100 Zeichen sein. Der Name muss innerhalb der AWS Region und des AWS Kontos, in dem Sie den Cluster erstellen, eindeutig sein. + **ClusterName**: Geben Sie den Namen ein, den Sie bei der Erstellung Ihres Amazon EKS-Clusters verwendet haben. Dieser Name muss exakt mit dem Cluster-Namen übereinstimmen, andernfalls werden Ihre Knoten dem Cluster nicht beitreten. + **ClusterControlPlaneSecurityGroup**: Wählen Sie den **SecurityGroups**Wert aus der AWS CloudFormation Ausgabe aus, die Sie bei der Erstellung Ihrer [VPC](creating-a-vpc.md) generiert haben. Die folgenden Schritte zeigen einen Vorgang zum Abrufen der entsprechenden Gruppe. 1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters). 1. Wählen Sie den Namen des Clusters. 1. Wählen Sie die Registerkarte **Network (Network)** aus. 1. Verwenden Sie den Wert **Zusätzliche Sicherheitsgruppen** als Referenz, wenn Sie aus der **ClusterControlPlaneSecurityGroup**Dropdownliste auswählen. + **ApiServerEndpoint**: Geben Sie den API-Server-Endpunkt für Ihren EKS-Cluster ein. Dies finden Sie im Abschnitt „Details“ der EKS-Cluster-Konsole + **CertificateAuthorityData**: Geben Sie die Base64-kodierten Zertifizierungsstellendaten ein, die Sie auch im Abschnitt „Details“ der EKS-Cluster-Konsole finden. + **ServiceCidr**: Geben Sie den CIDR-Bereich ein, der für die Zuweisung von IP-Adressen zu Kubernetes-Diensten innerhalb des Clusters verwendet wird. Dieser befindet sich auf der Registerkarte „Netzwerk“ der EKS-Cluster-Konsole. + **AuthenticationMode**: Wählen Sie den im EKS-Cluster verwendeten Authentifizierungsmodus aus, indem Sie auf der Registerkarte „Zugriff“ in der EKS-Cluster-Konsole nachsehen. + **NodeGroupName**: Geben Sie einen Namen für Ihre Knotengruppe ein. Dieser Name kann zu einem späteren Zeitpunkt zum Identifizieren der Auto-Scaling-Knotengruppe verwendet werden, die für Ihre Knoten erstellt wurde. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten. + **NodeAutoScalingGroupMinSize**: Geben Sie die Mindestanzahl von Knoten ein, auf die Ihre Auto Scaling Scaling-Gruppe für Knoten skalieren kann. + **NodeAutoScalingGroupDesiredCapacity**: Geben Sie die gewünschte Anzahl von Knoten ein, auf die bei der Erstellung Ihres Stacks skaliert werden soll. + **NodeAutoScalingGroupMaxSize**: Geben Sie die maximale Anzahl von Knoten ein, auf die Ihre Auto Scaling Scaling-Gruppe für Knoten skalieren kann. + **NodeInstanceType**: Wählen Sie einen Instance-Typ für Ihre Knoten. Weitere Informationen finden Sie unter [Auswahl eines optimalen Amazon-EC2-Knoten-Instance-Typs](choosing-instance-type.md). + **NodeImageIdSSMParam**: Vorab mit dem Amazon EC2 Systems Manager Manager-Parameter eines kürzlich von Amazon EKS optimierten Amazon Linux 2023 AMI für eine variable Kubernetes-Version gefüllt. Um eine andere Kubernetes-Nebenversion zu verwenden, die von Amazon EKS unterstützt wird, ersetzen Sie *1.XX* durch eine andere [unterstützte Version](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). Wir empfehlen, dieselbe Kubernetes-Version wie Ihr Cluster anzugeben. Sie können es auch *amazon-linux-2023* 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** Die Amazon EKS-Knoten AMIs basieren auf Amazon Linux. Sie können Sicherheits- oder Datenschutzereignisse für Amazon Linux 2023 im [Amazon Linux Security Center](https://alas.aws.amazon.com/alas2023.html) verfolgen oder den zugehörigen [RSS-Feed](https://alas.aws.amazon.com/AL2023/alas.rss) abonnieren. Sicherheits- oder Datenschutzereignisse enthalten eine Übersicht über das Problem, welche Pakete betroffen sind und wie Sie Ihre Instances aktualisieren, um das Problem zu beheben. + **NodeImageId**: (Optional) Wenn Sie Ihr eigenes benutzerdefiniertes AMI (anstelle eines für Amazon EKS optimierten AMI) verwenden, geben Sie eine Knoten-AMI-ID für Ihre AWS Region ein. Wenn Sie hier einen Wert angeben, überschreibt dieser alle Werte im **NodeImageIdSSMParam**Feld. + **NodeVolumeSize**: Geben Sie eine Root-Volume-Größe für Ihre Knoten in GiB an. + **NodeVolumeType**: Geben Sie einen Root-Volume-Typ für Ihre Knoten an. + **KeyName**: Geben Sie den Namen eines Amazon EC2 SSH-Schlüsselpaars ein, mit dem Sie nach dem Start über SSH eine Verbindung zu Ihren Knoten herstellen können. Wenn Sie noch kein EC2 Amazon-Schlüsselpaar haben, können Sie eines in der erstellen AWS-Managementkonsole. Weitere Informationen finden Sie unter [ EC2 Amazon-Schlüsselpaare](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im * EC2 Amazon-Benutzerhandbuch*. + **VpcId**: Geben Sie die ID für die [VPC](creating-a-vpc.md) ein, die Sie erstellt haben. + **Subnetze**: Wählen Sie die Subnetze aus, die Sie für Ihre VPC erstellt haben. Wenn Sie Ihre VPC anhand der unter [Erstellen einer Amazon VPC für Ihren Amazon-EKS-Cluster](creating-a-vpc.md) beschriebenen Schritte erstellt haben, geben Sie nur die privaten Subnetze innerhalb der VPC an, in denen Ihre Knoten gestartet werden sollen. Sie können sehen, welche Subnetze privat sind, indem Sie den jeweiligen Subnetzlink in der Registerkarte **Networking** (Netzwerk) Ihres Clusters öffnen. **Wichtig** Wenn es sich bei einem oder einigen der Subnetze um öffentliche Subnetze handelt, muss die Einstellung für die automatische Zuweisung öffentlicher IP-Adressen aktiviert sein. Wenn die Einstellung für das öffentliche Subnetz nicht aktiviert ist, wird allen Knoten, die Sie in diesem öffentlichen Subnetz bereitstellen, keine öffentliche IP-Adresse zugewiesen und sie können nicht mit dem Cluster oder anderen Diensten kommunizieren. AWS Wenn das Subnetz vor dem 26. März 2020 mithilfe einer der [Amazon AWS CloudFormation EKS-VPC-Vorlagen](creating-a-vpc.md) oder mithilfe `eksctl` von bereitgestellt wurde, ist die automatische Zuweisung öffentlicher IP-Adressen für öffentliche Subnetze deaktiviert. Informationen dazu, wie Sie die Zuweisung öffentlicher IP-Adressen für ein Subnetz aktivieren, finden Sie unter [Ändern des Attributs für die öffentliche IPv4 Adressierung](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) für Ihr Subnetz. Wenn der Knoten in einem privaten Subnetz bereitgestellt wird, kann er über ein NAT-Gateway mit dem Cluster und anderen AWS Diensten kommunizieren. Wenn die Subnetze keinen Internetzugang haben, stellen Sie sicher, dass Sie die Überlegungen und zusätzlichen Schritte unter [Bereitstellen privater Cluster mit eingeschränktem Internetzugang](private-clusters.md) kennen. Wenn Sie AWS Outposts-, Wavelength- oder Local Zone-Subnetze auswählen, dürfen die Subnetze bei der Erstellung des Clusters nicht übergeben worden sein. 1. Treffen Sie die gewünschte Auswahl auf der Seite **Configure stack options** (Stackoptionen konfigurieren) und wählen Sie dann **Next** (Weiter) aus. 1. Aktivieren Sie das Kontrollkästchen links neben **Ich bestätige, dass AWS CloudFormation möglicherweise IAM-Ressourcen erstellt** werden. , und wählen Sie dann **Stapel erstellen** aus. 1. Wenn Ihr Stack fertig erstellt wurde, wählen Sie ihn in der Konsole aus und klicken Sie auf **Outputs** (Ausgaben). Wenn Sie den `EKS API and ConfigMap` Authentifizierungsmodus `EKS API` oder verwenden, ist dies der letzte Schritt. 1. Wenn Sie den `ConfigMap` Authentifizierungsmodus verwenden, notieren Sie den **NodeInstanceRole**für die Knotengruppe, die erstellt wurde. **Schritt 2: Knoten, die Ihrem Cluster beitreten sollen, aktivieren** **Anmerkung** Die folgenden zwei Schritte sind nur erforderlich, wenn Sie den Configmap-Authentifizierungsmodus innerhalb des EKS-Clusters verwenden. Wenn Sie Knoten in einer privaten VPC ohne ausgehenden Internetzugang gestartet haben, stellen Sie außerdem sicher, dass Knoten Ihrem Cluster von der VPC aus beitreten können. 1. Überprüfen Sie, ob Sie bereits über eine `aws-auth` `ConfigMap` verfügen. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. Wenn eine `aws-auth` `ConfigMap` angezeigt wird, aktualisieren Sie sie nach Bedarf. 1. Öffnen Sie `ConfigMap` zum Bearbeiten. ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. Fügen Sie nach Bedarf einen neuen `mapRoles`-Eintrag hinzu. Setzen Sie den `rolearn` Wert auf den **NodeInstanceRole**Wert, den Sie im vorherigen Verfahren aufgezeichnet haben. ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes [...] ``` 1. Speichern Sie die Datei und beenden Sie den Text-Editor. 1. Wenn die Fehlermeldung `Error from server (NotFound): configmaps "aws-auth" not found` angezeigt wird, wenden Sie die standardmäßige `ConfigMap` an. 1. Laden Sie die Konfigurationszuordnung herunter. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml ``` 1. Stellen Sie in der `aws-auth-cm.yaml` Datei den `rolearn` Wert auf den **NodeInstanceRole**Wert ein, den Sie im vorherigen Verfahren aufgezeichnet haben. Hierzu können Sie einen Texteditor verwenden oder *my-node-instance-role* ersetzen und den folgenden Befehl ausführen: ``` sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml ``` 1. Wenden Sie die Konfiguration an. Die Ausführung dieses Befehls kann einige Minuten dauern. ``` kubectl apply -f aws-auth-cm.yaml ``` 1. Sehen Sie sich den Status Ihrer Knoten an und warten Sie, bis diese in den `Ready`-Status eintreten. ``` kubectl get nodes --watch ``` Geben Sie `Ctrl`\$1`C` ein, um zum Shell-Prompt zurückzukehren. **Anmerkung** Wenn Sie Autorisierungs- oder Ressourcenfehler erhalten, finden Sie weitere Informationen unter [Nicht autorisiert oder Zugriff verweigert (`kubectl`)](troubleshooting.md#unauthorized) im Thema zur Fehlerbehebung. Sollten Knoten nicht in den Cluster aufgenommen werden können, finden Sie weitere Informationen unter [Knoten können nicht mit dem Cluster verknüpft werden](troubleshooting.md#worker-node-fail) im Kapitel zur Fehlerbehebung. 1. (Nur GPU-Knoten) Wenn Sie einen GPU-Instance-Typ und das für Amazon EKS optimierte beschleunigte AMI ausgewählt haben, müssen Sie das [NVIDIA-Geräte-Plug-In für Kubernetes](https://github.com/NVIDIA/k8s-device-plugin) als a DaemonSet auf Ihrem Cluster anwenden. Ersetzen Sie es *vX.X.X* durch die gewünschte [s-device-pluginNVIDIA/K8-Version](https://github.com/NVIDIA/k8s-device-plugin/releases), bevor Sie den folgenden Befehl ausführen. ``` kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml ``` **Schritt 3: Zusätzliche Aktionen** 1. (Optional) [Eine Beispielanwendung in Linux bereitstellen](sample-deployment.md) Stellen Sie eine Beispielanwendung bereit, um Ihren Cluster und Ihre Linux-Worker-Knoten zu testen. 1. (Optional) Wenn die von **AmazonEKS\$1CNI\$1Policy** verwaltete IAM-Richtlinie (wenn Sie einen `IPv4` Cluster haben) oder die *AmazonEKS\$1CNI\$1IPv6\$1Policy* (die Sie [selbst erstellt](cni-iam-role.md#cni-iam-role-create-ipv6-policy) haben, wenn Sie einen `IPv6` Cluster haben) mit Ihrer [Amazon EKS-Knoten-IAM-Rolle verknüpft ist, empfehlen wir, sie stattdessen einer IAM-Rolle](create-node-role.md) zuzuweisen, die Sie dem Kubernetes-Servicekonto zuordnen. `aws-node` Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md). 1. 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 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](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). # Selbstverwaltete Bottlerocket-Knoten erstellen **Anmerkung** Verwaltete Knotengruppen bieten möglicherweise einige Vorteile für Ihren Anwendungsfall. Weitere Informationen finden Sie unter [Vereinfachung des Knotenlebenszyklus mit verwalteten Knotengruppen](managed-node-groups.md). In diesem Thema wird beschrieben, wie Sie Auto-Scaling-Gruppen von [Bottlerocket](https://aws.amazon.com/bottlerocket/)-Knoten starten, die mit Ihrem Amazon-EKS-Cluster registriert sind. Bottlerocket ist ein Linux-basiertes Open-Source-Betriebssystem, mit dem Sie Container auf virtuellen AWS Maschinen oder Bare-Metal-Hosts ausführen können. Nachdem die Knoten dem Cluster beigetreten sind, können Sie Kubernetes-Anwendungen darin bereitstellen. Weitere Informationen zu Bottlerocket finden Sie in der Dokumentation unter [Using a Bottlerocket AMI with Amazon EKS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-EKS.md) on GitHub and [Custom](https://eksctl.io/usage/custom-ami-support/) AMI support. `eksctl` [Informationen zu direkten Upgrades finden Sie unter Bottlerocket Update Operator unter.](https://github.com/bottlerocket-os/bottlerocket-update-operator) GitHub **Wichtig** Amazon-EKS-Worker-Knoten sind Standard-Amazon-EC2-Instances und werden Ihnen basierend auf normalen Amazon-EC2-Instance-Preisen berechnet. Weitere Informationen dazu finden Sie unter [Amazon EC2 – Preise](https://aws.amazon.com/ec2/pricing/). Sie können Bottlerocket-Knoten in erweiterten Amazon EKS-Clustern auf AWS Outposts starten, aber Sie können sie nicht in lokalen Clustern auf Outposts starten. AWS Weitere Informationen finden Sie unter [Bereitstellung von Amazon EKS On-Premises mit AWS Outposts](eks-outposts.md). Sie können auf Amazon-EC2-Instances mit `x86`- oder Arm -Prozessoren bereitstellen. Sie können jedoch nicht auf Instances bereitstellen, die über Inferentia-Chips verfügen. Bottlerocket ist kompatibel mit. AWS CloudFormation Es gibt jedoch keine offizielle CloudFormation Vorlage, die kopiert werden kann, um Bottlerocket-Knoten für Amazon EKS bereitzustellen. Bottlerocket-Images werden nicht mit einem SSH-Server oder einer Shell geliefert. Sie können out-of-band Zugriffsmethoden verwenden, um die SSH-Aktivierung des Admin-Containers zu ermöglichen und einige Bootstrapping-Konfigurationsschritte mit Benutzerdaten zu durchlaufen. Weitere Informationen finden Sie in diesen Abschnitten im [bottlerocket README.md](https://github.com/bottlerocket-os/bottlerocket) auf GitHub: [Exploration](https://github.com/bottlerocket-os/bottlerocket#exploration) (Erkundung) [Administrator-Container](https://github.com/bottlerocket-os/bottlerocket#admin-container) [Kubernetes-Einstellungen](https://github.com/bottlerocket-os/bottlerocket#kubernetes-settings) 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 ``` Anweisungen zum Installieren oder Aktualisieren von `eksctl` finden Sie unter [Installation](https://eksctl.io/installation) in der `eksctl`-Dokumentation. HINWEIS: Dieses Verfahren funktioniert nur für Cluster, die mit `eksctl` erstellt wurden. 1. Kopieren Sie den folgenden Inhalt auf Ihr Gerät. Ersetzen Sie *my-cluster* mit dem Namen Ihres Clusters. Der Name darf nur alphanumerische Zeichen (wobei die Groß- und Kleinschreibung beachtet werden muss) und Bindestriche enthalten. Es muss mit einem alphanumerischen Zeichen beginnen und darf nicht länger als 100 Zeichen sein. Der Name muss innerhalb der AWS Region und des AWS Kontos, in dem Sie den Cluster erstellen, eindeutig sein. Ersetzen Sie *ng-bottlerocket* durch einen Namen für Ihre Knotengruppe. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten. Um die Bereitstellung auf Arm-Instances durchzuführen, ersetzen Sie *m5.large* durch einen Arm-Instance-Typ. Ersetzen Sie *my-ec2-keypair-name* mit dem Namen eines Amazon-EC2-SSH-Schlüsselpaars ein, das Sie für die Verbindung über SSH in Ihre Arbeitsknoten verwenden können, nachdem sie gestartet wurden. Wenn Sie noch kein Amazon-EC2-Schlüsselpaar haben, können Sie eines in der AWS-Managementkonsole erstellen. Weitere Informationen finden Sie unter [Amazon-EC2-Schlüsselpaare](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im *Amazon-EC2-Benutzerhandbuch*. Ersetzen Sie alle verbleibenden Beispielwerte durch Ihre eigenen Werte. Nachdem Sie das Ersetzen vorgenommen haben, führen Sie den geänderten Befehl aus, um die `bottlerocket.yaml`-Datei zu erstellen. Wenn Sie einen Arm Amazon EC2 EC2-Instance-Typ angeben, lesen Sie AMIs vor der Bereitstellung die Überlegungen im für [Amazon EKS optimierten Arm Amazon Linux](eks-optimized-ami.md#arm-ami). Anweisungen zur Bereitstellung mit einem benutzerdefinierten AMI finden Sie in der Dokumentation unter [Building Bottlerocket](https://github.com/bottlerocket-os/bottlerocket/blob/develop/BUILDING.md) on GitHub und [Custom AMI support](https://eksctl.io/usage/custom-ami-support/). `eksctl` Um eine verwaltete Knotengruppe bereitzustellen, stellen Sie ein benutzerdefiniertes AMI mithilfe einer Startvorlage bereit. Weitere Informationen finden Sie unter [Verwaltete Knoten mit Startvorlagen anpassen](launch-templates.md). **Wichtig** Um eine Knotengruppe in AWS Outposts-, AWS Wavelength- oder AWS Local Zone-Subnetzen bereitzustellen, übergeben Sie beim Erstellen des Clusters keine AWS Outposts-, AWS Wavelength- oder AWS Local Zone-Subnetze. Sie müssen die Subnetze im folgenden Beispiel angeben. Weitere Informationen finden Sie unter [Verwenden von Config-Dateien](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) und im [Config-Datei-Schema](https://eksctl.io/usage/schema/) in der `eksctl`-Dokumentation. Ersetzen Sie es *region-code* durch die AWS Region, in der sich Ihr Cluster befindet. ``` cat >bottlerocket.yaml < Dieses Thema beschreibt Hinweise zum Starten von Auto-Scaling-Gruppen von -Windows-Knoten, die mit Ihrem Amazon-EKS-Cluster registriert sind. Nachdem die Knoten dem Cluster beigetreten sind, können Sie Kubernetes-Anwendungen darin bereitstellen. **Wichtig** Amazon-EKS-Worker-Knoten sind Standard-Amazon-EC2-Instances und werden Ihnen basierend auf normalen Amazon-EC2-Instance-Preisen berechnet. Weitere Informationen dazu finden Sie unter [Amazon EC2 – Preise](https://aws.amazon.com/ec2/pricing/). Sie können Windows-Knoten in erweiterten Amazon EKS-Clustern auf AWS Outposts starten, aber Sie können sie nicht in lokalen Clustern auf AWS Outposts starten. Weitere Informationen finden Sie unter [Bereitstellung von Amazon EKS On-Premises mit AWS Outposts](eks-outposts.md). Aktivieren Sie den Windows-Support für Ihren Cluster. Es wird empfohlen, wichtige Überlegungen zu berücksichtigen, bevor Sie eine Windows-Knotengruppe starten. Weitere Informationen finden Sie unter [Windows-Support aktivieren](windows-support.md#enable-windows-support). Sie können selbstverwaltete Windows-Knoten mit einer der folgenden Methoden starten: + [`eksctl`](#eksctl_create_windows_nodes) + [AWS-Managementkonsole](#console_create_windows_nodes) ## `eksctl` **Selbstverwaltete Windows-Knoten mithilfe von `eksctl` starten ** Bei diesem Verfahren wird davon ausgegangen, dass Sie `eksctl` installiert haben und dass Ihre `eksctl`-Version mindestens `0.215.0` ist. 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. (Optional) Wenn die von **AmazonEKS\$1CNI\$1Policy** verwaltete IAM-Richtlinie (wenn Sie einen `IPv4` Cluster haben) oder die *AmazonEKS\$1CNI\$1IPv6\$1Policy* (die Sie [selbst erstellt](cni-iam-role.md#cni-iam-role-create-ipv6-policy) haben, wenn Sie einen `IPv6` Cluster haben) mit Ihrer [Amazon EKS-Knoten-IAM-Rolle verknüpft ist, empfehlen wir, sie stattdessen einer IAM-Rolle](create-node-role.md) zuzuweisen, die Sie dem Kubernetes-Servicekonto zuordnen. `aws-node` Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md). 1. Bei diesem Verfahren wird davon ausgegangen, dass Sie einen bestehenden Cluster haben. Wenn Sie nicht über einen Amazon-EKS-Cluster und eine Amazon-Linux-Knotengruppe verfügen, zu der Sie eine Windows-Knotengruppe hinzufügen können, empfehlen wir Ihnen, [Erste Schritte mit Amazon EKS – `eksctl`](getting-started-eksctl.md) zu befolgen. Dieses Handbuch bietet eine vollständige Anleitung zum Erstellen eines Amazon-EKS-Clusters mit Amazon-Linux-Knoten. Erstellen Sie Ihre Knoten-Gruppe mit dem folgenden Befehl. Ersetzen *region-code* Sie es durch die Region, in der sich Ihr Cluster befindet. AWS Ersetzen Sie *my-cluster* mit Ihrem Clusternamen. Der Name darf nur alphanumerische Zeichen (wobei die Groß- und Kleinschreibung beachtet werden muss) und Bindestriche enthalten. Es muss mit einem alphanumerischen Zeichen beginnen und darf nicht länger als 100 Zeichen sein. Der Name muss innerhalb der AWS Region und des AWS Kontos, in dem Sie den Cluster erstellen, eindeutig sein. Ersetzen Sie *ng-windows* durch einen Namen für Ihre Knotengruppe. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten. Sie können durch *2019* ersetzen`2022`, um Windows Server 2022 oder Windows Server 2025 `2025` zu verwenden. Ersetzen Sie die restlichen Beispielwerte durch Ihre eigenen Werte. **Wichtig** Um eine Knotengruppe in AWS Outposts-, AWS Wavelength- oder AWS Local Zone-Subnetzen bereitzustellen, übergeben Sie die Subnetze AWS Outposts, Wavelength oder Local Zone nicht, wenn Sie den Cluster erstellen. Erstellen Sie die Knotengruppe mit einer Konfigurationsdatei, in der Sie die Subnetze AWS Outposts, Wavelength oder Local Zone angeben. Weitere Informationen finden Sie unter [Verwenden von Config-Dateien](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) und im [Config-Datei-Schema](https://eksctl.io/usage/schema/) in der `eksctl`-Dokumentation. ``` eksctl create nodegroup \ --region region-code \ --cluster my-cluster \ --name ng-windows \ --node-type t2.large \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false \ --node-ami-family WindowsServer2019FullContainer ``` **Anmerkung** Wenn Arbeitsknoten dem Cluster nicht beitreten können, finden Sie weitere Informationen unter [Knoten können nicht mit dem Cluster verknüpft werden](troubleshooting.md#worker-node-fail) im Handbuch zur Fehlerbehebung. Geben Sie den folgenden Befehl ein, um die verfügbaren Optionen für `eksctl`-Befehle anzuzeigen. ``` eksctl command -help ``` Eine Beispielausgabe sieht wie folgt aus. Mehrere Zeilen werden ausgegeben, während die Knoten erstellt werden. Die letzte Ausgabezeile ähnelt der folgenden Beispielzeile. ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (Optional) [Eine Beispielanwendung in Linux bereitstellen](sample-deployment.md) Stellen Sie eine Beispielanwendung bereit, um Ihren Cluster und Ihre Windows-Worker-Knoten zu testen. 1. 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). ## AWS-Managementkonsole **Voraussetzungen** + Ein bestehender Amazon-EKS-Cluster und eine Linux-Knotengruppe. Wenn Sie nicht über diese Ressourcen verfügen, empfehlen wir Ihnen, diese mithilfe einer unserer Anleitungen in [Erste Schritte mit Amazon EKS](getting-started.md) zu erstellen. Diese Anleitungen beschreiben, wie Sie einen Amazon-EKS-Cluster mit Linux-Knoten erstellen. + Eine vorhandene VPC und eine Sicherheitsgruppe, die die Voraussetzungen für einen Amazon-EKS-Cluster erfüllen. Weitere Informationen erhalten Sie unter [Amazon-EKS-Netzwerkanforderungen für VPC und Subnetze](network-reqs.md) und [Anforderungen der Amazon-EKS-Sicherheitsgruppe für Cluster anzeigen](sec-group-reqs.md). Die Guides in [Erste Schritte mit Amazon EKS](getting-started.md) erstellen eine VPC, die den Anforderungen entspricht. Alternativ können Sie auch den Abschnitt [Erstellen einer Amazon VPC für Ihren Amazon-EKS-Cluster](creating-a-vpc.md) befolgen, um manuell eine VPC zu erstellen. + Ein vorhandener Amazon-EKS-Cluster, der eine VPC und eine Sicherheitsgruppe verwendet, die die Voraussetzungen eines Amazon-EKS-Clusters erfüllt. Weitere Informationen finden Sie unter [Amazon-EKS-Cluster erstellen](create-cluster.md). Wenn Sie Subnetze in der AWS Region haben, in der Sie AWS Outposts, AWS Wavelength oder AWS Local Zones aktiviert haben, dürfen diese Subnetze bei der Erstellung des Clusters nicht weitergegeben worden sein. **Schritt 1: Selbstverwaltete Windows-Knoten mit der AWS-Managementkonsole starten ** 1. Warten Sie, bis der Status des Clusters als `ACTIVE` angezeigt wird. Wenn Sie Ihre Knoten starten, bevor der Cluster aktiv ist, werden die Knoten nicht mit dem Cluster registriert und Sie müssen sie neu starten. 1. Öffnen Sie die [AWS CloudFormation -Konsole](https://console.aws.amazon.com/cloudformation/). 1. Wählen Sie **Stack erstellen** aus. 1. Wählen Sie unter **Vorlage angeben** die Option **Amazon-S3-URL** aus. 1. Kopieren Sie die folgende URL und fügen Sie sie in die **Amazon S3 URL** (Amazon-S3-URL) ein. ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml ``` 1. Wählen Sie zweimal **Next** (Weiter) aus. 1. Füllen Sie auf der Seite **Quick create stack** (Stack schnell erstellen) die folgenden Parameter entsprechend aus: + **Stack-Name**: Wählen Sie einen Stack-Namen für Ihren Stack. AWS CloudFormation Sie können ihn beispielsweise `my-cluster-nodes` nennen. + **ClusterName**: Geben Sie den Namen ein, den Sie bei der Erstellung Ihres Amazon EKS-Clusters verwendet haben. **Wichtig** Dieser Name muss genau mit dem Namen übereinstimmen, den Sie in [Schritt 1: Amazon-EKS-Cluster erstellen](getting-started-console.md#eks-create-cluster) verwendet haben. Andernfalls können Ihre Knoten dem Cluster nicht beitreten. + **ClusterControlPlaneSecurityGroup**: Wählen Sie die Sicherheitsgruppe aus der AWS CloudFormation Ausgabe aus, die Sie bei der Erstellung Ihrer [VPC](creating-a-vpc.md) generiert haben. Die folgenden Schritte zeigen eine Methode zum Abrufen der entsprechenden Gruppe. 1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters). 1. Wählen Sie den Namen des Clusters. 1. Wählen Sie die Registerkarte **Network (Network)** aus. 1. Verwenden Sie den Wert **Zusätzliche Sicherheitsgruppen** als Referenz, wenn Sie aus der **ClusterControlPlaneSecurityGroup**Dropdownliste auswählen. + **NodeGroupName**: Geben Sie einen Namen für Ihre Knotengruppe ein. Dieser Name kann zu einem späteren Zeitpunkt zum Identifizieren der Auto-Scaling-Knotengruppe verwendet werden, die für Ihre Knoten erstellt wurde. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten. + **NodeAutoScalingGroupMinSize**: Geben Sie die Mindestanzahl von Knoten ein, auf die Ihre Auto Scaling Scaling-Gruppe für Knoten skalieren kann. + **NodeAutoScalingGroupDesiredCapacity**: Geben Sie die gewünschte Anzahl von Knoten ein, auf die bei der Erstellung Ihres Stacks skaliert werden soll. + **NodeAutoScalingGroupMaxSize**: Geben Sie die maximale Anzahl von Knoten ein, auf die Ihre Auto Scaling Scaling-Gruppe für Knoten skalieren kann. + **NodeInstanceType**: Wählen Sie einen Instance-Typ für Ihre Knoten. Weitere Informationen finden Sie unter [Auswahl eines optimalen Amazon-EC2-Knoten-Instance-Typs](choosing-instance-type.md). **Anmerkung** [Die unterstützten Instance-Typen für die neueste Version des [Amazon VPC CNI-Plug-ins für Kubernetes sind in vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s) on aufgeführt.](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) GitHub 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). + **NodeImageIdSSMParam**: Vorab mit dem Amazon EC2 Systems Manager Manager-Parameter der aktuell empfohlenen Amazon EKS-optimierten Windows Core AMI-ID gefüllt. Um die Vollversion von Windows zu verwenden, ersetzen Sie *Core* durch `Full`. + **NodeImageId**: (Optional) Wenn Sie Ihr eigenes benutzerdefiniertes AMI (anstelle eines für Amazon EKS optimierten AMI) verwenden, geben Sie eine Knoten-AMI-ID für Ihre AWS Region ein. Wenn Sie einen Wert für dieses Feld angeben, überschreibt dieser alle Werte in dem **NodeImageIdSSMParam**Feld. + **NodeVolumeSize**: Geben Sie eine Root-Volume-Größe für Ihre Knoten in GiB an. + **KeyName**: Geben Sie den Namen eines Amazon EC2 SSH-Schlüsselpaars ein, mit dem Sie sich nach dem Start über SSH mit Ihren Knoten verbinden können. Wenn Sie noch kein Amazon-EC2-Schlüsselpaar haben, können Sie eines in der AWS-Managementkonsole erstellen. Weitere Informationen finden Sie unter [Amazon-EC2-Schlüsselpaare](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) im *Amazon-EC2-Benutzerhandbuch*. **Anmerkung** Wenn Sie hier kein key pair angeben, kann der AWS CloudFormation Stack nicht erstellt werden. + **BootstrapArguments**: Geben Sie alle optionalen Argumente an, die an das Node-Bootstrap-Skript übergeben werden sollen, z. B. zusätzliche `kubelet` Argumente mit`-KubeletExtraArgs`. + **Deaktivieren IMDSv1**: Standardmäßig unterstützt jeder Knoten den Instanz-Metadatendienst Version 1 (IMDSv1) und IMDSv2. Sie können deaktivieren IMDSv1. Um zu verhindern, dass future Knoten und Pods in der Knotengruppe verwendet werden MDSv1, setzen **Sie Disable IMDSv1** auf **true**. Weitere Informationen finden Sie unter [Konfiguration des Instance-Metadatenservice](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). + **VpcId**: Wählen Sie die ID für die [VPC](creating-a-vpc.md) aus, die Sie erstellt haben. + **NodeSecurityGroups**: Wählen Sie die Sicherheitsgruppe aus, die für Ihre Linux-Knotengruppe erstellt wurde, als Sie Ihre [VPC](creating-a-vpc.md) erstellt haben. Wenn Ihren Linux-Knoten mehr als eine Sicherheitsgruppe angehängt ist, geben Sie alle an. Dies z. B., wenn die Linux-Knotengruppe mit `eksctl` erstellt wurde. + **Subnets** (Subnetze): Wählen Sie die Subnetze aus, die Sie erstellt haben. Wenn Sie Ihre VPC gemäß den Schritten unter [Erstellen einer Amazon VPC für Ihren Amazon-EKS-Cluster](creating-a-vpc.md) erstellt haben, geben Sie nur die privaten Subnetze innerhalb der VPC an, in denen Ihre Knoten gestartet werden sollen. **Wichtig** Wenn es sich bei einem oder einigen der Subnetze um öffentliche Subnetze handelt, muss die Einstellung für die automatische Zuweisung öffentlicher IP-Adressen aktiviert sein. Wenn die Einstellung für das öffentliche Subnetz nicht aktiviert ist, wird allen Knoten, die Sie in diesem öffentlichen Subnetz bereitstellen, keine öffentliche IP-Adresse zugewiesen und sie können nicht mit dem Cluster oder anderen Diensten kommunizieren. AWS Wenn das Subnetz vor dem 26. März 2020 mithilfe einer der [Amazon AWS CloudFormation EKS-VPC-Vorlagen](creating-a-vpc.md) oder mithilfe `eksctl` von bereitgestellt wurde, ist die automatische Zuweisung öffentlicher IP-Adressen für öffentliche Subnetze deaktiviert. Informationen zum Aktivieren der Zuweisung öffentlicher IP-Adressen für ein Subnetz finden Sie unter [Ändern des Attributs für die öffentliche IPv4 Adressierung](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) für Ihr Subnetz. Wenn der Knoten in einem privaten Subnetz bereitgestellt wird, kann er über ein NAT-Gateway mit dem Cluster und anderen AWS Diensten kommunizieren. Wenn die Subnetze keinen Internetzugang haben, stellen Sie sicher, dass Sie die Überlegungen und zusätzlichen Schritte unter [Bereitstellen privater Cluster mit eingeschränktem Internetzugang](private-clusters.md) kennen. Wenn Sie AWS Outposts-, Wavelength- oder Local Zone-Subnetze auswählen, dürfen die Subnetze bei der Erstellung des Clusters nicht übergeben worden sein. 1. Bestätigen Sie, dass der Stack IAM-Ressourcen erstellen kann, und wählen Sie dann **Create stack** (Stack erstellen) aus. 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, wenn Sie Ihre Amazon-EKS-Windows-Knoten konfigurieren. **Schritt 2: Knoten, die Ihrem Cluster beitreten sollen, aktivieren** 1. Überprüfen Sie, ob Sie bereits über eine `aws-auth` `ConfigMap` verfügen. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. Wenn eine `aws-auth` `ConfigMap` angezeigt wird, aktualisieren Sie sie nach Bedarf. 1. Öffnen Sie `ConfigMap` zum Bearbeiten. ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. Fügen Sie nach Bedarf neue `mapRoles`-Einträge hinzu. Stellen Sie die `rolearn` Werte auf die **NodeInstanceRole**Werte ein, die Sie in den vorherigen Verfahren aufgezeichnet haben. ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - eks:kube-proxy-windows [...] ``` 1. Speichern Sie die Datei und beenden Sie den Text-Editor. 1. Wenn die Fehlermeldung `Error from server (NotFound): configmaps "aws-auth" not found` angezeigt wird, wenden Sie die standardmäßige `ConfigMap` an. 1. Laden Sie die Konfigurationszuordnung herunter. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml ``` 1. Stellen Sie in der `aws-auth-cm-windows.yaml` Datei die `rolearn` Werte auf die entsprechenden **NodeInstanceRole**Werte ein, die Sie in den vorherigen Verfahren aufgezeichnet haben. Hierzu können Sie einen Texteditor verwenden oder die Beispielwerte ersetzen und den folgenden Befehl ausführen: ``` sed -i.bak -e 's||my-node-linux-instance-role|' \ -e 's||my-node-windows-instance-role|' aws-auth-cm-windows.yaml ``` **Wichtig** Ändern Sie keine weiteren Zeilen in dieser Datei. Verwenden Sie nicht dieselbe IAM-Rolle sowohl für Windows- als auch für Linux-Knoten. 1. Wenden Sie die Konfiguration an. Die Ausführung dieses Befehls kann einige Minuten dauern. ``` kubectl apply -f aws-auth-cm-windows.yaml ``` 1. Sehen Sie sich den Status Ihrer Knoten an und warten Sie, bis diese in den `Ready`-Status eintreten. ``` kubectl get nodes --watch ``` Geben Sie `Ctrl`\$1`C` ein, um zum Shell-Prompt zurückzukehren. **Anmerkung** Wenn Sie Autorisierungs- oder Ressourcenfehler erhalten, finden Sie weitere Informationen unter [Nicht autorisiert oder Zugriff verweigert (`kubectl`)](troubleshooting.md#unauthorized) im Thema zur Fehlerbehebung. Sollten Knoten nicht in den Cluster aufgenommen werden können, finden Sie weitere Informationen unter [Knoten können nicht mit dem Cluster verknüpft werden](troubleshooting.md#worker-node-fail) im Kapitel zur Fehlerbehebung. **Schritt 3: Zusätzliche Aktionen** 1. (Optional) [Eine Beispielanwendung in Linux bereitstellen](sample-deployment.md) Stellen Sie eine Beispielanwendung bereit, um Ihren Cluster und Ihre Windows-Worker-Knoten zu testen. 1. (Optional) Wenn die von **AmazonEKS\$1CNI\$1Policy** verwaltete IAM-Richtlinie (wenn Sie einen `IPv4` Cluster haben) oder die *AmazonEKS\$1CNI\$1IPv6\$1Policy* (die Sie [selbst erstellt](cni-iam-role.md#cni-iam-role-create-ipv6-policy) haben, wenn Sie einen `IPv6` Cluster haben) mit Ihrer [Amazon EKS-Knoten-IAM-Rolle verknüpft ist, empfehlen wir, sie stattdessen einer IAM-Rolle](create-node-role.md) zuzuweisen, die Sie dem Kubernetes-Servicekonto zuordnen. `aws-node` Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md). 1. 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). # Selbstverwaltete Ubuntu Linux-Knoten erstellen **Anmerkung** Verwaltete Knotengruppen bieten möglicherweise einige Vorteile für Ihren Anwendungsfall. Weitere Informationen finden Sie unter [Vereinfachung des Knotenlebenszyklus mit verwalteten Knotengruppen](managed-node-groups.md). In diesem Thema wird beschrieben, wie Sie Auto Scaling-Gruppen von Knoten von [Ubuntu in Amazon Elastic Kubernetes Service (EKS)](https://cloud-images.ubuntu.com/aws-eks/) oder Knoten von [Ubuntu Pro in Amazon Elastic Kubernetes Service (EKS)](https://ubuntu.com/blog/ubuntu-pro-for-eks-is-now-generally-available) starten, die bei Ihrem Amazon-EKS-Cluster registriert sind. Ubuntu und Ubuntu Pro für EKS basieren auf dem offiziellen Ubuntu Minimal LTS, enthalten den benutzerdefinierten AWS Kernel, der gemeinsam mit EKS entwickelt wurde AWS, und wurden speziell für EKS gebaut. Ubuntu Pro bietet zusätzliche Sicherheit durch die Unterstützung erweiterter EKS-Supportzeiträume, Kernel-Live-Patches, FIPS-Konformität und die Möglichkeit, eine unbegrenzte Anzahl von Pro-Containern auszuführen. Nachdem die Knoten dem Cluster beigetreten sind, können Sie darin containerisierte Anwendungen bereitstellen. Weitere Informationen finden Sie in der Dokumentation zu [Ubuntu in AWS](https://documentation.ubuntu.com/aws/en/latest/) und zum [Benutzerdefinierten AMI-Support](https://eksctl.io/usage/custom-ami-support/) in der `eksctl`-Dokumentation. **Wichtig** Amazon-EKS-Worker-Knoten sind Standard-Amazon-EC2-Instances und werden Ihnen basierend auf normalen Amazon-EC2-Instance-Preisen berechnet. Weitere Informationen dazu finden Sie unter [Amazon EC2 – Preise](https://aws.amazon.com/ec2/pricing/). Sie können Ubuntu-Knoten in erweiterten Amazon EKS-Clustern auf AWS Outposts starten, aber Sie können sie nicht in lokalen Clustern auf AWS Outposts starten. Weitere Informationen finden Sie unter [Bereitstellung von Amazon EKS On-Premises mit AWS Outposts](eks-outposts.md). Sie können auf Amazon-EC2-Instances mit `x86`- oder Arm -Prozessoren bereitstellen. Bei Instances mit Inferentia-Chips muss jedoch möglicherweise zuerst das [Neuron SDK](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/) installiert werden. 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 ``` Anweisungen zum Installieren oder Aktualisieren von `eksctl` finden Sie unter [Installation](https://eksctl.io/installation) in der `eksctl`-Dokumentation. HINWEIS: Dieses Verfahren funktioniert nur für Cluster, die mit `eksctl` erstellt wurden. 1. Kopieren Sie den folgenden Inhalt auf Ihr Gerät. Ersetzen Sie `my-cluster` mit dem Namen Ihres Clusters. Der Name darf nur alphanumerische Zeichen (wobei die Groß- und Kleinschreibung beachtet werden muss) und Bindestriche enthalten. Es muss mit einem alphabetischen Zeichen beginnen und darf nicht mehr als 100 Zeichen umfassen. Ersetzen Sie `ng-ubuntu` durch einen Namen für Ihre Knotengruppe. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten. Um die Bereitstellung auf Arm-Instances durchzuführen, ersetzen Sie `m5.large` durch einen Arm-Instance-Typ. Ersetzen Sie `my-ec2-keypair-name` mit dem Namen eines Amazon-EC2-SSH-Schlüsselpaars ein, das Sie für die Verbindung über SSH in Ihre Arbeitsknoten verwenden können, nachdem sie gestartet wurden. Wenn Sie noch kein Amazon-EC2-Schlüsselpaar haben, können Sie eines in der AWS-Managementkonsole erstellen. Weitere Informationen finden Sie unter [Amazon-EC2-Schlüsselpaare](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im Amazon-EC2-Benutzerhandbuch. Ersetzen Sie alle verbleibenden Beispielwerte durch Ihre eigenen Werte. Nachdem Sie das Ersetzen vorgenommen haben, führen Sie den geänderten Befehl aus, um die `ubuntu.yaml`-Datei zu erstellen. **Wichtig** Um eine Knotengruppe in AWS Outposts-, AWS Wavelength- oder AWS Local Zone-Subnetzen bereitzustellen, übergeben Sie beim Erstellen des Clusters keine AWS Outposts-, AWS Wavelength- oder AWS Local Zone-Subnetze. Sie müssen die Subnetze im folgenden Beispiel angeben. Weitere Informationen finden Sie unter [Verwenden von Config-Dateien](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) und im [Config-Datei-Schema](https://eksctl.io/usage/schema/) in der `eksctl`-Dokumentation. Ersetzen Sie es *region-code* durch die AWS Region, in der sich Ihr Cluster befindet. ``` cat >ubuntu.yaml < 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).