3 min read

Probes no Kubernetes: Como Garantir a Saúde e Disponibilidade das Aplicações com Liveness, Readiness e Startup Checks

Probes no Kubernetes: Como Garantir a Saúde e Disponibilidade das Aplicações com Liveness, Readiness e Startup Checks

Visão geral

No Kubernetes, as probes são responsáveis por monitorar a saúde dos containers e pods. Elas permitem que apenas pods saudáveis recebam tráfego, que o cluster recupere falhas automaticamente e que o balanceamento e as estratégias de atualização funcionem de forma previsível.

Neste texto você encontrará:

  • Os três tipos de probes – liveness, readiness e startup – e como cada um afeta o rollout e a disponibilidade.
  • Padrões recomendados para endpoints de saúde.
  • Dicas práticas para configurar probes de forma robusta.

1. Tipos de Probes

Liveness Probe

  • Objetivo: Detectar se o container está “vivo”.
  • Quando falha, o kubelet reinicia o container, assumindo que ele travou ou entrou em estado inconsistente.
  • Ideal para capturar deadlocks, crashes silenciosos e loops infinitos.

Exemplo (HTTP):

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15   # espera antes da primeira verificação
  periodSeconds: 20         # intervalo entre verificações
  failureThreshold: 3       # número de falhas consecutivas antes de reiniciar

Readiness Probe

  • Objetivo: Indicar se o container está pronto para atender requisições.
  • Se falhar, o pod é removido das listas de endpoints dos Services, evitando que tráfego seja enviado a ele.
  • Crucial durante a inicialização ou em operações temporárias (por exemplo, migração de banco).

Exemplo (TCP):

readinessProbe:
  tcpSocket:
    port: 3306
  initialDelaySeconds: 10
  periodSeconds: 15

Startup Probe

  • Objetivo: Dar ao container tempo suficiente para iniciar quando o boot é longo.
  • Enquanto a startup probe não chega a sucesso, as probes de liveness e readiness ficam suspensas.
  • Se a startup probe falhar, o container é reiniciado.

Exemplo (exec):

startupProbe:
  exec:
    command: ["cat", "/tmp/startup-success"]
  failureThreshold: 30   # permite até 30 tentativas falhas
  periodSeconds: 10

2. Impacto no Rollout, Balanceamento e Disponibilidade

Probe Influência no Balanceamento Influência no Rollout Consequência de Má Configuração
Readiness Determina se o pod aparece nos endpoints do Service. O Deployment só considera o pod “pronto” quando a readiness está OK. Pod pode ser excluído do tráfego prematuramente → perda de capacidade.
Liveness Não afeta diretamente o Service, mas garante que pods travados sejam reiniciados. Não interfere no rollout, mas reinicializações frequentes podem atrasar a convergência. Reinícios em loop → alta churn e instabilidade.
Startup Suspende readiness/liveness até que o container esteja pronto. Evita que o rollout avance antes do container estar completamente inicializado. Falha prematura → reinício constante; falha tardia → rollout mais lento.

Recomendações de configuração

  • initialDelaySeconds – ajuste de acordo com o tempo de boot da aplicação.
  • periodSeconds e failureThreshold – balanceie rapidez de detecção com tolerância a picos transitórios.
  • Use códigos HTTP 200 para indicar saúde; evite lógica pesada nos endpoints.
  • Teste os endpoints localmente (por exemplo, curl http://localhost:8080/healthz) antes de aplicar no cluster.

3. Padrões de Endpoints de Saúde

Probe Endpoint Típico Comentário
Liveness /healthz ou /live Verifica dependências internas (DB, cache) e estado geral.
Readiness /ready ou /readyz Garante que todas as dependências externas estejam disponíveis.
Startup /startup (menos comum) Indica que o processo de boot terminou com sucesso.

Boas práticas:

  • Responda em ≤ 100 ms para não atrasar o ciclo de verificação.
  • Não inclua checks que possam bloquear (ex.: consultas longas ao banco).
  • Diferencie claramente a lógica de liveness (“está vivo?”) da de readiness (“pode atender tráfego?”).

4. Manifesto de Pod com Todas as Probes

apiVersion: v1
kind: Pod
metadata:
  name: exemplo-pod
spec:
  containers:
  - name: app-container
    image: minha-aplicacao:latest
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20
      failureThreshold: 3
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    startupProbe:
      httpGet:
        path: /startup
        port: 8080
      periodSeconds: 10
      failureThreshold: 30

5. Dicas para Configuração Eficiente

  1. Comece conservador: use delays maiores que o tempo máximo esperado de inicialização e reduza gradualmente.
  2. Monitore métricas de probe: o kube‑apiserver expõe contadores (kubelet_running_pods, container_last_terminated_reason) que ajudam a identificar falhas frequentes.
  3. Teste em staging: simule falhas (por exemplo, bloqueie a conexão ao DB) e verifique se a readiness reage como esperado.
  4. Combine probes: use startup para evitar reinícios prematuros, liveness para recuperação automática e readiness para controle de tráfego.

Resumo rápido

Probe Função Principal Impacto Principal Endpoint Típico
Liveness Detecta se o container está vivo Reinicia containers travados /healthz ou /live
Readiness Indica disponibilidade para tráfego Controla balanceamento de serviços /ready ou /readyz
Startup Gerencia inicialização longa Suspende liveness/readiness até o boot concluir /startup (opcional)

Conclusão

Configurar probes adequadamente é essencial para a confiabilidade de aplicações no Kubernetes. Elas permitem detectar falhas rapidamente, evitar downtime inesperado e garantir que os rollouts ocorram de forma controlada. Ajuste os parâmetros de delay e threshold ao perfil da sua aplicação e valide tudo em ambientes de teste antes de levar à produção.

No próximo artigo, abordaremos estratégias avançadas de autoscaling e gerenciamento de recursos no Kubernetes.

Geisler