Health checks, scaling, rollout e rollback no Kubernetes

Nos conteúdos anteriores, construímos o caminho até aqui em camadas: primeiro o problema de orquestração, depois Pods e Deployments, em seguida Services e descoberta, e por fim configuração, Secrets e persistência.

Agora falta a pergunta que separa “o objeto existe” de “o sistema está realmente operando bem”:

como Kubernetes decide se uma nova instância pode receber tráfego, se precisa ser reiniciada e se uma nova versão está pronta para substituir a anterior?

É aqui que health checks, réplicas, scaling, rollout, rollback e observabilidade começam a se encontrar.

O erro mais comum é tratar tudo isso como sinônimo de “alta disponibilidade”. Não é.

Um container pode estar rodando e a aplicação ainda estar inicializando. Um Pod pode estar Ready e uma dependência crítica estar degradada. Um Deployment pode concluir o rollout e usuários continuarem recebendo erros de negócio.

A cadeia que vale guardar desde o início é esta:

rollout concluído
      ≠
workloads prontos
      ≠
serviço saudável
      ≠
usuário satisfeito

Kubernetes consegue automatizar ações quando recebe sinais técnicos confiáveis. Ele não descobre sozinho o que “saudável” significa para o seu produto.

Processo iniciado não significa aplicação pronta

Quando um processo começa a executar, o sistema operacional sabe que existe algo rodando. Isso é muito diferente de saber se a aplicação já pode atender uma requisição real.

Uma API pode precisar:

• carregar configuração;
• abrir pools de conexão;
• aquecer caches;
• validar certificados;
• restaurar estado temporário;
• concluir migrações ou preparação interna;
• estabelecer comunicação com dependências essenciais.

Durante alguns segundos — ou minutos — o processo existe, mas ainda não deveria receber tráfego.

Essa distinção parece pequena em uma aplicação única numa VPS. Em um ambiente reconciliado, ela é decisiva: novas réplicas aparecem durante scaling e rollout, e o sistema precisa distinguir “nasceu” de “está pronta”.

É justamente para evitar uma única pergunta genérica do tipo “está saudável?” que Kubernetes separa probes com responsabilidades diferentes.

Startup probe: a aplicação terminou de iniciar?

A startup probe responde à pergunta mais inicial:

a aplicação já concluiu sua fase de startup?

Enquanto uma startup probe está configurada e ainda não obteve sucesso, Kubernetes não executa liveness nem readiness probes daquele container.

Isso protege aplicações que realmente precisam de mais tempo para iniciar. Sem essa separação, uma liveness probe agressiva poderia interpretar inicialização lenta como falha e reiniciar o processo repetidamente antes que ele tivesse chance de ficar operacional.

O efeito seria um ciclo perverso:

aplicação inicia
      ↓
ainda está aquecendo
      ↓
liveness conclui "falhou"
      ↓
container reinicia
      ↓
startup começa do zero

A startup probe não deve virar desculpa para inicializações eternas. Ela cria uma janela explícita para um comportamento conhecido.

Se a startup probe nunca passa dentro da tolerância configurada, o kubelet encerra o container e aplica sua política de restart.

O conceito importante não é decorar failureThreshold ou periodSeconds. É modelar corretamente a fase de vida: antes de avaliar saúde contínua, a aplicação precisa demonstrar que conseguiu iniciar.

Readiness probe: esta instância pode receber tráfego agora?

Depois da inicialização vem uma pergunta diferente:

esta instância está pronta para atender tráfego neste momento?

Esse é o papel da readiness probe.

Uma aplicação pode continuar viva e, ainda assim, precisar sair temporariamente do caminho de requisições. Pense em um backend que:

• perdeu acesso momentâneo a uma dependência essencial;
• está recarregando dados;
• entrou em sobrecarga controlada;
• ainda está aquecendo caches;
• está concluindo uma transição necessária antes de responder corretamente.

Nesses casos, matar o processo pode ser pior do que simplesmente parar de enviar novas requisições para aquela réplica.

Quando a readiness falha, Kubernetes marca o container/Pod como não pronto e o EndpointSlice controller remove o endereço daquele Pod dos endpoints prontos dos Services correspondentes.

O processo continua executando. A diferença é operacional:

vivo?         sim
pronto?       não
recebe tráfego regular do Service? não

Readiness, portanto, é uma ferramenta de admissão de tráfego, não um mecanismo de restart.

Ela também roda durante todo o ciclo de vida do container. Uma réplica pode estar pronta agora, ficar temporariamente não pronta e voltar a ficar pronta depois.

Essa característica é importante para sistemas distribuídos: “não me envie tráfego por alguns instantes” é um estado legítimo e diferente de “reinicie-me”.

Liveness probe: este processo ainda consegue continuar?

A liveness probe responde a uma pergunta mais dura:

este container entrou em um estado do qual não esperamos recuperação sem restart?

Um exemplo clássico é um deadlock: o processo existe, mas deixou de fazer progresso.

Quando a liveness falha além da tolerância configurada, o kubelet encerra e reinicia o container conforme a política aplicável.

É um mecanismo poderoso — e perigoso quando a pergunta está errada.

Se sua liveness depende de uma API externa, banco remoto ou serviço que pode ficar indisponível para todas as réplicas ao mesmo tempo, uma falha dessa dependência pode provocar reinícios em massa justamente durante o incidente.

A documentação oficial alerta para esse risco: uma liveness mal desenhada pode amplificar falhas em cascata, reduzir capacidade e aumentar carga nas réplicas restantes.

Uma regra mental melhor é:

• startup: “já terminei de iniciar?”;
• readiness: “posso receber tráfego agora?”;
• liveness: “ainda consigo continuar sem restart?”.

Não use as três para perguntar exatamente a mesma coisa só porque tecnicamente podem consultar o mesmo endpoint.

Health check técnico não é saúde do produto

Mesmo probes perfeitamente desenhadas enxergam apenas o contrato que você programou.

Uma readiness pode verificar que a aplicação responde em poucos milissegundos. Isso não prova que:

• o checkout conclui;
• a fila está sendo consumida no ritmo certo;
• pagamentos estão sendo autorizados;
• uma feature crítica não regrediu;
• latência de usuários reais está aceitável;
• a taxa de erro de negócio continua normal.

Kubernetes trabalha com sinais técnicos de infraestrutura e workload.

A saúde do sistema exige também observabilidade: logs, métricas, traces, eventos e, quando possível, sinais ligados ao comportamento real do usuário.

Probes participam desse sistema de feedback. Não o substituem.

Réplicas: disponibilidade começa antes do autoscaling

Antes de falar em autoscaling, vale separar um conceito mais simples: ter várias réplicas.

Se um Deployment deseja três Pods equivalentes, o ReplicaSet tenta manter essa quantidade. Quando um desaparece, outro pode ser criado.

Isso não é autoscaling. É reconciliação da quantidade desejada.

Mesmo uma quantidade fixa de réplicas já permite distribuir tráfego e tolerar a perda de uma instância — desde que a aplicação e suas dependências tenham sido desenhadas para isso.

A quantidade certa não vem do Kubernetes. Ela depende de:

• carga;
• consumo de recursos;
• latência;
• tempo de startup;
• capacidade das dependências;
• requisitos de disponibilidade;
• custo aceitável;
• comportamento durante manutenção e rollout.

Colocar dez Pods onde o banco suporta apenas três vezes mais concorrência não cria resiliência. Pode apenas deslocar o gargalo.

Scaling aumenta capacidade de uma camada; não elimina limites do sistema inteiro.

Scaling horizontal: mudar a quantidade de instâncias

Horizontal scaling significa alterar o número de Pods que executam o workload.

Em termos conceituais:

mais demanda
     ↓
mais réplicas
     ↓
mais capacidade paralela — se o restante do sistema suportar

Kubernetes permite mudar essa quantidade manualmente ou automaticamente.

O HorizontalPodAutoscaler, HPA, é uma das formas de automatizar isso. Ele observa métricas e ajusta a escala desejada de workloads escaláveis, como Deployments e StatefulSets.

Mas HPA não é “Kubernetes percebe que está lento e resolve”.

Ele precisa de métricas, targets e comportamento configurados. CPU e memória são sinais possíveis; métricas customizadas e externas também podem participar.

Mais importante: o controlador precisa lidar com Pods que ainda estão iniciando ou não estão prontos. A própria documentação do HPA possui regras para evitar que métricas de inicialização distorçam decisões de escala.

Isso conecta duas partes que muitas vezes são ensinadas separadamente:

autoscaling depende de sinais de readiness coerentes.

Se uma aplicação marca Ready cedo demais, métricas e tráfego podem tratar uma réplica ainda em aquecimento como plenamente disponível. Se nunca fica pronta, aumentar réplicas pode apenas multiplicar instâncias problemáticas.

Por isso, neste ciclo, HPA entra apenas como mapa conceitual. Configurar autoscaling corretamente é competência operacional de Lab/curso.

Rollout: mudar o estado desejado sem trocar tudo de uma vez

Quando o template de Pod de um Deployment muda — por exemplo, uma nova imagem — Kubernetes inicia um rollout.

O Deployment cria uma nova revisão e coordena ReplicaSets para aproximar o estado observado do novo estado desejado.

No modo RollingUpdate, que é o padrão, o desenho geral é:

ReplicaSet antigo  ████
ReplicaSet novo    ░

          ↓

antigo             ██
novo               ███

          ↓

antigo
novo               ████

O ritmo dessa substituição depende da estratégia e das regras do Deployment.

A ideia é evitar uma troca “tudo ou nada” quando o workload permite evolução gradual.

Mas novamente existe uma dependência importante: para o rollout avançar com segurança, as novas réplicas precisam demonstrar disponibilidade. Readiness e minReadySeconds, quando usados, participam da definição técnica do que significa estar disponível.

Um rollout pode ficar travado por problemas como:

• readiness que nunca passa;
• imagem inexistente;
• falta de quota;
• permissões;
• configuração inválida;
• crash loop;
• falta de capacidade.

O Deployment consegue expor esse estado. progressDeadlineSeconds, por exemplo, permite sinalizar que a progressão estagnou.

O que Kubernetes não faz automaticamente ao detectar essa condição é decidir a estratégia de negócio correta para o incidente.

“Successfully rolled out” não significa “versão boa”

Este é um dos pontos mais importantes de toda a série.

A documentação considera um Deployment completo quando, em resumo, todas as réplicas foram atualizadas, estão disponíveis e não restam réplicas antigas em execução.

Isso é uma definição operacional útil. Mas ela não conhece a semântica da aplicação.

Uma versão pode cumprir todas essas condições e ainda:

• retornar preço errado;
• quebrar apenas uma rota menos acessada;
• produzir eventos duplicados;
• elevar latência em um fluxo específico;
• corromper um dado sem derrubar o processo;
• falhar apenas para determinado perfil de cliente;
• consumir muito mais banco mesmo permanecendo Ready.

Por isso:

Deployment Complete
        ↓
prova que a transição técnica atingiu o estado esperado

não prova
        ↓
que a versão entregou o comportamento esperado ao usuário

É aqui que métricas de aplicação, traces, logs, error rate, latência e sinais de negócio precisam participar do gate de release.

Kubernetes executa reconciliação. A organização define critérios de sucesso.

Rollback: voltar o template não desfaz o mundo

Deployment mantém histórico de revisões — dentro do limite configurado — e pode voltar a uma revisão anterior.

Mas rollback também é frequentemente superestimado.

Uma revisão de Deployment existe quando o Pod template muda. Escalar de três para cinco réplicas, por exemplo, não cria uma nova revisão do Deployment.

Ao fazer rollback, o que volta é o Pod template daquela revisão.

Isso não significa automaticamente reverter:

• migration já aplicada no banco;
• mensagem já publicada numa fila;
• alteração em serviço externo;
• arquivo já transformado;
• configuração gerida fora daquele template;
• efeito de negócio já executado.

Portanto, “temos rollback no Kubernetes” não equivale a “qualquer deploy é reversível”.

Uma estratégia real de rollback precisa considerar compatibilidade de dados, contratos entre versões e efeitos colaterais.

Em alguns sistemas, roll-forward — corrigir rapidamente com uma nova versão — pode ser mais seguro do que tentar voltar.

A capacidade do Deployment é valiosa, mas ela resolve a camada do workload.

O elo entre rollout e observabilidade

Imagine que uma nova revisão entra em produção.

Os Pods iniciam. Startup passa. Readiness passa. O Deployment progride. A revisão antiga some.

Agora surgem duas perguntas diferentes:

1. a plataforma conseguiu implantar?
2. a versão está funcionando bem?

A primeira é respondida principalmente por estado de recursos e controllers.

A segunda precisa de observabilidade.

Um processo maduro pode observar, por exemplo:

• taxa de erro;
• p95/p99 de latência;
• saturação;
• backlog de filas;
• falhas em integrações;
• traces anormais;
• eventos de restart;
• disponibilidade percebida;
• métricas críticas de negócio.

Se a única evidência de sucesso for “o rollout terminou”, o feedback está incompleto.

Automatizar sem observar apenas acelera o erro

Kubernetes é excelente em repetir ações consistentemente.

Isso é vantagem quando a intenção está correta e os sinais são bons.

Também significa que uma regra ruim pode ser aplicada rapidamente em dezenas de réplicas.

Uma liveness errada pode reiniciar Pods saudáveis.

Uma readiness superficial pode enviar tráfego cedo demais.

Um autoscaler guiado por uma métrica ruim pode escalar na direção errada.

Um rollout pode promover uma regressão funcional para todas as réplicas.

Automação não reduz a importância do entendimento operacional. Ela aumenta o impacto tanto das boas decisões quanto das ruins.

É por isso que Kubernetes deve entrar depois de fundamentos como deploy reproduzível, healthchecks, observabilidade e capacidade de recuperação — não como substituto deles.

Um modelo mental para operação de uma revisão

Você pode pensar na vida de uma nova versão desta forma:

nova revisão declarada
        ↓
novos Pods são criados
        ↓
startup: conseguiram iniciar?
        ↓
readiness: podem receber tráfego?
        ↓
Deployment: há réplicas disponíveis suficientes?
        ↓
rollout progride
        ↓
réplicas antigas saem
        ↓
rollout conclui
        ↓
observabilidade: a versão está realmente saudável?
        ↓
manter, corrigir, roll-forward ou rollback

Cada etapa responde uma pergunta diferente.

Misturá-las produz falso conforto. Separá-las cria gates mais claros.

Antes de automatizar scaling

Autoscaling deveria responder a um comportamento medido: demanda real, tempo de startup, capacidade das dependências, custo e um workload que seja de fato horizontalmente escalável.

Se esses sinais ainda são nebulosos, aumentar Pods automaticamente pode multiplicar custo e pressão sem entregar capacidade útil. HPA é uma ferramenta de controle; a qualidade do controle depende do sinal e do modelo do sistema.

Kubernetes não conhece seu SLO por osmose

Um cluster pode manter Pods disponíveis e ainda violar objetivos de serviço.

Seu SLO pode dizer que 99,9% das requisições precisam completar com sucesso abaixo de determinado limite. Kubernetes não deduz esse objetivo da existência de uma readiness probe.

Probes são binárias e locais ao contrato que você programou.

SLOs, alertas e observabilidade trabalham em outra dimensão: comportamento agregado ao longo do tempo.

Por isso, uma arquitetura operacional madura conecta as duas coisas sem confundi-las:

• probes protegem o tráfego e a vida do workload;
• controllers reconciliam quantidade e versão;
• observabilidade mede comportamento;
• SLOs definem o que é aceitável;
• pessoas e automações tomam decisões a partir desses sinais.

Quando rollback é uma decisão, não um botão

Diante de uma regressão, voltar a revisão anterior pode ser correto.

Mas a decisão deveria considerar:

• a versão anterior ainda é compatível com o estado atual dos dados?
• a falha está realmente no código da revisão?
• houve mudança de configuração externa?
• a dependência problemática continua indisponível?
• o rollback pode agravar a inconsistência?
• existe uma correção pequena mais segura para roll-forward?

Rollback é uma capacidade de recuperação. Não é uma garantia de reversibilidade total.

O que Kubernetes automatiza — e o que continua sendo seu

Kubernetes automatiza reconciliação: restart baseado em liveness, retirada de endpoints não prontos, manutenção de réplicas, scaling quando modelado, rollout e restauração de Pod templates anteriores.

Sua equipe continua responsável por definir os sinais, observar o comportamento, compreender dependências e dados, estabelecer critérios de release e decidir quando manter, corrigir, avançar ou reverter. Essa divisão de responsabilidade é mais importante do que qualquer comando.

O fechamento dos fundamentos de Kubernetes

Com este artigo, a sequência conceitual fica completa:

por que orquestrar
      ↓
Pods / ReplicaSets / Deployments
      ↓
Services / DNS / networking
      ↓
ConfigMaps / Secrets / volumes
      ↓
probes / scaling / rollout / rollback

Isso ainda não transforma leitura em competência operacional.

O próximo passo, fora desta série editorial, é prática controlada: criar workloads, provocar falhas, observar reconciliação, validar readiness, testar rollout, induzir rollback e coletar evidence.

É justamente por isso que a prática pertence aos Labs e cursos.

Antes disso, porém, vale responder uma pergunta mais básica: sua aplicação e sua equipe estão realmente prontas para assumir a complexidade de Kubernetes?

O checklist de prontidão que acompanha este ciclo existe para ajudar nessa decisão — sem tratar Kubernetes como destino obrigatório de todo projeto.

Saia na Frente

Receba o filtro da semana

IA, produto e negócio — sem avalanche.

Website

Nome (opcional) E-mail

Aceito a Política de Privacidade. Receber o filtro