**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. # 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'] ```