In sintesi
Kubernetes 1.37 “Garhwal” è stato rilasciato il 26 agosto 2026 con 67 miglioramenti. Per i team con carichi AI/ML contano soprattutto due novità: i taint dei dispositivi DRA diventano stabili (lo scheduler evita da solo i nodi GPU guasti) e il gang scheduling arriva in Beta (posizionamento “tutto o niente” tramite PodGroup, senza plugin di scheduling esterni). Sul fronte delle deprecazioni, kube-dns ha una data di rimozione fissa nella 1.40: è una migrazione da pianificare adesso, non più avanti.
Per gli ingegneri cloud e DevOps, la 1.37 prosegue anche la deprecazione del backend IPVS di kube-proxy, con rimozione prevista nella 1.43. Il sostituto è il backend nftables. Nessuna delle due modifiche rompe nulla oggi, ma entrambe hanno una scadenza fissa: ignorarle significa andare incontro a un aggiornamento doloroso.
Cosa include Kubernetes 1.37
Kubernetes rilascia una nuova versione circa ogni quattro mesi; la 1.37 “Garhwal” (dal nome della regione himalayana dell’Uttarakhand) è arrivata il 26 agosto 2026. I 67 miglioramenti si dividono in 16 Stable, 23 Beta e 27 Alpha, più un annuncio di deprecazione. Il progetto segue con attenzione la maturità di ogni funzionalità: Stable significa che l’API è bloccata e sicura in produzione, Beta che può ancora cambiare in piccola misura ma è pronta per test estesi.
Il tema della release è l’efficienza dei carichi su GPU e acceleratori. Le due funzionalità principali — taint dei dispositivi DRA e gang scheduling — affrontano guasti che i team incontrano di continuo nel training e nell’inferenza dei grandi modelli linguistici: un nodo GPU guasto che blocca silenziosamente un job e un posizionamento parziale dei Pod che brucia il budget degli acceleratori. La comunità dell’ingegneria Kubernetes tratta questi problemi come prioritari dall’ondata del calcolo AI; con la 1.37 le risposte del control plane escono dall’Alpha.
Taint dei dispositivi DRA: aggirare le GPU guaste su larga scala
Dynamic Resource Allocation (DRA) è il framework di Kubernetes per gestire acceleratori e hardware specializzato. Nella 1.37, DRA ottiene i taint dei dispositivi come Stable: lo stesso meccanismo taint/toleration che gli operatori usano già per i vincoli di scheduling a livello di nodo, applicato direttamente alle singole GPU o ai singoli acceleratori.
In pratica, un device plugin (o il driver DRA) può contrassegnare una GPU specifica come NoSchedule o NoExecute quando rileva errori hardware, guasti della memoria ECC o throttling termico. Lo scheduler smette quindi di posizionare sul nodo nuovi Pod che richiedono quel dispositivo, e i Pod esistenti senza toleration corrispondente possono essere espulsi. La GPU guasta viene aggirata in automatico: nessuno deve svuotare il nodo o metterlo in cordon a mano.
Perché conta su larga scala? Nei grandi cluster di training — da 64 a 256 nodi H100 o B200 — una sola GPU degradata può bloccare un intero job multi-nodo o produrre in silenzio risultati errati. Prima dei taint DRA, gli operatori dovevano monitorare lo stato delle GPU fuori dal cluster, intervenire manualmente e rimettere in coda i job. Con i taint DRA stabili se ne occupa il control plane: il dispositivo difettoso viene segnalato, il lavoro viene reindirizzato e il job prosegue su hardware sano. A 2–3 dollari per ora-GPU, questa automazione si traduce direttamente in budget di calcolo recuperato.
Gang scheduling: posizionamento dei Pod “tutto o niente”
Il gang scheduling — o preemption consapevole del workload — risolve il problema del posizionamento parziale: un job di training distribuito richiede N Pod worker con GPU, ma solo N-2 possono essere posizionati perché due nodi sono occupati. Senza gang scheduling, quegli N-2 worker partono, occupano la memoria GPU e restano inattivi in attesa dei ritardatari. Con il gang scheduling, lo scheduler posiziona tutti gli N Pod insieme oppure nessuno, e mette il job in coda finché la capacità non è disponibile.
In Kubernetes 1.37, il gang scheduling tramite preemption consapevole del workload passa in Beta su scheduling.k8s.io/v1beta1. L’API PodGroup permette di dichiarare un insieme di Pod come unità logica; lo scheduler ne tratta il posizionamento in modo atomico. Se un job a priorità più alta ha bisogno delle risorse del cluster, il PodGroup in attesa viene sottoposto a preemption per intero, invece di disperdere i singoli Pod nella coda di espulsione.
Il beneficio operativo è significativo: i job di training non lasciano più GPU inattive in attesa dei ritardatari, e l’utilizzo complessivo degli acceleratori migliora perché job posizionati a metà non trattengono più risorse. Finora serviva installare scheduler esterni come Volcano o YuniKorn. Nella 1.37 la funzionalità è nel core: nessun componente di control plane in più da versionare, monitorare e aggiornare insieme al cluster.
Deprecazioni con scadenze fisse
Kubernetes 1.37 introduce due deprecazioni con una tabella di marcia di rimozione vincolante — non un generico “potrebbe essere rimosso in futuro”, ma release precise.
kube-dns deprecato; rimozione in Kubernetes 1.40. CoreDNS è l’implementazione DNS predefinita da Kubernetes 1.13 (2019). kube-dns era sopravvissuto come opzione per i cluster precedenti al passaggio. Con la 1.37 il progetto lo depreca formalmente e fissa la rimozione alla 1.40. Per chi usa servizi Kubernetes gestiti — EKS, GKE, AKS — probabilmente non è un problema: questi servizi usano CoreDNS da anni. I cluster autogestiti con installazioni kube-dns dell’epoca 1.12 dovrebbero verificare il proprio deployment DNS prima di superare la 1.39.
Backend IPVS di kube-proxy deprecato; rimozione in Kubernetes 1.43. IPVS era nato come alternativa ad alte prestazioni a iptables per kube-proxy nei cluster di grandi dimensioni. Il backend nftables, stabile da Kubernetes 1.33, è ora il successore raccomandato. nftables richiede Linux 5.13 o successivo: verificate la versione del kernel prima di migrare. La scadenza 1.43 lascia diversi cicli di release, ma la migrazione richiede un riavvio di kube-proxy su ogni nodo — pianificatela invece di subirla.
Cosa significa per i team software negli Stati Uniti e in Europa
Per i team che sviluppano prodotti AI/ML su infrastruttura cloud, i miglioramenti GPU della 1.37 arrivano al momento giusto. La spesa per infrastrutture di inferenza e training basate su Kubernetes è cresciuta molto nel 2026, e il collo di bottiglia si è spostato dalla qualità dei modelli all’efficienza operativa: come tenere occupate GPU costose, gestire i guasti hardware senza interventi manuali e ridurre l’inattività nelle code di training.
Taint dei dispositivi DRA e gang scheduling eliminano insieme due delle cause più frequenti di spreco di GPU. Il primo automatizza la risposta ai guasti (dispositivo segnalato, workload reindirizzato), il secondo rimuove la frammentazione che lascia girare a vuoto job posizionati a metà. I team con training distribuiti in produzione vedranno entrambi i vantaggi senza scrivere nuovo codice infrastrutturale: aggiornare il cluster, configurare il driver DRA perché emetta i taint e definire PodGroup per i training batch.
Le deprecazioni sono più una questione di igiene operativa che un’emergenza. Un cluster che usa ancora kube-dns ha due cicli di release prima della 1.40; la risposta corretta è inserire la migrazione nel prossimo sprint infrastrutturale. La migrazione a nftables per chi usa IPVS è ancora più lontana (1.43), ma il requisito di kernel (Linux 5.13+) impone ad alcune VM o host bare metal datati un aggiornamento del sistema operativo prima — avviate subito questa verifica.
Cosa significa per il mercato italiano?
In Italia molte aziende stanno portando i primi progetti di AI generativa dalla fase pilota alla produzione, spesso con poche GPU condivise tra più team e budget di calcolo stretti: proprio lo scenario in cui una GPU guasta non rilevata o un training posizionato a metà pesano di più. Per chi opera in cloud, la scelta ricade spesso su region europee o su infrastrutture proprie per esigenze di residenza dei dati; vale la pena chiedere esplicitamente al provider quando la 1.37 sarà disponibile nei servizi gestiti e con quali driver GPU.
Nei settori regolati il cambiamento va governato: banche e assicurazioni sono soggette dal gennaio 2025 al regolamento europeo DORA, che richiede una gestione documentata dei cambiamenti ICT, mentre la Pubblica Amministrazione può usare solo servizi cloud qualificati dall’Agenzia per la Cybersicurezza Nazionale (ACN). Un aggiornamento che tocca DNS e backend di rete dovrebbe quindi passare come change pianificato, con evidenza di test in un ambiente di collaudo, piano di rollback e approvazione. La 1.37 lascia margine sufficiente per gestire correttamente le migrazioni di kube-dns e IPVS dentro questo processo.
Tre azioni prima della 1.38
- Verificate lo stack DNS. Eseguite
kubectl get pods -n kube-system -l k8s-app=kube-dns. Se compaiono Pod kube-dns, pianificate la migrazione a CoreDNS prima di superare la 1.39. La guida alla migrazione nella documentazione di Kubernetes è semplice per la maggior parte dei cluster; il rischio riguarda i cluster con stub zone personalizzate da portare. - Attivate i taint dei dispositivi DRA nei node pool GPU. Verificate che la versione del device plugin NVIDIA, AMD o Google sia in grado di emettere taint DRA. NVIDIA GPU Operator 24.x e successivi supportano l’API DRA stabile. Aggiornate il device plugin prima di passare alla 1.37, così che i taint siano attivi fin dal primo giorno.
- Testate il gang scheduling sui training più grandi. Create un cluster di staging su 1.37 e annotate i job multi-worker con
scheduling.k8s.io/pod-group. Misurate l’utilizzo delle GPU prima e dopo l’attivazione: la riduzione dell’inattività è di solito misurabile già nel primo ciclo completo.
Domande frequenti
Cosa sono i taint dei dispositivi DRA in Kubernetes 1.37?
I taint dei dispositivi DRA consentono al control plane di contrassegnare una specifica GPU o un acceleratore come degradato o guasto. Una volta applicato il taint, lo scheduler non vi posiziona più nuovi Pod che richiedono quel dispositivo e i Pod esistenti senza toleration corrispondente possono essere espulsi. La risposta ai guasti GPU diventa automatica, senza svuotare manualmente un nodo. I taint dei dispositivi DRA sono stabili da Kubernetes 1.37.
Cos’è il gang scheduling in Kubernetes e perché conta per l’AI?
Il gang scheduling garantisce che tutti i Pod di un workload distribuito, come i worker di un job di training, vengano posizionati insieme o per niente. Senza, alcuni worker occupano GPU e restano inattivi in attesa di ritardatari che non possono essere posizionati. Nella 1.37 il gang scheduling tramite preemption consapevole del workload è arrivato in Beta con l’API PodGroup (scheduling.k8s.io/v1beta1), disponibile nel core senza plugin di scheduling esterni.
Quando verrà rimosso kube-dns da Kubernetes?
kube-dns è deprecato in Kubernetes 1.37 e la rimozione è prevista in Kubernetes 1.40. Chi lo usa ancora dovrebbe migrare a CoreDNS prima che il cluster arrivi alla 1.40. CoreDNS è il predefinito da Kubernetes 1.13 e la maggior parte dei servizi gestiti (EKS, GKE, AKS) lo usa già. I cluster autogestiti possono verificarlo con kubectl get pods -n kube-system -l k8s-app=kube-dns.
Cosa sostituisce IPVS in Kubernetes?
Il backend nftables di kube-proxy sostituisce IPVS. nftables è stabile da Kubernetes 1.33 e richiede un kernel Linux 5.13 o successivo. IPVS è deprecato nella 1.37, con rimozione prevista in Kubernetes 1.43. La migrazione richiede un riavvio di kube-proxy su ogni nodo: pianificatela come intervento di manutenzione, non come modifica estemporanea.
Conviene aggiornare subito a Kubernetes 1.37?
Sì, la 1.37 è una release stabile e l’aggiornamento dalla 1.36 è semplice. Prima di procedere: individuate ogni uso di kube-dns e IPVS per pianificare le migrazioni, verificate che i device plugin GPU supportino l’API DRA stabile e testate il gang scheduling in staging per i training distribuiti. Nessuna funzionalità deprecata viene rimossa nella 1.37: le rimozioni arrivano nella 1.40 (kube-dns) e nella 1.43 (IPVS).
Fonti
Kubernetes Project — Kubernetes v1.37 Release, 26 August 2026 (primary source)
The Register — Kubernetes cleans house, bins legacy kube-dns, IPVS and cgroup v1, 26 August 2026
Cloud Native Now — Kubernetes v1.37 Enhances Dynamic Resource Allocation, 2026