Estendi 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 avviati da GKE

Le rimozioni dei pod sono una parte normale dell'esecuzione dei carichi di lavoro su Kubernetes. GKE rimuove i carichi di lavoro durante eventi pianificati, come upgrade automatici dei nodi e scale down 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 rimuova il pod. Per gli upgrade automatici dei nodi, il periodo di tolleranza può durare fino a un'ora. Per gli eventi di scale down, il periodo di tolleranza può durare fino a 10 minuti.

Kubernetes dispone di funzionalità integrate che i container possono utilizzare per gestire agevolmente le eliminazioni, come i PodDisruptionBudgets e i PodDisruptionBudgets. Tuttavia, alcuni carichi di lavoro, ad esempio code batch o server di gioco multiplayer, devono essere eseguiti per un periodo di tempo più lungo per essere rimossi. 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 rimuovere carichi di lavoro specifici per un massimo di 7 giorni.

Casi d'uso

Ecco alcune situazioni in cui potresti voler dire a GKE di evitare di rimuovere i carichi di lavoro:

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

Prezzi

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

  • I cluster Autopilot applicano valori minimi più elevati per le richieste di risorse dei pod di durata estesa. I cluster Autopilot ti addebitano le richieste di risorse dei pod in esecuzione. Non ti viene addebitato l'overhead del sistema o la capacità dei nodi inutilizzata.
  • L'utilizzo dei pod di durata estesa potrebbe aumentare il numero di nodi nel cluster, con ripercussioni sull'utilizzo e sulla scalabilità degli indirizzi IP. L'esecuzione di DaemonSet su ogni nodo comporta un numero maggiore di DaemonSet nel cluster.

Per i dettagli sui prezzi, consulta 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
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.

Limitazioni

  • Non puoi richiedere tempi di esecuzione estesi per i pod spot.
  • I tempi di pull delle immagini vengono conteggiati per il calcolo del tempo di esecuzione esteso.
  • Puoi avere un massimo di 50 carichi di lavoro di durata estesa (con richieste di CPU diverse) in ogni cluster. Ciò significa che fino a 50 insiemi diversi di valori di richiesta della CPU, dopo aver superato i valori minimi delle risorse Autopilot, i rapporti e i controlli delle dimensioni di incremento, 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 posiziona ciascun pod di tempo di esecuzione esteso sul proprio nodo. Questo comportamento garantisce lo fare lo scale down dei nodi se sono sottoutilizzati.

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 avvenire uno scale down o un upgrade automatico dei nodi.

Considerazioni e consigli

Quando utilizzi questa funzionalità, tieni presente quanto segue:

  • I pod di durata estesa non sono protetti dall'eliminazione basata sulla priorità. Se utilizzi PriorityClass di Kubernetes, prendi in considerazione i metodi seguenti per ridurre al minimo la probabilità di rimozione basata sulla priorità:
    • Assicurati che i pod di durata estesa utilizzino il valore PriorityClass con priorità più elevata, in modo che gli altri pod utente non eliminino i pod di durata estesa.
    • Utilizza la separazione dei carichi di lavoro per eseguire pod di durata estesa separatamente dagli altri pod.
  • I pod di sistema vengono eseguiti con la massima priorità e possono sempre rimuovere i pod di durata estesa. Per ridurre al minimo le probabilità che ciò accada, GKE pianifica i pod di sistema sul nodo prima di pianificare il pod con durata estesa.
  • I pod di durata estesa possono comunque essere rimossi all'inizio delle seguenti situazioni:
    • Eliminazione per creare spazio per pod utente con priorità più elevata (utilizzando un valore PriorityClass più elevato)
    • Rimozione per fare spazio ai componenti di sistema di Kubernetes
    • Eliminazione dell'esaurimento della memoria kubelet se il pod utilizza più memoria di quella richiesta (OOMKill)
    • Eventi di manutenzione delle VM di Compute Engine. I tipi di macchine ottimizzate per l'acceleratore hanno maggiori probabilità di essere interessati da questi eventi perché queste macchine non supportano la migrazione live.
    • Riparazioni automatiche dei nodi
    • Eventi avviati dall'utente come 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 consentendoti di continuare a pagare per questi nodi. Inoltre, i pod non sono protetti dalle rimozioni causate dagli upgrade automatici dei nodi.

Passaggi successivi