Estendi il tempo 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

Le eliminazioni dei pod sono una parte normale dell'esecuzione di carichi di lavoro su Kubernetes. GKE rimuove i carichi di lavoro durante gli eventi pianificati, come gli upgrade automatici dei nodi e le 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 elimini 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 è dotato di funzionalità integrate che i container possono utilizzare per gestire agevolmente gli eliminamenti, come PodDisruptionBudgets e i periodi di terminazione corretti. 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 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 chiedere ad Autopilot di evitare di eliminare carichi di lavoro specifici per un massimo di 7 giorni.

Casi d'uso

Di seguito sono riportate alcune situazioni in cui potresti voler comunicare a GKE di evitare la rimozione dei carichi di lavoro:

  • Esegui server di gioco multiplayer che, in caso di terminazione anticipata dei server, avrebbero fatto uscire i giocatori dalle loro sessioni.
  • Utilizzi un software per videoconferenze o audio che interromperebbe le riunioni in corso in caso di chiusura dei server.
  • Esegui attività che richiedono tempo per essere completate e la risoluzione anticipata causerebbe la perdita del lavoro in corso.
  • Esegui un servizio stateful meno tollerante alle interruzioni e vuoi ridurre al minimo la frequenza delle interruzioni.

Prezzi

Puoi richiedere tempi di esecuzione prolungati per i pod senza costi aggiuntivi. Tuttavia, prendi in considerazione 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 alcun costo per l'overhead del sistema o per la capacità dei nodi inutilizzata.
  • L'uso di pod di durata estesa potrebbe aumentare il numero di nodi nel cluster, con possibili ripercussioni sull'utilizzo e sulla scalabilità dell'indirizzo IP. Se disponi di DaemonSet in esecuzione su ogni nodo, il risultato sarà un numero maggiore di DaemonSet nel cluster,

Per i dettagli dei prezzi, vedi 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 quindi initialize gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.

Limitazioni

  • Non puoi richiedere tempi di esecuzione prolungati per i pod Spot.
  • Nel calcolo del tempo di esecuzione esteso vengono conteggiati i tempi di pull delle immagini.
  • 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 diversi set di valori delle richieste di CPU, dopo aver superato il minimo di 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 ogni pod con 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 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 sia possibile fare lo scale down o un upgrade automatico dei nodi.

Considerazioni e consigli

Quando utilizzi questa funzionalità, considera quanto segue:

  • I pod con durata estesa non sono protetti dall'eliminazione basata sulla priorità. Se utilizzi Kubernetes PriorityClasss, prendi in considerazione i seguenti metodi per ridurre al minimo la probabilità di eliminazione basata sulla priorità:
    • Assicurati che i pod di durata estesa utilizzino il valore PriorityClass con la priorità più alta, in modo che i pod di altri utenti non elimino i pod di durata estesa.
    • Usa la separazione dei carichi di lavoro per eseguire i pod di durata estesa 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 durata estesa. Per ridurre al minimo la probabilità che ciò si verifichi, GKE pianifica i pod di sistema sul nodo prima di pianificare il pod di durata estesa.
  • I pod con durata estesa possono comunque essere rimossi nelle seguenti situazioni:
    • Eliminazione per creare spazio per i pod utente con priorità più alta (utilizzando un valore PriorityClass superiore)
    • Eliminazione per liberare spazio per i componenti di sistema di Kubernetes
    • Eliminazione della memoria insufficiente per kubelet se il pod utilizza più memoria di quella richiesta (OOMKill)
    • Eventi di manutenzione delle VM di Compute Engine. I tipi di macchine ottimizzati per l'acceleratore hanno maggiori probabilità di essere interessati da questi eventi, perché 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 i nodi. Inoltre, i pod non sono protetti da eliminazioni causate dagli upgrade automatici dei nodi.

Passaggi successivi