Kubernetes 1.37 acaba com o resize de pod travado em estado Deferred

• Preemption presa ao nó. Diferente da preemption de colocação, que varre o cluster inteiro atrás do melhor encaixe, aqui a busca por "vítimas" é restrita ao nó onde o pod deferido já roda. Se, mesmo despejando todos os pods elegíveis de baixa prioridade daquele nó, ainda faltar capacidade, o resize continua Deferred. Não há migração para outro nó.
• Reserva de recurso. Para evitar corrida e dupla alocação, o scheduler trata o recurso pedido no resize como já consumido, o que dá ao Kubelet a garantia de executar assim que a preemption libera espaço.
• Separação de responsabilidades. O Kubelet tem um critical Pod admission handler que, na admissão, pode despejar pods localmente para garantir carga crítica. Com a feature gate ligada, esse handler não faz mais preemption local para operações de resize: ele defere e delega a decisão inteiramente ao scheduler. Um único orquestrador centralizado passa a mandar em toda a lógica de preemption de resize, respeitando prioridades globais, Pod Disruption Budgets e terminação graciosa.
• Corridas entre resizes. Se, durante um ciclo ativo de preemption, chega um pedido de resize de prioridade ainda maior para outro pod do mesmo nó, o Kubelet prioriza esse pedido e o scheduler dispara uma nova rodada de preemption se precisar de mais capacidade.

Há também um freio no nível do nó. Um novo campo spec.podPreemptionPolicy no Node permite desligar a preemption de resize para nós específicos:

apiVersion: v1
kind: Node
metadata:
  name: batch-workload-node
spec:
  podPreemptionPolicy:
    disableResizePreemption:
    - "cluster-autoscaler.kubernetes.io/disable-preemption"
    - "operator.example.com/policy-override"

O caso de uso citado no blog é o de um controlador que prefere reduzir outros pods ou ajustar a capacidade do nó por conta própria, deixando a preemption do scheduler como último recurso. Faz sentido: despejar carga é a solução mais barata em latência, mas a mais violenta em disrupção. Ter o botão para desligá-la em nós de batch é o tipo de trade-off explícito que evita surpresa.

Vendo funcionar num kind local

A fonte traz um mini-tutorial reproduzível num cluster kind de nó único com CPU limitada. O gate liga na criação do cluster:

# kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
featureGates:
  InPlacePodVerticalScalingSchedulerPreemption: true

kind create cluster --config kind-config.yaml --image kindest/node:v1.37.0

O nó de exemplo expõe 8 CPUs alocáveis. O roteiro cria duas PriorityClass (high-priority com valor 1000000 e low-priority com 1000), sobe um pod de baixa prioridade pedindo 3 CPUs e um de alta pedindo 4, consumindo 7 das 8 CPUs e deixando 1 de folga. Aí vem o teste: um patch sobe o requests/limits do pod de alta de 4 para 6 CPUs, um delta de +2 que não cabe na folga de 1.

kubectl patch pod high-priority-pod --subresource resize --patch \
 '{"spec":{"containers":[{"name":"app", "resources":{"requests":{"cpu":"6"}, "limits":{"cpu":"6"}}}]}}'

O ciclo de eventos conta a história inteira. No pod de baixa prioridade aparece um Preempted seguido de Killing. No de alta, a sequência ResizeDeferred (com o erro OutOfcpu: Node didn't have enough resource: cpu, requested: 6000, used: 3950, capacity: 8000), depois ResizeStarted quando a capacidade é liberada e, por fim, ResizeCompleted. A confirmação:

kubectl get pod high-priority-pod -o jsonpath='{.status.containerStatuses[0].allocatedResources.cpu}{"\n"}'
# 6

O container passou de 4 para 6 CPUs atualizando os limites de cgroup via container runtime, sem reiniciar. Esse é o ponto: o ResizeCompleted sem RESTARTS incrementado é o que separa esse recurso de um reagendamento comum.

O que muda para quem opera cluster no Brasil

Na prática, a leitura é que dá para empurrar o bin-packing mais longe com menos medo. Preencher a folga dos nós com batch, processamento em background e tarefas best-effort deixa de ser uma aposta contra o pico da carga crítica, porque o scheduler agora tem como reabrir espaço quando essa carga precisa crescer. Para quem paga a conta de nós ociosos só para manter buffer (e no câmbio de cloud isso pesa), a promessa é utilização mais alta sem sacrificar a resposta das aplicações sensíveis.

Dito isso, é alpha, e alpha não vai para produção. A feature gate precisa estar ligada em kube-apiserver, kube-scheduler e kubelet, control plane e todos os workers em v1.37 ou superior. Vale entender bem o comportamento antes de confiar: como a preemption é presa ao nó, um resize pode continuar Deferred mesmo com o cluster tendo espaço em outro lugar, e é preciso ter certeza de que os PDBs e as prioridades estão configurados de forma que a carga despejada seja mesmo descartável. A régua continua a mesma: se não dá para medir o efeito da preemption e reverter o comportamento (pelo spec.podPreemptionPolicy), não vai para o cluster que importa. O caminho sensato é o que o próprio SIG Scheduling pede: ligar em ambiente de teste, observar os eventos e dar feedback antes de qualquer plano de produção.

Fonte: Kubernetes Blog