Liveness probe failed

O que significa

A liveness probe é a pergunta que o kubelet faz periodicamente ao container: você ainda está funcionando? Quando a resposta falha failureThreshold vezes seguidas, o kubelet mata o container e o reinicia conforme a restartPolicy. Os padrões da API são: periodSeconds 10, timeoutSeconds 1, failureThreshold 3 e initialDelaySeconds 0 (referência da API do Kubernetes, objeto Probe).

Com os padrões, um container que para de responder é reiniciado em cerca de 30 s. Com uma probe errada, um container saudável também.

Achado ao reproduzir: o kubelet encerra o container com SIGTERM, e o exit code registrado depende de como o processo reage. O nginx do teste tratou o sinal e saiu limpo, com Exit Code: 0 e motivo Completed. Um processo que morre pelo próprio SIGTERM registra 143. Não use o exit code para decidir se foi a probe: use os eventos.

Causas comuns

Diagnóstico em 3 comandos

Saídas reais de um nginx de teste com a liveness apontando para /healthz, caminho que o nginx padrão não serve.

1 · reinícios subindo, container "Running"

kubectl -n loja get pod busca

NAME    READY   STATUS    RESTARTS      AGE
busca   1/1     Running   4 (38s ago)   109s

2 · a probe, o último término e os eventos

kubectl -n loja describe pod busca

    Last State:     Terminated
      Reason:       Completed
      Exit Code:    0
    Restart Count:  5
    Liveness:       http-get http://:80/healthz delay=5s timeout=1s period=5s #success=1 #failure=3
Events:
  Warning  BackOff    47s (x2 over 47s)   kubelet  Back-off restarting failed container busca in pod busca_loja(...)
  Normal   Killing    7s (x5 over 92s)    kubelet  Container busca failed liveness probe, will be restarted
  Warning  Unhealthy  2s (x16 over 102s)  kubelet  Liveness probe failed: HTTP probe failed with statuscode: 404

O statuscode: 404 fecha o diagnóstico: a aplicação responde, só não naquele caminho. connection refused apontaria porta errada ou processo que ainda não abriu a porta; context deadline exceeded, lentidão.

3 · teste o endpoint de dentro do pod

kubectl -n loja exec busca -- wget -qO- -S http://127.0.0.1:80/healthz

A correção

1. Aponte a probe para um endpoint que existe e que responde rápido, sem consultar banco nem API externa.
2. Para aplicação que demora a subir, use startupProbe: enquanto ela não passa, a liveness não roda. É a forma indicada pela documentação para proteger containers lentos na subida.
3. Dê margem de timeout ao endpoint sob carga, em vez de afrouxar o failureThreshold ao ponto de a probe não servir.

containers:
  - name: busca
    startupProbe:
      httpGet: { path: /saude, port: 80 }
      periodSeconds: 5
      failureThreshold: 24
    livenessProbe:
      httpGet: { path: /saude, port: 80 }
      periodSeconds: 10
      timeoutSeconds: 3
      failureThreshold: 3

No exemplo, a startup dá até 120 s para a subida (24 × 5 s); depois disso, a liveness assume com a cadência normal.

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.