**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. # Erstellen eines Knotenpools für EKS Auto Mode 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, einschließlich Instanztypen, 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 Kontrolle über die Rechenressourcen Ihres EKS-Clusters durch verschiedene unterstützte Bezeichnungen und Anforderungen. Dazu gehören Optionen für die Angabe 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-specific Labels (mit Präfix`eks.amazonaws.com/`) diese Funktionalität um AWS spezifische Attribute wie Instance-Typen, CPU-Hersteller, GPU-Fähigkeiten und Netzwerkspezifikationen. Dieses standardisierte Kennzeichnungssystem ermöglicht eine nahtlose Integration mit bestehenden Kubernetes-Tools und bietet gleichzeitig eine umfassende Infrastrukturintegration. AWS ## Erstellen Sie ein NodePool Gehen Sie wie folgt vor, um einen NodePool für Ihren Amazon EKS-Cluster zu erstellen: 1. Erstellen Sie eine YAML-Datei `nodepool.yaml` mit dem Namen Ihrer erforderlichen NodePool Konfiguration. Sie können die folgende Beispielkonfiguration verwenden. 1. Wenden Sie das NodePool auf Ihren Cluster an: ``` kubectl apply -f nodepool.yaml ``` 1. Stellen Sie sicher, dass das erfolgreich erstellt NodePool wurde: ``` kubectl get nodepools ``` 1. (Optional) Überwachen Sie den NodePool Status: ``` kubectl describe nodepool default ``` Stellen Sie sicher, dass Ihre NodePool Referenzen gültig sind NodeClass und in Ihrem Cluster vorhanden sind. Das 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 | Description | | --- | --- | --- | | topology.kubernetes. io/zone | us-east-2a | AWS Region | | node.kubernetes. io/instance-Typ | g4dn.8xgroß | AWS Instanztyp | | 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. | | Zimmermann. sh/capacity-Typ | 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-Typ | auto | Identifiziert von EKS Auto Mode verwaltete Knoten | | eks.amazonaws. com/instance-Verschlüsselung bei der Übertragung wird unterstützt | true | Instance-Typen, welche die Verschlüsselung während der Übertragung unterstützen (oder nicht) | | eks.amazonaws. com/instance-Kategorie | 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-Familie | g4dn | Instance-Typen mit ähnlichen Eigenschaften, aber unterschiedlichen Ressourcenmengen | | eks.amazonaws. com/instance-Größe | 8xlarge | Instance-Typen mit ähnlichen Ressourcenmengen, jedoch unterschiedlichen Eigenschaften | | eks.amazonaws. com/instance-Zentralprozessor | 32 | Anzahl der CPUs auf der Instance | | eks.amazonaws. com/instance-CPU-Hersteller | `aws` | Name des CPU-Herstellers | | eks.amazonaws. com/instance-Speicher | 131072 | Anzahl der Mebibyte Speicher auf der Instance | | eks.amazonaws. com/instance-ebs-Bandbreite | 9500 | 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-Netzwerkbandbreite | 131072 | 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-Hersteller | nvidia | Name des GPU-Herstellers | | eks.amazonaws. com/instance-Anzahl der Grafikprozessoren | 1 | Anzahl der GPUs auf der Instance | | eks.amazonaws. com/instance-GPU-Speicher | 16384 | Anzahl der Mebibyte Speicher auf der GPU | | eks.amazonaws. com/instance-lokal-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 Knotenpools erstellen, `default` NodeClass wird dieser nicht automatisch bereitgestellt. Sie müssen einen benutzerdefinierten 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-CLI](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 den EKS-Automodus so konfigurieren, dass er Nodes auf verschiedene NodePool Weise unterbricht. Sie können `spec.disruption.consolidationPolicy`, `spec.disruption.consolidateAfter` oder `spec.template.spec.expireAfter` verwenden. Sie können die Unterbrechung durch den EKS-Automatikmodus auch per Ratenbegrenzung einschränken. NodePool `spec.disruption.budgets` 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 a in einem EKS-Automodus nicht explizit definiert `terminationGracePeriod` ist NodePool, wendet das System automatisch eine standardmäßige Kündigungsfrist von 24 Stunden auf den zugehörigen Modus an NodeClaim. Kunden mit dem automatischen Modus von EKS werden in ihren benutzerdefinierten NodePool Konfigurationen zwar keinen `terminationGracePeriod` Standardwert sehen, aber sie werden diesen Standardwert auf der verwenden. NodeClaim Die Funktionalität bleibt konsistent, unabhängig davon, ob der Kulanzzeitraum explizit auf NodePool oder standardmäßig auf dem festgelegt ist NodeClaim, wodurch ein vorhersehbares Verhalten bei der Knotenbeendigung im gesamten Cluster gewährleistet wird.