Spot VM

Questa pagina spiega cosa sono le VM spot e come funzionano Google Kubernetes Engine (GKE). Per imparare a usare 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 Compute Engine standard e che 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 o a tolleranza di errore in grado di tollerare le interruzioni causate delle VM spot.

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

Per scoprire 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:

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 le risorse altrove.

Come funzionano le VM spot in GKE

Quando crei un cluster o un pool di nodi con le VM spot, GKE crea VM spot di Compute Engine sottostanti che si comportano come gruppo di istanze gestite. Nodi che utilizzano Le VM spot si comportano come nodi GKE standard, ma senza garanzia di disponibilità. Quando le risorse utilizzate dalle VM spot sono necessarie per eseguire VM standard, Compute Engine termina queste 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 risoluzione del contratto. Le VM Spot vengono interrotte 30 secondi dopo aver ricevuto una notifica di interruzione.

Per impostazione predefinita, i cluster usano il nodo gestito automaticamente arresta. Kubelet rileva la notifica di interruzione e termina in modo corretto i pod in esecuzione sul nodo. Se i pod fanno parte di un deployment, il controller crea e pianifica nuovi pod per sostituire quelli terminati.

Secondo il criterio del "best effort", il kubelet concede un periodo di terminazione corretto di 15 secondi per i pod non di sistema, dopodiché i pod di sistema (con system-cluster-critical o system-node-critical PriorityClass) hanno 15 secondi per terminare in modo controllato.

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

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 almeno 100 nodi, garbage collection ripulisce 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 cloud.google.com/gke-spot=true e cloud.google.com/gke-provisioning=spot (per i nodi in esecuzione GKE versione 1.25.5-gke.2500 o successiva) etichette ai nodi che usano le VM spot. Puoi pianificare pod specifici sui nodi che utilizzano le VM spot nodeSelector nella specifica del pod. I seguenti esempi utilizzano 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 comunicare a GKE di pianificare i pod sulle VM spot, 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 utilizzare nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution per preferire che GKE posizioni i pod sui nodi che utilizzano VM spot. Non è consigliabile preferire le VM spot, 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 di sistema, utilizza una incompatibilità dei nodi per garantire che GKE non pianifica carichi di lavoro critici Spot VM. Quando contami i nodi che utilizzano VM Spot, GKE pianifica su questi nodi solo i pod con la corrispondente tolleranza.

Se utilizzi incompatibilità dei nodi, assicurati che il cluster abbia anche almeno un pool di nodi che utilizza le VM standard di Compute Engine. I pool di nodi che utilizzano VM standard forniscono un luogo affidabile in cui GKE può 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 il taint nvidia.com/gpu=present:NoSchedule ai nuovi nodi. Solo i pod con la tolleranza corrispondente possono essere eseguiti su questi nodi. GKE è in esecuzione aggiunge questa tolleranza ai pod che richiedono GPU.

Il cluster deve avere almeno un pool di nodi non GPU esistente che utilizza alle VM standard prima della creazione di un pool di nodi GPU che utilizza le VM spot. Se il tuo cluster ha solo un pool di nodi GPU con VM spot, GKE non aggiunge l'alterazione 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, possono causare interruzioni causate dalle VM spot e aumentare il consumo di risorse perché i nodi GPU sono più costosi rispetto ai 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 eseguire lo scale up e lo scale down automatici dei cluster e dei pool di nodi in base alle esigenze dei carichi di lavoro. Sia il gestore della scalabilità automatica dei cluster che il provisioning automatico dei nodi supportano Spot VM.

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 carichi di lavoro. Quando pianifichi carichi di lavoro che richiedono VM Spot utilizzando un'affinità nodeSelector o dei nodi, il provisioning automatico dei nodi crea nuovi pool di nodi per ospitare i pod dei carichi di lavoro. GKE aggiunge automaticamente il taint cloud.google.com/gke-spot=true:NoSchedule ai nodi dei nuovi pool di nodi. Solo i pod con la tolleranza corrispondente possono essere eseguiti sui nodi in nei pool di nodi. Devi aggiungere la tolleranza corrispondente ai tuoi deployment per consentire a GKE di posizionare i pod su VM spot:

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

Puoi assicurarti che GKE pianifichi i pod solo su VM spot utilizzando sia una tolleranza sia una regola di affinità nodeSelector o del nodo per filtrare in base alle VM spot.

Se pianifichi un carico di lavoro utilizzando solo una tolleranza, GKE può di pianificare i pod su VM spot o VM standard esistenti e la capacità di archiviazione. Se hai bisogno di pianificare un carico di lavoro sulle VM spot, utilizza un nodeSelector o un'affinità nodo oltre a una tolleranza. Per saperne di più, consulta Programmazione 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. Se il tuo cluster contiene pod che non possono essere posizionati su VM spot esistenti, il gestore della scalabilità automatica del cluster aggiunge nuovi nodi che utilizzano VM spot.

Criterio predefinito

A partire da GKE versione 1.24.1-gke.800, puoi definire Norme sulla località del gestore della scalabilità automatica. Il gestore della scalabilità automatica dei cluster tenta di eseguire il provisioning Individua i pool di nodi delle VM quando le risorse sono disponibili e il criterio di località è impostato su ANY. Con questo criterio, le VM spot hanno un il rischio di prerilascio è inferiore. Per altri tipi di VM, il cluster predefinito Il criterio di distribuzione del gestore della scalabilità automatica è 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 mettere in isolamento e svuotare i nodi esistenti, poiché le VM spot non forniscono alcuna garanzia di disponibilità. Per saperne di più, vedi Surge upgrade.

Modifiche al comportamento di Kubernetes

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

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

Best practice per le VM spot

Durante la progettazione di un sistema che utilizza VM spot, puoi evitare gravi interruzioni seguendo queste linee guida:

  • Le VM spot non hanno garanzie di disponibilità. Progetta i tuoi sistemi in base presupposto che GKE possa recuperare una o tutte le tue VM spot in qualsiasi momento, senza alcuna garanzia circa la disponibilità di nuove istanze.
  • Per assicurarti che i carichi di lavoro e i job vengano elaborati anche in assenza di VM spot assicurati che i cluster abbiano una combinazione di pool di nodi che utilizzano VM spot e pool di nodi che utilizzano VM standard di Compute Engine.
  • Assicurati che il cluster abbia almeno un pool di nodi non GPU che utilizza VM standard prima di aggiungere un pool di nodi GPU che utilizza le VM spot.
  • Sebbene i nomi dei nodi di solito non cambino 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 assicurarti che i pod critici non vengano pianificati su pool di nodi che utilizzano VM spot.
  • Per eseguire carichi di lavoro stateful sulle VM spot, verifica che carichi di lavoro possono terminare in modo controllato entro 25 secondi dall'arresto per ridurre il rischio di danneggiamento permanente dei dati del volume.
  • Segui le best practice per la terminazione dei pod Kubernetes.

Passaggi successivi