Volcano 1.16 introduce NamespaceQueue e fairshare, amplia HyperNode

Nei cluster multi-tenant cambia la coda: Volcano 1.16 aggiunge NamespaceQueue e fairshare, così i tenant gestiscono code per namespace e ricevono risorse in modo più equilibrato quando condividono la stessa coda¹.

NamespaceQueue porta code gerarchiche dentro il perimetro del namespace. Gli amministratori autorizzano i pool di risorse. I team definiscono quote e priorità senza uscire dal proprio spazio e senza violare i limiti di piattaforma¹.

Fairshare inserisce lo storico dei consumi nel ciclo di scheduling. Se più namespace puntano alla stessa coda, lo scheduler guarda alla cronologia d’uso e distribuisce le assegnazioni tra i namespace, non tra singoli Pod. Così chi ha consumato di più non continua a prevalere quando le richieste convergono sulla stessa coda¹.

Sul fronte HyperNode, arriva un’adozione più flessibile. Le piattaforme che usano altri scheduler possono distribuire solo il controller HyperNode, senza toccare il componente di scheduling esistente. Il controller scopre la topologia, gestisce i supernode e le relative gerarchie, ed espone queste informazioni tramite la HyperNode API per l’integrazione con la piattaforma in uso¹.

Per i servizi di inferenza entrano regole di topology anti-affinity nei PodGroup. Le istanze si distribuiscono su supernode diversi per ridurre l’esposizione a un dominio di failure comune. La separazione su più supernode limita l’impatto di un guasto che colpisca una singola unità logica di infrastruttura¹.

Lo scheduler guadagna anche efficienza. L’Unschedulable Job Cache registra perché un Job non è schedulabile e salta i controlli ripetuti finché la condizione bloccante non cambia. Oltre a questa cache, migliorano tre percorsi interni: scoring dei nodi, aggiornamenti della cache e lookup delle code. Risultato atteso: meno lavoro inutile e passaggi critici più rapidi¹.

L’aggiornamento include il supporto a Kubernetes 1.36, la stima del carico per il dispatch in blocco dei Pod e lo scoring DRA. Queste funzioni si sommano al resto del ciclo e completano il perimetro tecnico della versione¹.

Per i tenant significa controllo locale delle code e assegnazioni più eque sotto contesa. Per i gestori di piattaforma, una via di integrazione graduale di HyperNode senza cambiare lo scheduler in uso. Per i carichi di inferenza, una diffusione più sicura su domini di failure separati¹.