Estendi il tempo di esecuzione dei pod Autopilot

Questa pagina mostra come richiedere tempi di esecuzione estesi per i pod prima che rimosso 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 terminazione al container non appena si verifica un evento, dopo il quale il container ha un periodo di tolleranza per terminare prima Kubernetes rimuove 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ò arrivare fino a 10 minuti.

Kubernetes dispone di funzionalità integrate che i container possono utilizzare per gestire in modo corretto gli sfollamenti, ad esempio PodDisruptionBudget 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. Periodo di tolleranza predefinito periodo concesso da GKE durante l'avvio di GKE le eliminazioni potrebbero non essere sufficienti per questi carichi di lavoro. In queste situazioni, puoi Indica ad Autopilot di evitare la rimozione di carichi di lavoro specifici per un massimo di 7 giorni.

Casi d'uso

Alcune situazioni in cui è consigliabile chiedere a GKE di evitare l'eliminazione dei carichi di lavoro include:

  • Esegui server di gioco multiplayer che espelleno i giocatori fuori dai loro sessioni se i server sono stati arrestati in anticipo.
  • Esegui software di videoconferenze o audio che interromperebbe le riunioni in corso se i server venissero chiusi.
  • Esegui attività che richiedono tempo per essere completate e la chiusura anticipata potrebbe causare la perdita di quello 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 prolungati per i pod senza costi aggiuntivi. Tuttavia, tieni conto delle seguenti modifiche comportamentali che potrebbero influire sui prezzi:

  • Applicazione forzata dei cluster Autopilot valori minimi più elevati per le richieste di risorse dei pod di durata estesa. Autopilot ti addebitano le richieste di risorse dei pod in esecuzione. Stai 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 disponi che vengono eseguiti su ogni nodo, determina un aumento del cluster,

Per i dettagli sui prezzi, vedi Prezzi di Autopilot.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Attiva l'API Google Kubernetes Engine.
    • Attiva l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi inizializzare con gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.

Limitazioni

  • Non puoi richiedere tempi di esecuzione prolungati per i pod Spot.
  • I tempi di estrazione delle immagini vengono conteggiati durante il calcolo del tempo di esecuzione esteso.
  • Puoi avere un massimo di 50 carichi di lavoro di durata estesa (con CPU diverse richieste) in ciascun cluster. Ciò significa che fino a 50 diversi set di CPU di richiesta, dopo aver superato i valori minimi delle risorse Autopilot, e di incremento dei controlli delle dimensioni, possono avere una durata estesa in ogni cluster.
  • Non puoi utilizzare l'affinità tra pod di Kubernetes nei pod di durata estesa.
  • Ove possibile, GKE posiziona ogni pod con tempo di esecuzione esteso sul suo nodo. Questo comportamento assicura che i nodi possano fare lo scale down 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 di uno scale down o di un nodo è possibile eseguire l'upgrade automatico.

Considerazioni e consigli

Quando utilizzi questa funzionalità, tieni presente quanto segue:

  • I pod con durata estesa non sono protetti dall'eliminazione basata sulla 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 di durata estesa utilizzino la priorità massima PriorityClass, in modo che i pod di altri utenti non elimino la tua durata estesa di pod.
    • Utilizza le funzionalità di 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 potranno sempre espellere i pod con durata estesa. Per minimizzare la probabilità, GKE pianifica i pod di sistema sul nodo prima di pianificare di un pod a durata estesa.
  • I pod con durata estesa possono comunque essere rimossi nelle prime fasi dei seguenti pod situazioni seguenti:
    • Eliminazione per liberare spazio per i pod degli utenti con priorità più elevata (utilizzando un modello PriorityClass)
    • Eliminazione per liberare spazio per i componenti di sistema di 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 in 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