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 che hanno un prezzo inferiore rispetto alle VM standard di Compute Engine e non offrono garanzia di disponibilità. Le VM spot offrono lo stesso tipi di macchina e opzioni come 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 senza 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 obbligatorie per eseguire le VM standard, Compute Engine termina le VM spot per utilizzare risorse altrove.

Chiusura e arresto controllato delle VM spot

Quando Compute Engine deve recuperare le risorse utilizzate dalle VM spot, notifica di terminazione viene inviata a GKE. Le VM spot terminano 30 secondi dopo la ricezione di un avviso di risoluzione.

Per impostazione predefinita, i cluster usano il nodo gestito automaticamente arresta. Il kubelet rileva l'avviso di terminazione e termina delicatamente i pod che sono 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 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

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 usare nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution preferisci che GKE posizioni i pod su nodi che utilizzano VM spot. La preferenza di VM spot non è consigliata perché GKE potrebbe pianificare i pod in nodi idonei esistenti che utilizzano invece VM standard.

Utilizzo di incompatibilità e tolleranze per la programmazione

Per evitare interruzioni del sistema, utilizza un'incompatibilità dei nodi per garantire che GKE non pianifica carichi di lavoro critici Spot VM. Quando incompatibilità nodi che utilizzano VM spot, GKE pianifica solo i pod che hanno la tollerazione corrispondente su quei nodi.

Se utilizzi incompatibilità dei nodi, assicurati che il cluster abbia anche almeno un pool di nodi che utilizza le VM standard di Compute Engine. Pool di nodi che utilizzano VM standard offre a GKE un luogo affidabile per la pianificazione di sistemi 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 nvidia.com/gpu=present:NoSchedule è incompatibilità con i nuovi nodi. Solo i pod con la tolleranza corrispondente può essere eseguita 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 le tue un cluster ha un pool di nodi GPU con VM spot, GKE non aggiunge l'incompatibilità nvidia.com/gpu=present:NoSchedule per i 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 scalare automaticamente i tuoi cluster e pool di nodi in base alle esigenze carichi di lavoro con scale out impegnativi. Sia il gestore della scalabilità automatica dei cluster che il provisioning automatico dei nodi supportano Spot VM.

Spot VM e provisioning automatico dei nodi

Il provisioning automatico dei nodi crea ed elimina automaticamente i pool di nodi per soddisfare le esigenze dei tuoi carichi di lavoro. Quando pianifichi carichi di lavoro richiedono VM spot utilizzando un nodeSelector o un'affinità dei nodi, il provisioning automatico dei nodi crea pool di nodi per ospitare i carichi di lavoro di pod. GKE è in esecuzione aggiunge l'incompatibilità cloud.google.com/gke-spot=true:NoSchedule ai nodi nel nuovo pool di nodi. Solo i pod con la tolleranza corrispondente possono essere eseguiti sui nodi 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 solo i pod su VM spot utilizzando sia una tolleranza sia una regola nodeSelector o di affinità nodo per per 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 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 Pianificazione dei carichi di lavoro sulle VM spot.

Spot VM 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 le tue include pod che non possono essere posizionati su VM spot esistenti, il gestore della scalabilità automatica aggiunge nuovi nodi che utilizzano le 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 configurato per l'uso di upgrade di sovraccarico, GKE crea nodi di sovraccarico Spot VM. Tuttavia, GKE non attende Fai in modo che le VM siano pronte prima di contrassegnare come non pianificabili e svuotare i nodi esistenti, poiché le VM spot non forniscono alcuna garanzia di disponibilità. Per saperne di più, vedi Incremento upgrade.

Modifiche al comportamento di Kubernetes

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

  • Il recupero di VM spot è involontario e non è coperto dai garanzie di PodDisruptionBudgets La disponibilità potrebbe essere maggiore di quella configurata 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 non cambino di solito quando vengono ricreati i nodi, gli indirizzi IP interni ed esterni utilizzati dalle VM spot potrebbero cambiare dopo attività ricreative.
  • Usa le incompatibilità e le tolleranze dei nodi per garantire che non vengano pianificati pod critici in pool di nodi che usano 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.
di Gemini Advanced.

Passaggi successivi