Basta over-provisioning per l'avvio: il nuovo CPU Startup Boost di GKE

Il compromesso: velocità di avvio vs. spreco a riposo

Ogni team che esegue workloads pesanti e sensibili alla latenza su Kubernetes è costretto a scegliere tra due compromessi frustranti:

Dimensionare per l'avvio e pagarlo per sempre. Imposti la CPU request abbastanza alta da completare rapidamente l'inizializzazione, anche se l'app ha bisogno di pochissima CPU una volta calda. Quella request resta lì 24 ore su 24. È ciò che lo scheduler usa per collocare il Pod, ciò che il cluster autoscaler usa per decidere se aggiungere nodi ed è ciò che ti viene fatturato. Su qualche centinaio di repliche, il compromesso tra avvio più rapido e spreco continuo si accumula in fretta.

Dimensionare per lo steady-state e soffrire all'avvio. Imposti la request in linea con l'utilizzo effettivo a runtime e accetti che ogni riavvio, ogni rolling deployment, ogni upgrade dei nodi comporti una lenta marcia verso la readiness. Sotto CPU throttling, un warm-up della JVM che dovrebbe richiedere 5 secondi può allungarsi a 30 o più. Questo significa rollout più lenti, scale-out più lento durante gli eventi HPA e potenziali picchi di latenza per gli utenti.

Nessuna delle due opzioni è davvero accettabile. Il CPU startup boost nasce per colmare questo divario.

Cosa risolve davvero il CPU startup boost

Il CPU startup boost è una nuova funzionalità del Vertical Pod Autoscaler (VPA) di GKE, attualmente in Preview. Permette di aumentare temporaneamente la CPU request di un container durante l'inizializzazione del Pod, per poi riportarla automaticamente al valore di base senza riavviare il container.

I runtime affamati di risorse (Java, Node.js e Python con import pesanti) ottengono il margine di CPU di cui hanno bisogno solo quando serve, cioè durante l'inizializzazione. La request di base può così riflettere l'utilizzo reale in steady-state anziché un compromesso gonfiato per i primi secondi di vita del Pod. Poiché il ridimensionamento dal valore boostato a quello di base usa l'in-place Pod resize (IPPR) di Kubernetes anziché un'eviction con ricreazione del Pod, il container continua a girare per tutto il tempo.

Tutto questo funziona in parallelo al compito abituale del VPA, ovvero raccomandare e applicare il dimensionamento delle risorse a lungo termine. Lo startup boost, in fondo, non è che un override di breve durata applicato sopra il valore di base che il VPA (o tu stesso) ha già stabilito.

Come funziona e come configurarlo

Guida completa qui: Accelerate application startup with CPU startup boost.

Il CPU startup boost si definisce aggiungendo un blocco startupBoost all'oggetto VerticalPodAutoscaler. Puoi applicarlo a livello di Pod, così ogni container riceve lo stesso boost, oppure a livello di container, per indirizzare container specifici o escluderne alcuni da un boost applicato all'intero Pod.

Si attiva solo alla creazione del Pod. Se un container si riavvia in un secondo momento, ad esempio dopo un OOMKill mentre il Pod resta in vita, il boost non viene riapplicato. L'admission webhook che inietta il boost viene eseguito solo all'admission iniziale del Pod.

Il tipo di boost può essere un moltiplicatore o una quantità fissa. type: "Factor" scala la CPU request di base per un moltiplicatore (factor: 2 la raddoppia); type: "Quantity" aggiunge una quantità fissa di CPU al valore di base.

Funziona insieme alle update modes del VPA, non al loro posto. Eseguilo con updateMode: "Off" se vuoi solo il comportamento di boost e nient'altro, oppure abbinalo a updateMode: "InPlaceOrRecreate" se vuoi che il VPA continui anche ad adeguare le risorse in base all'utilizzo effettivo.

Per configurare un boost a livello di Pod, usa una delle seguenti opzioni.

Boost a livello di Pod, con attuazione del VPA disattivata

Usa questa opzione quando vuoi il boost e nient'altro: il VPA non applicherà nessun'altra raccomandazione sulle risorse.

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

Ogni container del Pod riceve il doppio della sua CPU request di base per i primi 10 secondi dopo che il Pod raggiunge lo stato Ready, dopodiché GKE la riporta al valore di base in place.

Boost a livello di Pod, con gestione VPA continua

Usa questa opzione quando vuoi sia lo startup boost sia, successivamente, un right-sizing continuo delle risorse in place.

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

Stesso comportamento di boost, ma con updateMode: "InPlaceOrRecreate" il VPA continua a raccomandare e applicare modifiche alle risorse per tutta la vita del Pod, tentando prima il resize in place e ripiegando sulla ricreazione se necessario.

Boost a livello di container, mirato a un singolo container

Utile quando un Deployment include un sidecar o un container di servizio che non ha bisogno del picco di CPU all'avvio. Limiti il boost al solo container che ne ha bisogno tramite resourcePolicy.containerPolicies.

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"

Qui boosted-container-name riceve 2 vCPU extra oltre alla sua request di base durante l'avvio: una quantità fissa anziché un moltiplicatore.

Escludere un container da un boost a livello di Pod

Il caso inverso: è impostato un boost a livello di Pod, ma uno dei container non deve essere boostato insieme al resto.

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

Il boost a livello di Pod applica di default un fattore 2x a tutti i container, ma la policy del container lo sovrascrive con un fattore 1 per il container indicato.