Accelerare l'avvio delle applicazioni con il boosting della CPU all'avvio

Questo documento spiega come utilizzare l'incremento dell'avvio della CPU con Vertical Pod Autoscaler (VPA) in Google Kubernetes Engine (GKE) per aumentare temporaneamente le risorse CPU allocate a un pod durante la fase di inizializzazione.

L'aumento dell'avvio della CPU accelera l'avvio dell'applicazione e migliora l'efficienza in termini di costi aumentando temporaneamente le richieste di CPU durante l'inizializzazione e ridimensionandole di nuovo ai livelli di base in loco. Questo documento tratta i requisiti, la configurazione (a livello di pod e container), la verifica e le best practice per l'avvio rapido.

Questo documento è rivolto a ingegneri DevOps, ingegneri di piattaforma e sviluppatori di applicazioni che vogliono ottimizzare le prestazioni di avvio delle applicazioni in GKE.

Vantaggi

L'utilizzo del boost della CPU all'avvio offre i seguenti vantaggi:

  • Avvio più rapido: accelera l'inizializzazione di applicazioni che richiedono molte risorse, come quelle scritte in Java, Node.js o Python.
  • Efficienza dei costi: evita l'over-provisioning della CPU per il funzionamento in stato stazionario soddisfacendo comunque le richieste di avvio. Il funzionamento in stato stazionario è il periodo successivo al completamento dell'inizializzazione di un'applicazione e alla stabilizzazione dell'utilizzo delle risorse.
  • Nessuna interruzione: ridimensiona le risorse ai livelli di base utilizzando il ridimensionamento dei pod in loco (IPPR) di Kubernetes senza riavviare i container.
  • Riduzione dello sforzo manuale: riduci al minimo lo spreco di risorse e lo sforzo manuale necessario per dimensionare correttamente i tuoi workload.

Requisiti

Per utilizzare l'avvio rapido della CPU, devi soddisfare i seguenti requisiti:

  • Versione GKE: utilizza 1.36.0-gke.4447000 e versioni successive per i cluster Standard e Autopilot.
  • VPA enabled: abilita la scalabilità automatica verticale dei pod sui cluster Standard. GKE abilita VPA per impostazione predefinita sui cluster Autopilot. Puoi utilizzare VPA esclusivamente per l'aumento dell'avvio della CPU scegliendo una modalità di aggiornamento specifica. Per attivare e configurare VPA, vedi Impostare automaticamente le richieste di risorse dei pod.
  • Tipo di workload: utilizza un controller, ad esempio un deployment o un StatefulSet, per gestire il tuo workload.
  • Capacità dei nodi: assicurati che i cluster Standard abbiano una capacità sufficiente per il pod potenziato. Se la capacità non è sufficiente, GKE limita la richiesta di pod con priorità per adattarsi al nodo.

Come funziona il boost della CPU all'avvio

Per saperne di più sul ciclo di vita del boost e su come il boost all'avvio della CPU calcola gli aumenti delle risorse, consulta Come funziona il boost all'avvio della CPU.

Prima di iniziare

Prima di iniziare, assicurati di aver selezionato il progetto Cloud de Confiance by S3NS contenente il cluster che vuoi aumentare e di aver eseguito le seguenti attività:

  • Abilita l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine
  • Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

  • Configura gcloud CLI in modo da utilizzare il progetto selezionato:

    gcloud config set project PROJECT_ID

    Sostituisci PROJECT_ID con l'ID del tuo progetto.

  • Assicurati di avere un cluster GKE esistente. Se non ne hai uno, consulta Creare un cluster.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per attivare e utilizzare l'avvio rapido della CPU, chiedi all'amministratore di concederti i seguenti ruoli IAM nel progetto:

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Attivare il boost della CPU all'avvio

Per attivare l'avvio rapido della CPU, aggiungi un blocco di configurazione startupBoost al manifest VerticalPodAutoscaler (VPA). Puoi configurare l'incremento in modo che venga applicato a tutti i container di un pod o scegliere come target singoli container con aumenti specifici delle risorse.

Configura un boost a livello di pod

Un boost a livello di pod applica lo stesso aumento delle risorse CPU a ogni container nel workload. Puoi configurare l'incremento iniziale della CPU con o senza la gestione continua delle risorse di VPA.

Per configurare un boost a livello di pod, utilizza una delle seguenti opzioni.

Opzione A: Avvio rapido abilitato e modalità di aggiornamento dell'assistente vocale disattivata

Utilizza questa opzione per sfruttare VPA esclusivamente per le sue funzionalità di aumento dell'avvio della CPU senza attivare i normali consigli VPA. Il seguente esempio applica un fattore di moltiplicazione della CPU pari a 2 e lo mantiene per 10 secondi dopo che il pod raggiunge lo stato Ready:

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

Opzione B: sono attive sia la modalità di aggiornamento dell'avvio rapido sia quella di VPA

Se vuoi che GKE gestisca l'avvio rapido e poi continui a regolare automaticamente le richieste di risorse del pod in base all'utilizzo continuo, utilizza questa opzione. L'esempio seguente applica l'avvio rapido e imposta il campo updateMode su InPlaceOrRecreate:

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

Configurare un boost a livello di contenitore

Se il tuo workload include sidecar o altri container che non richiedono risorse aggiuntive, puoi scegliere come target container specifici per un boost all'avvio nella sezione resourcePolicy. Il valore di containerName deve corrispondere al campo name di un container nella specifica del deployment.

Per configurare un aggiustamento a livello di contenitore, utilizza una delle seguenti opzioni.

Opzione A: aumenta l'offerta per un container specifico (attivazione VPA disattivata)

Utilizza questa opzione per applicare un boost a un singolo container mantenendo invariate le richieste di risorse del resto del pod. Il seguente manifest di esempio aggiunge due vCPU alla richiesta di base per un container denominato boosted-container-name:

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: "boosted-container-name"
      mode: "Off"
      startupBoost:
        cpu:
          type: "Quantity"
          quantity: "2"

Opzione B: disattiva un container specifico da un boost a livello di pod

Se hai configurato un boost a livello di pod, ma vuoi escludere un container specifico, utilizza questa opzione. Il seguente manifest di esempio applica un fattore di moltiplicazione della CPU pari a 2 all'intero pod, ma disattiva il boost per un container denominato disable-cpu-boost-for-this-container impostando il relativo fattore su 1:

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
  resourcePolicy:
    containerPolicies:
    - containerName: "disable-cpu-boost-for-this-container"
      startupBoost:
        cpu:
          type: "Factor"
          factor: 1

Verificare il boost della CPU all'avvio

Per verificare che i pod ricevano l'incremento, controlla la configurazione VPA, le richieste di risorse dei pod, le annotazioni dei pod e gli eventi VPA.

Verifica la configurazione di VPA

Per controllare i dettagli dell'oggetto VerticalPodAutoscaler, esegui questo comando:

kubectl describe vpa VPA_NAME

Sostituisci VPA_NAME con il nome dell'oggetto VPA.

Controlla la richiesta di CPU aumentata sul pod

Per verificare le richieste di risorse correnti per il pod, esegui questo comando:

kubectl describe pod POD_NAME

Sostituisci POD_NAME con il nome del tuo pod.

Verifica l'aumento della CPU utilizzando le annotazioni dei pod

L'webhook di ammissione VPA inserisce un'annotazione con ambito container per monitorare le risorse originali a cui ogni container deve tornare alla scadenza del boost. Per controllare queste annotazioni, esegui questo comando:

kubectl get pod POD_NAME --output yaml

Nella sezione metadata.annotations, cerca un'annotazione formattata come vpaCpuStartupBoost/CONTAINER_NAME. Ad esempio:

metadata:
  annotations:
    vpaCpuStartupBoost/slow-starter: '{"requests":{"cpu":"50m","memory":"64Mi"},"limits":{"cpu":"200m","memory":"128Mi"}}'

L'output comando indica uno dei seguenti risultati della verifica:

  • Boost riuscito: l'annotazione vpaCpuStartupBoost/CONTAINER_NAME è presente sul pod.
  • Potenziamento non riuscito: l'annotazione è completamente assente. Ciò significa che il controller di ammissione ha ignorato l'incremento, probabilmente a causa dei limiti di capacità dei nodi o delle limitazioni delle risorse di Autopilot.

Controllare gli eventi di riduzione delle dimensioni

Per verificare che GKE abbia ridotto correttamente l'allocazione delle risorse CPU alla baseline, controlla gli eventi del cluster eseguendo questo comando:

kubectl get events --field-selector reason=InPlaceResizedByVPA

L'output comando indica uno dei seguenti risultati della verifica:

  • Riduzione riuscita: visualizzi un evento InPlaceResizedByVPA con un messaggio che indica che il pod è stato ridimensionato in loco da VPA Updater. Ciò conferma che la richiesta di CPU è tornata al suo valore di base senza riavviare il container.
  • Annullamento del boost senza esito: l'annotazione vpaCpuStartupBoost/CONTAINER_NAME rimane sul pod molto tempo dopo la scadenza del boost e non è presente alcun evento InPlaceResizedByVPA.

Best practice e limitazioni

Tieni presente quanto segue quando utilizzi l'avvio rapido della CPU.

Interazioni con la scalabilità automatica orizzontale dei pod

Se utilizzi lo scalabilità automatica pod orizzontale (HPA) con l'ottimizzazione dell'avvio della CPU, segui queste linee guida:

  • Definisci i probe di integrità: devi definire un readinessProbe per i tuoi workload.
  • Configura il ritardo della durata: devi impostare il parametro durationSeconds su 0. Questa configurazione impedisce a HPA di scalare orizzontalmente la tua applicazione prematuramente a causa dell'utilizzo elevato della CPU durante l'avvio.

Gestore della scalabilità automatica del cluster e cicli di rimozione

Se utilizzi il gestore della scalabilità automatica dei cluster sui cluster GKE Standard, tieni presente questi comportamenti dei nodi:

  • Potenziali cicli di espulsione: un aumento temporaneo della CPU potrebbe attivare lo scale up di un nodo. Una volta che il pod è pronto e viene ridimensionato, il sottoutilizzo potrebbe attivare la riduzione della scalabilità dei nodi e rimuovere il pod, creando un ciclo infinito.
  • Mitigazione: ti consigliamo vivamente di utilizzare GKE Autopilot per mitigare i problemi relativi al ciclo di deframmentazione ed eliminazione dei nodi.

Riavvii dei container

Per capire in che modo i riavvii dei container influiscono sull'aumento dell'avvio della CPU, esamina i seguenti comportamenti:

  • Solo durante la creazione del pod: l'aumento dell'avvio della CPU si applica solo durante la fase iniziale di creazione del pod.
  • Nessun boost al riavvio: se un container viene riavviato, ad esempio a causa di un evento OOMKill, ma il pod rimane attivo, GKE non applica nuovamente il boost. Questo comportamento si verifica perché il webhook di ammissione del pod viene attivato solo durante il processo di creazione iniziale del pod.

Esegui la pulizia

Poiché configuri l'incremento dell'avvio della CPU sui workload esistenti, tieni presente quanto segue per evitare interruzioni del workload:

  • Non è necessario eliminare alcuna risorsa Kubernetes.
  • Se l'oggetto VerticalPodAutoscaler o i controller dei carichi di lavoro (come Deployment o StatefulSet) sono ancora necessari per le operazioni in stato stazionario, non eliminarli.

  • Se non hai bisogno dell'avvio rapido della CPU, puoi disattivare solo l'avvio rapido utilizzando uno dei seguenti metodi in base all'ambito:

    • Disabilita il boost per l'intero workload: elimina il blocco startupBoost dalla specifica dell'oggetto VerticalPodAutoscaler e applica il manifest aggiornato al cluster.

    • Disattiva il boost per un container specifico: per escludere un container specifico da un boost a livello di pod, aggiungi una policy del container nella sezione containerPolicies e imposta il fattore moltiplicatore della CPU su 1.

        startupBoost:
    cpu:
      type: "Factor"
      factor: 1

      Per saperne di più, consulta Configurare un boost a livello di container.

Passaggi successivi