Kubernetes probes: liveness, readiness e startup (sem mistério)

Se seu rollout derruba tráfego, ou seu pod entra em restart loop, tem uma boa chance do problema estar em probe.

A ideia é simples:

• readinessProbe decide se o pod pode receber tráfego
• livenessProbe decide se o container deve ser reiniciado
• startupProbe dá tempo de boot para apps lentas sem matar o pod antes da hora

Quando usar cada uma

readinessProbe (tráfego)

Use quando:

• seu app precisa de alguns segundos pra ficar pronto
• você tem dependência externa (DB, cache, migrations) e quer segurar tráfego

Se ela falhar:

• o pod continua vivo
• mas sai do load balancer do Service

livenessProbe (reinício)

Use quando:

• você quer reiniciar o container se ele travar/deadlock
• você quer “self-healing” básico

Se ela falhar:

• o kubelet reinicia o container

startupProbe (boot lento)

Use quando:

• sua aplicação demora pra subir (Java, apps com warmup/cache)
• você colocou livenessProbe e começou a tomar restart antes do boot terminar

Ela é basicamente um “período de graça”.

Erros comuns (que eu vejo direto)

• Usar liveness pra tudo e causar restart loop (quando era só readiness)
• Probe muito agressiva (timeout pequeno, failureThreshold baixo)
• Endpoint de probe caro (faz query pesada no DB e piora tudo)

Checklist rápido pra debugar

kubectl describe pod -n <ns> <pod>
kubectl get events -n <ns> --sort-by=.lastTimestamp | tail -n 30
kubectl logs -n <ns> <pod> -c <container> --tail=200

Procure por:

• Readiness probe failed
• Liveness probe failed
• Back-off restarting failed container

Exemplo (HTTP probes)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: nginx:1.27
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /health
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 5
            timeoutSeconds: 2
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: /health
              port: 80
            initialDelaySeconds: 30
            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3
          startupProbe:
            httpGet:
              path: /health
              port: 80
            periodSeconds: 5
            failureThreshold: 30

Leitura prática desse YAML:

• readiness começa cedo (pra segurar tráfego até estar ok)
• liveness começa mais tarde (pra não matar o container em boot)
• startup dá até ~150s de boot (30 * 5s)

Dica final

Se você está em dúvida, separe responsabilidade:

• readiness = “posso receber tráfego?”
• liveness = “tô travado e preciso reiniciar?”

E evita inventar probe que faz query no banco.

Se você quiser conectar com estratégia de rollout/rollback, dá uma olhada neste post: Estratégias de deployment em produção: blue-green, canary e rolling updates.

Simples assim! :)