Throttling de CPU e OOM Kills no Kubernetes: encontre os picos de startup

TL;DR

• Um pico de startup é o burst de CPU e memória de que um container precisa durante a inicialização (carregamento de classes, compilação JIT, carregamento de dependências, aquecimento de caches, pools de conexão) e que desaparece quando o processo atinge o estado estável.
• Médias e até o p99 de uma semana escondem o pico. Um burst de 45 segundos dentro de uma janela de 7 dias representa menos de 0,01% das amostras, então qualquer recomendação baseada no uso misturado dimensiona o pod para a fase errada.
• O pico se manifesta como throttling de CPU, OOM kills com exit code 137, falhas de readiness probe e rollouts lentos, todos concentrados no primeiro minuto de vida do container — e depois desaparecem.
• Para detectá-lo, plote o uso em função da idade do container em vez do tempo de relógio, e filtre as métricas de throttling e OOM para containers jovens.
• Quando você consegue ver as duas fases separadamente, pode dimensionar para cada uma delas em vez de escolher qual incidente prefere.

Seu serviço roda bem. A CPU fica em 15% do limite, a memória em 60%, nenhum alerta. Aí um rollout substitui 40 pods, metade deles sofre throttling por 50 segundos, três levam OOM kill logo no primeiro boot, as readiness probes falham e o rollout trava. Dez minutos depois tudo parece saudável de novo e os dashboards não mostram nada fora do normal.

Isso é um pico de startup, e ele se esconde porque toda métrica que você usa para dimensionar workloads o dilui na média.

Um checklist de detecção para rodar esta semana

1. Escolha os workloads que mais reiniciam. Consulte increase(kube_pod_container_status_restarts_total[7d]) e ordene de forma decrescente. Picos de startup doem mais onde o startup acontece mais.
2. Verifique se o throttling depende da idade. Rode a consulta de throttling em containers jovens acima contra os mesmos workloads com mais de dez minutos. Uma diferença grande confirma o pico.
3. Verifique o padrão de OOM. Para qualquer workload com OOMKilled em last_terminated_reason, olhe o restarts_total. Contagens baixas concentradas logo após deploys significam OOM de startup.
4. Meça o tempo até o ready durante um rollout. Dispare um rollout em staging, registre o histograma de readiness, depois reduza o limite de CPU pela metade e rode de novo. O delta é o custo do seu pico em segundos.
5. Olhe os primeiros 300 segundos de um pod. Um painel do Grafana, um pod, uso versus limite. Se a linha se achata contra o limite, anote por quanto tempo.
6. Separe os dois números. Para cada workload com picos, registre o pico de startup e o p95 do estado estável. A razão entre eles mostra quanto você paga a mais ao dimensionar para o pico — e quanto throttling sofre ao dimensionar para o platô.

As correções que silenciosamente pioram tudo

Algumas respostas comuns escondem o sintoma em vez de resolvê-lo.

Adicionar um startupProbe com um failureThreshold generoso interrompe o loop de restarts, o que é a decisão certa para a confiabilidade, mas também interrompe o alerta. O pod continua inicializando sob throttling por 90 segundos e os usuários continuam esperando por ele; você só deixa de ver.

Aumentar o request de CPU para cobrir o pico corrige o throttling e perpetua o desperdício em cada réplica pelo resto da vida dela. Em um serviço com 40 réplicas, um pico de 2 cores e um platô de 200m, essa decisão reserva 72 cores que ficam ociosos 99,9% do tempo. Também prejudica o bin-packing, já que o scheduler aloca pods pelo request, e requests inflados significam menos pods por node e mais nodes do que você precisa.

Remover completamente os limites de CPU, o que o PerfectScale recomenda para a maioria dos workloads no guia de limites de CPU, permite que o startup use a capacidade ociosa do node em burst. Ajuda, e geralmente é o padrão certo. Mas só funciona quando o node tem CPU ociosa no momento em que o pod inicia. Durante um rollout, quando 20 pods novos caem no mesmo node recém-criado e todos começam a compilar ao mesmo tempo, não há CPU ociosa para absorver o burst. O pico volta como contenção em vez de throttling.

Cada uma dessas medidas é razoável por si só. O problema é que as três continuam tratando o container como um único número quando o uso dele tem dois formatos distintos.

Dimensionando para duas fases em vez de uma

O Kubernetes agora tem a primitiva que torna possível uma abordagem em duas fases. O resize in-place de pods, que permite alterar os requests e limits de um container em execução sem reiniciá-lo, ficou estável na versão 1.35 e vem habilitado por padrão na 1.36 (o PerfectScale testou a versão alpha lá em 2024, bugs e tudo mais). O GKE já o utiliza no recurso de startup CPU boost. O padrão é simples: dê ao pod o que ele precisa para inicializar e retire quando ele atingir o estado estável.

Isso só funciona se você conseguir distinguir as duas fases em primeiro lugar — e é para isso que serve tudo o que foi descrito acima.

FAQ

O que é throttling de CPU no Kubernetes? O throttling de CPU acontece quando um container tenta usar mais tempo de CPU do que seu limite permite dentro de um período de escalonamento do CFS (100ms por padrão). O kernel pausa o container até o início do próximo período. Um limite de 500m permite que um container rode por 50ms a cada 100ms; se gastar isso cedo demais, o container espera. O throttling desacelera a aplicação sem derrubá-la, e pode ocorrer mesmo quando o node tem CPU ociosa.

Por que meu pod leva OOM kill só no startup? A inicialização costuma alocar mais memória do que a operação em estado estável: carregamento de classes, construção de caches, execução de migrações ou dimensionamento do heap da JVM antes de a aplicação conhecer seu working set real. Se o limite de memória cobre o número do estado estável, mas não o pico de startup, o kernel mata o container durante o boot com exit code 137. Depois que sobrevive ao startup, o uso cai abaixo do limite e o pod roda normalmente — por isso o contador de restarts geralmente para em um ou dois.

Como diferencio um pico de startup de um problema de dimensionamento em estado estável? Filtre suas métricas de throttling e OOM pela idade do container. Se os problemas se concentram nos primeiros um ou dois minutos de vida do container e desaparecem depois, é um pico de startup. Se ocorrem em momentos aleatórios ao longo da vida do pod, o request ou o limite de estado estável está errado.

Remover limites de CPU corrige o throttling no startup? Remove a quota do CFS, então o container pode usar em burst qualquer CPU ociosa que o node tiver. Isso ajuda quando os nodes têm folga. Não ajuda durante um rollout, quando muitos pods iniciam no mesmo node simultaneamente, porque não há CPU ociosa para absorver o burst. O request continua determinando o escalonamento, então um request subdimensionado ainda pode concentrar pods demais com picos em um mesmo node.

Enxergando as duas fases de cada workload

Tudo o que foi descrito acima você pode construir à mão com Prometheus, kube-state-metrics e alguns painéis do Grafana. A parte difícil é fazer isso para 400 workloads e manter tudo atualizado conforme mudanças no código deslocam onde o pico acontece.

O PerfectScale by DoiT faz o profiling de cada container no nível do workload, de modo que o comportamento de startup e o de estado estável aparecem como padrões separados, e não como uma média misturada. Para workloads Java, ele vai uma camada mais fundo: com o agente Coroot habilitado, detecta containers JVM automaticamente e acompanha heap, non-heap e tempo de GC ao longo do tempo, sinaliza containers rodando sem configurações explícitas de heap e respeita -Xms e -Xmx ao fazer uma recomendação ou aplicar uma mudança. Em clusters rodando Kubernetes 1.33 ou superior, sua automação aplica right-sizing in-place, sem reiniciar o pod, e recorre a um rolling restart apenas quando um resize não é viável no node atual.

Quer ver o pico de startup sendo achatado ao vivo? Participe do workshop sobre o pico de startup da JVM, onde mostramos o que acontece dentro da JVM no boot e redimensionamos um pod em execução para o estado estável sem restart. Ou agende uma sessão técnica e a gente dá uma olhada nos seus clusters.