Controlla gli attributi dei nodi con scalabilità automatica con ComputeClass personalizzate

Questo documento mostra come controllare l'infrastruttura di computing e il comportamento di scalabilità automatica dei cluster Google Kubernetes Engine (GKE) in base alle esigenze specifiche dei tuoi workload utilizzando ComputeClass personalizzate.

Questo documento è rivolto agli amministratori della piattaforma che vogliono definire in modo dichiarativo i profili di scalabilità automatica per i nodi e agli operatori dei cluster che vogliono eseguire i propri workload su ComputeClass specifiche.

Informazioni sulle ComputeClass personalizzate

Le ComputeClass personalizzate sono risorse personalizzate di Kubernetes che ti consentono di definire le priorità che GKE deve seguire durante il provisioning dei nodi per l'esecuzione dei workload. Puoi utilizzare una ComputeClass personalizzata per:

  • Fornisci a GKE un insieme di priorità da seguire in sequenza durante il provisioning dei nodi, ciascuna con parametri specifici come una serie di macchine Compute Engine o una capacità minima delle risorse
  • Definisci le soglie e i parametri di scalabilità automatica per rimuovere i nodi sottoutilizzati e consolidare i workload in modo efficiente sulla capacità di computing esistente
  • Indica a GKE di sostituire automaticamente le configurazioni dei nodi meno preferite con quelle più preferite per prestazioni ottimali del workload

Per comprendere tutte le opzioni di configurazione e il modo in cui interagiscono tra loro e con la modalità Autopilot di GKE e la modalità Standard di GKE, consulta Informazioni sulle ComputeClass personalizzate.

Prezzi

La risorsa personalizzata ComputeClass viene fornita senza costi aggiuntivi in GKE. Si applicano le seguenti considerazioni sui prezzi:

Limitazioni

Il nome di ComputeClass non può iniziare con gke o autopilot.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Abilita l'API Google Kubernetes Engine.
  • Abilita l'API Google Kubernetes Engine
  • Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

Scenario di esempio per ComputeClasses

Questo documento presenta uno scenario di esempio per il quale definisci una ComputeClass personalizzata. In pratica, devi considerare i requisiti dei tuoi workload e della tua organizzazione specifici e definire ComputeClasses che soddisfino questi requisiti. Per descrizioni complete di tutte le opzioni per le ComputeClass e per considerazioni speciali, consulta Informazioni sulle ComputeClass personalizzate.

Considera il seguente scenario di esempio:

  • Il tuo obiettivo è ottimizzare i costi di esecuzione dei tuoi workload
  • I tuoi workload sono a tolleranza di errore e non richiedono l'arresto normale o un runtime esteso
  • I tuoi workload richiedono almeno 64 vCPU per essere eseguiti in modo ottimale
  • Puoi utilizzare solo la serie di macchine Compute Engine N4

In base allo scenario di esempio, decidi di voler una ComputeClass che esegua le seguenti operazioni:

  • Dà la priorità ai nodi N4 Spot con almeno 64 vCPU
  • Consente a GKE di eseguire il fallback su qualsiasi nodo Spot N4, indipendentemente dalla capacità di calcolo
  • Se non sono disponibili nodi spot N4, consente a GKE di utilizzare nodi N4 on demand
  • Indica a GKE di spostare i workload sui nodi Spot ogni volta che sono nuovamente disponibili

Configura una classe ComputeClass in modalità Autopilot

In GKE Autopilot, definisci una ComputeClass, ne esegui il deployment nel cluster e la richiedi nei tuoi workload. GKE esegue per te tutti i passaggi di configurazione dei nodi, come l'applicazione di etichette e taint.

Salva il seguente manifest come compute-class.yaml:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-optimized
spec:
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false
  activeMigration:
    optimizeRulePriority: true
  nodePoolAutoCreation:
    enabled: true

Configura una ComputeClass in modalità Standard

Nei cluster in modalità GKE Standard, potresti dover eseguire la configurazione manuale per assicurarti che i pod ComputeClass vengano pianificati come previsto. La configurazione manuale dipende dalla creazione automatica o meno dei pool di nodi, come segue:

Per consentire a GKE di creare automaticamente i node pool per la tua ComputeClass, segui questi passaggi:

  1. Per i cluster in modalità Standard che eseguono una versione precedente alla 1.33.3-gke.1136000 e non sono registrati nel canale di rilascio rapido, attiva il provisioning automatico dei nodi a livello di cluster.
  2. Salva il seguente manifest di esempio come compute-class.yaml:

    apiVersion: cloud.google.com/v1
    kind: ComputeClass
    metadata:
      name: cost-optimized
    spec:
      priorities:
      - machineFamily: n4
        spot: true
        minCores: 64
      - machineFamily: n4
        spot: true
      - machineFamily: n4
        spot: false
      activeMigration:
        optimizeRulePriority: true
      nodePoolAutoCreation:
        enabled: true
    

    Quando esegui il deployment di pod che richiedono questa classe di computing di esempio e devono essere creati nuovi nodi, GKE dà la priorità alla creazione di nodi nell'ordine degli elementi nel campo priorities. Se necessario, GKE crea nuovi node pool che soddisfano i requisiti hardware della classe ComputeClass.

Puoi anche specificare un tipo di macchina personalizzata preciso nelle tue priorità. L'utilizzo di tipi di macchine personalizzate richiede GKE versione 1.33.2-gke.1111000 o successive. L'esempio seguente configura una ComputeClass che dà la priorità alle VM spot per il tipo di macchina personalizzata n4-custom-8-20480 e utilizza come VM di riserva le VM on demand dello stesso tipo se la capacità spot non è disponibile:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: custom-machine-type
spec:
  priorities:
  - machineType: n4-custom-8-20480
    spot: true
  - machineType: n4-custom-8-20480
    spot: false
  nodePoolAutoCreation:
    enabled: true

Per ottimizzare la disponibilità della capacità durante i vincoli di capacità, definisci una ComputeClass che si estende su più serie e generazioni di macchine. Per i workload stateless o con tolleranza alle interruzioni, puoi anche attivare la migrazione attiva per riportare i workload all'hardware preferito quando la capacità viene ripristinata:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: multi-family-fallback
spec:
  priorities:
  - machineFamily: c4d
  - machineFamily: c3d
  - machineFamily: c4
  - machineFamily: c3
  - machineFamily: n4
  - machineFamily: n2d
  activeMigration:
    optimizeRulePriority: true
  nodePoolAutoCreation:
    enabled: true

Le serie di macchine più recenti, come C4, C4D e N4, supportano solo Hyperdisk, mentre le serie precedenti, come N2D, utilizzano Persistent Disk. Se i workload stateful utilizzano una ComputeClass che comprende entrambe le generazioni, disattiva la migrazione attiva e, in GKE versione 1.35.3-gke.1290000 e successive, utilizza la StorageClass dynamic-rwo integrata o una StorageClass personalizzata con selezione automatica del tipo di disco (parameters.type: dynamic), use-allowed-disk-topology: "true" e volumeBindingMode: WaitForFirstConsumer. GKE seleziona quindi un tipo di disco compatibile durante il provisioning dei nuovi volumi e pianifica i volumi esistenti solo su serie di macchine compatibili.

Utilizza ComputeClasses con i node pool creati manualmente

Questa sezione mostra come definire una ComputeClass in un cluster che utilizza solo pool di nodi creati manualmente.

  1. Salva il seguente manifest come compute-class.yaml:

    apiVersion: cloud.google.com/v1
    kind: ComputeClass
    metadata:
      name: cost-optimized
    spec:
      priorities:
      - machineFamily: n4
        spot: true
        minCores: 64
      - machineFamily: n4
        spot: true
      - machineFamily: n4
        spot: false
      activeMigration:
        optimizeRulePriority: true
    
  2. Crea un nuovo pool di nodi con scalabilità automatica che utilizza VM spot e associalo alla classe ComputeClass:

    gcloud container node-pools create cost-optimized-pool \
        --location=LOCATION \
        --cluster=CLUSTER_NAME \
        --machine-type=n4-standard-64 \
        --spot \
        --enable-autoscaling \
        --max-nodes=9 \
        --node-labels="cloud.google.com/compute-class=cost-optimized" \
        --node-taints="cloud.google.com/compute-class=cost-optimized:NoSchedule"
    

    Sostituisci quanto segue:

    • LOCATION: la località del tuo cluster.
    • CLUSTER_NAME: il nome del cluster esistente.
  3. Crea un nuovo pool di nodi con scalabilità automatica con VM on demand e associalo alla ComputeClass:

    gcloud container node-pools create on-demand-pool \
        --location=LOCATION \
        --cluster=CLUSTER_NAME \
        --machine-type=n4-standard-64 \
        --enable-autoscaling \
        --max-nodes=9 \
        --num-nodes=0 \
        --node-labels="cloud.google.com/compute-class=cost-optimized" \
        --node-taints="cloud.google.com/compute-class=cost-optimized:NoSchedule"
    

Quando esegui il deployment dei pod che richiedono questa ComputeClass e devono essere creati nuovi nodi, GKE dà la priorità alla creazione di nodi nel pool di nodi cost-optimized-pool. Se non è possibile creare nuovi nodi, GKE li crea nel pool di nodi on-demand-pool.

Per maggiori dettagli su come i node pool creati manualmente interagiscono con le ComputeClass personalizzate, consulta Configura i node pool creati manualmente per l'utilizzo di ComputeClass.

Personalizza le soglie di scalabilità automatica per il consolidamento dei nodi

Per impostazione predefinita, GKE rimuove i nodi sottoutilizzati e ripianifica i workload su altri nodi disponibili. Puoi personalizzare ulteriormente le soglie e i tempi dopo i quali un nodo diventa un candidato per la rimozione utilizzando il campo autoscalingPolicy nella definizione di ComputeClass, come nell'esempio seguente:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-optimized
spec:
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false
  activeMigration:
    optimizeRulePriority: true
  autoscalingPolicy:
    consolidationDelayMinutes : 5
    consolidationThreshold    : 70

In questo esempio, un nodo diventa un candidato per la rimozione se è sottoutilizzato del 70% della capacità di CPU e memoria disponibile per più di cinque minuti. Per un elenco dei parametri disponibili, consulta Imposta i parametri di scalabilità automatica per il consolidamento dei nodi.

Esegui il deployment di una ComputeClass in un cluster

Dopo aver definito una ComputeClass, eseguine il deployment nel cluster:

kubectl apply -f compute-class.yaml

Questa classe ComputeClass è pronta per l'uso nel cluster. Puoi richiedere la classe di calcolo nelle specifiche dei pod o, facoltativamente, impostarla come classe di calcolo predefinita in uno spazio dei nomi specifico.

Richiedi una ComputeClass in un workload

Per richiedere una classe ComputeClass in un workload, aggiungi un selettore di nodi per quella classe ComputeClass nel manifest, come descritto nei passaggi seguenti:

  1. Salva il seguente manifest come cc-workload.yaml:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: custom-workload
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: custom-workload
      template:
        metadata:
          labels:
            app: custom-workload
        spec:
          nodeSelector:
            cloud.google.com/compute-class: cost-optimized
          containers:
          - name: test
            image: registry.k8s.io/pause
            resources:
              requests:
                cpu: 1.5
                memory: "4Gi"
    
  2. Esegui il deployment del workload:

    kubectl apply -f cc-workload.yaml
    

Quando esegui il deployment di questo workload, GKE aggiunge automaticamente ai pod una tolleranza che corrisponde alla contaminazione del nodo per la classe ComputeClass richiesta. Questa tolleranza contribuisce a garantire che solo i pod che richiedono la ComputeClass vengano eseguiti sui nodi ComputeClass.

Filtra i nodi per ComputeClass

Tutti i nodi associati a ComputeClasses hanno l'etichetta cloud.google.com/compute-class.

Per visualizzare tutti i nodi associati a una classe ComputeClass specifica, esegui questo comando:

kubectl get nodes -l cloud.google.com/compute-class=COMPUTECLASS_NAME

Sostituisci COMPUTECLASS_NAME con il nome di ComputeClass (ad esempio cost-optimized).

L'output è simile al seguente:

NAME                                                  STATUS   ROLES    AGE   VERSION
gke-cluster-1-cost-optimized-pool-f213e529-rx7d       Ready    <none>   5m    v1.32.4-gke.1236007
gke-cluster-1-cost-optimized-pool-f213e529-ab12       Ready    <none>   5m    v1.32.4-gke.1236007

Per visualizzare tutti i nodi del cluster associati a una classe ComputeClass, esegui questo comando:

kubectl get nodes -L cloud.google.com/compute-class

Aggiorna una ComputeClass di cui è stato eseguito il deployment

Per aggiornare una ComputeClass di cui è stato eseguito il deployment, modifica il manifest YAML per la ComputeClass. Quindi, esegui il deployment del manifest modificato eseguendo questo comando:

kubectl apply -f PATH_TO_FILE

Sostituisci PATH_TO_FILE con il percorso del manifest modificato. Assicurati che il valore nel campo name rimanga invariato.

Quando esegui il deployment della classe ComputeClass aggiornata, GKE utilizza la configurazione aggiornata per creare nuovi nodi. GKE non modifica i nodi esistenti con la configurazione aggiornata.

Nel tempo, GKE potrebbe spostare i pod esistenti in nodi che utilizzano la configurazione aggiornata se la classe ComputeClass utilizza la migrazione attiva e se i pod esistenti sono idonei alla migrazione.

Passaggi successivi