NodeWright da NVIDIA o gerenciador de pacotes Kubernetes que sua frota de GPUs estava pedindo

O drama silencioso do gerenciamento de nodes GPU

O Kubernetes é show de bola pra orquestrar workloads, mas gerenciar os nodes por baixo—especialmente os de GPU—ainda é aquele trabalho manual que ninguém quer fazer. Parâmetros de kernel, pacotes de sistema, layout de storage, agentes de segurança e tuning de host precisam estar consistentes em centenas de máquinas. A maioria dos times resolve isso com playbooks Ansible, scripts customizados e janelas de manutenção às 3 da manhã.

Com GPU a coisa fica mais complicada. Você não pode simplesmente descartar um node GPU e subir outro no lugar—hardware é escasso, reposição demora horas e jobs de treinamento longos não podem ser remarcados do nada. A pergunta real não é como mudar um node, mas como mudar todos eles sem matar o treinamento.

É aí que entra o NodeWright, a resposta open-source da NVIDIA pra esse problema. Rodava internamente como Skyhook e agora está disponível publicamente como parte da plataforma DSX OS. É um gerenciador de pacotes nativo do Kubernetes pra infraestrutura de host—pensa num apt ou yum, mas ciente do cluster, dos disruption budgets e capaz de fazer rollout progressivo na frota inteira.

Esse conteúdo é baseado no blog oficial de engenharia da NVIDIA. Pra conferir o material original, dá uma olhada no anúncio oficial do NodeWright.

Como o NodeWright funciona por dentro

O NodeWright tem três componentes principais: um operator, custom resources e packages.

• O operator é um controller do Kubernetes que observa os custom resources do NodeWright e gerencia o ciclo de vida das mudanças nos nodes.
• Os packages são imagens de container que carregam as modificações de verdade—scripts, configurações, binários—além de scripts de verificação que param o rollout quando algo dá errado.
• Os custom resources definem o que aplicar, onde e com qual agressividade.

Olha só um exemplo mínimo de custom resource apontando pra nodes 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

Quando você aplica esse recurso, o operator orquestra uma sequência cuidadosa em cada node alvo:

1. Cordon — marca o node como não agendável.
2. Wait — deixa os workloads críticos terminarem com calma (você declara quais pods nunca podem ser interrompidos via labels).
3. Drain — expulsa os pods restantes respeitando PodDisruptionBudgets.
4. Apply and configure — executa o package: mexe em parâmetros de kernel, instala agentes, configura serviços.
5. Interrupt — reinicia um serviço ou o node se precisar.
6. Uncordon — devolve o node ao cluster, pronto pra workloads.

Essa sequência é a diferença entre perder metade de um treinamento por causa de um update de kernel e aplicar o mesmo update na frota inteira sem dor de cabeça.

Rollouts progressivos em escala

Empurrar uma mudança pra um node é moleza. Empurrar pra mil nodes GPU rodando treinamento em produção é outra história. O recurso DeploymentPolicy do NodeWright oferece três estratégias de rollout progressivo:

Cada estratégia tem um batch threshold (percentual mínimo de sucesso antes de avançar) e um failure threshold opcional (para o compartimento se muitos lotes consecutivos falharem). Você define o risco; o NodeWright executa.

Limitações e cuidados

• Não substitui o GPU Operator nem o Network Operator. O NodeWright gerencia a camada de SO do host por baixo deles—não confunda os escopos.
• Operações com root exigem RBAC bem feito. Packages executam operações privilegiadas, então admission controllers e RBAC granular são obrigatórios em produção.
• Ecossistema de packages ainda crescendo. A NVIDIA cobre Hopper/Blackwell e as principais clouds (EKS, GKE), mas combos de hardware/cloud mais nichados podem exigir packages customizados.
• Precisa de disciplina GitOps. Se o time ainda não usa Argo CD, Flux ou Helm, a curva de aprendizado é real.

Ferramentas companheiras do ecossistema

• NVCRE (NVIDIA Cluster Readiness Engine): validação antes do workload.
• NVSentinel: monitoramento de falhas em runtime e self-healing.
• AICR (AI Cluster Runtime): receitas versionadas pra drivers, operators e kernels.

Vale a pena adotar o NodeWright?

Se você roda clusters Kubernetes com GPU em qualquer escala relevante, o NodeWright resolve uma dor operacional de verdade. Ele traz a mesma abordagem declarativa e GitOps-friendly que você já usa pros workloads pra camada de host—chega de sessões SSH às 3 da manhã e planilhas controlando janelas de manutenção.

Pra começar é tranquilo:

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

Depois é só definir um custom resource do NodeWright, apontar pros nodes via label e deixar o operator fazer o resto.

Próximos passos no seu aprendizado

1. Mapeie as dores atuais de config de host. O que ainda é manual? Esses são seus primeiros candidatos ao NodeWright.
2. Comece com um node canário. Usa a estratégia Fixed com lote 1 pra validar antes de escalar.
3. Explore o repositório de packages. A NVIDIA publica pacotes de tuning pra Hopper/Blackwell e bootstraps específicos de cloud (EKS com EFA, GKE com COS).
4. Integre com receitas AICR se quiser configurações versionadas e reproduzíveis.

O NodeWright é Apache 2.0 e faz parte do portfólio DSX OS. Adote um projeto, integre vários ou componha tudo numa plataforma—o valor tá nas interfaces abertas e na adoção independente.

Leia também:

• Como o Santander reduziu o provisionamento de infra de 90 dias pra horas
• Grok Build 0.1 no Vercel AI Gateway: uma nova era pra codificação agêntica