O que são liveness, readiness e startup probes, e quando você usa cada uma?

Question

IT Interview Practice · Accepted Answer

Probes permitem que o kubelet verifique a saúde de um container e aja com base no resultado. Há três: **liveness** (está vivo, ou deve ser reiniciado?), **readiness** (está pronto para receber tráfego?) e **startup** (já terminou de inicializar?). Cada uma responde a uma pergunta diferente.

## As três probes num relance

```text
LIVENESS   → "O app está travado/deadlocked?"   FALHA → o kubelet REINICIA o container
READINESS  → "Pode servir tráfego agora?"        FALHA → o Pod é removido dos endpoints
                                                          do Service (NÃO reiniciado)
STARTUP    → "O boot lento já terminou?"          roda PRIMEIRO; enquanto roda, liveness &
                                                   readiness ficam suspensas
```

## Readiness vs liveness — a distinção-chave

```text
Readiness controla o TRÁFEGO:
  → um Pod que falha no readiness é RETIRADO do load-balancer do Service,
    mas continua rodando (ex.: está aquecendo um cache ou uma dependência caiu)
Liveness controla a VIDA:
  → um Pod que falha no liveness é MORTO e reiniciado (está quebrado sem recuperação)
Usar liveness onde você queria readiness causa loops de restart desnecessários.
```

## Definições de probe

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      ports: [{ containerPort: 8080 }]

startupProbe:            # dá tempo a quem inicia devagar antes que as outras entrem
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = até 5 min para iniciar
        periodSeconds: 10

readinessProbe:          # controla o tráfego
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # reinicia se não estiver saudável
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Mecanismos de probe

```text
httpGet    → GET num path; 2xx/3xx = passa       (mais comum para web apps)
tcpSocket  → conseguimos abrir uma conexão TCP?   (para serviços não-HTTP)
exec       → roda um comando; exit 0 = passa      (verificações customizadas)
grpc       → health check gRPC nativo
Botões-chave: initialDelaySeconds, periodSeconds, timeoutSeconds,
              failureThreshold, successThreshold.
```

## Por que existem startup probes

```text
Apps de início lento (JVM warmup, migrations grandes) antes forçavam você a definir um
initialDelaySeconds enorme na liveness — o que tornava crashes reais lentos de detectar.
A startupProbe resolve isso: ela protege o boot lento, e SOMENTE depois de passar é que
liveness/readiness começam com seus tempos (apertados) normais.
```

```bash
kubectl describe pod app     # ver falhas de probe & motivos de restart nos eventos
kubectl get pod app          # a coluna READY reflete readiness; RESTARTS reflete liveness
```

## Por que isso importa

Health probes são como o Kubernetes entrega self-healing e roteamento de tráfego seguro, então entender os três tipos e quando usar cada um é conhecimento essencial de confiabilidade. A distinção crucial — uma que pega muitos engenheiros de surpresa — é entre **readiness** e **liveness**: readiness controla o **tráfego** (um Pod que falha é retirado do load-balancer do Service mas continua rodando, ideal quando está aquecendo ou uma dependência está temporariamente fora), enquanto liveness controla a **vida** (um Pod que falha é morto e reiniciado, para quando está em deadlock sem recuperação). Confundir as duas — usar uma liveness probe onde readiness era o que se queria — causa loops de restart desnecessários e indisponibilidades, então saber qual pergunta cada probe responde é diretamente prático. A **startup** probe resolve uma dor histórica real: apps de boot lento antes forçavam um `initialDelaySeconds` enorme na liveness (o que atrasava a detecção de crashes genuínos), ao passo que uma startup probe protege a janela de boot e deixa liveness/readiness rodarem com tempos apertados e normais somente depois que o startup tem sucesso. Entender os mecanismos de probe (`httpGet`, `tcpSocket`, `exec`, `grpc`) e os botões de ajuste (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, etc.) permite configurar o health checking corretamente em vez de no chute. Como as probes determinam diretamente se os usuários atingem Pods saudáveis e se Pods quebrados se recuperam automaticamente, acertá-las é fundamental para rodar workloads confiáveis e de nível de produção no Kubernetes.

As três probes num relance

Readiness vs liveness — a distinção-chave

Definições de probe

Mecanismos de probe

Por que existem startup probes

Por que isso importa

Perguntas relacionadas