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

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, gli upgrade e lo scale down della scalabilità automatica dei nodi, aggiornate e ottimizzate per un utilizzo efficiente delle risorse. Per impostazione predefinita, GKE invia un segnale di terminazione al container non appena si verifica un evento, dopodiché 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 ha funzionalità integrate che i container possono usare per gestire agevolmente eliminazioni, ad esempio PodDisruptionBudgets e la risoluzione grata periodi. Tuttavia, alcuni carichi di lavoro, come code batch o server di gioco multiplayer, richiedono per un periodo di tempo più lungo prima di essere rimossi. 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.
  • Usi software per videoconferenze o audio che disturbano l'attività in corso riunioni in caso di terminazione dei server.
  • Esegui attività che richiedono tempo per essere completate e la chiusura anticipata potrebbe causare la perdita di quello in corso.
  • Esegui un servizio stateful meno tollerante alle interruzioni e vuoi per ridurre al minimo la frequenza delle interruzioni.

Prezzi

Puoi richiedere tempi di esecuzione prolungati per i pod senza costi aggiuntivi. Tuttavia, prendi in considerazione i seguenti cambiamenti comportamentali che potrebbero influire sulle tue 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'uso di pod di durata estesa potrebbe aumentare il numero di nodi nel tuo questo potrebbe influire sull'utilizzo e sulla scalabilità dell'indirizzo 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.
    • Abilita 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.
  • 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 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.
  • Quando possibile, GKE posiziona ogni pod con tempo di esecuzione esteso di un nodo autonomo. Questo comportamento assicura che i nodi possano fare lo scale down se sono sottoutilizzati.

Richiedi tempo di esecuzione esteso

Per richiedere tempo di esecuzione esteso per un pod, imposta il parametro Kubernetes Annotazione cluster-autoscaler.kubernetes.io/safe-to-evict per false in la 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à, considera quanto segue:

  • I pod con durata estesa non sono protetti dall'eliminazione basata sulla priorità. Se utilizza Kubernetes PriorityClasss, prendi in considerazione i seguenti metodi per ridurre al minimo la probabilità di eliminazione:
      .
    • 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 priorità più alta e potranno sempre essere rimossi di pod di 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ù alta (utilizzando un modello PriorityClass)
    • Eliminazione per liberare spazio per i componenti di sistema di Kubernetes
    • Eliminazione dalla memoria insufficiente di kubelet se il pod utilizza più memoria di quella richiesta (OOMKill)
    • Eventi di manutenzione delle VM di Compute Engine. Tipi di macchine ottimizzati per l'acceleratore sono più propensi a essere interessati da questi eventi perché Le macchine non supportano 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 in cluster standard, ma il risultato non è lo stesso. I pod vengono eseguiti all'infinito anche se si verifica un evento di scale down, impedisce l'eliminazione dei nodi, continua a pagare per questi nodi. Inoltre, i pod non sono protette dalle eliminazioni causate dagli upgrade automatici dei nodi.

Passaggi successivi