Estendere il tempo di esecuzione dei pod Autopilot

Questa pagina mostra come richiedere tempi di esecuzione estesi per i pod prima che vengano espulsi 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 esegue l'espulsione dei 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 interruzione al contenitore non appena si verifica l'evento, dopodiché il contenitore ha un periodo di tolleranza per l'interruzione prima che Kubernetes escluda il pod. Per gli upgrade automatici dei nodi, il periodo di tolleranza può essere fino a un'ora. Per gli eventi di riduzione, il periodo di tolleranza può essere fino a 10 minuti.

Kubernetes dispone di funzionalità integrate che i container possono utilizzare per gestire in modo corretto gli sfollamenti, ad esempio PodDisruptionBudgets e periodi di interruzione graduale. 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 espulsi. 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 chiedere ad Autopilot di evitare di svuotare carichi di lavoro specifici per un massimo di 7 giorni.

Casi d'uso

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

  • Gestisci server di giochi multiplayer che rimuoveranno i giocatori dalle loro sessioni se i server si arrestano in modo anomalo.
  • Esegui software di videoconferenze o audio che interromperebbe le riunioni in corso se i server venissero terminati.
  • Esegui attività che richiedono tempo per essere completate e l'interruzione anticipata causerebbe la perdita del lavoro in corso.
  • Gestisci un servizio con stato meno tollerante alle interruzioni e vuoi minimizzare la frequenza con cui si verificano.

Prezzi

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

  • I cluster Autopilot applicano valori minimi più elevati per le richieste di risorse dei pod con 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'utilizzo di pod con durata estesa potrebbe aumentare il numero di nodi nel cluster, il che potrebbe influire sull'utilizzo e sulla scalabilità degli indirizzi IP. Se hai gaggi che vengono eseguiti su ogni nodo, il numero di gaggi nel cluster aumenta.

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à, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.

Limitazioni

  • Non puoi richiedere tempi di esecuzione estesi per i pod Spot.
  • I tempi di estrazione 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 durata estesa (con richieste di CPU diverse). Ciò significa che fino a 50 diversi insiemi di valori di richiesta della CPU, dopo aver superato i controlli minimi, i rapporti e le dimensioni degli incrementi delle risorse di Autopilot, possono avere una durata estesa in ogni cluster.
  • Non puoi utilizzare l'affinità tra pod di Kubernetes nei pod con durata estesa.
  • Ove possibile, GKE posiziona ogni pod con tempo di esecuzione esteso sul suo nodo. Questo comportamento garantisce che i nodi possano essere fare lo scale down se sono sottoutilizzati.

Richiedere 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 funzionare per almeno 7 giorni prima che possa verificarsi un ridimensionamento o un upgrade automatico del nodo.

Considerazioni e consigli

Quando utilizzi questa funzionalità, tieni presente quanto segue:

  • I pod con durata estesa non sono protetti dall'espulsione in base alla priorità. Se utilizzi PriorityClasses di Kubernetes, valuta i seguenti metodi per ridurre al minimo la probabilità di espulsione in base alla priorità:
    • Assicurati che i pod con durata estesa utilizzino la priorità più elevata PriorityClass, in modo che gli altri pod degli utenti non esilino i pod con durata estesa.
    • Utilizza la separazione dei carichi di lavoro per eseguire pod con durata estesa separatamente dagli altri pod.
  • I pod di sistema vengono eseguiti con la massima priorità e potranno sempre espellere i pod con durata estesa. Per ridurre al minimo questa probabilità, GKE pianifica i pod di sistema sul nodo prima di pianificare il pod con durata estesa.
  • I pod con durata estesa possono comunque essere espulsi in anticipo nelle seguenti situazioni:
    • Sfollamento per fare spazio ai pod utente con priorità più elevata (utilizzando un valore PriorityClass più elevato)
    • Sfollamento per fare spazio ai componenti di sistema Kubernetes
    • Eliminazone di kubelet per esaurimento della memoria 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 in tempo reale.
    • 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 facendoti continuare a pagare per questi nodi. Inoltre, i pod non sono protetti dagli sfollamenti causati dagli upgrade automatici dei nodi.

Passaggi successivi