Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

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

Autopilot

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

Panoramica

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

I pod spot sono ideali per eseguire workload stateless, batch o a tolleranza di errore a costi inferiori rispetto all'esecuzione di questi workload come pod standard. Per utilizzare i pod spot nei cluster Autopilot, modifica il manifest con la specifica del pod per richiedere i pod spot.

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

Per scoprire di più sui prezzi dei pod Spot nei cluster Autopilot, consulta Prezzi di Google Kubernetes Engine.

I pod spot sono esclusi dall'accordo sul livello del servizio di Autopilot.

Vantaggi

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

Prezzi inferiori rispetto all'esecuzione degli stessi carichi di lavoro sui pod Autopilot standard.
GKE gestisce automaticamente la scalabilità automatica e la pianificazione.
GKE contamina 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 tolleranza corrispondente.

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

Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare la proprietà compute/region. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

Richiedere pod spot nei carichi di lavoro Autopilot

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

I pod spot possono essere rimossi e terminati in qualsiasi momento, ad esempio se le risorse di calcolo sono richieste altrove in Google Cloud. Quando si verifica una terminazione, i pod Spot sul nodo in fase di terminazione possono richiedere un periodo di tolleranza fino a 15 secondi prima della terminazione, che viene concesso secondo il criterio del "best effort", specificando il campo terminationGracePeriodSeconds.

Il periodo di tolleranza massimo concesso ai pod spot durante la preemption è di 15 secondi. La richiesta di più di 15 secondi in terminationGracePeriodSeconds non garantisce più di 15 secondi durante la preemption. Al momento dell'espulsione, al pod viene inviato il segnale SIGTERM e deve adottare misure per l'arresto durante il periodo di tolleranza.

Per Autopilot, GKE esegue automaticamente anche il taint dei nodi creati per eseguire i pod spot e modifica questi workload con la tolleranza corrispondente. L'impostazione di incompatibilità impedisce la pianificazione dei pod standard sui nodi che eseguono pod Spot.

Utilizza un nodeSelector per richiedere i pod spot

Puoi utilizzare un nodeSelector per richiedere pod spot in un deployment. Aggiungi l'etichetta cloud.google.com/gke-spot=true al 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: 15
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

Utilizza l'affinità dei nodi per richiedere pod spot

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

requiredDuringSchedulingIgnoredDuringExecution: Deve utilizzare i pod Spot.
preferredDuringSchedulingIgnoredDuringExecution: utilizza i pod Spot nel miglior modo possibile.

Per utilizzare l'affinità dei nodi per richiedere 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: 15
      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 pod Spot secondo il criterio del "best effort", utilizza preferredDuringSchedulingIgnoredDuringExecution. Quando richiedi Spot Pod in base a una preferenza, 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 calcolo 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 che un numero maggiore di pod viene eseguito come pod standard anziché come pod Spot, il che ti impedisce di sfruttare appieno i prezzi più bassi dei pod Spot.

Richieste di pod prerilasciabili

I cluster Autopilot supportano le richieste di pod preemptive utilizzando il selettore cloud.google.com/gke-preemptible. I pod che utilizzano questo selettore vengono migrati automaticamente ai pod spot e il selettore viene modificato in cloud.google.com/gke-spot.

Trova ed elimina i pod terminati

Durante la terminazione controllata del pod, kubelet assegna lo stato Failed e il motivo Shutdown ai pod terminati. Quando il numero di pod terminati raggiunge una soglia di 1000, la raccolta dei rifiuti pulisce i pod. Puoi anche eliminare manualmente i pod di arresto utilizzando il seguente comando:

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

Impedire ai carichi di lavoro di utilizzare i pod spot

Se hai pod spot esistenti che vuoi aggiornare per l'esecuzione come pod standard, puoi utilizzare uno dei seguenti metodi:

Ricrea il workload: elimina il deployment, rimuovi le righe nel manifest che selezionano i pod Spot, quindi applica il manifest del deployment aggiornato al cluster.
Modifica il workload: modifica la specifica del deployment mentre i pod sono in esecuzione nel cluster.

Con entrambi questi metodi, potresti riscontrare interruzioni minime del workload.

Ricrea il workload

I passaggi seguenti mostrano come eliminare il deployment esistente e applicare un manifest di aggiornamento al cluster. Puoi anche utilizzare questi passaggi per altri tipi di carichi di lavoro Kubernetes, come i job.

Per assicurarti che GKE posizioni i pod aggiornati sul tipo di nodo corretto, devi esportare lo stato esistente del workload dal server API Kubernetes in un file e modificarlo.

Scrivi la specifica del workload in un file YAML:
```
kubectl get deployment DEPLOYMENT_NAME -o yaml > DEPLOYMENT_NAME-on-demand.yaml
```
Sostituisci DEPLOYMENT_NAME con il nome del deployment. Per altri tipi di carichi di lavoro, come job o pod, utilizza il nome della risorsa corrispondente nel comando kubectl get, ad esempio kubectl get pod.
Apri il file YAML in un editor di testo:
```
vi DEPLOYMENT_NAME-on-demand.yaml
```

Rimuovi il nodeSelector per i pod spot e la tolleranza aggiunta da GKE per i pod spot dal file:

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
  # lines omitted for clarity
spec:
  progressDeadlineSeconds: 600
  replicas: 6
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      pod: nginx-pod
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
    # lines omitted for clarity
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: web-server
        resources:
          limits:
            ephemeral-storage: 1Gi
          requests:
            cpu: 500m
            ephemeral-storage: 1Gi
            memory: 2Gi
        securityContext:
          capabilities:
            drop:
            - NET_RAW
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      nodeSelector:
        cloud.google.com/gke-spot: "true"
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext:
        seccompProfile:
          type: RuntimeDefault
      terminationGracePeriodSeconds: 15
      tolerations:
      - effect: NoSchedule
        key: kubernetes.io/arch
        operator: Equal
        value: amd64
      - effect: NoSchedule
        key: cloud.google.com/gke-spot
        operator: Equal
        value: "true"
status:
  #lines omitted for clarity

Devi rimuovere sia la tolleranza sia il nodeSelector per indicare a GKE che i pod devono essere eseguiti su nodi on demand anziché su nodi Spot.

Salva il manifest di aggiornamento.
Elimina e riapplica il manifest del deployment al cluster:
```
kubectl replace -f DEPLOYMENT_NAME-on-demand.yaml
```
La durata di questa operazione dipende dal numero di pod che GKE deve terminare e pulire.

Modificare il workload sul posto

I passaggi seguenti mostrano come modificare un deployment in esecuzione in loco per indicare a GKE che i pod devono essere eseguiti su nodi on demand. Puoi utilizzare questi passaggi anche per altri tipi di carichi di lavoro Kubernetes, come i job.

Devi modificare l'oggetto workload nell'API Kubernetes perché GKE aggiunge automaticamente una tolleranza per i pod spot alla specifica del workload durante l'ammissione del workload.

Apri il manifest del carico di lavoro per la modifica in un editor di testo:
```
kubectl edit deployment/DEPLOYMENT_NAME
```
Sostituisci DEPLOYMENT_NAME con il nome del deployment. Per altri tipi di workload, come job o pod, utilizza il nome della risorsa corrispondente nel comando kubectl edit, ad esempio kubectl edit pod/POD_NAME.

Nell'editor di testo, elimina il selettore di nodi o la regola di affinità nodo per i pod spot e la tolleranza che GKE ha aggiunto al manifest, come nel seguente esempio:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      type: dev
  template:
    metadata:
      labels:
        type: dev
    spec:
      nodeSelector:
        cloud.google.com/gke-spot: "true"
      tolerations:
      - effect: NoSchedule
        key: cloud.google.com/gke-spot
        operator: Equal
        value: "true"
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

Salva il manifest di aggiornamento e chiudi l'editor di testo. La configurazione dell'oggetto aggiornato indica a GKE che i pod devono essere eseguiti su nodi on demand. GKE ricrea i pod per posizionarli su nuovi nodi on demand.

Verifica che i carichi di lavoro vengano eseguiti sui nodi on demand

Per verificare che i carichi di lavoro aggiornati non vengano più eseguiti sui pod Spot, ispeziona il carico di lavoro e cerca la tolleranza per i pod Spot:

Ispeziona il workload:

kubectl describe deployment DEPLOYMENT_NAME

L'output non mostra una voce per cloud.google.com/gke-spot nel campo spec.tolerations.