Questa pagina è stata tradotta dall'API Cloud Translation.

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

Autopilot

Questa pagina mostra come eseguire carichi di lavoro tolleranti ai guasti a costi inferiori utilizzando Spot Pod nei cluster Autopilot Google Kubernetes Engine (GKE).

Panoramica

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

I pod spot sono ideali per l'esecuzione di carichi di lavoro senza stato, batch o a tolleranza di errore a costi inferiori rispetto all'esecuzione di questi carichi di lavoro 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 i pod Spot nella classe di calcolo Autopilot per uso generale predefinita, nonché in classi di calcolo specializzate che soddisfano requisiti hardware specifici. Per informazioni su queste classi di calcolo, consulta Classi di calcolo in Autopilot.

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

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

Vantaggi

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

Prezzi inferiori rispetto all'esecuzione degli stessi carichi di lavoro su pod Autopilot standard.
GKE gestisce automaticamente la scalabilità automatica e la pianificazione.
GKE contamina automaticamente i nodi su cui vengono eseguiti 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 operazioni:

Attiva l'API Google Kubernetes Engine.

Attiva l'API Google Kubernetes Engine

Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti le posizioni predefinite, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location.

Richiedere 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 nodeSelector o node affinity nella specifica del pod. GKE esegue automaticamente il provisioning dei nodi che possono eseguire pod Spot.

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

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

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

Utilizzare 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 deployment, come nell'esempio seguente:

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

Utilizzare l'affinità dei nodi per richiedere pod Spot

In alternativa, puoi utilizzare l'affinità dei nodi per richiedere i pod spot. L'affinità dei nodi offre un modo più estendibile per selezionare i nodi su cui eseguire i carichi di lavoro. Ad esempio, puoi combinare diversi criteri di selezione per avere un maggiore controllo sulla pubblicazione dei pod. Quando utilizzi l'affinità dei nodi per richiedere pod Spot, puoi specificare il tipo di affinità dei nodi da utilizzare, come segue:

requiredDuringSchedulingIgnoredDuringExecution: devi utilizzare i pod Spot.
preferredDuringSchedulingIgnoredDuringExecution: utilizza i pod Spot su una base migliore.

Per utilizzare l'affinità dei nodi 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: 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 i pod Spot in base alla 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 in grado di eseguire pod Spot, se le risorse di calcolo sono disponibili.
Nuovi nodi standard.

Poiché GKE preferisce i nodi standard esistenti con capacità allocatile 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.

Richieste per pod prerilasciabili

I cluster Autopilot supportano le richieste di pod preemptibili utilizzando il selettorecloud.google.com/gke-preemptible. Per i pod che utilizzano questo selettore viene eseguita automaticamente la migrazione ai pod Spot e il selettore viene modificato in cloud.google.com/gke-spot.

Trovare ed eliminare i pod terminati

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

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

Interrompere l'utilizzo dei pod Spot da parte dei carichi di lavoro

Se hai pod Spot esistenti che vuoi aggiornare in modo che vengano eseguiti come pod standard, puoi utilizzare uno dei seguenti metodi:

Rigenera il carico di lavoro: elimina il deployment, rimuovi le righe nel manifest che selezionano i pod spot e poi applica il manifest del deployment aggiornato al cluster.
Modifica il workload: modifica la specifica di deployment mentre i pod sono in esecuzione nel cluster.

Con entrambi i metodi, potresti riscontrare lievi interruzioni del carico di lavoro.

Ricrea il workload

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

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

Scrivi la specifica del carico di lavoro 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 file manifest aggiornato.
Elimina e riapplica il manifest di 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 ripulire.

Modificare il workload in situ

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

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

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 carichi di lavoro, 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à dei nodi per i pod Spot e la tolleranza aggiunta da GKE al manifest, come nell'esempio seguente:

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 file manifest aggiornato e chiudi l'editor di testo. La configurazione dell'oggetto aggiornata indica a GKE che i pod devono essere eseguiti su nodi on demand. GKE ricrea i pod per posizionarli su nuovi nodi on demand.

Verificare che i carichi di lavoro vengano eseguiti su nodi on demand

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

Controlla il carico di lavoro:

kubectl describe deployment DEPLOYMENT_NAME

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