InfraAvançado8 min de leitura6 seções2014, Data conhecida

Kubernetes & pods

Você declara o estado desejado — '3 réplicas desta imagem, com este tanto de memória' — e o cluster trabalha continuamente para a realidade convergir. Pod é a menor unidade: um ou mais containers que vivem e morrem juntos.

Em 10 segundos

Um termostato para infraestrutura: você declara o estado desejado (3 réplicas, versão X, tanto de CPU) e o loop de reconciliação corrige a realidade sem parar. Pod = a menor unidade agendável: containers que compartilham IP e destino.

Antes de ter nome

O Borg, escalonador interno do Google desde ~2003, é o avô direto: o Kubernetes é a terceira tentativa de contar o que o Borg aprendeu.

  • #orquestracao
  • #pods
  • #k8s
  • #deploy
  • #escala
Analogia

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.

01Conceito

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.

Como se organiza
  • Cluster

    • Node A

      • Pod: app + sidecar

      • Pod: app

    • Node B

      • Pod: app

Cluster contém nodes; nodes rodam pods; o pod agrupa containers inseparáveis. As réplicas se espalham entre nodes — um node morto leva um pod, nunca o serviço.
02Anatomia

As três camadas do modelo

Camada 1/3Estado desejado (manifestos)

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.0

Se 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.

03Implementação

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() {/* ... */}
04No mundo real

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.

05Cuidado

Armadilhas

  1. 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.

  2. 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.

  3. 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.

  4. 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.

06Decisão

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 pods

O 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