Estendere la durata di esecuzione dei pod Autopilot

Questa pagina mostra come richiedere tempi di esecuzione estesi per i pod prima che vengano eliminati da Google Kubernetes Engine (GKE).

Informazioni sull'eliminazione dei pod avviata da GKE

L'eliminazione dei pod è una parte normale dell'esecuzione dei carichi di lavoro su Kubernetes. GKE elimina i carichi di lavoro durante gli eventi pianificati, come gli upgrade automatici dei nodi e le riduzioni della scalabilità automatica, per garantire che i nodi siano aggiornati e ottimizzati per un utilizzo efficiente delle risorse. Per impostazione predefinita, GKE invia un segnale di terminazione al container non appena si verifica l'evento, dopodiché il container ha un periodo di tolleranza per terminare prima che Kubernetes elimini il pod. Per gli upgrade automatici dei nodi, il periodo di tolleranza può durare fino a un'ora. Per gli eventi di riduzione, il periodo di tolleranza può durare fino a 10 minuti.

Kubernetes dispone di funzionalità integrate che i container possono utilizzare per gestire con garbo le eliminazioni, come PodDisruptionBudgets e i periodi di terminazione con garbo. Tuttavia, alcuni carichi di lavoro, come le code batch o i server di gioco multiplayer, devono essere eseguiti per un periodo di tempo più lungo prima di essere eliminati. Il periodo di tolleranza predefinito concesso da GKE durante le eliminazioni avviate da GKE potrebbe non essere sufficiente per questi carichi di lavoro. In queste situazioni, puoi indicare ad Autopilot di evitare di eliminare carichi di lavoro specifici per un massimo di 7 giorni.

Puoi richiedere un tempo di esecuzione esteso per i carichi di lavoro in esecuzione nei cluster Autopilot o per i carichi di lavoro in modalità Autopilot in GKE Standard.

Casi d'uso

Di seguito sono riportate alcune situazioni in cui potresti voler indicare a GKE di evitare di eliminare i carichi di lavoro:

  • Esegui server di gioco multiplayer che espellerebbero i giocatori dalle loro sessioni se i server terminassero in anticipo.
  • Esegui software di videoconferenza audio o video che interromperebbe le riunioni in corso se i server terminassero.
  • Esegui attività che richiedono tempo per essere completate e la terminazione anticipata causerebbe la perdita del lavoro in corso.
  • Esegui un servizio stateful meno tollerante alle interruzioni e vuoi ridurre al minimo la frequenza con cui si verificano.

Prezzi

Puoi richiedere tempi di esecuzione estesi per i pod senza costi aggiuntivi. Tuttavia, tieni presente le seguenti modifiche del comportamento che potrebbero influire sui prezzi:

  • Autopilot applica valori minimi più elevati per le richieste di risorse dei pod di lunga durata. Autopilot ti addebita le richieste di risorse dei pod in esecuzione. Non ti vengono addebitati costi per l'overhead di sistema o per la capacità del nodo inutilizzata.
  • L'utilizzo di pod di lunga durata potrebbe aumentare il numero di nodi nel cluster, il che potrebbe influire sull'utilizzo degli indirizzi IP e sulla scalabilità. Se hai DaemonSet in esecuzione su ogni nodo, nel cluster sono presenti più DaemonSet.

Per i dettagli sui prezzi, consulta la pagina Prezzi di Autopilot.

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à, installa e poi inizializza la gcloud CLI. Se hai installato in precedenza gcloud CLI, scarica l'ultima versione eseguendo il gcloud components update comando. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  • Assicurati di avere un cluster GKE esistente.

Limitazioni

  • Non puoi richiedere tempi di esecuzione estesi per i pod Spot.
  • I tempi di pull delle immagini vengono conteggiati nel calcolo del tempo di esecuzione esteso.
  • In ogni cluster puoi avere un massimo di 50 carichi di lavoro di lunga durata (con richieste di CPU diverse). Ciò significa che in ogni cluster possono avere una durata estesa fino a 50 insiemi diversi di valori di richiesta di CPU, dopo aver superato i controlli di valori minimi, rapporti e dimensioni dell'incremento delle risorse di Autopilot.
  • Non puoi utilizzare l'affinità tra pod di Kubernetes nei pod di lunga durata.
  • Quando possibile, GKE inserisce ogni pod di lunga durata sul proprio nodo. Questo comportamento consente di garantire che i nodi possano essere fare lo scale down se sono sottoutilizzati.
  • Non puoi richiedere tempi di esecuzione estesi per i pod che hanno come target le classi di computing personalizzate personalizzate.

Richiedi un tempo di esecuzione esteso

Per richiedere un tempo di esecuzione esteso per un pod, imposta l'annotazione cluster-autoscaler.kubernetes.io/safe-to-evict di Kubernetes su false nella specifica del pod.

  1. Salva il seguente manifest come extended-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: extended-pods
  labels:
    duration: extended
spec:
  selector:
    matchLabels:
      duration: extended
  template:
    metadata:
      annotations:
        cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
      labels:
        duration: extended
    spec:
      containers:
      - name: example-container
        image: registry.k8s.io/pause
        resources:
          requests:
            cpu: 200m

  2. Crea il deployment:

    kubectl create -f extended-deployment.yaml

I pod continuano a essere eseguiti per almeno 7 giorni prima che possa verificarsi una riduzione o un upgrade automatico dei nodi.

Considerazioni e consigli

Quando utilizzi questa funzionalità, tieni presente quanto segue:

  • I pod di lunga durata non sono protetti dall'eliminazione basata sulla priorità. Se utilizzi PriorityClass di Kubernetes, valuta i seguenti metodi per ridurre al minimo la probabilità di eliminazione basata sulla priorità:
    • Assicurati che i pod di lunga durata utilizzino la PriorityClass con la priorità più alta, in modo che gli altri pod utente non eliminino i pod di lunga durata.
    • Utilizza la separazione dei carichi di lavoro per eseguire i pod di lunga durata separatamente dagli altri pod.
  • I pod di sistema vengono eseguiti con la priorità più alta e potranno sempre eliminare i pod di lunga durata. Per ridurre al minimo la probabilità che ciò accada, GKE pianifica i pod di sistema sul nodo prima di pianificare il pod di lunga durata.

  • I pod di lunga durata possono comunque essere eliminati in anticipo nelle seguenti situazioni:

  • Puoi utilizzare l'annotazione cluster-autoscaler.kubernetes.io/safe-to-evict nei cluster Standard, ma il risultato non è lo stesso. I pod vengono eseguiti a tempo indeterminato anche se si verifica un evento di riduzione, impedendo l'eliminazione dei nodi sottoutilizzati e comportando il pagamento continuo di questi nodi. Inoltre, i pod non sono protetti dalle eliminazioni causate dagli upgrade automatici dei nodi.

Passaggi successivi