**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.
# Vereinfachung des Knotenlebenszyklus mit verwalteten Knotengruppen
Von Amazon EKS verwaltete Knotengruppen automatisieren die Bereitstellung und das Lebenszyklusmanagement von Knoten ( EC2 Amazon-Instances) für Amazon EKS Kubernetes-Cluster.
Mit Amazon EKS-verwalteten Knotengruppen müssen Sie die EC2 Amazon-Instances, die Rechenkapazität für die Ausführung Ihrer Kubernetes-Anwendungen bereitstellen, nicht separat bereitstellen oder registrieren. Sie können Knoten für Ihren Cluster mit einem einzigen Vorgang erstellen, aktualisieren oder beenden. Knotenaktualisierungen und -beendigungen entleeren Knoten automatisch, um sicherzustellen, dass Ihre Anwendungen verfügbar bleiben.
Jeder verwaltete Knoten wird als Teil einer Amazon EC2 Auto Scaling Scaling-Gruppe bereitgestellt, die von Amazon EKS für Sie verwaltet wird. Jede Ressource, einschließlich der Instances und Auto Scaling Scaling-Gruppen, wird in Ihrem AWS Konto ausgeführt. Jede Knotengruppe wird in mehreren Availability Zones ausgeführt, die Sie definieren.
Verwaltete Knotengruppen können optional auch die automatische Knotenreparatur nutzen, die den Zustand der Knoten kontinuierlich überwacht. Sie reagiert automatisch auf erkannte Probleme und ersetzt Knoten, wenn möglich. Dies unterstützt die Gesamtverfügbarkeit des Clusters mit minimalen manuellen Eingriffen. Weitere Informationen finden Sie unter [Erkennen Sie Probleme mit dem Knotenstatus und aktivieren Sie die automatische Knotenreparatur](node-health.md).
Sie können mithilfe der Amazon EKS-Konsole, AWS CLI, `eksctl` AWS API oder Infrastruktur als Code-Tools eine verwaltete Knotengruppe zu neuen oder vorhandenen Clustern hinzufügen, einschließlich AWS CloudFormation. Knoten, die als Teil einer verwalteten Knotengruppe gestartet werden, werden vom Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) automatisch für die automatische Erkennung mit Tags versehen. Sie können die Knotengruppe verwenden, um Kubernetes-Labels auf Knoten anzuwenden und sie jederzeit zu aktualisieren.
Für die Nutzung von Amazon EKS-verwalteten Knotengruppen fallen keine zusätzlichen Kosten an. Sie zahlen nur für die AWS Ressourcen, die Sie bereitstellen. Dazu gehören EC2 Amazon-Instances, Amazon EBS-Volumes, Amazon EKS-Cluster-Stunden und jede andere AWS Infrastruktur. Es fallen keine Mindestgebühren oder Vorauszahlungen an.
Weitere Informationen zu den ersten Schritten mit einem neuen Amazon-EKS-Cluster und einer verwalteten Knotengruppe finden Sie unter [Erste Schritte mit Amazon EKS — AWS-Managementkonsole und AWS CLI](getting-started-console.md).
Informationen zum Hinzufügen einer verwalteten Knotengruppe zu einem bestehenden Cluster finden Sie unter [Eine verwaltete Knotengruppe für Ihren Cluster erstellen](create-managed-node-group.md).
## Konzepte für verwaltete Knotengruppen
+ Von Amazon EKS verwaltete Knotengruppen erstellen und verwalten EC2 Amazon-Instances für Sie.
+ Jeder verwaltete Knoten wird als Teil einer Amazon EC2 Auto Scaling Scaling-Gruppe bereitgestellt, die von Amazon EKS für Sie verwaltet wird. Darüber hinaus werden alle Ressourcen, einschließlich EC2 Amazon-Instances und Auto Scaling Scaling-Gruppen, in Ihrem AWS Konto ausgeführt.
+ Die Auto-Scaling-Gruppe einer verwalteten Knotengruppe umfasst alle Subnetze, die Sie beim Erstellen der Gruppe angeben.
+ Amazon EKS kennzeichnet verwaltete Knotengruppenressourcen, sodass sie für die Verwendung des Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) konfiguriert sind.
**Wichtig**
Wenn Sie eine zustandsbehaftete Anwendung über mehrere Availability Zones hinweg ausführen, die von Amazon-EBS-Volumes gesichert wird und den Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) verwendet, sollten Sie mehrere Knotengruppen konfigurieren, die jeweils für eine einzelne Availability Zone gelten. Außerdem sollten Sie das `--balance-similar-node-groups`-Feature aktivieren.
+ Sie können eine benutzerdefinierte Startvorlage für ein höheres Maß an Flexibilität und Anpassung bei der Bereitstellung verwalteter Knoten verwenden. Zum Beispiel können Sie zusätzliche `kubelet`-Argumente angeben und ein benutzerdefiniertes AMI verwenden. Weitere Informationen finden Sie unter [Verwaltete Knoten mit Startvorlagen anpassen](launch-templates.md). Wenn Sie beim ersten Erstellen einer verwalteten Knotengruppe keine benutzerdefinierte Startvorlage verwenden, gibt es eine automatisch generierte Startvorlage. Ändern Sie diese automatisch generierte Vorlage nicht manuell sonst treten Fehler auf.
+ Amazon EKS folgt dem Modell der gemeinsamen Verantwortung für CVEs und Sicherheitspatches auf verwalteten Knotengruppen. Wenn verwaltete Knoten ein für Amazon EKS optimiertes AMI ausführen, ist Amazon EKS für die Erstellung von Patch-Versionen des AMI verantwortlich, wenn Fehler oder Probleme gemeldet werden. Wir können eine Korrektur veröffentlichen. Sie sind jedoch dafür verantwortlich, diese Patch-AMI-Versionen für Ihre verwalteten Knotengruppen bereitzustellen. Wenn verwaltete Knoten ein benutzerdefiniertes AMI ausführen, sind Sie für die Erstellung von Patch-Versionen des AMI verantwortlich, wenn Fehler oder Probleme gemeldet werden, und für die anschließende Bereitstellung des AMI. Weitere Informationen finden Sie unter [Eine verwaltete Knotengruppe für Ihren Cluster aktualisieren](update-managed-node-group.md).
+ Von Amazon EKS verwaltete Knotengruppen können sowohl in öffentlichen als auch privaten Subnetzen gestartet werden. Wenn Sie eine verwaltete Knotengruppe am oder nach dem 22. April 2020 in einem öffentlichen Subnetz starten, muss `MapPublicIpOnLaunch` für das Subnetz auf „Wahr“ gesetzt sein, damit die Instances einem Cluster hinzugefügt werden können. Wenn das öffentliche Subnetz am `eksctl` oder nach dem 26. März 2020 mithilfe der von [Amazon EKS bereitgestellten AWS CloudFormation Vorlagen](creating-a-vpc.md) erstellt wurde, ist diese Einstellung bereits auf true gesetzt. Wenn die öffentlichen Subnetze vor dem 26. März 2020 erstellt wurden, müssen Sie die Einstellung manuell ändern. Weitere Informationen finden Sie unter [Ändern des Attributs für die öffentliche IPv4 Adressierung für Ihr Subnetz](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip).
+ Wenn Sie eine verwaltete Knotengruppe in privaten Subnetzen bereitstellen, müssen Sie sicherstellen, dass diese auf Amazon ECR zugreifen kann, um Container-Images abzurufen. Sie können dies tun, indem Sie ein NAT-Gateway mit der Routing-Tabelle des Subnetzes verbinden oder indem Sie die folgenden [AWS PrivateLink -VPC-Endpunkte](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create) hinzufügen:
+ Amazon-ECR-API-Endpunktschnittstelle – `com.amazonaws.region-code.ecr.api`
+ API-Endpunktschnittstelle der Amazon-ECR-Docker-Registrierung – `com.amazonaws.region-code.ecr.dkr`
+ Amazon-S3-Gateway-Endpunkt – `com.amazonaws.region-code.s3`
Weitere häufig verwendete Services und Endpunkte finden Sie unter [Bereitstellung privater Cluster mit eingeschränktem Internetzugang](private-clusters.md).
+ Verwaltete Knotengruppen können nicht in [AWS Outposts](eks-outposts.md) oder in [AWS Wavelength](https://docs.aws.amazon.com/wavelength/) bereitgestellt werden. Verwaltete Knotengruppen können [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) erstellt werden. Weitere Informationen finden Sie unter [Starten Sie EKS-Cluster mit geringer Latenz in AWS Local Zones.](local-zones.md).
+ Sie können mehrere verwaltete Knotengruppen innerhalb eines einzelnen Clusters erstellen. So können Sie beispielsweise eine Knotengruppe mit dem standardmäßig für Amazon EKS optimierten Amazon Linux AMI für einige Workloads und eine andere mit der GPU-Variante für Workloads erstellen, die GPU-Unterstützung erfordern.
+ Wenn Ihre verwaltete Knotengruppe auf einen Fehler bei der [Überprüfung des EC2 Amazon-Instance-Status](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html) stößt, gibt Amazon EKS einen Fehlercode zurück, der Ihnen bei der Diagnose des Problems hilft. Weitere Informationen finden Sie unter [Fehlercodes bei verwalteten Knotengruppen](troubleshooting.md#troubleshoot-managed-node-groups).
+ Amazon EKS fügt Kubernetes-Labels zu verwalteten Knotengruppen-Instances hinzu. Diese von Amazon EKS bereitgestellten Labels sind mit dem Präfix `eks.amazonaws.com` versehen.
+ Amazon EKS leert Knoten automatisch mit der Kubernetes-API während Beendigungs- oder Aktualisierungsvorgängen.
+ Die Budgets für Pod-Unterbrechung werden nicht eingehalten, wenn ein Knoten mit `AZRebalance` beendet oder die Anzahl der gewünschten Knoten reduziert wird. Diese Aktionen versuchen, Pods auf dem Knoten zu entfernen. Wenn dies jedoch länger als 15 Minuten dauert, wird der Knoten beendet, unabhängig davon, ob alle Pods auf dem Knoten beendet sind. Um den Zeitraum bis zum Beenden des Knotens zu verlängern, fügen Sie der Auto-Scaling-Gruppe einen Lebenszyklus-Hook hinzu. Weitere Informationen finden [Sie unter Hinzufügen von Lifecycle-Hooks](https://docs.aws.amazon.com/autoscaling/ec2/userguide/adding-lifecycle-hooks.html) im *Amazon EC2 Auto Scaling Scaling-Benutzerhandbuch*.
+ Damit der Draining-Prozess nach Erhalt einer Benachrichtigung über eine Spot-Unterbrechung oder eine Kapazitätsumverteilung korrekt ausgeführt werden kann, muss `CapacityRebalance` auf `true` eingestellt sein.
+ Aktualisierungen verwalteter Knotengruppen respektieren die Budgets für Pod-Unterbrechung, die Sie für Ihre Pods festgelegt haben. Weitere Informationen finden Sie unter [Alle Phasen der Knotenaktualisierung verstehen](managed-node-update-behavior.md).
+ Für die Verwendung verwalteter Amazon-EKS-Knotengruppen fallen keine zusätzlichen Kosten an. Sie zahlen nur für die AWS Ressourcen, die Sie bereitstellen.
+ Wenn Sie Amazon-EBS-Volumes für Ihre Knoten verschlüsseln möchten, können Sie die Knoten mithilfe einer Startvorlage bereitstellen. Um verwaltete Knoten mit verschlüsselten Amazon-EBS-Volumes ohne Verwendung einer Startvorlage bereitzustellen, verschlüsseln Sie alle neuen Amazon-EBS-Volumes, die in Ihrem Konto erstellt wurden. Weitere Informationen finden Sie unter [Standardverschlüsselung](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) im * EC2 Amazon-Benutzerhandbuch*.
## Kapazitätstypen für verwaltete Knotengruppen
Beim Erstellen einer verwalteten Knotengruppe können Sie entweder den Kapazitätstyp On-Demand oder Spot-Kapazität auswählen. Amazon EKS stellt eine verwaltete Knotengruppe mit einer Amazon EC2 Auto Scaling Scaling-Gruppe bereit, die entweder nur On-Demand-Instances oder nur Amazon EC2 Spot-Instances enthält. Sie können Pods für Fehlertoleranz-Anwendungen für verwaltete Spot-Knotengruppen und fehlerintolerante Anwendungen für On-Demand-Knotengruppen in einem einzelnen Kubernetes-Cluster planen. Standardmäßig stellt eine verwaltete Knotengruppe EC2 On-Demand-Amazon-Instances bereit.
### On-Demand
Mit On-Demand-Instances zahlen Sie für Rechenkapazität bis zur zweiten Stunde ohne langfristige Verpflichtungen.
Standardmäßig: Wenn Sie keinen **Capacity Type** festlegen, wird die verwaltete Knotengruppe mit On-Demand-Instances bereitgestellt. Eine verwaltete Knotengruppe konfiguriert in Ihrem Namen eine Amazon EC2 Auto Scaling Scaling-Gruppe, wobei die folgenden Einstellungen angewendet werden:
+ Die Allokationsstrategie zur Bereitstellung von On-Demand-Kapazität ist auf `prioritized` eingestellt. Verwaltete Knotengruppen verwenden die Reihenfolge der in der API übergebenen Instance-Typen, um zu bestimmen, welcher Instance-Typ bei der Erfüllung der On-Demand-Kapazität zuerst verwendet werden soll. Sie können beispielsweise drei Instance-Typen in der folgenden Reihenfolge angeben: `c5.large`, `c4.large`, und `c3.large`. Wenn Ihre On-Demand-Instances gestartet werden, erfüllt die verwaltete Knotengruppe On-Demand-Kapazität beginnend mit `c5.large`, dann `c4.large`, und dann `c3.large`. Weitere Informationen finden Sie unter [Amazon EC2 Auto Scaling Scaling-Gruppe](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-purchase-options.html#asg-allocation-strategies) im *Amazon EC2 Auto Scaling Scaling-Benutzerhandbuch*.
+ Amazon EKS fügt allen Knoten in Ihrer verwalteten Knotengruppe die folgende Kubernetes-Bezeichnung hinzu, die den Kapazitätstyp angibt: `eks.amazonaws.com/capacityType: ON_DEMAND`. Sie können dieses Label verwenden, um statusbehaftete oder fehlerintolerante Anwendungen auf On-Demand-Knoten zu planen.
### Spot-Instances
Amazon EC2 Spot-Instances sind freie EC2 Amazon-Kapazitäten, die erhebliche Rabatte gegenüber den On-Demand-Preisen bieten. Amazon EC2 Spot-Instances können mit einer zweiminütigen Unterbrechungsbenachrichtigung unterbrochen werden, wenn die Kapazität wieder EC2 benötigt wird. Weitere Informationen finden Sie unter [Spot-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) im * EC2 Amazon-Benutzerhandbuch*. Sie können eine verwaltete Knotengruppe mit Amazon EC2 Spot-Instances konfigurieren, um die Kosten für die Rechenknoten zu optimieren, die in Ihrem Amazon EKS-Cluster ausgeführt werden.
Um Spot-Instances in einer verwalteten Knotengruppe zu verwenden, müssen Sie eine verwaltete Knotengruppe erstellen, indem Sie den Kapazitätstyp als `spot` einstellen. Eine verwaltete Knotengruppe konfiguriert in Ihrem Namen eine Amazon EC2 Auto Scaling Scaling-Gruppe, wobei die folgenden bewährten Spot-Methoden angewendet werden:
+ Um sicherzustellen, dass Ihre Spot-Knoten in den optimalen Spot-Kapazitätspools bereitgestellt werden, ist die Zuweisungsstrategie auf eine der folgenden Optionen eingestellt:
+ `price-capacity-optimized` (PCO) – Beim Erstellen neuer Knotengruppen in einem Cluster mit Kubernetes-Version `1.28` oder höher ist die Zuweisungsstrategie auf `price-capacity-optimized` eingestellt. Allerdings wird die Zuweisungsstrategie für Knotengruppen nicht geändert, die bereits mit `capacity-optimized` erstellt wurden, bevor von Amazon EKS verwaltete Knotengruppen PCO unterstützt hatten.
+ `capacity-optimized` (CO) – Beim Erstellen neuer Knotengruppen in einem Cluster mit Kubernetes-Version `1.27` oder niedriger ist die Zuweisungsstrategie auf `capacity-optimized` eingestellt.
Um die Anzahl der Spot-Kapazitätspools zu erhöhen, die für die Zuweisung von Kapazität verfügbar sind, konfigurieren Sie eine verwaltete Knotengruppe für die Verwendung mehrerer Instance-Typen.
+ Amazon EC2 Spot Capacity Rebalancing ist aktiviert, sodass Amazon EKS Ihre Spot-Knoten problemlos entleeren und neu verteilen kann, um Anwendungsunterbrechungen zu minimieren, wenn ein Spot-Knoten einem erhöhten Unterbrechungsrisiko ausgesetzt ist. Weitere Informationen finden Sie unter [Amazon EC2 Auto Scaling Capacity Rebalancing](https://docs.aws.amazon.com/autoscaling/ec2/userguide/capacity-rebalance.html) im *Amazon EC2 Auto Scaling Scaling-Benutzerhandbuch*.
+ Wenn ein Spot-Knoten eine Neuausgleichsempfehlung erhält, versucht Amazon EKS automatisch, einen neuen Ersatz-Spot-Knoten zu starten.
+ Wenn ein Spot-Unterbrechungsnachweis in zwei Minuten eintrifft, bevor sich der Ersatz-Spot-Knoten in einem`Ready`, beginnt Amazon EKS mit dem Entleeren des Spot-Knotens, der die Neuausgleichsempfehlung erhalten hat. Amazon EKS entleert den Knoten nach bestem Wissen. Daher gibt es keine Garantie dafür, dass Amazon EKS wartet, bis der Ersatzknoten dem Cluster beitritt, bevor der vorhandene Knoten entleert wird.
+ Wenn ein Ersatz-Spot-Knoten gestartet wird und in dem `Ready` Zustand auf Kubernetes ist, sperrt Amazon EKS den Spot-Knoten, der die Neuausgleichs-Empfehlung erhalten hat, und entleert ihn. Durch das Cordoning des Spot-Knotens wird sichergestellt, dass der Service-Controller keine neuen Anforderungen an diesen Spot-Knoten sendet. Es entfernt sie auch aus der Liste der gesunden, aktiven Spot-Knoten. Durch das Entleeren des Spot-Knotens wird sichergestellt, dass ausgeführte Pods reibungslos entsorgt werden.
+ Amazon EKS fügt allen Knoten in Ihrer verwalteten Knotengruppe die folgende Kubernetes-Bezeichnung hinzu, die den Kapazitätstyp angibt: `eks.amazonaws.com/capacityType: SPOT`. Sie können dieses Label verwenden, um fehlertolerante Anwendungen auf Spot-Knoten zu planen.
**Wichtig**
EC2 gibt zwei Minuten vor dem Beenden Ihrer [Spot-Instance eine Benachrichtigung zur Spot-Unterbrechung](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html) aus. Pods auf Spot-Knoten erhalten jedoch möglicherweise nicht das volle 2-minütige Zeitfenster für ein ordnungsgemäßes Herunterfahren. Wenn Amazon EC2 EKS die Benachrichtigung ausgibt, gibt es eine Verzögerung, bis Amazon EKS mit der Räumung von Pods beginnt. Räumungen erfolgen sequenziell, um den Kubernetes-API-Server zu schützen. Bei mehreren gleichzeitigen Spot-Rückforderungen kann es also vorkommen, dass einige Pods verspätete Räumungsbenachrichtigungen erhalten. Pods können ohne Empfang von Kündigungssignalen gewaltsam beendet werden, insbesondere auf Knoten mit hoher Pod-Dichte, bei gleichzeitigen Rückforderungen oder bei Verwendung langer Kündigungsfristen. Für Spot-Workloads empfehlen wir, Anwendungen unterbrechungstolerant zu gestalten, Übergangsfristen von 30 Sekunden oder weniger zu verwenden, lang andauernde PreStop-Hooks zu vermeiden und die Pod-Räumungsmetriken zu überwachen, um die tatsächlichen Kulanzfristen in Ihren Clustern zu ermitteln. Für Workloads, die eine garantierte ordentliche Kündigung erfordern, empfehlen wir, stattdessen On-Demand-Kapazität zu verwenden.
Bei der Entscheidung, ob eine Knotengruppe mit On-Demand- oder Spot-Kapazität bereitgestellt werden soll, sollten Sie die folgenden Bedingungen berücksichtigen:
+ Spot-Instances eignen sich gut für zustandslose, fehlertolerante, flexible Anwendungen. Dazu gehören Workloads für Batch- und Machine-Learning-Schulungen, Big Data ETLs wie Apache Spark, Anwendungen zur Verarbeitung von Warteschlangen und statusfreie API-Endpunkte. Da es sich bei Spot um freie EC2 Amazon-Kapazität handelt, die sich im Laufe der Zeit ändern kann, empfehlen wir, Spot-Kapazität für unterbrechungstolerante Workloads zu verwenden. Insbesondere eignet sich die Spot-Kapazität für Workloads, die Zeiten tolerieren können, in denen die erforderliche Kapazität nicht verfügbar ist.
+ Es wird empfohlen, On-Demand für Anwendungen zu verwenden, die fehlerintolerant sind. Dazu gehören Cluster-Verwaltungs-Tools wie Überwachungs- und Betriebstools, Bereitstellungen, die `StatefulSets` erfordern, und zustandsbehaftete Anwendungen wie Datenbanken.
+ Um die Verfügbarkeit Ihrer Anwendungen bei der Verwendung von Spot-Instances zu maximieren, wird empfohlen, eine verwaltete Spot-Knotengruppe für die Verwendung mehrerer Instance-Typen zu konfigurieren. Es wird empfohlen, die folgenden Regeln anzuwenden, wenn mehrere Instance-Typen verwendet werden:
+ Wenn Sie innerhalb einer verwalteten Knotengruppe den [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) verwenden, wird empfohlen, einen flexiblen Satz von Instance-Typen mit der gleichen Menge an vCPU und Arbeitsspeicherressourcen zu verwenden. Dies soll sicherstellen, dass die Knoten in Ihrem Cluster wie erwartet skalieren. Wenn Sie beispielsweise vier V CPUs - und acht GiB Arbeitsspeicher benötigen, verwenden Sie`c3.xlarge`,`c4.xlarge`,`c5.xlarge`,`c5d.xlarge`, `c5a.xlarge``c5n.xlarge`, oder andere ähnliche Instance-Typen.
+ Um die Anwendungsverfügbarkeit zu verbessern, empfehlen wir Ihnen, mehrere Spot-verwaltete Knotengruppen bereitzustellen. Dafür sollte jede Gruppe einen flexiblen Satz von Instance-Typen verwenden, die über die gleichen vCPU- und Speicherressourcen verfügen. Wenn Sie beispielsweise 4 V CPUs und 8 GiB Arbeitsspeicher benötigen, empfehlen wir Ihnen, eine verwaltete Knotengruppe mit`c3.xlarge`,,,`c4.xlarge`, `c5.xlarge` `c5d.xlarge` `c5a.xlarge``c5n.xlarge`, oder anderen ähnlichen Instanztypen und eine zweite verwaltete Knotengruppe mit`m3.xlarge`,,,`m4.xlarge`, `m5.xlarge` `m5d.xlarge``m5a.xlarge`, `m5n.xlarge` oder anderen ähnlichen Instanztypen zu erstellen.
+ Wenn Sie Ihre Knotengruppe mit dem Spot-Kapazitätstyp bereitstellen, der eine benutzerdefinierte Startvorlage verwendet, verwenden Sie die API, um mehrere Instance-Typen zu übergeben. Übergeben Sie keinen einzelnen Instance-Typ durch die Startvorlage. Weitere Informationen zum Bereitstellen einer Knotengruppe mithilfe einer Startvorlage finden Sie unter[Verwaltete Knoten mit Startvorlagen anpassen](launch-templates.md)aus.
# Eine verwaltete Knotengruppe für Ihren Cluster erstellen
Dieses Thema beschreibt, wie Sie von Amazon EKS verwaltete Knotengruppen von Knoten starten können, die sich bei Ihrem Amazon-EKS-Cluster registrieren. Nachdem die Knoten dem Cluster beigetreten sind, können Sie Kubernetes-Anwendungen darin bereitstellen.
Wenn Sie zum ersten Mal eine von Amazon EKS verwaltete Knotengruppe starten, empfehlen wir Ihnen, stattdessen eine unserer Anleitungen unter [Erste Schritte mit Amazon EKS](getting-started.md) zu befolgen. Diese Anleitungen bieten schrittweise Anleitungen zum Erstellen eines Amazon-EKS-Clusters mit Knoten.
**Wichtig**
Amazon-EKS-Knoten sind Standard-Amazon-EC2-Instances. Die Abrechnung erfolgt auf Grundlage der normalen Amazon-EC2-Preise. Weitere Informationen finden Sie unter [Amazon EC2 – Preise](https://aws.amazon.com/ec2/pricing/).
Sie können keine verwalteten Knoten in einer AWS Region erstellen, in der AWS Outposts oder AWS Wavelength aktiviert sind. Sie könnenSelbstverwaltetes-Knoten. Weitere Informationen finden Sie unter [Selbstverwaltete Amazon-Linux-Knoten erstellen](launch-workers.md), [Selbstverwaltete Microsoft-Windows-Knoten erstellen](launch-windows-workers.md) und [Selbstverwaltete Bottlerocket-Knoten erstellen](launch-node-bottlerocket.md). Sie können auch eine selbstverwaltete Amazon-Linux-Knotengruppe auf einem Outpost erstellen. Weitere Informationen finden Sie unter [Amazon Linux-Knoten auf AWS Outposts erstellen](eks-outposts-self-managed-nodes.md).
Wenn Sie keine [AMI-ID für die `bootstrap.sh`-Datei angeben](launch-templates.md#launch-template-custom-ami), die in Amazon-EKS-optimiertem Linux oder Bottlerocket enthalten ist, erzwingen verwaltete Knotengruppen eine maximale Anzahl für den Wert von `maxPods`. Für Instances mit weniger als 30 V CPUs ist `110` die maximale Anzahl. Bei Instances mit mehr als 30 V CPUs springt die maximale Anzahl auf`250`. Diese Erzwingung hat Vorrang vor anderen `maxPods` Konfigurationen, darunter. `maxPodsExpression` Weitere Informationen darüber, wie es bestimmt `maxPods` wird und wie es angepasst werden kann, finden Sie unter[Wie wird MaxPods bestimmt](choosing-instance-type.md#max-pods-precedence).
+ Ein vorhandener Amazon-EKS-Cluster. Informationen zum Bereitstellen finden Sie unter [Amazon-EKS-Cluster erstellen](create-cluster.md).
+ 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 [Auswahl eines optimalen Instance-Typ für Amazon-EC2-Knoten](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.
+ Um eine von Windows verwaltete Knotengruppe hinzuzufügen, müssen Sie zunächst den Windows-Support für Ihren Cluster aktivieren. Weitere Informationen finden Sie unter [Bereitstellung von Windows-Knoten in EKS-Clustern](windows-support.md).
Sie können eine verwaltete Knotengruppe mit einer der folgenden Optionen erstellen:
+ [`eksctl`](#eksctl_create_managed_nodegroup)
+ [AWS-Managementkonsole](#console_create_managed_nodegroup)
## `eksctl`
**Verwaltete Knotengruppe mit eksctl erstellen**
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).
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. Erstellen Sie eine verwaltete Knotengruppe mit oder ohne Verwendung einer benutzerdefinierten Startvorlage. Das manuelle Angeben einer Startvorlage ermöglicht eine bessere Anpassung einer Knotengruppe. Zum Beispiel kann es die Bereitstellung eines benutzerdefinierten AMI oder die Bereitstellung von Argumenten für das `boostrap.sh`-Skript in einem für Amazon EKS optimierten AMI ermöglichen. Geben Sie den folgenden Befehl ein, um eine vollständige Liste aller verfügbaren Optionen und Standardwerte anzuzeigen.
```
eksctl create nodegroup --help
```
Ersetzen Sie im folgenden Befehl *my-cluster* durch den Namen Ihres Clusters und ersetzen Sie *my-mng* durch den Namen Ihrer 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.
**Wichtig**
Wenn Sie beim erstmaligen Erstellen einer verwalteten Knotengruppe keine benutzerdefinierte Startvorlage verwenden, sollten Sie später auch keine für die Knotengruppe verwenden. Wenn Sie keine benutzerdefinierte Startvorlage angegeben haben, generiert das System automatisch eine Startvorlage, die Sie nicht manuell ändern können. Das manuelle Ändern dieser automatisch generierten Startvorlage kann zu Fehlern führen.
**Ohne Startvorlage**
`eksctl` erstellt eine standardmäßige Amazon-EC2-Startvorlage in Ihrem Konto und stellt die Knotengruppe mithilfe einer Startvorlage bereit, die basierend auf den von Ihnen angegebenen Optionen erstellt wird. Bevor Sie einen Wert für `--node-type` festlegen, siehe [Auswahl eines optimalen Amazon-EC2-Knoten-Instance-Typs](choosing-instance-type.md).
Ersetzen Sie *ami-family* durch ein zulässiges Schlüsselwort. Weitere Informationen finden Sie unter [Einrichtung der Knoten-AMI-Familie](https://eksctl.io/usage/custom-ami-support/#setting-the-node-ami-family) in der `eksctl`-Dokumentation. Ersetzen Sie *my-key* mit dem Namen Ihres Amazon-EC2-Schlüsselpaars oder öffentlichen Schlüssels. Dieser Schlüssel wird für den SSH-Zugriff zu Ihren Knoten verwendet, nachdem diese gestartet wurden.
**Anmerkung**
Für Windows aktiviert dieser Befehl SSH nicht. Stattdessen wird das Amazon-EC2-Schlüsselpaar mit der Instance verknüpft. Außerdem ermöglicht dies eine RDP-Verbindung mit der Instance.
Wenn Sie noch kein Amazon-EC2-Schlüsselpaar haben, können Sie eines in der AWS-Managementkonsole erstellen. Informationen zu Linux finden Sie unter [Amazon-EC2-Schlüsselpaare und Linux-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im *Benutzerhandbuch von Amazon EC2*. Informationen zu Windows finden Sie unter [Amazon-EC2-Schlüsselpaare und Windows-Instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) im *Benutzerhandbuch von Amazon EC2*.
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).
Wenn Sie den Pod-Zugriff auf IMDS blockieren möchten, fügen Sie die `--disable-pod-imds`-Option dem folgenden Befehl hinzu.
```
eksctl create nodegroup \
--cluster my-cluster \
--region region-code \
--name my-mng \
--node-ami-family ami-family \
--node-type m5.large \
--nodes 3 \
--nodes-min 2 \
--nodes-max 4 \
--ssh-access \
--ssh-public-key my-key
```
Ihre Instances können Pods optional eine deutlich höhere Anzahl von IP-Adressen zuweisen, Pods aus einem anderen CIDR-Block als der Instance IP-Adressen zuweisen und in einem Cluster ohne Internetzugang bereitgestellt werden. Weitere Informationen dazu finden Sie unter [Zuweisung weiterer IP-Adressen mit Präfixen zu Amazon-EKS-Knoten](cni-increase-ip-addresses.md), [Bereitstellung von Pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk](cni-custom-network.md) und [Bereitstellung privater Cluster mit eingeschränktem Internetzugang](private-clusters.md) für weitere Optionen, die dem vorherigen Befehl hinzugefügt werden.
Verwaltete Knotengruppen berechnen und wenden einen einzelnen Wert für die maximale Anzahl von Pods an, die auf jedem Knoten Ihrer Knotengruppe ausgeführt werden können, basierend auf dem Instance-Typ. Wenn Sie eine Knotengruppe mit unterschiedlichen Instance-Typen erstellen, wird der kleinste Wert, der für alle Instance-Typen berechnet wird, als die maximale Anzahl von Pods angewendet, die für jeden Instance-Typ in der Knotengruppe ausgeführt werden können. Verwaltete Knotengruppen berechnen den Wert mithilfe des Skripts, auf das in den von verwiesen wird.
**Mit einer Startvorlage**
Die Startvorlage muss bereits vorhanden sein und die in den [Grundlagen der Startvorlagenkonfiguration](launch-templates.md#launch-template-basics) angegebenen Anforderungen erfüllen. 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).
Wenn Sie den Pod-Zugriff auf IMDS blockieren möchten, geben Sie die erforderlichen Einstellungen in der Startvorlage an.
1. Kopieren Sie den folgenden Inhalt auf Ihr Gerät. Ersetzen Sie die Beispielwerte und führen Sie dann den modifizierten Befehl aus, um die Datei zu erstellen. `eks-nodegroup.yaml` Mehrere Einstellungen, die Sie bei der Bereitstellung ohne Startvorlage angeben, werden in die Startvorlage verschoben. Wenn Sie keine `version` angeben, wird die Standardversion verwendet.
```
cat >eks-nodegroup.yaml <
**Verwaltete Knotengruppe mithilfe von AWS-Managementkonsole erstellen **
1. Warten Sie, bis der Status des Clusters als `ACTIVE` angezeigt wird. Sie können keine verwaltete Knotengruppe für einen Cluster erstellen, der noch nicht `ACTIVE` ist.
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie den Namen des Clusters aus, in dem Sie eine verwaltete Knotengruppe erstellen möchten.
1. Wählen Sie die Registerkarte **Compute** (Datenverarbeitung) aus.
1. Wählen Sie **Add Node Group** (Knotengruppe hinzufügen) aus.
1. Geben Sie auf der Seite **Configure node group (Knotengruppe konfigurieren)** die Parameter entsprechend aus, und wählen Sie dann **Next (Weiter)**.
+ **Name** – Geben Sie einen eindeutigen Namen für die verwaltete Knotengruppe ein. 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.
+ **Node IAM role** (Knoten-IAM-Rolle) – Wählen Sie die Knoten-Instance-Rolle aus, die mit Ihrer Knotengruppe verwendet werden soll. Weitere Informationen finden Sie unter [Amazon-EKS-Knoten-IAM-Rolle](create-node-role.md).
**Wichtig**
Sie können nicht dieselbe Rolle verwenden, die zum Erstellen von Clustern verwendet wurde.
Es wird empfohlen, eine Rolle zu verwenden, die derzeit nicht von einer selbstverwalteten Knotengruppe genutzt wird. Andernfalls planen Sie die Verwendung mit einer neuen selbstverwalteten Knotengruppe. Weitere Informationen finden Sie unter [Verwaltete Knotengruppe aus Ihrem Cluster löschen](delete-managed-node-group.md).
+ **Startvorlage verwenden** – (Optional) Wählen Sie aus, ob Sie eine bestehende Startvorlage verwenden möchten. Wählen Sie einen **Namen für die Startvorlage** aus. Wählen Sie dann eine **Launch template version** (Startvorlagenversion) aus. Wenn Sie keine Version auswählen, verwendet Amazon EKS die Standardversion der Vorlage. Startvorlagen ermöglichen eine stärkere Anpassung Ihrer Knotengruppe, z. B. die Bereitstellung eines benutzerdefinierten AMI, die Zuordnung einer deutlich höheren Anzahl von IP-Adressen zu Pods, die Zuordnung von IP-Adressen zu Pods aus einem anderen CIDR-Block als dem der Instance und die Bereitstellung von Knoten in einem Cluster ohne ausgehenden Internetzugang. Weitere Informationen finden Sie unter [Zuweisung weiterer IP-Adressen mit Präfixen zu Amazon-EKS-Knoten](cni-increase-ip-addresses.md), [Bereitstellung von Pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk](cni-custom-network.md) und [Bereitstellung privater Cluster mit eingeschränktem Internetzugang](private-clusters.md).
Die Startvorlage muss die Anforderungen unter [Verwaltete Knoten mit Startvorlagen anpassen](launch-templates.md) erfüllen Wenn Sie keine eigene Startvorlage verwenden, erstellt die Amazon-EKS-API eine standardmäßige Amazon-EC2-Startvorlage in Ihrem Konto und stellt die Knotengruppe mithilfe der Standard-Startvorlage bereit.
Wenn Sie [IAM-Rollen für Dienstkonten](iam-roles-for-service-accounts.md) implementieren, die erforderlichen Berechtigungen direkt jedem Pod zuweisen, der Zugriff auf AWS Dienste benötigt, und keine Pods in Ihrem Cluster aus anderen Gründen Zugriff auf IMDS benötigen, z. B. zum Abrufen der aktuellen AWS Region, können Sie den Zugriff auf IMDS auch für Pods deaktivieren, die kein Host-Netzwerk in einer Startvorlage 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).
+ **Kubernetes labels** – (Optional) Sie können Kubernetes-Labels auf die Knoten in Ihrer verwalteten Knotengruppe anwenden.
+ **Kubernetes-Taints** – (Optional) Sie können Kubernetes-Taints auf die Knoten in Ihrer verwalteten Knotengruppe anwenden. Die verfügbaren Optionen im Menü **Effect** (Effekt) sind ` NoSchedule `, ` NoExecute ` und ` PreferNoSchedule `. Weitere Informationen finden Sie unter [Anleitung: Verhindern, dass Pods auf bestimmten Knoten geplant werden](node-taints-managed-node-groups.md).
+ **Tags** – (Optional) Sie können wählen, ob Sie Ihre mit Amazon EKS verwaltete Knotengruppe taggen möchten. Diese Tags werden nicht an andere Ressourcen in der Knotengruppe, z. B. Auto-Scaling-Gruppen oder Instances, bekannt gegeben. Weitere Informationen finden Sie unter [Organisation von Amazon-EKS-Ressourcen mit Tags](eks-using-tags.md).
1. Geben Sie auf der Seite **Set compute configuration (Datenverarbeitung-Konfiguration einrichten)** die Parameter entsprechend ein, und wählen Sie dann **Next (Weiter)**.
+ **AMI-Typ** – Wählen Sie einen AMI-Typ aus. Wenn Sie Arm-Instances bereitstellen, sollten Sie AMIs vor der Bereitstellung unbedingt die Überlegungen unter [Amazon EKS-optimiertes Arm Amazon Linux](eks-optimized-ami.md#arm-ami) lesen.
Wenn Sie auf der vorherigen Seite eine Startvorlage angegeben haben und in der Startvorlage ein AMI angegeben haben, können Sie keinen Wert auswählen. Der Wert aus der Vorlage wird angezeigt. Das in der Vorlage angegebene AMI muss die Anforderungen unter [Angabe eines AMI](launch-templates.md#launch-template-custom-ami) erfüllen.
+ **Capacity type** (Kapazitätstyp) — Wählen Sie einen Kapazitätstyp aus. Weitere Informationen zur Auswahl eines Kapazitätstyps finden Sie unter [Kapazitätstypen für verwaltete Knotengruppen](managed-node-groups.md#managed-node-group-capacity-types). Es ist nicht möglich, verschiedene Kapazitätstypen innerhalb derselben Knotengruppe zu mischen. Wenn Sie beide Kapazitätstypen verwenden möchten, erstellen Sie separate Knotengruppen mit jeweils eigenen Kapazitäts- und Instance-Typen. Informationen [ GPUs zur Bereitstellung und Skalierung von GPU-beschleunigten Worker-Knoten finden Sie unter Für verwaltete Knotengruppen reservieren](https://docs.aws.amazon.com/eks/latest/userguide/capacity-blocks-mng.html).
+ **Instance-Typen**- Standardmäßig wird ein oder mehrere Instance-Typen angegeben. Um einen Standard-Instance-Typ zu entfernen, wählen Sie `X` auf der rechten Seite des Instance-Typs. Wählen Sie den Instance-Typ aus, der in der verwalteten Knotengruppe verwendet werden soll. Weitere Informationen finden Sie unter [Auswahl eines optimalen Amazon-EC2-Knoten-Instance-Typs](choosing-instance-type.md).
Die Konsole zeigt eine Reihe von häufig verwendeten Instance-Typen an. Wenn Sie eine verwaltete Knotengruppe mit einem Instanztyp erstellen müssen, der nicht angezeigt wird`eksctl`, verwenden Sie die AWS CLI oder ein SDK AWS CloudFormation, um die Knotengruppe zu erstellen. Wenn Sie auf der vorherigen Seite eine Startvorlage angegeben haben, können Sie keinen Wert auswählen, da der Instance-Typ in der Startvorlage angegeben werden muss. Der Wert aus der Startvorlage wird angezeigt. Wenn Sie die Option**Spot-Instances**für**Capacity type (Kapazitätstyp)**Wir empfehlen Ihnen, mehrere Instance-Typen anzugeben, um die Verfügbarkeit zu verbessern.
+ **Datenträgergröße** – Geben Sie die Datenträgergröße (in GiB) ein, die für das Root-Volume des Knotens verwendet werden soll.
Wenn Sie auf der vorherigen Seite eine Startvorlage angegeben haben, können Sie keinen Wert auswählen, da dieser in der Startvorlage angegeben werden muss.
+ **Desired size** (Gewünschte Größe) – Geben Sie die aktuelle Anzahl von Knoten an, die die verwaltete Knotengruppe beim Start beibehalten soll.
**Anmerkung**
Amazon EKS skaliert Ihre Knotengruppe nicht automatisch nach oben oder unten. Sie können jedoch den Kubernetes Cluster Autoscaler so konfigurieren, dass er dies für Sie übernimmt. Weitere Informationen finden Sie unter [Cluster Autoscaler on](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md). AWS
+ **Minimum size** (Mindestgröße) – Geben Sie die Mindestanzahl von Knoten an, auf die die verwaltete Knotengruppe skaliert werden kann.
+ **Maximum size** (Maximale Größe) – Geben Sie die maximale Anzahl von Knoten an, auf die die verwaltete Knotengruppe skaliert werden kann.
+ **Konfiguration der Knotengruppe aktualisieren**— (Optional) Sie können die Anzahl oder den Prozentsatz der Knoten auswählen, die parallel aktualisiert werden sollen. Diese Knoten werden während der Aktualisierung nicht verfügbar sein. Für**Maximal nicht verfügbar**Wählen Sie eine der folgenden Optionen und geben Sie einen**Value**:
+ **Zahl** – Wählen und geben Sie die Anzahl der Knoten in Ihrer Knotengruppe an, die parallel aktualisiert werden können.
+ **Prozentsatz** – Wählen und geben Sie den Prozentsatz der Knoten in der Knotengruppe an, die parallel aktualisiert werden können. Dies ist nützlich, wenn Sie eine große Anzahl von Knoten in Ihrer Knotengruppe haben.
+ **Konfiguration der automatischen Knotenreparatur** – (Optional) Wenn Sie das Kontrollkästchen **Automatische Knotenreparatur aktivieren** aktivieren, ersetzt Amazon EKS automatisch Knoten, wenn erkannte Probleme auftreten. Weitere Informationen finden Sie unter [Erkennen Sie Probleme mit dem Knotenstatus und aktivieren Sie die automatische Knotenreparatur](node-health.md).
1. Füllen Sie auf der Seite **Specify Details** (Details angeben) die Parameter entsprechend aus, und klicken Sie dann auf **Next**.
+ **Subnets** (Subnetze) – Wählen Sie die Subnetze aus, in die die verwalteten Knoten gestartet werden sollen.
**Wichtig**
Wenn Sie eine zustandsbehaftete Anwendung über mehrere Availability Zones hinweg ausführen, die von Amazon-EBS-Volumes gesichert wird und den Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) verwendet, sollten Sie mehrere Knotengruppen konfigurieren, die jeweils für eine einzelne Availability Zone gelten. Außerdem sollten Sie das `--balance-similar-node-groups`-Feature aktivieren.
**Wichtig**
Wenn Sie ein öffentliches Subnetz wählen und in Ihrem Cluster nur der öffentliche API-Server-Endpunkt aktiviert ist, muss das Subnetz `MapPublicIPOnLaunch` auf `true` eingestellt sein, damit die Instances erfolgreich einem Cluster zugeordnet werden können. Wenn das Subnetz am `eksctl` oder nach dem 26. März 2020 mithilfe der von [Amazon EKS bereitgestellten AWS CloudFormation Vorlagen](creating-a-vpc.md) erstellt wurde, ist diese Einstellung bereits auf gesetzt. `true` Wenn die Subnetze mit `eksctl` oder den AWS CloudFormation Vorlagen vor dem 26. März 2020 erstellt wurden, müssen Sie die Einstellung manuell ändern. Weitere Informationen finden Sie unter [Ändern des Attributs für die öffentliche IPv4 Adressierung für Ihr Subnetz](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip).
Wenn Sie eine Startvorlage verwenden und mehrere Netzwerkschnittstellen angeben, weist Amazon EC2 keine öffentliche `IPv4`-Adresse automatisch zu, selbst wenn `MapPublicIpOnLaunch` auf `true` festgelegt ist. Damit Knoten dem Cluster in diesem Szenario beitreten können, müssen Sie entweder den privaten API-Serverendpunkt des Clusters aktivieren oder Knoten in einem privaten Subnetz mit ausgehendem Internetzugriff starten, der über eine alternative Methode wie ein NAT-Gateway bereitgestellt wird. Weitere Informationen dazu finden Sie unter [Amazon-EC2-Instance-IP-Adressen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html) im *Amazon-EC2-Benutzerhandbuch*.
+ **Konfigurieren des SSH-Zugriffs auf Knoten** (Optional). Mit der Aktivierung von SSH können Sie eine Verbindung zu Ihren Instances herstellen und Diagnoseinformationen erfassen, wenn Probleme auftreten. Wir empfehlen dringend, den Fernzugriff zu aktivieren, sobald Sie eine Knotengruppe erstellen. Sie können den Fernzugriff nicht mehr aktivieren, nachdem die Knotengruppe erstellt wurde.
Wenn Sie eine Startvorlage verwenden möchten, wird diese Option nicht angezeigt. Um den Remotezugriff auf Ihre Knoten zu aktivieren, geben Sie in der Startvorlage ein Schlüsselpaar an und stellen Sie sicher, dass die richtige Schnittstelle für die Knoten in den Sicherheitsgruppen geöffnet ist, die Sie in der Startvorlage angeben. Weitere Informationen finden Sie unter [Benutzerdefinierte Sicherheitsgruppen](launch-templates.md#launch-template-security-groups).
**Anmerkung**
Für Windows aktiviert dieser Befehl SSH nicht. Stattdessen wird das Amazon-EC2-Schlüsselpaar mit der Instance verknüpft. Außerdem ermöglicht dies eine RDP-Verbindung mit der Instance.
+ Für **SSH-Schlüsselpaar** (optional) wählen Sie einen Amazon-EC2-SSH-Schlüssel aus, der verwendet werden soll. Informationen zu Linux finden Sie unter [Amazon-EC2-Schlüsselpaare und Linux-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im *Benutzerhandbuch von Amazon EC2*. Informationen zu Windows finden Sie unter [Amazon-EC2-Schlüsselpaare und Windows-Instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) im *Benutzerhandbuch von Amazon EC2*. Wenn Sie eine Startvorlage verwenden möchten, können Sie keine auswählen. Wenn ein Amazon EC2 EC2-SSH-Schlüssel für Knotengruppen bereitgestellt wird, die Bottlerocket verwenden AMIs, ist der administrative Container ebenfalls aktiviert. Weitere Informationen finden Sie unter [Administrator-Container](https://github.com/bottlerocket-os/bottlerocket#admin-container) auf GitHub.
+ Für **Zulassen des SSH-Remote-Zugriffs von**, wenn Sie den Zugriff auf bestimmte Instances beschränken möchten, wählen Sie die Sicherheitsgruppen aus, die diesen Instances zugeordnet sind. Wenn Sie keine bestimmten Sicherheitsgruppen auswählen, ist SSH-Zugriff von überall im Internet erlaubt (`0.0.0.0/0`).
1. Überprüfen Sie auf der Seite **Review and create (Überprüfen und Erstellen)** die Konfiguration der verwalteten Knoten, und wählen Sie **Create (Erstellen)**.
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. Sehen Sie sich den Status Ihrer Knoten an und warten Sie, bis diese in den `Ready`-Status eintreten.
```
kubectl get nodes --watch
```
1. (Nur GPU-Knoten) Wenn Sie einen GPU-Instance-Typ und ein für Amazon EKS optimiertes beschleunigtes AMI ausgewählt haben, müssen Sie das [NVIDIA-Geräte-Plug-In für Kubernetes](https://github.com/NVIDIA/k8s-device-plugin) als 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
```
## Kubernetes-Add-Ons installieren
Nachdem Sie nun über einen funktionierenden Amazon-EKS-Cluster mit Worker-Knoten verfügen, können Sie mit der Installation von Kubernetes-Add-Ons und -Anwendungen auf Ihrem Cluster beginnen. Die folgenden Dokumentationsthemen helfen Ihnen bei der Erweiterung der Funktionalität Ihres Clusters.
+ Der [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), der den Cluster erstellt hat, ist der einzige Prinzipal, der Aufrufe an den Kubernetes-API-Server mit `kubectl` oder AWS-Managementkonsole tätigen kann. Wenn Sie möchten, dass andere IAM-Prinzipale Zugriff auf Ihren Cluster haben, müssen Sie sie hinzufügen. Weitere Informationen erhalten Sie unter [Gewähren Sie IAM-Benutzern und -Rollen Zugriff auf Kubernetes APIs](grant-k8s-access.md) und [Erforderliche Berechtigungen](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
+ 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).
+ Konfigurieren Sie den Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md), um die Anzahl der Knoten in Ihren Knotengruppen automatisch anzupassen.
+ Stellen Sie eine [Beispielanwendung](sample-deployment.md) für Ihr Cluster bereit.
+ [Organisieren und überwachen Sie Cluster-Ressourcen](eks-managing.md) mit wichtigen Tools für die Verwaltung Ihres Clusters.
# Eine verwaltete Knotengruppe für Ihren Cluster aktualisieren
Wenn Sie eine Aktualisierung der verwalteten Knotengruppe initiieren, aktualisiert Amazon EKS Ihre Knoten automatisch für Sie. Führen Sie die Schritte aus, die unter [Jede Phase der Knotenaktualisierungen verstehen](managed-node-update-behavior.md) aufgelistet sind. Wenn Sie ein Amazon-EKS-optimiertes AMI verwenden, wendet Amazon EKS automatisch die neuesten Sicherheits-Patches und Betriebssystem-Aktualisierungen auf Ihre Knoten als Teil der neuesten AMI-Versionsversion an.
Es gibt mehrere Szenarien, in denen Sie die Version oder Konfiguration Ihrer verwalteten Amazon-EKS-Knotengruppe aktualisieren:
+ Sie haben die Kubernetes-Version für Ihren Amazon-EKS-Cluster aktualisiert und möchten Ihre Arbeitsknoten so aktualisieren, dass sie dieselbe Kubernetes-Version verwenden.
+ Eine neue AMI-Version ist für Ihre verwaltete Knotengruppe verfügbar. Weitere Informationen zu AMI-Versionen finden Sie unter diesen Abschnitten:
+ [Abrufen der Versionsinformationen zu Amazon-Linux-AMI](eks-linux-ami-versions.md)
+ [Erstellen Sie Knoten mit optimiertem Bottlerocket AMIs](eks-optimized-ami-bottlerocket.md)
+ [Abrufen der Windows-AMI-Versionsinformationen](eks-ami-versions-windows.md)
+ Sie möchten die minimale, maximale oder gewünschte Anzahl der Instances in Ihrer verwalteten Knotengruppe anpassen.
+ Sie möchten Kubernetes-Labels hinzufügen oder aus den Instances in Ihrer verwalteten Knotengruppe entfernen.
+ Sie möchten Ihrer verwalteten Knotengruppe AWS Tags hinzufügen oder daraus entfernen.
+ Sie müssen eine neue Version einer Startvorlage mit Konfigurationsänderungen bereitstellen, z. B. ein aktualisiertes benutzerdefiniertes AMI.
+ Sie haben Version `1.9.0` oder höher des Amazon VPC CNI-Add-ons bereitgestellt, das Add-on für die Präfix-Delegierung aktiviert und möchten, dass neue AWS Nitro System-Instances in einer Knotengruppe eine deutlich höhere Anzahl von Pods unterstützen. Weitere Informationen finden Sie unter [Zuweisung weiterer IP-Adressen mit Präfixen zu Amazon-EKS-Knoten](cni-increase-ip-addresses.md).
+ Sie haben die IP-Präfix-Delegierung für Windows-Knoten aktiviert und möchten, dass neue AWS Nitro System-Instances in einer Knotengruppe eine deutlich höhere Anzahl von Pods unterstützen. Weitere Informationen finden Sie unter [Zuweisung weiterer IP-Adressen mit Präfixen zu Amazon-EKS-Knoten](cni-increase-ip-addresses.md).
Wenn es eine neuere AMI-Version für die Kubernetes-Version Ihrer verwalteten Knotengruppe gibt als die, welche Ihre Knotengruppe derzeit ausführt, können Sie sie aktualisieren, um diese neue AMI-Version zu verwenden. Wenn Ihr Cluster eine neuere Kubernetes-Version als Ihre Knotengruppe ausführt, können Sie die Knotengruppe so aktualisieren, dass sie die neueste AMI-Version verwendet, welche der Kubernetes-Version Ihres Clusters entspricht.
Wenn ein Knoten in einer verwalteten Knotengruppe aufgrund eines Skalierungsvorgangs oder Aktualisierung beendet wird, werden die Pods in diesem Knoten zuerst geleert. Weitere Informationen finden Sie unter [Alle Phasen der Knotenaktualisierung verstehen](managed-node-update-behavior.md).
## Aktualisieren einer Knotengruppenversion
Sie können eine Knotengruppen-Version mit einer der folgenden Methoden aktualisieren:
+ [`eksctl`](#eksctl_update_managed_nodegroup)
+ [AWS-Managementkonsole](#console_update_managed_nodegroup)
Die Version, auf die Sie aktualisieren, darf nicht höher sein als die Version der Steuerebene.
## `eksctl`
**Aktualisierung einer verwalteten Knotengruppe mithilfe von `eksctl`**
Aktualisieren Sie eine verwaltete Knotengruppe mit dem folgenden Befehl auf die neueste AMI-Version derselben Kubernetes-Version, die derzeit auf den Knoten bereitgestellt wird. Ersetzen Sie jede *example value* durch Ihre eigenen Werte.
```
eksctl upgrade nodegroup \
--name=node-group-name \
--cluster=my-cluster \
--region=region-code
```
**Anmerkung**
Wenn Sie eine Knotengruppe, die mit einer Startvorlage bereitgestellt wurde, auf eine neue Version der Startvorlage aktualisieren, fügen Sie `--launch-template-version version-number ` dem vorangehenden Befehl hinzu. Die Startvorlage muss die unter [Anpassen verwalteter Knoten mit Startvorlagen](launch-templates.md) beschriebenen Anforderungen erfüllen. Wenn die Startvorlage eine benutzerdefinierte AMI enthält, muss die AMI die Anforderungen unter [Angabe einer AMI](launch-templates.md#launch-template-custom-ami) erfüllen. Wenn Sie Ihre Knotengruppe auf eine neuere Version Ihrer Startvorlage aktualisieren, wird jeder Knoten wiederverwertet, um mit der neuen Konfiguration der angegebenen Startvorlagenversion übereinzustimmen.
Sie können eine Knotengruppe, die ohne eine Startvorlage bereitgestellt wird, nicht direkt auf eine neue Startvorlagenversion aktualisieren. Stattdessen müssen Sie mithilfe der Startvorlage eine neue Knotengruppe bereitstellen, um die Knotengruppe auf eine neue Version der Startvorlage zu aktualisieren.
Sie können eine Knotengruppe auf dieselbe Version aktualisieren wie die Kubernetes-Version der Steuerebene. Wenn Sie beispielsweise über einen Cluster mit Kubernetes `1.35` verfügen, können Sie Knoten, auf denen derzeit Kubernetes `1.34` ausgeführt wird, mit dem folgenden Befehl auf Version `1.35` aktualisieren.
```
eksctl upgrade nodegroup \
--name=node-group-name \
--cluster=my-cluster \
--region=region-code \
--kubernetes-version=1.35
```
## AWS-Managementkonsole
**Aktualisierung einer verwalteten Knotengruppe mithilfe von AWS-Managementkonsole **
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie den Cluster aus, der die zu aktualisierende Knotengruppe enthält.
1. Wenn mindestens eine Knotengruppe über ein verfügbares Update verfügt, wird oben auf der Seite ein Feld angezeigt, in dem Sie über das verfügbare Update informiert werden. Wenn Sie die Registerkarte **Datenverarbeitung** wählen, finden Sie den Eintrag **Jetzt aktualisieren** in der Spalte **AMI-Vorversion** in der Tabelle **Knotengruppen** für die Knotengruppe, für die eine Aktualisierung verfügbar ist. Um die Knotengruppe zu aktualisieren, wählen Sie **Update now** (Jetzt aktualisieren).
Es wird keine Benachrichtigung für Knotengruppen angezeigt, die mit einem benutzerdefinierten AMI bereitgestellt wurden. Wenn Ihre Knoten mit einem benutzerdefinierten AMI bereitgestellt werden, führen Sie die folgenden Schritte aus, um ein neues aktualisiertes benutzerdefiniertes AMI bereitzustellen.
1. Erstellen Sie eine neue Version Ihres AMI.
1. Erstellen Sie eine neue Version der Startvorlage mit der neuen AMI-ID.
1. Aktualisieren Sie die Knoten auf die neue Version der Startvorlage.
1. Aktivieren oder deaktivieren Sie im Dialogfeld **Update node group version** (Knotengruppenversion aktualisieren) die folgenden Optionen:
+ **Update node group version** (Knotengruppenversion aktualisieren) – Diese Option ist nicht verfügbar, wenn Sie ein benutzerdefiniertes AMI bereitgestellt haben oder Ihr Amazon EKS-optimiertes AMI derzeit über die neueste Version für Ihren Cluster verfügt.
+ **Change launch template version** (Startvorlagenversion ändern) – Diese Option ist nicht verfügbar, wenn die Knotengruppe ohne eine benutzerdefinierte Startvorlage bereitgestellt wird. Sie können die Version der Startvorlage nur für eine Knotengruppe aktualisieren, die mit einer benutzerdefinierten Startvorlage bereitgestellt wurde. Wählen Sie die **Launch template version** (Startvorlagenversion) aus, auf die Sie die Knotengruppe aktualisieren möchten. Wenn Ihre Knotengruppe mit einem benutzerdefinierten AMI konfiguriert ist, muss die ausgewählte Version auch ein AMI angeben. Wenn Sie ein Upgrade auf eine neuere Version Ihrer Startvorlage durchführen, wird jeder Knoten wiederverwertet, damit er der neuen Konfiguration der angegebenen Startvorlagenversion entspricht.
1. Wählen Sie für **Update strategy** (Aktualisierungsstrategie) eine der folgenden Optionen aus:
+ **Fortlaufende Aktualisierung** – Diese Option berücksichtigt die Budgets für die Pod-Unterbrechung Ihres Clusters. Aktualisierungen schlagen fehl, wenn ein Problem mit einem Budget für Pod-Unterbrechung auftritt, das dazu führt, dass Amazon EKS die Pods, die auf dieser Knotengruppe ausgeführt werden, nicht ordnungsgemäß entleert werden kann.
+ **Aktualisierung erzwingen** – Bei dieser Option werden Budgets für Pod-Unterbrechungen nicht berücksichtigt. Aktualisierungen erfolgen unabhängig von Problemen mit Budgets für Pod-Unterbrechung, indem Knoten-Neustarts erzwungen werden.
1. Wählen Sie **Aktualisieren** aus.
## Bearbeiten einer Knotengruppenkonfiguration
Sie können einige Konfigurationen einer verwalteten Knotengruppe ändern.
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie den Cluster aus, der die zu bearbeitende Knotengruppe enthält.
1. Wählen Sie die Registerkarte **Compute** (Datenverarbeitung) aus.
1. Wählen Sie die zu bearbeitende Knotengruppe aus und wählen Sie dann **Edit** (Bearbeiten).
1. (Optional) Gehen Sie auf der Seite **Edit node group** (Knotengruppe bearbeiten) wie folgt vor:
1. Bearbeiten Sie die **Node group scaling configuration** (Skalierungskonfiguration der Knotengruppe).
+ **Desired size** (Gewünschte Größe) – Geben Sie die aktuelle Anzahl von Knoten an, die die verwaltete Knotengruppe beibehalten soll.
+ **Minimum size** (Mindestgröße) – Geben Sie die Mindestanzahl von Knoten an, auf die die verwaltete Knotengruppe skaliert werden kann.
+ **Maximum size** (Maximale Größe) – Geben Sie die maximale Anzahl von Knoten an, auf die die verwaltete Knotengruppe skaliert werden kann. Die maximale Anzahl von Knoten, die in einer Knotengruppe unterstützt werden, finden Sie unter [Service Quotas für Amazon EKS und Fargate anzeigen und verwalten](service-quotas.md).
1. (Optional) Fügen Sie den Knoten in Ihrer Knotengruppe **Kubernetes-Labels** hinzu oder entfernen Sie sie. Die hier gezeigten Labels sind nur die Labels, die Sie mit Amazon EKS angewendet haben. Andere Labels können auf Ihren Knoten vorhanden sein, die hier nicht angezeigt werden.
1. (Optional) Fügen Sie den Knoten in Ihrer Knotengruppe **Kubernetes-Taints** hinzu oder entfernen Sie sie. Hinzugefügte Färbungen können die Wirkung von ` NoSchedule `,` NoExecute `, oder` PreferNoSchedule ` haben. Weitere Informationen finden Sie unter [Anleitung: Verhindern, dass Pods auf bestimmten Knoten geplant werden](node-taints-managed-node-groups.md).
1. (Optional) Fügen Sie **Tags** zu Ihrer Knotengruppenressource hinzu oder entfernen Sie sie. Diese Markierungen werden nur auf die Amazon-EKS-Knotengruppe angewendet. Knotengruppen-Tags werden nicht auf andere Ressourcen übertragen, die der Knotengruppe zugeordnet sind, z. B. die Amazon-EC2-Instances oder Subnetze.
1. (Optional) Bearbeiten Sie **Konfiguration der Knotengruppe aktualisieren**. Wählen Sie entweder **Zahl** oder **Prozentanteil** aus.
+ **Zahl** – Wählen und geben Sie die Anzahl der Knoten in Ihrer Knotengruppe an, die parallel aktualisiert werden können. Diese Knoten sind während der Aktualisierung nicht verfügbar.
+ **Prozentsatz** – Wählen und geben Sie den Prozentsatz der Knoten in der Knotengruppe an, die parallel aktualisiert werden können. Diese Knoten sind während der Aktualisierung nicht verfügbar. Dies ist nützlich, wenn Sie viele Knoten in Ihrer Knotengruppe haben.
1. Wenn Sie mit der Bearbeitung fertig sind, wählen Sie **Änderungen speichern** aus.
**Wichtig**
Bei der Aktualisierung der Knotengruppenkonfiguration werden bei der Änderung der [https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html)nicht die Budgets für Pod-Unterbrechungen berücksichtigt (PDBs). Im Gegensatz zum Prozess zum [Aktualisieren von Knotengruppen](managed-node-update-behavior.md) (bei dem PDBs während der Upgrade-Phase Knoten leer und respektiert werden) führt die Aktualisierung der Skalierungskonfiguration dazu, dass Knoten sofort durch einen Auto Scaling Scale-Down-Aufruf (ASG) beendet werden. Dies geschieht ohne weitere Überlegungen PDBs, unabhängig von der Zielgröße, auf die Sie herunterskalieren. Das heißt, wenn Sie die Anzahl einer `desiredSize` von Amazon EKS verwalteten Knotengruppe reduzieren, werden Pods entfernt, sobald die Knoten beendet werden, ohne dass sie berücksichtigt werden. PDBs
# Alle Phasen der Knotenaktualisierung verstehen
Die Upgrade-Strategie für verwaltete Amazon-EKS-Worker-Knoten umfasst vier verschiedene Phasen, die in den folgenden Abschnitten beschrieben werden.
## Einrichtungsphase
Die Einrichtungsphase umfasst folgende Schritte:
1. Erstellt eine neue Amazon-EC2-Startvorlage für die Auto-Scaling-Gruppe, die Ihrer Knotengruppe zugeordnet ist. Die neue Version der Startvorlage verwendet das Ziel-AMI oder die vom Kunden bereitgestellte Startvorlagenversion für die Aktualisierung.
1. Die Auto-Scaling-Gruppe wird so aktualisiert, dass sie die neueste Startvorlage verwendet.
1. Es bestimmt die maximale Anzahl der parallel zu aktualisierenden Knoten mithilfe der `updateConfig`-Eigenschaft für die Knotengruppe. Der maximal nicht verfügbare Wert hat ein Kontingent von 100 Knoten. Der Standardwert beträgt einen Knoten. Weitere Informationen dazu finden Sie unter der Eigenschaft [updateConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateNodegroupConfig.html#API_UpdateNodegroupConfig_RequestSyntax) in der *Amazon-EKS-API-Referenz*.
## Aufskalierungsphase
Beim Upgrade der Knoten in einer verwalteten Knotengruppe werden die aktualisierten Knoten in derselben Availability Zone gestartet wie diejenigen, die aktualisiert werden. Um diese Platzierung zu garantieren, verwenden wir das Availability Zone Rebalancing von Amazon EC2. Weitere Informationen dazu finden Sie unter [Availability-Zone-Rebalancing](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage) im *Amazon-EC2-Auto-Scaling-Benutzerhandbuch*. Um diese Anforderung zu erfüllen, ist es möglich, dass wir bis zu zwei Instances pro Availability Zone in Ihrer verwalteten Knotengruppe starten.
Die Aufskalierungsphase umfasst folgende Schritte:
1. Es erhöht die maximale Größe und die gewünschte Größe der Auto-Scaling-Gruppe um den jeweils größeren Wert:
+ Bis zu doppelt so viele Availability Zones, in denen die Auto-Scaling-Gruppe bereitgestellt wird.
+ Die maximale Nichtverfügbarkeit der Aktualisierung.
Wenn Ihre Knotengruppe beispielsweise über fünf Availability Zones und `maxUnavailable` als eine verfügt, kann der Upgrade-Prozess maximal zehn Knoten starten. Wenn jedoch `maxUnavailable` 20 ist (oder etwas größer als 10, würde der Prozess 20 neue Knoten starten).
1. Nach dem Skalieren der Auto-Scaling-Gruppe wird überprüft, ob die Knoten, die die neueste Konfiguration verwenden, in der Knotengruppe vorhanden sind. Dieser Schritt ist nur erfolgreich, wenn er diese Kriterien erfüllt:
+ Mindestens ein neuer Knoten wird in jeder Availability Zone gestartet, in der der Knoten existiert.
+ Jeder neue Knoten sollte im `Ready`-Zustand sein.
+ Neue Knoten sollten Amazon-EKS-Labels angewandt haben.
Dies sind die von Amazon EKS auf die Worker-Knoten in einer regulären Knotengruppe angewandten Labels:
+ `eks.amazonaws.com/nodegroup-image=$amiName`
+ `eks.amazonaws.com/nodegroup=$nodeGroupName`
Dies sind die von Amazon EKS angewendeten Labels auf den Worker-Knoten in einer benutzerdefinierten Startvorlage oder AMI-Knotengruppe:
+ `eks.amazonaws.com/nodegroup-image=$amiName`
+ `eks.amazonaws.com/nodegroup=$nodeGroupName`
+ `eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId`
+ `eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion`
1. Es markiert Knoten als nicht planbar, um die Planung neuer Pods zu vermeiden. Es kennzeichnet Knoten auch mit `node.kubernetes.io/exclude-from-external-load-balancers=true`, um die Knoten aus den Load Balancern zu entfernen, bevor die Knoten beendet werden.
Die folgenden sind bekannte Gründe, die zu einem `NodeCreationFailure`-Fehler in dieser Phase führen:
**Nicht genügend Kapazität in der Availability Zone**
Es besteht die Möglichkeit, dass die Availability Zone nicht über die Kapazität der angeforderten Instance-Typen verfügt. Es wird empfohlen, beim Erstellen einer verwalteten Knotengruppe mehrere Instance-Typen zu konfigurieren.
**EC2-Instance-Limits in Ihrem Konto**
Möglicherweise müssen Sie die Anzahl der Amazon-EC2-Instances erhöhen, die Ihr Konto gleichzeitig mit Service Quotas ausführen kann. Weitere Informationen dazu finden Sie unter [EC2-Service-Quotas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) im *Amazon-Elastic-Compute-Cloud-Benutzerhandbuch für Linux-Instances*.
**Anwenderbezogene Benutzerdaten**
Anwenderbezogene Benutzerdaten können manchmal den Bootstrap-Prozess stören. Dieses Szenario kann dazu führen, dass `kubelet` nicht auf dem Knoten startet oder Knoten nicht die erwarteten Amazon-EKS-Labels auf ihnen erhalten. Weitere Informationen finden Sie unter [Angeben eines AMI](launch-templates.md#launch-template-custom-ami).
**Alle Änderungen, die dazu führen, dass ein Knoten fehlerhaft ist oder nicht bereit ist**
Knotenfestplattendruck, Speicherdruck und ähnliche Bedingungen können dazu führen, dass ein Knoten nicht in den `Ready`-Zustand wechselt.
**Jeder Knoten wird in der Regel innerhalb von 15 Minuten gebootet**
Wenn ein Knoten länger als 15 Minuten zum Bootstrapping und Beitritt zum Cluster benötigt, kommt es zu einer Zeitüberschreitung des Upgrades. Dies ist die Gesamtlaufzeit für das Booten eines neuen Knotens, gemessen von der Zeit, in welcher der neue Knoten benötigt wird, bis zu seinem Beitritt zum Cluster. Bei der Aktualisierung einer verwalteten Knotengruppe beginnt der Zeitzähler zu laufen, sobald die Größe der Auto-Scaling-Gruppe zunimmt.
## Aktualisierungs-Phase
Die Aktualisierungsphase verläuft je nach *Aktualisierungsstrategie* auf zwei unterschiedliche Arten. Es gibt zwei Aktualisierungsstrategien: **Standard** und **Minimal**.
Wir empfehlen in den meisten Fällen die Standard-Strategie. Diese erstellt neue Knoten, bevor die alten beendet werden, sodass die verfügbare Kapazität während der Aktualisierungsphase erhalten bleibt. Diese Minimal-Strategie ist in Szenarien sinnvoll, in denen Sie hinsichtlich Ressourcen oder Kosten eingeschränkt sind, beispielsweise bei Hardware-Beschleunigern wie GPUs. Es werden die alten Knoten beendet, bevor neue erstellt werden, sodass die Gesamtkapazität niemals über die von Ihnen konfigurierte Menge hinausgeht.
Die *Standard*-Aktualisierungsstrategie umfasst folgende Schritte:
1. Die Anzahl der Knoten (gewünschte Anzahl) in der Auto-Scaling-Gruppe wird erhöht, wodurch die Knotengruppe zusätzliche Knoten erstellt.
1. Es wählt nach dem Zufallsprinzip einen Knoten aus, der aktualisiert werden muss, bis zum Maximum der für die Knotengruppe nicht verfügbar ist.
1. Es entleert die Pods vom Knoten. Wenn die Pods den Knoten nicht innerhalb von 15 Minuten verlassen und es kein Erzwingungs-Flag gibt, scheitert die Aktualisierungsphase mit einem `PodEvictionFailure`-Fehler. Für dieses Szenario können Sie das Erzwingungs-Flag mit der `update-nodegroup-version`-Anforderung anwenden, um die Pods zu löschen.
1. Der Knoten wird nach dem Entfernen jedes Pods gesperrt und wartet 60 Sekunden lang. Dies geschieht, damit der Service-Controller keine neuen Anfragen an diesen Knoten sendet und diesen Knoten aus seiner Liste der aktiven Knoten entfernt.
1. Es sendet eine Beendigungsanforderung an die Auto-Scaling-Gruppe für den abgesperrten Knoten.
1. Es wiederholt die vorherigen Aktualisierungsschritte, bis keine Knoten in der Knotengruppe mehr vorhanden sind, die mit der früheren Version der Startvorlage bereitgestellt wurden.
Die *Minimal*-Aktualisierungsstrategie umfasst folgende Schritte:
1. Zunächst werden alle Knoten der Knotengruppe gesperrt, sodass der Service-Controller keine neuen Anfragen an diese Knoten sendet.
1. Es wählt nach dem Zufallsprinzip einen Knoten aus, der aktualisiert werden muss, bis zum Maximum der für die Knotengruppe nicht verfügbar ist.
1. Es entleert die Pods aus den ausgewählten Knoten. Wenn die Pods den Knoten nicht innerhalb von 15 Minuten verlassen und es kein Erzwingungs-Flag gibt, scheitert die Aktualisierungsphase mit einem `PodEvictionFailure`-Fehler. Für dieses Szenario können Sie das Erzwingungs-Flag mit der `update-nodegroup-version`-Anforderung anwenden, um die Pods zu löschen.
1. Nachdem jeder Pod entfernt wurde und 60 Sekunden gewartet hat, sendet er eine Beendigungsanforderung an die Auto-Scaling-Gruppe für die ausgewählten Knoten. Die Auto-Scaling-Gruppe erstellt neue Knoten (entsprechend der Anzahl der ausgewählten Knoten), um die fehlende Kapazität zu ersetzen.
1. Es wiederholt die vorherigen Aktualisierungsschritte, bis keine Knoten in der Knotengruppe mehr vorhanden sind, die mit der früheren Version der Startvorlage bereitgestellt wurden.
### `PodEvictionFailure`-Fehler während der Aktualisierungsphase
Die folgenden sind bekannte Gründe, die zu einem `PodEvictionFailure`-Fehler in dieser Phase führen:
**Aggressive PDB**
Aggressive PDB ist auf dem Pod definiert oder es gibt mehrere PDBs, die auf denselben Pod zeigen.
**Bereitstellung unterstützt alle Taints**
Sobald jeder Pod entfernt wurde, wird erwartet, dass der Knoten leer ist, da der Knoten in den vorherigen Schritten [verunreinigt](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) ist. Wenn die Bereitstellung jedoch jeden Taint toleriert, ist der Knoten eher nicht leer, was zu einem Pod-Bereinigungsfehler führt.
## Abskalierungsphase
Die Abskalierungsphase verringert die maximale Größe der Auto-Scaling-Gruppe und die gewünschte Größe um eins, um zu den Werten zurückzukehren, bevor die Aktualisierung gestartet wurde.
Wenn der Upgrade-Workflow feststellt, dass der Cluster-Autoscaler die Knotengruppe während der Herunterskalierungsphase des Workflows skaliert, wird er sofort beendet, ohne die Knotengruppe wieder auf ihre ursprüngliche Größe zu bringen.
# Verwaltete Knoten mit Startvorlagen anpassen
Für ein Höchstmaß an Anpassung können Sie verwaltete Knoten mit Ihrer eigenen Startvorlage bereitstellen, die auf den Schritten auf dieser Seite basiert. Die Verwendung einer Startvorlage ermöglicht Funktionen wie das Bereitstellen von Bootstrap-Argumenten während der Bereitstellung eines Knotens (z. B. zusätzliche [Kubelet-Argumente](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)), das Zuweisen von IP-Adressen zu Pods aus einem anderen CIDR-Block als der dem Knoten zugewiesenen IP-Adresse, das Bereitstellen Ihres eigenen benutzerdefinierten AMI für Knoten oder das Bereitstellen Ihres eigenen benutzerdefinierten CNI für Knoten.
Wenn Sie beim ersten Erstellen einer verwalteten Knotengruppe Ihre eigene Startvorlage angeben, haben Sie auch später mehr Flexibilität. Wenn Sie eine verwaltete Knotengruppe mit Ihrer eigenen Startvorlage bereitstellen, können Sie sie schrittweise mit einer anderen Version derselben Startvorlage aktualisieren. Wenn Sie Ihre Knotengruppe auf eine andere Version Ihrer Startvorlage aktualisieren, werden alle Knoten in der Gruppe wiederverwertet, damit sie der neuen Konfiguration der angegebenen Startvorlagenversion entsprechen.
Verwaltete Knotengruppen werden immer mit einer Startvorlage bereitgestellt, die mit der Amazon-EC2-Auto-Scaling-Gruppe verwendet werden soll. Wenn Sie keine Startvorlage bereitstellen, erstellt die Amazon-EKS-API automatisch eine mit Standardwerten in Ihrem Konto. Es wird jedoch nicht empfohlen, automatisch generierte Startvorlagen zu ändern. Außerdem können vorhandene Knotengruppen, die keine benutzerdefinierte Startvorlage verwenden, nicht direkt aktualisiert werden. Stattdessen müssen Sie eine neue Knotengruppe mit einer benutzerdefinierten Startvorlage erstellen.
## Grundlagen der Konfiguration der Vorlage starten
Sie können eine Amazon EC2 Auto Scaling Scaling-Startvorlage mit der AWS-Managementkonsole AWS CLI oder einem AWS SDK erstellen. Weitere Informationen finden Sie unter [Erstellen einer Startvorlage für eine Auto-Scaling-Gruppe](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html) im *Amazon-EC2-Auto-Scaling-Benutzerhandbuch*. Einige der Einstellungen in einer Startvorlage ähneln den Einstellungen, die für die Konfiguration verwalteter Knoten verwendet werden. Beim Bereitstellen oder Aktualisieren einer Knotengruppe mit einer Startvorlage müssen einige Einstellungen entweder in der Knotengruppenkonfiguration oder in der Startvorlage angegeben werden. Geben Sie eine Einstellung nicht an beiden Stellen an. Wenn eine Einstellung vorhanden ist, wo sie nicht sollte, schlagen Vorgänge wie das Erstellen oder Aktualisieren einer Knotengruppe fehl.
In der folgenden Tabelle werden die Einstellungen aufgelistet, die in einer Startvorlage nicht zulässig sind. Es listet auch ähnliche Einstellungen auf, falls verfügbar, die in der Konfiguration der verwalteten Knotengruppe erforderlich sind. Die aufgelisteten Einstellungen sind die Einstellungen, die in der Konsole angezeigt werden. Sie haben möglicherweise ähnliche, aber unterschiedliche Namen in der AWS CLI und im SDK.
| Startvorlage - Verboten | Amazon-EKS-Knotengruppenkonfiguration |
| --- | --- |
| **Subnetz** in **Netzwerkschnittstellen** (**Hinzufügen einer Netzwerkschnittstelle**) | **Subnets** (Subnetze) unter **Node group network configuration** (Netzwerkkonfiguration der Knotengruppe) auf der Seite **Specify networking** (Netzwerk angeben) |
| **IAM-Instance-Profil** in **Erweiterte Details** | **Node IAM role** (Knoten-IAM-Rolle) unter **Node group configuration** (Knotengruppenkonfiguration) auf der Seite **Configure Node group** (Knotengruppe konfigurieren) |
| **Verhalten beim Herunterfahren** und **Stop – Ruhezustand Verhalten** in **Erweiterte Details**. Standardeinstellung **Nicht in Startvorlage einschließen** für beide Einstellungen beibehalten. | Keine Entsprechung Amazon EKS muss den Instance-Lebenszyklus steuern, nicht die Auto-Scaling-Gruppe. |
In der folgenden Tabelle sind die unzulässigen Einstellungen in einer Konfiguration einer verwalteten Knotengruppe aufgeführt. Sie listet auch ähnliche Einstellungen auf, falls vorhanden, die in einer Startvorlage erforderlich sind. Die aufgelisteten Einstellungen sind die Einstellungen, die in der Konsole angezeigt werden. Sie haben möglicherweise ähnliche Namen in der AWS CLI und im SDK.
| Konfiguration der Amazon-EKS-Knotengruppe — Verboten | Startvorlage |
| --- | --- |
| (Nur wenn Sie ein benutzerdefiniertes AMI in einer Startvorlage angegeben haben) **AMI type** (AMI-Typ) unter **Node Group compute configuration** (Computing-Konfiguration der Knotengruppe) auf der Seite **Set compute and scaling configuration** (Computing- und Skalierungskonfiguration festlegen) – Die Konsole zeigt **Specified in launch template** (In Startvorlage angegeben) und die angegebene AMI-ID an. Wenn **Anwendungs- und Betriebssystem-Images (Amazon Machine Image)** nicht in der Startvorlage kein AMI-Typ angegeben wurde, können Sie in der Knotengruppenkonfiguration ein AMI auswählen. | **Application and OS Images (Amazon Machine Image)** (Anwendungs- und Betriebssystem-Images (Amazon Machine Image)) unter **Inhalt der Startvorlage** – Sie müssen eine ID angeben, wenn Sie eine der folgenden Anforderungen haben: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/launch-templates.html) |
| **Datenträgergröße** unter **Node Group compute configuration** (Computing-Konfiguration der Knotengruppe) auf der Seite **Set compute and scaling configuration** – Die Konsole zeigt **Specified in launch template** (In Startvorlage angegeben) an. | **Größe** unter **Speicher (Volumes)** (**Hinzufügen eines neuen Volumes**) enthalten. Sie müssen dies in der Startvorlage angeben. |
| **SSH key pair** (SSH-Schlüsselpaar) unter **Node group configuration** (Knotengruppenkonfiguration) auf der Seite **Specify Networking** (Netzwerk angeben) – Die Konsole zeigt den in der Startvorlage angegebenen Schlüssel an oder **Not specified in launch template** (Nicht in der Startvorlage angegeben). | **Schlüsselpaarname** in **Schlüsselpaar (Login)**. |
| Bei Verwendung einer Startvorlage können Sie keine Quell-Sicherheitsgruppen angeben, für die der Fernzugriff zulässig ist. | **Sicherheitsgruppen** unter **Netzwerkeinstellungen** für die Instance oder **Sicherheitsgruppen** unter **Netzwerkschnittstellen** (**Netzwerkschnittstelle hinzufügen**), aber nicht beides. Weitere Informationen finden Sie unter [Benutzerdefinierte Sicherheitsgruppen](#launch-template-security-groups). |
**Anmerkung**
Wenn Sie eine Knotengruppe mithilfe einer Startvorlage bereitstellen, geben Sie in einer Startvorlage unter **Inhalt der Startvorlage** null oder einen **Instance-Typ** an. Alternativ können Sie 0 bis 20 Instance-Typen für **Instance-Typen** auf der Seite **Einstellen von Compute- und Skalierungskonfiguration** in der Konsole angeben. Oder Sie können dies mit anderen Tools tun, die die Amazon EKS API verwenden. Wenn Sie in einer Startvorlage einen Instance-Typ angeben und diese Startvorlage zum Bereitstellen Ihrer Knotengruppe verwenden, können Sie keine Instance-Typen in der Konsole oder mit anderen Tools angeben, welche die Amazon-EKS-API verwenden. Wenn Sie für eine Startvorlage, in der Konsole oder mit anderen Tools, welche die Amazon-EKS-API verwenden, keinen Instance-Typ angeben, wird der `t3.medium`-Instance-Typ verwendet. Wenn Ihre Knotengruppe den Spot-Kapazitätstyp verwendet, empfehlen wir, mehrere Instance-Typen über die Konsole anzugeben. Weitere Informationen finden Sie unter [Kapazitätstypen für verwaltete Knotengruppen](managed-node-groups.md#managed-node-group-capacity-types).
Wenn Container, die Sie für die Knotengruppe bereitstellen, den Instance-Metadaten-Service Version 2 verwenden, stellen Sie sicher, dass Sie die **Hop-Limits für Metadaten** auf `2` in Ihrer Startvorlage festsetzen. Weitere Informationen finden Sie unter [Instance-Metadaten und Benutzerdaten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) im *Amazon-EC2-Benutzerhandbuch*.
Startvorlagen unterstützen das `InstanceRequirements`-Feature zur flexiblen Auswahl des Instance-Typs nicht.
## Markieren von Amazon-EC2-Instances
Sie können das `TagSpecification`-Parameter einer Startvorlage verwenden, um anzugeben, welche Markierungen auf Amazon-EC2-Instances in Ihrer Knotengruppe angewendet werden sollen. Die IAM-Entität, die `CreateNodegroup` oder aufruft, `UpdateNodegroupVersion` APIs muss über Berechtigungen für `ec2:RunInstances` und verfügen`ec2:CreateTags`, und die Tags müssen der Startvorlage hinzugefügt werden.
## Benutzerdefinierte Sicherheitsgruppen
Sie können eine Startvorlage verwenden, um benutzerdefinierte Amazon-EC2-[Sicherheitsgruppen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) anzugeben die auf Instances in Ihrer Knotengruppe angewendet werden. Dies kann entweder im Parameter für Sicherheitsgruppen auf Instance-Ebene oder als Teil der Konfigurationsparameter der Netzwerkschnittstelle sein. Sie können eine Instance nicht über eine Startvorlage starten, die Sicherheitsgruppen und eine Netzwerkschnittstelle angibt. Beachten Sie die folgenden Bedingungen, die für die Verwendung benutzerdefinierter Sicherheitsgruppen mit verwalteten Knotengruppen gelten:
+ Bei Verwendung von erlaubt Amazon EKS nur Startvorlagen mit einer einzigen Netzwerkschnittstellenspezifikation. AWS-Managementkonsole
+ Standardmäßig wendet Amazon EKS die [Cluster-Sicherheitsgruppe](sec-group-reqs.md) zu den Instances in Ihrer Knotengruppe hinzu, um die Kommunikation zwischen Knoten und der Steuerungsebene zu erleichtern. Wenn Sie benutzerdefinierte Sicherheitsgruppen in der Startvorlage mit einer der oben genannten Optionen angeben, fügt Amazon EKS die Cluster-Sicherheitsgruppe nicht hinzu. Sie müssen daher sicherstellen, dass die eingehenden und ausgehenden Regeln Ihrer Sicherheitsgruppen die Kommunikation mit dem Endpunkt Ihres Clusters ermöglichen. Wenn Ihre Sicherheitsgruppenregeln falsch sind, können die Worker-Knoten dem Cluster nicht beitreten. Weitere Informationen zu Sicherheitsgruppenregeln finden Sie unter [Anforderungen der Amazon-EKS-Sicherheitsgruppe für Cluster anzeigen](sec-group-reqs.md).
+ Wenn Sie SSH-Zugriff auf die Instances in Ihrer Knotengruppe benötigen, müssen Sie eine Sicherheitsgruppe einschließen, die diesen Zugriff zulässt.
## Amazon-EC2-Benutzerdaten
Die Startvorlage enthält einen Abschnitt für benutzerdefinierte Benutzerdaten. In diesem Abschnitt können Sie die Konfigurationseinstellungen für Ihre Knotengruppe angeben, ohne manuell individuelle benutzerdefinierte Einstellungen erstellen zu müssen AMIs. Weitere Informationen zu den für Bottlerocket verfügbaren Einstellungen finden Sie unter [Benutzerdaten verwenden](https://github.com/bottlerocket-os/bottlerocket#using-user-data) am. GitHub
Sie können Amazon-EC2-Benutzerdaten in Ihrer Startvorlage mithilfe von`cloud-init`, wenn Sie Ihre Instances starten. Weitere Informationen dazu finden Sie in der [cloud-init-Dokumentation](https://cloudinit.readthedocs.io/en/latest/index.html). Ihre Benutzerdaten können verwendet werden, um allgemeine Konfigurationsvorgänge durchzuführen. Dieser Filter umfasst die folgenden Optionen:
+ [Einschließen von Benutzern oder Gruppen](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups)
+ [Installieren von Paketen](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages)
Amazon EC2 EC2-Benutzerdaten in Startvorlagen, die mit verwalteten Knotengruppen verwendet werden, müssen im [mehrteiligen MIME-Archivformat](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive) für Amazon Linux AMIs und im TOML-Format für Bottlerocket vorliegen. AMIs Dies liegt daran, dass Ihre Benutzerdaten mit Amazon-EKS-Benutzerdaten zusammengeführt werden, die für Knoten erforderlich sind, um dem Cluster beizutreten. Geben Sie keine Befehle in Ihren Benutzerdaten an, die `kubelet` starten oder ändern. Dies wird als Teil der von Amazon EKS zusammengeführten Benutzerdaten durchgeführt. Bestimmte `kubelet`-Parameter, z. B. das Festlegen von Beschriftungen auf Knoten, können direkt über die API für verwaltete Knotengruppen konfiguriert werden.
**Anmerkung**
Weitere Hinweise zur erweiterten `kubelet`-Anpassung, einschließlich des manuellen Startens oder Übergebens benutzerdefinierter Konfigurationsparameter, finden Sie unter [Angeben eines AMI](#launch-template-custom-ami). Wenn in einer Startvorlage eine benutzerdefinierte AMI-ID angegeben ist, führt Amazon EKS keine Benutzerdaten zusammen.
Die folgenden Details enthalten weitere Informationen zum Abschnitt Benutzerdaten.
**Benutzerdaten von Amazon Linux 2**
Sie können mehrere Benutzerdatenblöcke in einer einzelnen mehrteiligen MIME-Datei kombinieren. So können Sie beispielsweise einen Cloud-Boothook, der den Docker-Daemon konfiguriert, mit einem Benutzerdaten-Shell-Skript kombinieren, das ein benutzerdefiniertes Paket installiert. Eine mehrteilige MIME-Datei umfasst folgende Komponenten:
+ Deklaration von Inhaltstyp und Teilgrenze – `Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="`
+ Deklaration der MIME-Version – `MIME-Version: 1.0`
+ Ein oder mehrere Benutzerdatenblöcke mit folgenden Komponenten:
+ Eröffnungsgrenze, die den Beginn eines Benutzerdatenblocks signalisiert – `--==MYBOUNDARY==`
+ Die Inhaltstypdeklaration für den Block: `Content-Type: text/cloud-config; charset="us-ascii"`. Weitere Informationen zu Inhaltstypen finden Sie in der [Cloud-Init-Dokumentation](https://cloudinit.readthedocs.io/en/latest/topics/format.html).
+ Der Inhalt der Benutzerdaten (z. B. eine Liste von Shell-Befehlen oder `cloud-init`-Direktiven).
+ Abschlussgrenze, die das Ende der mehrteiligen MIME-Datei signalisiert: `--==MYBOUNDARY==--`
Im Folgenden finden Sie ein Beispiel für eine mehrteilige MIME-Datei, die Sie verwenden können, um Ihre eigene zu erstellen.
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
echo "Running custom user data script"
--==MYBOUNDARY==--
```
**Benutzerdaten von Amazon Linux 2023**
Amazon Linux 2023 (AL2023) führt einen neuen Knoteninitialisierungsprozess ein`nodeadm`, der ein YAML-Konfigurationsschema verwendet. Wenn Sie selbstverwaltete Knotengruppen oder eine AMI mit einer Startvorlage verwenden, müssen Sie nun beim Erstellen einer neuen Knotengruppe explizit zusätzliche Cluster-Metadaten angeben. Ein [Beispiel](https://awslabs.github.io/amazon-eks-ami/nodeadm/) für die mindestens erforderlichen Parameter ist wie folgt, wobei jetzt `apiServerEndpoint`, `certificateAuthority` und Service-`cidr` erforderlich sind:
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
```
Normalerweise legen Sie diese Konfiguration in Ihren Benutzerdaten fest, entweder unverändert oder eingebettet in ein MIME-Multipart-Dokument:
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig spec: [...]
--BOUNDARY--
```
AL2In wurden die Metadaten dieser Parameter aus dem Amazon `DescribeCluster` EKS-API-Aufruf ermittelt. Mit hat sich dieses Verhalten geändert AL2023, da durch den zusätzlichen API-Aufruf die Gefahr einer Drosselung bei der Skalierung großer Knoten besteht. Diese Änderung betrifft Sie nicht, wenn Sie verwaltete Knotengruppen ohne Startvorlage verwenden oder wenn Sie Karpenter verwenden. Weitere Informationen zu `certificateAuthority` und Service `cidr` finden Sie unter [https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) in der *API-Referenz von Amazon EKS*.
Hier ist ein vollständiges Beispiel für AL2023 Benutzerdaten, das ein Shell-Skript für die Anpassung des Nodes (wie die Installation von Paketen oder das Pre-Caching von Container-Images) mit der erforderlichen Konfiguration kombiniert. `nodeadm` Dieses Beispiel veranschaulicht gängige Anpassungen, darunter: \$1 Installation zusätzlicher Systempakete \$1 Vorab-Caching von Container-Images zur Verbesserung der Pod-Startup-Zeit \$1 Einrichtung der HTTP-Proxy-Konfiguration \$1 Konfiguration von `kubelet`-Flags für die Knotenbeschriftung
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
set -o errexit
set -o pipefail
set -o nounset
# Install additional packages
yum install -y htop jq iptables-services
# Pre-cache commonly used container images
nohup docker pull public.ecr.aws/eks-distro/kubernetes/pause:3.2 &
# Configure HTTP proxy if needed
cat > /etc/profile.d/http-proxy.sh << 'EOF'
export HTTP_PROXY="http://proxy.example.com:3128"
export HTTPS_PROXY="http://proxy.example.com:3128"
export NO_PROXY="localhost,127.0.0.1,169.254.169.254,.internal"
EOF
--BOUNDARY
Content-Type: application/node.eks.aws
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
kubelet:
config:
clusterDNS:
- 10.100.0.10
flags:
- --node-labels=app=my-app,environment=production
--BOUNDARY--
```
**Bottlerocket-Benutzerdaten**
Bottlerocket strukturiert Benutzerdaten im TOML-Format. Sie können Benutzerdaten angeben, die mit den von Amazon EKS bereitgestellten Benutzerdaten zusammengeführt werden sollen. Zum Beispiel können Sie zusätzliche `kubelet`-Einstellungen bereitstellen.
```
[settings.kubernetes.system-reserved]
cpu = "10m"
memory = "100Mi"
ephemeral-storage= "1Gi"
```
Weitere Informationen zu unterstützten Einstellungen finden Sie in der [Bottlerocket-Dokumentation](https://github.com/bottlerocket-os/bottlerocket). Sie können Knotenbezeichnungen und [Taints](node-taints-managed-node-groups.md) in Ihren Benutzerdaten konfigurieren. Es wird jedoch empfohlen, diese stattdessen in Ihrer Knotengruppe zu konfigurieren. Amazon EKS wendet diese Konfigurationen an, wenn Sie dies tun.
Wenn Benutzerdaten zusammengeführt werden, wird die Formatierung nicht beibehalten, der Inhalt bleibt jedoch unverändert. Die Konfiguration, die Sie in Ihren Benutzerdaten angeben, überschreibt alle Einstellungen, die von Amazon EKS konfiguriert wurden. Wenn Sie also `settings.kubernetes.max-pods` oder `settings.kubernetes.cluster-dns-ip` festlegen, werden diese Werte in Ihren Benutzerdaten auf die Knoten angewendet.
Amazon EKS unterstützt nicht alle gültigen TOML. Im Folgenden finden Sie eine Liste bekannter nicht unterstützter Formate:
+ Zitate in Anführungszeichen: `'quoted "value"' = "value"`
+ Anführungszeichen mit Escapezeichen in Werten: `str = "I’m a string. \"You can quote me\""`
+ Gemischte Gleitkommazahlen und ganze Zahlen: `numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]`
+ Gemischte Typen in Arrays: `contributors = ["[foo@example.com](mailto:foo@example.com)", { name = "Baz", email = "[baz@example.com](mailto:baz@example.com)" }]`
+ Kopfzeilen in Klammern mit Anführungszeichen: `[foo."bar.baz"]`
**Windows-Benutzerdaten**
Windows-Benutzerdaten verwenden Befehle. PowerShell Beim Erstellen einer verwalteten Knotengruppe werden Ihre benutzerdefinierten Benutzerdaten mit den von Amazon EKS verwalteten Benutzerdaten kombiniert. Ihre PowerShell Befehle stehen an erster Stelle, gefolgt von den Befehlen für verwaltete Benutzerdaten, alles innerhalb eines `` Tags.
Beim Erstellen von Windows-Knotengruppen aktualisiert Amazon EKS die `aws-auth` `ConfigMap`, damit Linux-basierte Knoten dem Cluster beitreten können. Der Dienst konfiguriert die Berechtigungen für Windows nicht automatisch AMIs. Wenn Sie Windows-Knoten verwenden, müssen Sie den Zugriff entweder über die Zugriffseintrag-API oder durch direkte Aktualisierung der `aws-auth` `ConfigMap` verwalten. Weitere Informationen finden Sie unter [Bereitstellung von Windows-Knoten in EKS-Clustern](windows-support.md).
Wenn in der Startvorlage keine AMI-ID angegeben ist, verwenden Sie nicht das Amazon-EKS-Bootstrap-Skript von Windows in den Benutzerdaten, um Amazon EKS zu konfigurieren.
Beispielbenutzerdaten lauten wie folgt.
```
Write-Host "Running custom user data script"
```
## Angeben eines AMI
Wenn Sie eine der folgenden Anforderungen haben, geben Sie eine AMI-ID in der `ImageId`-Startvorlage. Wählen Sie die Anforderung, die Sie für zusätzliche Informationen haben.
### Geben Sie Benutzerdaten an, um Argumente an die `bootstrap.sh` Datei zu übergeben, die in einem Amazon EKS-optimierten Linux/Bottlerocket AMI enthalten ist
Bootstrapping ist ein Begriff, der verwendet wird, um das Hinzufügen von Befehlen zu beschreiben, die beim Start einer Instance ausgeführt werden können. Bootstrapping ermöglicht beispielsweise die Verwendung zusätzlicher [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)-Argumente. Sie können Argumente mithilfe von `eksctl` an das `bootstrap.sh`-Skript übergeben, ohne eine Startvorlage anzugeben. Oder Sie können dies tun, indem Sie die Informationen im Abschnitt Benutzerdaten einer Startvorlage angeben.
**eksctl ohne Angabe einer Startvorlage**
Erstellen Sie eine Datei mit dem Namen *my-nodegroup.yaml* und dem folgenden Inhalt. Ersetzen Sie jede *example value* durch Ihre eigenen Werte. Die Argumente `--apiserver-endpoint`, `--b64-cluster-ca` und `--dns-cluster-ip` sind optional. Wenn sie definiert werden, verhindert dies jedoch, dass das `bootstrap.sh`-Skript einen `describeCluster`-Aufruf durchführt. Dies ist nützlich in privaten Cluster-Konfigurationen oder Clustern, in denen Sie häufig Knoten ab- und ausskalieren. Weitere Informationen zum `bootstrap.sh` Skript finden Sie in der Datei [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) unter GitHub.
+ Das einzige erforderliche Argument ist der Clustername (*my-cluster*).
+ Informationen zum Abrufen einer optimierten AMI-ID für `ami-1234567890abcdef0 ` finden Sie in den folgenden Abschnitten:
+ [Rufen Sie das empfohlene Amazon Linux AMI ab IDs](retrieve-ami-id.md)
+ [Empfohlenes Bottlerocket-AMI abrufen IDs](retrieve-ami-id-bottlerocket.md)
+ [Rufen Sie das empfohlene Microsoft Windows AMI ab IDs](retrieve-windows-ami-id.md)
+ Um die *certificate-authority* für Ihren Cluster zu überprüfen, führen Sie den folgenden Befehl aus.
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ Um den *api-server-endpoint* für Ihren Cluster zu überprüfen, führen Sie den folgenden Befehl aus.
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ Der Wert für`--dns-cluster-ip`ist Ihr Service CIDR mit`.10`am Ende. Um das *service-cidr* für Ihren Cluster zu überprüfen, führen Sie den folgenden Befehl aus. Wenn der zurückgegebene Wert beispielsweise `ipv4 10.100.0.0/16` ist, ist Ihr Wert *10.100.0.10*.
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ Dieses Beispiel umfasst ein `kubelet`-Argument, mit dem ein benutzerdefinierter `max-pods`-Wert anhand des `bootstrap.sh`-Skripts festgelegt wird, das im Amazon-EKS-optimierten AMI enthalten ist. 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. Hilfe zur Auswahl von *my-max-pods-value* finden Sie unter . Weitere Informationen darüber, wie festgelegt `maxPods` wird, wenn verwaltete Knotengruppen verwendet werden, finden Sie unter[Wie wird MaxPods bestimmt](choosing-instance-type.md#max-pods-precedence).
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: region-code
managedNodeGroups:
- name: my-nodegroup
ami: ami-1234567890abcdef0
instanceType: m5.large
privateNetworking: true
disableIMDSv1: true
labels: { x86-al2-specified-mng }
overrideBootstrapCommand: |
#!/bin/bash
/etc/eks/bootstrap.sh my-cluster \
--b64-cluster-ca certificate-authority \
--apiserver-endpoint api-server-endpoint \
--dns-cluster-ip service-cidr.10 \
--kubelet-extra-args '--max-pods=my-max-pods-value' \
--use-max-pods false
```
Informationen zu allen verfügbaren `eksctl`-`config`-Dateioptionen finden Sie im [Config file schema](https://eksctl.io/usage/schema/) (Config-Datei-Schema) in der `eksctl`-Dokumentation. Das `eksctl`-Dienstprogramm erstellt eine Startvorlage für Sie und füllt die Benutzerdaten mit den Daten aus, die Sie in der `config`-Datei angeben.
Erstellen Sie eine Knoten-Gruppe mit dem folgenden Befehl.
```
eksctl create nodegroup --config-file=my-nodegroup.yaml
```
**Benutzerdaten in einer Startvorlage**
Geben Sie die folgenden Informationen im Abschnitt Benutzerdaten Ihrer Startvorlage an. Ersetzen Sie jede *example value* durch Ihre eigenen Werte. Die Argumente `--apiserver-endpoint`, `--b64-cluster-ca` und `--dns-cluster-ip` sind optional. Wenn sie definiert werden, verhindert dies jedoch, dass das `bootstrap.sh`-Skript einen `describeCluster`-Aufruf durchführt. Dies ist nützlich in privaten Cluster-Konfigurationen oder Clustern, in denen Sie häufig Knoten ab- und ausskalieren. Weitere Informationen zum `bootstrap.sh` Skript finden Sie in der Datei [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) unter GitHub.
+ Das einzige erforderliche Argument ist der Clustername (*my-cluster*).
+ Um die *certificate-authority* für Ihren Cluster zu überprüfen, führen Sie den folgenden Befehl aus.
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ Um den *api-server-endpoint* für Ihren Cluster zu überprüfen, führen Sie den folgenden Befehl aus.
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ Der Wert für`--dns-cluster-ip`ist Ihr Service CIDR mit`.10`am Ende. Um das *service-cidr* für Ihren Cluster zu überprüfen, führen Sie den folgenden Befehl aus. Wenn der zurückgegebene Wert beispielsweise `ipv4 10.100.0.0/16` ist, ist Ihr Wert *10.100.0.10*.
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ Dieses Beispiel umfasst ein `kubelet`-Argument, mit dem ein benutzerdefinierter `max-pods`-Wert anhand des `bootstrap.sh`-Skripts festgelegt wird, das im Amazon-EKS-optimierten AMI enthalten ist. Hilfe zur Auswahl von *my-max-pods-value* finden Sie unter . Weitere Informationen darüber, wie festgelegt `maxPods` wird, wenn verwaltete Knotengruppen verwendet werden, finden Sie unter[Wie wird MaxPods bestimmt](choosing-instance-type.md#max-pods-precedence).
```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
set -ex
/etc/eks/bootstrap.sh my-cluster \
--b64-cluster-ca certificate-authority \
--apiserver-endpoint api-server-endpoint \
--dns-cluster-ip service-cidr.10 \
--kubelet-extra-args '--max-pods=my-max-pods-value' \
--use-max-pods false
--==MYBOUNDARY==--
```
### Stellen Sie Benutzerdaten bereit, um Argumente an die `Start-EKSBootstrap.ps1`-Datei zu übergeben, die in einer für Amazon EKS optimierten Windows-AMI enthalten ist.
Bootstrapping ist ein Begriff, der verwendet wird, um das Hinzufügen von Befehlen zu beschreiben, die beim Start einer Instance ausgeführt werden können. Sie können Argumente mithilfe von `eksctl` an das `Start-EKSBootstrap.ps1`-Skript übergeben, ohne eine Startvorlage anzugeben. Oder Sie können dies tun, indem Sie die Informationen im Abschnitt Benutzerdaten einer Startvorlage angeben.
Beachten Sie beim Angeben einer benutzerdefinierten Windows-AMI-ID die folgenden Überlegungen:
+ Sie müssen eine Startvorlage verwenden und die erforderlichen Bootstrap-Befehle im Abschnitt Benutzerdaten angeben. Um Ihre gewünschte Windows-ID abzurufen, können Sie die Tabelle unter [Knoten mit optimiertem Windows erstellen](eks-optimized-windows-ami.md) verwenden AMIs.
+ Es gibt verschiedene Grenzwerte und Bedingungen. Sie müssen beispielsweise `eks:kube-proxy-windows` zu Ihrer AWS IAM Authenticator-Konfigurationsübersicht etwas hinzufügen. Weitere Informationen finden Sie unter [Grenzen und Bedingungen bei der Angabe einer AMI-ID](#mng-ami-id-conditions).
Geben Sie die folgenden Informationen im Abschnitt Benutzerdaten Ihrer Startvorlage an. Ersetzen Sie jede *example value* durch Ihre eigenen Werte. Die Argumente `-APIServerEndpoint`, `-Base64ClusterCA` und `-DNSClusterIP` sind optional. Wenn sie definiert werden, verhindert dies jedoch, dass das `Start-EKSBootstrap.ps1`-Skript einen `describeCluster`-Aufruf durchführt.
+ Das einzige erforderliche Argument ist der Clustername (*my-cluster*).
+ Um die *certificate-authority* für Ihren Cluster zu überprüfen, führen Sie den folgenden Befehl aus.
```
aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
```
+ Um den *api-server-endpoint* für Ihren Cluster zu überprüfen, führen Sie den folgenden Befehl aus.
```
aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
```
+ Der Wert für`--dns-cluster-ip`ist Ihr Service CIDR mit`.10`am Ende. Um das *service-cidr* für Ihren Cluster zu überprüfen, führen Sie den folgenden Befehl aus. Wenn der zurückgegebene Wert beispielsweise `ipv4 10.100.0.0/16` ist, ist Ihr Wert *10.100.0.10*.
```
aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
```
+ Weitere Argumente finden Sie unter [Bootstrap-Skript-Konfigurationsparameter](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
**Anmerkung**
Wenn Sie CIDR für den benutzerdefinierten Service verwenden, müssen Sie diesen mithilfe des `-ServiceCIDR`-Parameters angeben. Andernfalls schlägt die DNS-Auflösung für Pods im Cluster fehl.
```
[string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1"
& $EKSBootstrapScriptFile -EKSClusterName my-cluster `
-Base64ClusterCA certificate-authority `
-APIServerEndpoint api-server-endpoint `
-DNSClusterIP service-cidr.10
```
### Führen Sie ein benutzerdefiniertes AMI aufgrund bestimmter Sicherheits-, Compliance- oder interner Richtlinienanforderungen aus
Weitere Informationen dazu finden Sie unter [Amazon Machine Images (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) im *Benutzerhandbuch für Amazon EC2*. Die Amazon-EKS-AMI-Entwicklungsspezifikation enthält Ressourcen und Konfigurationsskripte für die Erstellung eines benutzerdefinierten Amazon EKS AMI basierend auf Amazon Linux. Weitere Informationen finden Sie unter [Amazon-EKS-AMI-Build-Spezifikation](https://github.com/awslabs/amazon-eks-ami/) auf GitHub. Informationen zum Erstellen benutzerdefinierter AMIs Installationen mit anderen Betriebssystemen finden Sie unter [Amazon EKS Sample Custom AMIs](https://github.com/aws-samples/amazon-eks-custom-amis) unter GitHub.
Sie können keine dynamischen Parameterreferenzen für AMI IDs in Startvorlagen verwenden, die mit verwalteten Knotengruppen verwendet werden.
**Wichtig**
Wenn Sie ein AMI angeben, validiert Amazon EKS die in Ihr AMI eingebettete Kubernetes-Version nicht mit der Version der Kontrollebene Ihres Clusters. Sie sind dafür verantwortlich, sicherzustellen, dass die Kubernetes-Version Ihres benutzerdefinierten AMI der [Kubernetes-Richtlinie für Versionsverzerrungen](https://kubernetes.io/releases/version-skew-policy) entspricht:
Die `kubelet` Version auf Ihren Knoten darf nicht neuer als Ihre Cluster-Version sein
Die `kubelet` Version auf Ihren Knoten muss mindestens 3 Nebenversionen hinter Ihrer Cluster-Version (für Kubernetes-Version `1.28` oder höher) oder bis zu 2 Nebenversionen hinter Ihrer Cluster-Version (für Kubernetes-Version oder niedriger) sein `1.27`
Das Erstellen von verwalteten Knotengruppen mit Verstößen gegen den Versionsunterschied kann zu folgenden Ergebnissen führen:
Knoten können dem Cluster nicht beitreten
Undefiniertes Verhalten oder API-Inkompatibilitäten
Cluster-Instabilität oder Workload-Ausfälle
Bei der Angabe eines AMI führt Amazon EKS keine Benutzerdaten zusammen. Vielmehr sind Sie verantwortlich für die Bereitstellung der erforderlichen `bootstrap`-Befehle für Knoten, um dem Cluster beizutreten. Wenn Ihre Knoten dem Cluster nicht beitreten können, wird Amazon EKS `CreateNodegroup` und `UpdateNodegroupVersion`-Aktionen ebenfalls fehlschlagen.
## Grenzen und Bedingungen bei der Angabe einer AMI-ID
Im Folgenden sind die Grenzen und Bedingungen aufgeführt, die mit der Angabe einer AMI-ID mit verwalteten Knotengruppen verbunden sind:
+ Sie müssen eine neue Knotengruppe erstellen, um zwischen der Angabe einer AMI-ID in einer Startvorlage und der Nicht-Angabe einer AMI-ID zu wechseln.
+ Sie werden in der Konsole nicht benachrichtigt, wenn eine neuere AMI-Version verfügbar ist. Um Ihre Knotengruppe auf eine neuere AMI-Version zu aktualisieren, müssen Sie eine neue Version Ihrer Startvorlage mit einer aktualisierten AMI-ID erstellen. Dann müssen Sie die Knotengruppe mit der neuen Version der Startvorlage aktualisieren.
+ Die folgenden Felder können in der API nicht festgelegt werden, wenn Sie eine AMI-ID angeben:
+ `amiType`
+ `releaseVersion`
+ `version`
+ Alle in der API festgelegten `taints` werden asynchron angewendet, wenn Sie eine AMI-ID angeben. Um Taints anzuwenden, bevor ein Knoten mit dem Cluster verbunden wird, müssen Sie die Taints über das Befehlszeilen-Flag `--register-with-taints` an `kubelet` in Ihren Benutzerdaten weitergeben. Weitere Informationen finden Sie unter [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) in der Kubernetes-Dokumentation.
+ Wenn Sie eine benutzerdefinierte AMI-ID für von Windows verwaltete Knotengruppen angeben, fügen Sie `eks:kube-proxy-windows` diese Ihrer AWS IAM Authenticator-Konfigurationsübersicht hinzu. Dies ist erforderlich, damit DNS ordnungsgemäß funktioniert.
1. Öffnen Sie die AWS IAM Authenticator-Konfigurationsübersicht zur Bearbeitung.
```
kubectl edit -n kube-system cm aws-auth
```
1. Fügen Sie diesen Eintrag zur `groups`-Liste unter jedem `rolearn` hinzu, das Windows-Knoten zugeordnet ist. [Ihre Konfigurationsübersicht sollte ähnlich wie .yaml aussehen. aws-auth-cm-windows](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml)
```
- eks:kube-proxy-windows
```
1. Speichern Sie die Datei und beenden Sie den Text-Editor.
+ Für jedes AMI, das eine benutzerdefinierte Startvorlage verwendet, ist das Standard-`HttpPutResponseHopLimit` für verwaltete Knotengruppen auf `2` festgelegt.
# Verwaltete Knotengruppe aus Ihrem Cluster löschen
In diesem Thema wird beschrieben, wie Sie eine verwaltete Amazon-EKS-Knotengruppe löschen. Wenn Sie eine verwaltete Knotengruppe löschen, legt Amazon EKS zunächst die minimale, maximale und gewünschte Größe Ihrer Auto-Scaling-Gruppe auf Null fest. Dies bewirkt dann, dass Ihre Knotengruppe abskaliert wird.
Bevor jede Instance beendet wird, sendet Amazon EKS ein Signal, um diesen Knoten zu entleeren. Während des Drainprozesses führt Kubernetes für jeden Pod auf dem Knoten Folgendes aus: führt alle konfigurierten `preStop` Lifecycle-Hooks aus, sendet `SIGTERM` Signale an die Container und wartet dann auf das ordnungsgemäße Herunterfahren`terminationGracePeriodSeconds`. Wenn der Knoten nach 5 Minuten nicht entleert wurde, lässt Amazon EKS Auto Scaling die erzwungene Beendigung der Instance fortsetzen. Nachdem alle Instanzen beendet wurden, wird die Auto Scaling Scaling-Gruppe gelöscht.
**Wichtig**
Wenn Sie eine verwaltete Knotengruppe löschen, die eine Knoten-IAM-Rolle verwendet, die von keiner anderen verwalteten Knotengruppe im Cluster genutzt wird, wird die Rolle aus `aws-auth` `ConfigMap` entfernt. Wenn eine der selbstverwalteten Knotengruppen im Cluster dieselbe Knoten-IAM-Rolle verwendet, werden die selbstverwalteten Knoten in den `NotReady`-Status verschoben. Außerdem wird auch der Cluster-Betrieb unterbrochen. Informationen zum Hinzufügen einer Zuordnung für die Rolle, die Sie ausschließlich für selbstverwaltete Knotengruppen verwenden, finden Sie unter [Zugriffseinträge erstellen](creating-access-entries.md). Voraussetzung ist, dass die Plattformversion Ihres Clusters mindestens der im Abschnitt „Voraussetzungen“ unter [IAM-Benutzern Zugriff auf Kubernetes mit EKS-Zugriffseinträgen gewähren](access-entries.md) angegebenen Mindestversion entspricht. Wenn Ihre Plattformversion älter ist als die erforderliche Mindestversion für Zugriffseinträge, können Sie den Eintrag wieder in `aws-auth` `ConfigMap` hinzufügen. Weitere Informationen erhalten Sie durch Eingabe von `eksctl create iamidentitymapping --help` im Terminal.
Sie können eine verwaltete Knotengruppe wie folgt löschen:
+ [`eksctl`](#eksctl-delete-managed-nodegroup)
+ [AWS-Managementkonsole](#console-delete-managed-nodegroup)
+ [AWS CLI](#awscli-delete-managed-nodegroup)
## `eksctl`
**Eine verwaltete Knotengruppe mit `eksctl` löschen **
Geben Sie den folgenden Befehl ein. Ersetzen Sie jede `` durch Ihre eigenen Werte.
```
eksctl delete nodegroup \
--cluster \
--name \
--region
```
Weitere Optionen finden Sie unter [Löschen und Löschen von Knotengruppen](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups) in der `eksctl`-Dokumentation.
## AWS-Managementkonsole
**Eine verwaltete Knotengruppe mit AWS-Managementkonsole löschen **
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie auf der Seite **Clusters** den Cluster aus, der die zu löschende Knotengruppe enthält.
1. Wählen Sie auf der ausgewählten Cluster-Seite die Registerkarte **Datenverarbeitung** aus.
1. Wählen Sie im Abschnitt **Node groups** (Knotengruppen) die zu löschende Knotengruppe aus. Wählen Sie dann **Löschen** aus.
1. Geben Sie im Bestätigungsdialogfeld **Knotengruppe löschen** den Namen der Knotengruppe ein. Wählen Sie dann **Löschen** aus.
## AWS CLI
**Löschen Sie eine verwaltete Knotengruppe mit AWS CLI**
1. Geben Sie den folgenden Befehl ein. Ersetzen Sie jede `` durch Ihre eigenen Werte.
```
aws eks delete-nodegroup \
--cluster-name \
--nodegroup-name \
--region
```
1. Wenn `cli_pager=` es in der CLI-Konfiguration festgelegt ist, verwenden Sie die Pfeiltasten auf Ihrer Tastatur, um durch die Antwortausgabe zu blättern. Drücken Sie die `q`-Taste, wenn Sie fertig sind.
Weitere Optionen finden Sie unter dem ` [delete-nodegroup](https://docs.aws.amazon.com/cli/latest/reference/eks/delete-nodegroup.html) ` Befehl in der * AWS CLI-Befehlsreferenz*.