VM spot

Questo documento spiega cosa sono le VM spot e come funzionano in Google Kubernetes Engine (GKE). Per saperne di più sull'utilizzo delle VM spot, consulta quanto segue:

Puoi richiedere VM spot per i tuoi workload in modalità Standard e Autopilot utilizzando ComputeClasses o selettori di nodi.

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 forniscono alcuna garanzia 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 effimera 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 i seguenti:

Le VM spot offrono i seguenti vantaggi aggiuntivi:

  • A differenza delle VM prerilasciabili, che scadono dopo 24 ore, le VM spot non hanno un tempo di scadenza. Le VM spot vengono prerilasciate solo quando Compute Engine ha bisogno delle risorse altrove.
  • Con le VM spot, puoi visualizzare la disponibilità in tempo reale e l'uptime previsto per decidere dove e come eseguire il provisioning delle risorse. Per maggiori informazioni, consulta Visualizzare la disponibilità delle VM spot.

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.

Quando richiedi pod spot, Autopilot esegue automaticamente il provisioning delle VM spot, aggiunge taint e tolleranze e gestisce la scalabilità automatica e la pianificazione.

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 arresto controllato di 30 secondi per l'arresto dei pod dopo la ricezione della notifica di preemption. Questo periodo è suddiviso in 15 secondi per l'arresto dei pod, dopodiché i pod di sistema critici hanno 15 secondi per l'arresto.

Se vuoi, puoi estendere la durata del periodo di interruzione controllata a 120 secondi. La modalità di configurazione di questa durata dipende dal fatto che tu crei i pool di nodi manualmente o utilizzi ComputeClass personalizzate, come segue:

  • Pool di nodi standard: per configurare questa durata per i pool di nodi standard, 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 ulteriori informazioni sui campi specifici, consulta Arresto controllato delle VM spot in GKE.

    Puoi configurare questa durata utilizzando uno dei seguenti metodi:

    • Nuovi pool di nodi standard: esegui il provisioning delle VM spot in GKE durante la creazione del cluster o del pool di nodi utilizzando la consoleGoogle Cloud o Google Cloud CLI. I valori vengono memorizzati nella configurazione di sistema del nodo.
    • Node pool Standard esistenti: puoi aggiornare il periodo di terminazione controllata per i node pool Standard esistenti aggiornando la configurazione del sistema dei nodi. Per saperne di più, consulta Modifica aggiornando un pool di nodi esistente.

  • ComputeClass personalizzate: per configurare questa durata per le VM spot associate a ComputeClass personalizzate, utilizza i campi shutdownGracePeriodSeconds e shutdownGracePeriodCriticalPodsSeconds nell'oggetto kubeletConfig nella specifica ComputeClass. Il control plane del cluster deve eseguire GKE versione 1.36.0-gke.3204000 o successive.

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 regolari hanno 15 secondi per spegnersi, dopodiché i pod di sistema (con le priorityClasses system-cluster-critical o system-node-critical) hanno 15 secondi per spegnersi. 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 controllata.
  • shutdownGracePeriodCriticalPodsSeconds: estendi il periodo di tolleranza per terminare i pod di sistema critici. Questo campo è valido solo se specifichi anche il campo shutdownGracePeriodSeconds. Il valore in questo campo deve essere inferiore a quello nel campo shutdownGracePeriodSeconds. Ad esempio, se specifichi un valore di 30 nel campo shutdownGracePeriodCriticalPodsSeconds e un valore di 120 nel campo shutdownGracePeriodSeconds, i pod regolari hanno 90 secondi per terminare e i pod di sistema hanno 30 secondi per terminare.

Durante l'arresto controllato, se i pod fanno parte di un workload gestito, ad esempio un deployment, il controller crea e pianifica nuovi pod per sostituire quelli terminati. Se specifichi un valore maggiore del periodo di interruzione controllata impostato nel campo terminationGracePeriodSeconds del manifest del pod, il periodo di interruzione controllata non viene esteso. Il periodo di tolleranza totale massimo che qualsiasi 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) ai nodi che utilizzano le VM spot. Puoi pianificare pod specifici su 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. Preferire le VM spot non è consigliato, perché GKE potrebbe pianificare i pod su nodi validi esistenti che utilizzano invece 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 applichi un taint ai nodi che utilizzano 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 le 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 un 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 di 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 del 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 esigenze 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 pool di nodi 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 di 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 VM standard esistenti con capacità. Se vuoi che un workload venga pianificato sulle VM spot, utilizza un nodeSelector o un'affinità dei nodi in aggiunta 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 del cluster per aggiungere 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 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 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.

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 di picco, GKE crea nodi di picco 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 Aumento improvviso.

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 a PodDisruptionBudget configurato.

Best practice per le VM spot

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

  • Le VM spot non hanno 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.
  • Prima di creare VM spot, ti consigliamo di procedere come segue. Queste azioni contribuiscono a garantire che il tipo di macchina che vuoi che le tue VM spot utilizzino sia disponibile e che soddisfi le tue esigenze di costi e carichi di lavoro.
  • 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 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 workload stateful sulle VM spot, esegui test per assicurarti che i tuoi workload 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