NodeWright de NVIDIA el gestor de paquetes Kubernetes que tu flota de GPUs necesitaba

¡Hola Devs! El dolor oculto de gestionar nodos GPU

Kubernetes es una maravilla para orquestar workloads, pero administrar los nodos por debajo—especialmente los de GPU—sigue siendo ese trabajo manual que nadie quiere hacer. Parámetros de kernel, paquetes del sistema, layouts de storage, agentes de seguridad y tuning de host tienen que estar consistentes en cientos de máquinas. La mayoría de los equipos lo resuelven con playbooks de Ansible, scripts a medida y ventanas de mantenimiento a las 3 de la mañana.

Con GPU la cosa se complica más. No puedes simplemente tirar un nodo GPU y levantar otro—el hardware es escaso, los reemplazos tardan horas y los jobs de entrenamiento largos no se pueden reprogramar así nomás. La pregunta real no es cómo cambiar un nodo, sino cómo cambiarlos todos sin matar el entrenamiento.

Ahí entra NodeWright, la respuesta open-source de NVIDIA a este problema. Corría internamente como Skyhook y ahora está disponible públicamente como parte de la plataforma DSX OS. Es un gestor de paquetes nativo de Kubernetes para infraestructura de host—piensa en un apt o yum, pero consciente del cluster, de los disruption budgets y capaz de hacer rollouts progresivos en toda la flota.

Este contenido está basado en el blog oficial de ingeniería de NVIDIA. Para ver el material original, checa el anuncio oficial de NodeWright.

Vamos a ver cómo funciona NodeWright por dentro

NodeWright tiene tres componentes principales: un operator, custom resources y packages.

• El operator es un controller de Kubernetes que vigila los custom resources de NodeWright y gestiona el ciclo de vida de los cambios en los nodos.
• Los packages son imágenes de contenedor que llevan las modificaciones reales—scripts, configuraciones, binarios—más scripts de verificación que detienen el rollout cuando algo sale mal.
• Los custom resources definen qué aplicar, dónde y con qué agresividad.

Fíjate en este ejemplo mínimo de custom resource apuntando a nodos GPU:

apiVersion: nodewright.nvidia.com/v1alpha1
kind: NodeWright
metadata:
  name: gpu-node-tuning
spec:
  nodeSelectors:
    matchLabels:
      nodepool: gpu
  interruptionBudget:
    percent: 33
  podNonInterruptLabels:
    matchLabels:
      workload: long-running-training
  packages:
    nvidia-tuned:
      version: 0.9.0
      image: ghcr.io/nvidia/nodewright-packages/nvidia-tuned

Cuando aplicas este recurso, el operator orquesta una secuencia cuidadosa en cada nodo objetivo:

1. Cordon — marca el nodo como no agendable.
2. Wait — deja que los workloads críticos terminen con calma (tú declaras qué pods nunca se pueden interrumpir vía labels).
3. Drain — expulsa los pods restantes respetando PodDisruptionBudgets.
4. Apply and configure — ejecuta el package: toca parámetros de kernel, instala agentes, configura servicios.
5. Interrupt — reinicia un servicio o el nodo si hace falta.
6. Uncordon — devuelve el nodo al cluster, listo para workloads.

Esa secuencia es la diferencia entre perder la mitad de un entrenamiento por un update de kernel y aplicar el mismo update en toda la flota sin dolor.

Rollouts progresivos a escala

Empujar un cambio a un nodo es pan comido. Empujarlo a mil nodos GPU corriendo entrenamiento en producción es otra historia. El recurso DeploymentPolicy de NodeWright ofrece tres estrategias de rollout progresivo:

Cada estrategia incluye un batch threshold (porcentaje mínimo de éxito antes de avanzar) y un failure threshold opcional (detiene el compartimento si fallan muchos lotes seguidos). Tú defines el riesgo; NodeWright lo ejecuta.

Limitaciones y cuidados

• No reemplaza al GPU Operator ni al Network Operator. NodeWright gestiona la capa de SO del host por debajo de ellos—no confundas los alcances.
• Operaciones con root requieren RBAC bien hecho. Los packages ejecutan operaciones privilegiadas, así que admission controllers y RBAC granular son obligatorios en producción.
• El ecosistema de packages sigue creciendo. NVIDIA cubre Hopper/Blackwell y las clouds principales (EKS, GKE), pero combos de hardware/cloud más nicho pueden requerir packages a medida.
• Necesitas disciplina GitOps. Si tu equipo aún no usa Argo CD, Flux o Helm, la curva de aprendizaje es real.

Herramientas compañeras del ecosistema

• NVCRE (NVIDIA Cluster Readiness Engine): validación antes del workload.
• NVSentinel: monitoreo de fallas en runtime y self-healing.
• AICR (AI Cluster Runtime): recetas versionadas para drivers, operators y kernels.

¿Vale la pena adoptar NodeWright?

Si corres clusters de Kubernetes con GPU a cualquier escala relevante, NodeWright resuelve un dolor operativo real. Trae el mismo enfoque declarativo y GitOps-friendly que ya usas para workloads hasta la capa de host—se acabaron las sesiones SSH a las 3 de la mañana y las hojas de cálculo controlando ventanas de mantenimiento.

Para empezar es sencillo:

helm install nodewright oci://ghcr.io/nvidia/nodewright/charts/nodewright \
  --namespace nodewright \
  --create-namespace

Después solo defines un custom resource de NodeWright, apuntas a los nodos por label y dejas que el operator haga el resto.

Próximos pasos en tu aprendizaje

1. Mapea los dolores actuales de config de host. ¿Qué sigue siendo manual? Esos son tus primeros candidatos a NodeWright.
2. Empieza con un nodo canario. Usa la estrategia Fixed con lote 1 para validar antes de escalar.
3. Explora el repositorio de packages. NVIDIA publica paquetes de tuning para Hopper/Blackwell y bootstraps específicos de cloud (EKS con EFA, GKE con COS).
4. Integra con recetas AICR si quieres configuraciones versionadas y reproducibles.

NodeWright es Apache 2.0 y forma parte del portafolio DSX OS. Adopta un proyecto, integra varios o compón todo en una plataforma—el valor está en las interfaces abiertas y la adopción independiente.

Lee también:

• Cómo Santander redujo el provisioning de infra de 90 días a horas
• Grok Build 0.1 en Vercel AI Gateway: una nueva era para la codificación agéntica