Cluster instável? Como criar health checks no Kubernetes

Por que suas aplicações caem do nada no Kubernetes

Gerenciar sistemas em contêineres costuma parecer simples até o momento em que a aplicação trava silenciosamente em produção. Sem uma supervisão automatizada, o orquestrador continua enviando requisições para uma instância que já perdeu a capacidade de responder, gerando lentidão e frustração para o usuário final. Na prática, isso significa que a infraestrutura precisa de mecanismos constantes para checar a saúde dos serviços, disparando ações corretivas antes que o problema afete o negócio. Se você gerencia sistemas distribuídos, sabe que prevenir falhas exige um planejamento tão rigoroso quanto o necessário para estruturar uma arquitetura de resiliência e monitoramento preventivo.

O Kubernetes resolve essa necessidade utilizando verificações de saúde conhecidas como probes. Esses testes periódicos permitem que a plataforma descubra exatamente quando um serviço está pronto para receber tráfego, quando ele precisa ser reiniciado ou se ele sequer conseguiu inicializar corretamente. No entanto, configurar esses parâmetros de forma incorreta pode criar um efeito colateral grave, derrubando pods perfeitamente saudáveis apenas porque demoraram um pouco mais para processar uma carga intensa.

Entendendo os três tipos principais de sondas

Para estruturar uma defesa sólida, o Kubernetes divide as verificações em três categorias distintas, cada uma com um papel bem definido no ciclo de vida do contêiner. A primeira delas é a startup probe, responsável por verificar se a aplicação terminou de subir. Ela é especialmente útil em sistemas legados ou aplicações corporativas robustas que exigem tempo para carregar dados na memória antes de aceitar conexões. Enquanto a startup probe estiver rodando, as demais verificações ficam desativadas, impedindo que o orquestrador mate a aplicação prematuramente.

A segunda categoria é a liveness probe, que indica se o contêiner ainda está vivo e funcionando. Caso essa verificação falhe repetidamente, o Kubernetes entende que a aplicação entrou em um estado irrecuperável e decide destruí-la para criar uma nova instância do zero. Já a readiness probe cuida da prontidão: ela avisa ao balanceador de carga se o serviço está apto a receber tráfego de rede naquele exato momento. Se um banco de dados externo cair, por exemplo, a readiness probe falha, isolando o pod afetado sem precisar reiniciar o processo inteiro.

Erros comuns na configuração de tempos e limites

Um dos maiores equívocos cometidos por equipes de engenharia é tratar todas as sondas com os mesmos valores de tempo. Definir um intervalo muito curto para o initialDelaySeconds ou um timeout agressivo costuma gerar o chamado ciclo de morte, onde o sistema tenta reiniciar um pod que apenas estava processando uma consulta pesada. Na prática, isso esgota os recursos do cluster e agrava ainda mais a instabilidade que a verificação tentava evitar.

Outro problema frequente é utilizar endpoints excessivamente complexos para as checagens, como rotas que consultam múltiplos microsserviços e bancos de dados em cascata. Se o banco principal sofrer uma oscilação momentânea, todas as aplicações dependentes falham na liveness probe ao mesmo tempo, gerando uma reação em cadeia catastrófica. O ideal é manter a rota de health check leve, testando apenas a integridade interna do processo sem dependências externas profundas.

Como implementar liveness e readiness na prática

Configurar essas diretrizes exige atenção aos detalhes do manifesto YAML que define o seu deployment. A seguir, veja um exemplo prático de como estruturar esses testes utilizando requisições HTTP básicas para monitorar a saúde do serviço de forma segura.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: minha-api
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: api
        image: minha-api:v1
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /health/live
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20

Neste exemplo, a readiness probe começa a testar a aplicação após cinco segundos, repetindo a checagem a cada dez segundos. Enquanto isso, a liveness probe aguarda quinze segundos para dar margem à inicialização completa e depois monitora a vida útil do processo periodicamente. Esse espaçamento evita falsos positivos durante picos normais de utilização da CPU.

Boas práticas para manter seu cluster estável

Manter um ambiente de produção resiliente exige testes contínuos de estresse e validação dos limites configurados. Ajuste os parâmetros de failureThreshold e successThreshold para garantir que uma falha momentânea de rede não resulte em reinicializações desnecessárias. Além disso, garanta que sua aplicação libere conexões antigas corretamente e gerencie seus recursos de memória para evitar vazamentos que confundam as sondas de vivência.

Investir tempo na modelagem correta do ciclo de vida dos seus contêineres é o que diferencia um sistema frágil de uma infraestrutura verdadeiramente elástica. Quando a aplicação conversa bem com o orquestrador, as quedas misteriosas desaparecem e a operação ganha a previsibilidade necessária para escalar sem medo. Para complementar essa implementação em produção, vale conferir também nossas análises técnicas sobre Como rodar inteligência artificial local com Ollama e garantir privacidade e API lenta? Como otimizar consultas N+1 no Hibernate.

Considerações finais

A estabilidade de um cluster Kubernetes não depende apenas da capacidade dos nós físicos, mas da forma como cada microsserviço comunica seu estado real de saúde. O uso equilibrado de startup, liveness e readiness probes cria uma rede de segurança automatizada que protege o sistema contra falhas inesperadas. Ao evitar configurações genéricas e alinhar os tempos de resposta à realidade do seu software, você conquista um ambiente de produção muito mais seguro, previsível e preparado para o crescimento contínuo.