Le nuove funzionalità di scheduling sono pensate per i job di training AI e machine learning, dove gruppi di pod devono partire e scalare insieme.

Quando il progetto open source Kubernetes è nato, più di dieci anni fa, l’AI non era certo una priorità. I tempi sono cambiati.

Kubernetes 1.37 è disponibile e amplia le capacità di networking e di scheduling della piattaforma, mentre sempre più organizzazioni ci fanno girare workload di AI e machine learning. È il secondo aggiornamento maggiore del 2026, dopo la 1.36 uscita ad aprile. La release ha il nome in codice Garhwal, dalla regione dell’India settentrionale da cui proviene Dipesh Rawat, release lead della 1.37.

Un pezzo importante della 1.37 è la transizione del networking iniziata con Kubernetes 1.35, che aveva deprecato la modalità IPVS di kube-proxy e portato in general availability la modifica in-place delle risorse dei pod. Per chi si occupa di rete, la 1.37 continua a spostare la gestione del traffico di cluster da IPVS verso nftables. Anche lo scheduling diventa più workload aware, con funzionalità costruite per i job di training AI e machine learning che hanno bisogno di far partire e scalare gruppi di pod insieme.

Kubernetes è sempre più costruito attorno alla forma dei workload che esegue, non solo attorno ai singoli pod che li compongono.

«Prima c’era solo il pod: lo scheduler guardava il pod e lo schedulava», ha detto Rawat a Network World. «Ora Kubernetes nel suo insieme sta cercando di diventare workload aware.»

Lo scheduling workload-aware guarda all’AI

Storicamente Kubernetes ha schedulato e scalato i pod uno alla volta, con poca consapevolezza di come quei pod fossero collegati tra loro. È un approccio che funziona per i servizi stateless, ma crea problemi con i workload AI, dove più pod devono spesso partire insieme, condividere l’accesso agli acceleratori e scalare come gruppo anziché individualmente. La 1.37 affronta il problema con diverse funzionalità che portano sulla piattaforma un approccio di scheduling workload-aware.

HPA scale to zero (KEP-2021). Lo scale to zero dell’HorizontalPodAutoscaler passa in Beta nella 1.37 ed è abilitato di default. Permette a un Horizontal Pod Autoscaler di portare a zero le repliche di un workload quando la domanda sparisce, e di ripristinarle quando la domanda torna, usando metriche object o external al posto di quelle su CPU o memoria. Rawat ha spiegato che la funzionalità dipende da quei segnali esterni proprio perché, una volta che le repliche sono a zero, non c’è nessun pod in esecuzione di cui misurare CPU o memoria. «In sostanza, se stai facendo girare workload pesanti su GPU costose, ti fa risparmiare», ha aggiunto Rawat.

Gang scheduling (KEP-4671). Sascha Grunert, principal engineer nel team OpenShift Node di Red Hat, ha detto a Network World che questa funzionalità porta nativamente il piazzamento dei pod “tutto o niente” per i job di training distribuito.

Preemption workload-aware (KEP-5710). Anche questa funzionalità passa in Beta nella 1.37. Consente allo scheduler di valutare un PodGroup, invece dei singoli pod, quando deve fare preemption di workload a priorità più bassa.

Taint e toleration sui device DRA (KEP-5055). La Dynamic Resource Allocation (DRA) è il meccanismo con cui Kubernetes assegna hardware come le GPU ai workload. Questa funzionalità, che raggiunge lo stato Stable nella 1.37, permette a Kubernetes di marcare un device rotto o degradato in modo che non venga più assegnato a nuovi workload, come già oggi si può marcare come off-limits un nodo guasto. Gli amministratori possono inoltre escludere device in base a criteri come il driver che li gestisce. Secondo Grunert, la funzionalità consente di fare il drain dell’hardware degradato usando il familiare modello dei taint sui nodi.

Kubernetes migliora il networking

Kubernetes 1.37 continua a spostare il networking di cluster da IPVS e iptables verso nftables, l’approccio più recente integrato nel kernel Linux.

Il componente kube-proxy, cioè il servizio che instrada il traffico verso i Service di Kubernetes, supporta IPVS come alternativa a iptables fin da Kubernetes 1.8, ma IPVS si è sempre appoggiato a iptables sotto il cofano. Questa dipendenza è una delle ragioni per cui Kubernetes sta deprecando la modalità IPVS a favore di nftables.

«La storia principale è la transizione da iptables a nftables», ha detto Grunert.

Ha spiegato che i cluster che non impostano esplicitamente una modalità di kube-proxy ora ricevono un warning di deprecazione (KEP-5343). Inoltre il backend IPVS è formalmente deprecato (KEP-5495), con una roadmap che prevede di disabilitarlo nella 1.40 e rimuoverlo nella 1.43.

«nftables offre prestazioni migliori grazie agli aggiornamenti incrementali delle regole ed è allineato con la direzione dello stack di rete del kernel Linux», ha detto Grunert.

Un’altra novità di networking segnalata da Grunert è il DRA Resource Claim Status con dati standardizzati sulle interfacce di rete (KEP-4817). Grunert nota che dà ai driver DRA un modo coerente per descrivere le interfacce di rete collegate, cosa sempre più rilevante per i workload GPU e RDMA.

La sicurezza del cluster fa un passo avanti

I Pod Certificates (KEP-4317) e i ClusterTrustBundles (KEP-3257) migliorano la sicurezza dei cluster Kubernetes.

«I pod certificate e i cluster trust certificate sono passati a stable: in pratica ti danno un modo di prima classe per condividere chiavi private e certificati X.509 tra i pod, ed è una bella cosa», ha detto Rawat.

Grunert sottolinea che le due funzionalità danno a Kubernetes, per la prima volta, una storia completa e nativa di PKI per i workload. «I pod possono richiedere certificati X.509 a vita breve e ricevere trust anchor a livello di cluster tramite projected volume, rendendo possibile mTLS senza tooling esterno come cert-manager o SPIFFE/SPIRE», ha detto.

Stare dietro alla domanda di sviluppo

Oltre alle nuove funzionalità, il release team di Kubernetes sta aggiustando il proprio processo in vista delle prossime release.

Rawat ha spiegato che il numero di Kubernetes Enhancement Proposal (KEP) che entrano in ogni release è in crescita, e che questa release ha portato con sé un volume elevato di richieste di eccezione da parte dei contributor, che chiedevano più tempo per rispettare le scadenze.

Per la prossima release, il team ha quindi deciso di accorciare le due settimane di pausa che di solito servono tra una release e l’altra per sistemare i processi e aggiornare la documentazione. «In pratica questo ci dà due settimane effettive in più di sviluppo e test», ha detto Rawat.

Anche l’AI potrebbe contribuire ad accelerare lo sviluppo futuro di Kubernetes.

«Come community Kubernetes abbiamo una AI policy: i contributor sono liberi di usare qualsiasi strumento AI per aprire una PR, ma devono dichiararlo nella descrizione della PR», ha detto Rawat.

Il release team, di suo, non ha usato strumenti AI nel processo della release 1.37, affidandosi al lavoro manuale e all’automazione già esistente.

«Spero che in futuro, quando l’adozione crescerà e la community avrà definito processi adeguati, potremo iniziare ad adottarli», ha detto Rawat.