Estendere il tempo di esecuzione dei pod Autopilot

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

Informazioni sull'eliminazione dei pod avviata da GKE

L'espulsione dei pod è una parte normale dell'esecuzione dei carichi di lavoro su Kubernetes. GKE espelle i carichi di lavoro durante gli eventi pianificati, come gli upgrade automatici dei nodi e la riduzione 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 espella 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 correttamente le espulsioni, ad esempio PodDisruptionBudgets e periodi di terminazione controllata. Tuttavia, alcuni carichi di lavoro, come le code batch o i server di giochi multiplayer, devono essere eseguiti per un periodo di tempo più lungo prima di essere rimossi. Il periodo di tolleranza predefinito concesso da GKE durante le espulsioni avviate da GKE potrebbe non essere sufficiente per questi carichi di lavoro. In queste situazioni, puoi dire ad Autopilot di evitare di eliminare carichi di lavoro specifici per un massimo di 7 giorni.

Casi d'uso

Alcune situazioni in cui potresti voler indicare a GKE di evitare l'espulsione dei workload includono:

  • Gestisci server di gioco multiplayer che espellerebbero i giocatori dalle loro sessioni se i server terminassero in anticipo.
  • Esegui software di audioconferenza o videoconferenza che interromperebbero le riunioni in corso se i server venissero chiusi.
  • Esegui attività che richiedono tempo per essere completate e l'interruzione 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 interruzioni.

Prezzi

Puoi richiedere tempi di esecuzione estesi per i tuoi Pod senza costi aggiuntivi. Tuttavia, considera le seguenti modifiche comportamentali che potrebbero influire sui tuoi prezzi:

  • I cluster Autopilot applicano valori minimi più elevati per le richieste di risorse dei pod di lunga durata. I cluster Autopilot ti addebitano le richieste di risorse dei pod in esecuzione. Non ti viene addebitato alcun costo per l'overhead di sistema o per la capacità del nodo inutilizzata.
  • L'utilizzo di pod di durata estesa potrebbe aumentare il numero di nodi nel cluster, il che potrebbe influire sull'utilizzo e sulla scalabilità degli indirizzi IP. Se hai DaemonSet che vengono eseguiti su ogni nodo, nel cluster ci saranno più DaemonSet,

Per i dettagli sui prezzi, consulta Prezzi di Autopilot.

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 inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

Limitazioni

  • Non puoi richiedere tempi di esecuzione estesi per i tuoi Spot Pod.
  • I tempi di pull delle immagini vengono conteggiati durante il 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 fino a 50 diversi set di valori di richiesta CPU, dopo aver superato i controlli di incrementi, proporzioni e minimi delle risorse di Autopilot, possono avere una durata estesa in ogni cluster.
  • Non puoi utilizzare l'affinità tra pod di Kubernetes nei pod di durata estesa.
  • Quando possibile, GKE inserisce ogni pod con tempo di esecuzione esteso sul proprio nodo. Questo comportamento garantisce 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 classi di calcolo personalizzate.

Richiedi tempo di esecuzione esteso

Per richiedere un tempo di esecuzione esteso per un pod, imposta l'annotazione Kubernetes cluster-autoscaler.kubernetes.io/safe-to-evict 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 uno scale down 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'espulsione basata sulla priorità. Se utilizzi Kubernetes PriorityClasses, valuta i seguenti metodi per ridurre al minimo la probabilità di espulsione basata sulla priorità:
    • Assicurati che i pod di lunga durata utilizzino PriorityClass con la priorità più alta, in modo che gli altri pod utente non vengano eliminati.
    • 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 saranno sempre in grado di rimuovere 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 durata estesa.
  • I pod di durata estesa possono comunque essere eliminati in anticipo nelle seguenti situazioni:
    • Espulsione per fare spazio ai pod utente con priorità più alta (utilizzando una PriorityClass più alta)
    • Rimozione per fare spazio ai componenti di sistema Kubernetes
    • kubelet out-of-memory eviction se il pod utilizza più memoria di quella richiesta (OOMKill)
    • Eventi di manutenzione delle VM di Compute Engine. I tipi di macchine ottimizzati per gli acceleratori hanno maggiori probabilità di essere interessati da questi eventi perché non supportano la migrazione live.
    • Riparazioni automatiche dei nodi
    • Eventi avviati dall'utente, ad esempio lo svuotamento di un nodo
  • 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 scale down, impedendo l'eliminazione dei nodi sottoutilizzati e facendo sì che tu continui a pagare per questi nodi. I pod non sono protetti dalle espulsioni causate dagli upgrade automatici dei nodi.

Passaggi successivi