Instalar NVIDIA GPU Operator da por hecho que ya tenés un cluster de Kubernetes corriendo, con nodos listos y un control plane funcionando. NVIDIA acaba de publicar en estado preview un proyecto que ataca el problema un piso más abajo: la gestión de GPUs en Kubernetes desde cero, sobre máquinas bare metal que todavía no tienen ni control plane ni nodos unidos entre sí.
El proyecto se llama NVKE, sigla de NVIDIA Kubernetes Engine. Su propio repositorio en GitHub lo describe como una 'self-hosting factory for Kubernetes clusters': una fábrica que arma clusters completos, no un simple paquete de drivers para GPU.
TL;DR
- NVKE es el plano de administración en preview de NVIDIA para crear clusters de Kubernetes sobre GPU bare metal.- nvkectl levanta un cluster semilla temporal, forma el management cluster y desde ahí crea workload clusters independientes.- NICo es, en esta preview, el único proveedor de infraestructura compatible con NVKE.- Los nodos se autentican con SPIFFE/SPIRE y su TPM antes de recibir credenciales de unión al cluster.- GPU Operator instala drivers en un cluster existente; NVKE construye el cluster completo desde cero.
¿Qué es NVKE?
NVKE es la plataforma de NVIDIA para la gestión de GPUs en Kubernetes sobre infraestructura bare metal propia, sin depender de un proveedor cloud. Funciona como plano de administración: se instala una sola vez y desde ahí un equipo de plataforma crea y opera múltiples clusters de carga de trabajo independientes.
El proyecto vive en estado preview, lo que significa que NVIDIA no lo recomienda todavía para cargas de producción: sus APIs, su configuración y su comportamiento pueden cambiar entre versiones, así que cualquier evaluación conviene hacerla en un entorno descartable.
NVKE no es una distribución de Kubernetes ni una variante de Cluster API. Es, en palabras del propio proyecto, una fábrica de clusters que se autoalberga: un cluster semilla descartable levanta primero un management cluster, y ese management cluster después crea y opera, a demanda, tantos workload clusters como el equipo de plataforma necesite.
NVKE sigue en estado preview: NVIDIA todavía no lo recomienda para cargas de producción.
Por qué importa la gestión de GPUs en Kubernetes bare metal
Comprar o alquilar GPU por fuera de una nube pública obliga a resolver un problema que las nubes dan gratis: convertir un galpón de servidores en varios clusters de Kubernetes aislados, cada uno con su propio control plane, sin que el equipo de infraestructura tenga que armar esa automatización a mano.
Eso es justo lo que ataca NVKE. Un operador de infraestructura instala el management plane una sola vez sobre su parque de máquinas GPU, y desde ahí cada cliente interno, cada proyecto de investigación o cada equipo de machine learning recibe su propio workload cluster, con su propio etcd, en minutos y no en semanas de tickets contra el equipo de datacenter.
La gestión de GPUs en Kubernetes bare metal importa en particular para universidades, laboratorios y empresas que ya compraron el hardware GPU y no quieren pagar el margen de una nube pública solo para obtener la capa de orquestación encima.
Cómo funciona NVKE por dentro
Una instalación de NVKE tiene dos tipos de cluster de Kubernetes. El management cluster corre el plano de administración y los controladores de infraestructura; nvkectl lo forma usando un cluster semilla temporal, y instalar los servicios del management plane es un paso separado. Los workload clusters, en cambio, corren las aplicaciones de cada cliente y se crean y operan a través de NICo, Cluster API y un agente de nodo.
flowchart TD A["Cluster semilla temporal"] --> B["Management cluster NVKE"] B --> C["NICo: Infra Controller"] C --> D(("Nodos bare metal")) B --> E["Workload cluster 1"] B --> F["Workload cluster 2"] subgraph "Clusters de carga de trabajo" E F end El cluster semilla y el management cluster
El cluster semilla existe solo para arrancar: una vez que el management cluster queda en pie, el semilla se descarta. A partir de ahí, el equipo de plataforma instala sobre el management cluster los servicios que exponen la API de NVKE y la CLI nvkectl, que es el punto de entrada para pedir nuevos clusters.
Los workload clusters y sus node pools
Cada workload cluster se solicita por la API de NVKE o por nvkectl; NVKE provisiona las máquinas a través de NICo y forma el cluster con su propio control plane. Después, el mismo plano permite crear, escalar y borrar node pools, además de actualizar la versión de Kubernetes y reemplazar nodos, aunque en esta preview esas operaciones tienen límites manuales documentados en el repositorio del proyecto.
NICo, el único proveedor de infraestructura compatible
NICo, el NVIDIA Infra Controller, es por ahora el único proveedor de infraestructura compatible con NVKE. Es la pieza que traduce las peticiones de NVKE en máquinas físicas reales: sin NICo no hay dónde provisionar nada.
Identidad de nodos con SPIFFE/SPIRE
Antes de unirse a un cluster, cada nodo se autentica a través de SPIFFE/SPIRE usando su TPM, y solo después recibe las credenciales de unión. El cifrado de los datos de etcd está disponible por cluster, como opción que cada workload cluster puede activar por separado.
sequenceDiagram participant N as Nodo bare metal participant T as TPM del nodo participant S as SPIFFE/SPIRE participant M as Management plane NVKE N->>T: solicita evidencia de hardware T-->>N: entrega certificado de atestacion N->>S: presenta evidencia TPM S-->>M: valida identidad del nodo M-->>N: entrega credenciales de join Note over N,M: el nodo se une al workload cluster NICo es, por ahora, el único proveedor de infraestructura compatible con NVKE.
Ejemplos prácticos y cómo empezar
El repositorio de NVKE incluye un quickstart local que no necesita cuenta de NVIDIA ni hardware GPU real: corre sobre máquinas simuladas. Antes de tocar nada, confirmá que tu entorno cumple estos requisitos:
- Sistema operativo, host o VM Linux, arquitectura amd64 o arm64.- CPU y memoria, al menos 6 CPUs y 12 GiB de memoria libre.- Disco, al menos 100 GiB de espacio libre.- Docker, instalado y corriendo.- TPM virtual, soporte de TPM virtual disponible en el host.
En macOS no se usa Docker Desktop directo: la guía oficial corre la evaluación dentro de una VM Colima. En Windows no hay soporte nativo documentado; lo más directo es levantar una VM Linux (o WSL2 con Docker) y seguir los mismos pasos que en Linux.
Para explorar el código antes de instalar nada:
git clone https://github.com/dsx-ai-factory/nvke.git cd nvke ls cli management-engine cluster-api-provider-provisioned Este comando descarga el repositorio completo y lista tres carpetas que son parte real de su estructura: cli (el código de nvkectl), management-engine (el plano de administración) y cluster-api-provider-provisioned (el proveedor que arma los workload clusters). La salida esperada es, literalmente, esos tres nombres de carpeta.
Para la instalación completa paso a paso, con los comandos exactos del quickstart (que cambian entre previews), seguí la guía oficial enlazada desde el propio README del proyecto en lugar de copiar comandos de un tercero.
Una vez que el quickstart termina de crear un workload cluster de prueba, el propio instructivo pide confirmar que sus nodos están listos:
kubectl get nodes Salida esperada en la columna STATUS: Ready para todos los nodos. Si alguno queda en NotReady, el quickstart oficial documenta ese paso como bloqueante antes de seguir con el resto de la evaluación.
💡 Tip: corré el quickstart local primero en una VM descartable. Si algo sale mal, la destruís y empezás de nuevo sin arriesgar ninguna máquina real.
Casos de uso reales
- Laboratorios de IA con GPU propia, necesitan repartir esa capacidad en clusters aislados por proyecto sin pagar el margen de una nube pública.- Proveedores de GPU como servicio, pueden ofrecer Kubernetes administrado a sus clientes sin construir su propio proveedor de Cluster API desde cero.- Equipos de plataforma internos, dan de alta un cluster de prueba para un equipo de machine learning en minutos en vez de escalar un ticket al equipo de datacenter.
Errores comunes y buenas prácticas
El error más probable en esta preview es confundir 'funciona' con 'está listo para producción'. NVKE deja varios huecos documentados que hay que cubrir a mano antes de admitir tráfico real.
⚠️ Ojo: en esta preview, la autenticación del API de NVKE viene apagada y el tráfico corre en HTTP plano después de instalar. Configurarla es un paso manual obligatorio antes de admitir cualquier llamada externa.
Tampoco existe todavía un procedimiento de actualización, escalado o reemplazo automático para el propio management cluster, ni una rutina de backup o restore para él. Si ese cluster se cae, la recuperación depende por completo de lo que el equipo de plataforma haya planificado por su cuenta.
📌 Nota: las imágenes de nodo con cifrado de disco completo (FDE) que ofrece NVKE en esta preview son solo para evaluación: no dan confidencialidad real de datos en reposo.
Por último, conviene no mezclar las responsabilidades de NVKE y de su proyecto hermano, NVKR (NVIDIA Kubernetes Recipes). NVKR construye las imágenes de nodo y los componentes de NVKE a partir de insumos fijados (pinned inputs) y guarda la evidencia de esa construcción; NVKE solo despliega esos artefactos. Mezclar ambos roles complica saber, meses después, qué versión exacta corre en cada nodo.
NVKE frente a NVIDIA GPU Operator
NVKE y NVIDIA GPU Operator suenan parecidos pero resuelven capas distintas del mismo problema.
AspectoNVKENVIDIA GPU OperatorQué resuelveProvisiona y opera clusters completos de Kubernetes sobre bare metalInstala y mantiene el software GPU dentro de un cluster que ya existeNivel de la pilaPlano de administración que crea otros clustersConjunto de operators y CRDs dentro de un clusterQué entregaNodos, control plane, etcd y node pools vía NICoDriver NVIDIA, container toolkit, device plugin, exporter DCGMMulti-tenenciaSí, múltiples workload clusters independientesNo directamente, gestiona GPU dentro de un solo clusterEstadoPreview, no recomendado para producciónProducto GA, usado en producción
Nada impide, en teoría, correr GPU Operator dentro de un workload cluster creado por NVKE para administrar drivers a nivel de pod. La documentación del proyecto, sin embargo, todavía no confirma esa combinación como camino soportado, así que conviene tratarla como una hipótesis a probar, no como un hecho establecido.
Profundizando: identidad de nodos y el vínculo con NVKR
La atestación por TPM antes de entregar credenciales de join no es un detalle cosmético: evita que una máquina clonada o manipulada se haga pasar por un nodo legítimo del cluster. SPIFFE/SPIRE le da a cada nodo una identidad criptográfica verificable, independiente de su dirección IP o su nombre de host, algo especialmente útil cuando los nodos son máquinas físicas que se pueden reemplazar o mover.
flowchart LR R["NVKR: inputs fijados"] --> I["Imagenes de nodo y componentes NVKE"] I --> D["NVKE management plane"] D --> W(("Workload clusters")) Esa separación entre NVKR, que construye, y NVKE, que despliega, es la misma lógica que separar CI de CD en un pipeline de software tradicional: quien compila y firma el artefacto no es quien decide, en cada instalación, dónde correrlo. Aun así, en una preview sin procedimiento de backup para el management plane, esa separación no alcanza para garantizar continuidad si el management cluster se pierde.
📖 Resumen en Telegram: Ver resumen
Tu próximo paso: cloná el repositorio, corré el quickstart local sobre una VM descartable con Docker y TPM virtual, y confirmá con kubectl get nodes que el workload cluster de prueba queda en Ready.
Preguntas frecuentes
¿NVKE reemplaza a NVIDIA GPU Operator?
No. NVKE provisiona y opera clusters completos de Kubernetes sobre bare metal; GPU Operator instala y mantiene el software GPU dentro de un cluster que ya existe. Son capas distintas de la misma pila.
¿Se puede usar NVKE en producción hoy?
NVIDIA lo marca explícitamente como preview: sus APIs y su comportamiento pueden cambiar, y no lo recomienda para cargas de producción todavía.
¿Qué proveedores de infraestructura soporta NVKE?
En esta preview, NICo (NVIDIA Infra Controller) es el único proveedor de infraestructura compatible.
¿Qué hace nvkectl dentro de NVKE?
Es la CLI que arma el management cluster usando un cluster semilla temporal y que después se usa para pedir, escalar y borrar workload clusters.
¿NVKE corre en macOS o Windows?
El quickstart local oficial corre en Linux de forma nativa; en macOS se ejecuta dentro de una VM Colima. Windows no tiene soporte nativo documentado, así que conviene usar una VM Linux o WSL2 con Docker.
Referencias
- GitHub: dsx-ai-factory/nvke: repositorio oficial de NVKE, con su documentación de arquitectura, quickstart y limitaciones conocidas.- GitHub: NVIDIA/gpu-operator: repositorio oficial de NVIDIA GPU Operator, usado aquí como referencia de comparación.- SPIFFE: sitio oficial del proyecto SPIFFE/SPIRE para identidad de cargas de trabajo y nodos.- Cluster API (Kubernetes SIGs): documentación oficial del proyecto que NVKE usa para operar los workload clusters.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
