**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. # Verwaltung von Datenverarbeitungsressourcen mithilfe von Knoten Ein Kubernetes-Knoten ist ein Rechner, auf dem containerisierte Anwendungen ausgeführt werden. Jeder Knoten umfasst die folgenden Komponenten: + ** [Container-Laufzeit](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) ** – Software, die für den Betrieb der Container verantwortlich ist. + ** [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) ** – Stellt sicher, dass die Container fehlerfrei sind und innerhalb ihres zugeordneten Pods ausgeführt werden. + ** [kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/) ** – Behält die Netzwerkregeln bei, die die Kommunikation mit Ihren Pods ermöglichen. Weitere Informationen finden Sie unter [Nodes](https://kubernetes.io/docs/concepts/architecture/nodes/) in der Kubernetes-Dokumentation. Ihr Amazon-EKS-Cluster kann Pods auf einer beliebigen Kombination aus im [EKS Auto Mode verwalteten Knoten](automode.md), [selbstverwalteten Knoten](worker.md), [von Amazon EKS verwalteten Knotengruppen](managed-node-groups.md), [AWS Fargate](fargate.md) und [Amazon EKS Hybrid Nodes](hybrid-nodes-overview.md) planen. Weitere Informationen zu Knoten, die in Ihrem Cluster bereitgestellt werden, finden Sie unter [Kubernetes-Ressourcen anzeigen in der AWS-Managementkonsole](view-kubernetes-resources.md). **Anmerkung** Mit Ausnahme von Hybridknoten müssen sich die Knoten in derselben VPC befinden wie die Subnetze, die Sie beim Erstellen des Clusters ausgewählt haben. Die Knoten müssen sich jedoch nicht in denselben Subnetzen befinden. ## Vergleich von Rechenoptionen Die folgende Tabelle enthält mehrere Kriterien, die bei der Entscheidung ausgewertet werden müssen, welche Optionen Ihren Anforderungen am besten entsprechen. Selbstverwaltete Knoten sind eine weitere Option, die alle aufgeführten Kriterien erfüllen, jedoch erfordern sie einen deutlich höheren manuellen Wartungsaufwand. Weitere Informationen finden Sie unter [Knoten selbst mit selbstverwalteten Knoten verwalten](worker.md). **Anmerkung** Bottlerocket weist einige spezifische Unterschiede zu den allgemeinen Informationen in dieser Tabelle auf. Weitere Informationen finden Sie in der Bottlerocket-[Dokumentation](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md) auf GitHub. | Kriterien | EKS-verwaltete Knotengruppen | EKS Auto Mode | Amazon EKS Hybrid Nodes | | --- | --- | --- | --- | | Kann in [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) bereitgestellt werden | Nein | Nein | Nein | | Kann auf eine [AWS Lokale Zone](local-zones.md) bereitgestellt werden | Ja | Nein | Nein | | Kann Container ausführen, die Windows benötigen | Ja | Nein | Nein | | Kann Container ausführen, die Linux benötigen | Ja | Ja | Ja | | Kann Workloads ausführen, die den Inferentia-Chip benötigen | [Ja](inferentia-support.md) – nur Amazon-Linux-Knoten | Ja | Nein | | Kann Workloads ausführen, die eine GPU benötigen | [Ja](eks-optimized-ami.md#gpu-ami) – nur Amazon-Linux-Knoten | Ja | Ja | | Kann Workloads ausführen, die Arm-Prozessoren benötigen | [Ja](eks-optimized-ami.md#arm-ami) | Ja | Ja | | Kann ausgeführt werdenAWS [Bottlerocket](https://aws.amazon.com/bottlerocket/) | Ja | Ja | Nein | | Pods teilen CPU, Arbeitsspeicher, Speicher und Netzwerkressourcen mit anderen Pods. | Ja | Ja | Ja | | Bereitstellen und Verwalten von Amazon-EC2-Instances | Ja | Nein – Erfahren Sie mehr über [verwaltete EC2-Instances](automode-learn-instances.md) | Ja – die physischen oder virtuellen Maschinen On-Premises werden von Ihnen mit den Tools Ihrer Wahl verwaltet. | | Das Betriebssystem von Amazon-EC2-Instances muss gesichert, gewartet und gepatcht werden | Ja | Nein | Ja – das auf Ihren physischen oder virtuellen Maschinen ausgeführte Betriebssystem wird von Ihnen mit den Tools Ihrer Wahl verwaltet. | | Kann Bootstrap-Argumente bei der Bereitstellung eines Knotens bereitstellen, z. B. zusätzliche [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)-Argumente. | Ja – mithilfe von `eksctl` oder einer [Startvorlage](launch-templates.md) mit einem benutzerdefinierten AMI. | Nein – [Verwenden Sie zur Konfiguration der Knoten eine `NodeClass`](create-node-class.md) | Ja – Sie können Bootstrap-Argumente mit nodeadm anpassen. Siehe [`nodeadm`-Referenz für Hybridknoten](hybrid-nodes-nodeadm.md). | | IP-Adressen können Pods aus einem anderen CIDR-Block als der dem Knoten zugewiesenen IP-Adresse zuweisen. | Ja – Verwenden einer Startvorlage mit einem benutzerdefinierten AMI. Weitere Informationen finden Sie unter [Verwaltete Knoten mit Startvorlagen anpassen](launch-templates.md). | Nein | Ja – siehe [CNI für Hybridknoten konfigurieren](hybrid-nodes-cni.md). | | SSH im Knoten nicht möglich | Ja | Nein – [Erfahren Sie, wie Sie Fehler an Knoten beheben](auto-troubleshoot.md) | Ja | | Kann Ihr eigenes benutzerdefiniertes AMI auf Knoten bereitstellen | Ja – Verwenden eines [Startvorlage](launch-templates.md) | Nein | Ja | | Kann Ihr eigenes benutzerdefiniertes CNI auf Knoten bereitstellen | Ja – Verwenden eines [Startvorlage](launch-templates.md) mit einem benutzerdefinierten AMI | Nein | Ja | | Knoten-AMI muss selbst aktualisiert werden | [Ja](update-managed-node-group.md) – Wenn Sie ein für Amazon-EKS-optimiertes AMI bereitgestellt haben, werden Sie in der Amazon-EKS-Konsole benachrichtigt, wenn Aktualisierungen verfügbar sind. Sie können die Aktualisierung mit einem Klick in der Konsole durchführen. Wenn Sie ein benutzerdefiniertes AMI bereitgestellt haben, werden Sie in der Amazon-EKS-Konsole nicht benachrichtigt, wenn Aktualisierungen verfügbar sind. Sie müssen die Aktualisierung selbst durchführen. | Nein | Ja – das auf Ihren physischen oder virtuellen Maschinen ausgeführte Betriebssystem wird von Ihnen mit den Tools Ihrer Wahl verwaltet. Siehe [Vorbereitung des Betriebssystems für Hybridknoten](hybrid-nodes-os.md). | | Muss die Kubernetes-Version des Knotens selbst aktualisieren | [Ja](update-managed-node-group.md) – Wenn Sie ein für Amazon-EKS-optimiertes AMI bereitgestellt haben, werden Sie in der Amazon-EKS-Konsole benachrichtigt, wenn Aktualisierungen verfügbar sind. Sie können die Aktualisierung mit einem Klick in der Konsole durchführen. Wenn Sie ein benutzerdefiniertes AMI bereitgestellt haben, werden Sie in der Amazon-EKS-Konsole nicht benachrichtigt, wenn Aktualisierungen verfügbar sind. Sie müssen die Aktualisierung selbst durchführen. | Nein | Ja – Sie verwalten Upgrades von Hybridknoten mit den Tools Ihrer Wahl oder mit `nodeadm`. Siehe [Aktualisierung von Hybridknoten für Ihren Cluster](hybrid-nodes-upgrade.md). | | Kann Amazon-EBS-Speicher mit Pods verwenden | [Ja](ebs-csi.md) | Ja, als integrierte Funktion. Erfahren Sie, wie Sie [eine Speicherklasse erstellen.](create-storage-class.md) | Nein | | Kann Amazon-EFS-Speicher mit Pods verwenden | [Ja](efs-csi.md) | Ja | Nein | | Kann Amazon FSx für Lustre Speicher mit Pods verwenden | [Ja](fsx-csi.md) | Ja | Nein | | Kann Network Load Balancer für Services verwenden | [Ja](network-load-balancing.md) | Ja | Ja – Zieltyp `ip` muss verwendet werden. | | Pods können in einem öffentlichen Subnetz ausgeführt werden | Ja | Ja | Nein – Pods werden in einer On-Premises-Umgebung ausgeführt. | | Kann einzelnen Pods verschiedene VPC-Sicherheitsgruppen zuweisen | [Ja](security-groups-for-pods.md) – Nur Linux-Knoten | Nein | Nein | | Kann Kubernetes DaemonSets ausführen | Ja | Ja | Ja | | Unterstützung für `HostPort` und `HostNetwork` im Pod-Manifest | Ja | Ja | Ja | | AWS-Verfügbarkeit in Regionen | [Alle von Amazon EKS unterstützten Regionen](https://docs.aws.amazon.com/general/latest/gr/eks.html) | [Alle von Amazon EKS unterstützten Regionen](https://docs.aws.amazon.com/general/latest/gr/eks.html) | [Alle von Amazon EKS unterstützten Regionen](https://docs.aws.amazon.com/general/latest/gr/eks.html) mit Ausnahme der AWS GovCloud (US)-Regionen und der China-Regionen. | | Kann Container auf Amazon-EC2-Dedicated-Hosts ausführen | Ja | Nein | Nein | | Preise | Kosten einer Amazon-EC2-Instance, die mehrere Pods ausführt. Weitere Informationen dazu finden Sie unter [Amazon EC2 – Preise](https://aws.amazon.com/ec2/pricing/). | Wenn EKS Auto Mode in Ihrem Cluster aktiviert ist, zahlen Sie zusätzlich zu den Standardgebühren für EC2-Instances eine separate Gebühr für die Instances, die mit der Rechenleistung des Automatikmodus gestartet werden. Der Betrag hängt vom gestarteten Instance-Typ und der AWS-Region ab, in der sich Ihr Cluster befindet. Weitere Informationen finden Sie unter [Amazon EKS – Preise](https://aws.amazon.com/eks/pricing/). | Kosten für Hybridknoten-vCPU pro Stunde. Weitere Informationen finden Sie unter [Amazon EKS – Preise](https://aws.amazon.com/eks/pricing/). | # 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*. # Knoten selbst mit selbstverwalteten Knoten verwalten Ein Cluster enthält einen oder mehrere Amazon-EC2-Knoten, auf denen Pods geplant sind. Amazon-EKS-Knoten werden in Ihrem AWS-Konto ausgeführt und stellen eine Verbindung zur Steuerebene Ihres Clusters über den Cluster-API-Server-Endpunkt her. Sie werden basierend auf Amazon-EC2-Preisen in Rechnung gestellt. Weitere Informationen dazu finden Sie unter [Amazon EC2 – Preise](https://aws.amazon.com/ec2/pricing/). Ein Cluster kann mehrere Knotengruppen enthalten. Jede Knotengruppe enthält eine oder mehrere Knoten, die in einer [Gruppe von Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html) bereitgestellt werden. Der Instance-Typ der Knoten innerhalb der Gruppe kann variieren, z. B. wenn die [attributbasierte Instance-Typauswahl](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) mit [Karpenter](https://karpenter.sh/) verwendet wird. Alle Instances in einer Knotengruppe müssen die [Amazon-EKS-Knoten-IAM-Rolle](create-node-role.md) verwenden. Amazon EKS bietet spezialisierte Amazon Machine Images (AMIs), die als für Amazon EKS optimierte AMIs bezeichnet werden. Die AMIs sind so konfiguriert, dass sie mit Amazon EKS funktionieren. Zu ihren Komponenten gehören `containerd`, `kubelet`, und der AWS-IAM-Authenticator. Das AMI enthält auch ein spezialisiertes [Bootstrap-Skript](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh), mit dem Sie die Steuerebene Ihres Clusters automatisch erkennen und eine Verbindung damit herstellen können. Wenn Sie den Zugriff auf den öffentlichen Endpunkt Ihres Clusters mithilfe von CIDR-Blöcken einschränken, empfehlen wir, dass Sie auch den privaten Endpunktzugriff aktivieren. Auf diese Weise können Knoten mit dem Cluster kommunizieren. Wenn der private Endpunkt nicht aktiviert ist, müssen die CIDR-Blöcke, die Sie für den öffentlichen Zugriff angeben, die Ausgangsquellen aus Ihrer VPC enthalten. Weitere Informationen finden Sie unter [Cluster-API-Server-Endpunkt](cluster-endpoint.md). Informationen zum Hinzufügen selbstverwalteter Knoten zu Ihrem Amazon-EKS-Cluster finden Sie in den folgenden Themen. Wenn Sie selbstverwaltete Knoten manuell starten, fügen Sie jedem Knoten das folgende Tag hinzu und stellen Sie sicher, dass `` ​​mit Ihrem Cluster übereinstimmt. Weitere Informationen dazu finden Sie unter [Hinzufügen und Löschen von Markierungen für einzelne Ressourcen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). Wenn Sie die Schritte in der Anleitung ausführen, wird die erforderliche Markierung für Sie zum Knoten hinzugefügt. | Schlüssel | Value (Wert) | | --- | --- | | `kubernetes.io/cluster/` | `owned` | **Wichtig** Tags im Amazon EC2 Instance Metadata Service (IMDS) sind nicht mit EKS-Knoten kompatibel. Wenn Instance Metadata Tags aktiviert sind, wird die Verwendung von Schrägstrichen („/“) in Tag-Werten verhindert. Diese Einschränkung kann zu Fehlern beim Starten von Instances führen, insbesondere bei der Verwendung von Knotenmanagement-Tools wie Karpenter oder Cluster Autoscaler, da diese Services für ihre ordnungsgemäße Funktion auf Tags mit Schrägstrichen angewiesen sind. Weitere Informationen zu Worker-Knoten aus einer allgemeinen Kubernetes-Perspektive finden Sie unter [Nodes](https://kubernetes.io/docs/concepts/architecture/nodes/) in der Kubernetes-Dokumentation. **Topics** + [ # Selbstverwaltete Amazon-Linux-Knoten erstellen ](launch-workers.md) + [ # Selbstverwaltete Bottlerocket-Knoten erstellen ](launch-node-bottlerocket.md) + [ # Selbstverwaltete Microsoft-Windows-Knoten erstellen ](launch-windows-workers.md) + [ # Selbstverwaltete Ubuntu Linux-Knoten erstellen ](launch-node-ubuntu.md) + [ # Selbstverwaltete Knoten für Ihren Cluster aktualisieren ](update-workers.md) # Selbstverwaltete Amazon-Linux-Knoten erstellen Dieses Thema beschreibt Hinweise zum Starten von Auto-Scaling-Gruppen von Linux-Knoten, die mit Ihrem Amazon-EKS-Cluster registriert sind. Nachdem die Knoten dem Cluster beigetreten sind, können Sie Kubernetes-Anwendungen darin bereitstellen. Sie können auch selbstverwaltete Amazon Linux-Knoten mit `eksctl` oder dem AWS-Managementkonsole starten. Informationen dazu, wie Sie Knoten auf AWS Outposts starten müssen, finden Sie unter[Amazon Linux-Knoten auf AWS Outposts erstellen](eks-outposts-self-managed-nodes.md). + Ein vorhandener Amazon-EKS-Cluster. Informationen zum Bereitstellen finden Sie unter [Amazon-EKS-Cluster erstellen](create-cluster.md). Wenn Sie Subnetze in der AWS Region haben, in der Sie AWS Outposts, AWS Wavelength oder AWS Local Zones aktiviert haben, dürfen diese Subnetze bei der Erstellung Ihres Clusters nicht weitergegeben worden sein. + Eine vorhandene IAM-Rolle, die von den Knoten verwendet werden soll. Informationen zum Erstellen finden Sie unter [Amazon-EKS-Knoten-IAM-Rolle](create-node-role.md). Wenn diese Rolle keine der beiden Richtlinien für die VPC CNI enthält, ist die folgende separate Rolle für die VPC-CNI-Pods erforderlich. + (Optional, aber empfohlen) Das Amazon-VPC-CNI-Plugin für Kubernetes-Add-On, konfiguriert mit einer eigenen IAM-Rolle, der die erforderliche IAM-Richtlinie zugeordnet ist. Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md). + Vertrautheit mit den unter [Wählen Sie einen optimalen EC2 Amazon-Node-Instance-Typ](choosing-instance-type.md) aufgeführten Überlegungen. Je nachdem, welchen Instance-Typ Sie wählen, kann es zusätzliche Voraussetzungen für Ihren Cluster und Ihre VPC geben. Sie können selbstverwaltete Linux-Knoten mit einer der folgenden Optionen starten: + [`eksctl`](#eksctl_create_managed_amazon_linux) + [AWS-Managementkonsole](#console_create_managed_amazon_linux) ## `eksctl` **Selbstverwaltete Linux-Knoten mithilfe der `eksctl` starten ** 1. Installieren Sie Version `0.215.0` oder höher des auf Ihrem Gerät installierten `eksctl` Befehlszeilentools oder AWS CloudShell. Informationen zum Installieren und Aktualisieren von `eksctl` finden Sie in der Dokumentation zu `eksctl` unter [Installation](https://eksctl.io/installation). 1. (Optional) Wenn die verwaltete IAM-Richtlinie **AmazonEKS\$1CNI\$1Policy** Ihrer [IAM-Rolle des Amazon-EKS-Knoten](create-node-role.md) zugeordnet ist, empfehlen wir, sie stattdessen einer IAM-Rolle zuzuweisen, die Sie dem Kubernetes-Servicekonto `aws-node` zuordnen. Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md). 1. Der folgende Befehl erstellt eine Knotengruppe in einem bestehenden Cluster. Ersetzen Sie *al-nodes* durch einen Namen für Ihre Knotengruppe. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten. Ersetzen Sie *my-cluster* mit dem Namen Ihres Clusters. Der Name darf nur alphanumerische Zeichen (wobei die Groß- und Kleinschreibung beachtet werden muss) und Bindestriche enthalten. Es muss mit einem alphanumerischen Zeichen beginnen und darf nicht länger als 100 Zeichen sein. Der Name muss innerhalb der AWS Region und des AWS Kontos, in dem Sie den Cluster erstellen, eindeutig sein. Ersetzen Sie den Rest der *example value* durch Ihre eigenen Werte. Die Knoten werden standardmäßig mit derselben Kubernetes-Version wie die Steuerungsebene erstellt. Bevor Sie einen Wert für auswählen`--node-type`, lesen [Sie den Artikel Wählen Sie einen optimalen EC2 Amazon-Node-Instance-Typ](choosing-instance-type.md). *my-key*Ersetzen Sie es durch den Namen Ihres EC2 Amazon-Schlüsselpaars oder öffentlichen Schlüssels. Dieser Schlüssel wird für den SSH-Zugriff zu Ihren Knoten verwendet, nachdem diese gestartet wurden. Wenn Sie noch kein EC2 Amazon-Schlüsselpaar haben, können Sie eines in der erstellen AWS-Managementkonsole. Weitere Informationen finden Sie unter [ EC2 Amazon-Schlüsselpaare](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im * EC2 Amazon-Benutzerhandbuch*. Erstellen Sie Ihre Knoten-Gruppe mit dem folgenden Befehl. **Wichtig** Wenn Sie eine Knotengruppe in AWS Outposts-, Wavelength- oder Local Zone-Subnetzen bereitstellen möchten, gibt es zusätzliche Überlegungen: Die Subnetze dürfen beim Erstellen des Clusters nicht übergeben worden sein. Sie müssen die Knotengruppe mit einer Konfigurationsdatei erstellen, die die Subnetze und ` [volumeType](https://eksctl.io/usage/schema/#nodeGroups-volumeType): gp2` angibt. Weitere Informationen dazu finden Sie unter [Verwenden von Config-Dateien](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) und im [Config-Datei-Schema](https://eksctl.io/usage/schema/) in der `eksctl`-Dokumentation. ``` eksctl create nodegroup \ --cluster my-cluster \ --name al-nodes \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --ssh-access \ --managed=false \ --ssh-public-key my-key ``` Zum Bereitstellen einer Knotengruppe, die: + kann Pods eine deutlich höhere Anzahl von IP-Adressen zuweisen als die Standardkonfiguration, siehe [Zuweisung weiterer IP-Adressen mit Präfixen zu Amazon-EKS-Knoten](cni-increase-ip-addresses.md). + kann `IPv4`-Adressen an Pods aus einem anderen CIDR-Block als dem der Instance zuweisen, siehe [Bereitstellung von Pods in alternativen Subnetzen mit benutzerdefiniertem Netzwerk](cni-custom-network.md). + kann `IPv6`-Adressen an Pods und Services zuweisen, siehe [Erfahren Sie mehr über IPv6 Adressen für Cluster, Pods und Dienste](cni-ipv6.md). + hat keinen ausgehenden Internetzugriff, siehe [Bereitstellung privater Cluster mit eingeschränktem Internetzugang](private-clusters.md). Geben Sie den folgenden Befehl ein, um eine vollständige Liste aller verfügbaren Optionen und Standardwerte anzuzeigen. ``` eksctl create nodegroup --help ``` Sollten Knoten nicht in den Cluster aufgenommen werden können, finden Sie weitere Informationen unter [Knoten können nicht mit dem Cluster verknüpft werden](troubleshooting.md#worker-node-fail) im Kapitel zur Fehlerbehebung. Eine Beispielausgabe sieht wie folgt aus. Mehrere Zeilen werden ausgegeben, während die Knoten erstellt werden. Die letzte Ausgabezeile ähnelt der folgenden Beispielzeile. ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (Optional) [Eine Beispielanwendung in Linux bereitstellen](sample-deployment.md) Stellen Sie eine Beispielanwendung bereit, um Ihren Cluster und Ihre Linux-Worker-Knoten zu testen. 1. Wir empfehlen, den Pod-Zugriff auf das IMDS zu blockieren, wenn die folgenden Bedingungen erfüllt sind: + Sie planen, allen Ihren Kubernetes-Servicekonten IAM-Rollen zuzuweisen, damit Pods nur die Mindestberechtigungen haben, die sie benötigen. + Keine Pods im Cluster benötigen aus anderen Gründen Zugriff auf den Amazon EC2 Instance Metadata Service (IMDS), z. B. zum Abrufen der aktuellen AWS Region. Weitere Informationen finden Sie unter [Beschränken Sie den Zugriff auf das Instance-Profil, das dem Worker-Knoten zugewiesen ist](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). ## AWS-Managementkonsole **Schritt 1: Selbstverwaltete Linux-Knoten mit AWS-Managementkonsole starten ** 1. Laden Sie die neueste Version der AWS CloudFormation Vorlage herunter. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-26/amazon-eks-nodegroup.yaml ``` 1. Warten Sie, bis der Status des Clusters als `ACTIVE` angezeigt wird. Wenn Sie Ihre Knoten starten, bevor der Cluster aktiv ist, werden die Knoten nicht mit dem Cluster registriert und Sie müssen sie neu starten. 1. Öffnen Sie die [AWS CloudFormation -Konsole](https://console.aws.amazon.com/cloudformation/). 1. Wählen Sie **Create stack** (Stack erstellen) und dann **With new resources (standard)** (Mit neuen Ressourcen [Standard]) aus. 1. Wählen Sie für **Specify template** (Vorlage festlegen) **Upload a template file** (Vorlagendatei hochladen) aus und wählen Sie dann **Choose file** (Datei wählen). 1. Wählen Sie die heruntergeladene `amazon-eks-nodegroup.yaml`-Datei aus. 1. Klicken Sie auf **Weiter**. 1. Geben Sie auf der Seite **Specify stack details** (Stack-Details angeben) die folgenden Parameter ein und klicken Sie dann auf **Next** (Weiter): + **Stack-Name**: Wählen Sie einen Stack-Namen für Ihren AWS CloudFormation Stack. Sie können ihn beispielsweise *my-cluster-nodes* nennen. Der Name darf nur alphanumerische Zeichen (wobei die Groß- und Kleinschreibung beachtet werden muss) und Bindestriche enthalten. Es muss mit einem alphanumerischen Zeichen beginnen und darf nicht länger als 100 Zeichen sein. Der Name muss innerhalb der AWS Region und des AWS Kontos, in dem Sie den Cluster erstellen, eindeutig sein. + **ClusterName**: Geben Sie den Namen ein, den Sie bei der Erstellung Ihres Amazon EKS-Clusters verwendet haben. Dieser Name muss exakt mit dem Cluster-Namen übereinstimmen, andernfalls werden Ihre Knoten dem Cluster nicht beitreten. + **ClusterControlPlaneSecurityGroup**: Wählen Sie den **SecurityGroups**Wert aus der AWS CloudFormation Ausgabe aus, die Sie bei der Erstellung Ihrer [VPC](creating-a-vpc.md) generiert haben. Die folgenden Schritte zeigen einen Vorgang zum Abrufen der entsprechenden Gruppe. 1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters). 1. Wählen Sie den Namen des Clusters. 1. Wählen Sie die Registerkarte **Network (Network)** aus. 1. Verwenden Sie den Wert **Zusätzliche Sicherheitsgruppen** als Referenz, wenn Sie aus der **ClusterControlPlaneSecurityGroup**Dropdownliste auswählen. + **ApiServerEndpoint**: Geben Sie den API-Server-Endpunkt für Ihren EKS-Cluster ein. Dies finden Sie im Abschnitt „Details“ der EKS-Cluster-Konsole + **CertificateAuthorityData**: Geben Sie die Base64-kodierten Zertifizierungsstellendaten ein, die Sie auch im Abschnitt „Details“ der EKS-Cluster-Konsole finden. + **ServiceCidr**: Geben Sie den CIDR-Bereich ein, der für die Zuweisung von IP-Adressen zu Kubernetes-Diensten innerhalb des Clusters verwendet wird. Dieser befindet sich auf der Registerkarte „Netzwerk“ der EKS-Cluster-Konsole. + **AuthenticationMode**: Wählen Sie den im EKS-Cluster verwendeten Authentifizierungsmodus aus, indem Sie auf der Registerkarte „Zugriff“ in der EKS-Cluster-Konsole nachsehen. + **NodeGroupName**: Geben Sie einen Namen für Ihre Knotengruppe ein. Dieser Name kann zu einem späteren Zeitpunkt zum Identifizieren der Auto-Scaling-Knotengruppe verwendet werden, die für Ihre Knoten erstellt wurde. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten. + **NodeAutoScalingGroupMinSize**: Geben Sie die Mindestanzahl von Knoten ein, auf die Ihre Auto Scaling Scaling-Gruppe für Knoten skalieren kann. + **NodeAutoScalingGroupDesiredCapacity**: Geben Sie die gewünschte Anzahl von Knoten ein, auf die bei der Erstellung Ihres Stacks skaliert werden soll. + **NodeAutoScalingGroupMaxSize**: Geben Sie die maximale Anzahl von Knoten ein, auf die Ihre Auto Scaling Scaling-Gruppe für Knoten skalieren kann. + **NodeInstanceType**: Wählen Sie einen Instance-Typ für Ihre Knoten. Weitere Informationen finden Sie unter [Auswahl eines optimalen Amazon-EC2-Knoten-Instance-Typs](choosing-instance-type.md). + **NodeImageIdSSMParam**: Vorab mit dem Amazon EC2 Systems Manager Manager-Parameter eines kürzlich von Amazon EKS optimierten Amazon Linux 2023 AMI für eine variable Kubernetes-Version gefüllt. Um eine andere Kubernetes-Nebenversion zu verwenden, die von Amazon EKS unterstützt wird, ersetzen Sie *1.XX* durch eine andere [unterstützte Version](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). Wir empfehlen, dieselbe Kubernetes-Version wie Ihr Cluster anzugeben. Sie können es auch *amazon-linux-2023* durch einen anderen AMI-Typ ersetzen. Weitere Informationen finden Sie unter [Rufen Sie das empfohlene Amazon Linux AMI ab IDs](retrieve-ami-id.md). **Anmerkung** Die Amazon EKS-Knoten AMIs basieren auf Amazon Linux. Sie können Sicherheits- oder Datenschutzereignisse für Amazon Linux 2023 im [Amazon Linux Security Center](https://alas.aws.amazon.com/alas2023.html) verfolgen oder den zugehörigen [RSS-Feed](https://alas.aws.amazon.com/AL2023/alas.rss) abonnieren. Sicherheits- oder Datenschutzereignisse enthalten eine Übersicht über das Problem, welche Pakete betroffen sind und wie Sie Ihre Instances aktualisieren, um das Problem zu beheben. + **NodeImageId**: (Optional) Wenn Sie Ihr eigenes benutzerdefiniertes AMI (anstelle eines für Amazon EKS optimierten AMI) verwenden, geben Sie eine Knoten-AMI-ID für Ihre AWS Region ein. Wenn Sie hier einen Wert angeben, überschreibt dieser alle Werte im **NodeImageIdSSMParam**Feld. + **NodeVolumeSize**: Geben Sie eine Root-Volume-Größe für Ihre Knoten in GiB an. + **NodeVolumeType**: Geben Sie einen Root-Volume-Typ für Ihre Knoten an. + **KeyName**: Geben Sie den Namen eines Amazon EC2 SSH-Schlüsselpaars ein, mit dem Sie nach dem Start über SSH eine Verbindung zu Ihren Knoten herstellen können. Wenn Sie noch kein EC2 Amazon-Schlüsselpaar haben, können Sie eines in der erstellen AWS-Managementkonsole. Weitere Informationen finden Sie unter [ EC2 Amazon-Schlüsselpaare](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im * EC2 Amazon-Benutzerhandbuch*. + **VpcId**: Geben Sie die ID für die [VPC](creating-a-vpc.md) ein, die Sie erstellt haben. + **Subnetze**: Wählen Sie die Subnetze aus, die Sie für Ihre VPC erstellt haben. Wenn Sie Ihre VPC anhand der unter [Erstellen einer Amazon VPC für Ihren Amazon-EKS-Cluster](creating-a-vpc.md) beschriebenen Schritte erstellt haben, geben Sie nur die privaten Subnetze innerhalb der VPC an, in denen Ihre Knoten gestartet werden sollen. Sie können sehen, welche Subnetze privat sind, indem Sie den jeweiligen Subnetzlink in der Registerkarte **Networking** (Netzwerk) Ihres Clusters öffnen. **Wichtig** Wenn es sich bei einem oder einigen der Subnetze um öffentliche Subnetze handelt, muss die Einstellung für die automatische Zuweisung öffentlicher IP-Adressen aktiviert sein. Wenn die Einstellung für das öffentliche Subnetz nicht aktiviert ist, wird allen Knoten, die Sie in diesem öffentlichen Subnetz bereitstellen, keine öffentliche IP-Adresse zugewiesen und sie können nicht mit dem Cluster oder anderen Diensten kommunizieren. AWS Wenn das Subnetz vor dem 26. März 2020 mithilfe einer der [Amazon AWS CloudFormation EKS-VPC-Vorlagen](creating-a-vpc.md) oder mithilfe `eksctl` von bereitgestellt wurde, ist die automatische Zuweisung öffentlicher IP-Adressen für öffentliche Subnetze deaktiviert. Informationen dazu, wie Sie die Zuweisung öffentlicher IP-Adressen für ein Subnetz aktivieren, finden Sie unter [Ändern des Attributs für die öffentliche IPv4 Adressierung](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) für Ihr Subnetz. Wenn der Knoten in einem privaten Subnetz bereitgestellt wird, kann er über ein NAT-Gateway mit dem Cluster und anderen AWS Diensten kommunizieren. Wenn die Subnetze keinen Internetzugang haben, stellen Sie sicher, dass Sie die Überlegungen und zusätzlichen Schritte unter [Bereitstellen privater Cluster mit eingeschränktem Internetzugang](private-clusters.md) kennen. Wenn Sie AWS Outposts-, Wavelength- oder Local Zone-Subnetze auswählen, dürfen die Subnetze bei der Erstellung des Clusters nicht übergeben worden sein. 1. Treffen Sie die gewünschte Auswahl auf der Seite **Configure stack options** (Stackoptionen konfigurieren) und wählen Sie dann **Next** (Weiter) aus. 1. Aktivieren Sie das Kontrollkästchen links neben **Ich bestätige, dass AWS CloudFormation möglicherweise IAM-Ressourcen erstellt** werden. , und wählen Sie dann **Stapel erstellen** aus. 1. Wenn Ihr Stack fertig erstellt wurde, wählen Sie ihn in der Konsole aus und klicken Sie auf **Outputs** (Ausgaben). Wenn Sie den `EKS API and ConfigMap` Authentifizierungsmodus `EKS API` oder verwenden, ist dies der letzte Schritt. 1. Wenn Sie den `ConfigMap` Authentifizierungsmodus verwenden, notieren Sie den **NodeInstanceRole**für die Knotengruppe, die erstellt wurde. **Schritt 2: Knoten, die Ihrem Cluster beitreten sollen, aktivieren** **Anmerkung** Die folgenden zwei Schritte sind nur erforderlich, wenn Sie den Configmap-Authentifizierungsmodus innerhalb des EKS-Clusters verwenden. Wenn Sie Knoten in einer privaten VPC ohne ausgehenden Internetzugang gestartet haben, stellen Sie außerdem sicher, dass Knoten Ihrem Cluster von der VPC aus beitreten können. 1. Überprüfen Sie, ob Sie bereits über eine `aws-auth` `ConfigMap` verfügen. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. Wenn eine `aws-auth` `ConfigMap` angezeigt wird, aktualisieren Sie sie nach Bedarf. 1. Öffnen Sie `ConfigMap` zum Bearbeiten. ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. Fügen Sie nach Bedarf einen neuen `mapRoles`-Eintrag hinzu. Setzen Sie den `rolearn` Wert auf den **NodeInstanceRole**Wert, den Sie im vorherigen Verfahren aufgezeichnet haben. ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes [...] ``` 1. Speichern Sie die Datei und beenden Sie den Text-Editor. 1. Wenn die Fehlermeldung `Error from server (NotFound): configmaps "aws-auth" not found` angezeigt wird, wenden Sie die standardmäßige `ConfigMap` an. 1. Laden Sie die Konfigurationszuordnung herunter. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml ``` 1. Stellen Sie in der `aws-auth-cm.yaml` Datei den `rolearn` Wert auf den **NodeInstanceRole**Wert ein, den Sie im vorherigen Verfahren aufgezeichnet haben. Hierzu können Sie einen Texteditor verwenden oder *my-node-instance-role* ersetzen und den folgenden Befehl ausführen: ``` sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml ``` 1. Wenden Sie die Konfiguration an. Die Ausführung dieses Befehls kann einige Minuten dauern. ``` kubectl apply -f aws-auth-cm.yaml ``` 1. Sehen Sie sich den Status Ihrer Knoten an und warten Sie, bis diese in den `Ready`-Status eintreten. ``` kubectl get nodes --watch ``` Geben Sie `Ctrl`\$1`C` ein, um zum Shell-Prompt zurückzukehren. **Anmerkung** Wenn Sie Autorisierungs- oder Ressourcenfehler erhalten, finden Sie weitere Informationen unter [Nicht autorisiert oder Zugriff verweigert (`kubectl`)](troubleshooting.md#unauthorized) im Thema zur Fehlerbehebung. Sollten Knoten nicht in den Cluster aufgenommen werden können, finden Sie weitere Informationen unter [Knoten können nicht mit dem Cluster verknüpft werden](troubleshooting.md#worker-node-fail) im Kapitel zur Fehlerbehebung. 1. (Nur GPU-Knoten) Wenn Sie einen GPU-Instance-Typ und das für Amazon EKS optimierte beschleunigte AMI ausgewählt haben, müssen Sie das [NVIDIA-Geräte-Plug-In für Kubernetes](https://github.com/NVIDIA/k8s-device-plugin) als a DaemonSet auf Ihrem Cluster anwenden. Ersetzen Sie es *vX.X.X* durch die gewünschte [s-device-pluginNVIDIA/K8-Version](https://github.com/NVIDIA/k8s-device-plugin/releases), bevor Sie den folgenden Befehl ausführen. ``` kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml ``` **Schritt 3: Zusätzliche Aktionen** 1. (Optional) [Eine Beispielanwendung in Linux bereitstellen](sample-deployment.md) Stellen Sie eine Beispielanwendung bereit, um Ihren Cluster und Ihre Linux-Worker-Knoten zu testen. 1. (Optional) Wenn die von **AmazonEKS\$1CNI\$1Policy** verwaltete IAM-Richtlinie (wenn Sie einen `IPv4` Cluster haben) oder die *AmazonEKS\$1CNI\$1IPv6\$1Policy* (die Sie [selbst erstellt](cni-iam-role.md#cni-iam-role-create-ipv6-policy) haben, wenn Sie einen `IPv6` Cluster haben) mit Ihrer [Amazon EKS-Knoten-IAM-Rolle verknüpft ist, empfehlen wir, sie stattdessen einer IAM-Rolle](create-node-role.md) zuzuweisen, die Sie dem Kubernetes-Servicekonto zuordnen. `aws-node` Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md). 1. Wir empfehlen, den Pod-Zugriff auf das IMDS zu blockieren, wenn die folgenden Bedingungen erfüllt sind: + Sie planen, allen Ihren Kubernetes-Servicekonten IAM-Rollen zuzuweisen, damit Pods nur die Mindestberechtigungen haben, die sie benötigen. + Keine Pods im Cluster benötigen aus anderen Gründen Zugriff auf den Amazon EC2 Instance Metadata Service (IMDS), z. B. zum Abrufen der aktuellen AWS Region. Weitere Informationen finden Sie unter [Beschränken Sie den Zugriff auf das Instance-Profil, das dem Worker-Knoten zugewiesen ist](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). # Selbstverwaltete Bottlerocket-Knoten erstellen **Anmerkung** Verwaltete Knotengruppen bieten möglicherweise einige Vorteile für Ihren Anwendungsfall. Weitere Informationen finden Sie unter [Vereinfachung des Knotenlebenszyklus mit verwalteten Knotengruppen](managed-node-groups.md). In diesem Thema wird beschrieben, wie Sie Auto-Scaling-Gruppen von [Bottlerocket](https://aws.amazon.com/bottlerocket/)-Knoten starten, die mit Ihrem Amazon-EKS-Cluster registriert sind. Bottlerocket ist ein Linux-basiertes Open-Source-Betriebssystem, mit dem Sie Container auf virtuellen AWS Maschinen oder Bare-Metal-Hosts ausführen können. Nachdem die Knoten dem Cluster beigetreten sind, können Sie Kubernetes-Anwendungen darin bereitstellen. Weitere Informationen zu Bottlerocket finden Sie in der Dokumentation unter [Using a Bottlerocket AMI with Amazon EKS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-EKS.md) on GitHub and [Custom](https://eksctl.io/usage/custom-ami-support/) AMI support. `eksctl` [Informationen zu direkten Upgrades finden Sie unter Bottlerocket Update Operator unter.](https://github.com/bottlerocket-os/bottlerocket-update-operator) GitHub **Wichtig** Amazon-EKS-Worker-Knoten sind Standard-Amazon-EC2-Instances und werden Ihnen basierend auf normalen Amazon-EC2-Instance-Preisen berechnet. Weitere Informationen dazu finden Sie unter [Amazon EC2 – Preise](https://aws.amazon.com/ec2/pricing/). Sie können Bottlerocket-Knoten in erweiterten Amazon EKS-Clustern auf AWS Outposts starten, aber Sie können sie nicht in lokalen Clustern auf Outposts starten. AWS Weitere Informationen finden Sie unter [Bereitstellung von Amazon EKS On-Premises mit AWS Outposts](eks-outposts.md). Sie können auf Amazon-EC2-Instances mit `x86`- oder Arm -Prozessoren bereitstellen. Sie können jedoch nicht auf Instances bereitstellen, die über Inferentia-Chips verfügen. Bottlerocket ist kompatibel mit. AWS CloudFormation Es gibt jedoch keine offizielle CloudFormation Vorlage, die kopiert werden kann, um Bottlerocket-Knoten für Amazon EKS bereitzustellen. Bottlerocket-Images werden nicht mit einem SSH-Server oder einer Shell geliefert. Sie können out-of-band Zugriffsmethoden verwenden, um die SSH-Aktivierung des Admin-Containers zu ermöglichen und einige Bootstrapping-Konfigurationsschritte mit Benutzerdaten zu durchlaufen. Weitere Informationen finden Sie in diesen Abschnitten im [bottlerocket README.md](https://github.com/bottlerocket-os/bottlerocket) auf GitHub: [Exploration](https://github.com/bottlerocket-os/bottlerocket#exploration) (Erkundung) [Administrator-Container](https://github.com/bottlerocket-os/bottlerocket#admin-container) [Kubernetes-Einstellungen](https://github.com/bottlerocket-os/bottlerocket#kubernetes-settings) Für diesen Vorgang ist `eksctl` Version `0.215.0` oder höher erforderlich. Sie können Ihre -Version mit dem folgenden Befehl überprüfen: ``` eksctl version ``` Anweisungen zum Installieren oder Aktualisieren von `eksctl` finden Sie unter [Installation](https://eksctl.io/installation) in der `eksctl`-Dokumentation. HINWEIS: Dieses Verfahren funktioniert nur für Cluster, die mit `eksctl` erstellt wurden. 1. Kopieren Sie den folgenden Inhalt auf Ihr Gerät. Ersetzen Sie *my-cluster* mit dem Namen Ihres Clusters. Der Name darf nur alphanumerische Zeichen (wobei die Groß- und Kleinschreibung beachtet werden muss) und Bindestriche enthalten. Es muss mit einem alphanumerischen Zeichen beginnen und darf nicht länger als 100 Zeichen sein. Der Name muss innerhalb der AWS Region und des AWS Kontos, in dem Sie den Cluster erstellen, eindeutig sein. Ersetzen Sie *ng-bottlerocket* durch einen Namen für Ihre Knotengruppe. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten. Um die Bereitstellung auf Arm-Instances durchzuführen, ersetzen Sie *m5.large* durch einen Arm-Instance-Typ. Ersetzen Sie *my-ec2-keypair-name* mit dem Namen eines Amazon-EC2-SSH-Schlüsselpaars ein, das Sie für die Verbindung über SSH in Ihre Arbeitsknoten verwenden können, nachdem sie gestartet wurden. Wenn Sie noch kein Amazon-EC2-Schlüsselpaar haben, können Sie eines in der AWS-Managementkonsole erstellen. Weitere Informationen finden Sie unter [Amazon-EC2-Schlüsselpaare](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im *Amazon-EC2-Benutzerhandbuch*. Ersetzen Sie alle verbleibenden Beispielwerte durch Ihre eigenen Werte. Nachdem Sie das Ersetzen vorgenommen haben, führen Sie den geänderten Befehl aus, um die `bottlerocket.yaml`-Datei zu erstellen. Wenn Sie einen Arm Amazon EC2 EC2-Instance-Typ angeben, lesen Sie AMIs vor der Bereitstellung die Überlegungen im für [Amazon EKS optimierten Arm Amazon Linux](eks-optimized-ami.md#arm-ami). Anweisungen zur Bereitstellung mit einem benutzerdefinierten AMI finden Sie in der Dokumentation unter [Building Bottlerocket](https://github.com/bottlerocket-os/bottlerocket/blob/develop/BUILDING.md) on GitHub und [Custom AMI support](https://eksctl.io/usage/custom-ami-support/). `eksctl` Um eine verwaltete Knotengruppe bereitzustellen, stellen Sie ein benutzerdefiniertes AMI mithilfe einer Startvorlage bereit. Weitere Informationen finden Sie unter [Verwaltete Knoten mit Startvorlagen anpassen](launch-templates.md). **Wichtig** Um eine Knotengruppe in AWS Outposts-, AWS Wavelength- oder AWS Local Zone-Subnetzen bereitzustellen, übergeben Sie beim Erstellen des Clusters keine AWS Outposts-, AWS Wavelength- oder AWS Local Zone-Subnetze. Sie müssen die Subnetze im folgenden Beispiel angeben. Weitere Informationen finden Sie unter [Verwenden von Config-Dateien](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) und im [Config-Datei-Schema](https://eksctl.io/usage/schema/) in der `eksctl`-Dokumentation. Ersetzen Sie es *region-code* durch die AWS Region, in der sich Ihr Cluster befindet. ``` cat >bottlerocket.yaml < Dieses Thema beschreibt Hinweise zum Starten von Auto-Scaling-Gruppen von -Windows-Knoten, die mit Ihrem Amazon-EKS-Cluster registriert sind. Nachdem die Knoten dem Cluster beigetreten sind, können Sie Kubernetes-Anwendungen darin bereitstellen. **Wichtig** Amazon-EKS-Worker-Knoten sind Standard-Amazon-EC2-Instances und werden Ihnen basierend auf normalen Amazon-EC2-Instance-Preisen berechnet. Weitere Informationen dazu finden Sie unter [Amazon EC2 – Preise](https://aws.amazon.com/ec2/pricing/). Sie können Windows-Knoten in erweiterten Amazon EKS-Clustern auf AWS Outposts starten, aber Sie können sie nicht in lokalen Clustern auf AWS Outposts starten. Weitere Informationen finden Sie unter [Bereitstellung von Amazon EKS On-Premises mit AWS Outposts](eks-outposts.md). Aktivieren Sie den Windows-Support für Ihren Cluster. Es wird empfohlen, wichtige Überlegungen zu berücksichtigen, bevor Sie eine Windows-Knotengruppe starten. Weitere Informationen finden Sie unter [Windows-Support aktivieren](windows-support.md#enable-windows-support). Sie können selbstverwaltete Windows-Knoten mit einer der folgenden Methoden starten: + [`eksctl`](#eksctl_create_windows_nodes) + [AWS-Managementkonsole](#console_create_windows_nodes) ## `eksctl` **Selbstverwaltete Windows-Knoten mithilfe von `eksctl` starten ** Bei diesem Verfahren wird davon ausgegangen, dass Sie `eksctl` installiert haben und dass Ihre `eksctl`-Version mindestens `0.215.0` ist. Sie können Ihre Version mit dem folgenden Befehl überprüfen. ``` eksctl version ``` Eine Installations- und Upgrade-Anleitung für `eksctl` finden Sie in der Dokumentation zu `eksctl` unter [Installation](https://eksctl.io/installation). **Anmerkung** Dieses Verfahren funktioniert nur für Cluster, die mit `eksctl` erstellt wurden. 1. (Optional) Wenn die von **AmazonEKS\$1CNI\$1Policy** verwaltete IAM-Richtlinie (wenn Sie einen `IPv4` Cluster haben) oder die *AmazonEKS\$1CNI\$1IPv6\$1Policy* (die Sie [selbst erstellt](cni-iam-role.md#cni-iam-role-create-ipv6-policy) haben, wenn Sie einen `IPv6` Cluster haben) mit Ihrer [Amazon EKS-Knoten-IAM-Rolle verknüpft ist, empfehlen wir, sie stattdessen einer IAM-Rolle](create-node-role.md) zuzuweisen, die Sie dem Kubernetes-Servicekonto zuordnen. `aws-node` Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md). 1. Bei diesem Verfahren wird davon ausgegangen, dass Sie einen bestehenden Cluster haben. Wenn Sie nicht über einen Amazon-EKS-Cluster und eine Amazon-Linux-Knotengruppe verfügen, zu der Sie eine Windows-Knotengruppe hinzufügen können, empfehlen wir Ihnen, [Erste Schritte mit Amazon EKS – `eksctl`](getting-started-eksctl.md) zu befolgen. Dieses Handbuch bietet eine vollständige Anleitung zum Erstellen eines Amazon-EKS-Clusters mit Amazon-Linux-Knoten. Erstellen Sie Ihre Knoten-Gruppe mit dem folgenden Befehl. Ersetzen *region-code* Sie es durch die Region, in der sich Ihr Cluster befindet. AWS Ersetzen Sie *my-cluster* mit Ihrem Clusternamen. Der Name darf nur alphanumerische Zeichen (wobei die Groß- und Kleinschreibung beachtet werden muss) und Bindestriche enthalten. Es muss mit einem alphanumerischen Zeichen beginnen und darf nicht länger als 100 Zeichen sein. Der Name muss innerhalb der AWS Region und des AWS Kontos, in dem Sie den Cluster erstellen, eindeutig sein. Ersetzen Sie *ng-windows* durch einen Namen für Ihre Knotengruppe. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten. Sie können durch *2019* ersetzen`2022`, um Windows Server 2022 oder Windows Server 2025 `2025` zu verwenden. Ersetzen Sie die restlichen Beispielwerte durch Ihre eigenen Werte. **Wichtig** Um eine Knotengruppe in AWS Outposts-, AWS Wavelength- oder AWS Local Zone-Subnetzen bereitzustellen, übergeben Sie die Subnetze AWS Outposts, Wavelength oder Local Zone nicht, wenn Sie den Cluster erstellen. Erstellen Sie die Knotengruppe mit einer Konfigurationsdatei, in der Sie die Subnetze AWS Outposts, Wavelength oder Local Zone angeben. Weitere Informationen finden Sie unter [Verwenden von Config-Dateien](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) und im [Config-Datei-Schema](https://eksctl.io/usage/schema/) in der `eksctl`-Dokumentation. ``` eksctl create nodegroup \ --region region-code \ --cluster my-cluster \ --name ng-windows \ --node-type t2.large \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false \ --node-ami-family WindowsServer2019FullContainer ``` **Anmerkung** Wenn Arbeitsknoten dem Cluster nicht beitreten können, finden Sie weitere Informationen unter [Knoten können nicht mit dem Cluster verknüpft werden](troubleshooting.md#worker-node-fail) im Handbuch zur Fehlerbehebung. Geben Sie den folgenden Befehl ein, um die verfügbaren Optionen für `eksctl`-Befehle anzuzeigen. ``` eksctl command -help ``` Eine Beispielausgabe sieht wie folgt aus. Mehrere Zeilen werden ausgegeben, während die Knoten erstellt werden. Die letzte Ausgabezeile ähnelt der folgenden Beispielzeile. ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (Optional) [Eine Beispielanwendung in Linux bereitstellen](sample-deployment.md) Stellen Sie eine Beispielanwendung bereit, um Ihren Cluster und Ihre Windows-Worker-Knoten zu testen. 1. Wir empfehlen, den Pod-Zugriff auf das IMDS zu blockieren, wenn die folgenden Bedingungen erfüllt sind: + Sie planen, allen Ihren Kubernetes-Servicekonten IAM-Rollen zuzuweisen, damit Pods nur die Mindestberechtigungen haben, die sie benötigen. + Keine Pods im Cluster benötigen aus anderen Gründen Zugriff auf den Amazon EC2 EC2-Instance-Metadaten-Service (IMDS), z. B. zum Abrufen der aktuellen Region. AWS Weitere Informationen finden Sie unter [Beschränken Sie den Zugriff auf das Instance-Profil, das dem Worker-Knoten zugewiesen ist](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). ## AWS-Managementkonsole **Voraussetzungen** + Ein bestehender Amazon-EKS-Cluster und eine Linux-Knotengruppe. Wenn Sie nicht über diese Ressourcen verfügen, empfehlen wir Ihnen, diese mithilfe einer unserer Anleitungen in [Erste Schritte mit Amazon EKS](getting-started.md) zu erstellen. Diese Anleitungen beschreiben, wie Sie einen Amazon-EKS-Cluster mit Linux-Knoten erstellen. + Eine vorhandene VPC und eine Sicherheitsgruppe, die die Voraussetzungen für einen Amazon-EKS-Cluster erfüllen. Weitere Informationen erhalten Sie unter [Amazon-EKS-Netzwerkanforderungen für VPC und Subnetze](network-reqs.md) und [Anforderungen der Amazon-EKS-Sicherheitsgruppe für Cluster anzeigen](sec-group-reqs.md). Die Guides in [Erste Schritte mit Amazon EKS](getting-started.md) erstellen eine VPC, die den Anforderungen entspricht. Alternativ können Sie auch den Abschnitt [Erstellen einer Amazon VPC für Ihren Amazon-EKS-Cluster](creating-a-vpc.md) befolgen, um manuell eine VPC zu erstellen. + Ein vorhandener Amazon-EKS-Cluster, der eine VPC und eine Sicherheitsgruppe verwendet, die die Voraussetzungen eines Amazon-EKS-Clusters erfüllt. Weitere Informationen finden Sie unter [Amazon-EKS-Cluster erstellen](create-cluster.md). Wenn Sie Subnetze in der AWS Region haben, in der Sie AWS Outposts, AWS Wavelength oder AWS Local Zones aktiviert haben, dürfen diese Subnetze bei der Erstellung des Clusters nicht weitergegeben worden sein. **Schritt 1: Selbstverwaltete Windows-Knoten mit der AWS-Managementkonsole starten ** 1. Warten Sie, bis der Status des Clusters als `ACTIVE` angezeigt wird. Wenn Sie Ihre Knoten starten, bevor der Cluster aktiv ist, werden die Knoten nicht mit dem Cluster registriert und Sie müssen sie neu starten. 1. Öffnen Sie die [AWS CloudFormation -Konsole](https://console.aws.amazon.com/cloudformation/). 1. Wählen Sie **Stack erstellen** aus. 1. Wählen Sie unter **Vorlage angeben** die Option **Amazon-S3-URL** aus. 1. Kopieren Sie die folgende URL und fügen Sie sie in die **Amazon S3 URL** (Amazon-S3-URL) ein. ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml ``` 1. Wählen Sie zweimal **Next** (Weiter) aus. 1. Füllen Sie auf der Seite **Quick create stack** (Stack schnell erstellen) die folgenden Parameter entsprechend aus: + **Stack-Name**: Wählen Sie einen Stack-Namen für Ihren Stack. AWS CloudFormation Sie können ihn beispielsweise `my-cluster-nodes` nennen. + **ClusterName**: Geben Sie den Namen ein, den Sie bei der Erstellung Ihres Amazon EKS-Clusters verwendet haben. **Wichtig** Dieser Name muss genau mit dem Namen übereinstimmen, den Sie in [Schritt 1: Amazon-EKS-Cluster erstellen](getting-started-console.md#eks-create-cluster) verwendet haben. Andernfalls können Ihre Knoten dem Cluster nicht beitreten. + **ClusterControlPlaneSecurityGroup**: Wählen Sie die Sicherheitsgruppe aus der AWS CloudFormation Ausgabe aus, die Sie bei der Erstellung Ihrer [VPC](creating-a-vpc.md) generiert haben. Die folgenden Schritte zeigen eine Methode zum Abrufen der entsprechenden Gruppe. 1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters). 1. Wählen Sie den Namen des Clusters. 1. Wählen Sie die Registerkarte **Network (Network)** aus. 1. Verwenden Sie den Wert **Zusätzliche Sicherheitsgruppen** als Referenz, wenn Sie aus der **ClusterControlPlaneSecurityGroup**Dropdownliste auswählen. + **NodeGroupName**: Geben Sie einen Namen für Ihre Knotengruppe ein. Dieser Name kann zu einem späteren Zeitpunkt zum Identifizieren der Auto-Scaling-Knotengruppe verwendet werden, die für Ihre Knoten erstellt wurde. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten. + **NodeAutoScalingGroupMinSize**: Geben Sie die Mindestanzahl von Knoten ein, auf die Ihre Auto Scaling Scaling-Gruppe für Knoten skalieren kann. + **NodeAutoScalingGroupDesiredCapacity**: Geben Sie die gewünschte Anzahl von Knoten ein, auf die bei der Erstellung Ihres Stacks skaliert werden soll. + **NodeAutoScalingGroupMaxSize**: Geben Sie die maximale Anzahl von Knoten ein, auf die Ihre Auto Scaling Scaling-Gruppe für Knoten skalieren kann. + **NodeInstanceType**: Wählen Sie einen Instance-Typ für Ihre Knoten. Weitere Informationen finden Sie unter [Auswahl eines optimalen Amazon-EC2-Knoten-Instance-Typs](choosing-instance-type.md). **Anmerkung** [Die unterstützten Instance-Typen für die neueste Version des [Amazon VPC CNI-Plug-ins für Kubernetes sind in vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s) on aufgeführt.](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) GitHub Möglicherweise müssen Sie Ihre CNI-Version aktualisieren, um die neuesten unterstützten Instance-Typen zu nutzen. Weitere Informationen finden Sie unter [Pods mit dem Amazon VPC CNI zuweisen IPs](managing-vpc-cni.md). + **NodeImageIdSSMParam**: Vorab mit dem Amazon EC2 Systems Manager Manager-Parameter der aktuell empfohlenen Amazon EKS-optimierten Windows Core AMI-ID gefüllt. Um die Vollversion von Windows zu verwenden, ersetzen Sie *Core* durch `Full`. + **NodeImageId**: (Optional) Wenn Sie Ihr eigenes benutzerdefiniertes AMI (anstelle eines für Amazon EKS optimierten AMI) verwenden, geben Sie eine Knoten-AMI-ID für Ihre AWS Region ein. Wenn Sie einen Wert für dieses Feld angeben, überschreibt dieser alle Werte in dem **NodeImageIdSSMParam**Feld. + **NodeVolumeSize**: Geben Sie eine Root-Volume-Größe für Ihre Knoten in GiB an. + **KeyName**: Geben Sie den Namen eines Amazon EC2 SSH-Schlüsselpaars ein, mit dem Sie sich nach dem Start über SSH mit Ihren Knoten verbinden können. Wenn Sie noch kein Amazon-EC2-Schlüsselpaar haben, können Sie eines in der AWS-Managementkonsole erstellen. Weitere Informationen finden Sie unter [Amazon-EC2-Schlüsselpaare](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) im *Amazon-EC2-Benutzerhandbuch*. **Anmerkung** Wenn Sie hier kein key pair angeben, kann der AWS CloudFormation Stack nicht erstellt werden. + **BootstrapArguments**: Geben Sie alle optionalen Argumente an, die an das Node-Bootstrap-Skript übergeben werden sollen, z. B. zusätzliche `kubelet` Argumente mit`-KubeletExtraArgs`. + **Deaktivieren IMDSv1**: Standardmäßig unterstützt jeder Knoten den Instanz-Metadatendienst Version 1 (IMDSv1) und IMDSv2. Sie können deaktivieren IMDSv1. Um zu verhindern, dass future Knoten und Pods in der Knotengruppe verwendet werden MDSv1, setzen **Sie Disable IMDSv1** auf **true**. Weitere Informationen finden Sie unter [Konfiguration des Instance-Metadatenservice](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). + **VpcId**: Wählen Sie die ID für die [VPC](creating-a-vpc.md) aus, die Sie erstellt haben. + **NodeSecurityGroups**: Wählen Sie die Sicherheitsgruppe aus, die für Ihre Linux-Knotengruppe erstellt wurde, als Sie Ihre [VPC](creating-a-vpc.md) erstellt haben. Wenn Ihren Linux-Knoten mehr als eine Sicherheitsgruppe angehängt ist, geben Sie alle an. Dies z. B., wenn die Linux-Knotengruppe mit `eksctl` erstellt wurde. + **Subnets** (Subnetze): Wählen Sie die Subnetze aus, die Sie erstellt haben. Wenn Sie Ihre VPC gemäß den Schritten unter [Erstellen einer Amazon VPC für Ihren Amazon-EKS-Cluster](creating-a-vpc.md) erstellt haben, geben Sie nur die privaten Subnetze innerhalb der VPC an, in denen Ihre Knoten gestartet werden sollen. **Wichtig** Wenn es sich bei einem oder einigen der Subnetze um öffentliche Subnetze handelt, muss die Einstellung für die automatische Zuweisung öffentlicher IP-Adressen aktiviert sein. Wenn die Einstellung für das öffentliche Subnetz nicht aktiviert ist, wird allen Knoten, die Sie in diesem öffentlichen Subnetz bereitstellen, keine öffentliche IP-Adresse zugewiesen und sie können nicht mit dem Cluster oder anderen Diensten kommunizieren. AWS Wenn das Subnetz vor dem 26. März 2020 mithilfe einer der [Amazon AWS CloudFormation EKS-VPC-Vorlagen](creating-a-vpc.md) oder mithilfe `eksctl` von bereitgestellt wurde, ist die automatische Zuweisung öffentlicher IP-Adressen für öffentliche Subnetze deaktiviert. Informationen zum Aktivieren der Zuweisung öffentlicher IP-Adressen für ein Subnetz finden Sie unter [Ändern des Attributs für die öffentliche IPv4 Adressierung](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip) für Ihr Subnetz. Wenn der Knoten in einem privaten Subnetz bereitgestellt wird, kann er über ein NAT-Gateway mit dem Cluster und anderen AWS Diensten kommunizieren. Wenn die Subnetze keinen Internetzugang haben, stellen Sie sicher, dass Sie die Überlegungen und zusätzlichen Schritte unter [Bereitstellen privater Cluster mit eingeschränktem Internetzugang](private-clusters.md) kennen. Wenn Sie AWS Outposts-, Wavelength- oder Local Zone-Subnetze auswählen, dürfen die Subnetze bei der Erstellung des Clusters nicht übergeben worden sein. 1. Bestätigen Sie, dass der Stack IAM-Ressourcen erstellen kann, und wählen Sie dann **Create stack** (Stack erstellen) aus. 1. Wenn Ihr Stack fertig erstellt wurde, wählen Sie ihn in der Konsole aus und klicken Sie auf **Outputs** (Ausgaben). 1. Notieren Sie das **NodeInstanceRole**für die Knotengruppe, die erstellt wurde. Sie benötigen diese, wenn Sie Ihre Amazon-EKS-Windows-Knoten konfigurieren. **Schritt 2: Knoten, die Ihrem Cluster beitreten sollen, aktivieren** 1. Überprüfen Sie, ob Sie bereits über eine `aws-auth` `ConfigMap` verfügen. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. Wenn eine `aws-auth` `ConfigMap` angezeigt wird, aktualisieren Sie sie nach Bedarf. 1. Öffnen Sie `ConfigMap` zum Bearbeiten. ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. Fügen Sie nach Bedarf neue `mapRoles`-Einträge hinzu. Stellen Sie die `rolearn` Werte auf die **NodeInstanceRole**Werte ein, die Sie in den vorherigen Verfahren aufgezeichnet haben. ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - eks:kube-proxy-windows [...] ``` 1. Speichern Sie die Datei und beenden Sie den Text-Editor. 1. Wenn die Fehlermeldung `Error from server (NotFound): configmaps "aws-auth" not found` angezeigt wird, wenden Sie die standardmäßige `ConfigMap` an. 1. Laden Sie die Konfigurationszuordnung herunter. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml ``` 1. Stellen Sie in der `aws-auth-cm-windows.yaml` Datei die `rolearn` Werte auf die entsprechenden **NodeInstanceRole**Werte ein, die Sie in den vorherigen Verfahren aufgezeichnet haben. Hierzu können Sie einen Texteditor verwenden oder die Beispielwerte ersetzen und den folgenden Befehl ausführen: ``` sed -i.bak -e 's||my-node-linux-instance-role|' \ -e 's||my-node-windows-instance-role|' aws-auth-cm-windows.yaml ``` **Wichtig** Ändern Sie keine weiteren Zeilen in dieser Datei. Verwenden Sie nicht dieselbe IAM-Rolle sowohl für Windows- als auch für Linux-Knoten. 1. Wenden Sie die Konfiguration an. Die Ausführung dieses Befehls kann einige Minuten dauern. ``` kubectl apply -f aws-auth-cm-windows.yaml ``` 1. Sehen Sie sich den Status Ihrer Knoten an und warten Sie, bis diese in den `Ready`-Status eintreten. ``` kubectl get nodes --watch ``` Geben Sie `Ctrl`\$1`C` ein, um zum Shell-Prompt zurückzukehren. **Anmerkung** Wenn Sie Autorisierungs- oder Ressourcenfehler erhalten, finden Sie weitere Informationen unter [Nicht autorisiert oder Zugriff verweigert (`kubectl`)](troubleshooting.md#unauthorized) im Thema zur Fehlerbehebung. Sollten Knoten nicht in den Cluster aufgenommen werden können, finden Sie weitere Informationen unter [Knoten können nicht mit dem Cluster verknüpft werden](troubleshooting.md#worker-node-fail) im Kapitel zur Fehlerbehebung. **Schritt 3: Zusätzliche Aktionen** 1. (Optional) [Eine Beispielanwendung in Linux bereitstellen](sample-deployment.md) Stellen Sie eine Beispielanwendung bereit, um Ihren Cluster und Ihre Windows-Worker-Knoten zu testen. 1. (Optional) Wenn die von **AmazonEKS\$1CNI\$1Policy** verwaltete IAM-Richtlinie (wenn Sie einen `IPv4` Cluster haben) oder die *AmazonEKS\$1CNI\$1IPv6\$1Policy* (die Sie [selbst erstellt](cni-iam-role.md#cni-iam-role-create-ipv6-policy) haben, wenn Sie einen `IPv6` Cluster haben) mit Ihrer [Amazon EKS-Knoten-IAM-Rolle verknüpft ist, empfehlen wir, sie stattdessen einer IAM-Rolle](create-node-role.md) zuzuweisen, die Sie dem Kubernetes-Servicekonto zuordnen. `aws-node` Weitere Informationen finden Sie unter [Konfiguration des Amazon-VPC-CNI-Plugins für die Verwendung von IRSA](cni-iam-role.md). 1. Wir empfehlen, den Pod-Zugriff auf das IMDS zu blockieren, wenn die folgenden Bedingungen erfüllt sind: + Sie planen, allen Ihren Kubernetes-Servicekonten IAM-Rollen zuzuweisen, damit Pods nur die Mindestberechtigungen haben, die sie benötigen. + Keine Pods im Cluster benötigen aus anderen Gründen Zugriff auf den Amazon EC2 EC2-Instance-Metadaten-Service (IMDS), z. B. zum Abrufen der aktuellen Region. AWS Weitere Informationen finden Sie unter [Beschränken Sie den Zugriff auf das Instance-Profil, das dem Worker-Knoten zugewiesen ist](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). # Selbstverwaltete Ubuntu Linux-Knoten erstellen **Anmerkung** Verwaltete Knotengruppen bieten möglicherweise einige Vorteile für Ihren Anwendungsfall. Weitere Informationen finden Sie unter [Vereinfachung des Knotenlebenszyklus mit verwalteten Knotengruppen](managed-node-groups.md). In diesem Thema wird beschrieben, wie Sie Auto Scaling-Gruppen von Knoten von [Ubuntu in Amazon Elastic Kubernetes Service (EKS)](https://cloud-images.ubuntu.com/aws-eks/) oder Knoten von [Ubuntu Pro in Amazon Elastic Kubernetes Service (EKS)](https://ubuntu.com/blog/ubuntu-pro-for-eks-is-now-generally-available) starten, die bei Ihrem Amazon-EKS-Cluster registriert sind. Ubuntu und Ubuntu Pro für EKS basieren auf dem offiziellen Ubuntu Minimal LTS, enthalten den benutzerdefinierten AWS Kernel, der gemeinsam mit EKS entwickelt wurde AWS, und wurden speziell für EKS gebaut. Ubuntu Pro bietet zusätzliche Sicherheit durch die Unterstützung erweiterter EKS-Supportzeiträume, Kernel-Live-Patches, FIPS-Konformität und die Möglichkeit, eine unbegrenzte Anzahl von Pro-Containern auszuführen. Nachdem die Knoten dem Cluster beigetreten sind, können Sie darin containerisierte Anwendungen bereitstellen. Weitere Informationen finden Sie in der Dokumentation zu [Ubuntu in AWS](https://documentation.ubuntu.com/aws/en/latest/) und zum [Benutzerdefinierten AMI-Support](https://eksctl.io/usage/custom-ami-support/) in der `eksctl`-Dokumentation. **Wichtig** Amazon-EKS-Worker-Knoten sind Standard-Amazon-EC2-Instances und werden Ihnen basierend auf normalen Amazon-EC2-Instance-Preisen berechnet. Weitere Informationen dazu finden Sie unter [Amazon EC2 – Preise](https://aws.amazon.com/ec2/pricing/). Sie können Ubuntu-Knoten in erweiterten Amazon EKS-Clustern auf AWS Outposts starten, aber Sie können sie nicht in lokalen Clustern auf AWS Outposts starten. Weitere Informationen finden Sie unter [Bereitstellung von Amazon EKS On-Premises mit AWS Outposts](eks-outposts.md). Sie können auf Amazon-EC2-Instances mit `x86`- oder Arm -Prozessoren bereitstellen. Bei Instances mit Inferentia-Chips muss jedoch möglicherweise zuerst das [Neuron SDK](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/) installiert werden. Für diesen Vorgang ist `eksctl` Version `0.215.0` oder höher erforderlich. Sie können Ihre -Version mit dem folgenden Befehl überprüfen: ``` eksctl version ``` Anweisungen zum Installieren oder Aktualisieren von `eksctl` finden Sie unter [Installation](https://eksctl.io/installation) in der `eksctl`-Dokumentation. HINWEIS: Dieses Verfahren funktioniert nur für Cluster, die mit `eksctl` erstellt wurden. 1. Kopieren Sie den folgenden Inhalt auf Ihr Gerät. Ersetzen Sie `my-cluster` mit dem Namen Ihres Clusters. Der Name darf nur alphanumerische Zeichen (wobei die Groß- und Kleinschreibung beachtet werden muss) und Bindestriche enthalten. Es muss mit einem alphabetischen Zeichen beginnen und darf nicht mehr als 100 Zeichen umfassen. Ersetzen Sie `ng-ubuntu` durch einen Namen für Ihre Knotengruppe. Der Name der Knotengruppe darf nicht länger als 63 Zeichen sein. Er muss mit einem Buchstaben oder einer Ziffer beginnen, kann danach aber auch Bindestriche und Unterstriche enthalten. Um die Bereitstellung auf Arm-Instances durchzuführen, ersetzen Sie `m5.large` durch einen Arm-Instance-Typ. Ersetzen Sie `my-ec2-keypair-name` mit dem Namen eines Amazon-EC2-SSH-Schlüsselpaars ein, das Sie für die Verbindung über SSH in Ihre Arbeitsknoten verwenden können, nachdem sie gestartet wurden. Wenn Sie noch kein Amazon-EC2-Schlüsselpaar haben, können Sie eines in der AWS-Managementkonsole erstellen. Weitere Informationen finden Sie unter [Amazon-EC2-Schlüsselpaare](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im Amazon-EC2-Benutzerhandbuch. Ersetzen Sie alle verbleibenden Beispielwerte durch Ihre eigenen Werte. Nachdem Sie das Ersetzen vorgenommen haben, führen Sie den geänderten Befehl aus, um die `ubuntu.yaml`-Datei zu erstellen. **Wichtig** Um eine Knotengruppe in AWS Outposts-, AWS Wavelength- oder AWS Local Zone-Subnetzen bereitzustellen, übergeben Sie beim Erstellen des Clusters keine AWS Outposts-, AWS Wavelength- oder AWS Local Zone-Subnetze. Sie müssen die Subnetze im folgenden Beispiel angeben. Weitere Informationen finden Sie unter [Verwenden von Config-Dateien](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) und im [Config-Datei-Schema](https://eksctl.io/usage/schema/) in der `eksctl`-Dokumentation. Ersetzen Sie es *region-code* durch die AWS Region, in der sich Ihr Cluster befindet. ``` cat >ubuntu.yaml < Wenn eine neue Amazon-EKS-optimierte AMI veröffentlicht wird, ziehen Sie in Betracht, die Knoten in Ihrer selbstverwalteten Knoten-Gruppe durch die neue AMI zu ersetzen. Ebenso gilt, dass Sie bei einer Aktualisierung der Kubernetes-Version für Ihren Amazon-EKS-Cluster auch die Worker-Knoten aktualisieren, um Knoten mit derselben Kubernetes-Version zu verwenden. **Wichtig** In diesem Thema werden Worker-Knotenaktualisierungen für selbstverwaltete Knotengruppen behandelt. Wenn Sie [verwaltete Knotengruppen](managed-node-groups.md) verwenden, lesen Sie [Eine verwaltete Knotengruppe für Ihren Cluster aktualisieren](update-managed-node-group.md). Es gibt zwei grundlegende Möglichkeiten, selbstverwaltete Knotengruppen in Ihren Clustern zu aktualisieren, um ein neues AMI zu verwenden: ** [Anwendungen zu einer neuen Knotengruppe migrieren](migrate-stack.md) ** Erstellen Sie eine neue Worker-Knotengruppe und migrieren Sie Ihre Pods zu dieser Gruppe. Die Migration zu einer neuen Knotengruppe ist sinnvoller als die Aktualisierung der AMI-ID in einem bestehenden AWS-CloudFormation-Stack. Dies liegt daran, dass der Migrationsprozess die alte Knotengruppe als `NoSchedule` [verunreinigt](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) und die Knoten leert, nachdem ein neuer Stack bereit ist, die vorhandene Pod-Workload zu akzeptieren. ** [AWS-CloudFormation-Knoten-Stack aktualisieren](update-stack.md) ** Aktualisieren Sie den AWS-CloudFormation-Stack für eine vorhandene Worker-Knotengruppe, um das neue AMI zu verwenden. Diese Methode wird nicht bei Knoten-Gruppen unterstützt, die mit `eksctl` erstellt wurden. # Anwendungen zu einer neuen Knotengruppe migrieren Dieses Thema beschreibt Hinweise zum Erstellen einer neuen Knoten-Gruppe, zum ordnungsgemäßen Migrieren Ihrer vorhandenen Anwendungen zur neuen Gruppe und zum Entfernen der alten Knoten-Gruppe aus Ihrem Cluster. Sie können zu einer neuen Knotengruppe migrieren, indem Sie `eksctl` oder AWS-Managementkonsole benutzen. + [`eksctl`](#eksctl_migrate_apps) + [AWS-Managementkonsole und AWS CLI](#console_migrate_apps) ## `eksctl` **Migration Ihrer Anwendungen zu einer neuen Knotengruppe mit `eksctl` ** Weitere Informationen zur Verwendung von eksctl finden Sie unter [Upgrades von nicht verwalteten Knotengruppen](https://eksctl.io/usage/nodegroup-unmanaged/) in der `eksctl`-Dokumentation. Für diesen Vorgang ist `eksctl` Version `0.215.0` oder höher erforderlich. Sie können Ihre -Version mit dem folgenden Befehl überprüfen: ``` eksctl version ``` Eine Installations- und Upgrade-Anleitung für `eksctl` finden Sie in der Dokumentation zu `eksctl` unter [Installation](https://eksctl.io/installation). **Anmerkung** Dieses Verfahren funktioniert nur für Cluster, die mit `eksctl` erstellt wurden. 1. Rufen Sie den Namen Ihrer vorhandenen Knotengruppen ab und ersetzen Sie *my-cluster* durch Ihren Clusternamen. ``` eksctl get nodegroups --cluster=my-cluster ``` Eine Beispielausgabe sieht wie folgt aus. ``` CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID default standard-nodes 2019-05-01T22:26:58Z 1 4 3 t3.medium ami-05a71d034119ffc12 ``` 1. Starten Sie eine neue Knotengruppe mit `eksctl` mit dem folgenden Befehl. Ersetzen Sie im Befehl jedes *example value* durch Ihre eigenen Werte. Die Versionsnummer darf nicht höher als die Kubernetes-Version für Ihre Steuerebene sein. Außerdem darf sie nicht mehr als zwei Nebenversionen älter sein als die Kubernetes-Version für Ihre Steuerebene. Es wird empfohlen, dieselbe Version wie die Steuerebene zu verwenden. Wir empfehlen, den Pod-Zugriff auf das IMDS zu blockieren, wenn die folgenden Bedingungen erfüllt sind: + Sie planen, allen Ihren Kubernetes-Servicekonten IAM-Rollen zuzuweisen, damit Pods nur die Mindestberechtigungen haben, die sie benötigen. + Keine Pods im Cluster benötigen aus anderen Gründen Zugriff auf den Amazon EC2 EC2-Instance-Metadaten-Service (IMDS), z. B. zum Abrufen der aktuellen Region. AWS Weitere Informationen finden Sie unter [Beschränken Sie den Zugriff auf das Instance-Profil, das dem Worker-Knoten zugewiesen ist](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). Um den Pod-Zugriff auf IMDS zu blockieren, fügen Sie dem folgenden Befehl die Option `--disable-pod-imds` hinzu. **Anmerkung** Weitere verfügbare Flags und deren Beschreibungen finden Sie unterhttps://eksctl.io/. ``` eksctl create nodegroup \ --cluster my-cluster \ --version 1.35 \ --name standard-nodes-new \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false ``` 1. Wenn der vorherige Befehl abgeschlossen ist, bestätigen Sie mit folgendem Befehl, dass alle Ihre Worker-Knoten den `Ready`-Status erreicht haben: ``` kubectl get nodes ``` 1. Löschen Sie die ursprüngliche Knotengruppe mit dem folgenden Befehl. Ersetzen Sie im Befehl alle *example value* mit Ihren Cluster- und Knotengruppennamen: ``` eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old ``` ## AWS-Managementkonsole und AWS CLI **Migrieren Sie Ihre Anwendungen mit der AWS-Managementkonsole und AWS CLI auf eine neue Knotengruppe** 1. Starten Sie eine neue Knotengruppe, indem Sie die unter [Erstellen selbstverwalteter Amazon Linux-Knoten](launch-workers.md) beschriebenen Schritte befolgen. 1. Wenn Ihr Stack fertig erstellt wurde, wählen Sie ihn in der Konsole aus und klicken Sie auf **Outputs** (Ausgaben). 1. Notieren Sie das **NodeInstanceRole**für die Knotengruppe, die erstellt wurde. Sie benötigen diese Informationen zum Hinzufügen der neuen Amazon EKS-Knoten zu Ihrem Cluster. **Anmerkung** Wenn Sie der IAM-Rolle Ihrer alten Knotengruppen zusätzliche IAM-Richtlinien angefügt haben, dann sollten Sie die gleichen Richtlinien auch der IAM-Rolle Ihrer neuen Knotengruppe zuweisen, um diese Funktionalität für die neue Gruppe zu erhalten. Dies gilt für Sie, wenn Sie beispielsweise Berechtigungen für den Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) hinzugefügt haben. 1. Aktualisieren Sie die Sicherheitsgruppen für beide Worker-Knoten-Gruppen, sodass sie miteinander kommunizieren können. Weitere Informationen finden Sie unter [Anforderungen der Amazon-EKS-Sicherheitsgruppe für Cluster anzeigen](sec-group-reqs.md). 1. Notieren Sie die Sicherheitsgruppe IDs für beide Knotengruppen. Dies wird als **NodeSecurityGroup**Wert in den AWS CloudFormation Stack-Ausgaben angezeigt. Sie können die folgenden AWS CLI-Befehle verwenden, um die Sicherheitsgruppe IDs aus den Stack-Namen abzurufen. In diesen Befehlen `oldNodes` steht der AWS CloudFormation Stack-Name für Ihren älteren Knoten-Stack und `newNodes` der Name des Stacks, zu dem Sie migrieren. Ersetzen Sie jede *example value* durch Ihre eigenen Werte. ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) ``` 1. Fügen Sie Regeln für eingehenden Datenverkehr für jede Worker-Knoten-Sicherheitsgruppe hinzu, sodass sie voneinander Datenverkehr annehmen können. Die folgenden AWS CLI-Befehle fügen jeder Sicherheitsgruppe Regeln für eingehenden Datenverkehr hinzu, die den gesamten Datenverkehr auf allen Protokollen der anderen Sicherheitsgruppe zulassen. Auf diese Weise können Pods in jeder Knoten-Gruppe miteinander kommunizieren, während Sie Ihr Workload zur neuen Gruppe migrieren. ``` aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 authorize-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. Bearbeiten Sie die `aws-auth`-configmap, um die neue Worker-Knoten-Instance-Rolle in RBAC zuzuordnen. ``` kubectl edit configmap -n kube-system aws-auth ``` Fügen Sie einen neuen `mapRoles`-Eintrag für die neue Worker-Knoten-Gruppe hinzu. ``` apiVersion: v1 data: mapRoles: | - rolearn: ARN of instance role (not instance profile) username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> - rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes ``` [Ersetzen Sie das *ARN of instance role (not instance profile)* Snippet durch den **NodeInstanceRole**Wert, den Sie in einem vorherigen Schritt aufgezeichnet haben.](#node-instance-role-step) Speichern und schließen Sie dann die Datei, um die aktualisierte configmap anzuwenden. 1. Achten Sie auf den Status Ihrer Knoten und warten Sie, bis Ihre neuen Worker-Knoten Ihrem Cluster beigetreten sind und den Status `Ready` angenommen haben. ``` kubectl get nodes --watch ``` 1. (Optional) Wenn Sie [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) verwenden, skalieren Sie die Bereitstellung nach unten auf null (0) Replikate, um Konflikte zwischen Skalierungsaktionen zu vermeiden. ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. Verwenden Sie den folgenden Befehl, um jeden der Knoten, die Sie mit `NoSchedule` entfernen möchten, mit einem Taint zu versehen. Auf diese Weise werden neue Pods auf den Knoten, die Sie ersetzen, nicht geplant oder neu geplant. Weitere Informationen finden Sie unter [Taints und Toleranzen](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) in der Kubernetes-Dokumentation. ``` kubectl taint nodes node_name key=value:NoSchedule ``` Wenn Sie Ihre Knoten auf eine neue Kubernetes-Version aktualisieren, können Sie alle Knoten einer bestimmten Kubernetes-Version (in diesem Fall `1.33`) mit dem folgenden Code-Ausschnitt identifizieren und mit einem Taint versehen. Die Versionsnummer darf nicht höher als die Kubernetes-Version Ihrer Steuerebene sein. Sie darf auch nicht mehr als zwei Nebenversionen älter sein als die Kubernetes-Version Ihrer Steuerebene. Es wird empfohlen, dieselbe Version wie die Steuerebene zu verwenden. ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Tainting $node" kubectl taint nodes $node key=value:NoSchedule done ``` 1. Bestimmen Sie den DNS-Anbieter Ihres Clusters. ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` Eine Beispielausgabe sieht wie folgt aus. Dieser Cluster verwendet für die DNS-Auflösung, aber Ihr Cluster kann stattdessen `kube-dns` zurückgeben): ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. Wenn Ihre aktuelle Bereitstellung weniger als zwei Replikate ausführt, skalieren die Bereitstellung auf zwei Replikate. Ersetzen Sie `kubedns` durch *coredns*, falls Ihre vorherige Befehlsausgabe dies stattdessen zurückgegeben hat. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. Lassen Sie die einzelnen Knoten, die Sie aus Ihrem Cluster entfernen möchten, mit dem folgenden Befehl sperren: ``` kubectl drain node_name --ignore-daemonsets --delete-local-data ``` Wenn Sie Ihre Knoten auf eine neue Kubernetes-Version aktualisieren, identifizieren und löschen Sie alle Knoten einer bestimmten Kubernetes-Version (in diesem Fall*1.33*) mit dem folgenden Codeausschnitt. ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-local-data done ``` 1. Nachdem die alten Knoten entladen wurden, widerrufen Sie die Regeln für eingehenden Datenverkehr für Sicherheitsgruppen, die Sie zuvor autorisiert haben. Löschen Sie anschließend den Stack, um die Instanzen zu beenden AWS CloudFormation . **Anmerkung** Wenn Sie Ihrer alten Knotengruppen-IAM-Rolle zusätzliche IAM-Richtlinien hinzugefügt haben, z. B. das Hinzufügen von Berechtigungen für den [Kubernetes Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), trennen Sie diese zusätzlichen Richtlinien von der Rolle, bevor Sie Ihren Stack löschen können. AWS CloudFormation 1. Heben Sie die Regeln für eingehenden Datenverkehr auf, die Sie zuvor für die Knoten-Sicherheitsgruppen erstellt haben. In diesen Befehlen `oldNodes` steht der AWS CloudFormation Stack-Name für Ihren älteren Knoten-Stack und `newNodes` der Name des Stacks, zu dem Sie migrieren. ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 revoke-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. Öffnen Sie die [AWS CloudFormation -Konsole](https://console.aws.amazon.com/cloudformation/). 1. Wählen Sie Ihren alten Worker-Knoten-Stack aus. 1. Wählen Sie **Löschen** aus. 1. Wählen Sie im Bestätigungsdialogfeld **Stack löschen** **Stack löschen** aus. 1. Bearbeiten Sie die `aws-auth`-configmap, um die alten Worker-Knoten-Instance-Rolle aus RBAC zu entfernen. ``` kubectl edit configmap -n kube-system aws-auth ``` Löschen Sie den `mapRoles`-Eintrag für die alte Worker-Knoten-Gruppe. ``` apiVersion: v1 data: mapRoles: | - rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: arn:aws: iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> ``` Speichern und schließen Sie die Datei, um die aktualisierte configmap anzuwenden. 1. (Optional) Wenn Sie den Kubernetes-[Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) verwenden, skalieren Sie die Bereitstellung wieder auf ein Replikat. **Anmerkung** Außerdem müssen Sie Ihre neue Auto-Scaling-Gruppe (z. B. `k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster`) mit einem Tag versehen und den Befehl für die Cluster-Autoscaler-Bereitstellung so aktualisieren, dass er auf die neu getaggte Auto-Scaling-Gruppe verweist. Weitere Informationen finden Sie unter [Cluster Autoscaler on](https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws). AWS ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (Optional) Stellen Sie sicher, dass Sie die neueste Version des [Amazon-VPC-CNI-Plugins für Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) verwenden. Möglicherweise müssen Sie Ihre CNI-Version aktualisieren, um die neuesten unterstützten Instance-Typen zu nutzen. Weitere Informationen finden Sie unter [Pods mit dem Amazon VPC CNI zuweisen IPs](managing-vpc-cni.md). 1. Wenn Ihr Cluster `kube-dns` für die DNS-Auflösung verwendet (siehe [[migrate-determine-dns-step]](#migrate-determine-dns-step)), skalieren Sie in der `kube-dns`-Bereitstellung auf ein Replikat. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` # Einen AWS CloudFormation Knotenstapel aktualisieren In diesem Thema wird beschrieben, wie Sie einen vorhandenen AWS CloudFormation selbstverwalteten Knotenstapel mit einem neuen AMI aktualisieren können. Sie können diese Anleitung verwenden, um Ihre Knoten nach einer Cluster-Aktualisierung auf eine neue Version von Kubernetes zu aktualisieren. Andernfalls können Sie auf das neueste von Amazon EKS optimierte AMI für eine vorhandene Kubernetes-Version aktualisieren. **Wichtig** In diesem Thema werden Worker-Knotenaktualisierungen für selbstverwaltete Knotengruppen behandelt. Informationen zur Verwendung des [Vereinfachten Knoten-Lebenszyklus mit verwalteten Knotengruppen](managed-node-groups.md) finden Sie unter [Eine verwaltete Knotengruppe für Ihren Cluster aktualisieren](update-managed-node-group.md). Die neueste Amazon AWS CloudFormation EKS-Standardknotenvorlage ist so konfiguriert, dass eine Instance mit dem neuen AMI in Ihrem Cluster gestartet wird, bevor nacheinander eine alte entfernt wird. Diese Konfiguration stellt sicher, dass Sie immer über die gewünschte Anzahl der aktiven Instances Ihre Auto-Scaling-Gruppe in Ihrem Cluster verfügen, während die Aktualisierung durchgeführt wird. **Anmerkung** Diese Methode wird nicht bei Knoten-Gruppen unterstützt, die mit `eksctl` erstellt wurden. Wenn Sie Ihr Cluster oder Ihre Worker-Knoten-Gruppe Sie `eksctl` erstellt haben, finden Sie Informationen unter [Anwendungen zu einer neuen Knotengruppe migrieren](migrate-stack.md). 1. Bestimmen Sie den DNS-Anbieter Ihres Clusters. ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` Eine Beispielausgabe sieht wie folgt aus. Dieser Cluster verwendet CoreDNS für die DNS-Auflösung, aber Ihr Cluster kann stattdessen `kube-dns` zurückgeben. Ihre Ausgabe kann je nach verwendeter `kubectl`-Version anders aussehen. ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. Wenn Ihre aktuelle Bereitstellung weniger als zwei Replikate ausführt, skalieren die Bereitstellung auf zwei Replikate. Ersetzen Sie `kube-dns` durch *coredns*, falls Ihre vorherige Befehlsausgabe dies stattdessen zurückgegeben hat. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. (Optional) Wenn Sie Kubernetes [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) verwenden, skalieren Sie die Bereitstellung nach unten auf null (0) Replikate, um Konflikte zwischen Skalierungsaktionen zu vermeiden. ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. Bestimmen Sie den gewünschten Instance-Typ und die gewünschte Anzahl von Instances Ihrer aktuellen Knotengruppe. Sie geben diese Werte später ein, wenn Sie die AWS CloudFormation Vorlage für die Gruppe aktualisieren. 1. Öffnen Sie die Amazon EC2 EC2-Konsole unter https://console.aws.amazon.com/ec2/. 1. Wählen Sie im linken Navigationsbereich **Launch Configurations** (Startkonfigurationen) aus und beachten Sie den Instance-Typ für die Startkonfiguration der vorhandenen Knoten. 1. Wählen Sie im linken Navigationsbereich **Auto Scaling Groups** (Auto-Scaling-Gruppen) aus und beachten Sie die **Desired** (gewünschte) Instance-Anzahl für die Auto-Scaling-Gruppe der vorhandenen Knoten. 1. Öffnen Sie die [AWS CloudFormation -Konsole](https://console.aws.amazon.com/cloudformation/). 1. Wählen Sie Ihren Workerknoten-Gruppen-Stack aus und klicken Sie dann auf **Update (Aktualisieren)**. 1. Wählen Sie **Replace current template (Aktuelle Vorlage ersetzen)** und dann **Amazon S3 URL (Amazon S3-URL)** aus. 1. Fügen Sie für **Amazon S3 S3-URL** die folgende URL in den Textbereich ein, um sicherzustellen, dass Sie die neueste Version der AWS CloudFormation Node-Vorlage verwenden. Klicken Sie dann auf **Next (Weiter)**: ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml ``` 1. Geben Sie auf der Seite **Specify stack details (Stack-Details angeben)** die folgenden Parameter ein und wählen Sie **Next (Weiter)** aus: + **NodeAutoScalingGroupDesiredCapacity**— Geben Sie die gewünschte Anzahl von Instanzen ein, die Sie in einem [vorherigen Schritt](#existing-worker-settings-step) aufgezeichnet haben. Oder geben Sie die neue gewünschte Anzahl von Knoten ein, auf die bei der Aktualisierung Ihres Stacks skaliert werden soll. + **NodeAutoScalingGroupMaxSize**— Geben Sie die maximale Anzahl von Knoten ein, auf die Ihre Node-Auto-Scaling-Gruppe skalieren kann. Dieser Wert muss mindestens einen Knoten größer sein als Ihre gewünschte Kapazität. Auf diese Weise können Sie eine fortlaufende Aktualisierung Ihrer Knoten durchführen, ohne die Knotenanzahl während der Aktualisierung zu reduzieren. + **NodeInstanceType**— Wählen Sie den Instance-Typ, den Sie in einem [vorherigen Schritt](#existing-worker-settings-step) aufgezeichnet haben. Wählen Sie alternativ einen anderen Instance-Typ für Ihre Knoten aus. Bevor Sie sich für einen anderen Instance-Typ entscheiden, lesen Sie den Abschnitt [Auswahl eines optimalen Knoten-Instance-Typs für Amazon EC2](choosing-instance-type.md). Jeder Amazon-EC2-Instance-Typ unterstützt eine maximale Anzahl von Elastic-Network-Interfaces (ENIs) und jedes ENI unterstützt eine maximale Anzahl von IP-Adressen. Da jedem Worker-Knoten und Pod eine eigene IP-Adresse zugewiesen wird, ist es wichtig, einen Instance-Typ auszuwählen, der die maximale Anzahl von Pods unterstützt, die Sie auf jedem Amazon-EC2-Knoten ausführen möchten. Eine Liste der Netzwerkschnittstellen und IP-Adressen, die von Instance-Typen unterstützt werden, finden Sie unter [IP-Adressen pro Netzwerkschnittstelle pro Instance-Typ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI). Der Instance–Typ `m5.large` unterstützt zum Beispiel maximal 30 IP-Adressen für den Worker-Knoten und die Pods. **Anmerkung** Die unterstützten Instance-Typen für die neueste Version des [Amazon-VPC-CNI-Plugins für Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) sind in [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) auf GitHub aufgeführt. Möglicherweise müssen Sie Ihr Amazon-VPC-CNI-Plugin für die Kubernetes-Version aktualisieren, um die neuesten unterstützten Instance-Typen zu verwenden. Weitere Informationen finden Sie unter [Pods mit dem Amazon VPC CNI zuweisen IPs](managing-vpc-cni.md). **Wichtig** Einige Instance-Typen sind möglicherweise nicht in allen AWS Regionen verfügbar. + **NodeImageIdSSMParam**— Der Amazon EC2 Systems Manager Manager-Parameter der AMI-ID, auf die Sie aktualisieren möchten. Der folgende Wert verwendet das neueste Amazon-EKS-optimierte AMI für Kubernetes-Version `1.35`. ``` /aws/service/eks/optimized-ami/1.35/amazon-linux-2/recommended/image_id ``` Sie können es durch eine [Plattformversion *1.35* ersetzen, die identisch](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) ist. Oder er sollte bis zu einer Version älter sein als die Kubernetes-Version, die auf Ihrer Steuerebene läuft. Es wird empfohlen, die Knoten auf der gleichen Version wie die Steuerungsebene zu halten. Sie können es auch *amazon-linux-2* durch einen anderen AMI-Typ ersetzen. Weitere Informationen finden Sie unter [Rufen Sie das empfohlene Amazon Linux AMI ab IDs](retrieve-ami-id.md). **Anmerkung** Mit dem Amazon-EC2-Systems-Manager-Parameter können Sie Ihre Worker-Knoten in Zukunft aktualisieren, ohne eine AMI-ID suchen und angeben zu müssen. Wenn Ihr AWS CloudFormation Stack diesen Wert verwendet, startet jedes Stack-Update immer das neueste empfohlene Amazon EKS-optimierte AMI für Ihre angegebene Kubernetes-Version. Dies ist auch dann der Fall, wenn Sie keine Werte in der Vorlage ändern. + **NodeImageId**— Um Ihr eigenes benutzerdefiniertes AMI zu verwenden, geben Sie die ID ein, die das AMI verwenden soll. **Wichtig** Dieser Wert überschreibt jeden Wert, der für **NodeImageIdSSMParam**angegeben wurde. Wenn Sie den **NodeImageIdSSMParam**Wert verwenden möchten, stellen Sie sicher, dass der Wert für leer **NodeImageId**ist. + **Deaktivieren IMDSv1** — Standardmäßig unterstützt jeder Knoten den Instanz-Metadatendienst Version 1 (IMDSv1) und IMDSv2. Sie können ihn jedoch deaktivieren IMDSv1. Wählen Sie **true** aus, wenn Sie nicht möchten, dass in der Knotengruppe geplante Knoten oder Pods verwendet IMDSv1 werden. Weitere Informationen finden Sie unter [Konfiguration des Instance-Metadatenservice](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Wenn Sie IAM-Rollen für Dienstkonten implementiert haben, weisen Sie allen Pods, die Zugriff auf AWS Dienste benötigen, die erforderlichen Berechtigungen direkt zu. Auf diese Weise benötigen keine Pods in Ihrem Cluster Zugriff auf IMDS aus anderen Gründen, z. B. zum Abrufen der aktuellen Region. AWS Anschließend können Sie den Zugriff auf auch IMDSv2 für Pods deaktivieren, die kein Host-Netzwerk verwenden. Weitere Informationen finden Sie unter [Beschränken Sie den Zugriff auf das Instance-Profil, das dem Worker-Knoten zugewiesen ist](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). 1. (Optional) Markieren Sie auf der Seite **Options (Optionen)** Ihre Stack-Ressourcen. Wählen Sie **Weiter** aus. 1. Überprüfen Sie Ihre Angaben auf der Seite **Review** (Überprüfen), bestätigen Sie, dass der Stack IAM-Ressourcen erstellen kann, und klicken Sie dann auf **Update stack** (Stack aktualisieren). **Anmerkung** Die Aktualisierung jedes Knotens im Cluster dauert mehrere Minuten. Warten Sie, bis die Aktualisierung aller Knoten abgeschlossen ist, bevor Sie die nächsten Schritte durchführen. 1. Wenn der DNS-Anbieter Ihres Clusters `kube-dns` ist, skalieren Sie die `kube-dns`-Bereitstellung auf ein Replikat. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` 1. (Optional) Wenn Sie den Kubernetes-[Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) verwenden, skalieren Sie die Bereitstellung zurück auf die gewünschte Zahl von Replikaten. ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (Optional) Stellen Sie sicher, dass Sie die neueste Version des [Amazon-VPC-CNI-Plugins für Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) verwenden. Möglicherweise müssen Sie Ihr Amazon-VPC-CNI-Plugin für die Kubernetes-Version aktualisieren, um die neuesten unterstützten Instance-Typen zu verwenden. Weitere Informationen finden Sie unter [Pods mit dem Amazon VPC CNI zuweisen IPs](managing-vpc-cni.md). # Vereinfachung der Rechenverwaltung mit AWS Fargate In diesem Thema wird die Verwendung von Amazon EKS zum Ausführen von Kubernetes-Pods in AWS Fargate erläutert. Fargate ist eine Technologie, die bedarfsgerechte On-Demand-Rechenkapazität für [Container](https://aws.amazon.com/what-are-containers) bereitstellt. Mit Fargate müssen Sie keine Gruppen virtueller Maschinen selbst bereitstellen, konfigurieren oder skalieren, um Container auszuführen. Sie müssen auch keine Servertypen auswählen, entscheiden, wann Sie Ihre Knotengruppen skalieren oder die Cluster-Zusammenstellung optimieren. Sie können steuern, welche Pods in Fargate starten und wie sie mit [Fargate-Profilen](fargate-profile.md) ausgeführt werden. Fargate-Profile werden als Teil Ihres Amazon-EKS-Clusters definiert. Amazon EKS wird in Kubernetes mit Fargate integriert, indem Controller verwendet werden, die von AWS mithilfe des Upstream-Erweiterungsmodells von Kubernetes erstellt werden. Diese Controller werden als Teil der von Amazon EKS verwalteten Kubernetes-Steuerebene ausgeführt und sind für die Planung nativer Kubernetes-Pods in Fargate verantwortlich. Die Fargate-Controller enthalten einen neuen Scheduler, der neben dem Standard-Kubernetes-Scheduler und zusätzlich zu mehreren mutierenden und validierenden Zugangscontrollern ausgeführt wird. Wenn Sie einen Pod starten, der die Kriterien für die Ausführung in Fargate erfüllt, erkennen die Fargate-Controller, die im Cluster ausgeführt werden den Pod, und aktualisieren und planen ihn in Fargate. In diesem Thema werden die verschiedenen Komponenten von Pods beschrieben, die in Fargate ausgeführt werden, und auf besondere Überlegungen für die Verwendung von Fargate mit Amazon EKS hingewiesen. ## Überlegungen zu AWS-Fargate Hier sind einige Dinge, die Sie bei der Verwendung von Fargate auf Amazon EKS beachten sollten. + Jeder Pod, der in Fargate ausgeführt wird, verfügt über eine eigene Rechengrenze. Sie teilen sich weder den zugrunde liegenden Kernel noch CPU-Ressourcen, Speicherressourcen oder elastische Netzwerkschnittstellen mit anderen Pods. + Network Load Balancer und Application Load Balancer (ALBs) können mit Fargate nur mit IP-Zielen verwendet werden. Weitere Informationen erhalten Sie unter [Erstellen eines Network Load Balancers](network-load-balancing.md#network-load-balancer) und [Anwendungen und HTTP-Datenverkehr mit Application Load Balancers weiterleiten](alb-ingress.md). + Fargate-exponierte Services werden nur im IP-Modus des Zieltyps und nicht im Knoten-IP-Modus ausgeführt. Die empfohlene Möglichkeit, die Konnektivität von einem Service zu überprüfen, der auf einem verwalteten Knoten ausgeführt wird, und einem Service, der auf Fargate ausgeführt wird, besteht darin, eine Verbindung über den Servicenamen herzustellen. + Pods müssen zu dem Zeitpunkt, zu dem sie in Fargate ausgeführt werden sollen, mit einem Fargate-Profil übereinstimmen. Pods, die nicht mit einem Fargate-Profil übereinstimmen, können als `Pending` hängen bleiben. Wenn ein übereinstimmendes Fargate-Profil vorhanden ist, können Sie ausstehende Pods, die Sie erstellt haben, löschen, um sie in Fargate neu zu planen. + Daemonsets werden von Fargate nicht unterstützt. Wenn Ihre Anwendung einen Daemon benötigt, konfigurieren Sie diesen Daemon neu, sodass er als Sidecar-Container in Ihren Pods ausgeführt wird. + Privilegierte Container werden in Fargate nicht unterstützt. + Pods, die in Fargate ausgeführt werden, können im Pod-Manifest kein `HostPort` oder `HostNetwork` angeben. + Das standardmäßige weiche `nofile`- und `nproc`-Limit beträgt 1 024 und das harte Limit 65 535 für Fargate-Pods. + GPUs sind derzeit in Fargate nicht verfügbar. + Pods, die in Fargate ausgeführt werden, werden nur in privaten Subnetzen unterstützt (mit NAT Gateway-Zugriff auf AWS-Services, aber ohne direkte Route zu einem Internet-Gateway). Daher müssen für die VPC Ihres Clusters private Subnetze verfügbar sein. Weitere Informationen zu Clustern ohne ausgehenden Internetzugang finden Sie unter [Bereitstellung privater Cluster mit eingeschränktem Internetzugang](private-clusters.md). + Sie können die Option [Pod-Ressourcen mit Vertical Pod Autoscaler anpassen](vertical-pod-autoscaler.md) verwenden, um die anfängliche korrekte Größe von CPU und Arbeitsspeicher für Ihre Fargate-Pods festzulegen, und anschließend die Option [Pod-Bereitstellungen mit Horizontal Pod Autoscaler skalieren](horizontal-pod-autoscaler.md) verwenden, um diese Pods zu skalieren. Wenn Sie möchten, dass der Vertical Pod Autoscaler Pods mit größeren CPU- und Speicherkombinationen automatisch erneut in Fargate bereitstellt, stellen Sie den Modus für den Vertical Pod Autoscaler entweder auf `Auto` oder `Recreate` ein, um die korrekte Funktionalität sicherzustellen. Weitere Informationen finden Sie in der [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start)-Dokumentation auf GitHub. + DNS-Auflösung und DNS-Hostnamen müssen für Ihre VPC aktiviert sein. Weitere Informationen finden Sie unter [Anzeigen und Aktualisieren der DNS-Unterstützung für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating). + Amazon-EKS-Fargate erweitert die Verteidigung für Kubernetes-Anwendungen, indem jeder Pod innerhalb einer virtuellen Maschine (VM) isoliert wird. Diese VM-Grenze verhindert den Zugriff auf hostbasierte Ressourcen, die von anderen Pods im Falle eines Container-Escapes verwendet werden. Dies ist eine übliche Methode, um containerisierte Anwendungen anzugreifen und Zugriff auf Ressourcen außerhalb des Containers zu erhalten. Die Verwendung von Amazon EKS ändert nichts an Ihren Verantwortlichkeiten im Rahmen des [Modells der geteilten Verantwortung](security.md). Sie sollten die Konfiguration von Cluster-Sicherheits- und Governance-Kontrollen sorgfältig prüfen. Der sicherste Weg, eine Anwendung zu isolieren, besteht immer darin, sie in einem separaten Cluster auszuführen. + Fargate-Profile unterstützen die Angabe von Subnetzen aus sekundären VPC-CIDR-Blöcken. Möglicherweise möchten Sie einen sekundären CIDR-Block angeben. Das liegt daran, dass in einem Subnetz nur eine begrenzte Anzahl von IP-Adressen verfügbar ist. Daher gibt es auch eine begrenzte Anzahl von Pods, die im Cluster erstellt werden können. Durch die Verwendung verschiedener Subnetze für Pods können Sie die Anzahl der verfügbaren IP-Adressen erhöhen. Weitere Informationen finden Sie unter [Hinzufügen von IPv4 CIDR-Blöcken zu einer VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-resize). + Amazon EC2 Instance Metadata Service (IMDS) ist für Pods, die auf Fargate-Knoten bereitgestellt werden, nicht verfügbar. Wenn Sie Pods haben, die in Fargate bereitgestellt werden und IAM-Anmeldeinformationen erfordern, weisen Sie diese Ihren Pods mithilfe von [IAM-Rollen für Servicekonten](iam-roles-for-service-accounts.md) zu. Wenn Ihre Pods Zugriff auf andere Informationen benötigen, die über das IMDS verfügbar sind, müssen Sie diese Informationen in Ihre Pod-Spezifikation hart codieren. Dies umfasst die AWS-Region oder Availability Zone, in der ein Pod bereitgestellt wird. + Sie können Fargate-Pods nicht in AWS Outposts, AWS Wavelength oder AWS Local Zones bereitstellen. + Amazon EKS muss Fargate-Pods regelmäßig patchen, um deren Sicherheit zu gewährleisten. Wir versuchen, die Auswirkungen von Aktualisierungen möglichst gering zu halten. Es kann jedoch vorkommen, dass Pods gelöscht werden müssen, wenn sie nicht erfolgreich bereinigt wurden. Es gibt einige Maßnahmen, die Sie durchführen können, um Unterbrechungen zu minimieren. Weitere Informationen finden Sie unter [Festlegung von Maßnahmen für Betriebssystem-Patching-Ereignisse für AWS Fargate](fargate-pod-patching.md). + Das [Amazon-VPC-CNI-Plugin für Amazon EKS](https://github.com/aws/amazon-vpc-cni-plugins) ist standardmäßig auf Fargate-Knoten installiert. Sie können keine [Alternativen CNI-Plugins für Amazon-EKS-Cluster](alternate-cni-plugins.md) mit Fargate-Knoten verwenden. + Ein in Fargate ausgeführter Pod bindet automatisch ein Amazon-EFS-Dateisystem ein, ohne dass manuelle Schritte zur Treiberinstallation erforderlich sind. Sie können mit Fargate-Knoten keine dynamische Bereitstellung persistenter Volumes verwenden, aber Sie können eine statische Bereitstellung verwenden. + Amazon EKS unterstützt Fargate Spot nicht. + Sie können Amazon-EBS-Volumes nicht in Fargate-Pods mounten. + Sie können den Amazon-EBS-CSI-Controller in Fargate-Knoten ausführen, aber der Amazon-EBS-CSI-Knoten-DaemonSet kann nur in Amazon-EC2-Instances ausgeführt werden. + Nachdem ein [Kubernetes-Auftrag](https://kubernetes.io/docs/concepts/workloads/controllers/job/) als `Completed` oder `Failed` gekennzeichnet wurde, existieren die vom Auftrag erstellten Pods normalerweise weiter. Durch dieses Verhalten können Sie die Protokolle und Ergebnisse anzeigen. Bei Fargate entstehen jedoch Kosten, wenn Sie den Auftrag nachher nicht bereinigen. Um die zugehörigen Pods automatisch zu löschen, nachdem ein Auftrag abgeschlossen wurde oder fehlgeschlagen ist, können Sie mithilfe des TTL-Controllers (Time-to-Live) einen Zeitraum angeben. Das folgende Beispiel veranschaulicht die Angabe von `.spec.ttlSecondsAfterFinished` im Auftrags-Manifest. ``` apiVersion: batch/v1 kind: Job metadata: name: busybox spec: template: spec: containers: - name: busybox image: busybox command: ["/bin/sh", "-c", "sleep 10"] restartPolicy: Never ttlSecondsAfterFinished: 60 # <-- TTL controller ``` ## Fargate-Vergleichstabelle | Kriterien | AWS-Fargate | | --- | --- | | Kann in [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) bereitgestellt werden | Nein | | Kann auf eine [AWS Lokale Zone](local-zones.md) bereitgestellt werden | Nein | | Kann Container ausführen, die Windows benötigen | Nein | | Kann Container ausführen, die Linux benötigen | Ja | | Kann Workloads ausführen, die den Inferentia-Chip benötigen | Nein | | Kann Workloads ausführen, die eine GPU benötigen | Nein | | Kann Workloads ausführen, die Arm-Prozessoren benötigen | Nein | | Kann ausgeführt werdenAWS [Bottlerocket](https://aws.amazon.com/bottlerocket/) | Nein | | Pods teilen eine Kernel-Laufzeitumgebung mit anderen Pods | Nein – Jeder Pod hat einen bestimmten Kernel | | Pods teilen CPU, Arbeitsspeicher, Speicher und Netzwerkressourcen mit anderen Pods. | Nein – Jeder Pod hat bestimmte Ressourcen und kann unabhängig voneinander dimensioniert werden, um die Ressourcenauslastung zu maximieren. | | Pods können mehr Hardware und Speicher verwenden, als in den Pod-Spezifikationen angefordert | Nein – Der Pod kann jedoch mit einer größeren vCPU und Speicherkonfiguration erneut bereitgestellt werden. | | Bereitstellen und Verwalten von Amazon-EC2-Instances | Nein | | Das Betriebssystem von Amazon-EC2-Instances muss gesichert, gewartet und gepatcht werden | Nein | | Kann Bootstrap-Argumente bei der Bereitstellung eines Knotens bereitstellen, z. B. zusätzliche [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)-Argumente. | Nein | | IP-Adressen können Pods aus einem anderen CIDR-Block als der dem Knoten zugewiesenen IP-Adresse zuweisen. | Nein | | SSH im Knoten nicht möglich | Nein – Es gibt kein Knoten-Host-Betriebssystem für SSH. | | Kann Ihr eigenes benutzerdefiniertes AMI auf Knoten bereitstellen | Nein | | Kann Ihr eigenes benutzerdefiniertes CNI auf Knoten bereitstellen | Nein | | Knoten-AMI muss selbst aktualisiert werden | Nein | | Muss die Kubernetes-Version des Knotens selbst aktualisieren | Nein – Sie verwalten keine Knoten. | | Kann Amazon-EBS-Speicher mit Pods verwenden | Nein | | Kann Amazon-EFS-Speicher mit Pods verwenden | [Ja](efs-csi.md) | | Kann Amazon FSx für Lustre Speicher mit Pods verwenden | Nein | | Kann Network Load Balancer für Services verwenden | Ja, bei Verwendung der Option [Network Load-Balancer erstellen](network-load-balancing.md#network-load-balancer) | | Pods können in einem öffentlichen Subnetz ausgeführt werden | Nein | | Kann einzelnen Pods verschiedene VPC-Sicherheitsgruppen zuweisen | Ja | | Kann Kubernetes DaemonSets ausführen | Nein | | Unterstützung für `HostPort` und `HostNetwork` im Pod-Manifest | Nein | | AWS-Verfügbarkeit in Regionen | [Einige von Amazon EKS unterstützte Regionen](https://docs.aws.amazon.com/general/latest/gr/eks.html) | | Kann Container auf Amazon-EC2-Dedicated-Hosts ausführen | Nein | | Preise | Kosten für eine individuelle Fargate-Speicher- und CPU-Konfiguration. Jeder Pod hat seine eigenen Kosten. Weitere Informationen dazu finden Sie unter [AWS-Fargate-Preise](https://aws.amazon.com/fargate/pricing/). | # Beginnen Sie mit AWS Fargate für Ihren Cluster In diesem Thema werden die ersten Schritte zum Ausführen von Pods auf AWS Fargate mit Ihrem Amazon EKS-Cluster beschrieben. Wenn Sie den Zugriff auf den öffentlichen Endpunkt Ihres Clusters mithilfe von CIDR-Blöcken einschränken, empfehlen wir, dass Sie auch den privaten Endpunktzugriff aktivieren. Auf diese Weise können Fargate-Pods mit dem Cluster kommunizieren. Wenn der private Endpunkt nicht aktiviert ist, müssen die CIDR-Blöcke, die Sie für den öffentlichen Zugriff angeben, die Ausgangsquellen aus Ihrer VPC enthalten. Weitere Informationen finden Sie unter [Cluster-API-Server-Endpunkt](cluster-endpoint.md). **Voraussetzung** Einen vorhandenen -Cluster. Wenn Sie noch über keinen Amazon-EKS-Cluster verfügen, lesen Sie [Erste Schritte mit Amazon EKS](getting-started.md). ## Schritt 1: Sicherstellen, dass vorhandene Knoten mit Fargate-Pods kommunizieren können Wenn Sie mit einem neuen Cluster ohne Knoten oder einem Cluster nur mit verwalteten Knotengruppen arbeiten (siehe [Vereinfachung des Knotenlebenszyklus mit verwalteten Knotengruppen](managed-node-groups.md)), können Sie mit [Schritt 2: Fargate-Pod-Ausführungsrolle erstellen](#fargate-sg-pod-execution-role) fortfahren. Angenommen, Sie arbeiten mit einem vorhandenen Cluster, dem bereits Knoten zugeordnet sind. Stellen Sie sicher, dass die Pods auf diesen Knoten problemlos mit den Pods kommunizieren können, die in Fargate ausgeführt werden. Pods, die in Fargate ausgeführt werden, werden automatisch so konfiguriert, dass die Cluster-Sicherheitsgruppe für den Cluster verwendet wird, dem sie zugeordnet sind. Stellen Sie sicher, dass alle vorhandenen Knoten in Ihrem Cluster Datenverkehr an die Cluster-Sicherheitsgruppe senden und von dieser empfangen können. Verwaltete Knotengruppen werden automatisch so konfiguriert, dass sie auch die Cluster-Sicherheitsgruppe verwenden. Sie müssen sie also nicht ändern oder auf Kompatibilität prüfen (siehe [Vereinfachung des Knotenlebenszyklus mit verwalteten Knotengruppen](managed-node-groups.md)). Für bestehende Knotengruppen, die mit `eksctl` oder den von Amazon EKS verwalteten AWS CloudFormation Vorlagen erstellt wurden, können Sie die Cluster-Sicherheitsgruppe manuell zu den Knoten hinzufügen. Alternativ können Sie die Auto-Scaling-Gruppestartvorlage für die Knotengruppe ändern, um die Cluster-Sicherheitsgruppe an die Instances anzuhängen. Weitere Informationen finden Sie unter [Ändern der Sicherheitsgruppen einer Instance](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SG_Changing_Group_Membership) im *Amazon-VPC-Benutzerhandbuch*. Sie können im Abschnitt **Netzwerk** für den Cluster AWS-Managementkonsole nach einer Sicherheitsgruppe für Ihren Cluster suchen. Oder Sie können dies mit dem folgenden AWS CLI-Befehl tun. Wenn Sie diesen Befehl verwenden, ersetzen Sie `` durch den Namen Ihres Clusters. ``` aws eks describe-cluster --name --query cluster.resourcesVpcConfig.clusterSecurityGroupId ``` ## Schritt 2: Fargate-Pod-Ausführungsrolle erstellen Wenn Ihr Cluster Pods auf AWS Fargate erstellt, müssen die Komponenten, die auf der Fargate-Infrastruktur ausgeführt werden, in AWS APIs Ihrem Namen Aufrufe tätigen. Die Amazon-EKS-Pod-Ausführungsrolle stellt die entsprechenden IAM-Berechtigungen bereit. Informationen zum Erstellen einer AWS Fargate-Pod-Ausführungsrolle finden Sie unter[IAM-Rolle für die Ausführung von Amazon-EKS-Pods](pod-execution-role.md). **Anmerkung** Wenn Sie den Cluster mithilfe von `eksctl` und der `--fargate`-Option erstellt haben, verfügt der Cluster bereits über eine Pod-Ausführungsrolle, die Sie in der IAM-Konsole mit dem Muster `eksctl-my-cluster-FargatePodExecutionRole-ABCDEFGHIJKL` finden können. Wenn Sie Ihre Fargate-Profile mit `eksctl` anlegen, erstellt `eksctl` Ihre Pod-Ausführungsrolle, sofern noch keine erstellt wurde. ## Schritt 3: Fargate Profil für Ihren Cluster erstellen Bevor Sie Pods planen können, die in Fargate in Ihrem Cluster ausgeführt werden, müssen Sie ein Fargate-Profil definieren, das angibt, welche Pods Fargate beim Start verwenden soll. Weitere Informationen finden Sie unter [Festlegung, welche Pods beim Start AWS Fargate verwenden](fargate-profile.md). **Anmerkung** Wenn Sie Ihren Cluster mithilfe von `eksctl` und der Option `--fargate` erstellt haben, wurde bereits ein Fargate-Profil für Ihren Cluster mit Selektoren für alle Pods in den `kube-system`- und `default`-Namespaces erstellt. Gehen Sie wie folgt vor, um Fargate-Profile für alle anderen Namespaces zu erstellen, die Sie mit Fargate verwenden möchten. Sie können mit einem dieser Tools ein Fargate-Profil erstellen: + [`eksctl`](#eksctl_fargate_profile_create) + [AWS-Managementkonsole](#console_fargate_profile_create) ### `eksctl` 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). **So erstellen Sie ein Fargate-Profil mit `eksctl`** Erstellen Sie Ihr Fargate-Profil mit dem folgenden `eksctl`-Befehl und ersetzen Sie jede `` durch Ihre eigenen Werte. Sie müssen einen Namespace angeben. Die Option `--labels` ist jedoch nicht erforderlich. ``` eksctl create fargateprofile \ --cluster \ --name \ --namespace \ --labels ``` Sie können bestimmte Platzhalter für ``- und ``-Labels verwenden. Weitere Informationen finden Sie unter [Platzhalter für Fargate-Profile](fargate-profile.md#fargate-profile-wildcards). ### AWS-Managementkonsole **So erstellen Sie ein Fargate-Profil mit AWS-Managementkonsole ** 1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters). 1. Wählen Sie den Cluster aus, für den Sie ein Fargate-Profil erstellen möchten. 1. Wählen Sie die Registerkarte **Compute** (Datenverarbeitung) aus. 1. Wählen Sie unter **Fargate-Profile** die Option **Fargate-Profil hinzufügen** aus. 1. Auf der Seite **Konfigurieren des Fargate Profils** führen Sie folgende Schritte aus: 1. Geben Sie unter **Name** einen Namen für Ihr Fargate-Profil ein. Der Name muss eindeutig sein. 1. Wählen Sie für **Pod-Ausführungsrolle** die Pod-Ausführungsrolle aus, die mit Ihrem Fargate-Profil verwendet werden soll. Es werden nur IAM-Rollen mit dem `eks-fargate-pods.amazonaws.com`-Service-Prinzipal angezeigt. Wenn keine Rollen aufgelistet sind, müssen Sie eine erstellen. Weitere Informationen finden Sie unter [IAM-Rolle für die Ausführung von Amazon-EKS-Pods](pod-execution-role.md). 1. Ändern Sie die ausgewählten **Subnetze** nach Bedarf. **Anmerkung** Für Pods, die in Fargate ausgeführt werden, werden nur private Subnetze unterstützt. 1. Für **Tags** können Sie Ihr Fargate-Profil wahlweise markieren. Diese Tags werden nicht an andere Ressourcen weitergegeben, die dem Profil zugeordnet sind, z. B. Pods. 1. Wählen Sie **Weiter** aus. 1. Führen Sie auf der Seite **Pod-Auswahl konfigurieren** die folgenden Schritte aus: 1. Geben Sie für **Namespace** einen Namespace ein, der mit Pods übereinstimmt. + Sie können bestimmte Namespaces für den Abgleich verwenden, z. B. `kube-system` oder `default`. + Sie können bestimmte Platzhalter verwenden (z. B. `prod-*`), um mehrere Namespaces abzugleichen (z. B. `prod-deployment` und `prod-test`). Weitere Informationen finden Sie unter [Platzhalter für Fargate-Profile](fargate-profile.md#fargate-profile-wildcards). 1. (Optional) Fügen Sie dem Selektor Kubernetes-Markierungen hinzu. Fügen Sie sie insbesondere demjenigen hinzu, dem die Pods im angegebenen Namespace entsprechen müssen. + Sie können dem Selektor das Label `infrastructure: fargate` hinzufügen, sodass nur Pods im angegebenen Namespace, die ebenfalls die `infrastructure: fargate`-Kubernetes-Bezeichnung tragen, mit dem Selektor übereinstimmen. + Sie können bestimmte Platzhalter verwenden (z. B. `key?: value?`), um mehrere Namespaces abzugleichen (z. B. `keya: valuea` und `keyb: valueb`). Weitere Informationen finden Sie unter [Platzhalter für Fargate-Profile](fargate-profile.md#fargate-profile-wildcards). 1. Wählen Sie **Weiter** aus. 1. Überprüfen Sie auf der Seite **Überprüfen und erstellen** die Informationen für Ihr -Profil und wählen Sie **Erstellen** aus. ## Schritt 4: CoreDNS aktualisieren Standardmäßig ist CoreDNS so konfiguriert, dass es auf der EC2 Amazon-Infrastruktur auf Amazon EKS-Clustern ausgeführt wird. Wenn Sie Ihre Pods *nur* in Fargate in Ihrem Cluster ausführen möchten, führen Sie die folgenden Schritte aus. **Anmerkung** Wenn Sie einen Cluster mit `eksctl` unter Verwendung von `--fargate`-Option erstellt haben, können Sie zu [Nächste Schritte](#fargate-gs-next-steps) springen. 1. Erstellen Sie jedes Fargate-Profil für CoreDNS mit dem folgenden Befehl. ``Ersetzen Sie es durch Ihren Clusternamen, `<111122223333>` durch Ihre Konto-ID, `` durch den Namen Ihrer Pod-Ausführungsrolle und `<000000000000000a>``<000000000000000b>`, und `<000000000000000c>` durch die IDs Ihrer privaten Subnetze. Wenn Sie über keine Pod-Ausführungsrolle verfügen, müssen Sie zuerst eine erstellen (siehe [Schritt 2: Fargate-Pod-Ausführungsrolle erstellen](#fargate-sg-pod-execution-role)). **Wichtig** Der Rollen-ARN darf als [Pfad](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names) nur `/` enthalten. Wenn der Name Ihrer Rolle also beispielsweise `development/apps/AmazonEKSFargatePodExecutionRole` lautet, müssen Sie ihn beim Angeben des ARN für die Rolle in `AmazonEKSFargatePodExecutionRole` ändern. Das Format des Rollen-ARN muss ` arn:aws: iam::<111122223333>:role/` sein. ``` aws eks create-fargate-profile \ --fargate-profile-name coredns \ --cluster-name \ --pod-execution-role-arn arn:aws: iam::<111122223333>:role/ \ --selectors namespace=kube-system,labels={k8s-app=kube-dns} \ --subnets subnet-<000000000000000a> subnet-<000000000000000b> subnet-<000000000000000c> ``` 1. Lösen Sie die Einführung der `coredns`-Bereitstellung aus. ``` kubectl rollout restart -n kube-system deployment coredns ``` ## Nächste Schritte + Mit dem folgenden Workflow können Sie mit der Migration Ihrer vorhandenen Anwendungen zum Ausführen in Fargate beginnen. 1. [Erstellen eines Fargate-Profils](fargate-profile.md#create-fargate-profile), das mit dem Kubernetes-Namespace und den Kubernetes-Labels Ihrer Anwendung übereinstimmt. 1. Löschen Sie alle vorhandenen Pods und erstellen Sie sie neu, damit sie auf Fargate geplant werden. Ändern Sie `` und ``, um Ihre spezifischen Pods zu aktualisieren. ``` kubectl rollout restart -n deployment ``` + Stellen Sie das [Anwendungen und HTTP-Datenverkehr mit Application Load Balancers weiterleiten](alb-ingress.md) bereit, um Eingangsobjekte für Ihre Pods zuzulassen, die auf Fargate ausgeführt werden. + Sie können [Pod-Ressourcen mit Vertical Pod Autoscaler anpassen](vertical-pod-autoscaler.md) verwenden, um die CPU und den Speicher für Ihre Fargate- anfänglich richtig zu dimensionieren, und dann Fargate Pods verwenden, um [Skalierung von Pod-Bereitstellungen mit Horizontal Pod Autoscaler](horizontal-pod-autoscaler.md) diese Pods zu skalieren. Wenn Sie möchten, dass der Vertical Pod Autoscaler `Auto` mit höheren CPU- und Speicherkombinationen automatisch erneut in Fargate bereitstellt, stellen Sie den Modus für den Vertical-Pod-Autoscaler-Modus entweder auf oder `Recreate`. Dies dient der Gewährleistung einer korrekten Funktion. Weitere Informationen finden Sie in der [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start)-Dokumentation auf GitHub. + Sie können den [AWS Distro für OpenTelemetry](https://aws.amazon.com/otel)(ADOT)-Kollektor zur Anwendungsüberwachung durch Befolgen [dieser Anweisungen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-EKS-otel.html) einrichten. # Festlegung, welche Pods beim Start AWS Fargate verwenden Bevor Sie Pods auf Fargate in Ihrem Cluster planen, müssen Sie mindestens ein Fargate-Profil definieren, das angibt, welche Pods Fargate beim Start verwenden. Als Administrator können Sie mithilfe eines Fargate-Profils angeben, welche Pods in Fargate ausgeführt werden. Sie können dies über die Selektoren des Profils tun. Sie können bis zu fünf Selektoren zu jedem Profil hinzufügen. Jeder Selektor muss einen Namespace enthalten. Der Selector kann auch Labels enthalten. Das Label-Feld besteht aus mehreren optionalen Schlüssel-Wert-Paaren. Pods, die den Selektoren entsprechen, werden auf Fargate geplant. Pods werden mit einem Namespace und den Labels abgeglichen, die im Selektor angegeben sind. Wenn ein Namespace-Selektor ohne Labels definiert ist, versucht Amazon EKS, alle Pods, die in diesem Namespace ausgeführt werden, mithilfe des Profils in Fargate zu planen. Wenn ein zu planender Pod mit einem der Selektoren im Fargate-Profil übereinstimmt, wird dieser Pod in Fargate geplant. Wenn ein Pod mit mehreren Fargate-Profilen übereinstimmt, können Sie angeben, welches Profil ein Pod verwendet, indem Sie der Pod-Spezifikation das folgende Kubernetes-Label hinzufügen: `eks.amazonaws.com/fargate-profile: my-fargate-profile`. Der Pod muss mit einem Selektor in diesem Profil übereinstimmen, um in Fargate geplant zu werden. Die Affinitäts-/Anti-Affinitätsregeln von Kubernetes gelten nicht und sind bei Amazon-EKS-Fargate-Pods nicht erforderlich. Wenn Sie ein Fargate-Profil erstellen, müssen Sie eine Pod-Ausführungsrolle angeben. Diese Ausführungsrolle ist für die Amazon-EKS-Komponenten vorgesehen, die auf der Fargate-Infrastruktur mit dem Profil ausgeführt werden. Es wird zur Autorisierung der [Rollenbasierten Zugriffskontrolle](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) von Kubernetes des Clusters hinzugefügt. Auf diese Weise kann sich `kubelet`, das in der Fargate-Infrastruktur ausgeführt wird, bei Ihrem Amazon-EKS-Cluster registrieren und als Knoten in Ihrem Cluster angezeigt werden. Die Pod-Ausführungsrolle bietet auch IAM-Berechtigungen für die Fargate-Infrastruktur, um Lesezugriff auf Amazon-ECR-Image-Repositorys zu ermöglichen. Weitere Informationen finden Sie unter [IAM-Rolle für die Ausführung von Amazon-EKS-Pods](pod-execution-role.md). Fargate-Profile können nicht geändert werden. Sie können jedoch ein neues aktuelles Profil erstellen, um ein vorhandenes Profil zu ersetzen, und dann das Original löschen. **Anmerkung** Alle Pods, die mit einem Fargate-Profil ausgeführt werden, werden angehalten und als ausstehend gekennzeichnet, wenn das Profil gelöscht wird. Wenn Fargate-Profile in einem Cluster den Status `DELETING` haben, müssen Sie warten, bis dieses Fargate-Profil gelöscht wurde, bevor Sie andere Profile in diesem Cluster erstellen können. **Anmerkung** Fargate unterstützt derzeit keine Kubernetes [topologySpreadConstraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/). Amazon EKS und Fargate verteilen Pods auf alle Subnetze, die im Fargate-Profil definiert sind. Es kann jedoch zu einer ungleichmäßigen Verteilung kommen. Wenn Sie eine gleichmäßige Verteilung benötigen, verwenden Sie zwei Fargate-Profile. Eine gleichmäßige Verteilung ist in Szenarien wichtig, in denen Sie zwei Replikate bereitstellen möchten und keine Ausfallzeiten wünschen. Wir empfehlen, dass jedes Profil nur ein Subnetz hat. ## Fargate-Profilkomponenten Die folgenden Komponenten sind in einem Fargate-Profil enthalten. **Pod-Ausführungsrolle** Wenn Ihr Cluster Pods auf AWS Fargate erstellt, muss das auf der Fargate-Infrastruktur ausgeführte `kubelet` in Ihrem Namen AWS-API-Aufrufe durchführen. Beispielsweise muss er Aufrufe tätigen, um Container-Images aus Amazon ECR zu ziehen. Die Amazon-EKS-Pod-Ausführungsrolle stellt die entsprechenden IAM-Berechtigungen bereit. Wenn Sie ein Fargate-Profil erstellen, müssen Sie eine Pod-Ausführungsrolle angeben, die mit Ihren Pods verwendet werden soll. Diese Rolle wird zur Autorisierung der [Rollenbasierten Zugriffskontrolle](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) von Kubernetes des Clusters hinzugefügt. Auf diese Weise kann sich `kubelet`, das in der Fargate-Infrastruktur ausgeführt wird, bei Ihrem Amazon-EKS-Cluster registrieren und als Knoten in Ihrem Cluster angezeigt werden. Weitere Informationen finden Sie unter [IAM-Rolle für die Ausführung von Amazon-EKS-Pods](pod-execution-role.md). **Subnets** Die IDs von Subnetzen, in denen Pods gestartet werden, die dieses Profil verwenden. Derzeit werden Pods, die in Fargate ausgeführt werden, keine öffentlichen IP-Adressen zugewiesen. Daher werden für diesen Parameter nur private Subnetze ohne direkte Route zu einem Internet-Gateway akzeptiert. **Selektoren** Die Selektoren, mit denen Pods, die dieses Fargate-Profil verwenden, übereinstimmen sollen. Sie können bis zu fünf Selektoren in einem Fargate-Profil angeben. Die Selektoren bestehen aus folgenden Komponenten: + **Namespace** – Sie müssen einen Namespace für einen Selektor angeben. Der Selektor stimmt nur mit Pods überein, die in diesem Namespace erstellt werden. Sie können jedoch mehrere Selektoren erstellen, um mehrere Namespaces zu adressieren. + **Bezeichnungen** – Sie können optional Kubernetes-Bezeichnungen angeben, mit denen der Selektor übereinstimmen muss. Der Selektor stimmt nur mit Pods überein, die alle im Selektor angegebenen Labels aufweisen. ## Platzhalter für Fargate-Profile Zusätzlich zu den Zeichen, die von Kubernetes erlaubt sind, dürfen Sie `*` und `?` in den Selektorkriterien für Namespaces, Label-Schlüssel und Label-Werte verwenden: + `*` steht für kein, ein oder mehrere Zeichen. Zum Beispiel kann `prod*` `prod` und `prod-metrics` darstellen. + `?` steht für ein einzelnes Zeichen (z. B. kann `value?` `valuea` darstellen). Es kann jedoch nicht `value` und `value-a` darstellen, weil `?` nur genau ein Zeichen darstellen kann. Diese Platzhalterzeichen können an jeder Position und in Kombination verwendet werden (z. B. `prod*`, `*dev` und `frontend*?`). Andere Platzhalter und Formen des Mustervergleichs, wie reguläre Ausdrücke, werden nicht unterstützt. Wenn mehrere übereinstimmende Profile für den Namespace und die Labels in der Pod-Spezifikation vorhanden sind, übernimmt Fargate das Profil basierend auf einer alphanumerischen Sortierung nach Profilnamen. Wenn zum Beispiel Profil A (mit dem Namen `beta-workload`) und Profil B (mit dem Namen `prod-workload`) passende Selektoren für die zu startenden Pods haben, wählt Fargate Profil A (`beta-workload`) für die Pods aus. Die Pods haben Labels mit Profil A auf den Pods (z. B. `eks.amazonaws.com/fargate-profile=beta-workload`). Wenn Sie vorhandene Fargate-Pods auf neue Profile migrieren möchten, die Platzhalter verwenden, gibt es zwei Möglichkeiten, dies zu tun: + Erstellen Sie ein neues Profil mit passenden Selektoren und löschen Sie dann die alten Profile. Mit alten Profilen gekennzeichnete Pods werden in neue übereinstimmende Profile verschoben. + Wenn Sie Workloads migrieren möchten, sich aber nicht sicher sind, welche Fargate-Labels sich auf jedem Fargate-Pod befinden, können Sie die folgende Methode verwenden. Erstellen Sie ein neues Profil mit einem Namen, das zuerst alphanumerisch unter den Profilen auf demselben Cluster sortiert. Recyceln Sie dann die Fargate-Pods, die in neue Profile migriert werden müssen. ## Erstellen eines Fargate-Profils In diesem Abschnitt wird beschrieben, wie Sie ein Fargate-Profil erstellen. Sie müssen auch eine Pod-Ausführungsrolle erstellt haben, die für Ihr Fargate-Profil verwendet werden soll. Weitere Informationen finden Sie unter [IAM-Rolle für die Ausführung von Amazon-EKS-Pods](pod-execution-role.md). Pods, die in Fargate ausgeführt werden, werden nur in privaten Subnetzen unterstützt (mit [NAT Gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)-Zugriff auf AWS-Services, aber ohne direkte Route zu einem Internet-Gateway. Dies ist so, da in der VPC Ihres Clusters private Subnetze verfügbar sein müssen. Sie können ein Profil mit Folgendem erstellen: + [`eksctl`](#eksctl_create_a_fargate_profile) + [AWS-Managementkonsole](#console_create_a_fargate_profile) ## `eksctl` **So erstellen Sie ein Fargate-Profil mit `eksctl`** Erstellen Sie Ihr Fargate-Profil mit dem folgenden `eksctl`-Befehl und ersetzen Sie dabei alle Beispielwerte durch Ihre eigenen Werte. Sie müssen einen Namespace angeben. Die Option `--labels` ist jedoch nicht erforderlich. ``` eksctl create fargateprofile \ --cluster my-cluster \ --name my-fargate-profile \ --namespace my-kubernetes-namespace \ --labels key=value ``` Sie können bestimmte Platzhalter für `my-kubernetes-namespace`- und `key=value`-Labels verwenden. Weitere Informationen finden Sie unter [Platzhalter für Fargate-Profile](#fargate-profile-wildcards). ## AWS-Managementkonsole **So erstellen Sie ein Fargate-Profil mit AWS-Managementkonsole** 1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters). 1. Wählen Sie den Cluster aus, für den Sie ein Fargate-Profil erstellen möchten. 1. Wählen Sie die Registerkarte **Compute** (Datenverarbeitung) aus. 1. Wählen Sie unter **Fargate-Profile** die Option **Fargate-Profil hinzufügen** aus. 1. Auf der Seite **Konfigurieren des Fargate Profils** führen Sie folgende Schritte aus: 1. Geben Sie unter **Name** einen eindeutigen Namen für Ihr Fargate-Profil ein, wie z. B. `my-profile`. 1. Wählen Sie für **Pod-Ausführungsrolle** die Pod-Ausführungsrolle aus, die mit Ihrem Fargate-Profil verwendet werden soll. Es werden nur IAM-Rollen mit dem `eks-fargate-pods.amazonaws.com`-Service-Prinzipal angezeigt. Wenn keine Rollen aufgelistet sind, müssen Sie eine erstellen. Weitere Informationen finden Sie unter [IAM-Rolle für die Ausführung von Amazon-EKS-Pods](pod-execution-role.md). 1. Ändern Sie die ausgewählten **Subnetze** nach Bedarf. **Anmerkung** Für Pods, die in Fargate ausgeführt werden, werden nur private Subnetze unterstützt. 1. Für **Tags** können Sie Ihr Fargate-Profil wahlweise markieren. Diese Tags werden nicht an andere Ressourcen weitergegeben, die dem Profil zugeordnet sind, z. B. Pods. 1. Wählen Sie **Weiter** aus. 1. Führen Sie auf der Seite **Pod-Auswahl konfigurieren** die folgenden Schritte aus: 1. Geben Sie für **Namespace** einen Namespace ein, der mit Pods übereinstimmt. + Sie können bestimmte Namespaces für den Abgleich verwenden, z. B. `kube-system` oder `default`. + Sie können bestimmte Platzhalter verwenden (z. B. `prod-*`), um mehrere Namespaces abzugleichen (z. B. `prod-deployment` und `prod-test`). Weitere Informationen finden Sie unter [Platzhalter für Fargate-Profile](#fargate-profile-wildcards). 1. (Optional) Fügen Sie dem Selektor Kubernetes-Markierungen hinzu. Fügen Sie sie insbesondere demjenigen hinzu, dem die Pods im angegebenen Namespace entsprechen müssen. + Sie können dem Selektor das Label `infrastructure: fargate` hinzufügen, sodass nur Pods im angegebenen Namespace, die ebenfalls die `infrastructure: fargate`-Kubernetes-Bezeichnung tragen, mit dem Selektor übereinstimmen. + Sie können bestimmte Platzhalter verwenden (z. B. `key?: value?`), um mehrere Namespaces abzugleichen (z. B. `keya: valuea` und `keyb: valueb`). Weitere Informationen finden Sie unter [Platzhalter für Fargate-Profile](#fargate-profile-wildcards). 1. Wählen Sie **Weiter** aus. 1. Überprüfen Sie auf der Seite **Überprüfen und erstellen** die Informationen für Ihr -Profil und wählen Sie **Erstellen** aus. # Fargate-Profil löschen In diesem Thema wird beschrieben, wie Sie ein Fargate-Profil löschen. Wenn Sie ein Fargate-Profil löschen, werden alle Pods gelöscht, die in Fargate mit dem Profil geplant wurden. Wenn diese Pods mit einem anderen Fargate-Profil übereinstimmen, werden sie mit diesem Profil in Fargate geplant. Wenn sie nicht mehr mit einem der Fargate-Profile übereinstimmen, werden sie nicht in Fargate geplant und ggf. als ausstehend gekennzeichnet. Nur ein Fargate-Profil in einem Cluster kann sich jeweils im `DELETING`-Status befinden. Warten Sie, bis das Löschen eines Fargate-Profils abgeschlossen ist, bevor Sie andere Profile in diesem Cluster löschen können. Sie können ein Profil mit einem der folgenden Tools löschen: + [`eksctl`](#eksctl_delete_a_fargate_profile) + [AWS-Managementkonsole](#console_delete_a_fargate_profile) + [AWS-CLI](#awscli_delete_a_fargate_profile) ## `eksctl` **Löschen eines Fargate-Profils mit `eksctl` ** Verwenden Sie den folgenden Befehl, um ein Profil aus einem Cluster zu löschen. Ersetzen Sie jeden *Beispielwert* durch Ihre eigenen Werte. ``` eksctl delete fargateprofile --name my-profile --cluster my-cluster ``` ## AWS-Managementkonsole **Löschen eines Fargate-Profils mit AWS-Managementkonsole ** 1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters). 1. Wählen Sie im linken Navigationsbereich die Option **Cluster** aus. Wählen Sie in der Clusterliste den Cluster aus, in dem Sie das Fargate-Profil löschen möchten. 1. Wählen Sie die Registerkarte **Compute** (Datenverarbeitung) aus. 1. Wählen Sie das zu löschende Fargate-Profil und dann **Delete** (Löschen) aus. 1. Geben Sie auf der Seite **Delete Fargate profile** (Fargate-Profil löschen) den Namen des Profils ein und wählen Sie dann **Delete** (Löschen) aus. ## AWS-CLI **Löschen eines Fargate-Profils mit der AWS-CLI** Verwenden Sie den folgenden Befehl, um ein Profil aus einem Cluster zu löschen. Ersetzen Sie jeden *Beispielwert* durch Ihre eigenen Werte. ``` aws eks delete-fargate-profile --fargate-profile-name my-profile --cluster-name my-cluster ``` # Details zur Fargate-Pod-Konfiguration verstehen In diesem Abschnitt werden einige der eindeutigen Pod-Konfigurationsdetails für die Ausführung von Kubernetes-Pods in AWS-Fargate beschrieben. ## CPU und Arbeitsspeicher des Pods Mit Kubernetes können Sie Anforderungen, eine minimale vCPU-Menge und Arbeitsspeicherressourcen definieren, die jedem Container in einem Pod zugewiesen werden. Pods werden von Kubernetes geplant, um sicherzustellen, dass mindestens die angeforderten Ressourcen für jeden Pod in der Rechenressource verfügbar sind. Weitere Informationen finden Sie unter [Managing Compute Resources for Containers](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) in der Kubernetes-Dokumentation. **Anmerkung** Da Amazon-EKS-Fargate nur einen Pod pro Knoten ausführt, tritt das Szenario des Räumens von Pods bei weniger Ressourcen nicht auf. Alle Amazon-EKS-Fargate-Pods werden mit garantierter Priorität ausgeführt, daher müssen die angeforderte CPU-Leistung und der Arbeitsspeicher für alle Container dem Limit entsprechen. Weitere Informationen finden Sie unter [Konfigurieren von Dienstqualität für Pods](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/) in der Kubernetes-Dokumentation. Wenn Pods in Fargate geplant sind, bestimmen die vCPU- und Speicherreservierungen innerhalb der Pod-Spezifikation, wie viel CPU und Speicher für den Pod bereitgestellt werden sollen. + Die maximale Anforderung von Init-Containern wird verwendet, um die vCPU- und Speicheranforderungen für die Init-Anforderung zu bestimmen. + Anforderungen für alle lang laufenden Container werden addiert, um die Anforderungen an die vCPU und den Arbeitsspeicher für lange laufende Anforderungen zu bestimmen. + Der größere der beiden zuvor genannten Werte wird für die vCPU und die Speicheranforderung für Ihren Pod ausgewählt. + Fargate fügt 256 MB zur Speicherreservierung jedes Pods für die erforderlichen Kubernetes-Komponenten (`kubelet`, `kube-proxy` und `containerd`) hinzu. Fargate rundet auf die folgende Rechenkonfiguration auf, die der Summe von vCPU und Speicheranforderungen am nächsten liegt, damit Pods immer über die Ressourcen verfügen, die sie für ihre Ausführung benötigen. Wenn Sie keine vCPU- und Speicherkombination angeben, wird die kleinste verfügbare Kombination verwendet (0,25 vCPU und 0,5 GB Arbeitsspeicher). Die folgende Tabelle zeigt die vCPU- und Speicherkombinationen, die für Pods verfügbar sind, die in Fargate ausgeführt werden. | vCPU-Wert | Speicherwert | | --- | --- | | 0,25 vCPU | 0,5 GB, 1 GB, 2 GB | | 0,5 vCPU | 1 GB, 2 GB, 3 GB, 4 GB | | 1 vCPU | 2 GB, 3 GB, 4 GB, 5 GB, 6 GB, 7 GB, 8 GB | | 2 vCPU | Zwischen 4 GB und 16 GB in 1-GB-Schritten | | 4 vCPU | Zwischen 8 GB und 30 GB in 1-GB-Schritten | | 8 vCPU | Zwischen 16 GB und 60 GB in 4-GB-Schritten | | 16 vCPU | Zwischen 32 GB und 120 GB in 8-GB-Schritten | Der für die Kubernetes-Komponenten reservierte zusätzliche Arbeitsspeicher kann dazu führen, dass eine Fargate-Aufgabe mit mehr vCPUs als angefordert bereitgestellt wird. Bei einer Anforderung von 1 vCPU und 8 GB Speicher werden beispielsweise 256 MB zu ihrer Speicheranforderung hinzugefügt und eine Fargate-Aufgabe mit 2 vCPUs und 9 GB Speicher bereitgestellt, da keine Aufgabe mit 1 vCPU und 9 GB Speicher verfügbar ist. Es gibt keine Korrelation zwischen der Größe des Pods, der auf Fargate ausgeführt wird, und der von Kubernetes gemeldeten Knotengröße mit `kubectl get nodes`. Die gemeldete Knotengröße ist oft größer als die Kapazität des Pods. Sie können die Pod-Kapazität mit dem folgenden Befehl überprüfen. Ersetzen Sie *default* durch den Namespace Ihres Pods und *pod-name* durch den Namen Ihres Pods ``` kubectl describe pod --namespace default pod-name ``` Eine Beispielausgabe sieht wie folgt aus. ``` [...] annotations: CapacityProvisioned: 0.25vCPU 0.5GB [...] ``` Die `CapacityProvisioned`-Annotation stellt die erzwungene Pod-Kapazität dar und bestimmt die Kosten Ihres Pods, der auf Fargate ausgeführt wird. Preisinformationen für die Computing-Konfigurationen finden Sie unter [AWS-Fargate-Preise](https://aws.amazon.com/fargate/pricing/). ## Fargate-Speicher Ein in Fargate ausgeführter Pod bindet automatisch ein Amazon-EFS-Dateisystem ein, ohne dass manuelle Schritte zur Treiberinstallation erforderlich sind. Sie können mit Fargate-Knoten keine dynamische Bereitstellung persistenter Volumes verwenden, aber Sie können eine statische Bereitstellung verwenden. Weitere Informationen finden Sie unter [Amazon-EFS-CSI-Treiber](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md) in GitHub. Bei der Bereitstellung erhält jedes Pod, die in Fargate ausgeführt wird, standardmäßig 20 GiB flüchtigen Speicher. Diese Art von Speicher wird gelöscht, nachdem ein Pod stoppt. Bei neu auf Fargate gestarteten Pods ist die Verschlüsselung des flüchtigen Speicher-Volumes standardmäßig aktiviert. Der flüchtige Pod-Speicher wird mit einem AES-256-Verschlüsselungsalgorithmus mit AWS-Fargate-verwalteten Schlüsseln verschlüsselt. **Anmerkung** Der standardmäßig nutzbare Speicher für Amazon-EKS-Pods, die in Fargate ausgeführt werden, beträgt weniger als 20 GiB. Dies liegt daran, dass ein Teil des Speicherplatzes von `kubelet` und anderen Kubernetes-Modulen belegt wird, die im Pod geladen werden. Sie können die Gesamtmenge des flüchtigen Speichers bis zu einem Maximum von 175 GB erhöhen. Um die Größe mit Kubernetes zu konfigurieren, geben Sie die `ephemeral-storage`-Ressourcen-Anfragen für jeden Container in einem Pod an. Wenn Kubernetes Pods plant, stellt es sicher, dass die Summe der Ressourcen-Anfragen für jeden Pod geringer ist als die Kapazität der Fargate-Aufgabe. Weitere Informationen finden Sie unter [Ressourcen-Management für Pods und Container](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) in der Kubernetes-Dokumentation. Amazon EKS Fargate stellt mehr kurzlebigen Speicher bereit, als für die Systemnutzung angefordert wurde. Eine Anforderung von 100 GB stellt beispielsweise eine Fargate-Aufgabe mit 115 GB flüchtigem Speicher bereit. # Festlegung von Maßnahmen für Betriebssystem-Patching-Ereignisse für AWS Fargate Amazon EKS patcht regelmäßig das Betriebssystem für AWS-Fargate-Knoten, damit sie sicher bleiben. Im Rahmen des Patching-Prozesses werden die Knoten recycelt, um Betriebssystem-Patches zu installieren. Updates werden so durchgeführt, dass sie Ihre Services möglichst wenig beeinflussen. Wenn Pods jedoch nicht erfolgreich bereinigt wurden, kann es sein, dass sie gelöscht werden müssen. Die folgenden Maßnahmen können Ihnen helfen, potenzielle Unterbrechungen zu minimieren: + Legen Sie geeignete Budgets für Pod-Unterbrechung (PBDs) fest, um die Anzahl der Pods, die gleichzeitig ausfallen, zu steuern. + Erstellen Sie Amazon-EventBridge-Regeln für den Umgang mit fehlgeschlagenen Bereinigungen, bevor die Pods gelöscht werden. + Starten Sie die betroffenen Pods manuell neu, bevor das in der Benachrichtigung angegebene Bereinigungsdatum erreicht ist. + Erstellen Sie eine Benachrichtigungskonfiguration in AWS-Benutzerbenachrichtigungen. Amazon EKS arbeitet eng mit der Kubernetes-Community zusammen, um Fehlerbehebungen und Sicherheits-Patches so schnell wie möglich bereitzustellen. Alle Fargate-Pods starten mit der aktuellsten Kubernetes-Patch-Version, die über die über Amazon EKS für die Kubernetes-Version Ihres Clusters verfügbar ist. Wenn Sie einen Pod mit einer älteren Patch-Version haben, recycelt Amazon EKS ihn möglicherweise, um ihn auf die neueste Version zu aktualisieren. Das stellt sicher, dass Ihre Pods mit den neuesten Sicherheitsaktualisierungen ausgestattet sind. Wenn ein [Häufige Schwachstellen und Aufdeckungen](https://cve.mitre.org/) (CVE)-Problem auftritt, bleiben Sie so auf dem Laufenden und können Sicherheitsrisiken reduzieren. Wenn das AWS-Fargate-Betriebssystem aktualisiert wird, sendet Ihnen Amazon EKS eine Benachrichtigung, die Ihre betroffenen Ressourcen und das Datum der bevorstehenden Pod-Bereinigungen enthält. Wenn das angegebene Bereinigungsdatum ungünstig ist, haben Sie die Möglichkeit, Ihre betroffenen Pods vor dem in der Benachrichtigung angegebenen Bereinigungsdatum manuell neu zu starten. Alle Pods, die vor dem Zeitpunkt der Benachrichtigung erstellt wurden, können bereinigt werden. Weitere Anweisungen zum manuellen Neustart Ihrer Pods finden Sie in der [Kubernetes-Dokumentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_rollout/kubectl_rollout_restart). Um die Anzahl der Pods zu begrenzen, die bei der Wiederverwendung von Pods gleichzeitig ausfallen, können Sie Budgets für Pod-Unterbrechung (PDBs) festlegen. Sie können PDBs verwenden, um die Mindestverfügbarkeit basierend auf den Anforderungen jeder Ihrer Anwendungen zu definieren und gleichzeitig Aktualisierungen zuzulassen. Die Mindestverfügbarkeit Ihres PDB muss unter 100 % liegen. Weitere Informationen finden Sie unter [Angabe eines Budgets für Unterbrechung in Ihrer Anwendung](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) in der Kubernetes-Dokumentation. Amazon EKS verwendet die [Bereinigungs-AMI](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/#eviction-api), um den Pod sicher zu leeren. Dabei werden die PDBs eingehalten, die Sie für die Anwendung festgelegt haben. Pods werden von der Availability Zone bereinigt, um Auswirkungen zu minimieren. Wenn die Bereinigung erfolgreich ist, erhält der neue Pod den aktuellsten Patch und es sind keine weiteren Maßnahmen erforderlich. Wenn die Bereinigung für einen Pod fehlschlägt, sendet Amazon EKS ein Ereignis an Ihr Konto, das Details über die Pods enthält, deren Bereinigung fehlgeschlagen ist. Sie können vor der geplanten Beendigungszeit auf die Nachricht reagieren. Die spezifische Zeit variiert je nach Dringlichkeit des Patches. Zum festgelegten Zeitpunkt versucht Amazon EKS erneut, die Pods zu bereinigen. Dieses Mal wird bei einer fehlgeschlagenen Bereinigung jedoch kein neues Ereignis gesendet. Wenn die Bereinigung erneut fehlschlägt, werden Ihre vorhandenen Pods regelmäßig gelöscht, damit neue Pods den aktuellsten Patch haben. Nachfolgend sehen Sie ein Beispielereignis, das Sie erhalten könnten, wenn die Pod-Bereinigung fehlschlägt. Es enthält Informationen über den Cluster, den Pod-Namen, den Pod-Namespace, das Fargate-Profil und die geplante Beendigungszeit. ``` { "version": "0", "id": "12345678-90ab-cdef-0123-4567890abcde", "detail-type": "EKS Fargate Pod Scheduled Termination", "source": "aws.eks", "account": "111122223333", "time": "2021-06-27T12:52:44Z", "region": "region-code", "resources": [ "default/my-database-deployment" ], "detail": { "clusterName": "my-cluster", "fargateProfileName": "my-fargate-profile", "podName": "my-pod-name", "podNamespace": "default", "evictErrorMessage": "Cannot evict pod as it would violate the pod's disruption budget", "scheduledTerminationTime": "2021-06-30T12:52:44.832Z[UTC]" } } ``` Einer der Gründe für ein Bereinigungsfehlerereignis kann sein, dass einem Pod mehrere PDBs zugeordnet sind. In diesem Fall gibt das Ereignis die folgende Fehlernachricht zurück. ``` "evictErrorMessage": "This pod has multiple PodDisruptionBudget, which the eviction subresource does not support", ``` Basierend auf diesem Ereignis können Sie eine gewünschte Aktion erstellen. Sie können beispielsweise Ihr Budget für Pod-Unterbrechung (PDB) anpassen, um zu steuern, wie die Pods bereinigt werden. Nehmen Sie zum Beispiel an, dass Sie ein PDB starten, dass den Zielprozentsatz von verfügbaren Pods angibt. Bevor Ihre Pods während eines Upgrades automatisch beendet werden, können Sie das PDB an einen unterschiedlichen Prozentsatz von Pods anpassen. Um dieses Ereignis zu erhalten, müssen Sie eine Amazon-EventBridge-Regel im AWS-Konto und der AWS-Region erstellen, zu denen der Cluster gehört. Die Regel muss das folgende **benutzerdefinierte Muster** verwenden. Weitere Informationen finden Sie unter [Erstellen von Erstellen von Amazon-EventBridge-Regeln, die auf Ereignisse reagieren](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html) im *Amazon-EventBridge-Benutzerhandbuch*. ``` { "source": ["aws.eks"], "detail-type": ["EKS Fargate Pod Scheduled Termination"] } ``` Es kann ein geeignetes Ziel zur Erfassung durch das Ereignis festgelegt werden. Eine vollständige Liste der verfügbaren Ziele finden Sie unter [Amazon-EventBridge-Ziele](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html) im *Amazon-EventBridge-Benutzerhandbuch*. Sie können eine Benachrichtigungskonfiguration in AWS-Benutzerbenachrichtigungen erstellen. Wenn Sie die AWS-Managementkonsole verwenden, um die Benachrichtigung zu erstellen, wählen Sie unter **Ereignisregeln** **Elastic Kubernetes Service (EKS)** als **AWS-Name** und **Geplante Beendigung des EKS-Fargate-Pod** als **Ereignistyp** aus. Weitere Informationen finden Sie unter [Erste Schritte mit AWS Benutzerbenachrichtigungen](https://docs.aws.amazon.com/notifications/latest/userguide/getting-started.html) im AWS-Benutzerhandbuch für Benutzerbenachrichtigungen. Häufig gestellte Fragen zu EKS-Pod-Bereinigungen finden Sie in den [FAQs: Bereinigungsbeanchrichtigung für Fargate-Pods](https://repost.aws/knowledge-center/fargate-pod-eviction-notice) in * AWS re:Post*. # Erfassen Sie die App- und Nutzungsmetriken von AWS Fargate Sie können Systemmetriken und CloudWatch Nutzungsmetriken für AWS Fargate sammeln. ## Anwendungsmetriken Für Anwendungen, die auf Amazon EKS und AWS Fargate ausgeführt werden, können Sie die AWS Distribution for OpenTelemetry (ADOT) verwenden. ADOT ermöglicht es Ihnen, Systemmetriken zu sammeln und sie an Container Insights-Dashboards zu CloudWatch senden. Informationen zu den ersten Schritten mit ADOT für Anwendungen, die auf Fargate ausgeführt werden, finden Sie unter [Using CloudWatch Container Insights with AWS Distro for OpenTelemetry](https://aws-otel.github.io/docs/getting-started/container-insights) in der ADOT-Dokumentation. ## Nutzungsmetriken Sie können CloudWatch Nutzungsmetriken verwenden, um einen Überblick über die Ressourcennutzung Ihres Kontos zu erhalten. Verwenden Sie diese Metriken, um Ihre aktuelle Servicenutzung in CloudWatch Diagrammen und Dashboards zu visualisieren. AWS Die Nutzungsmetriken von Fargate entsprechen den AWS Servicekontingenten. Sie können Alarme konfigurieren, mit denen Sie benachrichtigt werden, wenn sich Ihre Nutzung einem Servicekontingent nähert. Weitere Hinweise zu Servicekontingenten für Fargate finden Sie unter [Service Quotas für Amazon EKS und Fargate anzeigen und verwalten](service-quotas.md). AWS Fargate veröffentlicht die folgenden Metriken im ` AWS/Usage` Namespace. | Metrik | Beschreibung | | --- | --- | | `ResourceCount` | Die Gesamtanzahl der angegebenen Ressourcen, die in Ihrem Konto ausgeführt werden. Die Ressource wird durch die Dimensionen definiert, die der Metrik zugeordnet sind. | Die folgenden Dimensionen werden verwendet, um die von AWS Fargate veröffentlichten Nutzungsmetriken zu verfeinern. | Dimension | Description | | --- | --- | | `Service` | Der Name des AWS Dienstes, der die Ressource enthält. Für AWS Fargate-Nutzungsmetriken ist `Fargate` der Wert für diese Dimension. | | `Type` | Der Typ der Entität, die gemeldet wird. Derzeit ist der einzig gültige Wert für AWS Fargate-Nutzungsmetriken. `Resource` | | `Resource` | Der Typ der Ressource, die ausgeführt wird. Derzeit gibt AWS Fargate Informationen zu Ihrer Fargate On-Demand-Nutzung zurück. Der Ressourcenwert für Fargate On-Demand-Nutzung ist `OnDemand`. [HINWEIS] ==== Die Fargate On-Demand-Nutzung kombiniert Amazon-EKS-Pods mit Fargate, Amazon-ECS-Aufgaben mit dem Fargate-Starttyp und Amazon-ECS-Aufgaben mithilfe des `FARGATE`-Kapazitätsanbieters. ==== | | `Class` | Die Klasse der nachverfolgten Ressource. Derzeit verwendet AWS Fargate die Klassendimension nicht. | ### Einen CloudWatch Alarm zur Überwachung der Fargate-Ressourcennutzungsmetriken erstellen AWS Fargate stellt CloudWatch Nutzungsmetriken bereit, die den AWS Servicekontingenten für die Nutzung von Fargate On-Demand-Ressourcen entsprechen. In der Service-Quotas-Konsole können Sie Ihre Nutzung in einem Diagramm visualisieren. Sie können auch Alarme konfigurieren, die Sie warnen, wenn sich Ihre Nutzung einem Service Quotas nähert. Weitere Informationen finden Sie unter [Erfassen Sie die App- und Nutzungsmetriken von AWS Fargate](#monitoring-fargate-usage). Gehen Sie wie folgt vor, um einen CloudWatch Alarm auf der Grundlage der Fargate-Kennzahlen zur Ressourcennutzung zu erstellen. 1. Öffnen Sie die Service Quotas Quotas-Konsole unter https://console.aws.amazon.com/servicequotas/. 1. Wählen Sie im linken Navigationsbereich ** AWS Dienste** aus. 1. Suchen Sie in der ** AWS Serviceliste** nach ** AWS Fargate** und wählen Sie es aus. 1. Wählen Sie in der Liste **Service quotas** (Servicekontingente) das Fargate-Nutzungskontingent aus, für das Sie einen Alarm erstellen möchten. 1. Wählen Sie im Bereich CloudWatch Amazon-Alarme die Option **Erstellen** aus. 1. Wählen Sie bei **Alarmschwellenwert** den Prozentsatz des angewendeten Kontingentwerts aus, den Sie als Alarmwert festlegen möchten. 1. Geben Sie bei **Alarmname** einen Namen für den Alarm ein und wählen Sie dann **Erstellen** aus. # AWS-Fargate-Protokollierung für Ihren Cluster starten Amazon EKS auf Fargate bietet einen integrierten Log-Router basierend auf Fluent Bit. Dies bedeutet, dass Sie einen Fluent-Bit-Container nicht explizit als Sidecar ausführen, sondern Amazon für Sie ausführen. Alles, was Sie tun müssen, ist den Log-Router zu konfigurieren. Die Konfiguration erfolgt über ein dediziertes `ConfigMap`, das die folgenden Kriterien erfüllen muss: + Benannte `aws-logging` + Erstellt in einem dedizierten Namespace namens `aws-observability` + Mehr als 5 300 Zeichen sind nicht zulässig. Sobald Sie die `ConfigMap` erstellt haben, erkennt Amazon EKS in Fargate sie automatisch und konfiguriert den Protokollrouter damit. Fargate verwendet eine Version von AWS für Fluent Bit, eine Upstream-kompatible Distribution von Fluent Bit, die von AWS verwaltet wird. Weitere Informationen finden Sie unter [AWS für Fluent Bit auf](https://github.com/aws/aws-for-fluent-bit) GitHub. Mit dem Log-Router können Sie die Bandbreite der Services von AWS für Protokoll-Analysen und -Speicherung nutzen. Sie können Protokolle von Fargate direkt an Amazon CloudWatch, Amazon OpenSearch Service streamen. Außerdem können Sie Protokolle über [Amazon Kinesis Data Firehose](https://aws.amazon.com/kinesis/data-firehose/) an Ziele wie [Amazon S3](https://aws.amazon.com/s3/), [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) und Partner-Tools streamen. + Ein vorhandenes Fargate-Profil, das einen vorhandenen Kubernetes-Namespace angibt, in dem Sie Fargate-Pods bereitstellen. Weitere Informationen finden Sie unter [Schritt 3: Fargate Profil für Ihren Cluster erstellen](fargate-getting-started.md#fargate-gs-create-profile). + Eine vorhandene Fargate-Pod-Ausführungsrolle. Weitere Informationen finden Sie unter [Schritt 2: Fargate-Pod-Ausführungsrolle erstellen](fargate-getting-started.md#fargate-sg-pod-execution-role). ## Router-Konfiguration protokollieren **Wichtig** Damit Protokolle erfolgreich veröffentlicht werden können, muss von der VPC, in der sich Ihr Cluster befindet, Netzwerkzugriff auf das Protokollziel bestehen. Dies betrifft vor allem Benutzer, die Ausgangsregeln für ihre VPC anpassen. Ein Beispiel für die Verwendung von CloudWatch finden Sie unter [Verwendung von CloudWatch-Protokollen mit Schnittstellen-VPC-Endpunkten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html) im *Benutzerhandbuch zu Amazon CloudWatch Logs*. Ersetzen Sie in den folgenden Schritten jedes *Beispielwert* durch Ihre eigenen Werte. 1. Erstellen Sie einen dedizierten Kubernetes-Namespace namens `aws-observability`. 1. Speichern Sie den folgenden Inhalt in einer Datei mit dem Namen `aws-observability-namespace.yaml` auf Ihrem Computer. Der Wert für `name` muss `aws-observability` sein und das Label `aws-observability: enabled` ist erforderlich. ``` kind: Namespace apiVersion: v1 metadata: name: aws-observability labels: aws-observability: enabled ``` 1. Erstellen Sie den Namespace. ``` kubectl apply -f aws-observability-namespace.yaml ``` 1. Erstellen Sie ein `ConfigMap` mit einem `Fluent Conf`-Datenwert, um Container-Logs an ein Ziel zu versenden. Fluent Conf ist Fluent Bit, eine schnelle und leichte Konfigurationssprache für den Protokollprozessor, die verwendet wird, um Container-Protokolle an ein Protokollziel Ihrer Wahl weiterzuleiten. Weitere Informationen finden Sie unter [Konfigurationsdatei](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/classic-mode/configuration-file) in der Fluent-Bit-Dokumentation. **Wichtig** In einer typischen `Fluent Conf` sind die Hauptabschnitte `Service`, `Input`, `Filter` und `Output` enthalten. Der Fargate-Protokoll-Router akzeptiert jedoch nur: Die Abschnitte `Filter` und `Output`. Ein `Parser`-Abschnitt. Wenn Sie andere Abschnitte angeben, werden diese abgelehnt. Der Fargate-Protokollrouter verwaltet die Abschnitte `Service` und `Input`. Es verfügt über den folgenden Abschnitt `Input`, der nicht geändert werden kann und in Ihrem `ConfigMap` nicht benötigt wird. Sie können daraus jedoch Erkenntnisse gewinnen, z. B. die Speicherpuffergrenze und das für Protokolle angewendete Tag. ``` [INPUT] Name tail Buffer_Max_Size 66KB DB /var/log/flb_kube.db Mem_Buf_Limit 45MB Path /var/log/containers/*.log Read_From_Head On Refresh_Interval 10 Rotate_Wait 30 Skip_Long_Lines On Tag kube.* ``` Berücksichtigen Sie beim Erstellen des `ConfigMap`, die folgenden Regeln, die Fargate verwendet, um Felder zu validieren: + `[FILTER]`, `[OUTPUT]`, und `[PARSER]` sollen unter jedem entsprechenden Schlüssel angegeben werden. `[FILTER]` muss beispielsweise unter `filters.conf` liegen. Sie können ein oder mehrere `[FILTER]` in der `filters.conf` haben. Die Abschnitte `[OUTPUT]` und `[PARSER]` sollten sich auch unter den entsprechenden Schlüssel befinden. Durch die Angabe mehrerer `[OUTPUT]`-Abschnitte können Sie Ihre Protokolle gleichzeitig an verschiedene Ziele weiterleiten. + Fargate validiert die erforderlichen Schlüssel für jeden Abschnitt. `Name` und `match`sind für jedes `[FILTER]` und `[OUTPUT]` erforderlich. `Name` und `format` werden jeweils für jeden `[PARSER]` benötigt. Bei den Schlüssel wird nicht zwischen Groß- und Kleinschreibung unterschieden. + Umgebungsvariablen wie `${ENV_VAR}` sind im `ConfigMap` nicht erlaubt. + Die Einrückung muss für die Direktive oder das Schlüssel-Wert-Paar innerhalb von `filters.conf`, `output.conf` und `parsers.conf` gleich sein. Schlüssel-Wert-Paare müssen stärker eingerückt werden als Direktiven. + Fargate validiert gegen die folgenden unterstützten Filter: `grep`, `parser`, `record_modifier`, `rewrite_tag`, `throttle`, `nest`, `modify`, und `kubernetes`. + Fargate validiert mit der folgenden unterstützten Ausgabe: `es`, `firehose`, `kinesis_firehose`, `cloudwatch`, `cloudwatch_logs`, und `kinesis`. + Mindestens ein unterstütztes `Output`-Plugin muss im `ConfigMap` bereitgestellt werden, um die Protokollierung zu ermöglichen. `Filter` und `Parser` sind nicht erforderlich, um die Protokollierung zu aktivieren. Sie können Fluent Bit auch auf Amazon EC2 mit der gewünschten Konfiguration ausführen, um alle Probleme zu beheben, die sich aus der Validierung ergeben. Erstellen Sie Ihr `ConfigMap` mit einem der folgenden Beispiele. **Wichtig** Die Amazon-EKS-Fargate-Protokollierung unterstützt keine dynamische Konfiguration einer `ConfigMap`. Alle Änderungen an eine `ConfigMap` werden nur auf neue Pods angewendet. Änderungen werden nicht auf vorhandene Pods angewendet. Erstellen Sie anhand des Beispiels ein `ConfigMap` für Ihr gewünschtes Protokollziel. **Anmerkung** Sie können auch Amazon Kinesis Data Streams als Protokollziel verwenden. Stellen Sie bei der Nutzung von Kinesis Data Streams sicher, dass der Pod-Ausführungsrolle die Berechtigung `kinesis:PutRecords` erteilt wurde. Weitere Informationen finden Sie unter [Berechtigungen](https://docs.fluentbit.io/manual/pipeline/outputs/kinesis#permissions) für Amazon Kinesis Data Streams im offiziellen *Handbuch zu Fluent Bit*. **Example** ------ #### [ CloudWatch ] Bei der Verwendung von CloudWatch haben Sie zwei Ausgabeoptionen: + [Ein Ausgabe-Plug-In in C geschrieben](https://docs.fluentbit.io/manual/v/1.5/pipeline/outputs/cloudwatch) + [Ein in Golang geschriebenes Ausgabe-Plug-In](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) Das folgende Beispiel zeigt Ihnen, wie Sie das `cloudwatch_logs`-Plug-in verwenden, um Protokolle an CloudWatch zu senden. 1. Speichern Sie den folgenden Inhalt in einer Datei namens `aws-logging-cloudwatch-configmap.yaml`. Ersetzen Sie den *region-code* durch die AWS-Region, in der sich Ihr Cluster befindet. Die Parameter unter `[OUTPUT]` sind erforderlich. ``` kind: ConfigMap apiVersion: v1 metadata: name: aws-logging namespace: aws-observability data: flb_log_cw: "false" # Set to true to ship Fluent Bit process logs to CloudWatch. filters.conf: | [FILTER] Name parser Match * Key_name log Parser crio [FILTER] Name kubernetes Match kube.* Merge_Log On Keep_Log Off Buffer_Size 0 Kube_Meta_Cache_TTL 300s output.conf: | [OUTPUT] Name cloudwatch_logs Match kube.* region region-code log_group_name my-logs log_stream_prefix from-fluent-bit- log_retention_days 60 auto_create_group true parsers.conf: | [PARSER] Name crio Format Regex Regex ^(?