GPU e AI mettono in crisi autoscaler e scheduler di Kubernetes

Con carichi AI su GPU, pod che dovrebbero partire restano pending anche quando il cluster ha ancora capacità utile: l’autoscaler aggiunge nodi che lo scheduler non userà. Lo segnala la Cloud Native Computing Foundation in un articolo del 19 ottobre 2026¹.

Per anni Kubernetes ha retto su due loop separati. Lo scheduler piazza i pod su nodi esistenti. L’autoscaler crea nodi quando i pod non ci stanno. La separazione ha funzionato perché il calcolo era in gran parte intercambiabile. Ogni loop poteva decidere senza conoscere a fondo l’altro¹.

Con l’AI cambiano le condizioni. Gli acceleratori rendono i nodi meno fungibili. La scelta del nodo diventa vincolo, non dettaglio. Conta la tipologia, contano le risorse presenti. Qui emerge il difetto: i due loop non si parlano abbastanza per legare la scala al bisogno reale del pod¹.

Chi gestisce GPU conosce la scena. Un pod resta pending. Il cluster non è a secco. Capacità di acceleratori esiste, ma resta inutilizzata. L’istinto punta alla scarsità di regione. A volte è così. Altre volte no: il nodo che l’autoscaler è pronto ad aggiungere non è un nodo che lo scheduler potrà accettare per quel pod.

Risultato: spreco. GPU ferme, applicazioni in attesa. La catena si inceppa prima della scelta del nodo utile. La domanda operativa non è più solo se scalare. Conta cosa scalare perché lo scheduler possa collocare quel pod. Questa è la correzione di rotta proposta nel pezzo della fondazione¹.

Non si demolisce il design originario. La separazione tra loop regge gran parte dei carichi. Gli edge case dell’AI però mostrano dove la divisione fatica. Un nodo “qualsiasi” non basta quando serve un certo acceleratore o una specifica capacità. La decisione di scala deve riflettere il vincolo espresso dal pod, non un’astrazione della capacità.

Il collo di bottiglia nasce dallo sfasamento nel tempo e nell’informazione. L’autoscaler vede che serve un nodo e lo aggiunge. Lo scheduler poi, con regole proprie, rifiuta quel nodo per quel pod. Il ciclo ricomincia. In mezzo rimane capacità di acceleratori senza uso.

Contare nodi o GPU “in aggregato” non basta. Serve legare la scelta del nodo al requisito concreto del carico in attesa. La CNCF riassume in una domanda pratica: non se scalare, ma cosa esattamente scalare, così che lo scheduler possa poi collocare il pod¹.

C’è un motivo di tempistica. Il ritmo con cui evolvono i carichi AI sposta questi bordi del sistema da curiosità a priorità. È qui che operatori e sviluppatori possono intervenire: allineare i due loop sulla realtà dei vincoli, prima che la capacità resti di nuovo parcheggiata.¹