VM spot

Questa pagina spiega cosa sono le VM spot e come funzionano in Google Kubernetes Engine (GKE). Per scoprire come utilizzare le VM spot, consulta Utilizzare le VM spot.

Panoramica delle VM spot in GKE

Le VM spot sono istanze di macchine virtuali (VM) di Compute Engine che hanno un prezzo inferiore rispetto alle VM Compute Engine standard e non offrono garanzie di disponibilità. Le Spot VM offrono gli stessi tipi di macchine e opzioni delle VM standard.

Puoi utilizzare le VM spot nei cluster e nei pool di nodi per eseguire carichi di lavoro stateless, batch o a tolleranza di errore che possono tollerare interruzioni causate dalla natura temporanea delle VM spot.

Le VM spot rimangono disponibili finché Compute Engine non richiede le risorse per le VM standard.

Per saperne di più sulle VM spot, consulta la sezione VM spot nella documentazione di Compute Engine.

Vantaggi delle VM spot

Le VM spot e le VM prerilasciabili condividono molti vantaggi, tra cui:

A differenza delle VM prerilasciabili, che scadono dopo 24 ore, le VM spot non hanno un periodo di scadenza. Le VM spot vengono terminate solo quando Compute Engine ha bisogno delle risorse altrove.

Come funzionano le VM spot in GKE

Quando crei un cluster o un pool di nodi con VM spot, GKE crea VM spot di Compute Engine sottostanti che si comportano come un gruppo di istanze gestite (MIG). I nodi che utilizzano le VM spot si comportano come i nodi GKE standard, ma senza garanzia di disponibilità. Quando le risorse utilizzate dalle VM spot sono necessarie per eseguire VM standard, Compute Engine termina le VM spot per utilizzare le risorse altrove.

Terminazione e arresto controllato delle VM spot

Quando Compute Engine deve recuperare le risorse utilizzate dalle VM spot, a GKE viene inviata una notifica di terminazione. Le VM spot vengono terminate 30 secondi dopo aver ricevuto una notifica di terminazione.

Per impostazione predefinita, i cluster utilizzano l'arresto controllato dei nodi. Kubelet rileva la notifica di terminazione e termina normalmente i pod in esecuzione sul nodo. Se i pod fanno parte di un carico di lavoro gestito, ad esempio un deployment, il controller crea e pianifica nuovi pod per sostituire quelli terminati.

In base al principio del best effort, kubelet concede un periodo di terminazione controllata di 15 secondi per i pod non di sistema, dopodiché i pod di sistema (con le priorityClass system-cluster-critical o system-node-critical) hanno 15 secondi per terminare in modo controllato. Durante l'arresto controllato del nodo, kubelet aggiorna lo stato dei pod e assegna una fase Failed e un motivo Terminated ai pod terminati.

La VM si arresta 30 secondi dopo l'invio della notifica di terminazione, anche se specifichi un valore maggiore di 15 secondi nel campo terminationGracePeriodSeconds del manifest del pod.

Quando il numero di pod terminati raggiunge una soglia di 1000 per i cluster con meno di 100 nodi o 5000 per i cluster con 100 nodi o più, la garbage collection pulisce i pod.

Puoi anche eliminare manualmente i pod terminati utilizzando i seguenti comandi:

  kubectl get pods --all-namespaces | grep -i NodeShutdown | awk '{print $1, $2}' | xargs -n2 kubectl delete pod -n
  kubectl get pods --all-namespaces | grep -i Terminated | awk '{print $1, $2}' | xargs -n2 kubectl delete pod -n

Pianificazione dei carichi di lavoro sulle VM spot

GKE aggiunge automaticamente le etichette cloud.google.com/gke-spot=true e cloud.google.com/gke-provisioning=spot (per i nodi che eseguono GKE versione 1.25.5-gke.2500 o successive) ai nodi che utilizzano le VM spot. Puoi pianificare pod specifici sui nodi che utilizzano VM spot utilizzando il campo nodeSelector nella specifica del pod. Gli esempi seguenti utilizzano l'etichetta cloud.google.com/gke-spot:

apiVersion: v1
kind: Pod
spec:
  nodeSelector:
    cloud.google.com/gke-spot: "true"

In alternativa, puoi utilizzare l'affinità dei nodi per indicare a GKE di pianificare i pod sulle VM spot, in modo simile all'esempio seguente:

apiVersion: v1
kind: Pod
spec:
...
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/gke-spot
            operator: In
            values:
            - "true"
...

Puoi anche utilizzare nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution per preferire che GKE posizioni i pod sui nodi che utilizzano le VM spot. È sconsigliato preferire le VM spot, perché GKE potrebbe pianificare i pod su nodi validi esistenti che utilizzano VM standard.

Utilizzo di incompatibilità e tolleranze per la pianificazione

Per evitare interruzioni del sistema, utilizza una taint del nodo per assicurarti che GKE non pianifichi workload critici su VM spot. Quando contrassegni i nodi che utilizzano le VM spot, GKE pianifica solo i pod che hanno la tolleranza corrispondente su questi nodi.

Se utilizzi i taint dei nodi, assicurati che il cluster abbia anche almeno un pool di nodi che utilizza VM Compute Engine standard. I node pool che utilizzano VM standard forniscono un luogo affidabile in cui GKE può pianificare componenti di sistema critici come DNS.

Per informazioni sull'utilizzo di una taint del nodo per le VM spot, consulta Utilizzare taint e tolleranze per le VM spot.

Utilizzo di VM spot con node pool GPU

Le VM spot supportano l'utilizzo delle GPU. Quando crei un nuovo pool di nodi GPU, GKE aggiunge automaticamente il taint nvidia.com/gpu=present:NoSchedule ai nuovi nodi. Su questi nodi possono essere eseguiti solo i pod con la tolleranza corrispondente. GKE aggiunge automaticamente questa tolleranza ai pod che richiedono GPU.

Prima di creare un pool di nodi GPU che utilizza VM spot, il cluster deve avere almeno un pool di nodi non GPU esistente che utilizza VM standard. Se il tuo cluster ha solo un pool di nodi GPU con VM spot, GKE non aggiunge il taint nvidia.com/gpu=present:NoSchedule a questi nodi. Di conseguenza, GKE potrebbe pianificare i workload di sistema nei pool di nodi GPU con VM spot, il che può causare interruzioni a causa delle VM spot e aumentare il consumo di risorse perché i nodi GPU sono più costosi dei nodi non GPU.

Gestore della scalabilità automatica dei cluster e provisioning automatico dei nodi

Puoi utilizzare il gestore della scalabilità automatica dei cluster e il provisioning automatico dei nodi per scalare automaticamente i cluster e i pool di nodi in base alle esigenze dei tuoi carichi di lavoro. Sia il gestore della scalabilità automatica dei cluster che il provisioning automatico dei nodi supportano l'utilizzo delle VM spot.

VM spot e provisioning automatico dei nodi

Il provisioning automatico dei nodi crea ed elimina automaticamente i pool di nodi nel cluster per soddisfare le richieste dei tuoi carichi di lavoro. Quando pianifichi i workload che richiedono VM spot utilizzando un'nodeSelector o l'affinità dei nodi, il provisioning automatico dei nodi crea nuovi node pool per ospitare i pod dei workload. GKE aggiunge automaticamente il taint cloud.google.com/gke-spot=true:NoSchedule ai nodi nei nuovi node pool. Solo i pod con la tolleranza corrispondente possono essere eseguiti sui nodi in questi pool di nodi. Devi aggiungere la tolleranza corrispondente ai tuoi deployment per consentire a GKE di posizionare i pod sulle VM spot:

   tolerations:
   - key: cloud.google.com/gke-spot
     operator: Equal
     value: "true"
     effect: NoSchedule

Puoi assicurarti che GKE pianifichi solo i tuoi pod sulle VM spot utilizzando sia una tolleranza sia una regola di affinità dei nodi o nodeSelector per filtrare le VM spot.

Se pianifichi un workload utilizzando solo una tolleranza, GKE può pianificare i pod su VM spot o su VM standard esistenti con capacità. Se vuoi che un workload venga pianificato sulle VM spot, utilizza un nodeSelector o un'affinità dei nodi oltre a una tolleranza. Per saperne di più, consulta Pianificazione dei carichi di lavoro sulle VM spot.

VM spot e gestore della scalabilità automatica del cluster

Il gestore della scalabilità automatica dei cluster aggiunge e rimuove automaticamente i nodi nei pool di nodi in base alla domanda. Puoi configurare il gestore della scalabilità automatica dei cluster in modo che aggiunga nuovi nodi con una preferenza per le VM spot. Per saperne di più, consulta VM spot e gestore della scalabilità automatica dei cluster.

Policy predefinita

A partire dalla versione 1.24.1-gke.800 di GKE, puoi definire i criteri di località del gestore della scalabilità automatica. Il gestore della scalabilità automatica dei cluster tenta di eseguire il provisioning dei node pool di VM spot quando le risorse sono disponibili e il criterio di località predefinito è impostato su ANY. Con questa norma, le VM spot hanno un rischio inferiore di essere prerilasciate. Per altri tipi di VM, il criterio di distribuzione predefinito del gestore della scalabilità automatica dei cluster è BALANCED.

Esegui l'upgrade dei pool di nodi standard utilizzando le VM spot

Se i pool di nodi del cluster Standard che utilizzano VM spot sono configurati per utilizzare gli upgrade inattivi, GKE crea nodi inattivi con VM spot. Tuttavia, GKE non attende che le VM spot siano pronte prima di isolare e svuotare i nodi esistenti, in quanto le VM spot non forniscono alcuna garanzia di disponibilità. Per saperne di più, consulta Aumenti della tariffa dinamica.

Modifiche al comportamento di Kubernetes

L'utilizzo delle VM spot su GKE modifica alcune garanzie e vincoli forniti da Kubernetes, ad esempio:

  • Il recupero delle VM spot è involontario e non è coperto dalle garanzie di PodDisruptionBudgets. Potresti riscontrare una maggiore indisponibilità rispetto al PodDisruptionBudget configurato.

Best practice per le VM spot

Quando progetti un sistema che utilizza VM spot, puoi evitare interruzioni importanti utilizzando le seguenti linee guida:

  • Le VM spot non offrono garanzie di disponibilità. Progetta i tuoi sistemi partendo dal presupposto che GKE potrebbe recuperare una o tutte le tue VM spot in qualsiasi momento, senza alcuna garanzia di quando saranno disponibili nuove istanze.
  • Per assicurarti che i tuoi workload e job vengano elaborati anche quando non sono disponibili VM spot, assicurati che i tuoi cluster abbiano un mix di pool di nodi che utilizzano VM spot e pool di nodi che utilizzano VM Compute Engine standard.
  • Assicurati che il cluster abbia almeno un pool di nodi non GPU che utilizzi VM standard prima di aggiungere un pool di nodi GPU che utilizzi VM spot.
  • Anche se i nomi dei nodi di solito non cambiano quando vengono ricreati, gli indirizzi IP interni ed esterni utilizzati dalle VM di spot potrebbero cambiare dopo la ricreazione.
  • Utilizza le incompatibilità e le tolleranze dei nodi per garantire che i pod critici non vengano pianificati su pool di nodi che utilizzano VM spot.
  • Per eseguire carichi di lavoro stateful sulle VM spot, esegui test per assicurarti che i tuoi carichi di lavoro possano essere terminati correttamente entro 25 secondi dall'arresto per ridurre al minimo il rischio di danneggiamento dei dati del volume permanente.
  • Segui le best practice per la terminazione dei pod Kubernetes.

Passaggi successivi