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 agli errori a costi inferiori utilizzando i pod spot nei cluster Autopilot Google Kubernetes Engine (GKE).

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 rimossi da GKE ogni volta che sono necessarie risorse di calcolo per eseguire i pod standard.

Gli Spot Pod 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 pod spot 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 saperne 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 del 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 sui pod Autopilot standard.
GKE gestisce automaticamente la scalabilità automatica e la pianificazione.
GKE esegue automaticamente il taint dei 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 tuoi 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à, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione 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 località 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 in un'affinità dei nodi nella specifica del pod. GKE esegue automaticamente il provisioning dei nodi che possono eseguire 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 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 agli Spot Pod durante la preemption è di 15 secondi. Se richiedi più di 15 secondi in terminationGracePeriodSeconds, non ti verranno concessi più di 15 secondi durante la preemption. Al momento dell'espulsione, al pod viene inviato il segnale SIGTERM e deve adottare misure per arrestarsi 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'incompatibilità impedisce la pianificazione dei pod standard sui nodi che eseguono i pod spot.

Utilizzare 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, ad esempio 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à nodo 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ù estensibile per selezionare i nodi per eseguire i 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à dei nodi per richiedere pod spot, puoi specificare il tipo di affinità dei nodi da utilizzare, come segue:

requiredDuringSchedulingIgnoredDuringExecution: devono essere utilizzati i pod Spot.
preferredDuringSchedulingIgnoredDuringExecution: utilizza i pod Spot in base al massimo impegno.

Per utilizzare l'affinità dei nodi per richiedere 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 al meglio delle possibilità

Per utilizzare l'affinità nodo per richiedere pod spot in base al principio del best effort, utilizza preferredDuringSchedulingIgnoredDuringExecution. Quando richiedi Spot Pod in base a una preferenza, GKE pianifica i pod nel 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 alla creazione di nuovi nodi per i pod spot, potresti notare più pod in esecuzione come pod standard che 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.

Trovare ed eliminare i podcast 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 la 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 Spot Pod esistenti che vuoi aggiornare per farli funzionare come Pod standard, puoi utilizzare uno dei seguenti metodi:

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

Con entrambi i metodi, potresti riscontrare piccole interruzioni del workload.

Ricrea il workload

I seguenti passaggi mostrano come eliminare la deployment esistente e applicare un manifest aggiornato 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 corretto di nodo, 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 della tua implementazione. 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 selettore di nodi per i pod spot e la tolleranza che GKE ha aggiunto 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 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 pulire.

Modifica il workload sul posto

I seguenti passaggi mostrano come modificare un deployment in esecuzione sul posto 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 gli Spot Pod alla specifica del workload durante l'ammissione del workload.

Apri il manifest del carico di lavoro per modificarlo 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à 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 aggiornato 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.