NVIDIA dona il DRA Driver per GPU al CNCF e potenzia l'orchestrazione Kubernetes per l'AI
NVIDIA dona il driver DRA per GPU alla CNCF, introdusse il supporto GPU per Kata Containers e presenta AI Cluster Runtime per configurazioni Kubernetes validat…
Contenuto

Scopri anche
- NVIDIA rilascia Nemotron-Cascade 2: modello MoE da 30B con soli 3B parametri attivi per reasoning avanzato
- L'efficienza energetica dei chip Nvidia: il nuovo imperativo per l'infrastruttura AI
- Evo 2 e longevità: l'IA progetta genomi ma la vita richiede più del 70% di precisione
- GreenBoost: il driver open source che estende la VRAM delle GPU NVIDIA con RAM di sistema e NVMe
- Intel 18A e la strategia di recupero: produzione USA, partnership AI e sfide nel foundry
- Corea del Sud lancia la "AI Squid Game" per competere con USA e Cina
- Intel conferma il commitment verso le GPU: nuova roadmap focus su data center e AI
- Samsung e Nvidia consolidano l'alleanza AI: dal chip Groq 3 LPU all'AI Megafactory con oltre 50.000 GPU
- Qwen 3.5: Alibaba lancia modelli open-source che competono con GPT e Gemini
- NVIDIA DGX Spark: il supercomputer desktop per l'intelligenza artificiale
- L'intelligenza artificiale tra opportunità di investimento e sfide etiche: un quadro del settore
- Nvidia fornirà 1 milione di chip ad Amazon Web Services entro il 2027
- Nvidia registra utili record da 120 miliardi di dollari ma gli investitori temono una bolla AI
- Agenti AI: l'architettura invisibile che sta ridefinendo il software
- SiFive integra NVIDIA NVLink Fusion per i data center AI RISC-V di nuova generazione
- NVIDIA GTC 2026: Annunciate Vera Rubin, OpenClaw e la piattaforma per l'IA agentica
- AMD definisce le "Agent Computer" come nuova frontiera dell'AI PC
- Vivaldi 7.2: evoluzione della barra degli indirizzi e percorso verso il rilascio stabile
- AMD a CES 2026: la sfida dello yotta-scale computing tra innovazione e tensioni di mercato
- NVIDIA GTC 2026: Vera Rubin, OpenClaw e l'infrastruttura AI da un trilione di dollari
NVIDIA dona il DRA Driver per GPU al CNCF e potenzia l'orchestrazione Kubernetes per l'AI
- Supporto GPU per Kata Containers
- KAI Scheduler come progetto Sandbox CNCF
- Grove e l'ecosistema Dynamo
- AI Cluster Runtime per configurazioni Kubernetes validate
- Snapshot e validazione dei cluster
- Fasi di validazione
- NVIDIA GPU Operator: automazione del lifecycle delle GPU
- Architettura a tre strati
- Processo di deployment dell'GPU Operator
- Monitoraggio con DCGM Exporter
- Funzionalità avanzate
- Installazione e requisiti su Azure AKS
- Collaborazione e contributi
- Implicazioni e scenari
- Cosa monitorare
- Fonti
L'intelligenza artificiale è diventata uno dei workload più rilevanti nel computing moderno. Per la maggior parte delle imprese, questo carico di lavoro viene eseguito su Kubernetes, la piattaforma open source che automatizza il deployment, il dimensionamento e la gestione delle applicazioni containerizzate. NVIDIA ha annunciato al KubeCon Europe di Amsterdam la donazione del NVIDIA Dynamic Resource Allocation (DRA) Driver per GPU alla Cloud Native Computing Foundation (CNCF), organizzazione neutrale che favorisce l'ecosistema cloud-native.
Il driver passa dalla governance del vendor alla piena proprietà della comunità sotto il progetto Kubernetes. Chris Aniszczyk, chief technology officer della CNCF, ha dichiarato che la profonda collaborazione di NVIDIA con la comunità Kubernetes e CNCF per integrare il driver DRA segnala una tappa rilevante per Kubernetes open source e l'infrastruttura AI, rendendo l'orchestrazione GPU ad alte prestazioni accessibile a tutti.
Supporto GPU per Kata Containers
⬆ Torna suIn collaborazione con la comunità Confidential Containers della CNCF, NVIDIA ha introdotto il supporto GPU per Kata Containers, macchine virtuali leggere che fungono da container. Questa estensione dell'accelerazione hardware introduce un isolamento più forte, separando i workload per maggiore sicurezza e consentendo l'esecuzione di workload AI con protezione avanzata per implementare il confidential computing.
Storicamente, la gestione delle GPU nei data center richiedeva uno sforzo significativo. NVIDIA collabora con leader del settore tra cui Amazon Web Services, Broadcom, Canonical, Google Cloud, Microsoft, Nutanix, Red Hat e SUSE per sviluppare queste funzionalità a beneficio dell'intero ecosistema cloud-native.
KAI Scheduler come progetto Sandbox CNCF
⬆ Torna suNVIDIA ha annunciato che il suo scheduler per workload AI ad alte prestazioni, KAI Scheduler, è stato inserito come progetto Sandbox CNCF. Questo passaggio favorisce una collaborazione più ampia e garantisce che la tecnologia si evolva insieme alle esigenze dell'ecosistema cloud-native. Sviluppatori e organizzazioni possono utilizzare e contribuire al KAI Scheduler sin da subito.
Inoltre, NVIDIA ha comunicato che NVSentinel, un sistema per la correzione dei guasti GPU, e AI Cluster Runtime, un framework AI agentic, sono stati presentati al GTC della settimana precedente.
Grove e l'ecosistema Dynamo
⬆ Torna suSuccessivamente al rilascio di NVIDIA Dynamo 1.0, NVIDIA sta espandendo l'ecosistema Dynamo con Grove, un'interfaccia di programmazione applicativa Kubernetes open source per orchestrare i workload AI su cluster GPU. Grove consente agli sviluppatori di esprimere sistemi di inferenza complessi in una singola risorsa dichiarativa e viene integrato con lo stack di inferenza llm-d per una più ampia adozione nella comunità Kubernetes.
AI Cluster Runtime per configurazioni Kubernetes validate
⬆ Torna suAI Cluster Runtime è un progetto open source di NVIDIA che semplifica e standardizza la configurazione dei cluster Kubernetes per i workload AI fornendo ricette validate e riproducibili con versioni esatte dei componenti e ordine di deployment. Gli utenti possono effettuare uno snapshot dello stato corrente del cluster, generare ricette personalizzate per ambienti specifici e convalidare i deployment rispetto agli standard NVIDIA, garantendo configurazioni coerenti tra cloud e hardware come gli acceleratori NVIDIA H100 e NVIDIA Blackwell.
Ogni cluster AI su Kubernetes richiede uno stack software completo che funzioni insieme, dai driver di basso livello e impostazioni del kernel fino agli operator e alle configurazioni del workload. Il progetto pubblica le configurazioni Kubernetes ottimizzate, validate e riproducibili come ricette distribuibile sui cluster. Questi file YAML con versione bloccata catturano quali componenti sono stati testati, le versioni e i valori di configurazione per un determinato ambiente. Le ricette includono vincoli come la versione minima di Kubernetes, il sistema operativo richiesto, la versione del kernel e un ordine di deployment calcolato basato sulle dipendenze dei componenti.
Snapshot e validazione dei cluster
⬆ Torna suCon un cluster in esecuzione, è possibile acquisire uno snapshot del suo stato prima di generare una ricetta. Questo cattura il sistema operativo, la versione del kernel, l'hardware GPU e il driver, la versione Kubernetes e gli operator installati. Il comando snapshot esegue un Job di breve durata su un nodo target, raccoglie le misurazioni di sistema e scrive i risultati in una ConfigMap o file locale. Lo snapshot diventa la linea base contro cui i controlli di validazione vengono eseguiti.
Il comando recipe prende una descrizione dell'ambiente target e la confronta con una libreria di overlay validati per produrre una singola ricetta con versioni esatte dei componenti e impostazioni. Le ricette sono composte da livelli anziché mantenute come configurazioni monolitiche, con valori più specifici che hanno precedenza su quelli generali. Una ricetta completamente specializzata, come NVIDIA Blackwell con EKS, Ubuntu, training e Kubeflow, contiene fino a 268 valori di configurazione su 16 componenti.
Fasi di validazione
⬆ Torna suLa validazione si svolge in fasi. Prima di distribuire qualsiasi cosa, un controllo di readiness confronta i vincoli della ricetta con lo snapshot: versione Kubernetes, sistema operativo, kernel e hardware GPU. Dopo il deployment, le fasi successive convalidano la salute dei componenti e la conformità, verificando requisiti come l'allocazione dinamica delle risorse (DRA), la gang scheduling e il networking a livello di job secondo il programma CNCF Certified Kubernetes AI Conformance.
Le ricette si aggiornano man mano che le pipeline di validazione interne NVIDIA vengono eseguite. Nuove versioni dei componenti, aggiornamenti dei driver e modifiche ai parametri del kernel confluiscono nelle ricette pubblicate man mano che vengono testate. Quando una particolare impostazione NCCL migliora il throughput di Blackwell, questa viene inclusa nella prossima versione della ricetta. Poiché ogni ricetta è versionata, è possibile confrontare il deployment attuale con l'ultima configurazione validata e vedere esattamente cosa è cambiato prima di aggiornare.
NVIDIA GPU Operator: automazione del lifecycle delle GPU
⬆ Torna suIl NVIDIA GPU Operator utilizza il framework operator all'interno di Kubernetes per automatizzare la gestione di tutti i componenti software NVIDIA necessari per il provisioning delle GPU. Questi componenti includono i driver NVIDIA per abilitare CUDA, il plugin device Kubernetes per GPU, il NVIDIA Container Toolkit, l'etichettatura automatica dei nodi tramite GFD, il monitoraggio basato su DCGM e altri ancora.
L'GPU Operator consente agli amministratori di cluster Kubernetes di gestire i nodi GPU proprio come i nodi CPU nel cluster. Invece di predisporre un'immagine OS speciale per i nodi GPU, gli amministratori possono affidarsi a un'immagine OS standard per entrambi i tipi di nodi e poi contare sull'GPU Operator per fornire i componenti software necessari per le GPU. Questo è particolarmente utile per scenari in cui il cluster Kubernetes deve scalare rapidamente, ad esempio provisionando nodi GPU aggiuntivi sul cloud o on-prem e gestendo il ciclo di vita dei componenti software sottostanti.
Architettura a tre strati
⬆ Torna suL'integrazione GPU in Kubernetes comporta una configurazione manuale complessa a tre strati. Al livello host, il driver dispositivo NVIDIA comunica direttamente con l'hardware GPU. La compatibilità della versione tra driver e toolkit CUDA nell'immagine container è un requisito fondamentale: qualsiasi mismatch può compromettere la funzionalità GPU. Successivamente, il NVIDIA Container Toolkit funge da ponte tra il runtime del container come Docker, containerd o CRI-O e la GPU host. Infine, il NVIDIA Device Plugin, eseguito come DaemonSet sui nodi abilitati GPU, permette a Kubernetes di riconoscere e programmare le risorse GPU.
Processo di deployment dell'GPU Operator
⬆ Torna suL'GPU Operator segue il pattern Kubernetes Operator, automatizzando il deployment di driver, toolkit e plugin GPU utilizzando Helm. Una volta distribuito, inizializza il pod gpu-operator, un servizio di supervisione e riconciliazione, insieme al servizio node-feature-discovery che crea un pod su ogni nodo del cluster per rilevare le GPU collegate e aggiungere etichette ai nodi pertinenti. Queste etichette aiutano con lo scheduling e assicurano che solo i componenti necessari vengano distribuiti su quei nodi specifici.
I tre componenti installati sequenzialmente sono il driver, il container toolkit e il device plugin. Il driver NVIDIA è un DaemonSet distribuito su ogni nodo con GPU che esegue nvidia-installer per installare il modulo kernel sul sistema operativo host. Il toolkit container viene installato solo dopo che il driver è stato trovato, tramite un volume mount. Il device plugin espone le GPU come risorse di prima classe in Kubernetes utilizzando il framework device plugin per comunicare con il kubelet.
Monitoraggio con DCGM Exporter
⬆ Torna suIl monitoraggio delle GPU è fondamentale per massimizzare l'efficienza e garantire un forte ritorno sull'investimento per queste risorse computazionali costose. Il DCGM Exporter, incluso nell'GPU Operator, raccoglie metriche come utilizzo GPU, consumo di memoria, temperatura, errori ECC e stato di salute generale, esponendole tramite un endpoint HTTP in formato compatibile con Prometheus sulla porta 9400. Queste metriche possono essere visualizzate tramite dashboard Grafana, consentendo agli operatori di rilevare anomalie, ottimizzare i workload e garantire un utilizzo efficiente delle GPU nel cluster.
Funzionalità avanzate
⬆ Torna suL'GPU Operator supporta funzionalità avanzate come vGPU, Multi-Instance GPU (MIG), GPU Time-Slicing e semplifica configurazioni di rete e storage avanzate con GPUDirect RDMA e GPUDirect Storage. GPUDirect RDMA consente l'accesso diretto alla memoria tra GPU e dispositivi PCIe come NIC o adattatori storage, senza coinvolgere la CPU o la RAM di sistema, ideale per l'High-Performance Computing e l'addestramento AI dove la latenza è critica. GPUDirect Storage permette alle GPU di leggere dati direttamente da dispositivi NVMe, essenziale per i workload AI/ML che necessitano di accedere ed elaborare grandi dataset rapidamente.
Installazione e requisiti su Azure AKS
⬆ Torna suSu Azure Kubernetes Service (AKS), l'GPU Operator NVIDIA automatizza la gestione e il deployment di tutti i componenti software NVIDIA necessari per il provisioning GPU, inclusa l'installazione dei driver, il plugin dispositivo NVIDIA per Kubernetes e il runtime container NVIDIA. Poiché l'GPU Operator gestisce questi componenti, non è necessario installare separatamente il plugin dispositivo NVIDIA sul cluster AKS. L'installazione automatica dei driver GPU deve essere saltata impostando il campo API --gpu-driver al valore none durante la creazione del pool di nodi.
L'GPU Operator non è compatibile con versioni multiple del sistema operativo sullo stesso cluster AKS. Le VM abilitate GPU contengono hardware specializzato soggetto a prezzi più elevati e disponibilità regionale limitata. Il progetto è disponibile su GitHub come release alpha, includendo il CLI aicr, un server API, un agente cluster e ricette validate che coprono workload di training e inferenza su Kubernetes con acceleratori NVIDIA H100 e NVIDIA Blackwell su Ubuntu 24.04.
Collaborazione e contributi
⬆ Torna suProgettato per la collaborazione fin dall'inizio, AI Cluster Runtime consente a CSP, OEM, team di piattaforma e singoli operatori di aiutare a convalidare diverse combinazioni di hardware, sistema operativo e distribuzioni Kubernetes. I contributori possono copiare un overlay esistente, aggiornare i criteri e la configurazione per il proprio ambiente, eseguire i test e aprire una PR. Il flag --data permette di sovrapporre directory di ricette esterne a runtime, mantenendo configurazioni specifiche dell'organizzazione alongside quelle pubbliche senza fork.
Le ricette di training target Kubeflow Trainer mentre le ricette di inferenza target NVIDIA Dynamo. Ogni release include provenienza SLSA Level 3, SBOM firmati e attestazioni di immagine. Progetti sono in sviluppo per espandere AI Cluster Runtime su piattaforme aggiuntive, acceleratori e tipi di workload.
Questo articolo è una sintesi basata esclusivamente sulle fonti elencate.
Implicazioni e scenari
⬆ Torna suLa donazione del DRA Driver alla CNCF segna un cambiamento nella gestione delle risorse GPU su Kubernetes. Il passaggio da gestione vendor a governance comunitaria potrebbe accelerare l'adozione dell'orchestrazione GPU ad alte prestazioni, riducendo la dipendenza da soluzioni proprietarie.
- Scenario 1: l'integrazione con Kata Containers potrebbe favorire il confidential computing per workload sensibili, ampliando i casi d'uso oltre il training tradizionale.
- Scenario 2: le ricette validate di AI Cluster Runtime potrebbero ridurre gli errori di configurazione, ma l'efficacia dipende dall'aggiornamento costante delle pipeline di validazione.
- Scenario 3: l'ecosistema Grove e Dynamo potrebbe semplificare l'inferenza su cluster GPU, se l'adozione da parte della comunità Kubernetes continuerà a crescere.
Cosa monitorare
⬆ Torna su- L'evoluzione del KAI Scheduler come progetto Sandbox CNCF e i contributi esterni.
- La velocità di aggiornamento delle ricette AI Cluster Runtime rispetto a nuove architetture GPU.
- L'adozione del supporto GPU per Kata Containers negli ambienti produttivi.
Nota editoriale: questa sezione propone una lettura analitica dei temi trattati, senza introdurre dati fattuali non presenti nelle fonti.
Fonti
⬆ Torna su- https://blogs.nvidia.com/blog/nvidia-at-kubecon-2026/
- https://developer.nvidia.com/blog/validate-kubernetes-for-gpu-infrastructure-with-layered-reproducible-recipes/
- https://sagar-parmar.medium.com/nvidia-gpu-operator-explained-simplifying-gpu-workloads-on-kubernetes-436e0a60d0ac
- https://www.spectrocloud.com/blog/the-real-world-guide-to-the-nvidia-gpu-operator-for-kubernetes-ai
- https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/index.html
- https://github.com/NVIDIA/gpu-operator
- https://learn.microsoft.com/en-us/azure/aks/nvidia-gpu-operator
In breve
- nvidia
- gpu
- ai-infrastructure
- opensource