Esegui carichi di lavoro a tolleranza di errore a costi inferiori nei pod spot

Autopilot

Questa pagina mostra come eseguire carichi di lavoro a tolleranza di errore a costi inferiori utilizzando i pod spot nei cluster Autopilot di Google Kubernetes Engine (GKE).

Panoramica

Nei cluster GKE Autopilot, i pod spot sono pod che vengono eseguiti su nodi supportati da VM spot di Compute Engine. I pod spot hanno un costo inferiore rispetto ai pod Autopilot standard, ma possono essere rimossi da GKE ogni volta che sono necessarie risorse di calcolo per eseguire i pod standard.

I pod spot sono ideali per l'esecuzione di carichi di lavoro stateless, batch o a tolleranza di errore a costi inferiori rispetto all'esecuzione di questi carichi di lavoro come pod standard. Per usare i pod spot nei cluster Autopilot, modifica il manifest con la specifica dei pod.

Puoi eseguire pod spot sulla classe di calcolo Autopilot per uso generico predefinita, nonché su classi di calcolo specializzate che soddisfano requisiti hardware specifici. Per informazioni su queste classi di computing, consulta Classi di computing in Autopilot.

Per saperne di più sui prezzi per i pod spot nei cluster Autopilot, consulta i prezzi di Google Kubernetes Engine.

Vantaggi

L'utilizzo dei pod spot nei cluster Autopilot offre i seguenti vantaggi:

Prezzi più bassi rispetto all'esecuzione degli stessi carichi di lavoro su pod Autopilot standard.
GKE gestisce automaticamente la scalabilità automatica e la pianificazione.
GKE incompatibilità automaticamente i nodi che eseguono i pod Spot per garantire che i pod standard, come i carichi di lavoro critici, non vengano pianificati su questi nodi. I deployment che utilizzano i pod Spot vengono aggiornati automaticamente con una tollerazione corrispondente.

Requisiti e limitazioni

Richiede GKE versione 1.21.4 o successiva.
I pod spot sono esclusi dall'accordo sul livello del servizio di Autopilot.
GKE non può pianificare pod spot su cluster che eseguono versioni di GKE precedenti alla 1.21.4.
I cluster Autopilot supportano le richieste per i pod prerilasciabili nei cluster che eseguono GKE versione 1.21.4 o successive, utilizzando il selettore cloud.google.com/gke-preemptible. Viene eseguita la migrazione automatica dei pod che utilizzano questo selettore ai pod Spot e il selettore viene modificato in cloud.google.com/gke-spot.

Attenzione: la migrazione automatica del selettore cloud.google.com/gke-preemptible non è supportata sui cluster che eseguono versioni di GKE precedenti alla 1.21.4. Se richiedi pod prerilasciabili su questi cluster, questi avranno un comportamento prerilasciabile, ma a prezzi standard. Come best practice, evita di utilizzare pod prerilasciabili nei tuoi deployment, poiché ciò ne riduce la disponibilità senza alcun vantaggio in termini di prezzo.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

Abilita l'API Google Kubernetes Engine.

Abilita l'API Google Kubernetes Engine

Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
Nota: per le installazioni esistenti dell'interfaccia a riga di comando gcloud, assicurati di impostare le proprietà compute/region e compute/zone. Impostando le località predefinite, puoi evitare errori nellgcloud CLI come segue: One of [--zone, --region] must be supplied: Please specify location.

Richiedi pod Spot nei carichi di lavoro Autopilot

Per richiedere l'esecuzione dei pod come pod spot, utilizza l'etichetta cloud.google.com/gke-spot=true in un elemento nodeSelector o affinità nodo nella specifica del pod. GKE esegue automaticamente il provisioning dei nodi che possono eseguire pod spot.

I pod spot possono essere eliminati e terminati in qualsiasi momento, ad esempio se le risorse di calcolo sono necessarie altrove in Google Cloud. Quando si verifica una terminazione, i pod spot sul nodo di terminazione possono richiedere un periodo di tolleranza fino a 25 secondi prima della terminazione, che viene concesso al meglio delle possibilità, specificando il campo terminationGracePeriodSeconds.

Il periodo di tolleranza massimo concesso ai pod Spot durante il prerilascio è di 25 secondi. La richiesta di più di 25 secondi in terminationGracePeriodSeconds non concede più di 25 secondi durante il prerilascio. Al momento dell'eliminazione, il pod viene inviato all'indicatore SIGTERM, che dovrebbe intraprendere alcune azioni per arrestarsi durante il periodo di tolleranza.

Per Autopilot, GKE incompatibilità automaticamente i nodi creati per eseguire i pod spot e modifica questi carichi di lavoro con la tolleranza corrispondente. L'incompatibilità impedisce la pianificazione dei pod standard sui nodi che eseguono pod spot.

Utilizzo di un nodeSelector per richiedere pod spot

Puoi utilizzare un nodeSelector per richiedere pod spot in un deployment. Aggiungi l'etichetta cloud.google.com/gke-spot=true al tuo deployment, come nel seguente esempio:

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      labels:
        app: pi
    spec:
      nodeSelector:
        cloud.google.com/gke-spot: "true"
      terminationGracePeriodSeconds: 25
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

Utilizza l'affinità nodo per richiedere pod spot

In alternativa, puoi utilizzare l'affinità nodo per richiedere pod spot. L'affinità nodo offre un modo più estensibile per selezionare i nodi per l'esecuzione dei carichi di lavoro. Ad esempio, puoi combinare diversi criteri di selezione per avere un controllo più preciso su dove vengono eseguiti i pod. Quando utilizzi l'affinità nodo per richiedere i pod spot, puoi specificare il tipo di affinità nodo da utilizzare come segue:

requiredDuringSchedulingIgnoredDuringExecution: è necessario utilizzare pod spot.
preferredDuringSchedulingIgnoredDuringExecution: utilizza i pod spot secondo il criterio del "best effort".

Per utilizzare l'affinità nodo per require i pod spot in un deployment, aggiungi la seguente regola nodeAffinity al manifest del deployment:

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      labels:
        app: pi
    spec:
      terminationGracePeriodSeconds: 25
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cloud.google.com/gke-spot
                operator: In
                values:
                - "true"
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

Richiesta di pod Spot secondo il criterio del "best effort"

Per utilizzare l'affinità dei nodi per richiedere i pod Spot secondo il criterio del "best effort", utilizza preferredDuringSchedulingIgnoredDuringExecution. Quando richiedi i pod Spot come preferisci, GKE pianifica i pod in base al seguente ordine:

Nodi esistenti che possono eseguire pod spot con capacità allocabile disponibile.
Nodi standard esistenti con capacità allocabile disponibile.
Nuovi nodi che possono eseguire pod spot, se le risorse di computing sono disponibili.
Nuovi nodi standard.

Poiché GKE preferisce i nodi standard esistenti con capacità allocabile rispetto alla creazione di nuovi nodi per i pod spot, potresti notare un numero maggiore di pod in esecuzione come pod standard rispetto ai pod spot, il che ti impedisce di sfruttare appieno i prezzi inferiori dei pod spot.

Trovare ed eliminare i pod terminati

Durante la terminazione controllata dei pod, il kubelet assegna uno stato Failed e un motivo Shutdown ai pod terminati. Quando il numero di pod terminati raggiunge una soglia di 1000, la garbage collection pulisce i pod. Puoi anche eliminare manualmente i pod di chiusura utilizzando il comando seguente:

kubectl get pods --all-namespaces | grep -i shutdown | awk '{print $1, $2}' | xargs -n2 kubectl delete pod -n