O termostato, não o interruptor
Um aquecedor de interruptor obedece comandos: liga, desliga. O termostato recebe uma intenção — 'quero 22°C' — e trabalha sozinho: mede, compara, liga, desliga, o dia inteiro. O Kubernetes é o termostato da sua infraestrutura: você não manda 'suba um container na máquina 4'; declara 'existam 3 réplicas saudáveis' e ele faz o que for preciso — inclusive às 3h da manhã, quando a máquina 4 morrer.
O problema: containers demais para mãos humanas
Um container numa máquina é trivial. Trinta serviços, três réplicas cada, cinco máquinas: agora existe um problema de alocação (o que roda onde), um de saúde (quem vigia e reinicia), um de rede (como o serviço A acha o B se os IPs mudam a cada restart) e um de mudança (como trocar a versão sem janela de manutenção).
A resposta artesanal — scripts de deploy, systemd, um humano de plantão — funciona e para de funcionar num ponto previsível: quando a frequência de mudanças vezes o número de serviços ultrapassa o que cabe na cabeça de quem opera.
O vocabulário mínimo que destrava o resto: Pod — um ou mais containers agendados juntos, com IP compartilhado (o app e seu sidecar de proxy, por exemplo); pods são efêmeros e substituíveis, nunca consertados. Deployment — 'quero N réplicas desta imagem', com estratégia de rollout e rollback. Service — o endereço estável na frente de pods que nascem e morrem; quem chama o serviço nunca conhece um pod específico.
O insight profundo não é a escala — é o modelo declarativo. Manifestos em YAML no git descrevem o sistema inteiro; o cluster converge para eles. Auditar é ler o git; recuperar um desastre é aplicar os manifestos de novo; o 'como chegar lá' deixou de ser problema seu. É o mesmo salto do imperativo para o declarativo que o SQL deu sobre percorrer índices na mão.
Cluster
Node A
Pod: app + sidecar
Pod: app
Node B
Pod: app
As três camadas do modelo
Camada 1/3Estado desejado (manifestos)
use ← →Camada 1
Estado desejado (manifestos)
YAML no git descrevendo o que deve existir
Deployments, Services, ConfigMaps: a descrição completa e versionada do sistema. O git vira a fonte da verdade da infraestrutura — revisar mudança de produção é revisar um diff.
No código
replicas: 3
image: registro/app:1.42.0Se violar: mudanças aplicadas na mão com kubectl e nunca commitadas criam a deriva clássica: o cluster real não bate com o git, e a próxima aplicação dos manifestos desfaz um ajuste que alguém achava permanente.
Código
// O contrato que o Kubernetes espera do seu app: dois endpoints honestos
// e uma morte digna. Sem isso, rollout sem downtime é sorte, não garantia.
import http from "node:http";
let pronto = false; // readiness: "posso receber tráfego?"
let vivo = true; // liveness: "estou funcional ou preciso reiniciar?"
const servidor = http.createServer(async (req, res) => {
// LIVENESS: só responde "estou travado?" — nunca cheque dependências aqui.
// Se o banco cair e o liveness falhar por isso, o k8s reinicia TODOS os
// pods em loop... e o banco continua fora do ar.
if (req.url === "/healthz") {
return res.writeHead(vivo ? 200 : 500).end();
}
// READINESS: "consigo atender AGORA?" — aqui sim, cheque o que importa.
// Falhou? O k8s apenas tira o pod do balanceador até melhorar.
if (req.url === "/readyz") {
return res.writeHead(pronto ? 200 : 503).end();
}
res.writeHead(200).end("ok");
});
servidor.listen(3000, async () => {
await aquecerConexoes(); // pool de banco, caches...
pronto = true; // só então o tráfego começa a chegar
});
// No rollout, o k8s manda SIGTERM, espera o pod drenar, e só então mata.
process.on("SIGTERM", () => {
pronto = false; // sai do balanceador primeiro
servidor.close(() => process.exit(0)); // termina as requests em voo
});
async function aquecerConexoes() {/* ... */}Casos de uso
Rollout que se cancela sozinho
Cenário
Um serviço de pagamento com 6 réplicas precisa de deploys diários sem derrubar transação — e a versão nova às vezes tem bug que só aparece com tráfego real.
Como o padrão entra
O Deployment troca uma réplica por vez: sobe o pod novo, espera o readiness aprovar, só então drena um antigo. Se a versão nova reprova nas probes, o rollout congela com 5 réplicas velhas atendendo — e um comando volta tudo. O deploy vira não-evento.
Trade-off: A garantia é tão boa quanto as probes: readiness superficial aprova versão quebrada e o rollout 'bem-sucedido' derruba produção. Escrever probes honestas é parte do deploy, não acessório.
Black Friday sem provisionar para o pico o ano todo
Cenário
O tráfego normal pede 4 réplicas; o pico de promoção pede 40. Manter 40 o ano inteiro custa dez vezes mais; subir na mão durante o pico é apostar que alguém estará acordado.
Como o padrão entra
O autoscaler (HPA) observa CPU e fila e ajusta as réplicas entre 4 e 40 sozinho — sobe conforme a demanda chega, desce quando passa. O cluster agenda os pods novos onde há espaço; se os nodes acabam, o autoscaler de nodes pede mais máquinas ao provedor.
Trade-off: Autoscaling mal calibrado oscila (sobe-desce em loop) ou reage tarde demais para picos em degrau — e o teto de custo agora é dinâmico, o que o financeiro vai querer entender.
Armadilhas
Kubernetes para três serviços
Um cluster é um sistema distribuído complexo que você passa a operar: upgrades, certificados, rede, RBAC. Para meia dúzia de containers com tráfego modesto, um PaaS ou um Docker Compose num VPS entrega o mesmo resultado por uma fração do custo cognitivo. O k8s se paga em escala de serviços e de equipe — não antes.
Liveness probe que mente
Liveness que checa o banco transforma indisponibilidade de dependência em massacre de pods: o banco cai, todos os livenesses falham, o k8s reinicia tudo em loop — e o banco continua fora. Liveness responde 'estou travado?'; readiness responde 'posso atender agora?'. Confundir os dois é o incidente clássico.
Pods sem requests e limits
Sem declarar quanto de CPU e memória o pod precisa, o scheduler aloca no escuro e o runtime não protege os vizinhos: um vazamento de memória num serviço derruba o node e leva os inocentes junto. Requests e limits são o contrato mínimo de convivência.
Mudança de produção via kubectl e memória
O ajuste aplicado na mão ('só aumentei as réplicas') e nunca commitado vive até a próxima aplicação dos manifestos — que o desfaz silenciosamente. Se o git não é a fonte da verdade, ninguém sabe mais o que produção deveria ser.
Quando usar × quando evitar
Use quando
3- Muitos serviços, muitas equipes, deploys frequentes — o caso que justifica orquestração.
- Necessidade real de autoscaling e rollout gradual com rollback automático.
- Preferencialmente gerenciado (EKS/GKE/AKS) — operar o plano de controle é trabalho de time de plataforma.
Evite quando
3- Projetos pequenos — PaaS ou VPS com Compose resolvem por uma fração da complexidade.
- Times sem apetite operacional: o cluster não se administra sozinho.
- Workloads com estado pesado sem experiência — bancos em k8s são um capítulo avançado à parte.
Testar o que ficou
4 armadilhas de Kubernetes & pods viram perguntas, com o nome do padrão escondido, misturadas com padrões parecidos.
Onde isto aparece de verdade
Você já usa isto, talvez sem saber o nome.
GKE, EKS, AKSOs Kubernetes gerenciados de Google, AWS e Azure: você declara o estado desejado e o cluster cuida de manter os contêineres de pé.kubectl applyVocê entrega um manifesto do que quer e o controlador reconcilia a realidade até bater com ele, reiniciando o que cair pelo caminho.Deployments que reescalam sozinhosSob carga, o autoscaler sobe réplicas novas e as distribui pelos nós; quando a carga cai, ele as remove sem intervenção manual.
O padrão em uma linha
Sem nome de domínio, sem cerimônia. Só a ideia.
// Declara o desejado; o control loop converge.
// replicas: 3 → o cluster mantém 3 podsO que ele cobra
3 saltos a mais entre a chamada e o efeito.
- Um plano de controle inteiro a operar, atualizar e entender antes de rodar qualquer coisa
- A curva e a superfície de configuração são enormes, e o custo fixo não compensa em escala pequena
Não vale se: você tem poucos serviços e um tráfego que um par de máquinas aguenta — a complexidade do orquestrador supera o que ela resolve.
Onde isto aparece
Continue por aqui
- Docker & containersEmpacota o app com tudo que ele precisa numa imagem imutável que roda igual em qualquer máquina. Container é essa imagem em execução — um processo isolado pelo kernel, não uma máquina virtual.
- VPS — o servidor na sua mãoUma fatia virtual de um servidor físico, com root, IP público e nenhuma opinião: você instala, configura, protege e opera tudo. É o chão que explica os andares de cima — container, orquestrador e PaaS são abstrações disto aqui.