Il rilascio del 26 agosto

Kubernetes v1.37, nome in codice Garhwal, è stato rilasciato il 26 agosto 2026 dopo il consueto ciclo con enhancement freeze a metà giugno e code freeze a fine luglio. Il changelog conta 86 enhancement complessivi, di cui 16 passano a Stable e altri 28 sono classificati come “Graduating” tra Alpha e Beta. Per chi gestisce cluster in produzione, due filoni meritano un approfondimento perché toccano direttamente i costi operativi e la resilienza del control plane: lo scale-to-zero nativo dell’HPA e una serie di ottimizzazioni interne pensate per proteggere l’API server sotto carico estremo.

Scale-to-zero: l’HPA impara a spegnere tutto

Da anni chi vuole azzerare le repliche di un workload realmente idle (un job batch, un ambiente di staging fuori orario, un microservizio a bassissimo traffico) deve appoggiarsi a soluzioni esterne come KEDA, che introducono un ulteriore componente da gestire e monitorare. Con la KEP-2021 (“Support scaling to/from zero pods for object/external metrics”), che in questa release passa da Alpha a Beta, l’Horizontal Pod Autoscaler nativo guadagna questa capacità senza dipendenze esterne.

La differenza pratica rispetto al comportamento precedente è che ora si può impostare minReplicas: 0 quando l’HPA è configurato su metriche di tipo Object o External (non su CPU/memoria, per ovvie ragioni: non esiste un consumatore da cui misurare l’utilizzo se non ci sono pod):

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-scale-to-zero
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 10
  metrics:
  - type: External
    external:
      metric:
        name: queue_messages_ready
        selector:
          matchLabels:
            queue: orders
      target:
        type: AverageValue
        averageValue: "30"

La novità architetturale più interessante della graduazione a Beta è l’introduzione di una condizione di stato esplicita, ScaledToZero, esposta nell’oggetto HorizontalPodAutoscaler. Prima, un deployment a zero repliche poteva significare “l’HPA ha deciso di spegnerlo” oppure “qualcuno lo ha messo in pausa manualmente con kubectl scale --replicas=0“, e i controller di automazione (o gli operatori umani) non avevano un modo affidabile per distinguere i due casi. Con questa condizione visibile via kubectl describe hpa o via API, strumenti di GitOps e dashboard di osservabilità possono finalmente riconciliare correttamente lo stato desiderato senza riportare falsamente in vita un workload che era stato fermato apposta da un operatore.

Tolleranza configurabile: basta con il 10% fisso per tutti

Una seconda modifica, meno appariscente ma altrettanto utile in produzione, riguarda la KEP-4951 (“Configurable tolerance for Horizontal Pod Autoscalers”), che con questa release passa a Stable. Fino a v1.36, l’HPA applicava una tolleranza fissa a livello di cluster (il classico 10%) prima di decidere che uno scarto tra metrica osservata e target giustificasse un’azione di scaling. Questo valore, impostato una volta a livello di kube-controller-manager, andava bene come default generico ma era un compromesso scomodo per workload con esigenze molto diverse tra loro: un servizio latency-sensitive vorrebbe reagire a scostamenti minimi, mentre un batch job tollera oscillazioni ben più ampie senza bisogno di “flappare” in continuazione.

Ora il campo di tolleranza è configurabile per singolo HPA, direttamente in spec.behavior:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: latency-sensitive-api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-gateway
  minReplicas: 3
  maxReplicas: 20
  behavior:
    scaleUp:
      tolerance: "0.05"
    scaleDown:
      tolerance: "0.20"
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

Con questa configurazione, l’API gateway scala verso l’alto già con uno scostamento del 5% (per assorbire i picchi rapidamente) ma tollera fino al 20% di margine prima di scalare verso il basso (per evitare di disfare capacità troppo aggressivamente). L’algoritmo di calcolo dello scaling resta invariato: cambia solo la soglia di sensibilità, il che rende la migrazione da configurazioni esistenti sostanzialmente priva di rischi.

Proteggere l’API server: il vero collo di bottiglia dei cluster grandi

Il secondo filone di novità riguarda chi gestisce cluster di grandi dimensioni, dove l’API server è spesso il componente che soffre per primo sotto carico. La KEP-6178 (“Concurrent Watch Object Decode”) affronta un problema molto concreto: durante le migrazioni di versione delle Custom Resource Definition, ogni evento di watch attivo deve essere convertito nella nuova versione dello schema, e questa conversione avveniva storicamente in modo sequenziale. Su cluster con oltre 10.000 workload e numerosi watcher attivi, questo causava timeout verso etcd e, nei casi peggiori, errori HTTP 500 lato API server proprio nei momenti di maggior carico.

In questa release, il feature gate ConcurrentWatchObjectDecode passa a Beta ed è abilitato di default, permettendo la decodifica e conversione parallela degli eventi di watch. Per abilitarlo o disabilitarlo esplicitamente sull’API server:

kube-apiserver \
  --feature-gates=ConcurrentWatchObjectDecode=true \
  # ...altri flag esistenti

Collegata a questo filone c’è anche la KEP-6164 (“Eliminating Internal API Types”), che entra in questa release come novità in Alpha. Il problema di fondo è che Kubernetes mantiene internamente tipi API “interni” separati dai tipi versionati esposti tramite l’API, e ogni conversione tra i due formati durante operazioni di list su larga scala consuma CPU e memoria in modo non trascurabile. La prima fase della proposta rende i tipi interni memory-identical a quelli versionati, con benchmark che riportano guadagni fino a 5,7 volte in velocità e una riduzione di memoria di 3,3 volte nelle operazioni interessate; le fasi successive prevedono la sostituzione con Go type alias prima della rimozione completa della duplicazione. È presto per usarla in produzione (è Alpha), ma è un buon segnale di dove sta andando il lavoro di scalabilità del control plane nei prossimi cicli di rilascio.

Altre novità che meritano attenzione

Il changelog di v1.37 include diverse altre graduazioni utili nella pratica quotidiana:

• Pod-level resources (KEP-2837): permette di definire un pool condiviso di CPU, memoria e hugepages a livello di pod invece che per singolo container, migliorando l’utilizzo delle risorse per pod con più container che hanno pattern di consumo complementari;
• Storage Version Migrator in-tree (KEP-4192): porta nativamente nel cluster, tramite l’API storagemigration.k8s.io, la funzionalità di riscrittura automatica dei dati quando cambia la storage version di una risorsa, un’operazione che prima richiedeva strumenti esterni;
• CBOR come formato di serializzazione (KEP-4222, Beta): fino a 8 volte più veloce in encoding e 2 volte in decoding rispetto a JSON per le Custom Resource Definition, un dettaglio che pesa parecchio su cluster con molti CRD ad alta frequenza di aggiornamento;
• Nomi Service più permissivi (KEP-5311): i nomi ora possono iniziare con un numero (es. 123-backend), passando dal vincolo RFC 1035 al più permissivo formato DNS Label;
• Pod Certificates (KEP-4317): distribuzione di certificati X.509 ai pod senza passare da bearer token, tramite il nuovo oggetto PodCertificateRequest, utile per chi sta migrando verso autenticazione mutual TLS tra servizi;
• ClusterTrustBundles (KEP-3257, Beta): permette di montare bundle di trust CA come volume proiettato nei pod, semplificando la distribuzione di certificate authority personalizzate senza dover gestire ConfigMap manualmente.

Cosa verificare prima di aggiornare

Come per ogni major/minor release di Kubernetes, prima di pianificare l’upgrade su cluster di produzione vale la pena controllare tre cose in particolare: primo, se si usano CRD con più versioni attive contemporaneamente, testare il comportamento con ConcurrentWatchObjectDecode abilitato in un ambiente di staging che replichi il volume di watcher reale; secondo, se si dipende oggi da KEDA solo per lo scale-to-zero su metriche esterne (code, topic Kafka, metriche custom da Prometheus Adapter), valutare se la KEP-2021 in Beta copre già il caso d’uso, tenendo presente che è comunque prudente aspettare la Stable prima di rimuovere KEDA da workload critici; terzo, verificare la compatibilità di eventuali webhook di ammissione e operator custom con i pod-level resources, se già si sfruttano richieste/limiti a livello di container in modo granulare.

Nel complesso, v1.37 conferma una tendenza chiara delle ultime release: meno feature “vistose” rivolte all’utente finale, più lavoro di fondo su efficienza e resilienza del control plane, proprio nei punti dove i cluster più grandi iniziano a sentire la pressione della scala.

Fonte: 4sysops, con dettagli tecnici da PerfectScale e dalle note di rilascio ufficiali del progetto Kubernetes.