NVKE: NVIDIA presenta su versión de Kubernetes especializada para IA (todavía en preview)

Si estás montando una fábrica de IA y te toca ofrecer Kubernetes como servicio a tus clientes, probablemente ya sepas que construir un sistema de gestión de clústeres desde cero no es precisamente una tarde de viernes. NVIDIA lo sabe, y por eso lanzó NVIDIA Kubernetes Engine (NVKE), un sistema de gestión de Kubernetes open source que un operador de fábrica de IA instala para crear y operar clústeres en su propia infraestructura de GPUs NVIDIA.

Eso sí, ojo con la letra chica: NVKE está en estado preview. Las APIs, la configuración y el comportamiento pueden cambiar entre releases, y desde NVIDIA explícitamente no recomiendan usarlo para cargas de producción. Traducción: juega con él, experimenta, pero no le pongas encima el pipeline de inferencia de tus clientes que factura millones. La documentación oficial lista el estado de preview y limitaciones conocidas por si necesitas argumentos para convencer a tu jefe de esperar.

Qué es una fábrica de IA?

Qué es NVKE, en corto

NVKE es un sistema de gestión de Kubernetes que el operador de una AI factory instala para crear y correr clústeres para sus clientes. El operador solicita cada clúster a través de la API de NVKE, y NVKE se encarga de aprovisionar los nodos bare-metal, formar el clúster y manejar las operaciones del día a día: escalar node pools, actualizar Kubernetes, reemplazar nodos y renovar certificados.

NVKE trabaja de la mano con NVIDIA Kubernetes Recipes (NVKR), su sistema de build compañero, que construye las imágenes de OS de nodo y los componentes que NVKE despliega. Ambos están bajo licencia Apache 2.0 y aceptan contribuciones externas. Nada de lock-in propietario, al menos en el papel.

El ecosistema: NVKE, NVKR y compañía

NVKE no vive solo. Forma parte de un stack más grande, y cada pieza es un proyecto separado:

Cómo funciona NVKE por dentro

Una instalación de NVKE gestiona una flota de clústeres de workload dentro de una sola fábrica de IA. El flujo es más o menos así:

1. Arrancas un clúster de management en nodos que tú preparas.
2. nvkectl levanta un clúster semilla temporal, lo usa para formar el clúster de management con kubeadm, y lo borra cuando el bootstrap tiene éxito.
3. El clúster de management corre el plano de management de NVKE: la API y los controladores que operan clústeres, node pools y nodos.
4. Cuando creas un clúster de workload, el plano de management pide máquinas a tu proveedor de infraestructura (NICo) vía Cluster API.
5. NICo aprovisiona cada máquina desde tu imagen de OS de nodo, y el agente nvke-agent corre kubeadm e instala los componentes del clúster.
6. El cliente recibe un kubeconfig y usa kubectl contra el endpoint de la API de su clúster.

Los nodos pertenecen a node pools que comparten un tipo de instancia, un release y una versión de Kubernetes. Y ojo: cada clúster de workload tiene su propio plano de control, su propio etcd y sus propios node pools. Aislamiento de verdad, no de cartón.

El ciclo de vida: construir, arrancar, configurar y operar

Quién es responsable de qué

Esto es importante, porque en el mundo del managed Kubernetes la línea entre "lo que provee el software" y "lo que provee el operador" se difumina rápido. NVIDIA lo deja claro:

Lo que NVKE no hace

Para que no haya malentendidos:

• No gestiona bare metal. NICo descubre máquinas, actualiza firmware, configura redes y aprovisiona hosts. NVKE solo pide máquinas a NICo vía CAPNICo.
• No envía imágenes de OS ni binarios de Kubernetes. Tú los construyes, con NVKR o desde el repo de NVKE, y los alojas tú mismo.
• No corre las cargas de tus clientes. Tú operas el clúster, el cliente es dueño de lo que corre adentro.

Detalles técnicos que vale la pena destacar

• Builds verificables. NVKR construye cada artefacto desde fuentes fijas y registra un SBOM. Los releases del pipeline alojado están firmados y llevan build provenance, que puedes verificar contra tu propia política antes de que un artefacto llegue a un clúster.
• Identidad de nodo con TPM. En bare metal, cada nodo atestigua con su TPM vía SPIFFE/SPIRE antes de recibir una credencial de join. Además, hay encriptación de etcd en reposo por clúster.
• OVN-Kubernetes. Los clústeres usan un build curado por NVIDIA de OVN-Kubernetes, también open source.
• Telemetría con NKTP. El pipeline de telemetría de NVKE corre OpenTelemetry Collectors que recolectan métricas, logs y trazas y las exportan a tu backend vía OTLP. Se instala en el clúster de management y también corre en cualquier otro clúster de Kubernetes.
• Conformidad upstream. NVKE usa Kubernetes upstream, kubeadm y Cluster API. La CNCF certificó que NVKE crea clústeres conformes, y es una Certified Kubernetes AI Platform. Tus clientes no tendrán que reaprender nada, ni siquiera los malos hábitos de YAML.

Primeros pasos

• Probar sin hardware: Quickstart: evaluate locally with mock-NICo. Un solo Linux, sin GPUs. Ideal para ver si te convence antes de comprometer fierro.
• Construir tus primeros artefactos: Build and host node OS images.
• Instalar en tu hardware: Plan your installation.
• Revisar qué soporta el preview: Preview status and known limitations y Supported platforms and versions.

Referencias

• Documentación oficial de NVKE: https://docs.nvidia.com/nvke/
• Índice completo de documentación: https://docs.nvidia.com/nvke/llms.txt
• Repositorio de NVKR: https://github.com/dsx-ai-factory/nvkr
• NVIDIA AI Cluster Runtime (AICR): https://docs.nvidia.com/aicr
• CNCF Kubernetes conformance (NVKE): https://github.com/cncf/k8s-conformance/pull/4492
• CNCF Landscape — Certified Kubernetes AI Platform: https://github.com/cncf/landscape/pull/5236
• Estado de preview y limitaciones conocidas: https://docs.nvidia.com/nvke/documentation/overview/preview-status-and-known-limitations
• Plataformas y versiones soportadas: https://docs.nvidia.com/nvke/documentation/overview/supported-platforms-and-versions