Pool di nodi a capacità statica in modalità automatica EKS

La modalità automatica di Amazon EKS supporta pool di nodi a capacità statica che mantengono un numero fisso di nodi indipendentemente dalla domanda del pod. I pool di nodi con capacità statica sono utili per carichi di lavoro che richiedono capacità prevedibile, istanze riservate o requisiti di conformità specifici in cui è necessario mantenere un ingombro dell'infrastruttura coerente.

A differenza dei pool di nodi dinamici che si ridimensionano in base alle richieste di pianificazione dei pod, i pool di nodi con capacità statica mantengono il numero di nodi configurati.

Esempio di base

Ecco un semplice pool di nodi con capacità statica che mantiene 5 nodi:

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

Configurare un pool di nodi con capacità statica

Per creare un pool di nodi con capacità statica, imposta il replicas campo nelle tue specifiche. NodePool Il replicas campo definisce il numero esatto di nodi che il pool di nodi manterrà.

Vincoli del pool di nodi con capacità statica

I pool di nodi con capacità statica presentano diversi vincoli e comportamenti importanti:

Vincoli di configurazione:

• Impossibile cambiare modalità: una volta impostato replicas un pool di nodi, non è possibile rimuoverlo. Il pool di nodi non può passare dalla modalità statica a quella dinamica.

• Limiti di risorse limitati: nella sezione dei limiti è supportato solo il limits.nodes campo. I limiti di CPU e memoria non sono applicabili.

• Nessun campo di peso: il weight campo non può essere impostato su pool di nodi con capacità statica poiché la selezione dei nodi non si basa sulla priorità.

Comportamento operativo:

• Nessun consolidamento: i nodi nei pool di capacità statica non vengono presi in considerazione per il consolidamento in base all'utilizzo.

• Operazioni di scalabilità: le operazioni di scalabilità evitano i budget relativi alle interruzioni dei nodi, ma rispettano comunque i requisiti. PodDisruptionBudgets

• Sostituzione dei nodi: i nodi vengono comunque sostituiti per eventuali variazioni (come gli aggiornamenti AMI) e per scadenza in base alla configurazione.

Ridimensiona un pool di nodi con capacità statica

È possibile modificare il numero di repliche in un pool di nodi con capacità statica utilizzando il comando: kubectl scale

# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5

In caso di ridimensionamento, EKS Auto Mode terminerà i nodi in modo corretto, rispettando PodDisruptionBudgets e consentendo la riprogrammazione dei pod in esecuzione sui nodi rimanenti.

Monitora i pool di nodi con capacità statica

Usa i seguenti comandi per monitorare i tuoi pool di nodi a capacità statica:

# 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}'

Il status.nodes campo mostra il numero attuale di nodi gestiti dal pool di nodi, che dovrebbe corrispondere al replicas numero desiderato in condizioni normali.

Configurazioni di esempio

Pool di nodi con capacità statica di base

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

Capacità statica con tipi di istanze specifici

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%

Pool di nodi con capacità statica multizona

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 practice

Pianificazione della capacità:

• Impostato su un limits.nodes valore superiore replicas a per consentire il ridimensionamento temporaneo durante le operazioni di sostituzione dei nodi.

• Quando imposti i limiti, considera la capacità massima necessaria durante la deriva dei nodi o gli aggiornamenti AMI.

Selezione dell'istanza:

• Utilizza tipi di istanze specifici quando hai istanze riservate o requisiti hardware specifici.

• Evita requisiti eccessivamente restrittivi che potrebbero limitare la disponibilità delle istanze durante la scalabilità.

Gestione delle interruzioni:

• Configura budget adeguati per le interruzioni per bilanciare la disponibilità con le operazioni di manutenzione.

• Considerate la tolleranza della vostra applicazione per la sostituzione dei nodi quando impostate le percentuali di budget.

Monitoraggio:

• Monitora regolarmente il status.nodes campo per garantire il mantenimento della capacità desiderata.

• Imposta avvisi per quando il numero effettivo di nodi si discosta dalle repliche desiderate.

Distribuzione delle zone:

• Per un'elevata disponibilità, distribuisci la capacità statica su più zone di disponibilità.

• Quando si crea un pool di nodi a capacità statica che si estende su più zone di disponibilità, EKS Auto Mode distribuisce i nodi tra le zone specificate, ma non è garantito che la distribuzione sia uniforme.

• Per una distribuzione prevedibile e uniforme tra le zone di disponibilità, crea pool di nodi con capacità statica separati, ciascuno collegato a una zona di disponibilità specifica utilizzando il requisito. topology.kubernetes.io/zone

• Se hai bisogno di 12 nodi distribuiti uniformemente su tre zone, crea tre pool di nodi con 4 repliche ciascuno, anziché un pool di nodi con 12 repliche su tre zone.

risoluzione dei problemi

I nodi non raggiungono le repliche desiderate:

• Controlla se il limits.nodes valore è sufficiente

• Verifica che i requisiti non limitino eccessivamente la selezione delle istanze

• Controlla le quote AWS di servizio per i tipi di istanze e le regioni che stai utilizzando

La sostituzione dei nodi richiede troppo tempo:

• Modifica i budget per le interruzioni per consentire più sostituzioni simultanee

• Controlla se PodDisruptionBudgets stanno impedendo la chiusura del nodo

Chiusura imprevista del nodo:

• Rivedi le impostazioni expireAfter e terminationGracePeriod

• Verifica la presenza di interruzioni manuali dei nodi o di eventi AWS di manutenzione