VM spot

Autopilot Standard

---

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 a un prezzo inferiore rispetto alle VM di Compute Engine standard e non garantiscono la disponibilità. Le VM spot offrono gli stessi tipi di macchina e le stesse opzioni delle VM standard.

Nota: per una migliore disponibilità, utilizza tipi di macchina più piccoli.

Puoi utilizzare le VM spot nei cluster e nei pool di nodi per eseguire carichi di lavoro stateless, batch o a tolleranza di errore in grado di 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 massimizzare l'efficienza in termini di costi, combina l'utilizzo delle VM spot con le best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE.

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

Nota: i pod spot sono una funzionalità dei cluster GKE Autopilot. Quando richiedi pod spot, Autopilot esegue automaticamente il provisioning delle VM spot, aggiunge incompatibilità e tolleranze e gestisce la scalabilità automatica e la pianificazione. Scopri di più sui pod spot.

Vantaggi delle VM spot

Le VM spot e le VM prerilasciabili hanno molti vantaggi in comune, tra cui:

• Prezzi più bassi rispetto alle VM di Compute Engine standard.
• Utili per i carichi di lavoro stateless a tolleranza di errore e resilienti alla natura temporanea di queste VM.
• Funziona con il gestore della scalabilità automatica dei cluster e il provisioning automatico dei nodi.

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

Nota: GKE continua a supportare l'utilizzo di VM prerilasciabili nei cluster e nei pool di nodi. Tuttavia, le VM spot sono consigliate e sostituiscono la necessità di utilizzare VM prerilasciabili.

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. 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, viene inviata una notifica di terminazione a GKE. Le VM spot terminano 30 secondi dopo aver ricevuto un avviso di risoluzione.

Nei cluster che eseguono GKE versione 1.20 e successive, la funzionalità di arresto del nodo gestito tramite kubelet è abilitata per impostazione predefinita. kubelet rileva l'avviso di terminazione e termina gentilmente i pod in esecuzione sul nodo. Se i pod fanno parte di un oggetto Deployment, il controller crea e pianifica nuovi pod al posto di quelli terminati.

Secondo il criterio del "best effort", il kubelet concede il seguente periodo di terminazione controllata, in base alla versione GKE del pool di nodi:

• Dopo 1.22.8-gke.200: 15 secondi per i pod non di sistema, dopodiché i pod di sistema (con le classi di priorità system-cluster-critical o system-node-critical) hanno 15 secondi per eseguire l'arresto controllato.
• 1.22.8-gke.200 e versioni precedenti: 25 secondi per i pod non di sistema, dopodiché i pod di sistema (con le classi di priorità system-cluster-critical o system-node-critical) hanno 5 secondi per eseguire l'arresto controllato.

Nota: la modifica dei valori di terminationGracePeriodSeconds, shutdownGracePeriodCriticalPods o shutdownGracePeriod nelle specifiche dei pod a un tempo superiore a quello concesso (15 o 25 secondi) non ha alcun effetto sulla terminazione controllata dei nodi che utilizzano VM prerilasciabili o VM spot.

Durante la terminazione controllata del nodo, il kubelet aggiorna lo stato dei pod, assegnando una fase Failed e un motivo Terminated ai pod terminati.

Nota: per i cluster che eseguono la versione 1.27.2-gke.1800 o successive, GKE elimina automaticamente i pod eliminati durante la terminazione dei nodi. Segui le istruzioni riportate di seguito per eliminare manualmente i pod terminati per le versioni precedenti di GKE.

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

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

  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

Avviso: in Kubernetes 1.22 e versioni precedenti, l'eliminazione manuale dei pod di chiusura reimposta il contatore che i job potrebbero utilizzare per determinare backoffLimit.

Pianificazione dei carichi di lavoro su 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 su nodi che utilizzano VM spot utilizzando il campo nodeSelector nelle specifiche dei pod. I seguenti esempi 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à nodo per indicare a GKE di pianificare i pod sulle VM spot, come nell'esempio seguente:

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

Puoi anche usare nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution per preferire che GKE posizioni i pod sui nodi che utilizzano le VM spot. Non è consigliabile preferire le VM spot, perché GKE potrebbe pianificare i pod su nodi attuabili esistenti che utilizzano VM standard.

Nota: il gestore della scalabilità automatica dei cluster e il provisioning automatico dei nodi non sono interessati da preferredDuringSchedulingIgnoredDuringExecution quando prendono decisioni relative alla scalabilità automatica.

Usare incompatibilità e tolleranze per la pianificazione

Per evitare interruzioni del sistema, utilizza un'incompatibilità dei nodi per garantire che GKE non pianifichi carichi di lavoro critici sulle VM spot. Se incompatibilità i nodi che utilizzano le VM spot, GKE pianifica solo i pod con la tolleranza corrispondente su quei nodi.

Se utilizzi le incompatibilità dei nodi, assicurati che il cluster abbia anche almeno un pool di nodi che utilizza VM di Compute Engine standard. I pool di nodi che utilizzano VM standard forniscono a GKE un luogo affidabile per pianificare componenti di sistema critici come il DNS.

Per informazioni sull'utilizzo di un'incompatibilità dei nodi per le VM spot, consulta Utilizzare incompatibilità e tolleranze per le VM spot.

Utilizzo di VM spot con pool di nodi GPU

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

Per poter creare un pool di nodi GPU che utilizza le 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 l'incompatibilità nvidia.com/gpu=present:NoSchedule ai nodi. Di conseguenza, GKE potrebbe pianificare i carichi di lavoro di sistema sui pool di nodi GPU con le 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 di quelli 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 le VM spot.

VM spot e provisioning automatico dei nodi

Nota: le VM spot sono supportate solo dal provisioning automatico dei nodi in GKE 1.21 e versioni successive. Le VM prerilasciabili possono essere utilizzate nelle versioni precedenti di GKE.

Il provisioning automatico dei nodi crea ed elimina automaticamente i pool di nodi nel cluster per soddisfare le esigenze dei tuoi carichi di lavoro. Quando pianifichi i carichi di lavoro che richiedono VM spot utilizzando un'affinità di nodi o nodeSelector, il provisioning automatico dei nodi crea nuovi pool di nodi per supportare i pod dei carichi di lavoro. GKE aggiunge automaticamente l'incompatibilità cloud.google.com/gke-spot=true:NoSchedule ai nodi nei nuovi pool di nodi. 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

Attenzione: se non specifichi una tolleranza e il deployment richiede VM spot, i pod rimangono in stato non pianificabile.

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

Se pianifichi un carico di lavoro utilizzando solo una tolleranza, GKE può pianificare i pod su VM spot o VM standard esistenti con capacità. Se hai bisogno di pianificare un carico di lavoro sulle VM spot, utilizza un'affinità nodeSelector o nodo oltre a una tolleranza. Per scoprire di più, consulta Pianificazione dei carichi di lavoro sulle VM spot.

VM spot e gestore della scalabilità automatica dei cluster

Il gestore della scalabilità automatica dei cluster aggiunge e rimuove automaticamente i nodi nei pool di nodi in base alla domanda. Se il cluster contiene pod che non possono essere posizionati su VM spot esistenti, il gestore della scalabilità automatica del cluster aggiunge nuovi nodi che utilizzano le VM spot.

Criterio predefinito

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

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

Se i pool di nodi cluster standard che utilizzano le VM spot sono configurati per utilizzare upgrade di sovraccarico, GKE crea nodi di picco con le VM spot. Tuttavia, GKE non aspetta che le VM spot siano pronte prima di contrassegnare e svuotare i nodi esistenti, poiché le VM spot non offrono alcuna garanzia di disponibilità. Per scoprire di più, consulta la sezione Upgrade di Surge.

Modifiche al comportamento di Kubernetes

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

• La rivendicazione delle VM spot è involontaria e non è coperta dalle garanzie di PodDisruptionBudgets. Potresti riscontrare una indisponibilità maggiore rispetto a quella configurata per PodDisruptionBudget.

Best practice per le VM spot

Durante la progettazione di un sistema che utilizza le VM spot, puoi evitare gravi interruzioni utilizzando le seguenti linee guida:

• Le VM spot non hanno garanzie di disponibilità. Progetta i tuoi sistemi partendo dal presupposto che GKE possa recuperare una o tutte le tue VM spot in qualsiasi momento, senza alcuna garanzia quando saranno disponibili nuove istanze.
• Per assicurarti che i carichi di lavoro e i job vengano elaborati anche quando non sono disponibili VM spot, assicurati che i cluster abbiano un mix di pool di nodi che utilizzano VM spot e pool di nodi che utilizzano VM di Compute Engine standard.
• Prima di aggiungere un pool di nodi GPU che utilizza VM spot, assicurati che il cluster abbia almeno un pool di nodi non GPU che utilizza VM standard.
• Sebbene i nomi dei nodi di solito non cambino quando i nodi vengono ricreati, gli indirizzi IP interni ed esterni utilizzati dalle VM spot potrebbero cambiare dopo la nuova creazione.
• Utilizza le incompatibilità e le tolleranze dei nodi per garantire che i pod critici non siano pianificati per i pool di nodi che utilizzano le VM spot.
• Per eseguire carichi di lavoro stateful sulle VM spot, esegui dei test per assicurarti che i carichi di lavoro possano terminarsi automaticamente entro 25 secondi dall'arresto, in modo da ridurre al minimo il rischio di danneggiamento permanente dei dati dei volumi.
• Segui le best practice per la terminazione dei pod di Kubernetes.

Avviso: i dati sui nodi che utilizzano VM spot vengono eliminati quando l'istanza viene recuperata. Le unità SSD locali con VM spot collegate non vengono mantenute dopo l'eliminazione.

Passaggi successivi

• Scopri come utilizzare le VM spot nei pool di nodi.
• Scopri di più sulla scalabilità automatica dei cluster.
• Scopri come scalare le app di cui hai eseguito il deployment.
• Scopri di più sulle VM spot nella documentazione di Compute Engine.
• Segui un tutorial sul deployment di un carico di lavoro batch utilizzando le VM spot in GKE.