O Kubernetes foi desenhado para distribuir containers que competem por CPU e memória. Por mais de uma década, esse modelo funcionou. Mas GPUs mudaram a equação. Um cluster que roda inferência de LLM ou treinamento distribuído não se comporta como um serviço web stateless, e o ferramental do Kubernetes precisou evoluir para acompanhar.

Em menos de dois anos, três frentes se moveram ao mesmo tempo: o DRA (Dynamic Resource Allocation) chegou a GA, o cold start de containers pesados ganhou soluções concretas, e as métricas tradicionais de monitoramento perderam relevância para quem opera GPUs. Com o fim de vida do K8s 1.32 marcado para 28 de fevereiro de 2026, o momento de entender essas mudanças é agora.

O problema dos device plugins

Antes do DRA, a forma padrão de expor GPUs para o Kubernetes era via device plugins. O modelo era simples: o plugin registrava um recurso (como nvidia.com/gpu) e o scheduler tratava cada GPU como uma unidade opaca — sem informações sobre modelo, memória VRAM, interconexões NVLink ou perfis de particionamento MIG.

Isso funcionava quando GPU era exceção. Com workloads de IA se tornando o caso de uso dominante em muitos clusters, as limitações ficaram difíceis de ignorar:

  • Sem particionamento: não era possível dividir uma A100 em fatias MIG via scheduling nativo
  • Sem topologia: o scheduler não sabia quais GPUs compartilhavam o mesmo barramento PCIe
  • Sem paralelismo: a alocação era serial, com o driver sendo consultado pod a pod
  • Sem semântica declarativa: o pod pedia nvidia.com/gpu: 1 e torcia para receber hardware compatível

O resultado era subutilização. Clusters com GPUs ociosas enquanto workloads esperavam na fila, porque o scheduler não tinha informação suficiente para tomar decisões melhores.

DRA: alocação dinâmica que entende GPUs

O DRA resolve esses problemas com uma abordagem inspirada no modelo de PersistentVolumes. Em vez de tratar GPUs como contadores opacos, o DRA trabalha com dois objetos centrais:

  • ResourceSlice: publicado pelo driver de cada nó, descreve os dispositivos disponíveis com atributos estruturados: modelo, memória, perfis de particionamento, barramento PCIe, capacidades específicas
  • ResourceClaim: criado pelo workload, declara o que precisa usando expressões CEL que filtram dispositivos por atributos reais

Na prática, um pod pode pedir "uma GPU com pelo menos 40 GB de VRAM e suporte a MIG 3g.20gb" e o scheduler encontra o match correto sem interação com o driver em tempo de scheduling. A alocação fica registrada diretamente no status do ResourceClaim, o que permite ao scheduler processar múltiplos pods em paralelo, algo impossível com device plugins.

O DRA atingiu GA no Kubernetes 1.34, lançado em agosto de 2025. Na versão 1.35 (dezembro de 2025), o feature gate ficou permanente, sem possibilidade de desativação. Duas capacidades novas também entraram em maturação:

  • Extended resource requests: permitem que init containers reutilizem dispositivos alocados ao pod, evitando alocação dupla durante a inicialização
  • Consumable capacity: permite que múltiplos ResourceClaims de pods diferentes compartilhem o mesmo dispositivo físico via políticas de compartilhamento definidas pelo administrador

Para quem ainda usa device plugins, a migração não precisa ser imediata. Os dois modelos coexistem. Mas novos drivers da NVIDIA e AMD já publicam ResourceSlices nativamente, e as capacidades de particionamento MIG só estão disponíveis via DRA.

Cold start de containers de IA: o gargalo invisível

Subir um container que serve um modelo de 70 bilhões de parâmetros não é como subir um nginx. O cold start de workloads de IA envolve etapas que o Kubernetes tradicional não otimiza:

  1. Pull da imagem (que pode ter dezenas de gigabytes)
  2. Download dos pesos do modelo a partir de object storage
  3. Carregamento dos pesos na VRAM da GPU
  4. Warm-up de inferência (a primeira predição costuma ser mais lenta)

Cada etapa adiciona latência. Em cenários de autoscaling, onde novos pods precisam subir sob demanda, cold starts de minutos são inaceitáveis.

A Red Hat endereçou esse problema no OpenShift com o LADF (Local Accelerated Data Fetching). O mecanismo se integra ao sistema de admission checks do Kueue e garante que os dados estejam disponíveis antes do pod ser criado:

  1. O LADF intercepta o workload antes da admissão
  2. Verifica se o conteúdo do object storage remoto já está em cache no cluster GPFS local
  3. Se não estiver, o controlador STARM gera um CVO (Custom Volume Object) e dispara o download via AFM (Advanced File Management)
  4. O pod só é criado após a validação de que os dados estão prontos

Benchmarks publicados pela comunidade cloud-native indicam redução de até 40% na latência de carregamento de dados em cenários de treinamento distribuído. Na prática, o autoscaler passa a responder a picos de demanda sem que os novos pods gastem minutos baixando modelos do zero.

Outra frente de otimização vem do próprio OpenShift 4.20, com melhorias em SR-IOV para networking de alta performance. Benchmarks da Red Hat mostraram que SR-IOV alcança 98,6% da largura de banda teórica máxima, contra 81-89% do OVN-Kubernetes padrão. A diferença pesa em treinamento distribuído, onde a comunicação entre nós é intensiva.

Kueue: scheduling justo para GPUs compartilhadas

O scheduler padrão do Kubernetes aloca recursos no momento da criação do pod. Para GPUs, isso gera um problema: se 10 jobs de treinamento competem por 4 GPUs, os primeiros 4 jobs alocam tudo e os outros 6 ficam em pending indefinidamente, sem garantia de fairness.

O Kueue adiciona uma camada de enfileiramento nativa ao Kubernetes. Workloads entram em filas e são admitidos quando os recursos estão disponíveis, respeitando:

Cada equipe recebe uma cota de GPUs garantida. Quando um time está ocioso, outros podem usar temporariamente esses recursos, com devolução automática (quota borrowing). Workloads de treinamento distribuído são admitidos atomicamente: ou todos os pods sobem, ou nenhum (gang scheduling). Jobs de alta prioridade podem desalocar os de menor prioridade quando necessário (preemption).

O modelo de cohorts agrupa filas que compartilham o mesmo pool de recursos. Cada equipe mantém sua fila isolada, mas recursos não usados fluem para quem precisa. Um equilíbrio entre controle organizacional e eficiência de hardware que device plugins nunca ofereceram.

Em produção, implementações com Kueue reportam redução significativa no tempo ocioso de GPUs em clusters de treinamento. GPUs que antes ficavam reservadas mas sem uso passam a ser redistribuídas automaticamente.

Monitoramento pós-CPU: as métricas que importam

Os quatro golden signals do Google SRE (latência, tráfego, erros, saturação) continuam relevantes, mas para clusters de IA eles contam apenas parte da história. CPU utilization deixa de ser o sinal dominante quando o gargalo real está nos Tensor Cores.

O NVIDIA DCGM (Data Center GPU Manager) expõe métricas de GPU via Prometheus que todo cluster com aceleradores deveria estar monitorando:

  • DCGM_FI_PROF_SM_ACTIVE: percentual de ciclos em que os Streaming Multiprocessors têm pelo menos um warp ativo
  • DCGM_FI_PROF_PIPE_TENSOR_ACTIVE: percentual de ciclos em que o pipe de Tensor Cores está em uso
  • DCGM_FI_DEV_GPU_UTIL: utilização geral da GPU
  • DCGM_FI_DEV_FB_USED: memória de framebuffer consumida

A interpretação exige contexto. Uma GPU com 95% de SM_ACTIVE durante treinamento é normal — significa que o hardware está sendo bem aproveitado. A mesma GPU com 95% durante inferência pode indicar batch size excessivo ou modelo sem otimização.

O DCGM Exporter se instala via Helm chart e exporta essas métricas por padrão. Integrado com Grafana, permite cruzar métricas de GPU com sinais do Kubernetes (pod restarts, queue depth do Kueue, eventos de HPA) para ter visibilidade real do que acontece no cluster.

Benchmarks de 2026 mostram que autoscaling baseado em métricas de GPU via KEDA + DCGM reduz significativamente o tempo ocioso de GPUs comparado com autoscaling que usa apenas CPU como sinal.

K8s 1.32 morre em 28 de fevereiro

O Kubernetes 1.32 atinge o fim de vida em 28 de fevereiro de 2026. A última release da série é a 1.32.12, publicada em 10 de fevereiro. Após essa data, nenhum patch de segurança ou correção de bug será publicado para a branch 1.32.

Para quem opera clusters de IA, o upgrade vai além de manutenção de segurança. Cada versão trouxe funcionalidades que impactam diretamente workloads de GPU:

  • 1.32 para 1.33: DRA em beta com melhorias de UX, driver-owned resource claim status
  • 1.33 para 1.34: DRA graduando para GA, 23 features estabilizadas
  • 1.34 para 1.35: feature gate do DRA permanente (sempre ativo), consumable capacity, extended resource requests

O caminho recomendado é upgrade incremental: 1.32 para 1.33, depois 1.34. Não pule versões. E teste DRA em staging antes de habilitar em produção, já que drivers de GPU precisam ser compatíveis com a versão do cluster.

Conclusão

O Kubernetes de 2026 não é o Kubernetes de 2020. DRA em GA, Kueue em produção, LADF para cold start, DCGM para observabilidade. O stack inteiro mudou. Quem opera clusters com uso intensivo de GPUs ainda dependendo de device plugins, scheduling padrão e dashboards de CPU está operando sem visibilidade do que realmente importa.

O EOL do 1.32 é um bom momento para repensar a infraestrutura. Pegar patches de segurança é o mínimo. O ganho real está em adotar DRA e ter controle sobre o hardware que mais custa no cluster.

Referências pesquisadas nesta publicação