Gang scheduling e posicionamento por topologia: o que o Kubernetes precisa para treinar IA distribuída

O problema central é de modelo: o kube-scheduler agenda pods um a um, sem coordenar entre eles. Treinamento distribuído de IA tem pods interdependentes. Eles precisam começar juntos e ficar em hardware com banda inter-GPU adequada. Se um requisito falha, o job trava ou roda bem abaixo do que o hardware entrega.

O texto da CNCF divide a solução em duas peças. O Kueue fica acima do kube-scheduler, controla quais jobs chegam a ele e quando, e aplica o TAS na admissão. Ele agrupa nodes em domínios (block, rack e host) a partir de labels como topology.kubernetes.io/rack, mas não descobre a topologia sozinho: alguém (admin ou labeler do provedor de nuvem) precisa aplicar essas labels antes. O Coscheduling usa o recurso PodGroup e segura cada pod em espera até que o gang inteiro possa ser vinculado ao mesmo tempo.

A validação passa por quatro camadas. Na fila de admissão, as métricas kueue_pending_workloads, kueue_admission_wait_time_seconds e kueue_evicted_workloads_total (com motivos como NodeFailures e PodsReadyTimeout). Na topologia, o campo status.admission.podSetAssignments[].topologyAssignment do Workload. No gang, spec.minMember e status.phase do PodGroup (Pending, Scheduling, Running, Unknown, Finished, Failed). Por fim, o throughput de treino, porque métricas de infraestrutura medem atividade, não produtividade, e uma GPU pode parecer saudável enquanto a comunicação cross-rack consome o passo.

A cobertura anterior mostra o tema amadurecendo dentro do próprio Kubernetes. Em 15 de maio de 2026, o CEVIU noticiou "Kubernetes v1.36: Avanços no Scheduling Inteligente de Workloads", que dividiu a API de Workload em um template estático e uma API PodGroup para estado em runtime. O texto de agora trata gang scheduling com o PodGroup do plugin Coscheduling e cita a evolução das capacidades nativas do scheduler, mas o trecho disponível não detalha essa relação. Em 21 de outubro de 2026, o CEVIU publicou "Cargas de IA estão forçando o autoscaling do Kubernetes a repensar a divisão entre scheduler e autoscaler", sobre pods pending mesmo com capacidade. A notícia atual olha o mesmo atrito pelo lado do posicionamento e da coordenação.

Para quem opera plataforma de GPU, isso significa que o custo do mau posicionamento não aparece no dashboard comum. Vale instrumentar a fila do Kueue, o estado dos PodGroups e a vazão de treino juntos, e garantir que as labels de topologia existam nos nodes. Sem isso, o job roda, a GPU fica ocupada e a conta sobe sem alarme.