Readiness probe failed

O que significa

A readiness probe responde se o container pode receber tráfego agora. Enquanto ela falha, o pod é marcado como não pronto e sai da lista de destinos dos Services que o selecionam. Diferente da liveness, nada é reiniciado: o container segue rodando, e volta a receber tráfego quando a probe passa. Os padrões são os mesmos da liveness: periodSeconds 10, timeoutSeconds 1, failureThreshold 3 (referência da API do Kubernetes, objeto Probe).

O sintoma para quem usa o serviço é outro: erro 503 no Ingress, ou conexão recusada no Service, porque não sobrou nenhum pod pronto atrás dele.

Causas comuns

Diagnóstico em 3 comandos

Saídas reais de um nginx de teste com a readiness apontando para /pronto, caminho que não existe.

1 · rodando, mas 0/1

kubectl -n loja get pod checkout

NAME       READY   STATUS    RESTARTS   AGE
checkout   0/1     Running   0          109s

2 · os eventos

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

Events:
  Warning  Unhealthy  108s                kubelet  Readiness probe failed: Get "http://10.42.0.9:80/pronto":
                                                   dial tcp 10.42.0.9:80: connect: connection refused
  Warning  Unhealthy  4s (x22 over 107s)  kubelet  Readiness probe failed: HTTP probe failed with statuscode: 404

O primeiro evento, connection refused, é do segundo inicial em que o nginx ainda não tinha aberto a porta. Os seguintes, 404, são a causa de verdade.

3 · o Service tem para onde mandar?

kubectl -n loja get endpointslices -l kubernetes.io/service-name=checkout \
  -o jsonpath='{range .items[*].endpoints[*]}{.addresses[0]} ready={.conditions.ready}{"\n"}{end}'

10.42.0.9 ready=false

O pod aparece no EndpointSlice, mas com ready=false: está registrado e não recebe tráfego. O comando antigo, kubectl get endpoints, ainda funciona, mas no Kubernetes 1.35 ele avisa que a API está obsoleta desde a 1.33 e manda usar EndpointSlice:

kubectl -n loja get endpoints checkout

Warning: v1 Endpoints is deprecated in v1.33+; use discovery.k8s.io/v1 EndpointSlice
NAME       ENDPOINTS   AGE
checkout               2m11s

A correção

1. Teste o endpoint da probe de dentro do pod (kubectl exec) e aponte a probe para um caminho que exista.
2. Decida o que a prontidão deve checar. Se o pod consegue responder algo útil sem a dependência, deixe a dependência fora da readiness.
3. Num rollout, a readiness é o que impede o tráfego de chegar a uma versão quebrada. Probe que sempre passa tira essa proteção.

readinessProbe:
  httpGet: { path: /saude, port: 80 }
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 3

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.