In sintesi
Kubernetes v1.37 “Garhwal” (26 agosto 2026) contiene tre breaking change che richiedono una revisione immediata dell’infrastruttura: (1) i nodi con cgroup v1 non avviano più il kubelet – un blocco, non un avviso; (2) kube-dns viene ritirato, con scadenza di migrazione alla v1.40; (3) IPVS in kube-proxy entra nel percorso di deprecazione fino alla rimozione nella v1.43. In positivo, l’API metrics.k8s.io, che alimenta l’HorizontalPodAutoscaler e kubectl top, passa da beta a stabile (v1) dopo nove anni di uso in produzione. Chi usa Kubernetes gestito con immagini dei nodi aggiornate è poco toccato. I cluster autogestiti su immagini datate devono trattare l’aggiornamento come un progetto di modernizzazione, non come un semplice cambio di versione.
67 novità: che cosa è stato rilasciato
Il ciclo di rilascio della v1.37 è durato 15 settimane, dal 18 maggio al 26 agosto 2026, con i contributi di 1.754 persone di 212 aziende. Il bilancio: 67 novità, di cui 16 promosse a stabile, 23 a beta, 27 entrate in alpha e una deprecazione o rimozione. Il nome “Garhwal” viene da una regione himalayana dell’Uttarakhand, in India; il logo mostra cime innevate e un fiume tortuoso, a indicare che “ogni livello, ogni percorso e ogni contributo sono collegati”.
Tra le altre promozioni a stabile, le più rilevanti per l’operatività sono l’output KYAML di kubectl, la definizione delle risorse a livello di pod e i taint e toleration a livello di dispositivo per la Dynamic Resource Allocation (DRA). Quest’ultima conta soprattutto per chi gestisce carichi su GPU o acceleratori: la DRA sta diventando il meccanismo di base per lo scheduling di hardware eterogeneo nelle pipeline di AI e ML. Per i team che gestiscono cluster Kubernetes in produzione, però, la decisione di aggiornare dipende dai breaking change più che dalle novità – e questa release ne ha tre.
Addio a cgroup v1: il blocco all’avvio
Da Kubernetes v1.35 i nodi con cgroup v1 generano avvisi all’avvio. Nella v1.37 il comportamento si irrigidisce: se il kubelet rileva cgroup v1, il nodo non si inizializza. Nessuna degradazione graduale: aggiornare un cluster interessato mette subito fuori uso quei nodi.
Per verificare un nodo eseguite stat -fc %T /sys/fs/cgroup/. L’output tmpfs indica cgroup v1; cgroup2fs indica cgroup v2 e il nodo è sicuro. CentOS 7, RHEL 7 (kernel EL7 3.10) e Ubuntu 18.04 usano cgroup v1 di default. La maggior parte delle immagini dei nodi gestite su EKS, GKE e AKS è passata a cgroup v2 tra il 2022 e il 2023, quindi chi usa node pool aggiornati gestiti dal provider cloud in genere non è toccato.
Il campo failCgroupV1: false della KubeletConfiguration sopprime il blocco. Il progetto Kubernetes lo definisce pericoloso: il nodo perde la QoS della memoria, le metriche Pressure Stall Information (PSI) e alcune configurazioni di swap che richiedono cgroup v2, e il campo sparirà in una release futura. È un’assicurazione per la migrazione, non una configurazione permanente.
La strada pratica: aggiornare l’immagine dei nodi prima di toccare la versione di Kubernetes. Chi è on-premise passi a RHEL 8+, Rocky Linux, AlmaLinux 8+ o Ubuntu 20.04+; chi è in cloud con node group autogestiti aggiorni l’AMI o l’immagine della VM. Lo sforzo di ingegneria cloud e DevOps è reale ma ben delimitato: cgroup v2 è stabile da anni e il percorso di migrazione è ben documentato.
Le scadenze di kube-dns e IPVS
kube-dns viene ritirato nella v1.37. CoreDNS, predefinito da Kubernetes 1.13 (2018), lo sostituisce del tutto. I cluster ancora su kube-dns hanno tempo fino a Kubernetes 1.40; dopo, il DNS del cluster smetterà di funzionare. La migrazione sostituisce kube-dns con un Deployment CoreDNS e converte le ConfigMap nella sintassi Corefile. La maggior parte dei servizi Kubernetes gestiti l’ha automatizzata da anni. Se vedete pod kube-dns in kube-system, pianificate la migrazione in questo trimestre.
IPVS in kube-proxy entra formalmente in deprecazione con la v1.37, con rimozione prevista nella v1.43. Il sostituto è nftables, con prestazioni migliori, regole più espressive e manutenzione attiva upstream. Se il team di rete ha costruito monitoraggio, alert o strumenti interni sui contatori IPVS, pianificate il passaggio a nftables prima della v1.43: circa quattro cicli di rilascio, ovvero 12–18 mesi al ritmo attuale.
L’API delle metriche diventa stabile
L’API metrics.k8s.io, che fornisce il consumo di CPU e memoria di pod e nodi, passa da beta a stabile (v1) nella v1.37. Il release lead Dipesh Rawat sottolinea l’ironia: nonostante l’etichetta beta, l’API è usata ampiamente in produzione da anni. È ciò che fa funzionare kubectl top nodes, kubectl top pods, l’HorizontalPodAutoscaler (HPA) e il VerticalPodAutoscaler (VPA).
In pratica, l’interfaccia v1 rientra ora nella garanzia di compatibilità di Kubernetes e non cambierà in modo incompatibile nel prevedibile futuro. La nota nei runbook secondo cui l’HPA dipende da un’API beta si può eliminare.
Che cosa significa per i team software negli USA e nell’UE
L’addio a cgroup v1 è il punto più urgente di questa release. A differenza della maggior parte dei breaking change, che riguardano versioni di API o schemi dei manifest, questo colpisce l’infrastruttura dei nodi. Serve coordinamento tra il team di piattaforma e chi gestisce le immagini dei nodi – infrastruttura cloud, operations on-premise o chi fornisce le immagini delle VM. I responsabili tecnici dovrebbero lanciare il controllo stat su tutti i nodi questa settimana e classificare i risultati prima della prossima finestra di aggiornamento.
I cluster on-premise e ibridi sono i più esposti. Chi gestisce Kubernetes su distribuzioni enterprise datate, in particolare infrastrutture dell’era RHEL 7, rischia una doppia migrazione: sistema operativo e Kubernetes insieme. Nei settori regolati (FinTech, sanità, assicurazioni, pubblica amministrazione) un aggiornamento major del sistema operativo richiede di norma l’approvazione della security, scansioni di vulnerabilità pulite e talvolta il via libera di un change advisory board. Inserite questi tempi nella pianificazione da subito.
Le scadenze di kube-dns e IPVS sono più morbide, ma non infinite. La v1.40 e la v1.43 lasciano qualche ciclo di margine, ma questi temi vanno inseriti nel backlog già in questo ciclo di pianificazione. Il ritmo di rilascio di Kubernetes è aumentato: la distanza tra margine comodo e scadenza rigida si riduce più in fretta di un tempo.
Che cosa cambia per le aziende italiane?
In Italia l’impatto si concentra sui data center aziendali e sui provider nazionali. Banche, assicurazioni, utility, manifattura e pubblica amministrazione gestiscono spesso Kubernetes on-premise o presso cloud provider italiani, anche per esigenze di sovranità del dato; per la PA il riferimento è la qualificazione dei servizi cloud gestita da ACN. Proprio in questi ambienti restano nodi su CentOS 7 o RHEL 7, il cui supporto standard del vendor è terminato a giugno 2024: qui la 1.37 è prima di tutto un progetto di sistema operativo.
Il quadro normativo spinge nella stessa direzione. Le entità finanziarie sono soggette a DORA da gennaio 2025, e la NIS2, recepita in Italia con il D.Lgs. 138/2024, chiede ai soggetti nel perimetro di gestire vulnerabilità e patch in modo documentato. Unire la migrazione a cgroup v2 all’ammodernamento del sistema operativo, e tracciarla nel processo di change e risk management, permette di chiudere aggiornamento ed evidenze di audit in un solo intervento.
State pianificando un aggiornamento Kubernetes o la migrazione dei nodi a cgroup v2?
I nostri ingegneri pianificano ed eseguono aggiornamenti di cluster Kubernetes, migrazioni dei nodi a cgroup v2 e passaggi a CoreDNS per team di prodotto negli Stati Uniti e nell’UE, anche nei settori regolati in cui un aggiornamento del sistema operativo richiede l’approvazione della compliance. Individuiamo i breaking change rilevanti per la vostra configurazione prima di toccare un solo nodo.
Parla con un ingegnereChe cosa devono fare subito i responsabili tecnici
| Azione | Tempistica | Note |
|---|---|---|
Eseguire stat -fc %T /sys/fs/cgroup/ su tutti i nodi del cluster | Questa settimana | Output tmpfs = cgroup v1: il kubelet non partirà dopo l’aggiornamento. Verificare prima di qualsiasi tentativo di passaggio alla v1.37. |
| Aggiornare le immagini dei nodi su cgroup v1 prima di Kubernetes | Prima della prossima finestra | Obiettivo: RHEL 8+, Rocky Linux 8+, AlmaLinux 8+, Ubuntu 20.04+ o immagine cloud aggiornata. cgroup v2 deve essere attivo nel sistema operativo prima dell’aggiornamento del kubelet. |
| Verificare il DNS: CoreDNS e non kube-dns | Questo sprint | Eseguire kubectl get pods -n kube-system | grep dns. kube-dns va migrato prima della v1.40, altrimenti il DNS del cluster si interrompe. |
| Controllare la modalità IPVS di kube-proxy | Questo sprint | Cercare mode: ipvs in kubectl get configmap kube-proxy -n kube-system -o yaml. Se presente, pianificare nftables prima della v1.43. |
| Documentare la migrazione del sistema operativo nel change management (DORA/NIS2) | Questo ciclo di pianificazione | Per i soggetti regolati: conservare piano di aggiornamento, approvazioni e scenario di rollback come evidenza per audit e autorità. |
| Valutare le funzioni alpha della DRA per carichi su GPU o acceleratori | Questo ciclo di pianificazione | Taint e toleration a livello di dispositivo sono stabili. Le novità alpha della DRA possono ridurre lo scheduling personalizzato nelle pipeline di AI/ML. |
| Aggiornare i runbook dell’HPA (API delle metriche stabile) | Prossimo ciclo | Eliminare le riserve legate alla beta. L’API metrics.k8s.io v1 rientra nella garanzia di compatibilità di Kubernetes. |
Sources: Kubernetes v1.37: Garhwal — Official release blog (kubernetes.io, August 26, 2026); Kubernetes cleans house, bins legacy kube-dns, IPVS, and cgroup v1 (The Register, August 26, 2026).
FAQ
Che cos’è cgroup v1 e perché Kubernetes 1.37 lo rimuove?
cgroup v1 è il meccanismo Linux originale (control groups) con cui Kubernetes raggruppa e limita le risorse di CPU, memoria e I/O dei container. Dalla v1.35 Kubernetes emette avvisi all’avvio dei nodi ancora su cgroup v1. Nella v1.37 diventa un blocco: se il kubelet rileva cgroup v1 all’avvio, il nodo non si inizializza. cgroup v2, disponibile dal kernel Linux 4.5 e predefinito nella maggior parte delle distribuzioni moderne dal 2021, offre una gerarchia unificata, una QoS della memoria migliore, le metriche PSI e una gestione dello swap più efficiente.
Come verifico se i miei nodi usano cgroup v1?
Eseguite stat -fc %T /sys/fs/cgroup/ su ogni nodo. L’output tmpfs indica cgroup v1; cgroup2fs indica cgroup v2 e il nodo è pronto per l’aggiornamento. CentOS 7, RHEL 7 e Ubuntu 18.04 usano cgroup v1 di default. La maggior parte delle immagini dei nodi gestite su EKS, GKE e AKS è passata a cgroup v2 tra il 2022 e il 2023.
Che cos’è il workaround failCgroupV1 e conviene usarlo?
La KubeletConfiguration include il campo failCgroupV1 che, impostato a false, sopprime il blocco all’avvio. Il progetto Kubernetes lo definisce esplicitamente pericoloso: il nodo perde la QoS della memoria, le metriche PSI e le configurazioni di swap che richiedono cgroup v2, e il campo sarà rimosso in una release futura. Da usare solo come assicurazione temporanea durante la migrazione.
Che cosa succede a kube-dns e IPVS in Kubernetes 1.37?
kube-dns viene ritirato nella v1.37 a favore di CoreDNS, predefinito da Kubernetes 1.13 (2018). I cluster ancora su kube-dns devono migrare prima di Kubernetes 1.40, altrimenti il DNS del cluster smetterà di funzionare. IPVS in kube-proxy è deprecato dalla v1.37 e sarà rimosso nella v1.43, sostituito da nftables.
Che cosa significa per l’HPA la promozione a stabile di metrics.k8s.io?
L’API metrics.k8s.io, su cui si basano kubectl top, l’HorizontalPodAutoscaler (HPA) e il VerticalPodAutoscaler (VPA), passa da beta a stabile (v1) in Kubernetes 1.37 dopo nove anni in produzione. Ora rientra nella garanzia di compatibilità di Kubernetes e non cambierà più in modo incompatibile.
Che cosa cambia per le aziende in Italia?
In Italia molti cluster Kubernetes girano on-premise o presso provider nazionali, spesso su immagini Linux enterprise datate: per questi ambienti la 1.37 è prima di tutto un progetto di sistema operativo. Le entità finanziarie soggette a DORA e i soggetti che rientrano nel perimetro NIS2, recepita con il D.Lgs. 138/2024, devono comunque dimostrare una gestione delle vulnerabilità e delle patch: conviene inserire la migrazione a cgroup v2 nel processo di change e risk management.