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 il cui prezzo è inferiore rispetto alle VM standard di Compute Engine e non forniscono alcuna garanzia di disponibilità. Le VM spot offrono gli stessi tipi di macchine e le stesse 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 le 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 VM spot nella documentazione di Compute Engine.

Vantaggi delle VM spot

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

A differenza delle VM prerilasciabili, che scadono dopo 24 ore, le VM spot non hanno un tempo 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 VM spot si comportano come i nodi GKE standard, ma senza alcuna garanzia di disponibilità. Quando le risorse utilizzate dalle VM spot sono necessarie per eseguire le VM standard, Compute Engine termina queste VM spot per utilizzare le risorse altrove.

Terminazione e arresto normale delle VM spot

Quando Compute Engine deve recuperare le risorse utilizzate dalle VM spot, viene inviata una notifica di prerilascio a GKE. Dopo l'invio della notifica di prerilascio, Compute Engine invia un segnale ACPI G2 Soft Off per avviare il periodo di arresto della VM.

Per impostazione predefinita, i cluster GKE hanno un periodo di terminazione normale di 30 secondi per l'arresto dei pod dopo la ricezione della notifica di prerilascio. Questo periodo è suddiviso in 15 secondi per l'arresto dei pod, dopodiché i pod di sistema critici hanno 15 secondi per arrestarsi.

Facoltativamente, puoi estendere la durata del periodo di terminazione normale a 120 secondi. La configurazione di questa durata è in anteprima e il control plane del cluster deve eseguire GKE versione 1.35.0-gke.1171000 o successive. Puoi estendere la durata personalizzando la configurazione del sistema dei nodi per impostare i valori per pool di nodi standard specifici. Per saperne di più, consulta Terminazione normale delle VM spot in GKE. Questo metodo è supportato solo in modalità Standard.

Per impostazione predefinita, i cluster utilizzano l'arresto normale dei nodi per un periodo predefinito di 30 secondi tra la notifica di terminazione e l'arresto. I pod normali hanno 15 secondi per arrestarsi, dopodiché i pod di sistema (con le priorityClass system-cluster-critical o system-node-critical) hanno 15 secondi per arrestarsi. Puoi estendere il periodo di tolleranza utilizzando i seguenti campi:

  • shutdownGracePeriodSeconds: estendi il periodo di tolleranza totale per i pod a 120 secondi o a 0 secondi se non hai bisogno di tempo per la terminazione normale.
  • shutdownGracePeriodCriticalPodsSeconds: estendi il periodo di tolleranza per la terminazione dei pod di sistema critici. Questo campo è valido solo se specifichi anche il campo shutdownGracePeriodSeconds. Il valore in questo campo deve essere inferiore al valore nel campo shutdownGracePeriodSeconds. Ad esempio, se specifichi un valore di 30 nel campo shutdownGracePeriodCriticalPodsSeconds e un valore di 120 nel campo shutdownGracePeriodSeconds, i pod normali hanno 90 secondi per terminare e i pod di sistema hanno 30 secondi per terminare.

Durante la terminazione normale, se i pod fanno parte di un carico di lavoro gestito, ad esempio un deployment, il controller crea e pianifica nuovi pod per sostituire i pod terminati. La specifica di un valore maggiore del periodo di terminazione normale impostato nel campo terminationGracePeriodSeconds del manifest del pod non estende il periodo di terminazione normale. Il periodo di tolleranza totale massimo che un pod può ottenere è di 120 secondi.

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) labels ai nodi che utilizzano VM spot. Puoi pianificare pod specifici sui nodi che utilizzano VM spot utilizzando il nodeSelector campo nella specifica del pod. Gli esempi seguenti utilizzano l cloud.google.com/gke-spot etichetta:

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, come nel seguente esempio:

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 inserisca i pod sui nodi che utilizzano VM spot. L'utilizzo preferenziale delle VM spot non è consigliato, perché GKE potrebbe pianificare i pod sui nodi validi esistenti che utilizzano invece VM standard.

Utilizzo di incompatibilità e tolleranze per la pianificazione

Per evitare interruzioni del sistema, utilizza un' incompatibilità dei nodi per assicurarti che GKE non pianifichi carichi di lavoro critici sulle VM spot. Quando contrassegni i nodi che utilizzano VM spot, GKE pianifica solo i pod che hanno la tolleranza corrispondente su questi nodi.

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

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

Utilizzo delle VM spot con i pool di nodi GPU

Le VM spot supportano l'utilizzo delle GPU. Quando crei un nuovo pool di nodi GPU, GKE aggiunge automaticamente l'incompatibilità 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 cluster ha solo un pool di nodi GPU con VM spot, GKE non aggiunge l'incompatibilità nvidia.com/gpu=present:NoSchedule a questi nodi. Di conseguenza, GKE potrebbe pianificare i carichi di lavoro di sistema sui 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 carichi di lavoro. Sia il gestore della scalabilità automatica dei cluster sia 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 esigenze dei carichi di lavoro. Quando pianifichi i carichi di lavoro che richiedono VM spot utilizzando un nodeSelector o l'affinità dei nodi, il provisioning automatico dei nodi crea nuovi pool di nodi per ospitare 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. Sui nodi di questi pool di nodi possono essere eseguiti solo i pod con la tolleranza corrispondente. Devi aggiungere la tolleranza corrispondente ai deployment per consentire a GKE di inserire i pod sulle VM spot:

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

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

Se pianifichi un carico di lavoro utilizzando solo una tolleranza, GKE può pianificare i pod sulle VM spot o sulle VM standard esistenti con capacità. Se è necessario pianificare un carico di lavoro 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 dei 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 da GKE versione 1.24.1-gke.800, puoi definire la policy di località del gestore della scalabilità automatica. Il gestore della scalabilità automatica dei cluster tenta di eseguire il provisioning dei pool di nodi di VM spot quando le risorse sono disponibili e la policy di località predefinita è impostata su ANY. Con questa policy, le VM spot hanno un rischio inferiore di essere prerilasciate. Per altri tipi di VM, la policy di distribuzione predefinita del gestore della scalabilità automatica dei cluster è BALANCED.

Eseguire 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 di sovraccarico, GKE crea nodi di sovraccarico con VM spot. Tuttavia, GKE non attende che le VM spot siano pronte prima di isolare e svuotare i nodi esistenti, poiché le VM spot non forniscono alcuna garanzia di disponibilità. Per saperne di più, consulta Upgrade di sovraccarico.

Modifiche al comportamento di Kubernetes

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

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

Best practice per le VM spot

Quando progetti un sistema che utilizza VM spot, puoi evitare interruzioni importanti seguendo queste linee guida:

  • Le VM spot non hanno garanzie di disponibilità. Progetta i tuoi sistemi presupponendo che GKE possa recuperare tutte o alcune delle tue VM spot in qualsiasi momento, senza alcuna garanzia di 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 standard di Compute Engine.
  • 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.
  • Anche se i nomi dei nodi in genere non cambiano quando i nodi vengono ricreati, gli indirizzi IP interni ed esterni utilizzati dalle VM spot potrebbero cambiare dopo la ricreazione.
  • Utilizza le incompatibilità e le tolleranze dei nodi per assicurarti che i pod critici non vengano pianificati sui pool di nodi che utilizzano VM spot.
  • Per eseguire carichi di lavoro stateful sulle VM spot, esegui test per assicurarti che i carichi di lavoro possano terminare normalmente entro 25 secondi dall'arresto per ridurre al minimo il rischio di danneggiamento dei dati dei volumi permanenti.
  • Segui le best practice per la terminazione dei pod di Kubernetes.

Passaggi successivi