**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.
# Automatisieren der Cluster-Infrastruktur mit dem EKS-Automatikmodus
**Tipp**
[Melden Sie sich](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) für bevorstehende Amazon EKS Auto Mode-Workshops an.
EKS Auto Mode erweitert die AWS Verwaltung von Kubernetes-Clustern über den Cluster selbst hinaus, sodass AWS Sie auch die Infrastruktur einrichten und verwalten können, die den reibungslosen Betrieb Ihrer Workloads ermöglicht. Sie können wichtige Infrastrukturentscheidungen delegieren und das Fachwissen von for Operations nutzen. AWS day-to-day Die Cluster-Infrastruktur, die von verwaltet wird, AWS umfasst viele Kubernetes-Funktionen als Kernkomponenten, im Gegensatz zu Add-Ons wie Compute-Autoscaling, Pod- und Service-Networking, Anwendungslastausgleich, Cluster-DNS, Blockspeicher und GPU-Unterstützung.
Für den Einstieg können Sie einen neuen EKS-Auto-Mode-Cluster bereitstellen oder EKS Auto Mode für einen vorhandenen Cluster aktivieren. Sie können Ihre EKS-Auto-Mode-Cluster mithilfe von eksctl, der AWS CLI, dem, EKS oder Ihren bevorzugten AWS-Managementkonsole infrastructure-as-code Tools bereitstellen APIs, aktualisieren oder ändern.
Mit EKS Auto Mode können Sie weiterhin Ihre bevorzugten Kubernetes-kompatiblen Tools verwenden. Der EKS Auto Mode lässt sich in AWS Dienste wie Amazon EC2, Amazon EBS und ELB integrieren und nutzt AWS Cloud-Ressourcen, die bewährten Methoden folgen. Diese Ressourcen werden automatisch skaliert, kostenoptimiert und regelmäßig aktualisiert, um die Betriebskosten und den Aufwand zu minimieren.
## Features
EKS Auto Mode bietet die folgenden allgemeinen Features:
**Optimierung der Kubernetes-Cluster-Verwaltung:**: EKS Auto Mode optimiert die EKS-Verwaltung, indem er produktionsreife Cluster mit minimalem Betriebsaufwand bereitstellt. Mit EKS Auto Mode können Sie anspruchsvolle, dynamische Workloads zuverlässig ausführen, ohne dass Sie über fundierte EKS-Kenntnisse verfügen müssen.
**Anwendungsverfügbarkeit**: EKS Auto Mode fügt basierend auf den Anforderungen Ihrer Kubernetes-Anwendungen dynamisch Knoten in Ihrem EKS-Cluster hinzu oder entfernt sie. Dies minimiert den Bedarf an manueller Kapazitätsplanung und stellt die Anwendungsverfügbarkeit sicher
**Effizienz**: Der automatische Modus von EKS wurde entwickelt, um die Rechenkosten zu optimieren und gleichzeitig die Flexibilität zu wahren, die sich aus Ihren NodePool Anforderungen und den Workload-Anforderungen ergibt. Darüber hinaus werden nicht genutzte Instances beendet und Workloads auf anderen Knoten konsolidiert, um die Kosteneffizienz zu verbessern.
**Sicherheit**: Der automatische Modus von EKS verwendet für Ihre Knoten, AMIs die als unveränderlich behandelt werden. Diese AMIs setzen gesperrte Software durch, ermöglichen SELinux obligatorische Zugriffskontrollen und bieten schreibgeschützte Root-Dateisysteme. Darüber hinaus haben von EKS Auto Mode gestartete Knoten eine maximale Lebensdauer von 21 Tagen (die Sie reduzieren können), nach deren Ablauf sie automatisch durch neue Knoten ersetzt werden. Dieser Ansatz verbessert Ihre Sicherheitslage durch regelmäßiges Knotenwechsel und entspricht den bewährten Methoden, die bereits von vielen Kunden übernommen wurden.
**Automatisierte Upgrades**: Der automatische Modus von EKS hält Ihren Kubernetes-Cluster, Ihre Knoten und die zugehörigen Komponenten auf dem neuesten Stand und berücksichtigt gleichzeitig Ihre konfigurierten Pod-Disruption-Budgets () und Disruption-Budgets (PDBs). NodePool NDBs Bis zur maximalen Lebensdauer von 21 Tagen kann ein Eingreifen erforderlich sein, wenn Blockierungen PDBs oder andere Konfigurationen Updates verhindern.
**Verwaltete Komponenten**: Der automatische Modus von EKS umfasst Kubernetes- und AWS Cloud-Funktionen als Kernkomponenten, die andernfalls als Add-Ons verwaltet werden müssten. Dazu gehören integrierter Support für die Zuweisung von Pod-IP-Adressen, Pod-Netzwerkrichtlinien, lokale DNS-Services, GPU-Plug-ins, Zustandsprüfungen und EBS-CSI-Speicher.
**Anpassbar NodePools und NodeClasses**: Wenn Ihr Workload Änderungen an Speicher-, Rechen- oder Netzwerkkonfigurationen erfordert, können Sie benutzerdefinierte Konfigurationen erstellen NodePools und den EKS Auto Mode NodeClasses verwenden. Sie sollten die NodePools Standardkonfigurationen zwar nicht bearbeiten NodeClasses, aber Sie können neue benutzerdefinierte Konfigurationen NodePools oder NodeClasses zusätzlich zu den Standardkonfigurationen hinzufügen, um Ihren spezifischen Anforderungen gerecht zu werden.
## Automatisierte Komponenten
EKS Auto Mode optimiert den Betrieb Ihrer Amazon-EKS-Cluster durch die Automatisierung wichtiger Infrastruktur-Komponenten. Durch die Aktivierung von EKS Auto Mode werden die Aufgaben zur Verwaltung Ihrer EKS-Cluster weiter reduziert.
Nachfolgend finden Sie eine Liste der automatisierten Datenebenen-Komponenten:
+ **Rechenleistung**: Bei vielen Workloads können Sie mit EKS Auto Mode zahlreiche Aspekte der Rechenleistung für Ihre EKS-Cluster außer Acht lassen. Dazu zählen:
+ **Knoten**: Knoten in EKS Auto Mode sind so konzipiert, dass sie wie Geräte behandelt werden. EKS Auto Mode führt Folgendes durch:
+ Wählt ein geeignetes AMI, das mit vielen Services konfiguriert ist, die zum Ausführen Ihrer Workloads ohne Eingriff erforderlich sind.
+ Sperrt den Zugriff auf Dateien im AMI mithilfe des SELinux Erzwingungsmodus und eines schreibgeschützten Root-Dateisystems.
+ Verhindert den direkten Zugriff auf die Knoten, indem SSH- oder SSM-Zugriffe untersagt werden.
+ Beinhaltet GPU-Unterstützung mit separaten Kernel-Treibern und Plug-ins für NVIDIA und Neuron GPUs, was Hochleistungs-Workloads ermöglicht.
+ Verarbeitet automatisch [Benachrichtigungen über Unterbrechungen von EC2-Spot-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html) und Zustandsereignisse von EC2-Instances.
+ **Auto Scaling**: EKS Auto Mode basiert auf Auto Scaling von [Karpenter](https://karpenter.sh/docs/), überwacht nicht planbare Pods und ermöglicht die Bereitstellung neuer Knoten zum Ausführen dieser Pods. Wenn Workloads beendet werden, unterbricht EKS Auto Mode dynamisch die Knoten und beendet sie, wenn sie nicht mehr benötigt werden, wodurch die Ressourcennutzung optimiert wird.
+ **Upgrades**: Durch die Übernahme der Kontrolle über Ihre Knoten kann EKS Auto Mode bei Bedarf Sicherheits-Patches sowie Betriebssystem- und Komponenten-Upgrades bereitstellen. Diese Upgrades sind so konzipiert, dass sie Ihre Workloads nur minimal beeinträchtigen. Der automatische EKS-Modus erzwingt eine maximale Knotenlebensdauer von 21 Tagen, um sicherzustellen, dass Software und. up-to-date APIs
+ **Load Balancing**: EKS Auto Mode optimiert das Load Balancing durch die Integration mit dem Amazon-Service Elastic Load Balancing und automatisiert die Bereitstellung und Konfiguration von Load-Balancing-Modulen für Kubernetes-Services und Ingress-Ressourcen. Es unterstützt erweiterte Feature für Anwendungs- und Netzwerk-Load-Balancer, verwaltet deren Lebenszyklus und skaliert sie entsprechend den Cluster-Anforderungen. Diese Integration bietet eine einsatzbereite Load-Balancing-Lösung, die den AWS Best Practices entspricht, sodass Sie sich auf Anwendungen statt auf das Infrastrukturmanagement konzentrieren können.
+ **Speicher**: EKS Auto Mode konfiguriert flüchtigen Speicher für Sie, indem er Volumentypen, Volumengrößen, Verschlüsselungsrichtlinien und Löschrichtlinien bei Beendigung des Knotens einrichtet.
+ **Netzwerk**: EKS Auto Mode automatisiert wichtige Netzwerkaufgaben für die Pod- und Service-Konnektivität. Dazu gehören IPv4 IPv6 /-Unterstützung und die Verwendung sekundärer CIDR-Blöcke zur Erweiterung von IP-Adressräumen.
+ **Identitäts- und Zugriffsverwaltung**: Es ist nicht erforderlich, den EKS Pod Identity Agent in Clustern in EKS Auto Mode zu installieren.
Weitere Informationen zu diesen Komponenten finden Sie unter [Weitere Informationen zur Funktionsweise von EKS Auto Mode](auto-reference.md).
## Konfiguration
Obwohl EKS Auto Mode die meisten Ihrer Datenebenen-Services ohne Ihr Zutun effektiv verwaltet, kann es vorkommen, dass Sie das Verhalten einiger dieser Services ändern möchten. Sie können die Konfiguration Ihrer Cluster in EKS Auto Mode auf folgende Weise ändern:
+ **Kubernetes DaemonSets**: Anstatt die auf Ihren Knoten installierten Dienste zu ändern, können Sie stattdessen Kubernetes-Daemonsets verwenden. DaemonSets sind so konzipiert, dass sie von Kubernetes verwaltet werden, jedoch auf jedem Knoten im Cluster ausgeführt werden. Auf diese Weise können Sie spezielle Services für die Überwachung oder sonstige Beobachtung Ihrer Knoten hinzufügen.
+ **Benutzerdefiniert NodePools und NodeClasses**: Standard NodePools und NodeClasses werden von EKS Auto Mode konfiguriert und sollten nicht bearbeitet werden. Um das Verhalten von Knoten anzupassen, können Sie zusätzliche NodePools oder NodeClasses für folgende Anwendungsfälle erstellen:
+ Auswahl bestimmter Instance-Typen (z. B. beschleunigte Prozessoren oder EC2-Spot-Instances).
+ Isolierung von Workloads aus Sicherheits- oder Kostenverfolgungsgründen.
+ Konfiguration von Einstellungen für flüchtigen Speicher wie IOPS, Größe und Durchsatz.
+ **Load Balancing**: Bestimmte Services, wie beispielsweise Load Balancing, die EKS Auto Mode als Kubernetes-Objekte ausführen, können direkt auf Ihren EKS-Auto-Mode-Clustern konfiguriert werden.
Weitere Informationen zu den Optionen für die Konfiguration von EKS Auto Mode finden Sie unter [EKS-Auto-Mode-Einstellungen konfigurieren](settings-auto.md).
## Modell der geteilten Verantwortung
Das Modell der AWS gemeinsamen Verantwortung definiert die Sicherheits- und Compliance-Verantwortlichkeiten zwischen Kunden AWS und Kunden. Die Bilder und der Text unten vergleichen und verdeutlichen, wie sich Kunden und AWS Zuständigkeiten zwischen dem EKS-Automodus und dem EKS-Standardmodus unterscheiden.
![\[Modell der geteilten Verantwortung mit EKS Auto Mode und Standardmodus\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/eksautosrm.png)
EKS Auto Mode verlagert einen Großteil der gemeinsamen Verantwortung für die Kubernetes-Infrastruktur von den Kunden auf AWS. Mit EKS Auto Mode AWS übernimmt EKS mehr Verantwortung für die Cloud-Sicherheit, die früher in der Verantwortung des Kunden lag und nun gemeinsam genutzt wird. Kunden können sich jetzt mehr auf ihre Anwendungen konzentrieren und gleichzeitig die zugrunde liegende Infrastruktur AWS verwalten.
**Kundenverantwortung**
In EKS Auto Mode behalten Kunden weiterhin die Verantwortung für die Anwendungs-Container, einschließlich Verfügbarkeit, Sicherheit und Überwachung. Sie behalten auch die Kontrolle über die VPC-Infrastruktur und die EKS-Cluster-Konfiguration. Dieses Modell ermöglicht es Kunden, sich auf anwendungsspezifische Belange zu konzentrieren und gleichzeitig die Verwaltung der Cluster-Infrastruktur an diese zu delegieren. AWS Optionale Funktionen pro Knoten können über Add-Ons in Cluster integriert werden. AWS
** AWS -Verantwortung**
Mit dem automatischen Modus von EKS AWS erweitert sich seine Verantwortung um die Verwaltung mehrerer zusätzlicher kritischer Komponenten im Vergleich zu den Komponenten, die bereits in EKS-Clustern verwaltet werden, die den automatischen Modus nicht verwenden. Insbesondere übernimmt EKS Auto Mode die Konfiguration, Verwaltung, Sicherheit und Skalierung der gestarteten EC2-Instances sowie Cluster-Funktionen für Lastenausgleich, IP-Adressverwaltung, Netzwerkrichtlinien und Blockspeicher. Die folgenden Komponenten werden AWS im EKS-Automodus verwaltet:
+ Im **automatischen Modus gestartete EC2-Instances**: AWS wickelt den gesamten Lebenszyklus von Knoten ab, indem Amazon EC2 EC2-verwaltete Instances genutzt werden. Von EC2 verwaltete Instances übernehmen die Verantwortung für die Konfiguration des Betriebssystems, das Patchen, die Überwachung und die Aufrechterhaltung der Funktionsfähigkeit. In diesem Modell liegen sowohl die Instance selbst als auch das darauf ausgeführte Gastbetriebssystem in der Verantwortung von AWS. Die Knoten verwenden Varianten von [Bottlerocket, die für den Betrieb von Containern optimiert](https://aws.amazon.com/bottlerocket) AMIs sind. Die Bottlerocket AMIs verfügen über gesperrte Software, unveränderliche Root-Dateisysteme und sicheren Netzwerkzugriff (um direkte Kommunikation über SSH oder SSM zu verhindern).
+ **Cluster-Funktionen**: AWS verwaltet automatische Rechenskalierung, Pod-Netzwerke mit Durchsetzung von Netzwerkrichtlinien, Elastic Load Balancing Balancing-Integration und Speichertreiberkonfiguration.
+ **Cluster Control Plane**: AWS Verwaltet weiterhin den Kubernetes-API-Server, Cros-Accounts ENIs und die etcd-Datenbank wie bei Standard-EKS.
+ **Foundation Services und globale Infrastruktur**: AWS behält die Verantwortung für die zugrunde liegenden Rechen-, Speicher-, Netzwerk- und Überwachungsdienste sowie für die globale Infrastruktur von Regionen, lokalen Zonen und Edge-Standorten.
# Einen Cluster mit Amazon EKS Auto Mode erstellen
In diesem Kapitel wird erläutert, wie Sie mithilfe verschiedener Tools und Schnittstellen einen Amazon-EKS-Cluster mit Auto Mode erstellen. Auto Mode vereinfacht die Cluster-Erstellung durch die automatische Konfiguration und Verwaltung der Rechen-, Netzwerk- und Speicherinfrastruktur des Clusters. Sie erfahren, wie Sie mithilfe der AWS-CLI, AWS-Managementkonsole oder des Befehlszeilentools eksctl einen Auto-Mode-Cluster erstellen.
**Anmerkung**
EKS Auto Mode erfordert Kubernetes Version 1.29 oder höher.
Wählen Sie Ihr bevorzugtes Tool entsprechend Ihren Anforderungen: Die AWS-Managementkonsole bietet eine visuelle Benutzeroberfläche, die sich ideal zum Kennenlernen der Feature von EKS Auto Mode und zum Erstellen einzelner Cluster eignet. Die AWS-CLI eignet sich am besten für Skripting- und Automatisierungsaufgaben, insbesondere bei der Integration der Cluster-Erstellung in vorhandene Workflows oder CI/CD-Pipelines. Die eksctl-CLI bietet eine Kubernetes-native Erfahrung und wird Benutzern empfohlen, die mit Kubernetes-Tools vertraut sind und vereinfachte Befehlszeilenvorgänge mit sinnvollen Standardeinstellungen wünschen.
Stellen Sie vor Beginn sicher, dass Sie über die erforderlichen Voraussetzungen verfügen, einschließlich der entsprechenden IAM-Berechtigungen zum Erstellen von EKS-Clustern. Informationen zur Installation von CLI-Tools wie `kubectl`, `aws` und `eksctl` finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
Sie können die AWS-CLI, AWS-Managementkonsole, oder die eksctl CLI verwenden, um einen Cluster mit Amazon EKS Auto Mode zu erstellen.
**Topics**
+ [
# Erstellung eines EKS-Auto-Mode-Clusters mit der eksctl-Befehlszeilenschnittstelle
](automode-get-started-eksctl.md)
+ [
# Erstellen Sie einen EKS-Auto-Mode-Cluster mit der AWS CLI
](automode-get-started-cli.md)
+ [
# Erstellung eines EKS-Auto-Mode-Clusters mit AWS-Managementkonsole
](automode-get-started-console.md)
# Erstellung eines EKS-Auto-Mode-Clusters mit der eksctl-Befehlszeilenschnittstelle
In diesem Abschnitt wird erläutert, wie Sie einen EKS-Auto-Mode-Cluster mithilfe der Befehlszeilenschnittstelle (CLI) eksctl erstellen. Sie können einen EKS-Auto-Mode-Cluster entweder durch Ausführen eines einzelnen CLI-Befehls oder durch Anwenden einer YAML-Konfigurationsdatei erstellen. Beide Methoden bieten die gleiche Funktionalität, wobei der YAML-Ansatz eine detailliertere Kontrolle über die Cluster-Einstellungen ermöglicht.
Die eksctl CLI vereinfacht den Prozess der Erstellung und Verwaltung von EKS-Auto-Mode-Clustern, indem sie die Erstellung und Konfiguration der zugrunde liegenden AWS-Ressourcen übernimmt. Stellen Sie vor dem Fortfahren sicher, dass Sie die erforderlichen AWS-Anmeldeinformationen und Berechtigungen auf Ihrem lokalen Rechner konfiguriert haben. Dieser Leitfaden setzt voraus, dass Sie mit den grundlegenden Konzepten von Amazon EKS vertraut sind und die erforderlichen CLI-Tools bereits installiert haben.
**Anmerkung**
Sie müssen die Version `0.195.0` oder höher von eksctl installieren. Weitere Informationen finden Sie unter [eksctl-Versionen](https://github.com/eksctl-io/eksctl/releases) auf GitHub.
## Erstellung eines EKS-Auto-Mode-Clusters mit einem CLI-Befehl
Sie müssen die `aws`- und `eksctl`-Tools installiert haben. Sie müssen bei der AWS-CLI mit ausreichenden Berechtigungen angemeldet sein, um AWS-Ressourcen zu verwalten, darunter: EC2-Instances, EC2-Netzwerke, EKS-Cluster und IAM-Rollen. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
Führen Sie den folgenden Befehl aus, um einen neuen EKS-Auto-Mode-Cluster zu erstellen
```
eksctl create cluster --name= --enable-auto-mode
```
## Erstellung eines EKS-Auto-Mode-Clusters mit einer YAML-Datei
Sie müssen die `aws`- und `eksctl`-Tools installiert haben. Sie müssen bei der AWS-CLI mit ausreichenden Berechtigungen angemeldet sein, um AWS-Ressourcen zu verwalten, darunter: EC2-Instances, EC2-Netzwerke, EKS-Cluster und IAM-Rollen. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
Überprüfen Sie die Konfigurationsoptionen für EKS Auto Mode in der folgenden Beispiel-ClusterConfig-Ressource. Die vollständige ClusterConfig-Spezifikation finden Sie in der [eksctl-Dokumentation](https://eksctl.io/usage/creating-and-managing-clusters/).
AWS empfiehlt, EKS Auto Mode zu aktivieren. Sollten Sie zum ersten Mal einen EKS-Auto-Mode-Cluster erstellen, lassen Sie `nodeRoleARN` unverändert, um eine Knoten-IAM-Rolle für EKS Auto Mode zu erstellen. Wenn Sie bereits über eine Knoten-IAM-Rolle in Ihrem AWS-Konto verfügen, empfiehlt AWS, diese wiederzuverwenden.
AWS empfiehlt, keinen Wert für `nodePools` anzugeben. EKS Auto Mode erstellt Standard-Knoten-Pools. Sie können die Kubernetes-API verwenden, um zusätzliche Knoten-Pools zu erstellen.
```
# cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name:
region:
iam:
# ARN of the Cluster IAM Role
# optional, eksctl creates a new role if not supplied
# suggested to use one Cluster IAM Role per account
serviceRoleARN:
autoModeConfig:
# defaults to false
enabled: boolean
# optional, defaults to [general-purpose, system].
# suggested to leave unspecified
# To disable creation of nodePools, set it to the empty array ([]).
nodePools: []string
# optional, eksctl creates a new role if this is not supplied
# and nodePools are present.
nodeRoleARN: string
```
Speichern Sie die `ClusterConfig`-Datei als `cluster.yaml` und verwenden Sie den folgenden Befehl, um den Cluster zu erstellen:
```
eksctl create cluster -f cluster.yaml
```
# Erstellen Sie einen EKS-Auto-Mode-Cluster mit der AWS CLI
EKS-Auto-Mode-Cluster automatisieren routinemäßige Cluster-Verwaltungsaufgaben für Rechenleistung, Speicher und Netzwerke. EKS-Auto-Mode-Cluster erkennen beispielsweise automatisch, wenn zusätzliche Knoten erforderlich sind, und stellen neue EC2-Instances bereit, um den Workload-Anforderungen gerecht zu werden.
Dieses Thema führt Sie durch die Erstellung eines neuen EKS-Auto-Mode-Clusters mithilfe der AWS CLI und optional durch die Bereitstellung eines Beispiel-Workloads.
## Voraussetzungen
+ Die neueste Version der AWS Befehlszeilenschnittstelle (AWS CLI) ist auf Ihrem Gerät installiert und konfiguriert. Um Ihre aktuelle Version zu überprüfen, verwenden Sie `aws --version`. Informationen zur Installation der neuesten Version finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) und [Schnellkonfiguration](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config) mit aws configure im Benutzerhandbuch für die AWS Befehlszeilenschnittstelle.
+ Melden Sie sich mit ausreichenden IAM-Berechtigungen bei der CLI an, um AWS Ressourcen wie IAM-Richtlinien, IAM-Rollen und EKS-Cluster zu erstellen.
+ Das kubectl-Befehlszeilentool, das auf Ihrem Gerät installiert ist. AWS schlägt vor, dass Sie dieselbe kubectl-Version wie die Kubernetes-Version Ihres EKS-Clusters verwenden. Informationen zum Installieren von kubectl finden Sie unter [`kubectl` und `eksctl` einrichten](install-kubectl.md).
## Angabe von VPC-Subnetzen
Amazon EKS Auto Mode stellt Knoten in VPC-Subnetzen bereit. Beim Erstellen eines EKS-Clusters müssen Sie die VPC-Subnetze angeben, in denen die Knoten bereitgestellt werden sollen. Sie können die Standard-VPC-Subnetze in Ihrem AWS Konto verwenden oder eine dedizierte VPC für kritische Workloads erstellen.
+ AWS schlägt vor, eine dedizierte VPC für Ihren Cluster zu erstellen. Weitere Informationen erhalten Sie unter [Erstellung einer Amazon VPC für Ihren Amazon-EKS-Cluster](creating-a-vpc.md).
+ Die EKS-Konsole unterstützt Sie bei der Erstellung einer neuen VPC. Weitere Informationen erhalten Sie unter [Erstellung eines EKS-Auto-Mode-Clusters mit AWS-Managementkonsole](automode-get-started-console.md).
+ Alternativ können Sie die Standard-VPC Ihres AWS Kontos verwenden. Verwenden Sie die folgenden Anweisungen, um das IDs Subnetz zu finden.
### So finden Sie das Subnetz IDs Ihrer Standard-VPC
**Verwenden der AWS CLI:**
1. Führen Sie den folgenden Befehl aus, um die Standard-VPC und ihre Subnetze aufzulisten:
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$(aws ec2 describe-vpcs --query 'Vpcs[?IsDefault==`true`].VpcId' --output text)" --query 'Subnets[*].{ID:SubnetId,AZ:AvailabilityZone}' --output table
```
1. Speichern Sie die Ausgabe und notieren Sie sich das **Subnetz IDs**.
Beispielausgabe:
```
----------------------------------------
| DescribeSubnets |
----------------------------------------
| SubnetId | AvailabilityZone |
|--------------------|---------------------|
| subnet-012345678 | us-west-2a |
| subnet-234567890 | us-west-2b |
| subnet-345678901 | us-west-2c |
----------------------------------------
```
## IAM-Rollen für Cluster in EKS Auto Mode
### Cluster-IAM-Rolle
Der automatische EKS-Modus erfordert eine Cluster-IAM-Rolle, um Aktionen in Ihrem AWS Konto auszuführen, z. B. die Bereitstellung neuer EC2-Instances. Sie müssen diese Rolle erstellen, um EKS die erforderlichen Berechtigungen zu erteilen. AWS empfiehlt, die folgenden AWS verwalteten Richtlinien an die Cluster-IAM-Rolle anzuhängen:
+ [EKSComputeAmazon-Richtlinie](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [EKSNetworkingAmazon-Richtlinie](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [EKSClusterAmazon-Richtlinie](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
### Knoten-IAM-Rolle
Wenn Sie einen EKS-Auto-Mode-Cluster erstellen, geben Sie eine IAM-Rolle für den Knoten an. Wenn EKS Auto Mode Knoten zur Verarbeitung ausstehender Workloads erstellt, wird jedem neuen EC2-Instance-Knoten die Knoten-IAM-Rolle zugewiesen. Diese Rolle ermöglicht es dem Knoten, mit EKS zu kommunizieren, wird jedoch in der Regel nicht von den auf dem Knoten ausgeführten Workloads aufgerufen.
Wenn Sie Workloads, die auf einem Knoten ausgeführt werden, Berechtigungen gewähren möchten, verwenden Sie EKS Pod Identity. Weitere Informationen finden Sie unter [Erfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt](pod-identities.md).
Sie müssen diese Rolle erstellen und die folgende AWS verwaltete Richtlinie anhängen:
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
EKS Auto Mode erfordert außerdem eine serviceverknüpfte Rolle, die automatisch von AWS erstellt und konfiguriert wird. Weitere Informationen finden Sie unter [AWSServiceRoleForAmazonEKS](using-service-linked-roles-eks.md).
## Erstellung einer IAM-Rolle für einen Cluster in EKS Auto Mode
### Schritt 1: Vertrauensrichtlinie erstellen
Erstellen Sie eine Vertrauensrichtlinie, mit welcher der Amazon-EKS-Service die Rolle übernehmen kann. Speichern Sie die Richtlinie als `trust-policy.json`:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### Schritt 2: Erstellen der IAM-Rolle
Verwenden Sie die Vertrauensrichtlinie, um die Cluster-IAM-Rolle zu erstellen:
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://trust-policy.json
```
### Schritt 3: Rollen-ARN notieren
Rufen Sie die ARN der neuen Rolle ab und speichern Sie sie für die Verwendung in den folgenden Schritten:
```
aws iam get-role --role-name AmazonEKSAutoClusterRole --query "Role.Arn" --output text
```
### Schritt 4: Erforderliche Richtlinien hinzufügen
Fügen Sie der Cluster-IAM-Rolle die folgenden AWS verwalteten Richtlinien hinzu, um die erforderlichen Berechtigungen zu gewähren:
**EKSClusterAmazon-Richtlinie**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
```
**EKSComputeAmazon-Richtlinie**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSComputePolicy
```
**Amazon EKSBlock StoragePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**Amazon EKSLoad BalancingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**EKSNetworkingAmazon-Richtlinie**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSNetworkingPolicy
```
## Erstellung einer Knoten-IAM-Rolle in EKS Auto Mode
### Schritt 1: Vertrauensrichtlinie erstellen
Erstellen Sie eine Vertrauensrichtlinie, mit welcher der Amazon-EKS-Service die Rolle übernehmen kann. Speichern Sie die Richtlinie als `node-trust-policy.json`:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
#### Schritt 2: Knoten-IAM-Rolle erstellen
Verwenden Sie die **node-trust-policyJSON-Datei** aus dem vorherigen Schritt, um zu definieren, welche Entitäten die Rolle übernehmen können. Führen Sie den folgenden Befehl aus, um die Knoten-IAM-Rolle zu erstellen:
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
#### Schritt 3: Rollen-ARN notieren
Rufen Sie nach dem Erstellen der Rolle die ARN der Knoten-IAM-Rolle ab und speichern Sie sie. Sie benötigen diese ARN in den nachfolgenden Schritten. Um die ARN abzurufen, verwenden Sie den folgenden Befehl.
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
#### Schritt 4: Erforderliche Richtlinien hinzufügen
Fügen Sie der Node-IAM-Rolle die folgenden AWS verwalteten Richtlinien hinzu, um die erforderlichen Berechtigungen bereitzustellen:
**Amazon EKSWorker NodeMinimalPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
**Amazon EC2 ContainerRegistryPullOnly**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
## Erstellung eines Clusters in EKS Auto Mode
### -Übersicht
Um einen EKS-Auto-Mode-Cluster mit der AWS CLI zu erstellen, benötigen Sie die folgenden Parameter:
+ `cluster-name`: Der Name des Clusters.
+ `k8s-version`: Die Kubernetes-Version (z. B. 1.31).
+ `subnet-ids`: In den vorherigen Schritten IDs identifiziertes Subnetz.
+ `cluster-role-arn`: ARN der Cluster-IAM-Rolle.
+ `node-role-arn`: ARN der Knoten-IAM-Rolle.
#### Standard-Cluster-Konfigurationen
Überprüfen Sie diese Standardwerte und Feature, bevor Sie den Cluster erstellen:
+ `nodePools`: EKS Auto Mode beinhaltet universelle und systemseitige Standard-Knoten-Pools. Weitere Informationen zu [Knoten-Pools](create-node-pool.md)
**Hinweis:** Knoten-Pools in EKS Auto Mode unterscheiden sich von Amazon EKS verwalteten Knotengruppen, können jedoch im selben Cluster koexistieren.
+ `computeConfig.enabled`: Automatisiert routinemäßige Rechenaufgaben, wie das Erstellen und Löschen von EC2-Instances.
+ `kubernetesNetworkConfig.elasticLoadBalancing.enabled`: Automatisiert Load-Balancing-Aufgaben, einschließlich des Erstellens und Löschens von Elastic Load Balancers.
+ `storageConfig.blockStorage.enabled`: Automatisiert Speicheraufgaben, wie das Erstellen und Löschen von Amazon-EBS-Volumes.
+ `accessConfig.authenticationMode`: Erfordert EKS-Zugriffseinträge. Weitere Informationen zu [EKS-Authentifizierungsmodi](grant-k8s-access.md).
#### Ausführen des Befehls
Verwenden Sie den folgenden Befehl, um den Cluster zu erstellen:
```
aws eks create-cluster \
--region ${AWS_REGION} \
--cli-input-json \
"{
\"name\": \"${CLUSTER_NAME}\",
\"version\": \"${K8S_VERSION}\",
\"roleArn\": \"${CLUSTER_ROLE_ARN}\",
\"resourcesVpcConfig\": {
\"subnetIds\": ${SUBNETS_JSON},
\"endpointPublicAccess\": true,
\"endpointPrivateAccess\": true
},
\"computeConfig\": {
\"enabled\": true,
\"nodeRoleArn\":\"${NODE_ROLE_ARN}\",
\"nodePools\": [\"general-purpose\", \"system\"]
},
\"kubernetesNetworkConfig\": {
\"elasticLoadBalancing\": {
\"enabled\": true
}
},
\"storageConfig\": {
\"blockStorage\": {
\"enabled\": true
}
},
\"accessConfig\": {
\"authenticationMode\": \"API\"
}
}"
```
### Cluster-Status überprüfen
#### Schritt 1: Cluster-Erstellung überprüfen
Führen Sie den folgenden Befehl aus, um den Status Ihres Clusters zu überprüfen. Die Cluster-Erstellung dauert in der Regel 15 Minuten.
```
aws eks describe-cluster --name "${CLUSTER_NAME}" --output json
```
#### Schritt 2: kubeconfig aktualisieren
Sobald der Cluster bereit ist, aktualisieren Sie Ihre lokale kubeconfig-Datei, um die Kommunikation zwischen `kubectl` und dem Cluster zu ermöglichen. Diese Konfiguration verwendet die AWS CLI für die Authentifizierung.
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
#### Schritt 3: Knoten-Pools überprüfen
Listen Sie die Knoten-Pools in Ihrem Cluster mit dem folgenden Befehl auf:
```
kubectl get nodepools
```
## Nächste Schritte
+ Erfahren Sie, wie Sie einen [Beispiel-Workload in Ihrem neuen Cluster in EKS Auto Mode bereitstellen](automode-workload.md).
# Erstellung eines EKS-Auto-Mode-Clusters mit AWS-Managementkonsole
Die Erstellung eines EKS-Auto-Mode-Clusters in AWS-Managementkonsole erfordert weniger Konfigurationsaufwand als andere Optionen. EKS lässt sich in AWS IAM- und VPC-Netzwerke integrieren, um Sie bei der Erstellung der einem EKS-Cluster zugeordneten Ressourcen zu unterstützen.
Sie haben zwei Möglichkeiten, einen Cluster in der Konsole zu erstellen:
+ Schnellkonfiguration (mit EKS Auto Mode)
+ Benutzerdefinierte Konfiguration
In diesem Abschnitt erfahren Sie, wie Sie einen EKS-Auto-Mode-Cluster mithilfe der Schnellkonfigurations-Option erstellen.
## Erstellung von EKS Auto Mode mithilfe der Schnellkonfigurations-Option
Sie müssen mit ausreichenden Berechtigungen bei AWS-Managementkonsole angemeldet sein, um AWS-Ressourcen verwalten zu können, darunter: EC2-Instances, EC2-Netzwerke, EKS-Cluster und IAM-Rollen.
1. Navigieren Sie zur EKS-Konsole
1. Klicken Sie auf **Cluster erstellen**
1. Bestätigen Sie, dass die Option **Schnellkonfiguration** ausgewählt ist
1. Ermitteln Sie die folgenden Werte oder verwenden Sie die Standardwerte für einen Test-Cluster.
+ Cluster-**Name**
+ Kubernetes-Version
1. Wählen Sie die Cluster-IAM-Rolle aus. Wenn Sie zum ersten Mal einen EKS-Cluster im Automatikmodus erstellen, verwenden Sie die Option **Empfohlene Rolle erstellen**.
+ Optional können Sie eine einzelne Cluster-IAM-Rolle in Ihrem AWS-Konto für alle EKS-Auto-Mode-Cluster wiederverwenden.
+ Die Cluster-IAM-Rolle enthält die erforderlichen Berechtigungen für EKS Auto Mode, um Ressourcen wie EC2-Instances, EBS-Volumes und EC2 Load-Balancer zu verwalten.
+ Die Option **Empfohlene Rolle erstellen** füllt alle Felder mit empfohlenen Werten vorab aus. Wählen Sie **Weiter** und dann **Erstellen** aus. Die Rolle wird den vorgeschlagenen `AmazonEKSAutoClusterRole`-Namen verwenden.
+ Wenn Sie kürzlich eine neue Rolle erstellt haben, verwenden Sie das Symbol **Aktualisieren**, um die Dropdown-Liste für die Rollenauswahl neu zu laden.
1. Wählen Sie die Knoten-IAM-Rolle aus. Wenn Sie zum ersten Mal einen EKS-Cluster im Automatikmodus erstellen, verwenden Sie die Option **Empfohlene Rolle erstellen**.
+ Optional können Sie eine einzelne Knoten-IAM-Rolle in Ihrem AWS-Konto für alle EKS-Auto-Mode-Cluster wiederverwenden.
+ Die Knoten-IAM-Rolle enthält die erforderlichen Berechtigungen für Knoten im Automatikmodus, um eine Verbindung zum Cluster herzustellen. Die Knoten-IAM-Rolle muss Berechtigungen zum Abrufen von ECR-Images für Ihre Container enthalten.
+ Die Option **Empfohlene Rolle erstellen** füllt alle Felder mit empfohlenen Werten vorab aus. Wählen Sie **Weiter** und dann **Erstellen** aus. Die Rolle wird den vorgeschlagenen `AmazonEKSAutoNodeRole`-Namen verwenden.
+ Wenn Sie kürzlich eine neue Rolle erstellt haben, verwenden Sie das Symbol **Aktualisieren**, um die Dropdown-Liste für die Rollenauswahl neu zu laden.
1. Wählen Sie die VPC für Ihren EKS-Auto-Mode-Cluster aus. Wählen Sie **VPC erstellen**, um eine neue VPC für EKS zu erstellen, oder wählen Sie eine VPC aus, die Sie zuvor für EKS erstellt haben.
+ Wenn Sie die VPC-Konsole zum Erstellen einer neuen VPC verwenden, empfiehlt AWS, mindestens ein NAT-Gateway pro Availability Zone zu erstellen. Andernfalls können Sie alle anderen Standardeinstellungen verwenden.
+ Weitere Informationen und Details zu den Anforderungen für IPv6-Cluster finden Sie unter [Erstellung einer Amazon VPC für Ihren Amazon-EKS-Cluster](creating-a-vpc.md).
1. (Optional) EKS Auto Mode füllt automatisch die privaten Subnetze für die von Ihnen ausgewählte VPC. Sie können unerwünschte Subnetze entfernen.
+ EKS wählt automatisch private Subnetze aus der VPC gemäß bewährten Methoden aus. Optional können Sie zusätzliche Subnetze aus der VPC auswählen, beispielsweise öffentliche Subnetze.
1. (optional) Wählen Sie **Standardeinstellungen für die Schnellkonfiguration anzeigen** aus, um alle Konfigurationseinstellungen für den neuen Cluster zu überprüfen. Die Tabelle zeigt, dass einige Werte nach der Erstellung des Clusters nicht mehr bearbeitet werden können.
1. Wählen Sie **Cluster erstellen** aus. Beachten Sie, dass die Erstellung des Clusters bis zu fünfzehn Minuten dauern kann.
## Nächste Schritte
+ Erfahren Sie, wie Sie eine [Beispiel-Workload in Ihrem Cluster in EKS Auto Mode bereitstellen](sample-storage-workload.md).
# Aktivierung von EKS Auto Mode in vorhandenen EKS-Clustern
Sie können EKS Auto Mode in vorhandenen EKS-Clustern aktivieren.
** AWS unterstützt die folgenden Migrationen:**
+ Migration von Karpenter zu Knoten in EKS Auto Mode. Weitere Informationen finden Sie unter [Migration von Karpenter zu EKS Auto Mode mithilfe von kubectl](auto-migrate-karpenter.md).
+ Migration von EKS-verwalteten Knotengruppen zu Knoten in EKS Auto Mode. Weitere Informationen finden Sie unter [Migration von EKS-verwalteten Knotengruppen zu EKS Auto Mode](auto-migrate-mng.md).
+ Migration von EKS Fargate zu EKS Auto Mode. Weitere Informationen finden Sie unter [Migration von EKS Fargate zu EKS Auto Mode](auto-migrate-fargate.md).
** AWS unterstützt die folgenden Migrationen nicht:**
+ Migration von Volumes vom EBS-CSI-Controller (mithilfe des Amazon-EKS-Add-Ons) zum EBS-CSI-Controller in EKS Auto Mode (verwaltet durch EKS Auto Mode). Mit dem einen Controller erstellte PVCs können nicht vom anderen Controller eingebunden werden, da sie zwei verschiedene Kubernetes-Volume-Bereitsteller verwenden.
+ The [https://github.com/awslabs/eks-auto-mode-ebs-migration-tool](https://github.com/awslabs/eks-auto-mode-ebs-migration-tool) (AWS-Labs-Projekt) ermöglicht die Migration zwischen Standard EBS CSI StorageClass (`ebs.csi.aws.com`) und EKS Auto EBS CSI StorageClass (`ebs.csi.eks.amazonaws.com`). Beachten Sie, dass für die Migration das Löschen und Neuerstellen vorhandener PersistentVolumeClaim/PersistentVolume-Ressourcen erforderlich ist. Daher ist vor der Implementierung eine Validierung in einer Nicht-Produktionsumgebung unerlässlich.
+ Migration von Load Balancern vom AWS Load Balancer Controller zu EKS Auto Mode
Sie können den AWS Load Balancer Controller auf einem Cluster in Amazon EKS Auto Mode installieren. Verwenden Sie die Optionen `IngressClass` oder `loadBalancerClass`, um Service- und Ingress-Ressourcen entweder dem Load Balancer Controller oder EKS Auto Mode zuzuordnen.
+ Migration von EKS-Clustern mit alternativen CNIs oder anderen nicht unterstützten Netzwerk-Konfigurationen
## Migrationsreferenz
Verwenden Sie die folgende Migrationsreferenz, um Kubernetes-Ressourcen so zu konfigurieren, dass sie entweder selbstverwalteten Controllern oder EKS Auto Mode zugeordnet sind.
| Funktion | Ressource | Feld | Selbstverwaltet | EKS Auto Mode |
| --- | --- | --- | --- | --- |
| Blockspeicher | `StorageClass` | `provisioner` | `ebs.csi.aws.com` | `ebs.csi.eks.amazonaws.com` |
| Load Balancing | `Service` | `loadBalancerClass` | `service.k8s.aws/nlb` | `eks.amazonaws.com/nlb` |
| Load Balancing | `IngressClass` | `controller` | `ingress.k8s.aws/alb` | `eks.amazonaws.com/alb` |
| Load Balancing | `IngressClassParams` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| Load Balancing | `TargetGroupBinding` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| Computing | `NodeClass` | `apiVersion` | `karpenter.sh/v1` | `eks.amazonaws.com/v1` |
## Migration von EBS-Volumes
Bei der Migration von Workloads in EKS Auto Mode ist es aufgrund unterschiedlicher CSI-Treiber-Bereitsteller erforderlich, die Migration von EBS-Volumes zu berücksichtigen:
+ EKS-Auto-Mode-Bereitsteller: `ebs.csi.eks.amazonaws.com`
+ Open-Source-EBS-CSI-Bereitsteller: `ebs.csi.aws.com`
Führen Sie die folgenden Schritte aus, um Ihre persistenten Volumes zu migrieren:
1. **Volume-Aufbewahrungsrichtlinie ändern**: Ändern Sie die vorhandenen Plattformversionen (PVs) `persistentVolumeReclaimPolicy` in `Retain`, um sicherzustellen, dass das zugrunde liegende EBS-Volume nicht gelöscht wird.
1. **PV aus Kubernetes entfernen**: Löschen Sie die alte PV-Ressource, während das aktuelle EBS-Volume erhalten bleibt.
1. **Neue PV mit statischer Bereitstellung erstellen**: Erstellen Sie eine neue PV, die auf dasselbe EBS-Volume verweist, jedoch mit dem Ziel-CSI-Treiber funktioniert.
1. **An ein neues PVC binden**: Erstellen Sie ein neues PVC, die mithilfe des Feldes `volumeName` speziell auf Ihre PV verweist.
### Überlegungen
+ Stellen Sie sicher, dass Ihre Anwendungen beendet sind, bevor Sie mit dieser Migration beginnen.
+ Sichern Sie Ihre Daten, bevor Sie mit dem Migrationsprozess beginnen.
+ Dieser Vorgang muss für jedes persistente Volume durchgeführt werden.
+ Die Workload muss aktualisiert werden, um das neue PVC zu verwenden.
## Migration von Load Balancern
Sie können vorhandene Load Balancer nicht direkt vom selbstverwalteten AWS Load Balancer Controller in EKS Auto Mode übertragen. Stattdessen müssen Sie eine Blau-Grün-Bereitstellungsstrategie implementieren. Dabei wird die vorhandene Load-Balancer-Konfiguration beibehalten, während neue Load Balancer unter dem verwalteten Controller erstellt werden.
Um Service Unterbrechungen zu minimieren, empfehlen wir einen DNS-basierten Ansatz zur Datenverkehrsverlagerung. Erstellen Sie zunächst neue Load Balancer in EKS Auto Mode, während Ihre vorhandene Konfiguration betriebsbereit bleibt. Verwenden Sie anschließend DNS-Routing (z. B. Route 53), um den Datenverkehr schrittweise von den alten Load Balancern auf die neuen umzuleiten. Sobald der Datenverkehr erfolgreich migriert wurde und Sie die neue Konfiguration überprüft haben, können Sie die alten Load Balancer und den selbstverwalteten Controller außer Betrieb nehmen.
# Aktivierung von EKS Auto Mode in einem vorhandenen Cluster
In diesem Thema wird beschrieben, wie Sie Amazon EKS Auto Mode für Ihre vorhandenen Amazon-EKS-Cluster aktivieren. Um den Automatikmodus in einem vorhandenen Cluster zu aktivieren, müssen die IAM-Berechtigungen aktualisiert und die zentralen EKS-Auto-Mode-Einstellungen konfiguriert werden. Nach der Aktivierung können Sie mit der Migration Ihrer vorhandenen Rechen-Workloads beginnen, um die vereinfachten Vorgänge und die automatisierte Infrastrukturverwaltung des Automatikmodus zu nutzen.
**Wichtig**
Stellen Sie sicher, dass Sie die erforderliche Mindestversion bestimmter Amazon-EKS-Add-Ons installiert haben, bevor Sie EKS Auto Mode aktivieren. Weitere Informationen finden Sie unter [Erforderliche Add-On-Versionen](#auto-addons-required).
Stellen Sie vor Beginn sicher, dass Sie über Administratorzugriff auf Ihren Amazon-EKS-Cluster und Berechtigungen zum Ändern von IAM-Rollen verfügen. Die Schritte in diesem Thema führen Sie durch die Aktivierung des automatischen Modus mit der AWS-Managementkonsole oder AWS CLI.
## AWS-Managementkonsole
Sie müssen mit der Berechtigung zur Verwaltung von IAM, EKS und EC2 Ressourcen an der AWS Konsole angemeldet sein.
**Anmerkung**
Die Cluster-IAM-Rolle eines EKS-Clusters kann nach der Erstellung des Clusters nicht mehr geändert werden. EKS Auto Mode erfordert zusätzliche Berechtigungen für diese Rolle. Sie müssen der aktuellen Rolle zusätzliche Richtlinien anfügen.
### Cluster-IAM-Rolle aktualisieren
1. Öffnen Sie Ihre Cluster-Übersichtsseite in der AWS-Managementkonsole.
1. Wählen Sie unter **ARN der Cluster-IAM-Rolle** die Option **In IAM anzeigen** aus.
1. Wählen Sie in der Dropdown-Liste **Berechtigungen hinzufügen** die Option **Richtlinien hinzufügen** aus.
1. Verwenden Sie das Feld **Suche**, um die folgenden Richtlinien zu suchen und auszuwählen:
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
1. Wählen Sie **Berechtigungen hinzufügen** aus.
1. Wählen Sie auf der Registerkarte **Vertrauensbeziehungen** die Option **Vertrauensrichtlinie bearbeiten** aus
1. Fügen Sie die folgende Cluster-IAM-Rollen-Vertrauensrichtlinie ein und wählen Sie **Richtlinie aktualisieren** aus
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### EKS Auto Mode aktivieren
1. Öffnen Sie Ihre Cluster-Übersichtsseite in der AWS-Managementkonsole.
1. Wählen Sie unter **EKS Auto Mode** die Option **Verwalten** aus.
1. Aktivieren Sie **EKS Auto Mode**.
1. Wählen Sie aus der Dropdown-Liste **EKS-Knoten-Pool** die Standard-Knoten-Pools aus, die Sie erstellen möchten.
+ Weitere Informationen zu Knoten-Pools in EKS Auto Mode. Weitere Informationen finden Sie unter [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md).
1. Wenn Sie für dieses AWS Konto bereits eine EKS Auto Mode Node IAM-Rolle erstellt haben, wählen Sie sie in der Dropdownliste **Node IAM** Role aus. Falls Sie diese Rolle noch nicht erstellt haben, wählen Sie **Empfohlene Rolle erstellen** und befolgen Sie die Schritte.
## AWS CLI
### Voraussetzungen
+ Die Cluster-IAM-Rolle des vorhandenen EKS-Clusters muss über ausreichende Berechtigungen für EKS Auto Mode verfügen, beispielsweise die folgenden Richtlinien:
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
+ Die Cluster-IAM-Rolle muss über eine aktualisierte Vertrauensrichtlinie verfügen, welche die Aktion `sts:TagSession` enthält. Weitere Informationen zum Erstellen einer Cluster-IAM-Rolle finden Sie unter [Erstellen Sie einen EKS-Auto-Mode-Cluster mit der AWS CLI](automode-get-started-cli.md).
+ `aws`-CLI installiert, angemeldet und eine ausreichende Version vorhanden. Sie benötigen die Erlaubnis, IAM, EKS und EC2 Ressourcen zu verwalten. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
### Verfahren
Verwenden Sie die folgenden Befehle, um EKS Auto Mode in einem vorhandenen Cluster zu aktivieren.
**Anmerkung**
Die Funktionen für Rechenleistung, Blockspeicher und Lastenausgleich müssen alle in derselben Anfrage aktiviert oder deaktiviert werden.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=true \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{"blockStorage":{"enabled": true}}'
```
## Erforderliche Add-On-Versionen
Wenn Sie EKS Auto Mode in einem vorhandenen Cluster aktivieren möchten, müssen Sie möglicherweise bestimmte Add-Ons aktualisieren. Bitte beachten Sie Folgendes:
+ Dies gilt nur für vorhandene Cluster, die in EKS Auto Mode umgestellt werden.
+ Neue Cluster, die mit aktiviertem EKS Auto Mode erstellt wurden, erfordern diese Aktualisierungen nicht.
Wenn Sie eines der folgenden Add-Ons installiert haben, stellen Sie sicher, dass es mindestens die angegebene Mindestversion aufweist:
| Add-On-Name | Erforderliche Mindestversion |
| --- | --- |
| Amazon-VPC-CNI-Plugin für Kubernetes | v1.19.0-eksbuild.1 |
| Kube-proxy | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/auto-enable-existing.html) |
| Amazon-EBS-CSI-Treiber | v1.37.0-eksbuild.1 |
| CSI-Snapshot-Controller | v8.1.0-eksbuild.2 |
| EKS Pod Identity Agent | v1.3.4-eksbuild.1 |
Weitere Informationen finden Sie unter [Aktualisierung eines Amazon-EKS-Add-Ons](updating-an-add-on.md).
## Nächste Schritte
+ Informationen zum Migrieren von Workloads der Knotengruppe finden Sie unter [Migration von EKS-verwalteten Knotengruppen zu EKS Auto Mode](auto-migrate-mng.md).
+ Informationen zur Migration von selbstverwaltetem Karpenter finden Sie unter [Migration von Karpenter zu EKS Auto Mode mithilfe von kubectl](auto-migrate-karpenter.md).
# Migration von Karpenter zu EKS Auto Mode mithilfe von kubectl
Dieses Thema führt Sie durch den Prozess der Migration von Workloads von Karpenter zu Amazon EKS Auto Mode mithilfe von kubectl. Die Migration kann schrittweise durchgeführt werden, sodass Sie Workloads in Ihrem eigenen Tempo verschieben können, während die Cluster-Stabilität und die Verfügbarkeit der Anwendungen während der gesamten Übergangsphase gewährleistet bleiben.
Der unten beschriebene step-by-step Ansatz ermöglicht es Ihnen, Karpenter und EKS Auto Mode während der Migrationsphase parallel auszuführen. Diese duale Betriebsstrategie gewährleistet einen nahtlosen Übergang, da Sie das Workload-Verhalten in EKS Auto Mode überprüfen können, bevor Sie Karpenter vollständig außer Betrieb nehmen. Sie können Anwendungen einzeln oder in Gruppen migrieren, was Ihnen Flexibilität bietet, um Ihren spezifischen betrieblichen Anforderungen und Ihrer Risikotoleranz gerecht zu werden.
## Voraussetzungen
Stellen Sie vor Beginn der Migration sicher, dass Sie über Folgendes verfügen:
+ Karpenter v1.1 oder höher muss auf Ihrem Cluster installiert sein. Weitere Informationen finden Sie unter [Upgrade auf 1.1.0\$1](https://karpenter.sh/docs/upgrading/upgrade-guide/#upgrading-to-110) in der Karpenter-Dokumentation.
+ `kubectl` installiert und mit Ihrem Cluster verbunden. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
Bei diesem Thema wird davon ausgegangen, dass Sie mit Karpenter und vertraut sind. NodePools Weitere Informationen finden Sie in der [Dokumentation zu Karpenter.](https://karpenter.sh/)
## Schritt 1: EKS Auto Mode auf dem Cluster aktivieren
Aktivieren Sie den EKS-Automatikmodus auf Ihrem vorhandenen Cluster mithilfe der AWS CLI oder der Managementkonsole. Weitere Informationen finden Sie unter [Aktivierung von EKS Auto Mode in einem vorhandenen Cluster](auto-enable-existing.md).
**Anmerkung**
Aktivieren Sie den `general purpose`-Knoten-Pool in dieser Phase des Übergangs nicht, während Sie EKS Auto Mode aktivieren. Dieser Knoten-Pool ist nicht selektiv.
Weitere Informationen finden Sie unter [Integriert aktivieren oder deaktivieren NodePools](set-builtin-node-pools.md).
## Schritt 2: Erstellen Sie einen fehlerhaften EKS-Automatikmodus NodePool
Erstellen Sie einen neuen NodePool für EKS Auto Mode mit einem Makel. Dadurch wird sichergestellt, dass vorhandene Pods nicht automatisch auf den neuen EKS-Auto-Mode-Knoten geplant werden. Dieser Knoten-Pool verwendet den in EKS Auto Mode integrierten `default` `NodeClass`. Weitere Informationen finden Sie unter [Knotenklasse für Amazon EKS erstellen](create-node-class.md).
Beispiel für einen Knoten-Pool mit Taint:
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
taints:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
Aktualisieren Sie die Anforderungen für den Knoten-Pool, damit sie mit der Karpenter-Konfiguration übereinstimmen, von der Sie migrieren. Sie benötigen mindestens eine Anforderung.
## Schritt 3: Workloads für die Migration aktualisieren
Identifizieren und aktualisieren Sie die Workloads, die Sie in EKS Auto Mode migrieren möchten. Fügen Sie diesen Workloads sowohl Toleranzen als auch Knoten-Selektoren hinzu:
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
Durch diese Änderung kann die Workload auf den neuen EKS-Auto-Mode-Knoten geplant werden.
EKS Auto Mode verwendet andere Bezeichnungen als Karpenter. Beschriftungen, die sich auf EC2 verwaltete Instanzen beziehen, beginnen mit`eks.amazonaws.com`. Weitere Informationen finden Sie unter [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md).
## Schritt 4: Workloads schrittweise migrieren
Wiederholen Sie Schritt 3 für jede Workload, die Sie migrieren möchten. Auf diese Weise können Sie Workloads einzeln oder in Gruppen verschieben, je nach Ihren Anforderungen und Ihrer Risikotoleranz.
## Schritt 5: Entfernen Sie den ursprünglichen Karpenter NodePool
Sobald alle Workloads migriert wurden, können Sie den ursprünglichen Karpenter entfernen: NodePool
```
kubectl delete nodepool
```
## Schritt 6: Entfernen Sie den Makel aus dem EKS-Automatikmodus (optional) NodePool
Wenn Sie möchten, dass der EKS-Automodus zum Standard für neue Workloads wird, können Sie den Makel aus dem EKS-Automatikmodus entfernen: NodePool
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
# Remove the taints section
```
## Schritt 7: Knoten-Selektoren aus Workloads entfernen (optional)
Wenn Sie den Makel aus dem EKS-Automatikmodus entfernt haben NodePool, können Sie optional die Node-Selectors aus Ihren Workloads entfernen, da der EKS-Automodus jetzt der Standard ist:
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
# Remove the nodeSelector section
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
## Schritt 8: Karpenter von Ihrem Cluster deinstallieren
Die Schritte zum Entfernen von Karpenter hängen davon ab, wie Sie es installiert haben. Weitere Informationen finden Sie in den [Installationsanweisungen für Karpenter](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#create-a-cluster-and-add-karpenter).
# Migration von EKS-verwalteten Knotengruppen zu EKS Auto Mode
Bei der Umstellung Ihres Amazon-EKS-Clusters auf den EKS Auto Mode können Sie Ihre vorhandenen Workloads mithilfe des eksctl-CLI-Tools nahtlos aus verwalteten Knotengruppen (MNGs) migrieren. Dieser Vorgang gewährleistet die kontinuierliche Verfügbarkeit Ihrer Anwendungen, während EKS Auto Mode Ihre Rechenressourcen optimiert. Die Migration kann mit minimalen Unterbrechungen Ihrer ausgeführten Anwendungen durchgeführt werden.
Dieses Thema führt Sie durch die Schritte, mit denen Sie Pods sicher aus Ihren vorhandenen verwalteten Knotengruppen entfernen und EKS Auto Mode diese auf neu bereitgestellten Instances neu planen lassen können. Durch Befolgen dieses Verfahrens können Sie die Vorteile der intelligenten Workload-Konsolidierung von EKS Auto Mode nutzen und gleichzeitig die Verfügbarkeit Ihrer Anwendung während der gesamten Migration aufrechterhalten.
## Voraussetzungen
+ Cluster mit aktiviertem EKS Auto Mode
+ `eksctl`-CLI installiert und mit Ihrem Cluster verbunden. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
+ Karpenter ist auf dem Cluster nicht installiert.
## Verfahren
Verwenden Sie den folgenden `eksctl`-CLI-Befehl, um das Entleeren von Pods aus den vorhandenen verwalteten Knotengruppen-Instances zu initiieren. EKS Auto Mode erstellt neue Knoten, um die verschobenen Pods zu sichern.
```
eksctl delete nodegroup --cluster= --name=
```
Sie müssen diesen Befehl für jede verwaltete Knotengruppe in Ihrem Cluster ausführen.
Weitere Informationen zu diesem Befehl finden Sie unter [Knotengruppen löschen und leeren](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups) in der eksctl-Dokumentation.
# Migration von EKS Fargate zu EKS Auto Mode
In diesem Thema wird der Prozess der Migration von Workloads von EKS Fargate zu Amazon EKS Auto Mode mithilfe von `kubectl` erläutert Die Migration kann schrittweise durchgeführt werden, sodass Sie Workloads in Ihrem eigenen Tempo verschieben können, während die Cluster-Stabilität und die Verfügbarkeit der Anwendungen während der gesamten Übergangsphase gewährleistet bleiben.
Der unten beschriebene step-by-step Ansatz ermöglicht es Ihnen, EKS Fargate und EKS Auto Mode während des Migrationszeitraums parallel auszuführen. Diese Dual-Betriebsstrategie trägt zu einem nahtlosen Übergang bei, indem sie Ihnen die Möglichkeit bietet, das Workload-Verhalten in EKS Auto Mode zu validieren, bevor Sie EKS Fargate vollständig außer Betrieb nehmen. Sie können Anwendungen einzeln oder in Gruppen migrieren, was Ihnen Flexibilität bietet, um Ihren spezifischen betrieblichen Anforderungen und Ihrer Risikotoleranz gerecht zu werden.
## Vergleich von Amazon EKS Auto Mode und EKS mit AWS Fargate
Amazon EKS mit AWS Fargate bleibt eine Option für Kunden, die EKS ausführen möchten, aber Amazon EKS Auto Mode ist in Zukunft der empfohlene Ansatz. EKS Auto Mode ist vollständig Kubernetes-konform und unterstützt alle Upstream-Kubernetes-Primitive und Plattform-Tools wie Istio, die Fargate nicht unterstützen kann. EKS Auto Mode unterstützt außerdem alle EC2-Laufzeit-Kaufoptionen, einschließlich GPU- und Spot Instances, sodass Kunden verhandelte EC2-Rabatte und andere Sparmechanismen nutzen können. Diese Funktionen sind bei Verwendung von EKS mit Fargate nicht verfügbar.
Darüber hinaus können Kunden mit EKS Auto Mode dasselbe Isolationsmodell wie Fargate erzielen, indem sie die Standard-Planungsfunktionen von Kubernetes nutzen, um sicherzustellen, dass jede EC2-Instance einen einzelnen Anwendungs-Container ausführt. Durch die Einführung von Amazon EKS Auto Mode können Kunden alle Vorteile der Ausführung von Kubernetes nutzen AWS — eine vollständig Kubernetes-konforme Plattform, die die Flexibilität bietet, die gesamte Bandbreite von EC2 und Kaufoptionen zu nutzen und gleichzeitig die Benutzerfreundlichkeit und Abstraktion vom Infrastrukturmanagement beizubehalten, die Fargate bietet.
### Erzielen einer Fargate-ähnlichen Isolierung im EKS-Automatikmodus
Um das Pod-Isolationsmodell von Fargate zu replizieren, bei dem jeder Pod auf seiner eigenen dedizierten Instanz ausgeführt wird, können Sie Spread-Beschränkungen der Kubernetes-Topologie verwenden. Dies ist der empfohlene Ansatz zur Steuerung der Pod-Verteilung zwischen den Knoten:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: isolated-app
minDomains: 1
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
In dieser Konfiguration:
+ `maxSkew: 1`stellt sicher, dass der Unterschied in der Anzahl der Pods zwischen zwei beliebigen Knoten höchstens 1 beträgt, wodurch effektiv ein Pod pro Knoten verteilt wird
+ `topologyKey: kubernetes.io/hostname`definiert den Knoten als Topologiedomäne
+ `whenUnsatisfiable: DoNotSchedule`verhindert die Terminplanung, wenn die Einschränkung nicht eingehalten werden kann
+ `minDomains: 1`stellt vor der Planung sicher, dass mindestens eine Domäne (ein Knoten) vorhanden ist
Der automatische Modus von EKS stellt bei Bedarf automatisch neue EC2-Instances bereit, um diese Einschränkung zu erfüllen. Dabei wird dasselbe Isolationsmodell wie Fargate bereitgestellt, Sie haben jedoch Zugriff auf die gesamte Palette der EC2-Instance-Typen und Kaufoptionen.
Alternativ können Sie Pod-Anti-Affinitätsregeln für eine strengere Isolierung verwenden:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- isolated-app
topologyKey: kubernetes.io/hostname
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
Die `podAntiAffinity` Regel mit `requiredDuringSchedulingIgnoredDuringExecution` stellt sicher, dass keine zwei Pods mit dem Label auf `app: isolated-app` demselben Knoten geplant werden können. Dieser Ansatz bietet harte Isolationsgarantien, die denen von Fargate ähneln.
## Voraussetzungen
Stellen Sie vor Beginn der Migration sicher, dass Sie über Folgendes verfügen:
+ Richten Sie einen Cluster mit Fargate ein. Weitere Informationen finden Sie unter [Beginnen Sie mit AWS Fargate für Ihren Cluster](fargate-getting-started.md).
+ Installiert und `kubectl` mit Ihrem Cluster verbunden. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
## Schritt 1: Fargate-Cluster überprüfen
1. Ausführung der EKS-Cluster mit Fargate überprüfen:
```
kubectl get node
```
```
NAME STATUS ROLES AGE VERSION
fargate-ip-192-168-92-52.ec2.internal Ready 25m v1.30.8-eks-2d5f260
fargate-ip-192-168-98-196.ec2.internal Ready 24m v1.30.8-eks-2d5f260
```
1. Ausgeführte Pods überprüfen:
```
kubectl get pod -A
```
```
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-6659cb98f6-gxpjz 1/1 Running 0 26m
kube-system coredns-6659cb98f6-gzzsx 1/1 Running 0 26m
```
1. Bereitstellung in einer Datei mit dem Namen `deployment_fargate.yaml` erstellen:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: fargate
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. Bereitstellung durchführen:
```
kubectl apply -f deployment_fargate.yaml
```
```
deployment.apps/nginx-deployment created
```
1. Pods und Bereitstellungen überprüfen:
```
kubectl get pod,deploy
```
```
NAME READY STATUS RESTARTS AGE
pod/nginx-deployment-5c7479459b-6trtm 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-g8ssb 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-mq4mf 1/1 Running 0 61s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deployment 3/3 3 3 61s
```
1. Knoten überprüfen:
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
fargate-ip-192-168-111-43.ec2.internal Ready 31s v1.30.8-eks-2d5f260 192.168.111.43 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-117-130.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.117.130 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-74-140.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.74.140 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
```
## Schritt 2: EKS Auto Mode auf dem Cluster aktivieren
1. Aktivieren Sie den EKS-Automatikmodus auf Ihrem vorhandenen Cluster mithilfe der AWS CLI oder der Managementkonsole. Weitere Informationen finden Sie unter [Aktivierung von EKS Auto Mode in einem vorhandenen Cluster](auto-enable-existing.md).
1. Knoten-Pool überprüfen:
```
kubectl get nodepool
```
```
NAME NODECLASS NODES READY AGE
general-purpose default 1 True 6m58s
system default 0 True 3d14h
```
## Schritt 3: Workloads für die Migration aktualisieren
Identifizieren und aktualisieren Sie die Workloads, die Sie in EKS Auto Mode migrieren möchten.
Um eine Workload von Fargate nach EKS Auto Mode zu migrieren, wenden Sie die Annotation `eks.amazonaws.com/compute-type: ec2` an. Dadurch wird sichergestellt, dass die Arbeitslast trotz des Fargate-Profils nicht von Fargate geplant wird, sondern vom EKS-Automatikmodus übernommen wird. NodePool Weitere Informationen finden Sie unter [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md).
1. Ändern Sie Ihre Bereitstellungen (beispielsweise die `deployment_fargate.yaml`-Datei), um den Rechentyp auf `ec2` umzustellen:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. Wenden Sie die Bereitstellung an. Durch diese Änderung kann die Workload auf den neuen EKS-Auto–Mode-Knoten geplant werden:
```
kubectl apply -f deployment_fargate.yaml
```
1. Überprüfen Sie, ob die Bereitstellung im EKS-Auto-Mode-Cluster ausgeführt wird:
```
kubectl get pod -o wide
```
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-97967b68d-ffxxh 1/1 Running 0 3m31s 192.168.43.240 i-0845aafcb51630ffb
nginx-deployment-97967b68d-mbcgj 1/1 Running 0 2m37s 192.168.43.241 i-0845aafcb51630ffb
nginx-deployment-97967b68d-qpd8x 1/1 Running 0 2m35s 192.168.43.242 i-0845aafcb51630ffb
```
1. Überprüfen Sie, ob kein Fargate-Knoten ausgeführt wird und keine Bereitstellung in den verwalteten Knoten in EKS Auto Mode ausgeführt wird:
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
i-0845aafcb51630ffb Ready 3m30s v1.30.8-eks-3c20087 192.168.41.125 3.81.118.95 Bottlerocket (EKS Auto) 2025.3.14 (aws-k8s-1.30) 6.1.129 containerd://1.7.25+bottlerocket
```
## Schritt 4: Workloads schrittweise migrieren
Wiederholen Sie Schritt 3 für jede Workload, die Sie migrieren möchten. Auf diese Weise können Sie Workloads einzeln oder in Gruppen verschieben, je nach Ihren Anforderungen und Ihrer Risikotoleranz.
## Schritt 5: Das ursprüngliche Fargate-Profil entfernen
Sobald alle Workloads migriert wurden, können Sie das ursprüngliche `fargate`-Profil entfernen. Ersetze es ** durch den Namen deines Fargate-Profils:
```
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name
```
## Schritt 6: CoreDNS herunterskalieren
Da EKS Auto Mode CoreDNS verwaltet, skalieren Sie die `coredns`-Bereitstellung auf 0 herunter:
```
kubectl scale deployment coredns -n kube-system —-replicas=0
```
# Ausführung von Beispiel-Workloads in Clustern in EKS Auto Mode
Dieses Kapitel enthält Beispiele dafür, wie verschiedene Arten von Workloads in Amazon-EKS-Clustern bereitgestellt werden können, die im Automatikmodus ausgeführt werden. Die Beispiele veranschaulichen wichtige Workload-Muster, darunter Beispielanwendungen, Web-Anwendungen mit Lastenausgleich, zustandsbehaftete Workloads mit persistenter Speicherung und Workloads mit spezifischen Anforderungen an die Knoten-Platzierung. Jedes Beispiel enthält vollständige Manifeste und step-by-step Bereitstellungsanweisungen, die Sie als Vorlagen für Ihre eigenen Anwendungen verwenden können.
Bevor Sie mit den Beispielen fortfahren, stellen Sie sicher, dass ein EKS-Cluster im Auto-Modus läuft und dass Sie AWS CLI und kubectl installiert haben. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md). Die Beispiele setzen grundlegende Kenntnisse der Kubernetes-Konzepte und kubectl-Befehle voraus.
Sie können diese auf Anwendungsfällen basierenden Beispiele verwenden, um Workloads in Clustern in EKS Auto Mode auszuführen.
[Bereitstellung einer erhöhten Beispiel-Workload in einem Cluster in Amazon EKS Auto Mode](automode-workload.md)
Zeigt, wie Sie mithilfe von `kubectl`-Befehlen einen Beispiel-Workload in einem Cluster in EKS Auto Mode bereitstellen.
[Bereitstellung einer Beispiel-Workload für Load Balancer in EKS Auto Mode](auto-elb-example.md)
Zeigt, wie Sie eine containerisierte Version des Spiels 2048 in Amazon EKS bereitstellen.
[Bereitstellung einer Beispiel-Workload mit Statusverwaltung in EKS Auto Mode](sample-storage-workload.md)
Zeigt, wie Sie eine Beispielanwendung mit Status in einem Cluster in EKS Auto Mode bereitstellen.
[Einen beschleunigten Workload bereitstellen](auto-accelerated.md)
Zeigt, wie hardwarebeschleunigte Workloads auf Knoten bereitgestellt werden, die vom EKS Auto Mode verwaltet werden.
[Überprüfen, ob eine Workload in Knoten von EKS Auto Mode bereitgestellt wird](associate-workload.md)
Zeigt, wie Sie mithilfe einer Annotation steuern, ob eine Workload auf Knoten bereitgestellt wird, die von EKS Auto Mode verwaltet werden.
# Bereitstellung einer erhöhten Beispiel-Workload in einem Cluster in Amazon EKS Auto Mode
In diesem Tutorial erfahren Sie, wie Sie eine Beispiel-Workload in einem EKS-Auto-Mode-Cluster bereitstellen und beobachten, wie dieser automatisch die erforderlichen Rechenressourcen bereitstellt. Sie werden `kubectl` Befehle verwenden, um das Verhalten des Clusters zu beobachten und aus erster Hand zu erfahren, wie der Auto Mode den Kubernetes-Betrieb vereinfacht. AWS Am Ende dieses Tutorials werden Sie verstehen, wie EKS Auto Mode auf Workload-Bereitstellungen reagiert, indem er die zugrunde liegenden Rechenressourcen automatisch verwaltet, ohne dass eine manuelle Konfiguration der Knotengruppe erforderlich ist.
## Voraussetzungen
+ Ein Cluster in Amazon EKS Auto Mode. Notieren Sie sich den Namen und die AWS Region des Clusters.
+ Ein IAM-Prinzipal, beispielsweise ein Benutzer oder eine Rolle, mit ausreichenden Berechtigungen zur Verwaltung von Netzwerk-, Rechen- und EKS-Ressourcen.
+ Weitere Informationen finden Sie unter [Erstellung von Rollen und Hinzufügen von Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) im IAM-Benutzerhandbuch.
+ `aws`-CLI installiert und mit einer IAM-Identität konfiguriert.
+ `kubectl`-CLI installiert und mit dem Cluster verbunden.
+ Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
## Schritt 1: Vorhandene Rechenressourcen überprüfen (optional)
Verwenden Sie zunächst `kubectl`, um die Knoten-Pools in Ihrem Cluster aufzulisten.
```
kubectl get nodepools
```
Beispiel-Ausgabe:
```
general-purpose
```
In diesem Tutorial werden wir eine Workload bereitstellen, die für die Verwendung des `general-purpose`-Knoten-Pools konfiguriert ist. Dieser Knoten-Pool ist in EKS Auto Mode integriert und enthält sinnvolle Standardeinstellungen für allgemeine Workloads wie Microservices und Web-Anwendungen. Sie können Ihren eigenen Knoten-Pool erstellen. Weitere Informationen finden Sie unter [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md).
Verwenden Sie anschließend `kubectl`, um die mit Ihrem Cluster verbundenen Knoten aufzulisten.
```
kubectl get nodes
```
Wenn Sie gerade einen EKS-Auto-Mode-Cluster erstellt haben, werden keine Knoten angezeigt.
In diesem Tutorial werden Sie eine Beispiel-Workload bereitstellen. Wenn keine Knoten vorhanden sind oder die Workload nicht auf die vorhandenen Knoten passt, wird der EKS-Auto-Mode-Cluster einen neuen Knoten bereitstellen
## Schritt 2: Beispielanwendung im Cluster bereitstellen
Überprüfen Sie die folgende Kubernetes-Bereitstellung und speichern Sie sie als `inflate.yaml`
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 1
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
resources:
requests:
cpu: 1
securityContext:
allowPrivilegeEscalation: false
```
Beachten Sie, dass für den `eks.amazonaws.com/compute-type: auto`-Selektor die Bereitstellung des Workloads in einem Knoten von Amazon EKS Auto Mode erforderlich ist.
Wenden Sie die Bereitstellung auf Ihren Cluster an.
```
kubectl apply -f inflate.yaml
```
## Schritt 3: Kubernetes-Ereignisse beobachten
Verwenden Sie den folgenden Befehl, um Kubernetes-Ereignisse zu überwachen, einschließlich der Erstellung eines neuen Knotens. Verwenden Sie `ctrl+c`, um die Überwachung von Ereignissen zu beenden.
```
kubectl get events -w --sort-by '.lastTimestamp'
```
Verwenden Sie `kubectl`, um die mit Ihrem Cluster verbundenen Knoten erneut aufzulisten. Notieren Sie sich den neu erstellten Knoten.
```
kubectl get nodes
```
## Schritt 4: Knoten und Instanzen in der AWS Konsole anzeigen
Sie können die EKS-Automodus-Knoten in der EKS-Konsole und die zugehörigen EC2 Instanzen in der EC2 Konsole anzeigen.
EC2 Instances, die im automatischen Modus von EKS bereitgestellt werden, sind eingeschränkt. Sie können in EKS-Auto-Mode-Knoten keine beliebigen Befehle ausführen.
## Schritt 5: Bereitstellung löschen
Verwenden Sie `kubectl`, um die Beispielbereitstellung zu löschen
```
kubectl delete -f inflate.yaml
```
Wenn keine weiteren Workloads in Ihrem Cluster bereitgestellt sind, bleibt der vom EKS Auto Mode erstellte Knoten leer.
In der Standardkonfiguration erkennt EKS Auto Mode Knoten, die seit 30 Sekunden leer sind, und beendet sie.
Verwenden Sie `kubectl` oder die EC2 Konsole, um zu bestätigen, dass die zugehörige Instanz gelöscht wurde.
# Bereitstellung einer Beispiel-Workload für Load Balancer in EKS Auto Mode
Dieser Leitfaden führt Sie durch die Bereitstellung einer containerisierten Version des Spiels 2048 in Amazon EKS, einschließlich Load Balancing und Internetzugänglichkeit.
## Voraussetzungen
+ Ein EKS-Auto-Mode-Cluster
+ `kubectl` für die Interaktion mit Ihrem Cluster konfiguriert
+ Geeignete IAM-Berechtigungen für die Erstellung von ALB-Ressourcen
## Schritt 1: Namespace erstellen
Erstellen Sie zunächst einen dedizierten Namespace für die 2048-Spiel-Anwendung.
Erstellen Sie eine Datei namens `01-namespace.yaml`:
```
apiVersion: v1
kind: Namespace
metadata:
name: game-2048
```
Wenden Sie die Namespace-Konfiguration an:
```
kubectl apply -f 01-namespace.yaml
```
## Schritt 2: Anwendung bereitstellen
Die Anwendung führt mehrere Replikate des 2048-Spiel-Containers aus.
Erstellen Sie eine Datei namens `02-deployment.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: game-2048
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 5
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
resources:
requests:
cpu: "0.5"
```
**Anmerkung**
Sollten beim Laden des Images `public.ecr.aws/l6m2t8p7/docker-2048:latest` Fehler auftreten, überprüfen Sie, ob Ihre Knoten-IAM-Rolle über ausreichende Berechtigungen verfügt, um Images aus ECR abzurufen. Weitere Informationen finden Sie unter [Knoten-IAM-Rolle](auto-learn-iam.md#auto-learn-node-iam-role). Beachten Sie, dass es sich bei dem `docker-2048`-Image im Beispiel um ein `x86_64`-Image handelt, das in anderen Architekturen nicht ausgeführt werden kann.
**Zentrale Komponenten:**
+ Stellt 5 Replikate der Anwendung bereit
+ Verwendet ein öffentliches ECR-Image
+ Erfordert 0,5 CPU-Kerne pro Pod
+ Stellt Port 80 für HTTP-Datenverkehr bereit
Bereitstellung durchführen:
```
kubectl apply -f 02-deployment.yaml
```
## Schritt 3: Service erstellen
Der Service macht die Bereitstellung für das Cluster-Netzwerk sichtbar.
Erstellen Sie eine Datei namens `03-service.yaml`:
```
apiVersion: v1
kind: Service
metadata:
namespace: game-2048
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
app.kubernetes.io/name: app-2048
```
**Zentrale Komponenten:**
+ Erstellt einen NodePort-Service
+ Ordnet Port 80 dem Port 80 des Containers zu
+ Verwendet den Label-Selektor, um Pods zu finden
Wenden Sie den Service an:
```
kubectl apply -f 03-service.yaml
```
## Schritt 4: Load Balancing konfigurieren
Sie richten einen Ingress ein, um die Anwendung im Internet verfügbar zu machen.
Erstellen Sie zunächst die `IngressClass`. Erstellen Sie eine Datei namens `04-ingressclass.yaml`:
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
app.kubernetes.io/name: LoadBalancerController
name: alb
spec:
controller: eks.amazonaws.com/alb
```
**Anmerkung**
EKS Auto Mode erfordert Subnetz-Tags zur Identifizierung öffentlicher und privater Subnetze.
Wenn Sie Ihren Cluster mit `eksctl` erstellt haben, verfügen Sie bereits über diese Tags.
Weitere Informationen erhalten Sie unter [Kennzeichnung von Subnetzen für EKS Auto Mode](tag-subnets-auto.md).
Erstellen Sie anschließend die Ingress-Ressource. Erstellen Sie eine Datei namens `05-ingress.yaml`:
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: game-2048
name: ingress-2048
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-2048
port:
number: 80
```
**Zentrale Komponenten:**
+ Erstellt ein internetbasiertes ALB
+ Verwendet den IP-Zieltyp für die direkte Pod-Weiterleitung
+ Leitet den gesamten Datenverkehr (/) an den Spiele-Service weiter
Wenden Sie die Ingress-Konfigurationen an:
```
kubectl apply -f 04-ingressclass.yaml
kubectl apply -f 05-ingress.yaml
```
## Schritt 5: Bereitstellung überprüfen
1. Vergewissern Sie sich, dass alle Pods ausgeführt werden:
```
kubectl get pods -n game-2048
```
1. Überprüfen Sie, ob der Service erstellt wurde:
```
kubectl get svc -n game-2048
```
1. Rufen Sie den ALB-Endpunkt ab:
```
kubectl get ingress -n game-2048
```
Das Feld ADDRESS in der Ingress-Ausgabe zeigt Ihren ALB-Endpunkt an. Warten Sie 2–3 Minuten, bis der ALB alle Ziele bereitgestellt und registriert hat.
## Schritt 6: Auf das Spiel zugreifen
Öffnen Sie Ihren Web-Browser und navigieren Sie zur ALB-Endpunkt-URL aus dem vorherigen Schritt. Sie sollten nun die 2048-Spieloberfläche sehen.
## Schritt 7: Bereinigen
So entfernen Sie alle in diesem Tutorial erstellten Ressourcen:
```
kubectl delete namespace game-2048
```
Dadurch werden alle Ressourcen im Namespace gelöscht, einschließlich der Bereitstellungs-, Service- und Ingress-Ressourcen.
## Was hinter den Kulissen passiert
1. Die Bereitstellung erstellt fünf Pods, in denen das Spiel 2048 ausgeführt wird
1. Der Service bietet einen stabilen Netzwerkzugang zu diesen Pods
1. EKS Auto Mode:
+ Erstellt einen Application Load Balancer in AWS
+ Konfiguriert Zielgruppen für die Pods
+ Richtet Routing-Regeln ein, um den Datenverkehr zum Service zu leiten
## Fehlersuche
Falls das Spiel nicht geladen wird:
+ Stellen Sie sicher, dass alle Pods ausgeführt werden: `kubectl get pods -n game-2048`
+ Überprüfen Sie den Ingress-Status: `kubectl describe ingress -n game-2048`
+ Überprüfen Sie die ALB-Zustandsprüfungen: Zustand der Zielgruppe in der AWS-Konsole überprüfen
# Bereitstellung einer Beispiel-Workload mit Statusverwaltung in EKS Auto Mode
Dieses Tutorial führt Sie durch die Bereitstellung einer Beispielanwendung mit Statusverwaltung in Ihrem Cluster von EKS Auto Mode. Die Anwendung schreibt Zeitstempel in ein persistentes Volume und demonstriert damit die automatische EBS-Volume-Bereitstellung und die Persistenzfunktionen von EKS Auto Mode.
## Voraussetzungen
+ Ein EKS-Auto-Mode-Cluster
+ Die AWS CLI ist mit entsprechenden Berechtigungen konfiguriert
+ `kubectl` installiert und konfiguriert
+ Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
## Schritt 1: Umgebung konfigurieren
1. Legen Sie Ihre Umgebungsvariablen fest:
```
export CLUSTER_NAME=my-auto-cluster
export AWS_REGION="us-west-2"
```
1. Aktualisieren Sie Ihre kubeconfig:
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
## Schritt 2: Speicherklasse erstellen
`StorageClass` definiert, wie der EKS Auto Mode EBS-Volumes bereitstellt.
EKS Auto Mode erstellt keine `StorageClass` für Sie. Sie müssen eine `StorageClass`-Referenzierung `ebs.csi.eks.amazonaws.com` erstellen, um die Speicherfunktion von EKS Auto Mode zu nutzen.
1. Erstellen Sie eine Datei namens `storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
1. Wenden Sie `StorageClass` an:
```
kubectl apply -f storage-class.yaml
```
**Zentrale Komponenten:**
+ `provisioner: ebs.csi.eks.amazonaws.com` – Verwendet EKS Auto Mode
+ `volumeBindingMode: WaitForFirstConsumer` – Verzögert die Volume-Erstellung, bis ein Pod sie benötigt
+ `type: gp3` – Gibt den EBS-Volume-Typ an
+ `encrypted: "true"` – EBS verwendet den Standardschlüssel `aws/ebs` zum Verschlüsseln von Volumes, die mit dieser Klasse erstellt wurden. Dies ist zwar optional, wird aber empfohlen.
+ `storageclass.kubernetes.io/is-default-class: "true"` – Kubernetes verwendet standardmäßig diese Speicherklasse, sofern Sie nicht für einen persistenten Volume-Anspruch eine andere Volume-Klasse angeben. Seien Sie beim Festlegen dieses Werts vorsichtig, wenn Sie von einem anderen Speicher-Controller migrieren. (optional)
## Schritt 3: Persistenten Volume-Anspruch erstellen
Der PVC fordert Speicher von der `StorageClass` an.
1. Erstellen Sie eine Datei namens `pvc.yaml`:
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: auto-ebs-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: auto-ebs-sc
resources:
requests:
storage: 8Gi
```
1. Wenden Sie den PVC an:
```
kubectl apply -f pvc.yaml
```
**Zentrale Komponenten:**
+ `accessModes: ReadWriteOnce` – Das Volume kann jeweils von einem Knoten eingebunden werden
+ `storage: 8Gi` – Fordert ein Volumen von 8 GiB an
+ `storageClassName: auto-ebs-sc` – Verweist auf die von uns erstellte `StorageClass`
## Schritt 4: Anwendung bereitstellen
Die Bereitstellung führt einen Container aus, der Zeitstempel in das persistente Volume schreibt.
1. Erstellen Sie eine Datei namens `deployment.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate-stateful
spec:
replicas: 1
selector:
matchLabels:
app: inflate-stateful
template:
metadata:
labels:
app: inflate-stateful
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
containers:
- name: bash
image: public.ecr.aws/docker/library/bash:4.4
command: ["/usr/local/bin/bash"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 60; done"]
resources:
requests:
cpu: "1"
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: auto-ebs-claim
```
1. Bereitstellung durchführen:
```
kubectl apply -f deployment.yaml
```
**Zentrale Komponenten:**
+ Einfacher Bash-Container, der Zeitstempel in eine Datei schreibt
+ Bindet den PVC bei `/data` ein
+ Fordert 1 CPU-Kern an
+ Verwendet Knotenselektor für EKS-verwaltete Knoten
## Schritt 5: Einrichtung überprüfen
1. Überprüfen Sie, ob der Pod ausgeführt wird:
```
kubectl get pods -l app=inflate-stateful
```
1. Überprüfen Sie, ob der PVC eingebunden ist:
```
kubectl get pvc auto-ebs-claim
```
1. Überprüfen Sie das EBS-Volume:
```
# Get the PV name
PV_NAME=$(kubectl get pvc auto-ebs-claim -o jsonpath='{.spec.volumeName}')
# Describe the EBS volume
aws ec2 describe-volumes \
--filters Name=tag:CSIVolumeName,Values=${PV_NAME}
```
1. Überprüfen Sie, ob Daten geschrieben werden:
```
kubectl exec "$(kubectl get pods -l app=inflate-stateful \
-o=jsonpath='{.items[0].metadata.name}')" -- \
cat /data/out.txt
```
## Schritt 6: Bereinigen
Führen Sie den folgenden Befehl aus, um alle in diesem Tutorial erstellten Ressourcen zu entfernen:
```
# Delete all resources in one command
kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-ebs-sc
```
## Was hinter den Kulissen passiert
1. Der PVC fordert Speicher von der `StorageClass` an
1. Wenn der Pod geplant ist:
1. EKS Auto Mode stellt ein EBS-Volume bereit
1. Erstellt ein PersistentVolume
1. Fügt das Volume zum Knoten hinzu
1. Der Pod bindet das Volume ein und beginnt mit dem Schreiben von Zeitstempeln
## Snapshot-Controller
EKS Auto Mode ist mit dem Kubernetes CSI Snapshotter, auch bekannt als Snapshot-Controller, kompatibel. EKS Auto Mode umfasst jedoch keinen Snapshot-Controller. Sie sind für die Installation und Konfiguration des Snapshot-Controllers verantwortlich. Weitere Informationen finden Sie unter [Snapshot-Funktion für CSI-Volumes aktivieren](csi-snapshot-controller.md).
Überprüfen Sie die folgenden `VolumeSnapshotClass`, die sich auf die Speicherkapazität von EKS Auto Mode beziehen.
```
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: auto-ebs-vsclass
driver: ebs.csi.eks.amazonaws.com
deletionPolicy: Delete
```
[Weitere Informationen zum Kubernetes CSI Snapshotter.](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage)
# Einen beschleunigten Workload bereitstellen
Dieses Tutorial zeigt, wie Amazon EKS Auto Mode das Starten hardwarebeschleunigter Workloads vereinfacht. Amazon EKS Auto Mode optimiert den Betrieb über den Cluster hinaus. Dabei werden wichtige Infrastrukturkomponenten automatisiert und Funktionen für Rechenleistung, Netzwerke, Load Balancing, Speicher sowie Identitätszugriff und -verwaltung sofort bereitgestellt.
Amazon EKS Auto Mode umfasst die Treiber und Geräte-Plug-ins, die für bestimmte Instance-Typen wie NVIDIA- und AWS Neuron-Treiber erforderlich sind. Sie müssen diese Komponenten nicht installieren oder aktualisieren.
EKS Auto Mode verwaltet automatisch die Treiber für folgende Beschleuniger:
+ [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/)
+ [AWS Inferenz](https://aws.amazon.com/ai/machine-learning/inferentia/)
+ [ EC2 Beschleunigte Instances von NVIDIA GPUs auf Amazon](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html)
**Anmerkung**
EKS Auto Mode beinhaltet das NVIDIA-Geräte-Plugin für Kubernetes. Dieses Plugin wird automatisch ausgeführt und ist in Ihrem Cluster nicht als Daemon-Set sichtbar.
Zusätzliche Netzwerkunterstützung:
+ [Elastic Fabric Adapter (EFA)](https://aws.amazon.com/hpc/efa/)
Amazon EKS Auto Mode macht die aufwändige Verwaltung von Beschleunigertreibern und Geräte-Plugins überflüssig.
Sie können außerdem von Kosteneinsparungen profitieren, indem Sie den Cluster auf Null skalieren. Sie können EKS Auto Mode so konfigurieren, dass Instances beendet werden, wenn keine Workloads ausgeführt werden. Dies ist nützlich für Batch-basierte Inferenz-Workloads.
Nachfolgend finden Sie ein Beispiel für das Starten beschleunigter Workloads mit Amazon EKS Auto Mode.
## Voraussetzungen
+ Ein Kubernetes-Cluster mit konfiguriertem Amazon EKS Auto Mode.
+ Eine `default`-EKS-Knotenklasse wird erstellt, wenn die verwalteten Knoten-Pools `general-purpose` oder `system` aktiviert sind.
## Schritt 1: GPU-Workload bereitstellen
In diesem Beispiel erstellen Sie eine NodePool für NVIDIA-basierte Workloads, die 45 GB GPU-Speicher benötigen. Mit EKS Auto Mode definieren Sie Ihre Instance-Anforderungen mithilfe von Kubernetes-Planungsbeschränkungen.
Um den Amazon EKS Auto Mode `NodePool` und das Beispiel bereitzustellen`workload`, überprüfen Sie Folgendes NodePool und die Pod-Definition und speichern Sie unter `nodepool-gpu.yaml` und`pod.yaml`:
**nodepool-gpu.yaml**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
taints:
- key: nvidia.com/gpu
effect: NoSchedule
terminationGracePeriod: 24h0m0s
```
**pod.yaml**
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Beachten Sie, dass für den `eks.amazonaws.com/compute-type: auto`-Selektor die Bereitstellung des Workloads in einem Knoten von Amazon EKS Auto Mode erforderlich ist. Das stellt NodePool auch einen Makel dar, der es erlaubt, nur Pods mit Toleranzen für Nvidia GPUs zu planen.
Wenden Sie die Arbeitslast NodePool und den Workload auf Ihren Cluster an.
```
kubectl apply -f nodepool-gpu.yaml
kubectl apply -f pod.yaml
```
Die Ausgabe sollte folgendermaßen aussehen:
```
nodepool.karpenter.sh/gpu configured created
pod/nvidia-smi created
```
Warten Sie einige Sekunden und überprüfen Sie die Knoten in Ihrem Cluster. Sie sollten nun einen neuen Knoten in Ihrem Cluster von Amazon EKS Auto Mode sehen:
```
> kubectl get nodes
NAME TYPE CAPACITY ZONE NODE READY AGE
gpu-dnknr g6e.2xlarge on-demand us-west-2b i-02315c7d7643cdee6 True 76s
```
## Schritt 2: Validieren
Sie können sehen, dass Amazon EKS Auto Mode ein `g6e.2xlarge` statt eines `g6.2xlarge` gestartet hat, da die Workload gemäß den folgenden Kubernetes-Planungsbeschränkungen eine Instance mit l40s `GPU` erforderte:
```
...
nodeSelector:
eks.amazonaws.com/instance-gpu-name: l40s
...
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
```
Überprüfen Sie nun die Container-Protokolle, indem Sie den folgenden Befehl ausführen:
```
kubectl logs nvidia-smi
```
Beispielausgabe:
```
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.230.02 Driver Version: 535.230.02 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA L40S On | 00000000:30:00.0 Off | 0 |
| N/A 27C P8 23W / 350W | 0MiB / 46068MiB | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| No running processes found |
+---------------------------------------------------------------------------------------+
```
Sehen Sie sich nun die Container-Protokolle an, indem Sie den folgenden Befehl ausführen: Sie können sehen, dass der Container erkannt hat, dass er in einer Instance mit einer `NVIDIA` GPU ausgeführt wird, und dass Sie keine Gerätetreiber installieren mussten, da dies von Amazon EKS Auto Mode verwaltet wird.
## Schritt 3: Bereinigen
Um alle erstellten Objekte zu entfernen, verwenden Sie, `kubectl` um die Beispielbereitstellung zu löschen, NodePool sodass der Knoten beendet wird:
```
kubectl delete -f nodepool-gpu.yaml
kubectl delete -f pod.yaml
```
## NodePools Beispielreferenz
### Erstellen Sie eine NVIDIA NodePool
Im Folgenden wird Folgendes NodePool definiert:
+ Nur Instances der `g6e`- und `g6`-Familie starten
+ Knoten konsolidieren, wenn sie 1 Stunde lang leer sind
+ Der Wert von 1 Stunde für `consolodateAfter` unterstützt spitzenlastige Workloads und reduziert die Fluktuation der Knoten. Sie können `consolidateAfter` basierend auf Ihren Workload-Anforderungen optimieren.
**Beispiel NodePool mit GPU-Instanzfamilie und Konsolidierung**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
terminationGracePeriod: 24h0m0s
```
Anstatt `eks.amazonaws.com/instance-gpu-name` festzulegen, können Sie `eks.amazonaws.com/instance-family` verwenden, um die Instance-Familie anzugeben. Weitere bekannte Labels, welche die Überprüfung der Zeitplanung beeinflussen, finden Sie unter [Unterstützte Labels für EKS Auto Mode](create-node-pool.md#auto-supported-labels).
Wenn Sie spezielle Speicheranforderungen haben, können Sie den kurzlebigen Speicher der Knoten anpassen `size` und `throughput` Ihren eigenen Speicher erstellen`iops`, auf den Sie [NodeClass](create-node-class.md)verweisen können. NodePool Erfahren Sie mehr über die [konfigurierbaren NodeClass ](create-node-class.md) Optionen.
**Beispiel für eine Speicherkonfiguration für NodeClass**
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
ephemeralStorage:
iops: 3000
size: 80Gi
throughput: 125
```
### Definieren Sie ein AWS Trainium und Inferentia AWS NodePool
Im Folgenden NodePool ist `eks.amazonaws.com/instance-category` festgelegt, dass nur Instanzen der Inferentia- und Trainium-Familie gestartet werden sollen:
```
- key: "eks.amazonaws.com/instance-category"
operator: In
values:
- inf
- trn
```
# EKS-Auto-Mode-Einstellungen konfigurieren
In diesem Kapitel wird beschrieben, wie Sie bestimmte Aspekte Ihrer Amazon Elastic Kubernetes Service (EKS)-Auto-Mode-Cluster konfigurieren. Während EKS Auto Mode die meisten Infrastrukturkomponenten automatisch verwaltet, können Sie bestimmte Features an Ihre Workload-Anforderungen anpassen.
Mithilfe der in diesem Thema beschriebenen Konfigurationsoptionen können Sie Netzwerkeinstellungen, Rechenressourcen und Lastausgleichsverhalten ändern und gleichzeitig die Vorteile der automatisierten Infrastrukturverwaltung beibehalten. Bevor Sie Konfigurationsänderungen vornehmen, überprüfen Sie die verfügbaren Optionen in den folgenden Abschnitten, um zu bestimmen, welcher Ansatz Ihren Anforderungen am besten entspricht.
| Welche Features möchten Sie konfigurieren? | Konfigurationsoption |
| --- | --- |
| **Knotenvernetzung und -speicherung** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/settings-auto.html) | [Knotenklasse für Amazon EKS erstellen](create-node-class.md) |
| **Knoten-Rechenressourcen** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/settings-auto.html) | [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md) |
| **Knotenpools mit statischer Kapazität** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/settings-auto.html) | [Statische Kapazitätsknotenpools im automatischen EKS-Modus](auto-static-capacity.md) |
| **Einstellungen für Application Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/settings-auto.html) | [Erstellen Sie einen IngressClass , um einen Application Load Balancer zu konfigurieren](auto-configure-alb.md) |
| **Einstellungen für Network Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/settings-auto.html) | [Verwendung von Service-Annotationen zur Konfiguration von Network Load Balancers](auto-configure-nlb.md) |
| **Einstellungen für Speicherklasse** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/settings-auto.html) | [Erstellen einer Speicherklasse](create-storage-class.md) |
| **ODCR-Nutzung steuern** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/settings-auto.html) | [Steuern Sie die Bereitstellung von Workloads in Kapazitätsreservierungen mit EKS Auto Mode.](auto-odcr.md) |
| **Erweiterte Sicherheit für Knoten** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/settings-auto.html) | [Erweiterte Sicherheitseinstellungen für Knoten konfigurieren](auto-advanced-security.md) |
# Knotenklasse für Amazon EKS erstellen
Amazon-EKS-Knotenklassen sind Vorlagen, die eine differenzierte Steuerung der Konfiguration Ihrer im EKS Auto Mode verwalteten Knoten ermöglichen. Eine Knotenklasse definiert Einstellungen auf Infrastrukturebene, die für Knotengruppen in Ihrem EKS-Cluster gelten, einschließlich Netzwerkkonfiguration, Speichereinstellungen und Ressourcen-Kennzeichnung. In diesem Thema wird erläutert, wie Sie eine Knotenklasse erstellen und konfigurieren, um Ihre spezifischen Betriebsanforderungen zu erfüllen.
Wenn Sie die Bereitstellung und Konfiguration von EC2-Instances in EKS Auto Mode über die Standardeinstellungen hinaus anpassen müssen, erhalten Sie durch die Erstellung einer Knotenklasse präzise Kontrolle über wichtige Infrastruktur-Parameter. Beispielsweise können Sie zur Erhöhung der Sicherheit die Platzierung in einem privaten Subnetz festlegen, für leistungssensitive Workloads flüchtigen Instance-Speicher konfigurieren oder zur Kostenverteilung benutzerdefinierte Tags zuweisen.
## Erstellung einer Knotenklasse
Um eine `NodeClass` zu erstellen, gehen Sie wie folgt vor:
1. YAML-Datei (zum Beispiel `nodeclass.yaml`) mit Ihrer Knotenklassen-Konfiguration erstellen
1. Konfiguration mithilfe von `kubectl` auf Ihren Cluster anwenden
1. Verweisen Sie in Ihrer Knoten-Pool-Konfiguration auf die Knotenklasse. Weitere Informationen finden Sie unter [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md).
Sie müssen `kubectl` installiert und konfiguriert haben. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
### Beispiel für eine grundlegende Knotenklasse
Hier ist ein Beispiel für eine Knotenklasse:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: private-compute
spec:
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
ephemeralStorage:
size: "160Gi"
```
Dies NodeClass erhöht die Menge an flüchtigem Speicher auf dem Knoten.
Wenden Sie diese Konfiguration wie folgt an
```
kubectl apply -f nodeclass.yaml
```
Verweisen Sie anschließend in Ihrer Knoten-Pool-Konfiguration auf die Knotenklasse. Weitere Informationen finden Sie unter [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md).
## Knotenklassen-Zugriffseintrag erstellen
Wenn Sie eine benutzerdefinierte Knotenklasse erstellen, müssen Sie einen EKS-Zugriffseintrag erstellen, damit die Knoten dem Cluster beitreten können. EKS erstellt automatisch Zugriffseinträge, wenn Sie die integrierte Knotenklasse und Knoten-Pools verwenden.
Informationen zur Funktionsweise von Zugriffseinträgen finden Sie unter [IAM-Benutzern mit EKS-Zugriffseinträgen Zugriff auf Kubernetes gewähren](access-entries.md)
Beim Erstellen von Zugriffseinträgen für EKS-Auto-Mode-Knotenklassen müssen Sie den `EC2`-Zugriffseintragstyp verwenden.
### Zugriffseintrag mit der CLI erstellen
**Um einen Zugriffseintrag für EC2-Knoten zu erstellen und die EKS-Auto-Node-Richtlinie zuzuordnen:**
Aktualisieren Sie die folgenden CLI-Befehle mit Ihrem Cluster-Namen und der Knotenrollen-ARN. Die Knotenrollen-ARN ist in der Knotenklasse YAML angegeben.
```
# Create the access entry for EC2 nodes
aws eks create-access-entry \
--cluster-name \
--principal-arn \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name \
--principal-arn \
--policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
--access-scope type=cluster
```
### Erstellen Sie einen Zugangseintrag mit CloudFormation
**Um einen Zugriffseintrag für EC2-Knoten zu erstellen und die EKS-Auto-Node-Richtlinie zuzuordnen:**
Aktualisieren Sie Folgendes CloudFormation mit Ihrem Clusternamen und Ihrem Knotenrollen-ARN. Die Knotenrollen-ARN ist in der Knotenklasse YAML angegeben.
```
EKSAutoNodeRoleAccessEntry:
Type: AWS::EKS::AccessEntry
Properties:
ClusterName:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
Informationen zur Bereitstellung von CloudFormation Stacks finden Sie unter [Erste Schritte mit CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)
## Knotenklassen-Spezifikation
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Required fields
# role and instanceProfile are mutually exclusive fields.
role: MyNodeRole # IAM role for EC2 instances
# instanceProfile: eks-MyNodeInstanceProfile # IAM instance-profile for EC2 instances
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
# Alternative using direct subnet ID
# - id: "subnet-0123456789abcdef0"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Alternative approaches:
# - id: "sg-0123456789abcdef0"
# - name: "eks-cluster-security-group"
# Optional: Pod subnet selector for advanced networking
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
# Alternative using direct subnet ID
# - id: "subnet-0987654321fedcba0"
# must include Pod security group selector also
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
# Alternative using direct security group ID
# - id: "sg-0123456789abcdef0"
# Optional: Selects on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
Name: "targeted-odcr"
# Optional owning account ID filter
owner: "012345678901"
# Optional fields
snatPolicy: Random # or Disabled
networkPolicy: DefaultAllow # or DefaultDeny
networkPolicyEventLogs: Disabled # or Enabled
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# Optional KMS key for encryption
kmsKeyID: "arn:aws: kms:region:account:key/key-id"
# Accepted formats:
# KMS Key ID
# KMS Key ARN
# Key Alias Name
# Key Alias ARN
advancedNetworking:
# Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
# If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
associatePublicIPAddress: false
# Optional: Forward proxy, commonly requires certificateBundles as well
# for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
#httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
noProxy: #Max 50 entries
- localhost #Max 255 characters each
- 127.0.0.1
#- ::1 # IPv6 localhost
#- 0:0:0:0:0:0:0:1 # IPv6 localhost
- 169.254.169.254 # EC2 Instance Metadata Service
#- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
# Domains to exclude, put all VPC endpoints here
- .internal
- .eks.amazonaws.com
# ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
ipv4PrefixSize: Auto # or "32"
# enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
enableV4Egress: false
advancedSecurity:
# Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
fips: false
# Optional: Custom certificate bundles.
certificateBundles:
- name: "custom-cert"
data: "base64-encoded-cert-data"
# Optional: Additional EC2 tags (with restrictions)
tags:
Environment: "production"
Team: "platform"
# Note: Cannot use restricted tags like:
# - kubernetes.io/cluster/*
# - karpenter.sh/provisioner-name
# - karpenter.sh/nodepool
# - karpenter.sh/nodeclaim
# - karpenter.sh/managed-by
# - eks.amazonaws.com/nodeclass
```
## Überlegungen
+ Wenn Sie überprüfen möchten, über wie viel lokalen Speicherplatz eine Instance verfügt, können Sie den Knoten beschreiben, um die flüchtige Speicher-Ressource anzuzeigen.
+ **Volumenverschlüsselung** — EKS verwendet den konfigurierten benutzerdefinierten KMS-Schlüssel, um das schreibgeschützte Root-Volume der Instanz und das Datenvolumen zu verschlüsseln. read/write
+ **IAM-Rolle des Knotens ersetzen** – Wenn Sie die einer `NodeClass` zugeordneten IAM-Rolle ändern, müssen Sie einen neuen Zugriffseintrag erstellen. EKS erstellt während der Cluster-Erstellung automatisch einen Zugriffseintrag für die IAM-Rolle des Knotens. Die IAM-Rolle des Knotens erfordert die `AmazonEKSAutoNodePolicy`-EKS-Zugriffsrichtlinie. Weitere Informationen finden Sie unter [IAM-Benutzern mit EKS-Zugriffseinträgen Zugriff auf Kubernetes gewähren](access-entries.md).
+ **Maximale Pod-Dichte** – EKS begrenzt die maximale Anzahl von Pods auf einem Knoten auf 110. Diese Begrenzung wird nach der vorhandenen Berechnung der maximalen Pods angewendet. Weitere Informationen finden Sie unter [Auswahl eines optimalen Amazon-EC2-Knoten-Instance-Typs](choosing-instance-type.md).
+ **Tags** – Wenn Sie Tags von Kubernetes auf EC2 übertragen möchten, müssen Sie zusätzliche IAM-Berechtigungen konfigurieren. Weitere Informationen finden Sie unter [Weitere Informationen zu Identität und Zugriff in EKS Auto Mode](auto-learn-iam.md).
+ **Standard-Knotenklasse** – Benennen Sie Ihre benutzerdefinierte Knotenklasse `default` nicht. Dies liegt daran, dass EKS Auto Mode eine `NodeClass` mit dem Namen `default` enthält, die automatisch bereitgestellt wird, wenn Sie mindestens ein integriertes `NodePool` aktivieren. Informationen zur Aktivierung des integrierten `NodePools` finden Sie unter [Integriert aktivieren oder deaktivieren NodePools](set-builtin-node-pools.md).
+ ** `subnetSelectorTerms`-Verhalten bei mehreren Subnetzen** – Wenn mehrere Subnetze vorhanden sind, die den `subnetSelectorTerms`-Bedingungen entsprechen oder die Sie anhand der ID angeben, erstellt der EKS Auto Mode Knoten, die über die Subnetze verteilt sind.
+ Wenn sich die Subnetze in unterschiedlichen Availability Zones (AZs) befinden, können Sie Kubernetes-Funktionen wie [Spread-Beschränkungen für die Pod-Topologie und Topology](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints) [Aware Routing](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) verwenden, um Pods und Traffic auf die Zonen zu verteilen.
+ Wenn es *in derselben AZ* mehrere Subnetze gibt, die mit `subnetSelectorTerms` übereinstimmen, erstellt EKS Auto Mode Pods auf jedem Knoten, die über die Subnetze in dieser AZ verteilt sind. EKS Auto Mode erstellt sekundäre Netzwerkschnittstellen auf jedem Knoten in den anderen Subnetzen derselben AZ. Die Auswahl erfolgt anhand der Anzahl der verfügbaren IP-Adressen in jedem Subnetz, um die Subnetze effizienter zu nutzen. Sie können jedoch nicht festlegen, welches Subnetz EKS Auto Mode für jeden Pod verwendet. Wenn Sie möchten, dass Pods in bestimmten Subnetzen ausgeführt werden, verwenden Sie stattdessen [Separate Subnetze und Sicherheitsgruppen für Pods](#pod-subnet-selector).
## Separate Subnetze und Sicherheitsgruppen für Pods
Die `podSecurityGroupSelectorTerms` Felder `podSubnetSelectorTerms` und ermöglichen erweiterte Netzwerkkonfigurationen, da Pods andere Subnetze und Sicherheitsgruppen als ihre Knoten verwenden können. Beide Felder müssen zusammen angegeben werden. Diese Trennung bietet eine verbesserte Kontrolle über das Routing des Netzwerkverkehrs und die Sicherheitsrichtlinien.
**Anmerkung**
Diese Funktion unterscheidet sich von der Funktion [Security Groups for Pods](security-groups-for-pods.md) (SGPP), die mit der AWS VPC CNI für Datenverarbeitung im automatischen Modus ohne EKS verwendet wird. SGPP wird im automatischen EKS-Modus nicht unterstützt. Verwenden Sie stattdessen `podSecurityGroupSelectorTerms` in, `NodeClass` um separate Sicherheitsgruppen auf den Pod-Verkehr anzuwenden. Die Sicherheitsgruppen gelten auf der `NodeClass` Ebene, d. h. alle Pods auf Knoten, die diese verwenden, `NodeClass` teilen sich dieselben Pod-Sicherheitsgruppen.
### Funktionsweise
Wenn Sie konfigurieren `podSubnetSelectorTerms` und`podSecurityGroupSelectorTerms`:
1. Die primäre ENI des Knotens verwendet die Subnetze und Sicherheitsgruppen von `subnetSelectorTerms` und`securityGroupSelectorTerms`. Dieser Schnittstelle ist nur die eigene IP-Adresse des Knotens zugewiesen.
1. Der automatische EKS-Modus erstellt ENIs in den übereinstimmenden Subnetzen ein sekundäres `podSubnetSelectorTerms` Element, wobei die Sicherheitsgruppen von `podSecurityGroupSelectorTerms` angehängt werden. Pod-IP-Adressen werden diesen sekundären Adressen standardmäßig ENIs mit /28-Präfixen zugewiesen. Wenn kein zusammenhängender Präfixblock verfügbar ist, wird automatisch auf sekundäre Adressen IPs (/32) zurückgegriffen. Wenn auf in gesetzt `ipv4PrefixSize` ist, werden nur sekundäre Geräte `"32"` verwendet`advancedNetworking`. IPs
1. Die unter angegebenen Sicherheitsgruppen `podSecurityGroupSelectorTerms` gelten für den Pod-Verkehr innerhalb der VPC. Für Datenverkehr außerhalb der VPC verwenden Pods die primäre ENI des Knotens (und seine Sicherheitsgruppen), da die Source Network Address Translation (SNAT) die Pod-IP in die Knoten-IP übersetzt. Sie können dieses Verhalten mit dem Feld in der `snatPolicy` ändern. `NodeClass`
### Anwendungsfälle
Verwenden Sie `podSubnetSelectorTerms` und `podSecurityGroupSelectorTerms` wann Sie müssen:
+ Wenden Sie verschiedene Sicherheitsgruppen an, um den Verkehr für Knoten und Pods getrennt zu steuern.
+ Trennen Sie den Infrastrukturverkehr (node-to-node Kommunikation) vom Anwendungsverkehr (Pod-to-Pod Kommunikation).
+ Wenden Sie auf Knoten-Subnetze andere Netzwerkkonfigurationen an als auf Pod-Subnetze.
+ Konfigurieren Sie Reverse-Proxys oder Netzwerkfilter speziell für den Knoten-Datenverkehr, ohne den Pod-Datenverkehr zu beeinträchtigen. Verwenden Sie `advancedNetworking` und `certificateBundles`, um Ihren Reverse-Proxy und alle selbstsignierten oder privaten Zertifikate für den Proxy zu definieren.
### Beispielkonfiguration
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
# Subnets and security groups for EC2 instances (nodes)
subnetSelectorTerms:
- tags:
Name: "node-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Separate subnets and security groups for Pods
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
```
### Überlegungen zu separaten Pod-Subnetzen und Sicherheitsgruppen
+ **Geltungsbereich der Sicherheitsgruppe**: Die Sicherheitsgruppen von `podSecurityGroupSelectorTerms` sind an die sekundäre Gruppe angehängt ENIs und gelten für den Pod-Verkehr innerhalb der VPC. Wenn SNAT aktiviert ist (Standard`snatPolicy: Random`), wird der Datenverkehr, der die VPC verlässt, in die primäre ENI-IP-Adresse des Knotens übersetzt, sodass die Sicherheitsgruppen des Knotens stattdessen für diesen Datenverkehr `securityGroupSelectorTerms` gelten. Wenn Sie diese Einstellung festlegen`snatPolicy: Disabled`, verwenden Pods ihre eigenen IP-Adressen für den gesamten Datenverkehr, und Sie müssen sicherstellen, dass Routing- und Sicherheitsgruppen entsprechend konfiguriert sind.
+ **NodeClassGranularität auf -Ebene**: Die Pod-Sicherheitsgruppen gelten für alle Pods, die auf Knoten geplant sind, die die verwenden. `NodeClass` Um unterschiedliche Sicherheitsgruppen auf unterschiedliche Workloads anzuwenden, erstellen Sie separate `NodePool` Ressourcen `NodeClass` und verwenden Sie Taints, Toleranzen oder Node-Selectoren, um Workloads auf die entsprechenden Knoten zu planen.
+ **Reduzierte Pod-Dichte**: Auf jedem Knoten können weniger Pods ausgeführt werden, da die primäre Netzwerkschnittstelle des Knotens für die Knoten-IP reserviert ist und nicht für Pods verwendet werden kann.
+ **Einschränkungen bei der Subnetzauswahl**: Der Standard `subnetSelectorTerms` und die `securityGroupSelectorTerms` Konfigurationen gelten nicht für die Auswahl des Pod-Subnetzes oder der Sicherheitsgruppe.
+ **Netzwerk-Planung**: Stellen Sie sicher, dass in den Knoten- und Pod-Subnetzen ausreichend IP-Adressraum vorhanden ist, um Ihre Workload-Anforderungen zu erfüllen.
+ **Routing-Konfiguration**: Stellen Sie sicher, dass die Routing-Tabelle und die Netzwerkzugriffssteuerungsliste (ACL) der Pod-Subnetze ordnungsgemäß für die Kommunikation zwischen Knoten- und Pod-Subnetzen konfiguriert sind.
+ **Availability Zones**: Stellen Sie sicher, dass Sie Pod-Subnetze für mehrere erstellt haben. AZs Wenn Sie ein bestimmtes Pod-Subnetz verwenden, muss es sich in derselben AZ wie das Knotensubnetz AZ befinden.
## Sekundärer IP-Modus für Pods
Das `ipv4PrefixSize` Feld ermöglicht erweiterte Netzwerkkonfigurationen, indem Knoten nur sekundäre IP-Adressen zugewiesen werden. Diese Funktion weist Knoten keine Präfixe (/28) zu und behält nur eine sekundäre IP als Minimalwert bei. IPTarget
### Anwendungsfälle
Verwenden Sie `ipv4PrefixSize`, wenn Sie Folgendes benötigen:
+ **Reduzierte IP-Auslastung**: In jedem Knoten wird nur eine IP-Adresse aufgewärmt.
+ **Geringere Anzahl an Pods**: Die Geschwindigkeit der Pod-Erstellung ist kein großes Problem.
+ **Keine Präfixfragmentierung: Die durch das Präfix** verursachte Fragmentierung ist ein großes Problem oder verhindert die Verwendung des automatischen Modus.
### Beispielkonfiguration
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
ipv4PrefixSize: "32"
```
### Überlegungen zum sekundären IP-Modus
+ **Geringere Geschwindigkeit bei der Pod-Erstellung**: Da nur eine sekundäre IP aufgewärmt ist, benötigt der IPAM-Dienst mehr Zeit für die Bereitstellung, IPs wenn mehr Pods erstellt werden.
## Deaktiviert den IPv4 Ausgang von IPv6 Pods in Clustern. IPv6
Das `enableV4Egress` Feld ist `true` standardmäßig. Bei IPv6 Clustern im automatischen Modus kann die Funktion deaktiviert werden, sodass im automatischen Modus keine reine IPv4 Ausgangsschnittstelle für Pods erstellt wird. IPv6 Dies ist wichtig, da die IPv4 Ausgangsschnittstelle nicht der Durchsetzung von Netzwerkrichtlinien unterliegt. Netzwerkrichtlinien werden nur auf der primären Schnittstelle des Pods (eth0) durchgesetzt.
### Anwendungsfälle
Verwenden Sie `enableV4Egress`, wenn Sie Folgendes benötigen:
+ ** IPv6 Cluster verwenden**: IPv4 Ausgehender Datenverkehr ist standardmäßig zulässig.
+ **Netzwerkrichtlinie verwenden**: Derzeit unterstützt die EKS-Netzwerkrichtlinie keinen Dual-Stack-Modus. Durch die Deaktivierung `enableV4Egress` kann verhindert werden, dass der Pod-Verkehr unerwartet übergeht. IPv4
### Beispielkonfiguration
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
enableV4Egress: false
```
### Überlegungen zur Deaktivierung von EnableV4Egress
+ **Netzwerkrichtlinie im IPv6 Cluster: IPv6 Cluster lassen standardmäßig Datenverkehr** zu. IPv4 Diese Einstellung `enableV4Egress: false` blockiert IPv4 ausgehenden Datenverkehr und sorgt so für mehr Sicherheit, insbesondere bei Verwendung mit Netzwerkrichtlinien.
# Einen Knotenpool für EKS Auto Mode erstellen
Amazon-EKS-Knoten-Pools bieten eine flexible Möglichkeit zur Verwaltung von Rechenressourcen in Ihrem Kubernetes-Cluster. Dieses Thema veranschaulicht, wie Sie mit Karpenter, einem Tool zur Bereitstellung von Knoten, das die Cluster-Skalierung und Ressourcenauslastung optimiert, Knoten-Pools erstellen und konfigurieren können. Mit der NodePool-Ressource von Karpenter können Sie spezifische Anforderungen für Ihre Rechenressourcen definieren, darunter Instance-Typen, Availability Zones, Architekturen und Kapazitätstypen.
Die integrierten `system`- und `general-purpose`- Knoten-Pools können nicht geändert werden. Sie können sie lediglich aktivieren oder deaktivieren. Weitere Informationen finden Sie unter [Integriert aktivieren oder deaktivieren NodePools](set-builtin-node-pools.md).
Die NodePool-Spezifikation ermöglicht eine detaillierte Steuerung der Rechenressourcen Ihres EKS-Clusters durch verschiedene unterstützte Labels und Anforderungen. Dazu gehören Optionen zur Festlegung von EC2-Instance-Kategorien, CPU-Konfigurationen, Availability Zones, Architekturen (ARM64/AMD64) und Kapazitätstypen (Spot oder On-Demand). Sie können auch Ressourcenlimits für die CPU- und Speichernutzung festlegen, um sicherzustellen, dass Ihr Cluster innerhalb der erforderlichen Betriebsgrenzen bleibt.
EKS Auto Mode nutzt bekannte Kubernetes-Labels, um konsistente und standardisierte Methoden zur Identifizierung von Knotenmerkmalen bereitzustellen. Diese Labels, wie beispielsweise `topology.kubernetes.io/zone` für Availability Zones und `kubernetes.io/arch` für die CPU-Architektur, entsprechen den gängigen Kubernetes-Konventionen. Darüber hinaus erweitern EKS-spezifische Labels (mit dem Präfix `eks.amazonaws.com/`) diese Funktionalität um AWS-spezifische Attribute wie Instance-Typen, CPU-Hersteller, GPU-Fähigkeiten und Netzwerk-Spezifikationen. Dieses standardisierte Kennzeichnungssystem ermöglicht eine nahtlose Integration in vorhandene Kubernetes-Tools und bietet gleichzeitig eine umfassende AWS-Infrastrukturintegration.
## Einen NodePool erstellen
Führen Sie die folgenden Schritte aus, um einen NodePool für Ihren Amazon-EKS-Cluster zu erstellen
1. Erstellen Sie eine YAML-Datei mit dem Namen `nodepool.yaml` und der erforderlichen NodePool-Konfiguration. Sie können die folgende Beispielkonfiguration verwenden.
1. Wenden Sie den NodePool auf Ihren Cluster an:
```
kubectl apply -f nodepool.yaml
```
1. Überprüfen Sie, ob der NodePool erfolgreich erstellt wurde:
```
kubectl get nodepools
```
1. (Optional) Überwachen Sie den NodePool-Status:
```
kubectl describe nodepool default
```
Stellen Sie sicher, dass Ihr NodePool auf eine gültige NodeClass verweist, die in Ihrem Cluster vorhanden ist. Die NodeClass definiert AWS-spezifische Konfigurationen für Ihre Rechenressourcen. Weitere Informationen finden Sie unter [Knotenklasse für Amazon EKS erstellen](create-node-class.md).
## Beispiel-NodePool
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## Unterstützte Labels für EKS Auto Mode
EKS Auto Mode unterstützt die folgenden bekannten Labels.
**Anmerkung**
EKS Auto Mode verwendet andere Bezeichnungen als Karpenter. Bezeichnungen, die sich auf von EC2 verwaltete Instances beziehen, beginnen mit `eks.amazonaws.com`.
| Label (Bezeichnung) | Beispiel | Beschreibung |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-east-2a | Region AWS |
| node.kubernetes.io/instance-type | g4dn.8xgroß | AWS-Instance-Typ |
| kubernetes.io/arch | amd64 | Architekturen werden durch [GOARCH-Werte](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58) auf der Instance definiert. |
| karpenter.sh/capacity-type | spot | Zu den Kapazitätstypen gehören `spot`, `on-demand` |
| eks.amazonaws.com/instance-hypervisor | nitro | Instance-Typen, die einen bestimmten Hypervisor verwenden |
| eks.amazonaws.com/compute-type | auto | Identifiziert von EKS Auto Mode verwaltete Knoten |
| eks.amazonaws.com/instance-encryption-in-transit-supported | true | Instance-Typen, welche die Verschlüsselung während der Übertragung unterstützen (oder nicht) |
| eks.amazonaws.com/instance-category | g | Instance-Typen derselben Kategorie, in der Regel die Zeichenfolge vor der Generierungsnummer |
| eks.amazonaws.com/instance-generation | 4 | Instace-Typ-Generierungsnummer innerhalb einer Instance-Kategorie |
| eks.amazonaws.com/instance-family | g4dn | Instance-Typen mit ähnlichen Eigenschaften, aber unterschiedlichen Ressourcenmengen |
| eks.amazonaws.com/instance-size | 8xlarge | Instance-Typen mit ähnlichen Ressourcenmengen, jedoch unterschiedlichen Eigenschaften |
| eks.amazonaws.com/instance-cpu | 32 | Anzahl der CPUs auf der Instance |
| eks.amazonaws.com/instance-cpu-manufacturer | `aws` | Name des CPU-Herstellers |
| eks.amazonaws.com/instance-memory | 13 1072 | Anzahl der Mebibyte Speicher auf der Instance |
| eks.amazonaws.com/instance-ebs-bandwidth | 9 500 | Anzahl der verfügbaren [maximalen Megabits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance) auf der Instance |
| eks.amazonaws.com/instance-network-bandwidth | 13 1072 | Anzahl der verfügbaren [Basis-Megabits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) auf der Instance |
| eks.amazonaws.com/instance-gpu-name | t4 | Name der GPU auf der Instance, sofern verfügbar |
| eks.amazonaws.com/instance-gpu-manufacturer | nvidia | Name des GPU-Herstellers |
| eks.amazonaws.com/instance-gpu-count | 1 | Anzahl der GPUs auf der Instance |
| eks.amazonaws.com/instance-gpu-memory | 16 384 | Anzahl der Mebibyte Speicher auf der GPU |
| eks.amazonaws.com/instance-local-nvme | 900 | Anzahl der Gibibyte lokalen NVMe-Speichers auf der Instance |
**Anmerkung**
EKS Auto Mode unterstützt nur bestimmte Instances und hat Mindestgrößenanforderungen. Weitere Informationen finden Sie unter [Unterstützte Instance-Referenz für EKS Auto Mode](automode-learn-instances.md#auto-supported-instances).
## Von EKS Auto Mode nicht unterstützte Labels
EKS Auto Mode unterstützt die folgenden Labels nicht.
+ EKS Auto Mode unterstützt Linux nicht
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## Integrierte Knoten-Pools deaktivieren
Wenn Sie benutzerdefinierte Knoten-Pools erstellen, können Sie die integrierten Knoten-Pools deaktivieren. Weitere Informationen finden Sie unter [Integriert aktivieren oder deaktivieren NodePools](set-builtin-node-pools.md).
## Cluster ohne integrierte Knoten-Pools
Sie können einen Cluster ohne integrierte Knoten-Pools erstellen. Dies ist nützlich, wenn Ihr Unternehmen benutzerdefinierte Knoten-Pools erstellt hat.
**Anmerkung**
Wenn Sie einen Cluster ohne integrierte Knoten-Pools erstellen, wird die `default` NodeClass nicht automatisch bereitgestellt. Sie müssen eine benutzerdefinierte NodeClass erstellen. Weitere Informationen finden Sie unter [Knotenklasse für Amazon EKS erstellen](create-node-class.md).
**Übersicht:**
1. Erstellen Sie einen EKS-Cluster, bei dem die `nodePools`- und `nodeRoleArn`-Werte leer sind.
+ Beispiel-eksctl `autoModeConfig`:
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
Weitere Informationen finden Sie unter [Erstellung eines EKS-Auto-Mode-Clusters mit der eksctl-Befehlszeilenschnittstelle](automode-get-started-eksctl.md).
1. Benutzerdefinierte Knotenklasse mit einer Knotenrollen-ARN erstellen
+ Weitere Informationen finden Sie unter [Knotenklasse für Amazon EKS erstellen](create-node-class.md).
1. Zugriffseintrag für die benutzerdefinierte Knotenklasse erstellen
+ Weitere Informationen finden Sie unter [Knotenklassen-Zugriffseintrag erstellen](create-node-class.md#auto-node-access-entry).
1. Erstellen Sie einen benutzerdefinierten Knoten-Pool, wie oben beschrieben.
## Unterbrechung
Sie können EKS Auto Mode so konfigurieren, dass Knoten über Ihren NodePool auf verschiedene Arten unterbrochen werden. Sie können `spec.disruption.consolidationPolicy`, `spec.disruption.consolidateAfter` oder `spec.template.spec.expireAfter` verwenden. Sie können die Unterbrechung von EKS Auto Mode auch über den `spec.disruption.budgets` des NodePools begrenzen. Außerdem können Sie die Zeitfenster und die Anzahl der gleichzeitig unterbrochenen Knoten steuern. Anweisungen zur Konfiguration dieses Verhaltens finden Sie unter [Unterbrechung](https://karpenter.sh/docs/concepts/disruption/) in der Karpenter-Dokumentation.
Sie können Unterbrechungen für Knoten-Pools wie folgt konfigurieren:
+ Identifizieren Sie, wann Instances nicht ausreichend ausgelastet sind, und konsolidieren Sie Workloads.
+ Erstellen Sie ein Budget für Knoten-Pool-Unterbrechung, um die Beendigung von Knoten aufgrund von Abweichungen, Leerständen und Konsolidierungen zu begrenzen.
Standardmäßig macht EKS Auto Mode Folgendes:
+ Konsolidiert nicht ausgelastete Instances.
+ Beendet Instances nach 336 Stunden.
+ Legt ein einzelnes Budget für Unterbrechung von 10 % der Knoten fest.
+ Ermöglicht den Austausch von Knoten aufgrund von Abweichungen, wenn eine neue AMI im Automatikmodus veröffentlicht wird. Das kommt etwa einmal pro Woche vor.
## Kündigungsfrist
Wenn ein `terminationGracePeriod` in einem EKS Auto NodePool nicht explizit definiert ist, wendet das System automatisch eine standardmäßige 24-stündige Kündigungsfrist auf den zugehörigen NodeClaim an. Während EKS-Auto-Kunden in ihren benutzerdefinierten NodePool-Konfigurationen keinen Standardwert von `terminationGracePeriod` sehen, beobachten sie diesen Standardwert im NodeClaim. Die Funktionalität bleibt konsistent, unabhängig davon, ob die Karenzzeit explizit im NodePool festgelegt oder im NodeClaim standardmäßig festgelegt ist. Dies gewährleistet ein vorhersehbares Knoten-Beendigungsverhalten im gesamten Cluster.
# Statische Kapazitätsknotenpools im automatischen EKS-Modus
Amazon EKS Auto Mode unterstützt Knotenpools mit statischer Kapazität, die unabhängig vom Pod-Bedarf eine feste Anzahl von Knoten beibehalten. Knotenpools mit statischer Kapazität sind nützlich für Workloads, die vorhersehbare Kapazität, reservierte Instances oder spezifische Compliance-Anforderungen erfordern, bei denen Sie eine konsistente Infrastruktur aufrechterhalten müssen.
Im Gegensatz zu dynamischen Knotenpools, die auf der Grundlage der Pod-Scheduling-Anforderungen skaliert werden, behalten Knotenpools mit statischer Kapazität die Anzahl der von Ihnen konfigurierten Knoten bei.
## Konfigurieren Sie einen Knotenpool mit statischer Kapazität
Um einen Knotenpool mit statischer Kapazität zu erstellen, legen Sie das `replicas` Feld in Ihrer NodePool Spezifikation fest. Das `replicas` Feld definiert die genaue Anzahl von Knoten, die der Knotenpool verwalten wird. Informationen [Beispiele](#static-capacity-examples) zur Konfiguration finden Sie unter`replicas`.
## Überlegungen zum Knotenpool mit statischer Kapazität
Knotenpools mit statischer Kapazität weisen mehrere wichtige Einschränkungen und Verhaltensweisen auf:
**Einschränkungen bei der Konfiguration:**
+ Der **Modus kann nicht gewechselt** werden: Sobald Sie einen Knotenpool eingerichtet `replicas` haben, können Sie ihn nicht mehr entfernen. Der Knotenpool kann nicht zwischen statischem und dynamischem Modus wechseln.
+ **Begrenzte Ressourcenlimits**: Nur das `limits.nodes` Feld wird im Abschnitt „Limits“ unterstützt. CPU- und Speichergrenzwerte gelten nicht.
+ **Kein Gewichtungsfeld**: Das `weight` Feld kann nicht für Knotenpools mit statischer Kapazität festgelegt werden, da die Knotenauswahl nicht auf der Priorität basiert.
**Betriebsverhalten:**
+ **Keine Konsolidierung**: Knoten in statischen Kapazitätspools werden für die Konsolidierung nicht berücksichtigt.
+ **Skalierung von Abläufen**: Skalierungsoperationen umgehen Budgets für Knotenunterbrechungen, werden aber trotzdem eingehalten PodDisruptionBudgets.
+ **Node-Austausch**: Nodes werden aufgrund von Drift (z. B. AMI-Updates) und Ablaufzeiten immer noch auf Grundlage Ihrer Konfiguration ersetzt.
## Best Practices
**Kapazitätsplanung:**
+ Legen Sie einen `limits.nodes` höheren Wert als fest`replicas`, um eine temporäre Skalierung bei Vorgängen zum Austausch von Knoten zu ermöglichen.
+ Berücksichtigen Sie bei der Festlegung von Grenzwerten die maximale Kapazität, die bei Node-Drift- oder AMI-Updates benötigt wird.
**Auswahl der Instanz:**
+ Verwenden Sie bestimmte Instance-Typen, wenn Sie Reserved Instances haben oder bestimmte Hardwareanforderungen haben.
+ Vermeiden Sie zu restriktive Anforderungen, die die Instance-Verfügbarkeit während der Skalierung einschränken könnten.
**Störungsmanagement:**
+ Richten Sie angemessene Budgets für Unterbrechungen ein, um ein Gleichgewicht zwischen Verfügbarkeit und Wartungsbetrieb herzustellen.
+ Berücksichtigen Sie bei der Festlegung von Budgetanteilen die Toleranz Ihrer Anwendung in Bezug auf den Austausch von Knoten.
**Überwachung:**
+ Überwachen Sie das `status.nodes` Feld regelmäßig, um sicherzustellen, dass Ihre gewünschte Kapazität erhalten bleibt.
+ Richten Sie Warnmeldungen ein, wenn die tatsächliche Knotenzahl von den gewünschten Replikaten abweicht.
**Zonenverteilung:**
+ Für eine hohe Verfügbarkeit sollten Sie die statische Kapazität auf mehrere Availability Zones verteilen.
+ Wenn Sie einen Knotenpool mit statischer Kapazität erstellen, der sich über mehrere Availability Zones erstreckt, verteilt EKS Auto Mode die Knoten auf die angegebenen Zonen, aber es kann nicht garantiert werden, dass die Verteilung gleichmäßig ist.
+ Für eine vorhersehbare und gleichmäßige Verteilung über die Availability Zones sollten Sie separate statische Kapazitätsknotenpools erstellen, die jeweils anhand der Anforderung an eine bestimmte Availability Zone gebunden sind. `topology.kubernetes.io/zone`
+ Wenn Sie 12 Knoten benötigen, die gleichmäßig auf drei Zonen verteilt sind, erstellen Sie drei Knotenpools mit jeweils 4 Replikaten anstelle eines Knotenpools mit 12 Replikaten in drei Zonen.
## Skalieren Sie einen Knotenpool mit statischer Kapazität
Sie können die Anzahl der Replikate in einem Knotenpool mit statischer Kapazität mithilfe des `kubectl scale` folgenden Befehls ändern:
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
Beim Herunterskalieren beendet der automatische Modus von EKS die Knoten ordnungsgemäß. Dabei werden laufende Pods berücksichtigt PodDisruptionBudgets und können auf die verbleibenden Knoten verschoben werden.
## Überwachen Sie Knotenpools mit statischer Kapazität
Verwenden Sie die folgenden Befehle, um Ihre Knotenpools mit statischer Kapazität zu überwachen:
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
Das `status.nodes` Feld zeigt die aktuelle Anzahl der vom Knotenpool verwalteten Knoten, die unter normalen Bedingungen Ihrer gewünschten `replicas` Anzahl entsprechen sollte.
## Fehlerbehebung
**Knoten, die die gewünschten Replikate nicht erreichen:**
+ Prüfen Sie, ob der `limits.nodes` Wert ausreichend ist
+ Stellen Sie sicher, dass Ihre Anforderungen die Instanzauswahl nicht zu stark einschränken
+ Prüfen Sie die AWS Servicekontingente für die Instanztypen und Regionen, die Sie verwenden
**Der Austausch des Knotens dauert zu lange:**
+ Passen Sie die Budgets für Unterbrechungen an, um mehr gleichzeitige Ersatzlieferungen zu ermöglichen
+ Prüfen Sie, ob PodDisruptionBudgets die Kündigung eines Knotens verhindert wird
**Unerwarteter Knotenabbruch:**
+ Überprüfen Sie `expireAfter` die `terminationGracePeriod` Einstellungen
+ Suchen Sie nach manuellen Knotenabbrüchen oder AWS Wartungsereignissen
## Beispiele
### Grundlegender Knotenpool mit statischer Kapazität
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### Statische Kapazität mit bestimmten Instanztypen
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### Knotenpool mit statischer Kapazität aus mehreren Zonen
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### Statische Kapazität mit Kapazitätsreservierung
Das folgende Beispiel zeigt, wie ein statischer Kapazitätsknotenpool mit einer EC2-Kapazitätsreservierung verwendet wird. Weitere Informationen zur Verwendung von EC2-Kapazitätsreservierungen mit dem automatischen EKS-Modus finden Sie unter. [Steuern Sie die Bereitstellung von Workloads in Kapazitätsreservierungen mit EKS Auto Mode.](auto-odcr.md)
`NodeClass`definieren der `capacityReservationSelectorTerms`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
`NodePool`auf das Obige verweisen `NodeClass` und verwenden`karpenter.sh/capacity-type: reserved`.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# Erstellen Sie einen IngressClass , um einen Application Load Balancer zu konfigurieren
EKS Auto Mode automatisiert Routineaufgaben für den Lastausgleich, einschließlich der Bereitstellung von Cluster-Anwendungen im Internet
AWS schlägt vor, Application Load Balancers (ALB) für den HTTP- und HTTPS-Verkehr zu verwenden. Application Load Balancers können Anfragen basierend auf dem Inhalt der Anfrage weiterleiten. Weitere Informationen über Application Load Balancer finden Sie unter [Was ist elastischer Lastenausgleich?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html).
Der automatische EKS-Modus erstellt und konfiguriert Application Load Balancers (). ALBs Beispielsweise erstellt EKS Auto Mode einen Load Balancer, wenn Sie ein `Ingress`-Kubernetes-Objekt erstellen, und konfiguriert ihn so, dass der Datenverkehr an Ihre Cluster-Workload weitergeleitet wird.
**Übersicht**
1. Erstellen Sie eine Workload, die Sie im Internet verfügbar machen möchten.
1. Erstellen Sie eine `IngressClassParams` Ressource und geben Sie AWS bestimmte Konfigurationswerte an, z. B. das zu verwendende Zertifikat SSL/TLS und VPC-Subnetze.
1. Erstellen Sie eine `IngressClass`-Ressource und legen Sie fest, dass EKS Auto Mode als Controller für die Ressource dienen soll.
1. Erstellen Sie eine `Ingress`-Ressource, die einen HTTP-Pfad und einen Port mit einer Cluster-Workload verknüpft.
EKS Auto Mode erstellt einen Application Load Balancer, der auf die in der `Ingress`-Ressource angegebene Workload verweist und die in der `IngressClassParams`-Ressource angegebene Load-Balancer-Konfiguration verwendet.
## Voraussetzungen
+ EKS Auto Mode in einem Amazon-EKS-Cluster aktiviert
+ Kubectl für die Verbindung mit Ihrem Cluster konfiguriert
+ Sie können `kubectl apply -f ` verwenden um die unten aufgeführten YAML-Beispiel-Konfigurationsdateien in Ihren Cluster anwenden.
**Anmerkung**
EKS Auto Mode erfordert Subnetz-Tags zur Identifizierung öffentlicher und privater Subnetze.
Wenn Sie Ihren Cluster mit `eksctl` erstellt haben, verfügen Sie bereits über diese Tags.
Weitere Informationen erhalten Sie unter [Kennzeichnung von Subnetzen für EKS Auto Mode](tag-subnets-auto.md).
## Schritt 1: Workload erstellen
Erstellen Sie zunächst eine Workload, die Sie im Internet verfügbar machen möchten. Dies kann jede Kubernetes-Ressource sein, die HTTP-Datenverkehr bereitstellt, z. B. eine Bereitstellung oder ein Service.
In diesem Beispiel wird ein einfacher HTTP-Service mit dem Namen `service-2048` verwendet, der auf Port `80` empfangsbereit ist. Erstellen Sie diesen Service und dessen Bereitstellung, indem Sie das folgende Manifest `2048-deployment-service.yaml` anwenden:
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
Wenden Sie die Konfiguration auf Ihren Cluster an:
```
kubectl apply -f 2048-deployment-service.yaml
```
Die oben aufgeführten Ressourcen werden im Standard-Namespace erstellt. Sie können dies durch Ausführung des folgenden Befehls überprüfen:
```
kubectl get all -n default
```
## Schritt 2: Erstellen IngressClassParams
Erstellen Sie ein `IngressClassParams` Objekt, um AWS spezifische Konfigurationsoptionen für den Application Load Balancer anzugeben. In diesem Beispiel erstellen wir eine `IngressClassParams`-Ressource mit dem Namen `alb` (die Sie im nächsten Schritt verwenden werden), die das Load-Balancer-Schema als `internet-facing` in einer Datei mit dem Namen `alb-ingressclassparams.yaml` festlegt.
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
Wenden Sie die Konfiguration auf Ihren Cluster an:
```
kubectl apply -f alb-ingressclassparams.yaml
```
## Schritt 3: Erstellen IngressClass
Erstellen Sie eine`IngressClass`, die auf die AWS spezifischen Konfigurationswerte verweist, die in der `IngressClassParams` Ressource in einer Datei mit dem Namen festgelegt sind`alb-ingressclass.yaml`. Notieren Sie den Namen des `IngressClass`. In diesem Beispiel haben sowohl `IngressClass` als auch `IngressClassParams` den Namen `alb`.
Verwenden Sie die `is-default-class`-Annotation, um zu steuern, ob `Ingress`-Ressourcen diese Klasse standardmäßig verwenden sollen.
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
Weitere Informationen zu den Konfigurationsoptionen finden Sie unter [IngressClassParams Referenz](#ingress-reference).
Wenden Sie die Konfiguration auf Ihren Cluster an:
```
kubectl apply -f alb-ingressclass.yaml
```
## Schritt 4: Ingress erstellen
Erstellen Sie eine `Ingress`-Ressource in einer Datei mit dem Namen `alb-ingress.yaml`. Der Zweck dieser Ressource besteht darin, Pfade und Ports dem Application Load Balancer mit Workloads in Ihrem Cluster zuzuordnen. Für dieses Beispiel erstellen wir eine `Ingress`-Ressource mit dem Namen `2048-ingress`, die den Datenverkehr an einen Service mit dem Namen `service-2048` auf Port 80 weiterleitet.
Weitere Informationen zum Konfigurieren dieser Ressource finden Sie unter [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) in der Kubernetes-Dokumentation.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
Wenden Sie die Konfiguration auf Ihren Cluster an:
```
kubectl apply -f alb-ingress.yaml
```
## Schritt 5: Status überprüfen
Verwenden Sie `kubectl`, um den Status von `Ingress` zu ermitteln. Es kann einige Minuten dauern, bis der Load Balancer verfügbar ist.
Verwenden Sie den Namen der `Ingress`-Ressource, die Sie im vorherigen Schritt festgelegt haben. Beispiel:
```
kubectl get ingress 2048-ingress
```
Sobald die Ressource bereit ist, rufen Sie den Domain-Namen des Load Balancers ab.
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
Um den Service in einem Webbrowser anzuzeigen, überprüfen Sie den Port und den Pfad, die in der `Ingress`-Rettungsdatei angegeben sind.
## Schritt 6: Bereinigen
Zur Bereinigung des Load Balancer verwenden Sie den folgenden Befehl:
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
Der automatische Modus von EKS löscht automatisch den zugehörigen Load Balancer in Ihrem AWS Konto.
## IngressClassParams Referenz
Die folgende Tabelle dient als Kurzübersicht über häufig verwendete Konfigurationsoptionen.
| Feld | Description | Beispielwert |
| --- | --- | --- |
| `scheme` | Legt fest, ob der ALB intern oder mit dem Internet verbunden ist | `internet-facing` |
| `namespaceSelector` | Schränkt ein, welche Namespaces dies verwenden können IngressClass | `environment: prod` |
| `group.name` | Gruppiert mehrere Ingresses, um einen einzigen ALB gemeinsam zu nutzen | `retail-apps` |
| `ipAddressType` | Legt den IP-Adresstyp für den ALB fest | `dualstack` |
| `subnets.ids` | Liste der Subnetze für die ALB-Bereitstellung IDs | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | Tag-Filter zur Auswahl von Subnetzen für ALB | `Environment: prod` |
| `certificateARNs` | ARNs der zu verwendenden SSL-Zertifikate | ` arn:aws: acm:region:account:certificate/id` |
| `tags` | Benutzerdefinierte Tags für AWS Ressourcen | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | Load-Balancer-spezifische Attribute | `idle_timeout.timeout_seconds: 60` |
## Überlegungen
+ Sie können Anmerkungen nicht für eine verwenden, IngressClass um Load Balancer mit dem automatischen EKS-Modus zu konfigurieren. IngressClass Die Konfiguration sollte durch erfolgen. IngressClassParams Sie können jedoch Anmerkungen zu einzelnen Ingress-Ressourcen verwenden, um das Verhalten des Load Balancers zu konfigurieren (z. B. `alb.ingress.kubernetes.io/security-group-prefix-lists` oder). `alb.ingress.kubernetes.io/conditions.*`
+ Im automatischen Modus von EKS können Sie keine [ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html)Einstellungen vornehmen.
+ Sie müssen die Cluster-IAM-Rolle aktualisieren, um die Tag-Weitergabe von Kubernetes an AWS Load Balancer-Ressourcen zu ermöglichen. Weitere Informationen finden Sie unter [Benutzerdefinierte AWS Tags für EKS Auto-Ressourcen](auto-learn-iam.md#tag-prop).
+ Informationen zum Zuordnen von Ressourcen zum automatischen Modus von EKS oder zum selbstverwalteten Load AWS Balancer Controller finden Sie unter. [Migrationsreferenz](migrate-auto.md#migration-reference)
+ Informationen zum Beheben von Problemen mit Load Balancern finden Sie unter [Fehlerbehebung mit EKS Auto Mode](auto-troubleshoot.md).
+ Weitere Überlegungen zur Verwendung der Load-Balancing-Funktion von EKS Auto Mode finden Sie unter [Lastausgleich](auto-networking.md#auto-lb-consider).
Die folgenden Tabellen bieten einen detaillierten Vergleich der Änderungen IngressClassParams, der Ingress-Anmerkungen und der TargetGroupBinding Konfigurationen für den EKS-Automatikmodus. Diese Tabellen zeigen die wichtigsten Unterschiede zwischen der Lastenausgleichsfunktion von EKS Auto Mode und dem Open-Source Load Balancer Controller auf, darunter Änderungen der API-Version, veraltete Features und aktualisierte Parameternamen.
### IngressClassParams
| Vorherige | Neu | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Änderung der API-Version |
| `spec.certificateArn` | `spec.certificateARNs` | Support für mehrere Zertifikate ARNs |
| `spec.subnets.tags` | `spec.subnets.matchTags` | Geändertes Schema für die Subnetz-Zuordnung |
| `spec.listeners.listenerAttributes` | Nicht unterstützt | Wird von EKS Auto Mode noch nicht unterstützt |
### Ingress-Annotationen
| Vorherige | Neu | Description |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | Nicht unterstützt | `spec.ingressClassName` in Eingangsobjekten verwenden |
| `alb.ingress.kubernetes.io/group.name` | Nicht unterstützt | Geben Sie IngressClass nur Gruppen an |
| `alb.ingress.kubernetes.io/waf-acl-id` | Nicht unterstützt | Stattdessen WAF v2 verwenden |
| `alb.ingress.kubernetes.io/web-acl-id` | Nicht unterstützt | Stattdessen WAF v2 verwenden |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | Nicht unterstützt | Shield-Integration deaktiviert |
| `alb.ingress.kubernetes.io/auth-type: oidc` | Nicht unterstützt | OIDC-Authentifizierungstyp wird derzeit nicht unterstützt |
### TargetGroupBinding
| Vorherige | Neu | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Änderung der API-Version |
| `spec.targetType` optional | `spec.targetType` erforderlich | Explizite Angabe des Zieltyps |
| `spec.networking.ingress.from` | Nicht unterstützt | NLB ohne Sicherheitsgruppen wird nicht mehr unterstützt |
Um die benutzerdefinierte TargetGroupBinding Funktion verwenden zu können, müssen Sie die Zielgruppe mit dem eks: eks-cluster-name -Tag und dem Clusternamen taggen, um dem Controller die erforderlichen IAM-Berechtigungen zu gewähren. Beachten Sie, dass der Controller die Zielgruppe löscht, wenn die TargetGroupBinding Ressource oder der Cluster gelöscht wird.
# Verwendung von Service-Annotationen zur Konfiguration von Network Load Balancers
Erfahren Sie, wie Sie Network Load Balancers (NLB) in Amazon EKS mithilfe von Kubernetes-Service-Annotationen konfigurieren. In diesem Thema werden die Anmerkungen erläutert, die vom automatischen Modus von EKS für die Anpassung des NLB-Verhaltens unterstützt werden, einschließlich Internetzugriff, Integritätsprüfungen, SSL/TLS Kündigung und IP-Targeting-Modi.
Wenn Sie einen Kubernetes-Dienst vom Typ `LoadBalancer` im EKS-Automodus erstellen, stellt EKS automatisch einen AWS Network Load Balancer bereit und konfiguriert ihn auf der Grundlage der von Ihnen angegebenen Anmerkungen. Dieser deklarative Ansatz ermöglicht es Ihnen, Load-Balancer-Konfigurationen direkt über Ihre Kubernetes-Manifeste zu verwalten und so die Infrastruktur als Code zu verwalten.
Der automatische Modus von EKS übernimmt standardmäßig die Bereitstellung von Network Load Balancer für alle Dienste dieses Typs LoadBalancer — es ist keine zusätzliche Controller-Installation oder -Konfiguration erforderlich. Die `loadBalancerClass: eks.amazonaws.com/nlb`-Spezifikation wird automatisch als Cluster-Standard festgelegt, wodurch der Bereitstellungsprozess optimiert und gleichzeitig die Kompatibilität mit vorhandenen Kubernetes-Workloads gewährleistet wird.
**Anmerkung**
EKS Auto Mode erfordert Subnetz-Tags zur Identifizierung öffentlicher und privater Subnetze.
Wenn Sie Ihren Cluster mit `eksctl` erstellt haben, verfügen Sie bereits über diese Tags.
Weitere Informationen erhalten Sie unter [Kennzeichnung von Subnetzen für EKS Auto Mode](tag-subnets-auto.md).
## Beispiel-Service
Weitere Informationen zur Kubernetes-`Service`-Ressource finden Sie in [der Kubernetes-Dokumentation](https://kubernetes.io/docs/concepts/services-networking/service/).
Überprüfen Sie die unten stehende `Service`-Beispiel-Ressource:
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## Häufig verwendete Annotationen
Die folgende Tabelle listet häufig verwendete Annotationen auf, die von EKS Auto Mode unterstützt werden. Beachten Sie, dass EKS Auto Mode möglicherweise nicht alle Annotationen unterstützt.
**Tipp**
Alle folgenden Annotationen müssen mit `service.beta.kubernetes.io/` vorangestellt werden
| Feld | Description | Beispiel |
| --- | --- | --- |
| `aws-load-balancer-type` | Gibt den Typ des Load Balancers an. Verwenden Sie `external` für neue Bereitstellungen. | `external` |
| `aws-load-balancer-nlb-target-type` | Gibt an, ob der Datenverkehr an Knoteninstanzen oder direkt an den Pod weitergeleitet werden soll. IPs Verwenden Sie `instance` für Standard-Bereitstellungen oder `ip` für die direkte Pod-Weiterleitung. | `instance` |
| `aws-load-balancer-scheme` | Steuert, ob der Load Balancer intern oder mit dem Internet verbunden ist. | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | Protokoll für die Zustandsprüfung der Zielgruppe. Gängige Optionen sind `TCP` (Standard) oder `HTTP`. | `HTTP` |
| `aws-load-balancer-healthcheck-path` | Der HTTP-Pfad für Integritätsprüfungen bei Verwendung HTTP/HTTPS des Protokolls. | `/healthz` |
| `aws-load-balancer-healthcheck-port` | Der für Zustandsprüfungen verwendete Port. Dies kann eine bestimmte Portnummer oder `traffic-port` sein. | `traffic-port` |
| `aws-load-balancer-subnets` | Gibt an, in welchen Subnetzen der Load Balancer erstellt werden soll. Kann Subnetz IDs oder Namen verwenden. | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | ARN des SSL-Zertifikats von AWS Certificate Manager für HTTPS/TLS. | ` arn:aws: acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | Legt fest, welche Ports SSL/TLS verwenden sollen. | `443, 8443` |
| `load-balancer-source-ranges` | Für den Zugriff auf den Load Balancer zulässige CIDR-Bereiche. | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | Zusätzliche AWS Tags, die auf den Load Balancer und verwandte Ressourcen angewendet werden sollen. | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | Gibt an, ob der Load Balancer Dual-Stack (IPv4 \$1) verwendet IPv4 . IPv6 | `ipv4` oder `dualstack` |
## Überlegungen
+ Sie müssen die Cluster-IAM-Rolle aktualisieren, um die Tag-Weitergabe von Kubernetes an AWS Load Balancer-Ressourcen zu ermöglichen. Weitere Informationen finden Sie unter [Benutzerdefinierte AWS Tags für EKS Auto-Ressourcen](auto-learn-iam.md#tag-prop).
+ Informationen zum Zuordnen von Ressourcen zum automatischen Modus von EKS oder zum selbstverwalteten Load AWS Balancer Controller finden Sie unter. [Migrationsreferenz](migrate-auto.md#migration-reference)
+ Informationen zum Beheben von Problemen mit Load Balancern finden Sie unter [Fehlerbehebung mit EKS Auto Mode](auto-troubleshoot.md).
+ Weitere Überlegungen zur Verwendung der Load-Balancing-Funktion von EKS Auto Mode finden Sie unter [Lastausgleich](auto-networking.md#auto-lb-consider).
Bei der Migration zu EKS Auto Mode für Load Balancing sind mehrere Änderungen an Service-Annotationen und Ressourcen-Konfigurationen erforderlich. Die folgenden Tabellen zeigen die wichtigsten Unterschiede zwischen der bisherigen und der neuen Implementierung, einschließlich nicht unterstützter Optionen und empfohlener Alternativen.
### Service-Annotationen
| Vorherige | Neu | Description |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | Nicht unterstützt | `spec.loadBalancerSourceRanges` für Service verwenden |
| `service.beta.kubernetes.io/aws-load-balancer-type` | Nicht unterstützt | `spec.loadBalancerClass` für Service verwenden |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | Nicht unterstützt | Verwenden von `service.beta.kubernetes.io/aws-load-balancer-scheme` |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | Nicht unterstützt | Stattdessen `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` verwenden |
| Verschiedene Attribute des Load Balancers | Nicht unterstützt | Verwenden von `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | Nicht unterstützt | Stattdessen `service.beta.kubernetes.io/aws-load-balancer-attributes` verwenden |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | Nicht unterstützt | Stattdessen `service.beta.kubernetes.io/aws-load-balancer-attributes` verwenden |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | Nicht unterstützt | Stattdessen `service.beta.kubernetes.io/aws-load-balancer-attributes` verwenden |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | Nicht unterstützt | Stattdessen `service.beta.kubernetes.io/aws-load-balancer-attributes` verwenden |
Um von veralteten Annotation zu Load-Balancer-Attributen zu migrieren, konsolidieren Sie diese Einstellungen in der `service.beta.kubernetes.io/aws-load-balancer-attributes`-Annotation. Diese Annotation akzeptiert eine durch Kommas getrennte Liste von Schlüssel-Wert-Paaren für verschiedene Load-Balancer-Attribute. Verwenden Sie beispielsweise das folgende Format, um die Zugriffsprotokollierung und den zonenübergreifenden Lastenausgleich zu spezifizieren:
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
Dieses konsolidierte Format bietet eine konsistentere und flexiblere Möglichkeit zur Konfiguration von Load Balancer-Attributen und reduziert gleichzeitig die Anzahl der erforderlichen einzelnen Annotationen. Überprüfen Sie Ihre vorhandenen Service-Konfigurationen und aktualisieren Sie sie, um dieses konsolidierte Format zu verwenden.
### TargetGroupBinding
| Vorherige | Neu | Description |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Änderung der API-Version |
| `spec.targetType` optional | `spec.targetType` erforderlich | Explizite Angabe des Zieltyps |
| `spec.networking.ingress.from` | Nicht unterstützt | NLB ohne Sicherheitsgruppen wird nicht mehr unterstützt |
Hinweis: Um die benutzerdefinierte TargetGroupBinding Funktion verwenden zu können, müssen Sie die Zielgruppe mit dem Tag mit `eks:eks-cluster-name` dem Clusternamen kennzeichnen, um dem Controller die erforderlichen IAM-Berechtigungen zu gewähren. Beachten Sie, dass der Controller die Zielgruppe löscht, wenn die TargetGroupBinding Ressource oder der Cluster gelöscht wird.
# Erstellen einer Speicherklasse
Eine `StorageClass` im Amazon EKS Auto Mode definiert, wie Amazon-EBS-Volumes automatisch bereitgestellt werden, wenn Anwendungen persistenten Speicher anfordern. Auf dieser Seite wird erläutert, wie Sie eine `StorageClass` erstellen und konfigurieren, das mit dem Amazon EKS Auto Mode zusammenarbeitet, um EBS-Volumes bereitzustellen.
Durch die Konfiguration einer `StorageClass` können Sie Standardeinstellungen für Ihre EBS-Volumes festlegen, darunter Volume-Typ, Verschlüsselung, IOPS und andere Speicherparameter. Sie können den auch so konfigurieren`StorageClass`, dass AWS KMS-Schlüssel für die Verschlüsselungsverwaltung verwendet werden.
EKS Auto Mode erstellt keine `StorageClass` für Sie. Sie müssen eine `StorageClass`-Referenzierung `ebs.csi.eks.amazonaws.com` erstellen, um die Speicherfunktion von EKS Auto Mode zu nutzen.
Erstellen Sie zunächst eine Datei mit dem Namen `storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
Wenden Sie anschließend die Speicherklasse auf Ihren Cluster an.
```
kubectl apply -f storage-class.yaml
```
**Zentrale Komponenten:**
+ `provisioner: ebs.csi.eks.amazonaws.com` – Verwendet EKS Auto Mode
+ `allowedTopologies` – Durch die Angabe von `matchLabelExpressions` für die Übereinstimmung mit `eks.amazonaws.com/compute-type:auto` wird sichergestellt, dass Ihre Pods, die ein Volume benötigen, das automatisch im Automatikmodus bereitgestellt wird, nicht auf Nicht-Automatik-Knoten geplant werden.
+ `volumeBindingMode: WaitForFirstConsumer` – Verzögert die Volume-Erstellung, bis ein Pod sie benötigt
+ `type: gp3` – Gibt den EBS-Volume-Typ an
+ `encrypted: "true"` – EBS verschlüsselt alle Volumes, die mit `StorageClass` erstellt wurden. EBS verwendet den `aws/ebs`-Standard-Schlüssel-Alias. Weitere Informationen finden Sie unter [So funktioniert die Amazon-EBS-Verschlüsselung](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html) im Amazon-EBS-Benutzerhandbuch. Dieser Wert ist optional, wird jedoch empfohlen.
+ `storageclass.kubernetes.io/is-default-class: "true"` – Kubernetes verwendet standardmäßig diese Speicherklasse, sofern Sie nicht für einen persistenten Volume-Anspruch eine andere Volume-Klasse angeben. Dieser Wert ist optional. Seien Sie beim Festlegen dieses Werts vorsichtig, wenn Sie von einem anderen Speicher-Controller migrieren.
## Selbstverwalteter KMS-Schlüssel zur Verschlüsselung von EBS-Volumes verwenden
Um einen selbstverwalteten KMS-Schlüssel zur Verschlüsselung von EBS-Volumes zu verwenden, die durch EKS Auto Mode automatisiert werden, müssen Sie folgende Schritte ausführen:
1. Erstellen Sie einen selbstverwalteten KMS-Schlüssel.
+ Weitere Informationen finden Sie unter [Erstellen eines symmetrischen KMS-Verschlüsselungsschlüssels](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html) oder [So verwendet Amazon Elastic Block Store (Amazon EBS) KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html) im KMS-Benutzerhandbuch.
1. Erstellen Sie eine neue Richtlinie, die den Zugriff auf den KMS-Schlüssel zulässt.
+ Verwenden Sie die unten aufgeführte Beispiel-IAM-Richtlinie, um die Richtlinie zu erstellen. Geben Sie die ARN des neuen selbstverwalteten KMS-Schlüssels ein. Weitere Informationen finden Sie im AWS IAM-Benutzerhandbuch unter [Rollen erstellen und Richtlinien anhängen (Konsole)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html).
1. Fügen Sie die Richtlinie der EKS- Cluster-Rolle an.
+ Verwenden Sie die AWS Konsole, um den ARN der EKS-Clusterrolle zu finden. Die Rollen-Informationen sind im Abschnitt **Übersicht** einsehbar. Weitere Informationen finden Sie unter [Amazon-EKS-Cluster-IAM-Rolle](cluster-iam-role.md).
1. Aktualisieren Sie `StorageClass`, um auf die KMS-Schlüssel-ID im `parameters.kmsKeyId`-Feld zu verweisen.
### Beispiel für eine selbstverwaltete KMS-IAM-Richtlinie
Aktualisieren Sie die folgenden Werte in der unten aufgeführten Richtlinie:
+ ``— Ihre AWS Konto-ID, z. B. `111122223333`
+ ``— Die AWS Region Ihres Clusters, wie `us-west-2`
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### Beispiel für ein selbstverwaltetes KMS `StorageClass`
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## `StorageClass`-Parameter-Referenz
Allgemeine Informationen zu den `StorageClass`-Kubernetes-Ressourcen finden Sie unter [Speicherklassen](https://kubernetes.io/docs/concepts/storage/storage-classes/) in der Kubernetes-Dokumentation
THe `parameters`Der Abschnitt der `StorageClass` Ressource ist spezifisch für AWS. Verwenden Sie die folgende Tabelle, um die verfügbaren Optionen zu überprüfen.
| Parameters | Werte | Standard | Description |
| --- | --- | --- | --- |
| „csi.storage.k8s.io/fstype“ | xfs, ext2, ext3, ext4 | ext4 | Dateisystemtyp, der während der Volume-Erstellung formatiert wird. Bei diesem Parameter wird zwischen Groß- und Kleinschreibung unterschieden\$1 |
| „type“ | io1, io2, gp2, gp3, sc1, st1, standard, sbp1, sbg1 | gp3 | EBS-Volume-Typ. |
| „iopsPerGB“ | | | E/A-Vorgänge pro Sekunde pro GiB. Kann für IO1 IO2, und GP3 Volumen angegeben werden. |
| „Automatisch zulassen IOPSPerGBIncrease“ | true, false | false | Wenn `"true"` der CSI-Treiber die IOPS für ein Volume erhöht, wenn `iopsPerGB * ` es zu niedrig ist, um in den von unterstützten IOPS-Bereich zu passen. AWS Dadurch ist die dynamische Bereitstellung immer erfolgreich, selbst wenn der Benutzer eine zu geringe PVC-Kapazität oder einen zu geringen `iopsPerGB`-Wert angibt. Andererseits können zusätzliche Kosten entstehen, da solche Volumes höhere IOPS aufweisen als in `iopsPerGB` angefordert. |
| „iops“ | | | E/A-Vorgänge pro Sekunde. Kann für IO1, IO2 und GP3 Volumes angegeben werden. |
| „throughput“ | | 125 | Durchsatz in MiB/s. Nur wirksam, wenn der Datenträgertyp gp3 angegeben ist. |
| „verschlüsselt“ | true, false | false | Ob das Volume verschlüsselt werden soll oder nicht. Gültige Werte sind „wahr“ oder „falsch“. |
| „blockExpress“ | true, false | false | Ermöglicht die Erstellung von io2-Block-Express-Volumes. |
| "kmsKeyId" | | | Die vollständige ARN des Schlüssels, der bei der Verschlüsselung des Volumes verwendet werden soll. Wenn nicht angegeben, AWS wird der Standard-KMS-Schlüssel für die Region verwendet, in der sich das Volume befindet. Wenn dieser nicht geändert wird, handelt es sich um einen automatisch generierten Schlüssel mit dem Namen `/aws/ebs`. |
| „blockSize“ | | | Die Blockgröße, die beim Formatieren des zugrunde liegenden Dateisystems verwendet werden soll. Wird nur auf Linux-Knoten und mit fstype `ext2`, `ext3`, `ext4` oder `xfs` unterstützt. |
| „inodeSize“ | | | Die Inode-Größe, die beim Formatieren des zugrunde liegenden Dateisystems verwendet werden soll. Wird nur auf Linux-Knoten und mit fstype `ext2`, `ext3`, `ext4` oder `xfs` unterstützt. |
| "bytesPerInode" | | | Die `bytes-per-inode`, die beim Formatieren des zugrunde liegenden Dateisystems verwendet werden sollen. Wird nur auf Linux-Knoten und mit fstype `ext2`, `ext3`, `ext4` unterstützt. |
| "numberOfInodes" | | | Die `number-of-inodes`, die beim Formatieren des zugrunde liegenden Dateisystems verwendet werden sollen. Wird nur auf Linux-Knoten und mit fstype `ext2`, `ext3`, `ext4` unterstützt. |
| „ext4BigAlloc“ | true, false | false | Ändert das `ext4`-Dateisystem, um die gruppierte Block-Zuweisung zu verwenden, indem die `bigalloc`-Formatierungsoption aktiviert wird. Warnung: `bigalloc` wird möglicherweise nicht vollständig vom Linux-Kernel Ihres Knotens unterstützt. |
| „ClusterSizeext4“ | | | Die Cluster-Größe, die beim Formatieren eines `ext4`-Dateisystems verwendet werden soll, wenn das `bigalloc`-Feature aktiviert ist. Hinweis: Der Parameter `ext4BigAlloc` muss auf „wahr“ gesetzt sein. |
Weitere Informationen finden Sie unter dem [AWS EBS-CSI-Treiber unter](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md). GitHub
## Überlegungen
**Anmerkung**
Sie können Workloads, die vom EKS-Automatikmodus abhängen, nur auf StorageClasses EKS-Automodus-Knoten bereitstellen. Wenn Sie über einen Cluster mit kombinierten Knotentypen verfügen, müssen Sie Ihre Workloads so konfigurieren, dass sie ausschließlich in EKS-Auto-Mode-Knoten ausgeführt werden. Weitere Informationen finden Sie unter [Überprüfen, ob eine Workload in Knoten von EKS Auto Mode bereitgestellt wird](associate-workload.md).
Die Blockspeicherfunktion des EKS Auto Mode unterscheidet sich vom EBS-CSI-Treiber.
+ Statische Bereitstellung
+ Wenn Sie extern erstellte EBS-Volumes mit dem automatischen EKS-Modus verwenden möchten, müssen Sie manuell ein AWS Tag mit dem Schlüssel `eks:eks-cluster-name` und dem Wert des Clusternamens hinzufügen.
+ Knoten-Startup-Taint
+ Es ist nicht möglich, das Node-Startup-Taint-Feature zu verwenden, um die Pod-Planung zu verhindern, bevor die Speicherkapazität bereit ist.
+ Benutzerdefinierte Tags auf dynamisch bereitgestellten Volumes
+ Sie können das CLI-Flag „extra-tag“ nicht verwenden, um benutzerdefinierte Tags für dynamisch bereitgestellte EBS-Volumes zu konfigurieren.
+ Sie können `StorageClass`-Kennzeichnung verwenden, um benutzerdefinierte Tags hinzuzufügen. Der automatische EKS-Modus fügt den zugehörigen Ressourcen Tags hinzu. AWS Sie müssen die Cluster-IAM-Rolle für benutzerdefinierte Tags aktualisieren. Weitere Informationen finden Sie unter [Benutzerdefinierte AWS Tags für EKS Auto-Ressourcen](auto-learn-iam.md#tag-prop).
+ Detaillierte EBS-Leistungsmetriken
+ Sie können nicht auf Prometheus-Metriken für die detaillierte EBS-Leistung zugreifen
## Add-On „CSI-Snapshot Controller“ installieren
EKS Auto Mode ist mit dem Amazon-EKS-Add-On „CSI Snapshot Controller“ kompatibel.
AWS schlägt vor, dass Sie dieses Add-on so konfigurieren, dass es auf dem integrierten `system` Knotenpool ausgeführt wird.
Weitere Informationen finden Sie unter:
+ [Kritische Add-Ons in dedizierten Instances ausführen](critical-workload.md)
+ [Integriert aktivieren oder deaktivieren NodePools](set-builtin-node-pools.md)
+ [Snapshot-Funktion für CSI-Volumes aktivieren](csi-snapshot-controller.md)
### So installieren Sie den Snapshot-Controller im System-Knoten-Pool
1. Öffnen Sie Ihren EKS-Cluster in der AWS Konsole
1. Wählen Sie auf der Registerkarte **Add-Ons** die Option **Weitere Add-Ons abrufen**
1. Wählen Sie den **CSI Snapshot Controller** und dann **Weiter**
1. Wählen Sie auf der Seite **Einstellungen für ausgewählte Add-Ons konfigurieren** die Option **Optionale Konfigurationseinstellungen** aus, um das **Add-On-Konfigurationsschema** anzuzeigen.
1. Fügen Sie das folgende YAML ein, um den Snapshot-Controller dem `system`-Knoten-Pool zuzuordnen. Der Snapshot-Controller enthält eine Toleranz für den `CriticalAddonsOnly`-Taint.
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. Klicken Sie auf **Weiter**
1. Überprüfen Sie die Add-On-Konfiguration und wählen Sie dann **Erstellen** aus
# EKS Auto Mode deaktivieren
Sie können EKS Auto Mode in einem vorhandenen EKS-Cluster deaktivieren. Hierbei handelt es sich um einen destruktiven Vorgang.
+ EKS beendet alle vom EKS Auto Mode betriebenen EC2 Instanzen.
+ EKS wird alle von EKS Auto Mode betriebenen Load Balancer löschen.
+ EKS löscht **keine** EBS-Volumes, die von EKS Auto Mode bereitgestellt werden.
EKS Auto Mode wurde entwickelt, um die von ihm erstellten Ressourcen vollständig zu verwalten. Manuelle Eingriffe können dazu führen, dass EKS Auto Mode diese Ressourcen bei seiner Deaktivierung nicht vollständig bereinigt. Wenn Sie beispielsweise auf eine verwaltete Sicherheitsgruppe aus externen Sicherheitsgruppenregeln verwiesen haben und vergessen, diesen Verweis zu entfernen, bevor Sie EKS Auto Mode für einen Cluster deaktivieren, wird die verwaltete Sicherheitsgruppe verloren gehen (nicht gelöscht). Die folgenden Schritte beschreiben, wie Sie eine verloren gegangene Sicherheitsgruppe entfernen, falls dies passieren sollte.
## Deaktivieren Sie den EKS-Automatikmodus (AWS Konsole)
1. Öffnen Sie Ihre Cluster-Übersichtsseite in der AWS-Managementkonsole.
1. Wählen Sie unter **EKS Auto Mode** die Option **Verwalten** aus.
1. Schalten Sie **EKS Auto Mode** auf `off` um.
Wenn eine verwaltete Sicherheitsgruppe am Ende dieses Vorgangs nicht gelöscht wird, können Sie sie mithilfe der Beschreibungen unter [Sicherheitsgruppe löschen](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html) manuell löschen.
## Deaktivieren Sie den EKS-Automatikmodus (AWS CLI)
Verwenden Sie den folgenden Befehl, um EKS Auto Mode in einem vorhandenen Cluster zu deaktivieren.
Sie müssen die `aws`-CLI installiert haben und mit ausreichenden Berechtigungen angemeldet sein, um EKS-Cluster zu verwalten. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
**Anmerkung**
Die Funktionen für Rechenleistung, Blockspeicher und Lastenausgleich müssen alle in derselben Anfrage aktiviert oder deaktiviert werden.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
Sie können wie folgt überprüfen, ob eine verloren gegangene Sicherheitsgruppe in EKS Auto Mode nach der Deaktivierung von EKS Auto Mode gelöscht werden konnte:
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
So löschen Sie die Sicherheitsgruppe:
```
aws ec2 delete-security-group --group-name=
```
# Aktualisierung der Kubernetes-Version eines Clusters in EKS Auto Mode
In diesem Thema wird erläutert, wie Sie die Kubernetes-Version Ihres Clusters im Automatikmodus aktualisieren können. Der Automatikmodus vereinfacht den Prozess der Versionsaktualisierung, indem er die Koordination der Aktualisierungen der Steuerebene mit dem Austausch von Knoten übernimmt. Gleichzeitig wird die Verfügbarkeit der Workload durch Budgets für Pod-Unterbrechung gewährleistet.
Bei der Aktualisierung eines Clusters im Automatikmodus werden viele Komponenten, die bisher manuell aktualisiert werden mussten, nun als Teil des Services verwaltet. Wenn Sie mit den automatisierten Aspekten des Aktualisierungsprozesses und Ihren Aufgaben vertraut sind, können Sie einen nahtlosen Versionswechsel für Ihren Cluster sicherstellen.
## Weitere Informationen zu Aktualisierungen mit EKS Auto Mode
Nachdem Sie ein Upgrade der Steuerebene initiiert haben, aktualisiert EKS Auto Mode die Knoten in Ihrem Cluster. Wenn Knoten ablaufen, ersetzt EKS Auto Mode diese durch neue Knoten. Die neuen Knoten verfügen über die entsprechende neue Kubernetes-Version. EKS Auto Mode berücksichtigt beim Upgrade von Knoten die Budgets für Pod-Unterbrechung.
Darüber hinaus müssen Sie folgende Komponenten nicht mehr aktualisieren:
+ Amazon VPC CNI
+ AWS-Lastenverteilungs-Controller
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ AWS-EBS-CSI-Treiber
EKS Auto Mode ersetzt diese Komponenten durch Servicefunktionen.
Sie sind weiterhin für die Aktualisierung verantwortlich:
+ Apps und Workloads, die in Ihrem Cluster bereitgestellt werden
+ Selbstverwaltete Add-Ons und Controller
+ Amazon-EKS-Add-Ons
+ Erfahren Sie, wie Sie [Aktualisierung eines Amazon-EKS-Add-Ons](updating-an-add-on.md)
Erfahren Sie mehr über [Bewährte Methoden für Cluster-Upgrades](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)
## Cluster-Aktualisierung starten
Informationen zum Starten einer Cluster-Aktualisierung finden Sie unter [Aktualisierung des vorhandenen Clusters auf die neue Kubernetes-Version](update-cluster.md).
# Integriert aktivieren oder deaktivieren NodePools
Der EKS-Automatikmodus verfügt über zwei integrierte Funktionen NodePools. Sie können diese NodePools über die AWS Konsole, CLI oder API aktivieren oder deaktivieren.
## Integrierte NodePool Referenz
+ `system`
+ Das NodePool hat einen `CriticalAddonsOnly` Makel. Viele EKS-Add-Ons, wie beispielsweise CoreDNS, tolerieren diesen Taint. Verwenden Sie diesen System-KnotenPool, um Cluster-kritische Anwendungen zu trennen.
+ Unterstützt sowohl `amd64`- als auch `arm64`-Architekturen.
+ `general-purpose`
+ Dies NodePool bietet Unterstützung für das Starten von Knoten für allgemeine Workloads in Ihrem Cluster.
+ Verwendet nur `amd64`-Architektur.
Beide sind integriert NodePools:
+ Verwenden Sie das Standard-EKS NodeClass
+ Verwenden Sie nur EC2 On-Demand-Kapazität
+ Verwenden Sie die EC2 Instanzfamilien C, M und R
+ EC2 Instances der Generation 5 oder neuer erforderlich
**Anmerkung**
Die Aktivierung von mindestens einer integrierten NodePool Komponente ist erforderlich, damit EKS den „Standard“ bereitstellen kann NodeClass. Wenn Sie alle integrierten Funktionen deaktivieren NodePools, müssen Sie eine benutzerdefinierte Version erstellen NodeClass und eine konfigurieren NodePool , um sie zu verwenden. Weitere Informationen zu finden NodeClasses Sie unter[Knotenklasse für Amazon EKS erstellen](create-node-class.md).
## Verfahren
### Voraussetzungen
+ Die neueste Version der AWS Befehlszeilenschnittstelle (AWS CLI) ist auf Ihrem Gerät installiert und konfiguriert. Um Ihre aktuelle Version zu überprüfen, verwenden Sie `aws --version`. Informationen zur Installation der neuesten Version finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) und [Schnellkonfiguration](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config) mit aws configure im Benutzerhandbuch für die AWS Befehlszeilenschnittstelle.
+ Melden Sie sich mit ausreichenden IAM-Berechtigungen bei der CLI an, um AWS Ressourcen wie IAM-Richtlinien, IAM-Rollen und EKS-Cluster zu erstellen.
### Mit AWS CLI aktivieren
Verwenden Sie den folgenden Befehl, um beide integrierten Funktionen zu aktivieren NodePools:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
Sie können den Befehl ändern, um den selektiv zu aktivieren. NodePools
### Mit AWS CLI deaktivieren
Verwenden Sie den folgenden Befehl, um beide integrierten Funktionen zu deaktivieren NodePools:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# Überprüfen, ob eine Workload in Knoten von EKS Auto Mode bereitgestellt wird
Bei der Ausführung von Workloads in einem EKS-Cluster mit EKS Auto Mode kann es erforderlich sein, zu steuern, ob bestimmte Workloads in Knoten von EKS Auto Mode oder anderen Rechentypen ausgeführt werden. In diesem Thema wird beschrieben, wie Sie mithilfe von Knoten-Selektoren und Affinitätsregeln sicherstellen können, dass Ihre Workloads in der vorgesehenen Recheninfrastruktur geplant werden.
Die Beispiele in diesem Thema veranschaulichen, wie Sie mithilfe des `eks.amazonaws.com/compute-type`-Labels die Bereitstellung von Workloads auf Knoten in EKS Auto Mode entweder erfordern oder verhindern können. Dies ist besonders nützlich für Cluster im gemischten Modus, in denen sowohl EKS Auto Mode als auch andere Rechentypen ausgeführt werden, beispielsweise selbstverwaltete Karpenter-Bereitsteller oder EKS-verwaltete Knotengruppen.
Knoten von EKS Auto Mode haben den Wert des Labels von `eks.amazonaws.com/compute-type` auf `auto` festgelegt. Mit diesem Label können Sie steuern, ob eine Workload in Knoten bereitgestellt wird, die von EKS Auto Mode verwaltet werden.
## Voraussetzung: Eine Workload muss in Knoten von EKS Auto Mode bereitgestellt sein
**Anmerkung**
Dieser `nodeSelector`-Wert ist für EKS Auto Mode nicht erforderlich. Dieser `nodeSelector`-Wert ist nur relevant, wenn Sie einen Cluster im gemischten Modus ausführen, dessen Knotentypen nicht von EKS Auto Mode verwaltet werden. Beispielsweise können Sie in Ihrem Cluster über EKS-verwaltete Knotengruppen statische Rechenkapazität bereitstellen und über dynamische Rechenkapazität verfügen, die von EKS Auto Mode verwaltet wird.
Sie können diesen `nodeSelector` zu Bereitstellungen oder anderen Workloads hinzufügen, um zu verlangen, dass Kubernetes sie in Knoten von EKS Auto Mode plant.
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## Voraussetzung: Ein Workload wird nicht in Knoten von EKS Auto Mode bereitgestellt
Sie können diesen `nodeAffinity` zu Bereitstellungen oder anderen Workloads hinzufügen, um zu verlangen, dass Kubernetes sie **nicht** in Knoten von EKS Auto Mode plant.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# Kritische Add-Ons in dedizierten Instances ausführen
In diesem Thema erfahren Sie, wie Sie eine Workload mit einer `CriticalAddonsOnly`-Toleranz bereitstellen, sodass der EKS Auto Mode sie im `system`-Knoten-Pool plant.
Der integrierte `system`-Knoten-Pool des EKS Auto Mode ist für die Ausführung wichtiger Add-Ons in dedizierten Instances konzipiert. Diese Segmentierung stellt sicher, dass wichtige Komponenten über dedizierte Ressourcen verfügen und von allgemeinen Workloads isoliert sind, was die allgemeine Cluster-Stabilität und -Leistung verbessert.
Dieser Leitfaden zeigt, wie Add-Ons mithilfe von `CriticalAddonsOnly`-Toleranz und geeigneten Knotenselektoren im `system`-Knoten-Pool bereitgestellt werden können. Mit diesen Schritten können Sie sicherstellen, dass Ihre kritischen Anwendungen auf den dedizierten `system`-Knoten geplant werden, wobei Sie die Vorteile der Isolierung und Ressourcenzuweisung nutzen, welche die spezielle Knoten-Poolstruktur des EKS Auto Mode bietet.
EKS Auto Mode verfügt über zwei integrierte Knoten-Pools: `general-purpose` und `system`. Weitere Informationen finden Sie unter [Integriert aktivieren oder deaktivieren NodePools](set-builtin-node-pools.md).
Der Zweck des `system`-Knoten-Pools besteht darin, kritische Add-Ons auf verschiedene Knoten zu verteilen. Von dem `system`-Knoten-Pool bereitgestellte Knoten verfügen über einen `CriticalAddonsOnly`-Kubernetes-Taint. Kubernetes plant Pods nur dann auf diesen Knoten ein, wenn sie über eine entsprechende Toleranz verfügen. Weitere Informationen finden Sie unter [Taints und Toleranzen](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) in der Kubernetes-Dokumentation.
## Voraussetzungen
+ Cluster von EKS Auto Mode mit aktiviertem integrierten `system`-Knoten-Pool. Weitere Informationen finden Sie unter [Integriert aktivieren oder deaktivieren NodePools](set-builtin-node-pools.md).
+ `kubectl` installiert und konfiguriert. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
## Verfahren
Sehen Sie sich das YAML-Beispiel unten an. Beachten Sie die folgenden Konfigurationen:
+ `nodeSelector` – Dies ordnet die Workload dem integrierten `system`-Knoten-Pool zu. Dieser Knoten-Pool muss über die AWS-API aktiviert werden. Weitere Informationen finden Sie unter [Integriert aktivieren oder deaktivieren NodePools](set-builtin-node-pools.md).
+ `tolerations` – Diese Toleranz überwindet den `CriticalAddonsOnly`-Taint von Knoten im `system`-Knoten-Pool.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
Zur Aktualisierung einer Workload für die Ausführung im `system`-Knoten-Pool sind folgende Schritte erforderlich:
1. Aktualisieren Sie die vorhandene Workload, um die folgenden oben beschriebenen Konfigurationen hinzuzufügen:
+ `nodeSelector`
+ `tolerations`
1. Die aktualisierte Workload mit `kubectl apply` in Ihrem Cluster bereitstellen
Nach der Aktualisierung der Workload wird diese in dedizierten Knoten ausgeführt.
# Verwendung von Netzwerkrichtlinien mit EKS Auto Mode
## -Übersicht
Da Kunden ihre Anwendungsumgebungen mithilfe von EKS skalieren, wird die Isolierung des Netzwerkverkehrs immer wichtiger, um unbefugten Zugriff auf Ressourcen innerhalb und außerhalb des Clusters zu verhindern. Dies ist besonders wichtig in einer Umgebung mit mehreren Mandanten, in der mehrere voneinander unabhängige Workloads nebeneinander im Cluster ausgeführt werden. Mit Kubernetes-Netzwerkrichtlinien können Sie die Netzwerksicherheit für Ihre Kubernetes-Workloads und deren Integrationen mit clusterexternen Endpunkten verbessern. Der automatische Modus von EKS unterstützt verschiedene Arten von Netzwerkrichtlinien.
### Isolierung der Schichten 3 und 4
Standard-Kubernetes-Netzwerkrichtlinien arbeiten auf den Ebenen 3 und 4 des OSI-Netzwerkmodells und ermöglichen es Ihnen, den Verkehrsfluss auf IP-Adresse- oder Portebene innerhalb Ihres Amazon EKS-Clusters zu steuern.
#### Anwendungsfälle
+ Segmentieren Sie den Netzwerkverkehr zwischen Workloads, um sicherzustellen, dass nur verwandte Anwendungen miteinander kommunizieren können.
+ Isolieren Sie Mandanten auf Namespace-Ebene mithilfe von Richtlinien, um die Netzwerktrennung durchzusetzen.
### DNS-basierte Durchsetzung
Kunden stellen in der Regel Workloads in EKS bereit, die Teil einer breiteren verteilten Umgebung sind, von denen einige mit Systemen und Diensten außerhalb des Clusters kommunizieren müssen (Northbound-Verkehr). Diese Systeme und Dienste können sich in der AWS Cloud oder ganz außerhalb befinden AWS . Mit DNS-basierten Richtlinien (Domain Name System) können Sie Ihre Sicherheitslage verbessern, indem Sie einen stabileren und vorhersehbareren Ansatz verfolgen, um unbefugten Zugriff von Pods auf clusterexterne Ressourcen oder Endpunkte zu verhindern. Durch diesen Mechanismus ist es nicht mehr erforderlich, bestimmte IP-Adressen manuell zu verfolgen und aufzulisten. Durch die Sicherung von Ressourcen mit einem DNS-basierten Ansatz haben Sie auch mehr Flexibilität bei der Aktualisierung der externen Infrastruktur, ohne dass Sie Ihre Sicherheitslage lockern oder die Netzwerkrichtlinien ändern müssen, wenn sich Änderungen an vorgelagerten Servern und Hosts ergeben. Sie können ausgehenden Datenverkehr zu externen Endpunkten entweder mithilfe eines vollqualifizierten Domänennamens (FQDN) oder eines passenden Musters für einen DNS-Domainnamen filtern. Dies bietet Ihnen die zusätzliche Flexibilität, den Zugriff auf mehrere Subdomänen zu erweitern, die einem bestimmten externen Cluster-Endpunkt zugeordnet sind.
#### Anwendungsfälle
+ Verwenden Sie standardmäßig einen DNS-basierten Ansatz zur Filterung des Zugriffs von einer Kubernetes-Umgebung auf clusterexterne Endpunkte.
+ Sicherer Zugriff auf Dienste in einer Umgebung mit mehreren Mandanten. AWS
+ Verwalten Sie den Netzwerkzugriff von Pods bis hin zu lokalen Workloads in Ihren Hybrid-Cloud-Umgebungen.
### Administratorregeln (oder Clusterregeln)
In einigen Fällen, z. B. bei Mehrmandanten-Szenarien, müssen Kunden möglicherweise einen Netzwerksicherheitsstandard durchsetzen, der für den gesamten Cluster gilt. Anstatt wiederholt eine eigene Richtlinie für jeden Namespace zu definieren und zu verwalten, können Sie eine einzige Richtlinie verwenden, um die Netzwerkzugriffskontrollen für verschiedene Workloads im Cluster unabhängig von ihrem Namespace zentral zu verwalten. Mit diesen Richtlinientypen können Sie den Umfang der Durchsetzung Ihrer Netzwerkfilterregeln, die auf Ebene 3, Schicht 4 und bei der Verwendung von DNS-Regeln angewendet werden, erweitern.
#### Anwendungsfälle
+ Verwalten Sie die Netzwerkzugriffskontrollen für alle (oder eine Teilmenge von) Workloads in Ihrem EKS-Cluster zentral.
+ Definieren Sie einen standardmäßigen Netzwerksicherheitsstatus für den gesamten Cluster.
+ Erweitern Sie die organisatorischen Sicherheitsstandards auf betrieblich effizientere Weise auf den gesamten Clusterbereich.
## Erste Schritte
### Voraussetzungen
+ Ein Amazon-EKS-Cluster mit aktiviertem EKS Auto Mode
+ Kubectl für die Verbindung mit Ihrem Cluster konfiguriert
### Schritt 1: Netzwerkrichtlinien-Controller aktivieren
Um Netzwerkrichtlinien mit dem automatischen EKS-Modus verwenden zu können, müssen Sie zunächst den Network Policy Controller aktivieren, indem Sie a ConfigMap auf Ihren Cluster anwenden.
1. Erstellen Sie eine Datei mit dem Namen `enable-network-policy.yaml` und dem folgenden Inhalt:
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Wenden Sie das ConfigMap auf Ihren Cluster an:
```
kubectl apply -f enable-network-policy.yaml
```
### Schritt 2: Netzwerkrichtlinien erstellen und testen
Ihr EKS-Auto-Mode-Cluster ist nun für den Support von Kubernetes-Netzwerkrichtlinien konfiguriert. Sie können dies mit [Stars-Demo der Netzwerkrichtlinie für Amazon EKS](network-policy-stars-demo.md) testen.
### Schritt 3: Passen Sie die Konfiguration des Network Policy Agents in der Knotenklasse an (optional)
Sie können optional eine neue Knotenklasse erstellen, um das Standardverhalten des Network Policy Agent auf den Knoten zu ändern oder die Protokollierung von Netzwerkrichtlinienereignissen zu aktivieren. Führen Sie dazu die folgenden Schritte aus:
1. Erstellen oder bearbeiten Sie eine Knotenklassen-YAML-Datei (z. B. `nodeclass-network-policy.yaml`) mit dem folgenden Inhalt:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. Wenden Sie die Knotenklassen-Konfiguration auf Ihren Cluster an:
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. Überprüfen Sie, ob die Knotenklasse erstellt wurde:
```
kubectl get nodeclass network-policy-config
```
1. Aktualisieren Sie Ihren Knoten-Pool, um diese Knotenklasse zu verwenden. Weitere Informationen finden Sie unter [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md).
## Funktionsweise
### DNS-basierte Netzwerkrichtlinie
![\[Veranschaulichung des Workflows, wenn eine DNS-basierte Richtlinie in EKS Auto angewendet wird\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[Abbildung des Workflows, wenn eine DNS-basierte Richtlinie in EKS Auto angewendet wird\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/apply-dns-policy-2.png)
1. Das Plattformteam wendet eine DNS-basierte Richtlinie auf den EKS-Cluster an.
1. Der Network Policy Controller ist dafür verantwortlich, die Erstellung von Richtlinien innerhalb des Clusters zu überwachen und anschließend die Richtlinienendpunkte abzustimmen. In diesem Anwendungsfall weist der Netzwerkrichtlinien-Controller den Node-Agent an, DNS-Anfragen auf der Grundlage der Domänen zu filtern, die in der erstellten Richtlinie zugelassen sind. Domänennamen werden mithilfe des FQDN oder eines Domainnamens, der einem in der Kubernetes-Ressourcenkonfiguration definierten Muster entspricht, auf die Zulassungsliste gesetzt.
1. Workload A versucht, die IP für einen clusterexternen Endpunkt aufzulösen. Die DNS-Anfrage durchläuft zunächst einen Proxy, der solche Anfragen anhand der Zulassungsliste filtert, die in der Netzwerkrichtlinie angewendet wurde.
1. Sobald die DNS-Anfrage die Zulassungsliste des DNS-Filters durchlaufen hat, wird sie an CoreDNS weitergeleitet.
1. CoreDNS wiederum sendet die Anfrage an den externen DNS-Resolver (Amazon Route 53 Resolver), um die Liste der IP-Adressen hinter dem Domainnamen abzurufen.
1. Die IPs mit TTL aufgelösten Daten werden in der Antwort auf die DNS-Anfrage zurückgegeben. Diese IPs werden dann in eine eBPF-Map geschrieben, die im nächsten Schritt für die Durchsetzung der IP-Schicht verwendet wird.
1. Die an die Pod-Veth-Schnittstelle angeschlossenen eBPF-Sonden filtern dann den ausgehenden Datenverkehr von Workload A zum clusterexternen Endpunkt auf der Grundlage der geltenden Regeln. Dadurch wird sichergestellt, dass Pods nur clusterexternen Datenverkehr an die aufgelisteten Domänen senden können. IPs Ihre Gültigkeit IPs basiert auf der TTL, die vom externen DNS-Resolver (Amazon Route 53 Resolver) abgerufen wurde.
#### Verwendung der Anwendungsnetzwerkrichtlinie
Die `ApplicationNetworkPolicy` kombiniert die Funktionen von Standard-Kubernetes-Netzwerkrichtlinien mit DNS-basierter Filterung auf Namespace-Ebene unter Verwendung einer einzigen Custom Resource Definition (CRD). Daher `ApplicationNetworkPolicy` kann der verwendet werden für:
1. Definition von Einschränkungen auf den Ebenen 3 und 4 des Netzwerkstapels mithilfe von IP-Blöcken und Portnummern.
1. Definition von Regeln, die auf Schicht 7 des Netzwerkstapels angewendet werden, und ermöglichen es Ihnen, den Datenverkehr anhand dieser Kriterien zu filtern FQDNs.
**Wichtig**
DNS-basierte Regeln, die mithilfe von definiert wurden, `ApplicationNetworkPolicy` gelten nur für Workloads, die in EC2-Instances ausgeführt werden, die im EKS Auto Mode gestartet wurden. `ApplicationNetworkPolicy`unterstützt alle Felder des Standard-Kubernetes mit einem zusätzlichen `NetworkPolicy` FQDN-Filter für Ausgangsregeln.
**Warnung**
Verwenden Sie nicht denselben Namen für ein `ApplicationNetworkPolicy` und a `NetworkPolicy` innerhalb desselben Namespace. Wenn die Namen kollidieren, spiegeln die resultierenden `PolicyEndpoints` Objekte möglicherweise keine der beiden Richtlinien korrekt wider. Beide Ressourcen werden ohne Fehler akzeptiert, sodass dieses Problem nur schwer zu diagnostizieren ist.
Um einen Namenskonflikt zu lösen, benennen Sie entweder die `ApplicationNetworkPolicy` oder die um, `NetworkPolicy` sodass sie innerhalb des Namespaces eindeutig sind, und überprüfen Sie dann, ob die entsprechenden `PolicyEndpoints` Objekte korrekt aktualisiert wurden.
#### Beispiel
Sie haben einen Workload in Ihrem EKS-Auto-Mode-Cluster, der mit einer lokalen Anwendung kommunizieren muss, die sich hinter einem Load Balancer mit einem DNS-Namen befindet. Sie könnten dies mithilfe der folgenden Netzwerkrichtlinie erreichen:
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
Auf Kubernetes-Netzwerkebene würde dies den Ausgang von allen Pods im „Galaxy“ -Namespace ermöglichen, die mit gekennzeichnet sind, `role: backend` um eine Verbindung zum Domainnamen **myapp.mydomain.com** am TCP-Port 8080 herzustellen. Darüber hinaus müssten Sie die Netzwerkkonnektivität für den ausgehenden Datenverkehr von Ihrer VPC zu Ihrem Unternehmensrechenzentrum einrichten.
![\[Abbildung der Arbeitslast in EKS Automatische Kommunikation mit Anwendungen vor Ort\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### Netzwerkrichtlinie für Administratoren (oder Cluster)
![\[Abbildung der Bewertungsreihenfolge für Netzwerkrichtlinien in EKS\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/images/evaluation-order.png)
#### Verwendung der Cluster-Netzwerkrichtlinie
Bei Verwendung von werden die Richtlinien der Admin-Ebene zuerst bewertet und können nicht außer Kraft gesetzt werden. `ClusterNetworkPolicy` Wenn die Richtlinien auf Admin-Ebene evaluiert wurden, werden die angewendeten Netzwerksegmentierungsregeln anhand der standardmäßigen Namespace-Richtlinien ausgeführt. Dies kann entweder mit oder erreicht werden. `ApplicationNetworkPolicy` `NetworkPolicy` Schließlich werden die Baseline-Tier-Regeln, die die Standard-Netzwerkeinschränkungen für Cluster-Workloads definieren, durchgesetzt. Diese Regeln der Baseline-Stufe **können** bei Bedarf durch die Richtlinien für den Namespace-Bereich außer Kraft gesetzt werden.
#### Beispiel
Sie haben eine Anwendung in Ihrem Cluster, die Sie von anderen Mandanten-Workloads isolieren möchten. Sie können den Clusterverkehr von anderen Namespaces explizit blockieren, um den Netzwerkzugriff auf den sensiblen Workload-Namespace zu verhindern.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Überlegungen
### Verstehen Sie die Reihenfolge der Richtlinienevaluierung
Die in EKS unterstützten Funktionen für Netzwerkrichtlinien werden in einer bestimmten Reihenfolge bewertet, um ein vorhersehbares und sicheres Datenverkehrsmanagement zu gewährleisten. Daher ist es wichtig, den Bewertungsablauf zu verstehen, um eine effektive Netzwerksicherheit für Ihre Umgebung zu entwickeln.
1. **Richtlinien auf Admin-Ebene (zuerst bewertet)**: ClusterNetworkPolicies Die gesamte Admin-Ebene wird vor allen anderen Richtlinien bewertet. Innerhalb der Admin-Ebene werden Richtlinien in der Reihenfolge ihrer Priorität verarbeitet (Nummer mit der niedrigsten Priorität zuerst). Der Aktionstyp bestimmt, was als Nächstes passiert.
+ **Aktion ablehnen (höchste Priorität)**: Wenn eine Admin-Richtlinie mit der Aktion „Ablehnen“ dem Verkehr entspricht, wird dieser Verkehr sofort blockiert, unabhängig von anderen Richtlinien. Es werden keine weiteren ClusterNetworkPolicy NetworkPolicy OD-Regeln verarbeitet. Dadurch wird sichergestellt, dass unternehmensweite Sicherheitskontrollen nicht durch Richtlinien auf Namespace-Ebene außer Kraft gesetzt werden können.
+ **Aktion zulassen**: Nach der Auswertung der Ablehnungsregeln werden Administratorrichtlinien mit Zulassen-Aktionen in der Reihenfolge ihrer Priorität verarbeitet (die niedrigste Priorität zuerst). Wenn eine Aktion „Zulassen“ zutrifft, wird der Datenverkehr akzeptiert und es findet keine weitere Richtlinienbewertung statt. Diese Richtlinien können auf der Grundlage von Label-Selektoren Zugriff auf mehrere Namespaces gewähren und ermöglichen so eine zentrale Kontrolle darüber, welche Workloads auf bestimmte Ressourcen zugreifen können.
+ **Aktion weiterleiten**: Bei der Weiterleitung von Aktionen in den Richtlinien der Admin-Ebene wird die Entscheidungsfindung an untergeordnete Ebenen delegiert. Wenn der Traffic mit einer Pass-Regel übereinstimmt, werden bei der Evaluierung alle verbleibenden Regeln auf Admin-Ebene für diesen Traffic übersprungen und direkt zur NetworkPolicy Stufe weitergeleitet. Auf diese Weise können Administratoren die Kontrolle über bestimmte Datenverkehrsmuster explizit an Anwendungsteams delegieren. Sie können beispielsweise Pass-Regeln verwenden, um die Verwaltung des Datenverkehrs innerhalb des Namespaces an Namespace-Administratoren zu delegieren und gleichzeitig strenge Kontrollen des externen Zugriffs aufrechtzuerhalten.
1. **Netzwerkrichtlinienebene**: Wenn keine Richtlinie auf Admin-Ebene mit „Verweigern“ oder „Zulassen“ übereinstimmt oder wenn eine Pass-Aktion gefunden wurde, werden als Nächstes Ressourcen mit ApplicationNetworkPolicy Namespace-Bereich und herkömmliche Ressourcen bewertet. NetworkPolicy Diese Richtlinien ermöglichen eine detaillierte Steuerung innerhalb der einzelnen Namespaces und werden von Anwendungsteams verwaltet. Namespace-bezogene Richtlinien können nur restriktiver sein als Admin-Richtlinien. Sie können die Ablehnungsentscheidung einer Admin-Richtlinie nicht außer Kraft setzen, aber sie können den Datenverkehr weiter einschränken, der durch Admin-Richtlinien zugelassen oder weitergeleitet wurde.
1. **Administratorrichtlinien der Baseline-Stufe**: Wenn keine Admin- oder Namespace-bezogenen Richtlinien dem Traffic entsprechen, wird die Baseline-Stufe bewertet. ClusterNetworkPolicies Diese bieten standardmäßige Sicherheitsvorkehrungen, die durch Richtlinien im Namespace-Bereich außer Kraft gesetzt werden können. So können Administratoren unternehmensweite Standardeinstellungen festlegen und den Teams gleichzeitig die Flexibilität geben, sie nach Bedarf anzupassen. Basisrichtlinien werden in der Reihenfolge ihrer Priorität bewertet (niedrigste Priorität zuerst).
1. **Standardverweigerung (wenn keine Richtlinien zutreffen)**: Dieses deny-by-default Verhalten stellt sicher, dass nur explizit zugelassene Verbindungen zugelassen werden, wodurch ein hohes Maß an Sicherheit gewährleistet wird.
### Anwendung des Prinzips der geringsten Rechte
+ **Beginnen Sie mit restriktiven Richtlinien und fügen Sie nach Bedarf schrittweise Berechtigungen hinzu**. Implementieren Sie zunächst deny-by-default Richtlinien auf Clusterebene und fügen Sie dann schrittweise Zulassungsregeln hinzu, wenn Sie legitime Konnektivitätsanforderungen überprüfen. Dieser Ansatz zwingt die Teams, jede externe Verbindung ausdrücklich zu begründen, wodurch eine sicherere und überprüfbarere Umgebung geschaffen wird.
+ **Regelmäßige Überprüfung und Entfernung ungenutzter Richtlinienregeln** — Netzwerkrichtlinien können sich im Laufe der Zeit ansammeln, wenn sich Anwendungen weiterentwickeln, sodass veraltete Regeln zurückbleiben, die Ihre Angriffsfläche unnötig erweitern. Führen Sie einen regelmäßigen Überprüfungsprozess durch, um nicht mehr benötigte Richtlinienregeln zu identifizieren und zu entfernen. So stellen Sie sicher, dass Ihre Sicherheitsvorkehrungen weiterhin streng und durchführbar sind.
+ **Verwenden Sie nach Möglichkeit spezifische Domainnamen statt allgemeiner Muster.** Platzhaltermuster wie z. B. `*.amazonaws.com` bieten zwar Komfort, gewähren aber auch Zugriff auf eine breite Palette von Diensten. Geben Sie, wann immer möglich, genaue Domainnamen an, z. B. `s3.us-west-2.amazonaws.com` um den Zugriff nur auf die spezifischen Dienste zu beschränken, die Ihre Anwendungen benötigen, wodurch das Risiko einer seitlichen Verlagerung verringert wird, wenn eine Arbeitslast beeinträchtigt wird.
### Verwendung von DNS-basierten Richtlinien in EKS
+ DNS-basierte Regeln, die mithilfe von definiert wurden, `ApplicationNetworkPolicy` gelten nur für Workloads, die in EC2-Instances ausgeführt werden, die im automatischen EKS-Modus gestartet wurden. Wenn Sie einen Cluster im gemischten Modus ausführen (der sowohl aus EKS Auto- als auch aus Nicht-EKS Auto-Worker-Knoten besteht), sind Ihre DNS-basierten Regeln nur in den EKS-Workerknoten im automatischen Modus (EC2-verwaltete Instances) wirksam.
### Validierung Ihrer DNS-Richtlinien
+ **Verwenden Sie zum Testen Staging-Cluster, die die Topologie des Produktionsnetzwerks widerspiegeln**. Ihre Staging-Umgebung sollte die Netzwerkarchitektur, die externen Abhängigkeiten und die Konnektivitätsmuster der Produktion replizieren, um genaue Richtlinientests zu gewährleisten. Dazu gehören passende VPC-Konfigurationen, DNS-Auflösungsverhalten und Zugriff auf dieselben externen Dienste, die Ihre Produktions-Workloads benötigen.
+ **Implementieren Sie automatisierte Tests für kritische Netzwerkpfade** — Erstellen Sie automatisierte Tests, die die Konnektivität zu wichtigen externen Diensten als Teil Ihrer CI/CD Pipeline validieren. Mit diesen Tests sollte überprüft werden, ob legitimer Datenverkehr zulässig ist, während nicht autorisierte Verbindungen blockiert werden. Auf diese Weise wird kontinuierlich überprüft, ob Ihre Netzwerkrichtlinien bei der Weiterentwicklung Ihrer Infrastruktur den richtigen Sicherheitsstatus beibehalten.
+ **Überwachen Sie das Anwendungsverhalten nach Richtlinienänderungen** — Nach der Implementierung neuer oder geänderter Netzwerkrichtlinien in der Produktion sollten Sie die Anwendungsprotokolle, Fehlerraten und Leistungskennzahlen genau überwachen, um Verbindungsprobleme schnell zu identifizieren. Richten Sie klare Rollback-Verfahren ein, damit Sie Richtlinienänderungen schnell rückgängig machen können, falls sie zu unerwartetem Anwendungsverhalten oder Betriebsunterbrechungen führen.
### Interaktion mit der Amazon Route 53 DNS-Firewall
Die Admin- und Netzwerkrichtlinien von EKS werden zunächst auf Pod-Ebene bewertet, wenn der Datenverkehr initiiert wird. Wenn eine EKS-Netzwerkrichtlinie den Ausgang zu einer bestimmten Domäne zulässt, führt der Pod dann eine DNS-Abfrage durch, die den Route 53 53-Resolver erreicht. Zu diesem Zeitpunkt werden die DNS-Firewallregeln für Route 53 ausgewertet. Wenn die DNS-Firewall die Domänenabfrage blockiert, schlägt die DNS-Auflösung fehl und die Verbindung kann nicht hergestellt werden, obwohl die EKS-Netzwerkrichtlinie dies zulässt. Dadurch entstehen ergänzende Sicherheitsebenen: Die DNS-basierten Netzwerkrichtlinien von EKS bieten Ausgangskontrolle auf Pod-Ebene für anwendungsspezifische Zugriffsanforderungen und mehrinstanzenfähige Sicherheitsgrenzen, während die DNS-Firewall VPC-weiten Schutz vor bekannten bösartigen Domänen bietet und unternehmensweite Blocklisten durchsetzt.
# Kennzeichnung von Subnetzen für EKS Auto Mode
Wenn Sie die Lastausgleichsfunktion von EKS Auto Mode verwenden, müssen Sie Ihren VPC-Subnetzen AWS Tags hinzufügen.
## Hintergrund
Diese Tags kennzeichnen Subnetze als mit dem Cluster verbunden und, noch wichtiger, sie geben an, ob es sich um ein öffentliches oder privates Subnetz handelt.
Öffentliche Subnetze verfügen über einen direkten Internetzugang über ein Internet-Gateway. Sie werden für Ressourcen verwendet, die öffentlich zugänglich sein müssen, wie beispielsweise Load Balancer.
Private Subnetze verfügen über keinen direkten Internetzugang und verwenden NAT-Gateways für ausgehenden Datenverkehr. Sie werden für interne Ressourcen wie EKS-Knoten verwendet, die keine öffentlichen Ressourcen benötigen. IPs
Weitere Informationen zu NAT-Gateways und Internet-Gateways finden Sie unter [Verbinden Ihrer VPC mit anderen Netzwerken](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) im Benutzerhandbuch zu Amazon Virtual Private Cloud (VPC).
## Anforderung
Derzeit müssen Subnetze, die für den Lastausgleich im EKS Auto Mode verwendet werden, über eines der folgenden Tags verfügen.
### Öffentliche Subnetze
Öffentliche Subnetze werden für Load Balancer mit Internetverbindung verwendet. Diese Subnetze müssen die folgenden Tags aufweisen:
| Key (Schlüssel) | Value (Wert) |
| --- | --- |
| `kubernetes.io/role/elb` | `1` oder `` |
### Private Subnetze
Private Subnetze werden für interne Load Balancer verwendet. Diese Subnetze müssen die folgenden Tags aufweisen:
| Key (Schlüssel) | Value (Wert) |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1` oder `` |
## Verfahren
Ermitteln Sie zunächst, welche Subnetze öffentlich sind (mit Internetzugang) und welche privat sind (mit NAT-Gateway). Sie benötigen Berechtigungen, um VPC-Ressourcen zu ändern.
### AWS-Managementkonsole
1. Öffnen Sie die Amazon VPC-Konsole und navigieren Sie zu **Subnetze**.
1. Wählen Sie das Subnetz aus, das Sie kennzeichnen möchten.
1. Wählen Sie die Registerkarte „**Tags**“ und dann „**Tag hinzufügen**“.
1. Das entsprechende Tag hinzufügen:
+ Für öffentliche Subnetze: Schlüssel = `kubernetes.io/role/elb`
+ Für private Subnetze: Schlüssel = `kubernetes.io/role/internal-elb`
1. Legen Sie **Wert** auf fest `1` oder lassen Sie das Feld leer.
1. Speichern Sie und wiederholen Sie den Vorgang für die verbleibenden Subnetze.
### AWS CLI
Für öffentliche Subnetze:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
Für private Subnetze:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
Ersetzen Sie `subnet-ID` durch Ihre tatsächliche Subnetz-ID.
# CIS-Compliance-Berichte aus Kubernetes-Knoten mithilfe von kubectl debug generieren
In diesem Thema wird beschrieben, wie Sie mithilfe des `kubectl debug`-Befehls CIS-Konformitätsberichte (Center for Internet Security) für Amazon-EKS-Knoten generieren können. Mit diesem Befehl können Sie vorübergehend einen Debugging-Container in einem Kubernetes-Knoten erstellen und CIS-Konformitätsprüfungen mit dem `apiclient`-Tool durchführen. Das `apiclient`-Tool ist Teil von Bottlerocket OS, dem Betriebssystem, das von Knoten in EKS Auto Mode verwendet wird.
## Voraussetzungen
Stellen Sie vor Beginn sicher, dass Sie über Folgendes verfügen:
+ Zugriff auf einen Amazon-EKS-Cluster mit konfiguriertem `kubectl` (Version muss mindestens v1.32.0 sein. `kubectl version` eingeben, um dies zu überprüfen).
+ Die entsprechenden IAM-Berechtigungen zum Debuggen von Knoten.
+ Ein gültiges Profil, das Debugging-Vorgänge zulässt (z. B. `sysadmin`).
Weitere Informationen zur Verwendung von Debugging-Profilen mit `kubectl` finden Sie unter [Debugging eines Pods oder Knotens bei Anwendung eines Profils](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles) in der Kubernetes-Dokumentation.
## Verfahren
1. Ermitteln Sie die AWS Instanz-ID des Knotens, auf dem Sie den Bericht ausführen möchten. Verwenden Sie den folgenden Befehl, um die Knoten im Cluster aufzulisten. Die Instance-ID befindet sich in der Spalte „Name“ und beginnt mit `i-`:
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. Führen Sie den folgenden Befehl aus und ersetzen Sie `` durch die Instance-ID des Knotens, den Sie abfragen möchten:
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
Zu den Komponenten dieses Befehls gehören:
+ `kubectl debug node/` – Erstellt eine Debugging-Sitzung in der angegebenen EC2-Instance-ID.
+ `-it` – Weist ein TTY (Kommandozeilen-Shell) zu und hält die Standardeingabe für die interaktive Nutzung geöffnet.
+ `--profile=sysadmin` – Verwendet das angegebene `kubectl`-Profil mit den entsprechenden Berechtigungen.
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023` – Verwendet `amazonlinux:2023` als Container-Image zum Debuggen.
+ `bash -c "…"` – Führt die folgenden Befehle in einer Bash-Shell aus:
+ `yum install -q -y util-linux-core` – Installiert das erforderliche Service-Programmpaket im Hintergrund.
+ `nsenter -t 1 -m` – Führt `nsenter` aus, um in den Namespace des Host-Prozesses (PID 1) zu gelangen.
+ `apiclient report cis --level 1 --format text` – Führt den CIS-Konformitätsbericht auf Ebene 1 mit Textausgabe aus.
1. Überprüfen Sie die Textausgabe des Berichts.
## Auswertung der Ausgabe
Der Befehl generiert einen textbasierten Bericht, der den Konformitätsstatus verschiedener CIS-Steuerungen anzeigt. Die Ausgabe enthält:
+ Individuelle CIS-Steuerung IDs
+ Beschreibung jeder Steuerung
+ Status „Bestanden“, „Nicht bestanden“ oder „Übersprungen“ für jede Prüfung
+ Details, die etwaige Compliance-Probleme erklären
Nachfolgend finden Sie ein Beispiel für die Ausgabe des Berichts, der in einer Bottlerocket-Instance ausgeführt wurde:
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
Informationen zum Benchmark finden Sie unter [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) vom Center for Internet Security (CIS).
## Zugehörige Ressourcen
+ [Bottlerocket CIS Benchmark](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/) in der Bottlerocket-OS-Dokumentation.
+ [Debugging von ausgeführten Pods](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/) in der Kubernetes-Dokumentation.
+ [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) vom Center for Internet Security (CIS)
# EBS-Volume-Verschlüsselung mit vom Kunden verwalteten KMS-Schlüsseln für EKS Auto Mode aktivieren
Sie können das flüchtige Root-Volume für Instances in EKS Auto Mode mit einem vom Kunden verwalteten KMS-Schlüssel verschlüsseln.
Amazon EKS Auto Mode verwendet serviceverknüpfte Rollen, um Berechtigungen an andere AWS Services zu delegieren, wenn verschlüsselte EBS-Volumes für Ihre Kubernetes-Cluster verwaltet werden. In diesem Thema wird beschrieben, wie Sie die Schlüsselrichtlinie einrichten, die Sie benötigen, wenn Sie einen vom Kunden verwalteten Schlüssel für die Amazon-EBS-Verschlüsselung mit EKS Auto Mode angeben.
Überlegungen:
+ Der automatische Modus von EKS benötigt keine zusätzliche Autorisierung, um den AWS verwalteten Standardschlüssel zum Schutz der verschlüsselten Volumes in Ihrem Konto zu verwenden.
+ In diesem Thema wird das Verschlüsseln kurzlebiger Volumes, also der Root-Volumes für Instances, behandelt. EC2 Weitere Informationen zur Verschlüsselung von für Workloads verwendeten Daten-Volumes finden Sie unter [Erstellen einer Speicherklasse](create-storage-class.md).
## -Übersicht
Die folgenden AWS KMS-Schlüssel können für die Amazon EBS-Root-Volume-Verschlüsselung verwendet werden, wenn EKS Auto Mode Instances startet:
+ ** AWS -verwalteter Schlüssel** – Ein Verschlüsselungsschlüssel in Ihrem Konto, den Amazon EBS erstellt, besitzt und verwaltet. Dies ist der Standardverschlüsselungsschlüssel für ein neues Konto.
+ **Kundenverwalteter Schlüssel** – Ein benutzerdefinierter Verschlüsselungsschlüssel, den Sie erstellen, besitzen und verwalten.
**Anmerkung**
Der Schlüssel muss symmetrisch sein. Amazon EBS unterstützt keine asymmetrischen vom Kunden verwalteten Schlüssel.
## Schritt 1: Schlüsselrichtlinie konfigurieren
Ihre KMS-Schlüssel müssen über eine Schlüsselrichtlinie verfügen, die es EKS Auto Mode ermöglicht, Instances mit Amazon-EBS-Volumes zu starten, die mit einem vom Kunden verwalteten Schlüssel verschlüsselt sind.
Konfigurieren Sie Ihre Schlüsselrichtlinie mit der folgenden Struktur:
**Anmerkung**
Diese Richtlinie umfasst nur Berechtigungen für EKS Auto Mode. Die Schlüsselrichtlinie benötigt möglicherweise zusätzliche Berechtigungen, wenn andere Identitäten den Schlüssel verwenden oder Berechtigungen verwalten müssen.
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
Stellen Sie sicher, dass Sie es `` durch Ihre tatsächliche AWS Konto-ID ersetzen.
Beim Konfigurieren der Schlüsselrichtlinie:
+ Die `ClusterServiceRole` muss über die erforderlichen IAM-Berechtigungen verfügen, um den KMS-Schlüssel für Verschlüsselungsvorgänge zu verwenden
+ Die `kms:GrantIsForAWSResource` Bedingung stellt sicher, dass Zuschüsse nur für AWS Dienstleistungen gewährt werden können
## Schritt 2: Konfigurieren Sie NodeClass mit Ihrem vom Kunden verwalteten Schlüssel
Nachdem Sie die Schlüsselrichtlinie konfiguriert haben, verweisen Sie in Ihrer NodeClass EKS-Konfiguration für den automatischen Modus auf den KMS-Schlüssel:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# KMS key for encryption
kmsKeyID: "arn:aws: kms:::key/"
```
Ersetzen Sie die Platzhalterwerte durch Ihre tatsächlichen Werte:
+ ``mit Ihrer AWS Region
+ ``mit deiner AWS Konto-ID
+ `` mit Ihrer KMS-Schlüssel-ID
Sie können den KMS-Schlüssel in einem der folgenden Formate angeben:
+ KMS-Schlüssel-ID: `1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ KMS-Schlüssel-ARN: ` arn:aws: kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ Schlüssel-Alias-Name: `alias/eks-auto-mode-key`
+ Schlüssel-Alias-ARN: ` arn:aws: kms:us-west-2:111122223333:alias/eks-auto-mode-key`
Wenden Sie die NodeClass Konfiguration mit kubectl an:
```
kubectl apply -f nodeclass.yaml
```
## Verwandte Ressourcen
+ [Knotenklasse für Amazon EKS erstellen](create-node-class.md)
+ Weitere Informationen finden Sie im AWS Key Management Service Developer Guide
+ [Berechtigungen für AWS Dienste in wichtigen Richtlinien](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [Schlüsselrichtlinie ändern](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [Zuschüsse in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# Organisationssteuerung für EKS Auto Mode aktualisieren
Einige Organisationssteuerungen können die korrekte Funktion von EKS Auto Mode beeinträchtigen. In diesem Fall müssen Sie diese Steuerungen aktualisieren, damit EKS Auto Mode über die erforderlichen Berechtigungen verfügt, um EC2-Instances in Ihrem Namen zu verwalten.
EKS Auto Mode verwendet eine Servicerolle zum Starten der EC2-Instances, welche die Knoten von EKS Auto Mode unterstützen. Eine Servicerolle ist eine [IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html), die in Ihrem Konto erstellt wird und die ein Service übernimmt, um in Ihrem Namen Aktionen auszuführen. [Dienststeuerungsrichtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCPs) gelten immer für Aktionen, die mit Servicerollen ausgeführt werden. Dadurch kann ein SCP die Vorgänge im Automatikmodus unterbinden. Am häufigsten kommt es vor, wenn ein SCP verwendet wird, um die Amazon Machine Images (AMIs) einzuschränken, die gestartet werden können. Damit der EKS-Automodus funktioniert, ändern Sie den SCP so, dass der Start AMIs von EKS-Automodus-Konten aus möglich ist.
Sie können auch die AMIs Funktion [EC2 Allowed](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) verwenden, um die Sichtbarkeit von AMIs in anderen Konten einzuschränken. Wenn Sie dieses Feature verwenden, müssen Sie die Image-Kriterien erweitern, um auch die AMI-Konten in EKS Auto Mode in den relevanten Regionen einzubeziehen.
## Beispiel SCP, um alle AMIs außer dem EKS-Automatikmodus zu blockieren AMIs
Die nachfolgende SCP verhindert den Aufruf von `ec2:RunInstances`, es sei denn, die AMI gehört zum AMI-Konto in EKS Auto Mode für us-west-2 oder us-east-1.
**Anmerkung**
Es ist wichtig, den Kontextschlüssel `ec2:Owner` **nicht** zu verwenden. Amazon ist Eigentümer der AMI-Konten in EKS Auto Mode, und der Wert für diesen Schlüssel ist stets `amazon`. Die Konstruktion eines SCP, das den Start ermöglicht, AMIs wenn der `ec2:Owner` IS `amazon` das Starten aller Amazon-eigenen AMI ermöglicht, nicht nur der AMIs für den EKS-Automatikmodus. \$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## AMI-Konten in EKS Auto Mode
AWS Konten, die je nach Region variieren, hosten EKS Auto Mode public AMIs.
| | |
| --- |--- |
| AWS Region | Account |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-east-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-southeast-6 | 905418310314 |
| ap-southeast-7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-central-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us-east-1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## Öffentliche IP-Adresse zuweisen
Wenn `ec2:RunInstances` aufgerufen wird, wird das `AssociatePublicIpAddress`-Feld für einen Instance-Start automatisch durch den Typ des Subnetzes bestimmt, in dem die Instance gestartet wird. Ein SCP kann verwendet werden, um sicherzustellen, dass dieser Wert unabhängig vom Typ des Subnetzes, in dem der Start erfolgt, explizit auf „false“ gesetzt wird. In diesem Fall `spec.advancedNetworking.associatePublicIPAddress` kann das NodeClass Feld auch auf false gesetzt werden, um die Anforderungen des SCP zu erfüllen.
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# Steuern Sie die Bereitstellung von Workloads in Kapazitätsreservierungen mit EKS Auto Mode.
Sie können die Bereitstellung von Workloads in [Kapazitätsreservierungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html) steuern. EKS Auto Mode unterstützt EC2-On-Demand-Kapazitätsreservierungen (ODCRs) und EC2-Kapazitätsblöcke für ML.
**Tipp**
Standardmäßig kann der automatische EKS-Modus ODCRs durch Open-Matching in Open gestartet werden, priorisiert sie jedoch nicht. Instances, die durch Open-Matching gestartet werden, sind gekennzeichnet`karpenter.sh/capacity-type: on-demand`, nicht. `reserved` Um der ODCR-Nutzung Priorität einzuräumen und Instanzen beschriften zu lassen`karpenter.sh/capacity-type: reserved`, konfigurieren Sie dies `capacityReservationSelectorTerms` in der Definition. NodeClass Kapazitätsblöcke für ML sind immer erforderlich `capacityReservationSelectorTerms` und werden nicht automatisch verwendet.
## EC2-Kapazitätsreservierungen auf Abruf () ODCRs
EC2-Kapazitätsreservierungen ermöglichen Ihnen das Reservieren von Datenverarbeitungskapazität für Ihre Amazon-EC2-Instances in einer bestimmten Availability Zone für eine beliebige Dauer. Bei Verwendung von EKS Auto Mode möchten Sie möglicherweise steuern, ob Ihre Kubernetes-Workloads in diesen reservierten Instances bereitgestellt werden, um die Auslastung der im Voraus erworbenen Kapazität zu maximieren oder um sicherzustellen, dass wichtige Workloads Zugriff auf garantierte Ressourcen haben.
Standardmäßig wird der EKS-Automatikmodus automatisch geöffnet ODCRs. Durch die Konfiguration `capacityReservationSelectorTerms` auf a können Sie NodeClass jedoch explizit steuern, welche ODCRs Workloads verwendet werden. Knoten, die mithilfe von configured bereitgestellt wurden, haben ODCRs Vorrang vor On-Demand-Nodes `karpenter.sh/capacity-type: reserved` und Spot-Nodes und haben auch weiterhin Priorität. Sobald diese Funktion aktiviert ist, verwendet der automatische EKS-Modus nicht mehr automatisch die Option „Öffnen“ ODCRs. Sie müssen explizit durch ein ausgewählt werden NodeClass, sodass Sie die Kapazitätsreservierungsnutzung in Ihrem gesamten Cluster genau steuern können.
**Warnung**
Wenn Sie NodeClass in `capacityReservationSelectorTerms` einem Cluster eine Konfiguration vornehmen, verwendet EKS Auto Mode nicht mehr automatisch open ODCRs für *alle* NodeClass im Cluster.
### Beispiel NodeClass
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
Dieses Beispiel NodeClass zeigt zwei Ansätze für die Auswahl ODCRs. Die erste Methode verweist direkt über die ID (`cr-56fac701cc1951b03`) auf einen bestimmten ODCR. Die zweite Methode verwendet eine Tag-basierte Auswahl, ODCRs wobei das Targeting anhand des Tags `Name: "targeted-odcr"` erfolgt. Sie können optional auch nach dem AWS Konto filtern, dem die Reservierung gehört. Dies ist besonders nützlich in kontoübergreifenden Szenarien oder bei der Arbeit mit Reservierungen für gemeinsame Kapazitäten.
## EC2-Kapazitätsblöcke für ML
Kapazitätsblöcke für ML reservieren GPU-basierte beschleunigte Rechen-Instances für einen zukünftigen Zeitpunkt, um Ihre kurzfristigen Machine-Learning-Workloads (ML) zu unterstützen. Instances, die innerhalb eines Kapazitätsblocks ausgeführt werden, werden in Amazon EC2 automatisch nahe beieinander platziert UltraClusters, um blockierungsfreie Netzwerke im Petabit-Bereich mit niedriger Latenz zu gewährleisten.
Weitere Informationen zu den unterstützten Plattformen und Instance-Typen finden Sie unter [Kapazitätsblöcke für ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) im EC2-Benutzerhandbuch.
Sie können einen automatischen EKS-Modus erstellen NodeClass , der einen Kapazitätsblock für ML verwendet, ähnlich einem ODCR (weiter oben beschrieben).
Die folgenden Beispieldefinitionen erstellen drei Ressourcen:
1. A NodeClass , das auf Ihre Kapazitätsblock-Reservierung verweist
1. Eine NodePool , die den NodeClass und verwendet, verleiht ihm einen Makel
1. Eine Pod-Spezifikation, die den Taint toleriert und GPU-Ressourcen anfordert
### Beispiel NodeClass
Dies NodeClass verweist anhand seiner Reservierungs-ID auf einen bestimmten Kapazitätsblock für ML. Sie können diese ID über die EC2-Konsole abrufen.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
Weitere Informationen finden Sie unter [Knotenklasse für Amazon EKS erstellen](create-node-class.md).
### Beispiel NodePool
Dies NodePool verweist auf die `gpu` NodeClass und spezifiziert eine wichtige Konfiguration:
+ Er nutzt **auschliesslich** reservierte Kapazität, indem er `karpenter.sh/capacity-type: reserved` festlegt
+ Es werden bestimmte GPU-Instance-Familien angefordert, die für ML-Workloads geeignet sind
+ Es wird ein `nvidia.com/gpu` Taint angewendet, um sicherzustellen, dass nur GPU-Workloads auf diesen Knoten geplant werden
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
Weitere Informationen finden Sie unter [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md).
### Beispiel Pod
Dieses Beispiel-Pod veranschaulicht, wie Sie eine Workload für die Ausführung in Ihren Kapazitätsblock-Knoten konfigurieren:
+ Es verwendet einen **NodeSelector**, um auf bestimmte GPU-Typen abzuzielen (in diesem Fall H200) GPUs
+ Es beinhaltet eine **Toleranz für den Makel, der durch** den `nvidia.com/gpu` NodePool
+ Es fordert **explizit GPU-Ressourcen** unter Verwendung des `nvidia.com/gpu`-Ressourcentyps an
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Weitere Informationen finden Sie unter [Dry run](https://kubernetes.io/docs/concepts/workloads/pods/) in der Kubernetes-Dokumentation.
### Verwandte Ressourcen
+ [Kapazitätsblöcke für ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) im Benutzerhandbuch für Amazon-EC2
+ [Kapazitätsblöcke suchen und erwerben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) im Benutzerhandbuch für Amazon-EC2
+ [Rechenressourcen für AI/ML Workloads auf Amazon EKS verwalten](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ [GPU-Ressourcenoptimierung und Kostenmanagement](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) im EKS-Leitfaden für bewährte Verfahren
# Stellen Sie EKS-Automodus-Knoten in Local Zones bereit
Der automatische Modus von EKS bietet eine vereinfachte Clusterverwaltung mit automatischer Knotenbereitstellung. AWS Local Zones erweitern die AWS Infrastruktur auf geografische Standorte, die näher an Ihren Endbenutzern liegen, und reduzieren so die Latenz für latenzempfindliche Anwendungen. Dieses Handbuch führt Sie durch den Prozess der Bereitstellung von EKS-Automodus-Knoten in AWS Local Zones, sodass Sie containerisierte Anwendungen mit geringerer Latenz für Benutzer in bestimmten geografischen Gebieten ausführen können.
In diesem Leitfaden wird auch gezeigt, wie Sie mithilfe von Kubernetes-Taints and Tolerations sicherstellen können, dass nur bestimmte Workloads auf Ihren Local-Zone-Knoten ausgeführt werden. So können Sie die Kosten kontrollieren und die Ressourcennutzung optimieren.
## Voraussetzungen
Bevor Sie mit der Bereitstellung von EKS-Automodus-Knoten in Local Zones beginnen, stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind:
+ [Ein vorhandener EKS-Auto-Mode-Cluster](create-auto.md)
+ [Sie haben sich in Ihrem Konto für die lokale Zone angemeldet AWS](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## Schritt 1: Subnetz für die lokale Zone erstellen
Der erste Schritt bei der Bereitstellung von EKS-Automodus-Knoten in einer lokalen Zone besteht darin, ein Subnetz in dieser lokalen Zone zu erstellen. Dieses Subnetz stellt die Netzwerkinfrastruktur für Ihre Knoten bereit und ermöglicht ihnen, mit dem Rest Ihrer VPC zu kommunizieren. Folgen Sie den Anweisungen zum [Erstellen eines Subnetzes für eine lokale Zone](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet) (im Benutzerhandbuch für AWS Local Zones), um ein Subnetz in der von Ihnen ausgewählten lokalen Zone zu erstellen.
**Tipp**
Notieren Sie sich den Namen Ihres lokalen Zonen-Subnetzes.
## Schritt 2: Erstellen Sie das NodeClass Subnetz für die lokale Zone
Nachdem Sie Ihr Subnetz für die lokale Zone erstellt haben, müssen Sie ein Subnetz definieren, NodeClass das auf dieses Subnetz verweist. Das NodeClass ist eine benutzerdefinierte Kubernetes-Ressource, die die Infrastrukturattribute für Ihre Knoten spezifiziert, einschließlich der zu verwendenden Subnetze, Sicherheitsgruppen und Speicherkonfigurationen. Im folgenden Beispiel erstellen wir eine NodeClass sogenannte „lokale Zone“, die anhand ihres Namens auf ein Subnetz der lokalen Zone abzielt. Sie können auch die Subnetz-ID verwenden. Sie müssen diese Konfiguration an Ihr lokales Zonen-Subnetz anpassen.
Weitere Informationen finden Sie unter [Knotenklasse für Amazon EKS erstellen](create-node-class.md).
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## Schritt 3: Create NodePool with NodeClass und Taint
Nachdem Sie es NodeClass konfiguriert haben, müssen Sie jetzt eine erstellen NodePool , die dies NodeClass verwendet. A NodePool definiert die Recheneigenschaften Ihrer Knoten, einschließlich der Instanztypen. Der NodePool verwendet das NodeClass als Referenz, um zu bestimmen, wo Instances gestartet werden sollen.
Im folgenden Beispiel erstellen wir eine, NodePool die auf unsere „lokale Zone“ verweist. NodeClass Außerdem fügen wir den Knoten einen Tain hinzu, um sicherzustellen, dass nur Pods mit einer entsprechenden Toleranz auf diesen Local-Zone-Knoten geplant werden können. Dies ist besonders wichtig für Knoten in der lokalen Zone, die in der Regel höhere Kosten verursachen und nur von Workloads verwendet werden sollten, die speziell von der reduzierten Latenz profitieren.
Weitere Informationen finden Sie unter [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md).
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
Der Nachteil von Schlüssel `aws.amazon.com/local-zone` und Effekt `NoSchedule` stellt sicher, dass Pods ohne entsprechende Toleranzen nicht auf diesen Knoten eingeplant werden. Dadurch wird verhindert, dass reguläre Workloads versehentlich in der lokalen Zone ausgeführt werden, was zu unerwarteten Kosten führen könnte.
## Schritt 4: Stellen Sie Workloads mit Toleranz und Knotenaffinität bereit
Für eine optimale Kontrolle der Workload-Platzierung auf Knoten in der lokalen Zone sollten Sie beide taints/tolerations und die Knotenaffinität zusammen verwenden. Dieser kombinierte Ansatz bietet die folgenden Vorteile:
1. **Kostenkontrolle**: Dieser Fehler stellt sicher, dass nur Pods mit ausdrücklichen Toleranzen potenziell teure Local-Zone-Ressourcen nutzen können.
1. **Garantierte Platzierung**: Durch die Knotenaffinität wird sichergestellt, dass Ihre latenzempfindlichen Anwendungen ausschließlich in der lokalen Zone und nicht auf regulären Clusterknoten ausgeführt werden.
Hier ist ein Beispiel für eine Bereitstellung, die speziell für die Ausführung auf Knoten der lokalen Zone konfiguriert wurde:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
Diese Bereitstellung hat zwei wichtige Planungskonfigurationen:
1. Diese **Toleranz** ermöglicht es, die Pods auf Knoten mit dem `aws.amazon.com/local-zone` Makel zu planen.
1. Die Anforderung an die **Knotenaffinität** stellt sicher, dass diese Pods nur auf Knoten mit dem Label ausgeführt werden. `node-type: local-zone`
Zusammen stellen sie sicher, dass Ihre latenzempfindliche Anwendung nur auf Knoten der lokalen Zone ausgeführt wird und reguläre Anwendungen die Ressourcen der lokalen Zone nicht verbrauchen, sofern sie nicht ausdrücklich dafür konfiguriert wurden.
## Schritt 5: Überprüfen Sie mit der Konsole AWS
Nachdem Sie Ihre NodeClass NodePool, und Bereitstellungen eingerichtet haben, sollten Sie überprüfen, ob die Knoten wie erwartet in Ihrer lokalen Zone bereitgestellt werden und ob Ihre Workloads auf ihnen ausgeführt werden. Sie können die AWS Managementkonsole verwenden, um zu überprüfen, ob EC2 Instances im richtigen Subnetz der lokalen Zone gestartet werden.
Darüber hinaus können Sie anhand `kubectl get nodes -o wide` der Kubernetes-Knotenliste überprüfen, ob die Knoten Ihrem Cluster mit den richtigen Labels und Taints beitreten:
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
Sie können auch überprüfen, ob Ihre Workload-Pods auf den Knoten der lokalen Zone geplant sind:
```
kubectl get pods -o wide
```
Durch diesen Ansatz wird sichergestellt, dass auf diesen Knoten nur Workloads geplant werden, die den Taint Local Zone speziell tolerieren. Auf diese Weise können Sie die Kosten kontrollieren und die Ressourcen Ihrer lokalen Zone so effizient wie möglich nutzen.
# Erweiterte Sicherheitseinstellungen für Knoten konfigurieren
In diesem Thema wird beschrieben, wie Sie mithilfe der `advancedSecurity` Spezifikation in Ihrer Node Class erweiterte Sicherheitseinstellungen für Amazon EKS Auto Mode-Knoten konfigurieren.
## Voraussetzungen
Stellen Sie vor Beginn sicher, dass Sie über Folgendes verfügen:
+ Ein Cluster in Amazon EKS Auto Mode. Weitere Informationen finden Sie unter [Einen Cluster mit Amazon EKS Auto Mode erstellen](create-auto.md).
+ `kubectl` installiert und konfiguriert. Weitere Informationen finden Sie unter [Einrichtung zur Verwendung von Amazon EKS](setting-up.md).
+ Verständnis der Node Class-Konfiguration. Weitere Informationen finden Sie unter [Knotenklasse für Amazon EKS erstellen](create-node-class.md).
## Konfigurieren Sie erweiterte Sicherheitseinstellungen
Um erweiterte Sicherheitseinstellungen für Ihre Knoten zu konfigurieren, legen Sie die `advancedSecurity` Felder in Ihrer Node Class-Spezifikation fest:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
Wenden Sie diese Konfiguration an:
```
kubectl apply -f nodeclass.yaml
```
Verweisen Sie in Ihrer Node-Pool-Konfiguration auf diese Node-Klasse. Weitere Informationen finden Sie unter [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md).
## Beschreibungen der Felder
+ `fips`(boolean, optional): Wenn auf gesetzt`true`, werden Knoten mithilfe von FIPS AMIs 140-2-validierten kryptografischen Modulen bereitgestellt. Mit dieser Einstellung wird FIPS-konform ausgewählt. Kunden sind für die Verwaltung ihrer Compliance-Anforderungen AMIs verantwortlich. [Weitere Informationen finden Sie unter FIPS-Konformität.AWS](https://aws.amazon.com/compliance/fips/) Standard: `false`.
+ `kernelLockdown`(Zeichenfolge, optional): Steuert den Modus des Kernel-Lockdown-Sicherheitsmoduls. Zulässige Werte:
+ `integrity`: Blockiert Methoden zum Überschreiben des Kernelspeichers oder zum Ändern des Kernelcodes. Verhindert das Laden von Kernelmodulen ohne Vorzeichen.
+ `none`: Deaktiviert den Kernel-Lockdown-Schutz.
Weitere Informationen finden Sie in der [Dokumentation zum Lockdown des Linux-Kernels](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html).
## Überlegungen
+ FIPS-konform AMIs sind in den Regionen AWS USA Ost/West, AWS GovCloud (USA) und AWS Kanada (Zentral/West) verfügbar. [Weitere Informationen finden Sie unter FIPS-Konformität.AWS](https://aws.amazon.com/compliance/fips/)
+ Stellen Sie bei der Verwendung sicher`kernelLockdown: "integrity"`, dass Ihre Workloads nicht das Laden von unsignierten Kernelmodulen oder das Ändern des Kernelspeichers erfordern.
## Zugehörige Ressourcen
+ [Knotenklasse für Amazon EKS erstellen](create-node-class.md)- Vollständiger Leitfaden zur Konfiguration von Node Class
+ [Einen Knotenpool für EKS Auto Mode erstellen](create-node-pool.md)- Konfiguration des Knotenpools
# Weitere Informationen zur Funktionsweise von EKS Auto Mode
In diesem Kapitel erfahren Sie, wie die Komponenten von Amazon-EKS-Auto-Mode-Clustern funktionieren.
**Topics**
+ [
# Weitere Informationen zu von Amazon EKS Auto Mode verwalteten Instances
](automode-learn-instances.md)
+ [
# Weitere Informationen zu Identität und Zugriff in EKS Auto Mode
](auto-learn-iam.md)
+ [
# Weitere Informationen zu VPC-Netzwerke und Load Balancing in EKS Auto Mode
](auto-networking.md)
# Weitere Informationen zu von Amazon EKS Auto Mode verwalteten Instances
In diesem Thema wird erklärt, wie Amazon EKS Auto Mode EC2 Amazon-Instances in Ihrem EKS-Cluster verwaltet. Wenn Sie den automatischen EKS-Modus aktivieren, werden die Rechenressourcen Ihres Clusters automatisch von EKS bereitgestellt und verwaltet, wodurch sich die Art und Weise ändert, wie Sie mit den EC2 Instances interagieren, die als Knoten in Ihrem Cluster dienen.
Das Verständnis der Funktionsweise von Amazon EKS Auto Mode bei der Verwaltung von Instances ist für die Planung Ihrer Workload-Bereitstellungsstrategie und Ihrer Betriebsabläufe von entscheidender Bedeutung. Im Gegensatz zu herkömmlichen EC2 Instanzen oder verwalteten Knotengruppen folgen diese Instanzen einem anderen Lebenszyklusmodell, bei dem EKS die Verantwortung für viele betriebliche Aspekte übernimmt und gleichzeitig bestimmte Zugriffs- und Anpassungsarten einschränkt.
Amazon EKS Auto Mode automatisiert Routineaufgaben zur Erstellung neuer EC2 Instances und fügt sie als Knoten an Ihren EKS-Cluster an. Der automatische Modus von EKS erkennt, wenn ein Workload nicht auf bestehende Knoten passt, und erstellt eine neue EC2 Instance.
Amazon EKS Auto Mode ist für das Erstellen, Löschen und Patchen von EC2 Instances verantwortlich. Sie sind für die auf der Instance bereitgestellten Container und Pods verantwortlich.
EC2 Mit EKS Auto Mode erstellte Instances unterscheiden sich von anderen EC2 Instances, es handelt sich um verwaltete Instances. Diese verwalteten Instances sind Eigentum von EKS und unterliegen strengeren Beschränkungen. Sie können nicht direkt auf von EKS Auto Mode verwaltete Instances zugreifen oder Software darauf installieren.
AWS schlägt vor, entweder den EKS Auto Mode oder den selbstverwalteten Karpenter auszuführen. Sie können beide während einer Migration oder in einer erweiterten Konfiguration installieren. Wenn Sie beide installiert haben, konfigurieren Sie Ihre Knoten-Pools so, dass Workloads entweder Karpenter oder EKS Auto Mode zugeordnet sind.
Weitere Informationen finden Sie unter Von [Amazon EC2 verwaltete Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html) im EC2 Amazon-Benutzerhandbuch.
## Vergleichstabelle
| EC2 Standardinstanz | Von EKS Auto Mode verwaltete Instance |
| --- | --- |
| Sie sind für das Patchen und Aktualisieren der Instance verantwortlich. | AWS patcht und aktualisiert die Instanz automatisch. |
| EKS übernimmt keine Verantwortung für die Software auf der Instance. | EKS ist für bestimmte Software auf der Instance verantwortlich, wie `kubelet`, die Container-Laufzeitumgebung und das Betriebssystem. |
| Sie können die EC2 Instanz mithilfe der EC2 API löschen. | EKS bestimmt die Anzahl der in Ihrem Konto bereitgestellten Instances. Wenn Sie eine Workload löschen, reduziert EKS die Anzahl der Instances in Ihrem Konto. |
| Sie können SSH verwenden, um auf die EC2 Instance zuzugreifen. | Sie können Pods und Container auf der verwalteten Instance bereitstellen. |
| Sie bestimmen das Betriebssystem und das Image (AMI). | AWS bestimmt das Betriebssystem und das Image. |
| Sie können Workloads bereitstellen, die auf Windows- oder Ubuntu-Funktionalität basieren. | Sie können Container auf Linux-Basis bereitstellen, jedoch ohne spezifische Betriebssystemabhängigkeiten. |
| Sie legen fest, welcher Instance-Typ und welche Instance-Familie gestartet werden soll. | AWS bestimmt, welcher Instance-Typ und welche Familie gestartet werden sollen. Sie können einen Knoten-Pool verwenden, um die Instance-Typen einzuschränken, aus denen EKS Auto Mode auswählt. |
Die folgende Funktionalität funktioniert sowohl für verwaltete Instances als auch für EC2 Standard-Instances:
+ Sie können die Instanz in der AWS Konsole anzeigen.
+ Sie können den Instance-Speicher als flüchtigen Speicher für Workloads verwenden.
### AMI-Support
AWS Bestimmt im EKS-Automatikmodus das Image (AMI), das für Ihre Rechenknoten verwendet wird. AWS überwacht die Einführung neuer EKS Auto Mode AMI-Versionen. Wenn Sie Probleme mit der Workload im Zusammenhang mit einer AMI-Version haben, erstellen Sie einen Support-Fall. Weitere Informationen finden Sie unter [Erstellen von Supportfällen und Fallmanagement](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) im AWS Support-Benutzerhandbuch.
Im Allgemeinen veröffentlicht EKS jede Woche eine neue AMI, die CVE- und Sicherheitskorrekturen enthält.
## Unterstützte Instance-Referenz für EKS Auto Mode
EKS Auto Mode erstellt ausschließlich Instances von unterstützten Typen, die eine Mindestgröße aufweisen.
EKS Auto Mode unterstützt die folgenden Instance-Typen:
| Familie | Instance-Typen |
| --- | --- |
| Für Datenverarbeitung optimiert (C ) | c8i, c8i-flex, c8gd, c8gn, c8g, c7a, c7g, c7gn, c7gn, c7gd, c7i, c7i-flex, c6a, c6g, c6i, c6gn, c6id, c6in, c6gd, c5, c5a, c5d, c5ad, c5n, c4 |
| Allzweck (M) | m8i, m8i-flex, m8a, m8gn, m8gb, m8gd, m8g, m7i, m7a, m7g, m7g, m7i-flex, m6a, m6i, m6in, m6in, m6in, m6idn, m6gd, m5, m5a, m5ad, m5n, m5dn, m5d, m5zn, m4 |
| Speicheroptimiert (R ) | r8i, r8i-flex, r8gn, r8gb, r8gd, r8g, r7a, r7iz, r7iz, r7gd, r7i, r7g, r6a, r6i, r6id, r6in, r6idn, r6g, r6gd, r5, r5n, r5a, r5dn, r5b, r5ad, r5ad, r5n d, r4 |
| Mit Spitzenlast (T) | t4g, t3, t3a, t2 |
| Hoher Arbeitsspeicher (Z/X) | z1d, x8g, x2gd |
| Speicheroptimiert (I/D) | i8ge, i7i, i8g, i7ie, i4g, i4i, i3, i3en, is4gen, d3, d3en, im4gn |
| P/G/Inf/TrnBeschleunigtes Rechnen () | p5, p4d, p4de, p3, p3dn, gr6, g6, g6e, g5g, g5, g4dn, inf2, inf1, trn1, trn1n |
| Hochleistungs-Datenverarbeitung (X2) | x2iezn, x2iedn, x2idn |
Darüber hinaus erstellt der automatische Modus von EKS nur EC2 Instanzen, die die folgenden Anforderungen erfüllen:
+ Mehr als 1 CPU
+ Die Instance-Größe ist nicht Nano, Mikro oder klein
Weitere Informationen finden Sie unter [Benennungskonventionen für EC2 Amazon-Instance-Typen](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html).
## Instance-Metadatenservice
+ Im automatischen Modus von EKS gilt standardmäßig ein IMDSv2 Hop-Limit von 1, was den bewährten AWS Sicherheitsmethoden entspricht.
+ Diese Standardkonfiguration kann im Automatikmodus nicht geändert werden.
+ Geben Sie bei Add-Ons, für die normalerweise IMDS-Zugriff erforderlich ist, während der Installation Parameter (z. B. AWS Region) an, um IMDS-Abfragen zu vermeiden. Weitere Informationen finden Sie unter [Felder für die Anpassung von Amazon-EKS-Add-Ons festlegen](kubernetes-field-management.md).
+ Wenn ein Pod im Automatikmodus unbedingt IMDS-Zugriff benötigt, muss der Pod für die Ausführung mit `hostNetwork: true` konfiguriert werden. Dadurch kann der Pod direkt auf den Instance-Metadaten-Service zugreifen.
+ Berücksichtigen Sie die Sicherheitsauswirkungen, wenn Sie Pods Zugriff auf Instance-Metadaten gewähren.
Weitere Informationen zum Amazon EC2 Instance Metadata Service (IMDS) finden [Sie unter Konfiguration der Optionen für den Instance-Metadaten-Service](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html) im * EC2 Amazon-Benutzerhandbuch*.
## Überlegungen
+ Wenn der konfigurierte flüchtige Speicher in der kleiner NodeClass ist als der NVMe lokale Speicher für die Instance, macht der automatische EKS-Modus eine manuelle Konfiguration überflüssig, indem automatisch die folgenden Aktionen ausgeführt werden:
+ Verwendet ein kleineres (20 GiB) Amazon-EBS-Daten-Volume, um die Kosten zu senken.
+ Formatiert und konfiguriert den NVMe lokalen Speicher für die Verwendung kurzlebiger Daten. Dies beinhaltet die Einrichtung eines RAID 0-Arrays, falls mehrere Laufwerke vorhanden sind. NVMe
+ Wenn `ephemeralStorage.size` die lokale NVMe Kapazität erreicht oder diese überschreitet, werden die folgenden Aktionen ausgeführt:
+ Automatikmodus überspringt das kleine EBS-Volume.
+ Die NVMe Laufwerke sind direkt für Ihre Arbeitslast verfügbar.
+ Der automatische Modus von Amazon EKS unterstützt die folgenden Aktionen des AWS Fault Injection Service nicht:
+ `ec2:RebootInstances`
+ `ec2:SendSpotInstanceInterruptions`
+ `ec2:StartInstances`
+ `ec2:StopInstances`
+ `ec2:TerminateInstances`
+ `ec2:PauseVolumeIO`
+ Amazon EKS Auto Mode unterstützt EKS-Pod-Aktionen des AWS Fault Injection Service. Weitere Informationen finden Sie unter [Managing Fault Injection Service Experiments](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) und [Use the AWS FIS aws:eks:pod actions](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account) im Resilience Hub-Benutzerhandbuch. AWS
+ Sie brauchen das `Neuron Device Plugin` nicht in EKS-Auto-Mode-Knoten zu installieren.
Wenn Sie andere Knotentypen in Ihrem Cluster haben, müssen Sie das Neuron-Geräte-Plugin so konfigurieren, dass es nicht in Knoten im Automatikmodus ausgeführt wird. Weitere Informationen finden Sie unter [Überprüfen, ob eine Workload in Knoten von EKS Auto Mode bereitgestellt wird](associate-workload.md).
# Weitere Informationen zu Identität und Zugriff in EKS Auto Mode
In diesem Thema werden die Rollen und Berechtigungen des Identity and Access Management (IAM) beschrieben, die für die Verwendung von EKS Auto Mode erforderlich sind. EKS Auto Mode verwendet zwei primäre IAM-Rollen: eine Cluster-IAM-Rolle und eine Knoten-IAM-Rolle. Diese Rollen arbeiten in Verbindung mit EKS Pod Identity und EKS-Zugriffseinträgen, um eine umfassende Zugriffsverwaltung für Ihre EKS-Cluster zu gewährleisten.
Wenn Sie den automatischen EKS-Modus konfigurieren, müssen Sie diese IAM-Rollen mit bestimmten Berechtigungen einrichten, die es AWS Diensten ermöglichen, mit Ihren Clusterressourcen zu interagieren. Dazu gehören Berechtigungen für die Verwaltung von Rechenressourcen, Speicher-Volumes, Load Balancern und Netzwerkkomponenten. Das Verständnis dieser Rollenkonfigurationen ist für den ordnungsgemäßen Betrieb und die Sicherheit des Clusters von entscheidender Bedeutung.
Im automatischen EKS-Modus werden AWS IAM-Rollen über EKS-Zugriffseinträge automatisch den Kubernetes-Berechtigungen zugeordnet, sodass keine manuelle Konfiguration oder benutzerdefinierte Bindungen erforderlich sind. `aws-auth` ConfigMaps Wenn Sie einen neuen Auto-Mode-Cluster erstellen, erstellt EKS automatisch die entsprechenden Kubernetes-Berechtigungen mithilfe von Access-Einträgen und stellt so sicher, dass AWS Dienste und Clusterkomponenten sowohl innerhalb des Kubernetes-Autorisierungssystems als auch innerhalb des Kubernetes-Autorisierungssystems über die AWS entsprechenden Zugriffsebenen verfügen. Diese automatisierte Integration reduziert die Komplexität der Konfiguration und trägt dazu bei, Probleme im Zusammenhang mit Berechtigungen zu vermeiden, die bei der Verwaltung von EKS-Clustern häufig auftreten.
## Cluster-IAM-Rolle
Die Cluster-IAM-Rolle ist eine AWS Identity and Access Management (IAM) -Rolle, die von Amazon EKS zur Verwaltung von Berechtigungen für Kubernetes-Cluster verwendet wird. Diese Rolle gewährt Amazon EKS die erforderlichen Berechtigungen für die Interaktion mit anderen AWS Services im Namen Ihres Clusters und wird mithilfe von EKS-Zugriffseinträgen automatisch mit Kubernetes-Berechtigungen konfiguriert.
+ Sie müssen dieser Rolle AWS IAM-Richtlinien zuordnen.
+ EKS Auto Mode weist dieser Rolle automatisch Kubernetes-Berechtigungen mithilfe von EKS-Zugriffseinträgen zu.
+ Schlägt AWS vor, im automatischen Modus von EKS eine einzelne Cluster-IAM-Rolle pro AWS Konto zu erstellen.
+ AWS schlägt vor, diese Rolle `AmazonEKSAutoClusterRole` zu benennen.
+ Diese Rolle erfordert Berechtigungen für mehrere AWS Dienste zur Verwaltung von Ressourcen, einschließlich EBS-Volumes, Elastic Load Balancers und EC2 Instances.
+ Die vorgeschlagene Konfiguration für diese Rolle umfasst mehrere AWS verwaltete IAM-Richtlinien, die sich auf die verschiedenen Funktionen von EKS Auto Mode beziehen.
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
Weitere Informationen zur Cluster-IAM-Rolle und den AWS verwalteten IAM-Richtlinien finden Sie unter:
+ [AWS verwaltete Richtlinien für Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md)
+ [Amazon-EKS-Cluster-IAM-Rolle](cluster-iam-role.md)
Weitere Informationen zum Kubernetes-Zugriff finden Sie unter:
+ [Berechtigungen von Zugriffsrichtlinien überprüfen](access-policy-permissions.md)
## Knoten-IAM-Rolle
Die Node-IAM-Rolle ist eine AWS Identity and Access Management (IAM) -Rolle, die von Amazon EKS verwendet wird, um Berechtigungen für Worker-Knoten in Kubernetes-Clustern zu verwalten. Diese Rolle gewährt EC2 Instances, die als Kubernetes-Knoten ausgeführt werden, die erforderlichen Berechtigungen für die Interaktion mit AWS Diensten und Ressourcen. Sie wird mithilfe von EKS-Zugriffseinträgen automatisch mit Kubernetes-RBAC-Berechtigungen konfiguriert.
+ Sie müssen dieser Rolle IAM-Richtlinien zuordnen AWS .
+ EKS Auto Mode weist dieser Rolle automatisch Kubernetes-RBAC-Berechtigungen zu, indem er EKS-Zugriffseinträge verwendet.
+ AWS schlägt vor, diese Rolle `AmazonEKSAutoNodeRole` zu benennen.
+ Schlägt AWS vor, im automatischen Modus von EKS eine einzelne Node-IAM-Rolle pro AWS Konto zu erstellen.
+ Diese Rolle verfügt über eingeschränkte Berechtigungen. Zu den wichtigsten Berechtigungen gehören das Übernehmen einer Pod-Identity-Rolle und das Abrufen von Images aus ECR.
+ AWS schlägt die folgenden AWS verwalteten IAM-Richtlinien vor:
+ `AmazonEKSWorkerNodeMinimalPolicy`
+ `AmazonEC2ContainerRegistryPullOnly`
Weitere Informationen zur Cluster-IAM-Rolle und zu AWS verwalteten IAM-Richtlinien finden Sie unter:
+ [AWS verwaltete Richtlinien für Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md)
+ [Amazon-EKS-Knoten-IAM-Rolle](create-node-role.md)
Weitere Informationen zum Kubernetes-Zugriff finden Sie unter:
+ [Berechtigungen von Zugriffsrichtlinien überprüfen](access-policy-permissions.md)
## Servicegebundene Rolle
Amazon EKS verwendet für bestimmte Vorgänge eine serviceverknüpfte Rolle (SLR). Eine servicegebundene Rolle ist eine einzigartige Art von IAM-Rolle, die direkt mit Amazon EKS verknüpft ist. Servicebezogene Rollen sind von Amazon EKS vordefiniert und beinhalten alle Berechtigungen, die der Service benötigt, um andere AWS Services in Ihrem Namen aufzurufen.
AWS erstellt und konfiguriert die Spiegelreflexkamera automatisch. Sie können eine SLR erst löschen, nachdem Sie die zugehörigen Ressourcen gelöscht haben. Dies schützt Ihre Amazon-EKS-Ressourcen, da Sie nicht versehentlich die Zugriffsberechtigung für die Ressourcen entfernen können.
Die SLR-Richtlinie gewährt Amazon EKS die Erlaubnis, zentrale Infrastrukturkomponenten zu beobachten und zu löschen: EC2 Ressourcen (Instances, Netzwerkschnittstellen, Sicherheitsgruppen), ELB-Ressourcen (Load Balancer, Zielgruppen), CloudWatch Funktionen (Protokollierung und Metriken) und IAM-Rollen mit dem Präfix „eks“. Sie ermöglicht auch private Endpunktnetzwerke durch VPC/hosted Zonenzuweisung und beinhaltet Berechtigungen für die EventBridge Überwachung und Bereinigung von mit EKS markierten Ressourcen.
Weitere Informationen finden Sie unter:
+ [AWS verwaltete Richtlinie: Amazon EKSService RolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy)
+ [Serviceverknüpfte Rollenberechtigungen für Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks)
## Benutzerdefinierte AWS Tags für EKS Auto-Ressourcen
Standardmäßig erlauben die verwalteten Richtlinien im Zusammenhang mit dem automatischen Modus von EKS nicht das Anwenden von benutzerdefinierten Tags auf im automatischen Modus bereitgestellte AWS Ressourcen. Wenn Sie benutzerdefinierte Tags auf AWS Ressourcen anwenden möchten, müssen Sie der Cluster-IAM-Rolle zusätzliche Berechtigungen zuweisen, die über ausreichende Berechtigungen verfügen, um Tags auf AWS Ressourcen zu erstellen und zu ändern. Nachfolgend finden Sie ein Beispiel für eine Richtlinie, die uneingeschränkten Zugriff auf Tags gewährt:
### Beispiel für eine benutzerdefinierte Tag-Richtlinie anzeigen
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Compute",
"Effect": "Allow",
"Action": [
"ec2:CreateFleet",
"ec2:RunInstances",
"ec2:CreateLaunchTemplate"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-node-class-name": "*",
"aws:RequestTag/eks:kubernetes-node-pool-name": "*"
}
}
},
{
"Sid": "Storage",
"Effect": "Allow",
"Action": [
"ec2:CreateVolume",
"ec2:CreateSnapshot"
],
"Resource": [
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:snapshot/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "Networking",
"Effect": "Allow",
"Action": "ec2:CreateNetworkInterface",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-cni-node-name": "*"
}
}
},
{
"Sid": "LoadBalancer",
"Effect": "Allow",
"Action": [
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateRule",
"ec2:CreateSecurityGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldProtection",
"Effect": "Allow",
"Action": [
"shield:CreateProtection"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldTagResource",
"Effect": "Allow",
"Action": [
"shield:TagResource"
],
"Resource": "arn:aws:shield::*:protection/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
}
]
}
```
## Zugriffsrichtlinien-Referenz
Weitere Informationen zu den von EKS Auto Mode verwendeten Kubernetes-Berechtigungen finden Sie unter [Berechtigungen von Zugriffsrichtlinien überprüfen](access-policy-permissions.md).
# Weitere Informationen zu VPC-Netzwerke und Load Balancing in EKS Auto Mode
In diesem Thema wird erläutert, wie Sie die Netzwerk- und Load-Balancer-Features der Virtual Private Cloud (VPC) in EKS Auto Mode konfigurieren. Obwohl EKS Auto Mode die meisten Netzwerkkomponenten automatisch verwaltet, können Sie bestimmte Aspekte der Netzwerkkonfiguration Ihres Clusters dennoch über `NodeClass`-Ressourcen und Load-Balancer-Annotationen anpassen.
Wenn Sie EKS Auto Mode verwenden, AWS verwaltet es die VPC Container Network Interface (CNI) -Konfiguration und die Load Balancer-Bereitstellung für Ihren Cluster. Sie können das Netzwerkverhalten beeinflussen, indem Sie `NodeClass`-Objekte definieren und bestimmte Annotationen auf Ihre Service- und Ingress-Ressourcen anwenden, während Sie gleichzeitig das automatisierte Betriebsmodell beibehalten, das EKS Auto Mode bereitstellt.
## Netzwerkfähigkeit
EKS Auto Mode verfügt über eine neue Netzwerkfunktion, die das Netzwerk von Knoten und Pods verwaltet. Sie können es konfigurieren, indem Sie ein `NodeClass`-Kubernetes-Objekt erstellen.
Die Konfigurationsoptionen für das vorherige AWS VPC-CNI gelten nicht für den EKS-Automatikmodus.
### Konfiguration des Netzwerks mit einer `NodeClass`
Die `NodeClass`-Ressource in EKS Auto Mode ermöglicht es Ihnen, bestimmte Aspekte der Netzwerkfunktionen anzupassen. Über `NodeClass` können Sie Sicherheitsgruppen auswählen, die Platzierung von Knoten in VPC-Subnetzen steuern, SNAT-Richtlinien festlegen, Netzwerkrichtlinien konfigurieren und die Protokollierung von Netzwerkereignissen aktivieren. Dieser Ansatz behält das automatisierte Betriebsmodell von EKS Auto Mode bei und bietet gleichzeitig Flexibilität für die Anpassung des Netzwerks.
Sie können eine `NodeClass` verwenden, um:
+ Sicherheitsgruppe für Knoten auswählen
+ Steuern, wie Knoten in VPC-Subnetzen platziert werden
+ SNAT-Richtlinie für den Knoten auf `random` oder `disabled` festlegen
+ Aktivieren Sie die *Kubernetes-Netzwerkrichtlinien*, einschließlich:
+ Einstellen der Netzwerkrichtlinie auf „Standardmäßig ablehnen“ oder „Standardmäßig zulassen“
+ Aktivieren Sie die Protokollierung von Netzwerkereignissen in einer Datei.
+ Trennen Sie den Pod-Datenverkehr vom Knotendatenverkehr, indem Sie Pods an verschiedene Subnetze anfügen.
Erfahren Sie, wie Sie [ein Amazon EKS erstellen NodeClass](create-node-class.md).
### Überlegungen
EKS Auto Mode unterstützt:
+ EKS-Netzwerkrichtlinien.
+ Die `HostPort`- und `HostNetwork`-Optionen für Kubernetes-Pods.
+ Knoten und Pods in öffentlichen oder privaten Subnetzen.
+ Zwischenspeichern von DNS-Abfragen auf dem Knoten.
EKS Auto Mode unterstützt Folgendes **nicht**:
+ Sicherheitsgruppen pro Pod (SGPP). Um separate Sicherheitsgruppen auf den Pod-Verkehr im Auto-Modus anzuwenden, verwenden Sie `NodeClass` stattdessen `podSecurityGroupSelectorTerms` in. Weitere Informationen finden Sie unter [Separate Subnetze und Sicherheitsgruppen für Pods](create-node-class.md#pod-subnet-selector).
+ Benutzerdefinierte Netzwerke in `ENIConfig`. Sie können Pods in mehreren Subnetzen platzieren oder sie mit [Separate Subnetze und Sicherheitsgruppen für Pods](create-node-class.md#pod-subnet-selector) exklusiv vom Knoten-Datenverkehr isolieren.
+ Warm-IP-, Warm-Präfix- und Warm-ENI-Konfigurationen.
+ Konfiguration für minimale IP-Ziele.
+ Andere Konfigurationen, die von der AWS Open-Source-VPC CNI unterstützt werden.
+ Konfigurationen der Netzwerkrichtlinien, wie beispielsweise die Anpassung des Conntrack-Timers (Standardwert ist 300 Sekunden).
+ Netzwerkereignisprotokolle exportieren nach. CloudWatch
### Netzwerk-Ressourcenmanagement
Der automatische Modus von EKS kümmert sich um die Verwaltung von Präfixen, IP-Adressen und Netzwerkschnittstellen, indem er die NodeClass Ressourcen für Netzwerkkonfigurationen überwacht. Der Service führt mehrere wichtige Vorgänge automatisch aus:
**Präfix-Delegierung**
Der automatische Modus von EKS verwendet standardmäßig die Präfix-Delegierung (/28-Präfixe) für Pod-Netzwerke und verwaltet einen vordefinierten Warmpool von IP-Ressourcen, der auf der Grundlage der Anzahl der geplanten Pods skaliert wird. Wenn eine Fragmentierung des Pod-Subnetzes erkannt wird, stellt der automatische Modus sekundäre IP-Adressen (/32) bereit. Aufgrund dieses standardmäßigen Pod-Netzwerkalgorithmus berechnet der automatische Modus die maximale Anzahl von Pods pro Knoten auf der Grundlage der Anzahl ENIs und der IPs unterstützten pro Instanztyp (wobei der schlimmste Fall der Fragmentierung vorausgesetzt wird). Weitere Informationen zu Max ENIs und IPs pro Instance-Typ finden Sie unter [Maximale IP-Adressen pro Netzwerkschnittstelle](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html) im EC2-Benutzerhandbuch. Die Anzahl der Instance-Familien der neueren Generation (Nitro v6 und höher) wurde generell IPs pro Instance-Typ erhöht, ENIs und der automatische Modus passt die Berechnung der maximalen Anzahl an Pods entsprechend an.
Für IPv6 Cluster wird nur die Präfix-Delegierung verwendet, und der automatische Modus verwendet immer ein maximales Pod-Limit von 110 Pods pro Knoten.
**Abkühlungs-Management**
Der Dienst implementiert einen Cooldown-Pool für Präfixe oder sekundäre IPv4 Adressen, die nicht mehr verwendet werden. Nach Ablauf der Ruhephase werden diese Ressourcen wieder an die VPC zurückgegeben. Wenn Pods diese Ressourcen jedoch während der Ruhephase wiederverwenden, werden sie aus dem Abkühlungs-Pool wiederhergestellt.
**IPv6 Support**
Für IPv6 Cluster stellt EKS Auto Mode ein `/80` IPv6 Präfix pro Knoten auf der primären Netzwerkschnittstelle bereit. Bei Verwendung `podSubnetSelectorTerms` wird das Präfix stattdessen einer sekundären Netzwerkschnittstelle im Pod-Subnetz zugewiesen.
Der Service gewährleistet außerdem die ordnungsgemäße Verwaltung und Garbage Collection aller Netzwerkschnittstellen.
## Lastausgleich
Sie konfigurieren AWS Elastic Load Balancer, die vom EKS Auto Mode bereitgestellt werden, mithilfe von Anmerkungen zu Service- und Ingress-Ressourcen.
Für weitere Informationen siehe [Erstellen Sie einen IngressClass , um einen Application Load Balancer zu konfigurieren](auto-configure-alb.md) oder [Verwendung von Service-Annotationen zur Konfiguration von Network Load Balancers](auto-configure-nlb.md).
### Überlegungen zum Load Balancing mit EKS Auto Mode
+ Der Standard- Zielmodus ist der IP-Modus, nicht der Instance-Modus.
+ EKS Auto Mode unterstützt nur den Sicherheitsgruppenmodus für Network Load Balancers.
+ AWS unterstützt nicht die Migration von Load Balancern vom selbstverwalteten AWS Load Balancer-Controller zur Verwaltung durch EKS Auto Mode.
+ Das Feld `networking.ingress.ipBlock` wird in der `TargetGroupBinding`-Spezifikation nicht unterstützt.
+ Wenn Ihre Worker-Knoten benutzerdefinierte Sicherheitsgruppen verwenden (kein `eks-cluster-sg- `-Benennungsmuster), benötigt Ihre Cluster-Rolle zusätzliche IAM-Berechtigungen. Die standardmäßige von EKS verwaltete Richtlinie berechtigt EKS lediglich zur Änderung von Sicherheitsgruppen mit dem Namen `eks-cluster-sg-`. Ohne die Erlaubnis, Ihre benutzerdefinierten Sicherheitsgruppen zu ändern, kann EKS die erforderlichen Eingangsregeln nicht hinzufügen, die es ermöglichen, dass der ALB/NLB Datenverkehr Ihre Pods erreicht.
#### Überlegungen zu CoreDNS
Der automatische EKS-Modus verwendet nicht die herkömmliche CoreDNS-Bereitstellung, um die DNS-Auflösung innerhalb des Clusters bereitzustellen. Stattdessen verwenden Auto-Mode-Knoten CoreDNS, das als Systemdienst direkt auf jedem Knoten ausgeführt wird. Wenn Sie einen herkömmlichen Cluster in den automatischen Modus umstellen, können Sie die CoreDNS-Bereitstellung aus Ihrem Cluster entfernen, sobald Ihre Workloads auf die Knoten im automatischen Modus verschoben wurden.
**Wichtig**
Wenn Sie planen, einen Cluster mit Knoten im automatischen Modus und ohne automatischen Modus zu verwalten, müssen Sie die CoreDNS-Bereitstellung beibehalten. Knoten ohne automatischen Modus verlassen sich bei der DNS-Auflösung auf die CoreDNS CoreDNS-Pods, da sie nicht auf den DNS-Dienst auf Knotenebene zugreifen können, den der automatische Modus bereitstellt.
# Beobachtbarkeit für den EKS-Automatikmodus
In diesem Kapitel erfahren Sie mehr über Observability-Optionen für Amazon EKS Auto Mode-Cluster.
**Topics**
+ [
# Zugriff auf AWS verwaltete Komponentenprotokolle für EKS Auto
](auto-managed-component-logs.md)
# Zugriff auf AWS verwaltete Komponentenprotokolle für EKS Auto
Sie können über den automatischen Modus von EKS auf die AWS verwalteten Komponentenprotokolle zugreifen, um einen tieferen Einblick in Ihre Clustervorgänge zu erhalten. Der automatische Modus von EKS unterstützt Protokolle für die folgenden Quellen:
+ Automatische Skalierung berechnen - Karpenter
+ Blockspeicher — EBS CSI
+ Lastenausgleich - AWS Load Balancer Controller
+ Pod-Netzwerke — VPC CNI IP-Adressverwaltung
Protokolle können an ein [Lieferziel](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html) Ihrer Wahl geliefert werden.
Wenn Sie einen EKS-Auto-Cluster erstellen, haben Sie die Möglichkeit, die Protokollierung auf der Kontrollebene (API-Server, Audit, Authenticator, Controller-Manager, Scheduler) zu aktivieren. Automatisch verwaltete EKS-Komponentenprotokolle (wie Compute, Block Storage, Load Balancing und IPAM) erfordern eine separate Konfiguration bei der Protokollzustellung.
## Einrichten der Protokollbereitstellung
Verwenden Sie die Amazon Logs API, um die Bereitstellung von AWS-verwalteten CloudWatch Komponenten-Protokollen für Ihren EKS-Auto-Mode-Cluster zu konfigurieren. Eine ausführliche Anleitung zur Einrichtung finden Sie unter [Aktivieren der Protokollierung von AWS Diensten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-vended-logs-permissions-V2.html) im Amazon CloudWatch Logs-Benutzerhandbuch. Jede Funktion im automatischen Modus kann als individuelle Lieferquelle für CloudWatch Vending Logs konfiguriert werden, sodass Sie auswählen können, auf welche Protokolle Sie Zugriff haben möchten.
Der automatische Modus von EKS unterstützt die folgenden Protokolltypen:
+ **AUTO\$1MODE\$1COMPUTE\$1LOGS**
+ **AUTO\$1MODE\$1BLOCK\$1STORAGE\$1LOGS**
+ **AUTO\$1MODE\$1LOAD\$1BALANCING\$1LOGS**
+ **AUTO\$1MODE\$1IPAM\$1LOGS**
### Amazon verwenden CloudWatch APIs
Die Einrichtung der Protokollierung erfordert drei Schritte:
1. Erstellen Sie mithilfe der CloudWatch PutDeliverySource API eine Bereitstellungsquelle für die Funktion
1. Erstellen Sie ein Lieferziel mit PutDeliveryDestination
1. Erstellen Sie eine Lieferung, um die Quelle und das Ziel zu verbinden, indem Sie CreateDelivery
Sie können die Details des Ziels für die Protokolle des automatischen Modus mithilfe des deliveryDestinationConfiguration Objekts in der CloudWatch PutDeliveryDestination API konfigurieren. Es benötigt den ARN einer CloudWatch Protokollgruppe, eines S3-Buckets oder eines Kinesis Data Firehose Firehose-Lieferstreams.
Sie können eine einzelne Funktion im automatischen Modus (Zustellungsquelle) konfigurieren, um Protokolle an mehrere Ziele zu senden, indem Sie mehrere Lieferungen erstellen. Sie können auch mehrere Lieferungen erstellen, um mehrere Zustellungsquellen so zu konfigurieren, dass Protokolle an dasselbe Lieferziel gesendet werden.
### IAM-Berechtigungen
Je nach ausgewähltem Ziel müssen Sie möglicherweise IAM-Richtlinien oder -Rollen für die CloudWatch Protokollgruppe, den S3-Bucket und Kinesis Data Firehose konfigurieren, um eine erfolgreiche Protokollzustellung sicherzustellen. Wenn Sie Protokolle AWS kontenübergreifend senden, müssen Sie außerdem die PutDeliveryDestinationPolicy API verwenden, um eine IAM-Richtlinie zu konfigurieren, die die Übermittlung an das Ziel ermöglicht. Weitere Informationen finden Sie in der [Dokumentation zu den Berechtigungen von CloudWatch Vending Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-CloudWatchLogs).
## Ihre Logs einsehen
Sobald die Protokollzustellung konfiguriert ist, werden die Protokolle an das von Ihnen angegebene Ziel gesendet. Die Methode für den Zugriff auf Protokolle hängt von Ihrem ausgewählten Zieltyp ab:
+ **CloudWatch Logs** — Logs in der CloudWatch Logs-Konsole anzeigen, AWS CLI-Befehle verwenden oder Abfragen mit CloudWatch Logs Insights durchführen
+ **Amazon S3** — Greifen Sie über die S3-Konsole, AWS CLI oder Analysetools wie Amazon Athena auf Protokolle als Objekte in Ihrem S3-Bucket zu
+ **Amazon Data Firehose** — Protokolle werden an Ihr konfiguriertes Firehose-Ziel gestreamt (wie S3, OpenSearch Service, Redshift usw.)
## Preisgestaltung
CloudWatch Für die Lieferung und Lagerung von Protokollen fallen Gebühren von Vending Logs an, die auf dem von Ihnen ausgewählten Lieferziel basieren. CloudWatch Vending Logs ermöglicht eine zuverlässige und sichere Protokollzustellung mit integrierter AWS Authentifizierung und Autorisierung zu einem reduzierten Preis im Vergleich zu CloudWatch Standard-Logs. Weitere Informationen finden Sie im [Abschnitt Vending Logs auf der CloudWatch Preisseite](https://aws.amazon.com/cloudwatch/pricing/).
### Verwandte Ressourcen
+ [Amazon-EKS-Steuerebenen-Protokollierung](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)
+ [PutDeliverySource API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html) in der CloudWatch Logs-API-Referenz
+ [PutDeliveryDestination API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html) in der CloudWatch Logs-API-Referenz
+ [CreateDelivery API](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) in der CloudWatch Logs-API-Referenz
# Fehlerbehebung mit EKS Auto Mode
AWS Übernimmt mit dem automatischen Modus von EKS mehr Verantwortung für EC2-Instances in Ihrem AWS Konto. EKS übernimmt die Verantwortung für die Container-Laufzeit auf den Knoten, das Betriebssystem auf den Knoten und bestimmte Controller. Dazu gehören ein Blockspeicher-Controller, ein Load-Balancing-Controller und ein Compute-Controller.
Sie müssen Kubernetes verwenden AWS , um Fehler bei Knoten APIs zu beheben. Sie können:
+ Verwenden Sie eine Kubernetes-`NodeDiagnostic`-Ressource, um Knotenprotokolle mithilfe von [Knotenüberwachungsagent](#auto-node-monitoring-agent) abzurufen. Weitere Schritte finden Sie unter [Abrufen von Knotenprotokollen für einen verwalteten Knoten mithilfe von kubectl und S3](auto-get-logs.md).
+ Verwenden Sie den AWS EC2-CLI-Befehl`get-console-output`, um die Konsolenausgabe von Knoten abzurufen. Weitere Schritte finden Sie unter [Rufen Sie mithilfe der EC2-CLI die Konsolenausgabe von einer verwalteten AWS EC2-Instance ab](#auto-node-console).
+ Verwenden Sie *Debugging-Container* von Kubernetes, um Knotenprotokolle abzurufen. Weitere Schritte finden Sie unter [Knotenprotokolle mithilfe von *Debug-Containern* und der `kubectl`-CLI abrufen](#auto-node-debug-logs).
**Anmerkung**
EKS Auto Mode nutzt von verwaltete EC2-Instances. Sie können nicht direkt auf verwaltete EC2-Instances zugreifen, auch nicht über SSH.
Möglicherweise treten die folgenden Probleme auf, für die es spezifische Lösungen für EKS-Auto-Mode-Komponenten gibt:
+ Pods, die im Status `Pending` hängen geblieben sind und nicht auf Knoten im Automatikmodus geplant werden. Lösungen finden Sie unter [Fehlerbehebung bei fehlgeschlagener Pod-Planung in Knoten im Automatikmodus](#auto-troubleshoot-schedule).
+ Verwaltete EC2-Instances, die nicht als Kubernetes-Knoten dem Cluster beitreten. Lösungen finden Sie unter [Fehlerbehebung für Knoten, die nicht dem Cluster beitreten](#auto-troubleshoot-join).
+ Fehler und Probleme mit `NodePools`, `PersistentVolumes` und `Services`, welche die im EKS Auto Mode enthaltenen Controller verwenden. Lösungen finden Sie unter [Fehlerbehebung für im Automatikmodus enthaltene Controller](#auto-troubleshoot-controllers).
+ Die verbesserte Pod-Sicherheit verhindert die gemeinsame Nutzung von Volumes über Pods hinweg. Lösungen finden Sie unter [Freigabe von Volumes über Pods hinweg](#auto-troubleshoot-share-pod-volumes).
Sie können die folgenden Methoden zur Fehlerbehebung bei EKS-Auto-Mode-Komponenten anwenden:
+ [Rufen Sie mithilfe der EC2-CLI die Konsolenausgabe von einer verwalteten AWS EC2-Instance ab](#auto-node-console)
+ [Knotenprotokolle mithilfe von *Debug-Containern* und der `kubectl`-CLI abrufen](#auto-node-debug-logs)
+ [Zeigen Sie die mit EKS Auto Mode verknüpften Ressourcen in der AWS Konsole an](#auto-node-ec2-web)
+ [IAM-Fehler in Ihrem AWS Konto anzeigen](#auto-node-iam)
+ [Erkennung von Problemen mit der Knotenkonnektivität mit `VPC Reachability Analyzer`](#auto-node-reachability)
## Knotenüberwachungsagent
EKS Auto Mode umfasst den Amazon-EKS-Knoten-Überwachungsagent. Mit diesem Agenten können Sie Informationen zur Fehlerbehebung und zum Debugging von Knoten anzeigen. Der Knoten-Überwachungsagent veröffentlicht Kubernetes `events` und Knoten `conditions`. Weitere Informationen finden Sie unter [Erkennen Sie Probleme mit dem Knotenstatus und aktivieren Sie die automatische Knotenreparatur](node-health.md).
## Rufen Sie mithilfe der EC2-CLI die Konsolenausgabe von einer verwalteten AWS EC2-Instance ab
Dieses Verfahren unterstützt bei der Fehlerbehebung von Problemen beim Systemstart oder auf Kernel-Ebene.
Zunächst müssen Sie die EC2-Instance-ID der Instance ermitteln, die Ihrer Workload zugeordnet ist. Verwenden Sie zweitens die AWS CLI, um die Konsolenausgabe abzurufen.
1. Bestätigen Sie, dass Sie `kubectl` installiert und mit Ihrem Cluster verbunden haben
1. (Optional) Namen einer Kubernetes-Bereitstellung für die Auflistung der zugehörigen Pods verwenden
```
kubectl get pods -l app=
```
1. Verwenden Sie den Namen des Kubernetes-Pods, um die EC2-Instance-ID des zugehörigen Knotens zu ermitteln.
```
kubectl get pod -o wide
```
1. Verwenden Sie die EC2-Instance-ID, um die Konsolenausgabe abzurufen.
```
aws ec2 get-console-output --instance-id --latest --output text
```
## Knotenprotokolle mithilfe von *Debug-Containern* und der `kubectl`-CLI abrufen
Die empfohlene Methode zum Abrufen von Protokollen von einem EKS-Auto-Mode-Knoten ist die Verwendung der `NodeDiagnostic`-Ressource. Diese Schritte finden Sie unter [Abrufen von Knotenprotokollen für einen verwalteten Knoten mithilfe von kubectl und S3](auto-get-logs.md).
Sie können Protokolle jedoch auch live von einer Instance streamen, indem Sie den Befehl `kubectl debug node` verwenden. Dieser Befehl startet einen neuen Pod auf dem Knoten, den Sie debuggen möchten, und den Sie dann interaktiv verwenden können.
1. Starten Sie einen Debug-Container. Der folgende Befehl verwendet `i-01234567890123456` für die Instance-ID des Knotens, `-it` weist `tty` zu und fügt `stdin` für die interaktive Verwendung an und verwendet das `sysadmin`-Profil aus der kubeconfig-Datei.
```
kubectl debug node/i-01234567890123456 -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023
```
Eine Beispielausgabe sieht wie folgt aus.
```
Creating debugging pod node-debugger-i-01234567890123456-nxb9c with container debugger on node i-01234567890123456.
If you don't see a command prompt, try pressing enter.
bash-5.2#
```
1. Von der Shell aus können Sie nun `util-linux-core` installieren, das den Befehl `nsenter` bereitstellt. Verwenden Sie `nsenter`, um den Mount-Namespace von PID 1 (`init`) auf dem Host aufzurufen, und führen Sie den Befehl `journalctl` aus, um Protokolle von `kubelet` zu streamen:
```
yum install -y util-linux-core
nsenter -t 1 -m journalctl -f -u kubelet
```
Aus Sicherheitsgründen installiert das Amazon-Linux-Container-Image standardmäßig nicht viele Binärdateien. Mit dem Befehl `yum whatprovides` können Sie das Paket identifizieren, das installiert werden muss, um eine bestimmte Binärdatei bereitzustellen.
```
yum whatprovides ps
```
```
Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025.
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : @System
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : amazonlinux
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
```
## Zeigen Sie die mit EKS Auto Mode verknüpften Ressourcen in der AWS Konsole an
Sie können die AWS Konsole verwenden, um den Status der Ressourcen anzuzeigen, die Ihrem EKS-Auto-Mode-Cluster zugeordnet sind.
+ [EBS-Volumes](https://console.aws.amazon.com/ec2/home#Volumes)
+ Anzeigen der EKS-Auto-Mode-Volumes durch Suche nach dem Tag-Schlüssel `eks:eks-cluster-name`
+ [Load Balancer](https://console.aws.amazon.com/ec2/home#LoadBalancers)
+ Anzeigen der Load Balancer in EKS Auto Mode durch Suche nach dem Tag-Schlüssel `eks:eks-cluster-name`
+ [EC2-Instances](https://console.aws.amazon.com/ec2/home#Instances)
+ Anzeigen der EKS-Auto-Mode-Instances durch Suche nach dem Tag-Schlüssel `eks:eks-cluster-name`
## IAM-Fehler in Ihrem AWS Konto anzeigen
1. Navigieren Sie zur Konsole CloudTrail
1. Auswahl von „Ereignisverlauf“ im linken Navigationsbereich
1. Fehlercode-Filter anwenden:
+ AccessDenied
+ UnauthorizedOperation
+ InvalidClientTokenId
Suchen Sie nach Fehlern im Zusammenhang mit Ihrem EKS-Cluster. Verwenden Sie die Fehlermeldungen, um Ihre EKS-Zugriffseinträge, die Cluster-IAM-Rolle oder die Knoten-IAM-Rolle zu aktualisieren. Möglicherweise müssen Sie diesen Rollen eine neue Richtlinie mit Berechtigungen für den EKS-Automodus zuordnen.
## Fehlerbehebung bei fehlgeschlagener Pod-Planung in Knoten im Automatikmodus
Wenn Pods im `Pending`-Status verbleiben und nicht auf einen Automatikmodus-Knoten geplant werden, überprüfen Sie, ob Ihr Pod- oder Bereitstellungs-Manifest ein `nodeSelector` enthält. Wenn `nodeSelector` vorhanden ist, stellen Sie sicher, dass `eks.amazonaws.com/compute-type: auto` verwendet wird, um auf Knoten geplant zu werden, die von EKS Auto Mode erstellt wurden. Weitere Informationen zu den Knotenbezeichnungen, die von EKS Auto Mode verwendet werden, finden Sie unter [Überprüfen, ob eine Workload in Knoten von EKS Auto Mode bereitgestellt wird](associate-workload.md).
## Fehlerbehebung für Knoten, die nicht dem Cluster beitreten
EKS Auto Mode konfiguriert neue EC2-Instances automatisch mit den korrekten Informationen für den Beitritt zum Cluster, einschließlich des Cluster-Endpunkts und der Cluster-Zertifizierungsstelle (CA). Es kann jedoch vorkommen, dass diese Instances dennoch nicht als Knoten dem EKS-Cluster beitreten können. Führen Sie die folgenden Befehle aus, um Instances, die nicht dem Cluster beigetreten sind, zu identifizieren:
1. Führen Sie `kubectl get nodeclaim` aus, um nach `NodeClaims` zu suchen, die `Ready = False` sind.
```
kubectl get nodeclaim
```
1. Führen Sie `kubectl describe nodeclaim ` aus und überprüfen Sie unter **Status**, ob Probleme vorliegen, die den Knoten daran hindern, dem Cluster beizutreten.
```
kubectl describe nodeclaim
```
**Gängige Fehlermeldungen:**
`Error getting launch template configs`
Dieser Fehler kann auftreten, wenn Sie benutzerdefinierte Tags im `NodeClass` mit den Standardberechtigungen der Cluster-IAM-Rolle festlegen. Siehe [Weitere Informationen zu Identität und Zugriff in EKS Auto Mode](auto-learn-iam.md).
`Error creating fleet`
Möglicherweise liegt ein Autorisierungsproblem beim `RunInstances`-Aufruf der EC2-API vor. AWS CloudTrail Suchen Sie nach Fehlern und [IAM-Rolle für Cluster von Amazon EKS Auto Mode](auto-cluster-iam-role.md) nach den erforderlichen IAM-Berechtigungen.
### Erkennung von Problemen mit der Knotenkonnektivität mit `VPC Reachability Analyzer`
**Anmerkung**
Für jede Analyse, die mit dem VPC Reachability Analyzer durchgeführt wird, wird Ihnen eine Gebühr berechnet. Details zu den Preisen finden Sie unter [Amazon-VPC-Preise](https://aws.amazon.com/vpc/pricing/).
Ein Grund dafür, dass eine Instance dem Cluster nicht beigetreten ist, ist ein Problem mit der Netzwerkkonnektivität, das sie daran hindert, den API-Server zu erreichen. Zur Diagnose dieses Problems können Sie mit dem [VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) die Konnektivität zwischen einem Knoten, der dem Cluster nicht beitreten kann, und dem API-Server analysieren. Sie benötigen zwei Informationen:
+ **Instance-ID** eines Knotens, der dem Cluster nicht beitreten kann
+ IP-Adresse des **Kubernetes-API-Server-Endpunkts**
Um die **Instance-ID** zu erhalten, müssen Sie eine Workload auf dem Cluster erstellen, damit EKS Auto Mode eine EC2-Instance startet. Dadurch wird auch ein `NodeClaim`-Objekt in Ihrem Cluster erstellt, das die Instance-ID enthält. Führen Sie `kubectl get nodeclaim -o yaml` aus, um alle `NodeClaims` in Ihrem Cluster auszudrucken. Jedes `NodeClaim` enthält die Instance-ID als Feld und erneut in der providerID:
```
kubectl get nodeclaim -o yaml
```
Eine Beispielausgabe sieht wie folgt aus.
```
nodeName: i-01234567890123456
providerID: aws:///us-west-2a/i-01234567890123456
```
Sie können Ihren **Kubernetes-API-Server-Endpunkt** ermitteln, indem Sie `kubectl get endpoint kubernetes -o yaml` ausführen. Die Adressen befinden sich im Adressfeld:
```
kubectl get endpoints kubernetes -o yaml
```
Eine Beispielausgabe sieht wie folgt aus.
```
apiVersion: v1
kind: Endpoints
metadata:
name: kubernetes
namespace: default
subsets:
- addresses:
- ip: 10.0.143.233
- ip: 10.0.152.17
ports:
- name: https
port: 443
protocol: TCP
```
Mit diesen beiden Informationen können Sie die S-Analyse durchführen. Navigieren Sie zunächst zum VPC Reachability Analyzer in AWS-Managementkonsole.
1. Klicken Sie auf „Pfad erstellen und analysieren“.
1. Geben Sie einen Namen für die Analyse an (z. B. „Fehler beim Zusammenschluss von Knoten”).
1. Wählen Sie für „Quelltyp“ die Option „Instances“ aus
1. Geben Sie die Instance-ID des fehlerhaften Knotens als „Quelle“ ein
1. Wählen Sie für „Pfadziel“ die Option „IP-Adresse“ aus
1. Geben Sie eine der IP-Adressen für den API-Server als „Zieladresse“ ein
1. Erweitern Sie den Abschnitt „Zusätzliche Konfiguration des Paket-Headers“.
1. Geben Sie als „Zielport“ 443 ein
1. Wählen Sie „Protokoll“ als TCP, falls dies noch nicht ausgewählt ist
1. Klicken Sie auf „Pfad erstellen und analysieren“.
1. Der Test kann einige Minuten in Anspruh nehmen. Wenn die Analyseergebnisse eine fehlgeschlagene Erreichbarkeit anzeigen, wird angegeben, wo der Fehler im Netzwerkpfad aufgetreten ist, sodass Sie das Problem beheben können.
## Freigabe von Volumes über Pods hinweg
EKS-Automodus-Knoten werden SELinux im Modus „Durchsetzen“ konfiguriert, was für mehr Isolation zwischen Pods sorgt, die auf demselben Knoten ausgeführt werden. Wenn diese Option aktiviert SELinux ist, erhalten die meisten nicht privilegierten Pods automatisch ein eigenes Sicherheitslabel (Multi-Category Security, MCS). Dieses MCS-Label ist für jeden Pod einzigartig und soll sicherstellen, dass ein Prozess in einem Pod keinen Prozess in einem anderen Pod oder auf dem Host manipulieren kann. Selbst wenn ein gekennzeichneter Pod als Root ausgeführt wird und Zugriff auf das Host-Dateisystem hat, kann er keine Dateien manipulieren, keine vertraulichen Systemaufrufe im Host ausführen, nicht auf die Container-Laufzeitumgebung zugreifen und kein geheimes Schlüsselmaterial von Kubelet abrufen.
Aus diesem Grund können Probleme auftreten, wenn Sie versuchen, Daten zwischen Pods auszutauschen. Beispielsweise erlaubt ein `PersistentVolumeClaim` mit einem Zugriffsmodus von `ReadWriteOnce` immer noch nicht, dass mehrere Pods gleichzeitig auf das Volume zugreifen.
Um diese Freigabe zwischen Pods zu ermöglichen, können Sie das `seLinuxOptions` des Pods verwenden, um auf diesen Pods dasselbe MCS-Label zu konfigurieren. In diesem Beispiel weisen wir dem Pod die drei Kategorien `c123,c456,c789` zu. Dies steht nicht im Widerspruch zu den Kategorien, die den Pods auf dem Knoten automatisch zugewiesen werden, da ihnen nur zwei Kategorien zugewiesen werden.
```
securityContext:
seLinuxOptions:
level: "s0:c123,c456,c789"
```
## Anzeige von Karpenter-Ereignissen in den Protokollen der Steuerebene
Für EKS-Cluster mit aktivierten Steuerebenen-Protokollen können Sie durch Abfragen der Protokolle Einblicke in die Aktionen und Entscheidungsprozesse von Karpenter gewinnen. Dies kann besonders nützlich sein, um Probleme in EKS Auto Mode im Zusammenhang mit der Bereitstellung, Skalierung und Beendigung von Knoten zu beheben. Verwenden Sie die folgende Logs Insights-Abfrage, um Ereignisse im Zusammenhang mit Karpenter anzuzeigen: CloudWatch
```
fields @timestamp, @message
| filter @logStream like /kube-apiserver-audit/
| filter @message like 'DisruptionBlocked'
or @message like 'DisruptionLaunching'
or @message like 'DisruptionTerminating'
or @message like 'DisruptionWaitingReadiness'
or @message like 'Unconsolidatable'
or @message like 'FailedScheduling'
or @message like 'NoCompatibleInstanceTypes'
or @message like 'NodeRepairBlocked'
or @message like 'Disrupted'
or @message like 'Evicted'
or @message like 'FailedDraining'
or @message like 'TerminationGracePeriodExpiring'
or @message like 'TerminationFailed'
or @message like 'FailedConsistencyCheck'
or @message like 'InsufficientCapacityError'
or @message like 'UnregisteredTaintMissing'
or @message like 'NodeClassNotReady'
| sort @timestamp desc
```
Diese Abfrage filtert nach bestimmten [Karpenter-bezogenen](https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/events/reason.go) Ereignissen in den Überwachungsprotokollen des Kube-API-Servers. Zu den Ereignissen zählen verschiedene Störungszustände, Planungsfehler, Kapazitätsprobleme und knotenbezogene Probleme. Durch die Analyse dieser Protokolle erhalten Sie ein besseres Verständnis für Folgendes:
+ Warum Karpenter bestimmte Maßnahmen ergreift.
+ Alle Probleme, die eine ordnungsgemäße Bereitstellung, Skalierung oder Beendigung von Knoten verhindern.
+ Mögliche Kapazitäts- oder Kompatibilitätsprobleme mit Instance-Typen.
+ Ereignisse im Knoten-Lebenszyklus wie Störungen, Bereinigungen oder Beendigungen.
So verwenden Sie diese Abfrage:
1. Navigieren Sie zur Konsole CloudWatch
1. Wählen Sie im linken Navigationsbereich „Protokolleinblicke“ aus.
1. Wählen Sie die Protokollgruppe für die Protokolle der Steuerebene Ihres EKS-Clusters aus
1. Fügen Sie die Abfrage in den Abfrage-Editor ein
1. Passen Sie den Zeitraum nach Bedarf an
1. Run the query
Die Ergebnisse zeigen Ihnen eine Zeitleiste mit Karpenter-bezogenen Ereignissen, die Ihnen bei der Fehlerbehebung und beim Verständnis des Verhaltens von EKS Auto Mode in Ihrem Cluster behilflich sein können. Um die Aktionen von Karpenter auf einem bestimmten Knoten zu überprüfen, können Sie den folgenden Zeilenfilter mit der Instance-ID zur oben genannten Abfrage hinzufügen:
```
|filter @message like /[.replaceable]`i-12345678910123456`/
```
**Anmerkung**
Um diese Abfrage zu verwenden, muss die Protokollierung der Steuerebene in Ihrem EKS-Cluster aktiviert sein. Falls Sie dies noch nicht getan haben, lesen Sie [Protokolle der Kontrollebene an CloudWatch Logs senden](control-plane-logs.md).
## Fehlerbehebung für im Automatikmodus enthaltene Controller
Bei Problemen mit einem Controller sollten Sie Folgendes prüfen:
+ Ob die dem Controller zugeordneten Ressourcen korrekt formatiert und gültig sind.
+ Wenn die AWS IAM- und Kubernetes-RBAC-Ressourcen für Ihren Cluster ordnungsgemäß konfiguriert sind. Weitere Informationen finden Sie unter [Weitere Informationen zu Identität und Zugriff in EKS Auto Mode](auto-learn-iam.md).
## Zugehörige Ressourcen
In diesen Artikeln von AWS re:POST finden Sie weitere Schritte zur Fehlerbehebung:
+ [Wie behebt man häufige Skalierungsprobleme in EKS Auto Mode?](https://repost.aws/articles/ARLpQOknr5Rb-w5iAT9sUBpQ)
+ [Wie behebt man Probleme bei der Bereitstellung benutzerdefinierter Knoten-Pools und Knotenklassen in Amazon EKS Auto Mode?](https://repost.aws/articles/ARPcmFS1POTgqPCBdcZFp6BQ)
+ [Wie behebt man Probleme mit integrierten Knoten-Pools in EKS Auto Mode, deren Status unbekannt ist?](https://repost.aws/en/articles/ARLhrdl45TRASGkvViwtBG0Q)
# Versionshinweise zu EKS Auto Mode überprüfen
Diese Seite dokumentiert Aktualisierungen von Amazon EKS Auto Mode. Auf dieser Seite finden Sie regelmäßig Ankündigungen zu neuen Features, Fehlerbehebungen, bekannten Problemen und veralteten Funktionen.
Um Benachrichtigungen über alle Änderungen an den Quelldateien dieser spezifischen Dokumentationsseite zu erhalten, können Sie die folgende URL mit einem RSS-Reader abonnieren:
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/automode/auto-change.adoc.atom
```
## 2. Februar 2026
**Feature**: Unterstützung hinzugefügt, um den V4Egress-Verkehr von IPv6 Pods in EKS-Automodus-Clustern zu deaktivieren. IPv6 Weitere Informationen finden Sie unter [Deaktiviert den IPv4 Ausgang von IPv6 Pods in Clustern. IPv6](create-node-class.md#enableV4Egress).
## 19. Dezember 2025
**Feature**: Unterstützung für den sekundären IP-Modus hinzugefügt, der sekundäre IP-Adressen anstelle von Präfixen für Auto-Knoten bereitstellt. In diesem Modus wird eine einzige sekundäre IP als Minimal beibehalten IPTarget und IP-Ressourcen für Kunden eingespart, die keine weiteren sekundären IP-Adressen IPs oder Präfixe aufwärmen müssen. Weitere Informationen erhalten Sie unter [Knotenklassen-Spezifikation](create-node-class.md#auto-node-class-spec) und [Sekundärer IP-Modus für Pods](create-node-class.md#secondary-IP-mode).
## 19. November 2025
**Funktion**: Paralleles Ziehen und Entpacken von Seekable OCI (SOCI) für Instances der G-, P- und Trn-Familie mit lokalem Speicher aktiviert. NVMe SOCI Parallel Pull and Unpack wird für diese Instance-Familien mit EKS Auto Mode immer verwendet, und es sind keine Konfigurationsänderungen erforderlich, um ihn zu aktivieren. Weitere Informationen zu SOCI finden Sie im [Launch-Blog](https://aws.amazon.com/blogs/containers/introducing-seekable-oci-parallel-pull-mode-for-amazon-eks/).
## 19. November 2025
**Feature**: Es wurde Unterstützung für Knotenpools mit statischer Kapazität hinzugefügt, die eine feste Anzahl von Knoten verwalten. Weitere Informationen finden Sie unter [Statische Kapazitätsknotenpools im automatischen EKS-Modus](auto-static-capacity.md).
## 23. Oktober 2025
**Feature:** Benutzer mit Clustern in US-Regionen können jetzt beantragen, FIPS-kompatibel zu verwenden, AMIs indem sie dies `spec.advancedSecurity.fips` in ihrer NodeClass Definition angeben.
## 1. Oktober 2025
**Feature:** Der automatische EKS-Modus unterstützt jetzt die Bereitstellung von Knoten in AWS Local Zones. Weitere Informationen finden Sie unter [Stellen Sie EKS-Automodus-Knoten in Local Zones bereit](auto-local-zone.md).
## 30. September 2025
**Feature:** Unterstützung für InstanceProfile wurde hinzugefügt, NodeClass `spec.instanceProfile` was sich gegenseitig aus dem `spec.role` Feld ausschließt.
## 29. September 2025
DRA wird derzeit nicht vom EKS Auto Mode unterstützt.
## 10. September 2025
**Aufgabe:** Vom Auto-Mode-Compute-Controller ausgelöste Ereignisse verwenden jetzt den Namen `eks-auto-mode/compute` statt `karpenter`.
## 24. August 2025
**Fehlerbehebung:** VPCs Die Verwendung eines DHCP-Optionssatzes mit einem benutzerdefinierten Domainnamen, der Großbuchstaben enthielt, führte dazu, dass Knoten dem Cluster nicht beitreten konnten, da ein ungültiger Hostname generiert wurde. Dieses Problem wurde behoben, und Domain-Namen mit Großbuchstaben funktionieren nun korrekt.
## 15. August 2025
**Fehlerbehebung:** Der Pod Identity Agent überwacht jetzt nur noch die IPv4 Link Local-Adresse in einem IPv4 EKS-Cluster, um Probleme zu vermeiden, bei denen der Pod die Adresse nicht erreichen kann. IPv6
## 06. August 2025
**Feature:** Es wurde eine neue Konfiguration hinzugefügt NodeClass `spec.advancedNetworking.associatePublicIPAddress`, mit der verhindert werden kann, dass öffentliche IP-Adressen EKS-Automodus-Knoten zugewiesen werden
## 30. Juni 2025
**Feature:** Der Auto-Modus verwendet NodeClass jetzt den konfigurierten benutzerdefinierten KMS-Schlüssel, um zusätzlich zum Datenvolumen auch das schreibgeschützte Root-Volume der Instanz zu verschlüsseln. read/write Zuvor wurde der benutzerdefinierte KMS-Schlüssel nur zum Verschlüsseln des Daten-Volumes verwendet.
## 20. Juni 2025
**Feature:** Support für die Steuerung der Bereitstellung von Workloads in EC2 On-Demand-Kapazitätsreservierungen ()ODCRs. Dadurch wird der optionale Schlüssel `capacityReservationSelectorTerms` hinzugefügt NodeClass, sodass Sie explizit steuern können, welche ODCRs Workloads verwenden. Weitere Informationen finden Sie unter [Steuern Sie die Bereitstellung von Workloads in Kapazitätsreservierungen mit EKS Auto Mode.](auto-odcr.md).
## 13. Juni 2025
**Feature:** Unterstützung für separate Pod-Subnetze in `NodeClass`. Dadurch werden die optionalen Schlüssel ``podSubnetSelectorTerms` und `podSecurityGroupSelectorTerms` hinzugefügt, um die Subnetze und Sicherheitsgruppen für die Pods festzulegen. Weitere Informationen finden Sie unter [Separate Subnetze und Sicherheitsgruppen für Pods](create-node-class.md#pod-subnet-selector).
## 30. April 2025
**Feature:** Unterstützung für weitergeleitete Netzwerk-Proxys in `NodeClass`. Dadurch wird der optionale Schlüssel `advancedNetworking` zum Festlegen Ihres HTTPS-Proxys hinzugefügt. Weitere Informationen finden Sie unter [Knotenklassen-Spezifikation](create-node-class.md#auto-node-class-spec).
## 18. April 2025
**Feature:** Unterstützung für die Auflösung von .local-Domains (in der Regel für Multicast-DNS reserviert) über Unicast-DNS.
## 11. April 2025
**Feature:** `certificateBundles` und `ephemeralStorage.kmsKeyID` zu `NodeClass` hinzugefügt. Weitere Informationen finden Sie unter [Knotenklassen-Spezifikation](create-node-class.md#auto-node-class-spec).
**Feature:** Verbesserte Image-Abrufgeschwindigkeit, insbesondere für Instance-Typen mit lokalem Instance-Speicher, welche die schnellere Image-Dekomprimierung nutzen können.
**Fehlerbehebung:** Es wurde ein Race-Problem behoben FailedCreatePodSandBox , das zu einem Fehler beim Wählen führte: dial tcp 127.0.0. 1:50051: connect: connection failed to, was manchmal dazu führte, dass Pods direkt beim Start auf einen Node planten.
## 4. April 2025
**Feature:** `registryPullQPS` von 5 auf 25 und `registryBurst` von 10 auf 50 erhöhen, um die vom Client erzwungene Drosselung des Image-Pulls zu reduzieren (`Failed to pull image xyz: pull QPS exceeded`)
## 31. März 2025
**Fehlerbehebung:** Behebt ein Problem, bei dem, wenn ein Kern-DNS-Pod in einem Knoten im Automatikmodus ausgeführt wird, DNS-Anfragen von Pods auf dem Knoten diesen Kern-DNS-Pod anstelle des lokalen DNS-Servers des Knotens erreichen. DNS-Anfragen von Pods in einem Knoten im Automatikmodus werden nun stets an den lokalen DNS-Server des Knotens weitergeleitet.
## 21. März 2025
**Fehlerbehebung:** Knoten im Automatikmodus lösen `kube-dns.kube-system.svc.cluster.local` nun korrekt auf, wenn kein `kube-dns`-Service im Cluster installiert ist. Behebt GitHub Problem [\$12546](https://github.com/aws/containers-roadmap/issues/2546).
## 14. März 2025
**Feature**: `IPv4`-Ausgang in `IPv6`-Clustern aktiviert. Der `IPv4`-Datenverkehr, der aus `IPv6`-Clustern im Automatikmodus ausgegeben wird, wird nun automatisch in die `v4`-Adresse der primären ENI des Knotens übersetzt.