Karpenter v1.14: le novità e come eseguire l'upgrade

TLDR;

Karpenter v1.14, rilasciato l'11 luglio 2026, aggiunge tre funzionalità: il supporto alla Dynamic Resource Allocation (DRA) per lo scheduling di GPU e acceleratori, un'API CapacityBuffer in alpha per mantenere capacità di riserva sui nodi e una nuova policy di consolidamento Balanced che bilancia il risparmio sui costi con la disruption dei pod. Il consolidamento Balanced è un campo stabile e sicuro da usare in produzione; il supporto DRA e CapacityBuffer sono ancora in fase iniziale ed è meglio testarli prima in staging.

Karpenter v1.14: le novità e come eseguire l'upgrade

Karpenter v1.14 è l'ultima release del node autoscaler per Kubernetes. Introduce tre novità principali: il supporto alla Dynamic Resource Allocation (DRA), una nuova API CapacityBuffer per la capacità di riserva e una nuova policy di consolidamento Balanced. Due di queste sono ancora in fase iniziale. Il supporto DRA non è ancora GA in Karpenter, e CapacityBuffer è in alpha e disattivata per impostazione predefinita.

Entrambi i repository di Karpenter hanno rilasciato la v1.14.0 l'11 luglio 2026: il progetto core e il provider AWS.

Questo articolo spiega cosa fa ciascuna funzionalità, come eseguire l'upgrade e cosa è sicuro usare in produzione già oggi.

C'è un filo conduttore in questa release. Il team di Karpenter sa bene che affidabilità e disponibilità sono la priorità quando si mette a punto l'autoscaling. Nessuno vuole risparmiare sui costi al prezzo di un disservizio. Sia la nuova policy di consolidamento Balanced sia CapacityBuffer nascono con questa consapevolezza. La prima riduce i costi senza spostare nodi che non ci si può permettere di perdere. La seconda mantiene pronta della capacità di riserva, così i pod non restano in attesa. È lo stesso approccio ai costi orientato all'affidabilità che PerfectScale adotta fin dall'inizio.

Cosa c'è di nuovo in Karpenter v1.14?

Karpenter avvia nodi quando i pod non possono essere schedulati e li rimuove quando non servono più. La v1.14 non cambia questo compito. Rende Karpenter più intelligente con i workloads GPU e hardware, offre un modo per tenere pronti nodi di riserva e aggiunge un modo più prudente per risparmiare sui costi.

Tre cambiamenti spiccano in questa release:

a. Supporto DRA: Karpenter ora legge la richiesta DRA di un pod quando sceglie un nodo. È particolarmente importante per i workloads GPU e hardware.

b. CapacityBuffer: è possibile mantenere pronti nodi di riserva, così i pod partono subito. Questa funzionalità è in alpha.

c. Consolidamento Balanced: una nuova policy che rimuove un nodo solo quando il risparmio ottenuto giustifica la disruption.

Il supporto DRA in Karpenter v1.14

DRA è il meccanismo di Kubernetes per richiedere hardware speciale come GPU e altri acceleratori. Invece di richiedere un numero fisso come nvidia.com/gpu: 1, un pod descrive il device di cui ha bisogno con una ResourceClaim, e lo scheduler sceglie il device effettivo. Ogni nodo ha bisogno di un driver DRA per il proprio hardware. DRA è GA in Kubernetes dalla v1.34 ed è attiva per impostazione predefinita a partire da quella versione.

Prima della v1.14, Karpenter non leggeva queste richieste DRA durante la pianificazione di nuovi nodi. Un pod che richiedeva una GPU tramite DRA poteva quindi restare bloccato, perché Karpenter non avviava un nodo in grado di eseguirlo. Per aggirare il problema, bisognava indirizzare manualmente questi pod verso i nodi giusti, con un nodeSelector o una node affinity, nello stesso modo in cui i pod GPU vengono instradati con il vecchio modello dei device plugin. Karpenter li legge, ma non era in grado di leggere autonomamente la claim DRA. La v1.14 aggiunge un allocatore DRA. Karpenter ora legge la richiesta DRA del pod e la usa per scegliere il nodo giusto. Gestisce anche i device condivisi e divisibili, il che aiuta quando più pod condividono un unico acceleratore.

Non serve attivare nulla: la funzionalità è attiva per impostazione predefinita. Per fare in modo che Karpenter ignori le richieste DRA, impostare il flag --ignore-dra-requests. La funzionalità è però ancora in fase iniziale. Se si eseguono workloads GPU o con acceleratori tramite DRA, conviene provarla prima in staging. Servono inoltre Kubernetes 1.34 o successivo e un driver DRA per il proprio hardware. La Settings reference contiene i dettagli del flag.

Karpenter CapacityBuffer: nodi di riserva sempre pronti

I nuovi nodi impiegano tempo per avviarsi e unirsi al cluster. Per i workloads con picchi o che non possono attendere, quel ritardo è un problema. I pod restano in pending e il servizio non riesce a scalare in tempo per gestire il traffico. CapacityBuffer permette di mantenere pronta una certa capacità di riserva, così i pod vengono schedulati subito invece di attendere un nuovo nodo.

Funziona con pod segnaposto virtuali. Questi pod esistono solo nella pianificazione di Karpenter. Non diventano mai pod reali nel cluster. Fanno sì che Karpenter mantenga pronti nodi di riserva e si ripristinano da soli quando i pod reali occupano lo spazio di riserva.

La dimensione della capacità di riserva si imposta in uno di questi due modi:

1. podTemplateRef: puntare a un PodTemplate che descrive una singola unità di buffer, poi impostare replicas e/o limits.
2. scalableRef: puntare a un Deployment, StatefulSet o ReplicaSet, poi impostare una percentuale per mantenere la capacità di riserva allineata a quel workload.

Ecco un buffer fisso di cinque unità:

yaml

apiVersion: autoscaling.x-k8s.io/v1alpha1
kind: CapacityBuffer
metadata:
  name: web-app-buffer
  namespace: default
spec:
  provisioningStrategy: "buffer.x-k8s.io/active-capacity"
  podTemplateRef:
    name: web-buffer-template
  replicas: 5
  limits:
    cpu: "20"
    memory: "40Gi"

In alternativa, per mantenere la capacità di riserva allineata a un workload, si punta a un Deployment e si imposta una percentuale. In questo esempio la capacità del buffer resta al 20% delle repliche del Deployment api-service, quindi la capacità di riserva cresce e si riduce man mano che quel Deployment scala:

yaml

apiVersion: autoscaling.x-k8s.io/v1alpha1
kind: CapacityBuffer
metadata:
  name: api-service-buffer
  namespace: default
spec:
  scalableRef:
    apiGroup: apps
    kind: Deployment
    name: api-service
  percentage: 20

Se si imposta più di uno di questi valori, il conteggio finale è min(max(replicas, percentage), limits). Replicas e percentage vengono quindi combinati prendendo il valore maggiore, e limits pone un tetto al risultato.

C'è un aspetto da conoscere riguardo alla pulizia dei nodi. Karpenter non rimuoverà un nodo come vuoto se ospita capacità di buffer. I pod di buffer virtuali impediscono che venga conteggiato come vuoto, e Karpenter lo contrassegna con il motivo Node has buffer pods. Tutti gli altri tipi di pulizia continuano a funzionare, e qualsiasi nodo sostitutivo deve comunque ospitare i pod di buffer, così la capacità di riserva resta sempre al livello previsto.

CapacityBuffer è in alpha e disattivata per impostazione predefinita. Si abilita con il feature gate CapacityBuffer=true. È stata aggiunta nella v1.13, e la v1.14 ha fatto evolvere la sua API interna e aggiunto metriche di stato, ma è ancora in alpha e l'API può cambiare. Conviene provarla prima in un cluster di test. Va inoltre ricordato che la capacità di riserva costa, perché si pagano nodi inattivi. Meglio dimensionarla sul burst reale effettivamente necessario.