Kubernetes v1.36: Agendamento Atômico de PodGroups e APIs Desacopladas Revolucionam Cargas de IA

O Kubernetes v1.36 quebra o paradigma do agendamento pod-a-pod ao introduzir grupos atômicos, topologia consciente e APIs desacopladas que prometem acabar com deadlocks em cargas de IA e treinamento distribuído. O que muda na prática e como sua infraestrutura pode se preparar para essa nova era.

O gargalo que o scheduler tradicional nunca resolveu

Treinar um modelo de linguagem ou rodar inferência em escala exige que dezenas (ou milhares) de Pods sejam iniciados no mesmo instante, em nós específicos, com GPUs compartilhadas e latência mínima entre eles. Até a v1.35, o Kubernetes tratava cada Pod como uma ilha — sem visão do grupo como uma unidade lógica.

O resultado: deadlocks frequentes. Parte do grupo era agendada, o restante ficava esperando, recursos ociosos, jobs parados. Para equipes de ML em produção, isso significava desperdício de dinheiro e complexidade operacional desnecessária.

A v1.36 enfrenta esse problema de frente, separando definitivamente o template da execução e introduzindo uma nova abstração: o PodGroup.

Workload + PodGroup: a separação que muda tudo

A reforma começa nas APIs scheduling.k8s.io/v1alpha2:

• Workload: agora é apenas um template estático que descreve como os Pods devem ser criados. Nada de estado runtime.
• PodGroup: a nova entidade que representa o estado runtime de um grupo de Pods — membresia, status de agendamento, recursos alocados.

Essa separação permite sharding de status (o scheduler distribui o monitoramento entre múltiplos workers) e desacopla a lógica de criação (controllers) da lógica de agendamento (scheduler). O resultado: escalabilidade muito maior para clusters com milhares de grupos simultâneos.

A v1.36 ainda está em alpha. São necessários múltiplos feature gates habilitados e não há garantia de estabilidade ou retrocompatibilidade.

Ciclo de agendamento atômico: gang scheduling sem deadlocks

O novo ciclo opera de forma radicalmente diferente:

1. Snapshot único: o scheduler tira uma foto do estado atual do cluster.
2. Avaliação do grupo inteiro: verifica se todos os Pods do PodGroup podem ser alocados simultaneamente.
3. Decisão binária: ou todos os Pods são bindingados, ou nenhum. Não há alocações parciais.

“O scheduler só toma uma decisão quando tem certeza de que o grupo inteiro cabe no cluster.”

Isso elimina os deadlocks. Para cargas de treinamento distribuído, onde cada Pod depende dos outros para começar a execução, essa atomicidade é essencial.

Três novas capacidades que transformam a infraestrutura de IA

1. Topology-Aware Scheduling

Duas novas extensões — PlacementGenerate e PlacementScore — permitem definir restrições de co-localização baseadas em topologia. Exemplo: “todos os Pods desse PodGroup devem ficar no mesmo rack ou cluster de GPU”.

Isso reduz a latência de comunicação entre Pods, algo crítico para paralelismo de dados ou modelo. Agora é possível especificar “coloque todos os Pods desse job dentro de uma única zona de disponibilidade”.

2. Workload-Aware Preemption

O PodGroup passa a ser tratado como unidade de preempção. A nova API inclui:

• Prioridade própria do PodGroup (independente das prioridades individuais dos Pods).
• disruptionMode: define se a preempção deve ser all-or-nothing (grupo inteiro) ou Pod a Pod.

Isso impede que um Pod prioritário seja removido enquanto seus companheiros permanecem, causando inconsistência. Para cargas de IA/ML, onde a perda de um Pod pode invalidar um checkpoint inteiro, essa proteção é vital.

3. DRA ResourceClaim para PodGroups

O Dynamic Resource Allocation (DRA) ganha uma capacidade crucial: um ResourceClaim gerado no nível do PodGroup pode ser compartilhado entre todos os Pods do grupo. Isso resolve o gargalo anterior de 256 referências a dispositivos.

Agora, um grupo de 1000 Pods pode referenciar o mesmo ResourceClaim, permitindo compartilhar GPUs ou aceleradores de maneira escalável. Para treinamento de modelos massivos, isso é um divisor de águas.

Integração nativa com o Job Controller

O Job controller do Kubernetes foi atualizado para criar automaticamente um Workload e um PodGroup para Jobs que atendam a dois critérios:

• completionMode: Indexed
• parallelism == completions

Isso significa que qualquer Job tradicional com pods paralelos e índices pode se beneficiar das novas capacidades de agendamento com zero alteração no YAML do Job. Para workloads existentes como PyTorchJob ou TFJob, essa integração permite uma migração suave para o novo modelo.

Implicações de mercado: Kubernetes se consolida como plataforma nativa de IA

Essa evolução arquitetural fortalece o Kubernetes como plataforma de primeira classe para cargas de IA/ML e batch. Grandes provedores de cloud e operadores de clusters agora têm um caminho nativo para:

• Agendamento atômico de jobs distribuídos.
• Co-localização topológica para redução de latência.
• Compartilhamento escalável de GPUs/TPUs entre pods de um grupo.
• Preempção inteligente que respeita a integridade do grupo.

A expectativa é que soluções externas (como Volcano, Koordinator) vejam pressão para se integrar ou perder relevância, já que o core Kubernetes agora oferece capacidades equivalentes.

Riscos e limitações: alpha com restrições claras

É importante destacar que tudo isso está em alpha na v1.36. O algoritmo atual de agendamento PodGroup funciona apenas para grupos homogêneos — todos os Pods iguais, sem dependências entre si. Grupos heterogêneos ou com afinidades podem falhar.

Outras limitações:

• Topology-aware scheduling não suporta preempção nem múltiplos níveis de topologia (ex: rack + zona) na v1.36.
• Integração com Job controller é restrita a Jobs com completionMode: Indexed e parallelism == completions.
• A API de PodGroup ainda não permite minCount mutável — não é possível redimensionar dinamicamente o tamanho mínimo de um grupo.

Visão Metatron

O Kubernetes v1.36 não é apenas uma release — é um marco arquitetural. A separação entre template e runtime no agendamento, combinada com o suporte a grupos atômicos e topologia consciente, posiciona a plataforma para atender as demandas de cargas de IA/ML que crescem exponencialmente.

Olhando para o roadmap da v1.37, que promete APIs Beta, hierarquias multi-nível e uma API de integração unificada para controllers, fica claro que o Kubernetes está se transformando em um orquestrador verdadeiramente inteligente.

Para equipes de infraestrutura que lidam com treinamento distribuído, inferência em larga escala ou batch crítico, este é o momento de planejar a migração. As bases estão lançadas – e o futuro do agendamento no Kubernetes será, sem dúvida, atômico, topológico e preparado para IA.

Resumo prático

• Separação Workload + PodGroup: desacopla template de runtime, melhora escalabilidade.
• Agendamento atômico: elimina deadlocks em cargas distribuídas.
• Topologia consciente: reduz latência entre Pods de treinamento.
• Preempção por grupo: protege checkpoints e consistência.
• DRA compartilhado: escalável para milhares de GPUs/TPUs.
• Integração automática com Jobs Indexados: migração sem alteração de YAML.

Quer se preparar para essa nova era? A Metatron acompanha a evolução do Kubernetes de perto. Entre em contato para discutir como adaptar sua infraestrutura de IA/ML às capacidades da v1.36 e além.