Como corrigir políticas de recursos do Kubernetes que otimizam para a fase errada

TL;DR

• Uma política de recursos do Kubernetes é cada camada que decide quais requests e limits um contêiner acaba recebendo: ResourceQuota, LimitRange, regras de admissão (Kyverno, Gatekeeper, ValidatingAdmissionPolicy), defaults de Helm charts e qualquer recomendador que escreva os números.
• Cada uma dessas camadas assume um único número por contêiner para toda a vida do contêiner. Contêineres têm duas fases, startup e steady state, e a diferença entre elas pode ser de 3x a 10x.
• Políticas ajustadas para o steady state estrangulam e matam pods por OOM durante o startup. Políticas ajustadas para o startup reservam capacidade que ninguém usa, enchem as quotas do namespace com requests ociosos e deixam pods em Pending enquanto o cluster fica meio vazio.
• A correção é estrutural: quota sobre requests, não sobre limits; LimitRange que permite burst em vez de travá-lo; regras de admissão que exigem requests e limits de memória, mas param de obrigar limits de CPU; e um recomendador que enxerga startup e steady state como números separados.
• O resize de pods in-place torna o último passo viável. O startup recebe o que precisa, depois o pod encolhe até seu patamar sem reiniciar, e a quota é recuperada no mesmo instante.

No último post, mostramos como enxergar um pico de startup: filtre as métricas de throttling e OOM pela idade do contêiner, e o burst que as médias escondem aparece nos primeiros 60 segundos de vida de cada contêiner. Este post é sobre o que fazer quando você já consegue vê-lo, porque a parte difícil não é editar um Deployment. É que a camada de políticas em volta desse Deployment foi escrita para uma fase e vai continuar empurrando cada workload de volta para ela.

Correção 4: dimensione a memória para o startup e a CPU para o steady state

Quando a camada de políticas para de forçar uma resposta única, a decisão por workload fica mais simples — e é diferente para cada recurso.

O limit de memória precisa cobrir o pico de startup. Não existe degradação gradual para memória. Se a inicialização aloca 900Mi e o limit é 768Mi, o contêiner morre com exit code 137 antes mesmo de chegar ao seu patamar de 400Mi. Pegue max_over_time(container_memory_working_set_bytes[5m]) em uma janela que inclua um rollout e defina o limit acima desse número, com margem. Para workloads JVM, lembre que o heap é só parte do quadro: metaspace, code cache e stacks de threads ficam fora do -Xmx.

O request de memória fica no patamar. O request é o que o scheduler reserva e o que a quota conta. Defini-lo no working set de steady state, com uma folga modesta, mantém o bin-packing honesto. A distância entre request e limit coloca o pod em QoS Burstable, o que significa que ele é candidato a eviction sob pressão de memória do nó antes dos pods Guaranteed. Para a maioria dos serviços stateless, é uma troca aceitável; nos casos em que não é, defina request igual a limit deliberadamente e aceite a reserva.

O request de CPU fica no patamar; o limit de CPU, ausente. Sem quota do CFS, o startup pega emprestados ciclos ociosos do nó e os devolve um minuto depois. O request ainda importa: é o que o Karpenter e o scheduler usam para posicionar o pod, e é o denominador que o HPA usa para calcular a utilização. Dimensione-o pelo p95 do steady state, não pelo burst.

O único lugar onde isso quebra é um rollout que coloca muitos pods com picos no mesmo nó recém-criado, todos de uma vez. Sem CPU ociosa para emprestar, o startup roda devagar por contenção, não por throttling. Limite o maxSurge para que os novos pods cheguem em ondas em vez de todos juntos, e considere uma topologySpreadConstraint em kubernetes.io/hostname para que os pods novos de um rollout não se empilhem em um nó só. Um startupProbe com failureThreshold dimensionado para o caso lento impede que o kubelet reinicie um pod que está apenas subindo sob carga.

Correção 5: deixe o recomendador enxergar duas fases e deixe o pod mudar de tamanho

Tudo que está acima impede a política de forçar o número errado. Mas não produz o certo. Para isso, o recomendador precisa saber que startup e steady state são diferentes, e o pod precisa poder se mover entre eles.

O Vertical Pod Autoscaler, com seu recomendador padrão, constrói um histograma com decaimento sobre aproximadamente oito dias de amostras. Um burst de 45 segundos é ruído para ele, então ele recomenda o patamar — e o próximo rollout sofre throttling. Você pode restringi-lo com minAllowed para que nunca caia abaixo de um piso que sobreviva ao boot, mas isso só regrava o número de startup como reserva permanente por outra porta.

O resize de pods in-place muda o formato do problema. Ele ficou estável no Kubernetes 1.35, vem habilitado por padrão no 1.36 e permite que os requests e limits de um contêiner em execução mudem sem restart. O padrão é: inicie o pod com CPU e memória suficientes para um boot limpo e, depois que ele reportar readiness, faça o resize para baixo, até os valores de steady state. O startup CPU boost do GKE faz uma versão disso no Autopilot. O spec do pod só precisa declarar que uma mudança de CPU não deve disparar restart:

containers:
- name: app
  resizePolicy:
  - resourceName: cpu
    restartPolicy: NotRequired
  - resourceName: memory
    restartPolicy: NotRequired   # ou RestartContainer se o runtime não conseguir encolher o heap ao vivo
  resources:
    requests:
      cpu: "2"          # valor de startup; redimensionado para ~200m após o readiness
      memory: 1Gi
    limits:
      memory: 1Gi

É aqui que o trabalho de quota da Correção 1 se paga. Um resize é verificado contra o ResourceQuota como qualquer outra mudança de request, então quando o pod encolhe de 2 núcleos para 200m, o namespace recupera 1,8 núcleo de quota imediatamente. Quarenta réplicas fazem o boot em ondas, cada uma segurando sua reserva de startup por cerca de um minuto, e a pegada de steady state do namespace se estabiliza em 8 núcleos em vez de 80. Pods param de ficar em Pending atrás de reservas que descrevem uma fase em que ninguém está.

Uma restrição para considerar no design: um resize não pode mudar a classe de QoS de um pod. Um pod que começou Burstable continua Burstable, e um pod Guaranteed tem que manter requests iguais a limits em todo resize. Mais um motivo para não exigir Guaranteed por política em workloads que não precisam disso.

Um checklist para reescrever a política

1. Faça o inventário das camadas. Para cada namespace: kubectl get resourcequota,limitrange -o yaml, mais toda regra de Kyverno/Gatekeeper/VAP que toque em resources. Anote o que cada uma impõe.
2. Descubra a fase que cada camada assume. Qualquer limits.cpu em uma quota, qualquer max.cpu ou maxLimitRequestRatio.cpu baixo em um LimitRange, qualquer regra de admissão do tipo "deve definir limit de CPU" é uma política de steady state. Qualquer defaultRequest acima de algumas centenas de millicores, ou qualquer exigência de requests iguais a limits, é uma política de startup.
3. Meça a distância. Rode a query de razão requests/uso por namespace. Qualquer coisa acima de 3 a 4 é quota consumida pela fase errada.
4. Mova a quota para os requests. Tire limits.cpu do ResourceQuota; mantenha requests.* e limits.memory.
5. Abra o LimitRange. Remova default.cpu, aumente ou remova max.cpu, aplique maxLimitRequestRatio só na memória.
6. Reescreva a admissão. Exija requests de CPU e memória e um limit de memória. Pare de exigir limit de CPU.
7. Redimensione os dez workloads que mais reiniciam. Limit de memória no pico de startup, requests de memória e CPU no p95 do steady state, sem limit de CPU. Adicione maxSurge e spread constraints se os rollouts disputarem recursos.
8. Habilite o dimensionamento em duas fases onde o cluster suportar. No 1.33+ com resize in-place disponível, declare resizePolicy e deixe um controller encolher os pods após o readiness.
9. Repita o passo 3 uma semana depois. A razão deve cair em direção a 1,5 a 2 e a taxa de throttling em contêineres jovens deve cair em direção a zero ao mesmo tempo. Se só uma delas se moveu, você corrigiu um recurso e não o outro.

FAQ

O que é um resource quota no Kubernetes? Um ResourceQuota é um objeto com escopo de namespace que limita o total de recursos que todos os pods daquele namespace podem solicitar ou ter como limit, além de contagens de objetos como pods, services e PVCs. Ele é aplicado na admissão: um pod cujos requests ou limits levariam o namespace acima dos valores hard é rejeitado. Quotas contam os números do spec do pod, não o uso real — por isso uma quota pode se esgotar enquanto os nós por trás dela ficam ociosos.

Um ResourceQuota deve limitar limits ou requests? Limite requests.cpu e requests.memory, porque requests são o que o scheduler reserva e o que você paga em capacidade de nó. Limite limits.memory também, já que é uma proteção real contra um namespace consumir toda a memória do nó. Evite limits.cpu em quotas: ele pressiona os times a encolher os limits de CPU para caber, o que estrangula pods durante o startup sem proteger o nó.

Qual é a diferença entre ResourceQuota e LimitRange? ResourceQuota define um total para o namespace inteiro. LimitRange define defaults, mínimos, máximos e a razão permitida entre limit e request por contêiner (ou por pod, ou por PVC). A quota responde "quanto esse time pode usar no total"; o LimitRange responde "o que um contêiner recebe se não disser nada, e qual o máximo que ele pode pedir". Ambos são aplicados na admissão.

Resizes in-place de pods entram na conta do ResourceQuota? Sim. Um resize que aumenta os requests é validado contra a quota do namespace e rejeitado se for excedê-la. Um resize que reduz os requests devolve a diferença à quota imediatamente. É isso que permite que um padrão de startup-depois-encolher mantenha a pegada de quota de steady state de um namespace próxima do uso real.

Por que meus pods sofrem throttling no startup mesmo com CPU ociosa no nó? Porque um limit de CPU é aplicado pela quota do CFS do kernel por contêiner, independentemente da carga do nó. Se o limit é 500m, o contêiner recebe 50ms de cada período de 100ms, não importa quão ocioso o nó esteja. O trabalho de startup, como compilação JIT ou carregamento de módulos, esgota essa quota no início de cada período e espera. Remover o limit de CPU, ou aumentar o maxLimitRequestRatio para que o limit fique bem acima do request, permite que o startup use a capacidade ociosa.

Políticas que refletem como os contêineres realmente se comportam

Tudo que está acima pode ser feito à mão: reescreva a quota, abra o LimitRange, atualize a política de admissão, redimensione os workloads mais barulhentos, repita quando o código mudar. A parte difícil é justamente esse último item. Perfis de startup mudam a cada bump de dependência e a cada alteração de flag da JVM, e uma política que você ajustou corretamente em março já está errada de novo em junho.

O PerfectScale by DoiT traça o perfil de cada contêiner no nível do workload, então o comportamento de startup e de steady state aparece como padrões separados em vez de uma média misturada, e suas recomendações dimensionam a memória para cobrir o pico de boot mantendo os requests no patamar. Para workloads Java, ele detecta contêineres JVM automaticamente quando o agente Coroot está habilitado, acompanha heap, non-heap e GC ao longo do tempo, sinaliza contêineres rodando sem configurações explícitas de heap e respeita -Xms e -Xmx ao recomendar ou aplicar uma mudança. Em clusters com Kubernetes 1.33 ou superior, sua automação aplica right-sizing in-place sem reiniciar o pod, recorrendo a um rolling restart apenas quando um resize não é viável no nó atual — assim, a quota do namespace reflete o que os workloads estão usando agora, e não o que precisaram por 45 segundos depois do último deploy.

Quer ver um pod fazer boot com 2 núcleos e se estabilizar em 200m, sem restart e sem deixar quota presa? Participe do workshop sobre o pico de startup da JVM, ou agende uma sessão técnica e vamos analisar juntos as políticas de quota e LimitRange dos seus próprios clusters.