Scaling immediato: Active Buffer elimina i ritardi di provisioning dei nodi su GKE

I sistemi cloud-native moderni nascono per scalare, ma è la velocità con cui lo fanno a fare la differenza tra un'esperienza utente fluida e fastidiosi rallentamenti. Che si tratti di un sito e-commerce alle prese con un flash sale, di una piattaforma di gaming che accoglie un'ondata di giocatori o di un servizio di inferenza AI che deve gestire un picco improvviso di richieste, l'infrastruttura deve rispondere in pochi secondi, non nei minuti necessari all'hardware per allinearsi.

GKE mette da tempo a disposizione strumenti potenti come Cluster Autoscaler e Horizontal Pod Autoscaler (HPA) per gestire queste variazioni di carico. Anche i cluster più ottimizzati, però, hanno sempre dovuto fare i conti con un problema di fondo: la latenza di provisioning dei nodi.

Quando i workloads crescono, i tempi di attesa si sommano per effetto di diversi fattori:

• Inizializzazione del nodo: ingresso nel cluster e avvio dei DaemonSet.
• Image pull: download di container image che pesano diversi gigabyte.
• Warm-up dell'applicazione: inizializzazione dello stato applicativo o caricamento dei modelli AI nella memoria GPU.

Nei workloads di grandi dimensioni questi ritardi possono tradursi in diversi minuti di pod in stato pending, con il rischio di mancare gli SLO e compromettere l'esperienza utente.

I vecchi workaround e i loro limiti

Finora gli utenti GKE si sono affidati a due soluzioni imperfette per gestire la latenza di scale-out:

Over-provisioning con soglie HPA più basse: impostando soglie di utilizzo HPA conservative si tiene sempre un margine extra nel cluster. Il rovescio della medaglia: i costi crescono in modo lineare con il workload. Un cluster che gira costantemente al 60% di utilizzo invece che all'80% può costare il 20-30% in più nei deployment di grandi dimensioni.

Balloon pod: si distribuiscono pod segnaposto a bassa priorità che riservano capacità sui nodi, pronti a essere sfrattati quando arrivano i workloads reali. Quando i workloads target scalano, GKE espelle i pod segnaposto a priorità inferiore e schedula al loro posto le nuove repliche. Per quanto efficace, questo approccio richiede una configurazione attenta delle PriorityClass e un tuning costante: se le soglie si disallineano con l'evolvere del traffico, la protezione si degrada in silenzio.

Entrambi gli approcci condividono un problema più profondo: per restare efficaci richiedono un'attenzione operativa continua, di pari passo con l'evoluzione del traffico in produzione.

Arrivano i Capacity Buffer di GKE

Il 1° aprile 2026 Google ha annunciato la preview di active buffer per GKE, un'implementazione GKE-native dell'API OSS Kubernetes CapacityBuffer.

Invece di gestire PriorityClass complesse e deployment di pod segnaposto, gli utenti definiscono i propri requisiti tramite una Custom Resource CapacityBuffer. È questa a indicare al Cluster Autoscaler di GKE di mantenere costantemente una rete di sicurezza fatta di capacità calda e inutilizzata.

Come funzionano gli Active Buffer

Il Cluster Autoscaler di GKE tratta il CapacityBuffer come domanda in attesa. Riserva capacità tramite pod virtuali e inesistenti, che l'autoscaler considera pending demand, garantendo il provisioning dei nodi in anticipo. Quando il workload target scala, GKE lo schedula immediatamente sulla capacità di buffer disponibile, senza alcun ritardo di provisioning dei nodi.

Il buffer torna quindi in stato pending e l'autoscaler provvede in background al provisioning di un buffer di sostituzione.

Strategie di buffering flessibili

Active Buffer offre tre modi flessibili per definire quanta capacità di riserva mantenere:

1. Repliche fisse

L'opzione più semplice. Mantiene un numero costante e noto di unità di buffer, indipendentemente dalle dimensioni del workload.

apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: fixed-replica-buffer
  namespace: my-app
spec:
  podTemplateRef:
    name: buffer-unit-template
  replicas: 3

In pratica, si dice a GKE: tieni sempre pronta capacità per 3 pod di queste dimensioni.

2. Su base percentuale

Il buffer scala proporzionalmente a un workload esistente. Quando il deployment di produzione cresce, il buffer cresce con lui, senza alcun intervento manuale.

apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: percentage-buffer
  namespace: my-app
spec:
  scalableRef:
    apiGroup: apps
    kind: Deployment
    name: my-production-deployment
  percentage: 20

Se il deployment passa da 50 a 100 repliche, il buffer si adegua automaticamente da 10 a 20 unità.

3. Limiti di risorse

Definisce un tetto massimo sulle risorse di calcolo totali che il buffer può consumare, mantenendo i costi prevedibili. GKE calcola quanti pod di buffer mantenere in base alle resource request del PodTemplate e ai limiti definiti.

apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: resource-limit-buffer
  namespace: my-app
spec:
  podTemplateRef:
    name: buffer-unit-template
  limits:
    cpu: "20"
    memory: "20Gi"

A chi conviene usare Active Buffer?

Active Buffer è la scelta ideale per i workloads sensibili alla latenza che richiedono uno scale-up rapido:

• Servizi di inferenza AI: la latenza di cold start si traduce direttamente in un'esperienza utente compromessa o in SLO mancati.
• Applicazioni retail durante eventi promozionali: flash sale, drop a tiratura limitata o picchi stagionali in cui il traffico può moltiplicarsi in pochi secondi.
• Servizi finanziari: apertura e chiusura dei mercati, elaborazioni di fine giornata.
• Piattaforme di gaming: picchi di attività dei giocatori, lanci di giochi pianificati.
• API in tempo reale: qualsiasi servizio in cui la latenza per l'utente finale è vincolata contrattualmente.

Active Buffer non è invece consigliato per job di batch processing o per workloads insensibili alla latenza di avvio.

La configurazione pro: Active Buffer + Custom Compute Class

Active Buffer diventa ancora più potente se abbinato alle ComputeClass di GKE: una Custom Resource Kubernetes che descrive un insieme prioritizzato di configurazioni di nodo.

Quando GKE esegue l'autoscaling e deve provisionare nuovi nodi, segue le regole di priorità definite nella ComputeClass e ripiega sull'opzione successiva se l'hardware preferito non è disponibile.

Abbinare una ComputeClass a un capacity buffer significa che la capacità calda risiede esattamente sull'hardware di cui il workload ha bisogno, e non su un nodo qualsiasi. Un vantaggio particolarmente prezioso per i workloads di inferenza GPU/TPU. Le applicazioni di AI serving richiedono spesso configurazioni di acceleratori specifiche: un capacity buffer generico su nodi CPU standard non è di alcun aiuto se il workload ha bisogno di una GPU nvidia-l4.

L'esempio seguente mantiene tre nodi GPU L4 pre-riscaldati, privilegiando le istanze on-demand ma con fallback su Spot in caso di indisponibilità:

# ComputeClass targeting L4 GPUs with Spot VM fallback
apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: inference-compute
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - gpu:
      type: nvidia-l4
      count: 1
    spot: false
  - gpu:
      type: nvidia-l4
      count: 1
    spot: true
  - machineFamily: n4
    minCores: 16
  whenUnsatisfiable: DoNotScaleUp
---
# PodTemplate requesting the ComputeClass for buffer pods
apiVersion: v1
kind: PodTemplate
metadata:
  name: inference-buffer-template
  namespace: inference-ns
template:
  metadata:
    labels:
      cloud.google.com/compute-class: inference-compute
  spec:
    terminationGracePeriodSeconds: 0
    nodeSelector:
      cloud.google.com/compute-class: inference-compute
    tolerations:
    - key: cloud.google.com/compute-class
      operator: Equal
      value: inference-compute
      effect: NoSchedule
    containers:
    - name: buffer-container
      image: registry.k8s.io/pause:3.9
      resources:
        requests:
          cpu: "4"
          memory: "16Gi"
---
# CapacityBuffer maintaining 3 pre-warmed inference-ready nodes
apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: inference-buffer
  namespace: inference-ns
spec:
  podTemplateRef:
    name: inference-buffer-template
  replicas: 3

Per spingersi oltre: i capacity buffer eliminano i ritardi di provisioning dei nodi, ma non incidono sui tempi di image pull. Per ottenere latenze inferiori al secondo, consigliamo di affiancare ad Active Buffer l'Image Streaming.

Requisiti e prerequisiti

Prima di abilitare Active Buffer, tenga presenti questi punti:

• Versione GKE: richiede la versione del cluster 1.35.2-gke.1842000 o successiva.
• Modello di fatturazione: supportato solo per i workloads che utilizzano la fatturazione a nodo (non la fatturazione a Pod / Autopilot pay-per-Pod).
• Node auto-provisioning: consigliato (ma non obbligatorio): consente all'autoscaler di creare nuovi node pool quando deve ricaricare il buffer. Senza, l'autoscaler può solo scalare i node pool esistenti.
• Stato Preview: attualmente in Preview, soggetto ai Pre-GA Offerings Terms.

Considerazioni sui costi

Active Buffer elimina la latenza di scaling, ma comporta costi reali perché tiene attive delle VM inattive. È però sensibilmente più efficiente di un over-provisioning generalizzato. Anziché far girare l'intero cluster a un dispendioso 60% di utilizzo, si possono spingere i nodi attivi verso l'80-90%, mantenendo allo stesso tempo un buffer snello e mirato di nodi di sicurezza.

È possibile ridurre ulteriormente i costi del buffer utilizzando Spot VM per coprirne il fabbisogno di capacità. Dato che le Spot VM sono nettamente più economiche delle istanze on-demand, l'overhead del buffer può risultare minimo nei casi in cui i workloads tollerano il rischio di prelazione.

In sintesi

Active Buffer rappresenta un passo importante verso uno scaling sotto il secondo. Sostituendo la complessità operativa dei balloon pod con una Custom Resource CapacityBuffer pulita e dichiarativa, GKE offre ai platform engineer un modo nativo e manutenibile di garantire capacità calda per i workloads sensibili alla latenza.

Consulti la guida pratica al capacity buffer di GKE per esempi di configurazione e best practice.