Knotenpools mit statischer Kapazität 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 aufrechterhalten. 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.

Einfaches Beispiel

Hier ist ein einfacher Knotenpool mit statischer Kapazität, der 5 Knoten verwaltet:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: my-static-nodepool
spec:
  replicas: 5  # Maintain exactly 5 nodes

  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default

      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["m", "c"]
        - key: "topology.kubernetes.io/zone"
          operator: In
          values: ["us-west-2a", "us-west-2b"]

  limits:
    nodes: 8

Konfigurieren Sie einen Knotenpool mit statischer Kapazität

Um einen Knotenpool mit statischer Kapazität zu erstellen, legen Sie das replicas Feld in Ihrer Spezifikation fest. NodePool Das replicas Feld definiert die genaue Anzahl von Knoten, die der Knotenpool verwalten wird.

Einschränkungen des Knotenpools 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 Pools mit statischer Kapazität werden für eine Konsolidierung auf der Grundlage der Auslastung 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.

Skalieren Sie einen Knotenpool mit statischer Kapazität

Sie können die Anzahl der Replikate in einem Knotenpool mit statischer Kapazität mit dem folgenden Befehl ändern: kubectl scale

# 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.

Beispielkonfigurationen

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 in 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%

Best Practices

Kapazitätsplanung:

• Legen Sie einen limits.nodes höheren Wert als festreplicas, 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 Knotenpools mit statischer Kapazität erstellen, von denen jeder anhand der Anforderung an eine bestimmte Availability Zone gebunden ist. 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.

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