OOMKilled

O que significa

Quando você define resources.limits.memory, o kubelet configura esse valor como teto no cgroup do container. Se o processo tentar usar mais do que isso, o kernel aciona o OOM killer e encerra o processo com SIGKILL, sinal 9. O container termina com exit code 137 (128 + 9) e o kubelet registra Reason: OOMKilled. Com a restartPolicy padrão (Always), o container é reiniciado; se estourar de novo, entra em CrashLoopBackOff. Fonte: documentação do Kubernetes, "Assign Memory Resources to Containers and Pods", seção "Exceed a Container's memory limit".

Um detalhe que confunde: o request de memória não protege contra OOMKilled. O request serve ao scheduler para escolher o nó; o limite é o que o kernel aplica. Um container com request 64Mi e limit 128Mi morre ao passar de 128Mi, e não de 64Mi. Sem limit definido, ele pode usar toda a memória livre do nó e, aí, quem age é a eviction por pressão no nó, que é outro erro (Evicted).

Causas comuns

Diagnóstico em 4 comandos

Saídas reais de um pod de teste que tenta alocar 150M com limite de 128Mi.

1 · o STATUS já diz, por alguns segundos

kubectl -n loja get pod checkout-oom

NAME           READY   STATUS      RESTARTS      AGE
checkout-oom   0/1     OOMKilled   3 (52s ago)   75s

Entre um reinício e outro o STATUS alterna com CrashLoopBackOff. O registro que não some é o do último término:

2 · confirme o motivo do último término

kubectl -n loja get pod checkout-oom \
  -o jsonpath='{.status.containerStatuses[0].lastState}' | jq .

{
  "terminated": {
    "exitCode": 137,
    "finishedAt": "2026-09-25T22:55:22Z",
    "reason": "OOMKilled",
    "startedAt": "2026-09-25T22:55:22Z"
  }
}

3 · veja o limite configurado e o histórico de reinícios

kubectl -n loja describe pod checkout-oom | grep -E -A4 "Last State|Limits|Requests|Restart Count"

    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
    Restart Count:  3
    Limits:
      cpu:     500m
      memory:  128Mi
    Requests:
      cpu:        100m
      memory:     64Mi

4 · os eventos não citam OOMKilled

kubectl -n loja describe pod checkout-oom | sed -n '/Events:/,$p'

  Normal   Started  29s (x4 over 70s)  kubelet  Container started
  Warning  BackOff  28s (x4 over 66s)  kubelet  Back-off restarting failed container checkout in pod checkout-oom_loja(...)

No nosso teste, os eventos do pod mostraram só BackOff: quem mata é o kernel, e o motivo fica no Last State. Filtrar eventos por "OOM" não encontra nada. Se aparecer Unhealthy seguido de Killing, é a liveness probe que também está reiniciando o container, e o último término pode trazer outro exit code (0 ou 143, conforme o processo trate o SIGTERM).

Para comparar com o uso real, kubectl top pod --containers mostra o consumo do instante (precisa do metrics-server); o pico está no seu Prometheus ou Grafana.

A correção

1. Pegue o pico de memória de um período representativo (no Prometheus: max_over_time(container_memory_working_set_bytes[7d]), filtrando pelo container).
2. Defina limits.memory acima do pico, com folga para crescimento. A documentação não prescreve um fator: escolha um e registre o motivo em comentário no manifesto.
3. Suba requests.memory para o uso típico. Se request = limit em CPU e memória para todos os containers, o pod é da classe Guaranteed, a última a ser despejada por pressão no nó (documentação do Kubernetes, "Pod Quality of Service Classes").
4. Faça o runtime caber no limite: JVM com -XX:MaxRAMPercentage, Node com --max-old-space-size, .NET com DOTNET_GCHeapHardLimitPercent.

containers:
  - name: checkout
    image: registry.loja.internal/checkout:2.14.0
    resources:
      requests:
        cpu: 250m
        memory: 640Mi
      limits:
        cpu: 500m
        memory: 800Mi
    env:
      - name: JAVA_TOOL_OPTIONS
        value: "-XX:MaxRAMPercentage=75.0"

avisoSubir o limite trata o sintoma. Se o pico cresce a cada semana, é vazamento de memória, e o próximo OOMKilled é questão de tempo. Compare o pico de uma semana com o de um mês.

Como aparece no Kubepier

O Kubepier mostra os eventos do pod com os avisos primeiro, com filtro por tipo, namespace e motivo. O diagnóstico por IA explica o erro a partir dos eventos e do log, em português, com a sua chave de API (Anthropic ou OpenAI). Abaixo, uma ilustração com dados fictícios.