Kubernetes: o guia prático de orquestração de containers

• O que é Kubernetes e por que ele existe?
• Como funciona a arquitetura de um cluster?
• Quais objetos você realmente precisa conhecer?
• Como o Kubernetes escala e se recupera de falhas?
• Quando NÃO usar Kubernetes?
• Como começar com Kubernetes sem sofrer?

Kubernetes é o sistema que mantém aplicações em containers rodando do jeito que você declarou, sem depender de alguém acordado para consertar. Você descreve o estado desejado em YAML e o cluster reconcilia a realidade com essa descrição, continuamente.

O que é Kubernetes e por que ele existe?

Kubernetes (abreviado como K8s) é um orquestrador de containers open source, nascido da experiência do Google com o sistema interno Borg e doado à Cloud Native Computing Foundation em 2015. Ele resolve o problema que aparece logo depois do Docker: empacotar uma aplicação em container é simples; manter centenas delas vivas, distribuídas, atualizadas e acessíveis não é.

O conceito central é o modelo declarativo. Você não dá ordens ("suba dois containers no servidor 3"), você declara um fato desejado ("quero três réplicas desta imagem"). Um conjunto de controladores compara o estado atual com o desejado e age para eliminar a diferença — o loop de reconciliação.

A consequência prática é operacional: um nó morre às 3h da manhã e o cluster reprograma os Pods afetados em nós saudáveis antes de alguém acordar. Um deploy quebra e o rollback é uma linha de comando, porque a versão anterior continua descrita no histórico do objeto.

Exemplo prático: com Docker puro, se o processo do container morre em um servidor, alguém precisa reiniciar. Com Kubernetes, o kubelet detecta a falha, recria o container e — se o nó inteiro cair — o scheduler realoca a carga em outro nó, mantendo as três réplicas declaradas.

Como funciona a arquitetura de um cluster?

Um cluster tem duas camadas: o control plane, que decide, e os nós de trabalho, que executam.

No control plane:

• kube-apiserver — a porta de entrada. Todo comando, controlador e componente conversa por ele. É a única peça que fala com o banco de estado.
• etcd — banco chave-valor distribuído que guarda o estado inteiro do cluster. Perder o etcd sem backup é perder o cluster.
• kube-scheduler — decide em qual nó cada Pod novo vai rodar, considerando recursos disponíveis, afinidades e restrições.
• kube-controller-manager — executa os loops de reconciliação (réplicas, nós, endpoints).

Nos nós de trabalho:

• kubelet — o agente que garante que os containers descritos para aquele nó estejam rodando e saudáveis.
• kube-proxy — mantém as regras de rede que fazem o tráfego chegar ao Pod certo.
• container runtime — quem realmente executa (containerd é o padrão atual).

Exemplo prático: ao rodar kubectl apply -f deploy.yaml, o apiserver grava o objeto no etcd, o controller de Deployment cria um ReplicaSet, o ReplicaSet pede três Pods, o scheduler escolhe os nós e cada kubelet baixa a imagem e sobe o container. Você declarou uma vez; cinco componentes trabalharam.

Quais objetos você realmente precisa conhecer?

A documentação lista dezenas de tipos, mas cinco cobrem a maior parte do dia a dia:

O manifesto mínimo de uma aplicação web tem esta forma:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-pedidos
spec:
  replicas: 3
  selector:
    matchLabels: { app: api-pedidos }
  template:
    metadata:
      labels: { app: api-pedidos }
    spec:
      containers:
        - name: api
          image: registry.exemplo.com/api-pedidos:1.4.2
          ports: [{ containerPort: 3000 }]
          resources:
            requests: { cpu: 100m, memory: 128Mi }
            limits: { cpu: 500m, memory: 512Mi }
          readinessProbe:
            httpGet: { path: /health, port: 3000 }

Dois campos merecem destaque porque são os mais ignorados por quem começa. resources informa ao scheduler quanto a aplicação precisa: sem requests, ele aloca às cegas e o nó vira uma disputa por CPU. readinessProbe diz quando o Pod está pronto para receber tráfego: sem ela, o Service manda requisição para um container que ainda está subindo, e o deploy "sem downtime" produz erros 502.

Exemplo prático: um time investigava erros esporádicos em cada deploy. A causa era a ausência de readinessProbe — o Kubernetes considerava o Pod pronto assim que o processo iniciava, dez segundos antes de a aplicação terminar de carregar as conexões de banco.

Como o Kubernetes escala e se recupera de falhas?

A recuperação é consequência direta do loop de reconciliação, e acontece em três níveis:

1. Container. Se o processo morre, o kubelet reinicia segundo a política definida. Se a livenessProbe falha repetidamente, o container é reiniciado mesmo estando "vivo" tecnicamente — é como se detecta deadlock.
2. Pod. Se um Pod é destruído ou o nó fica indisponível, o ReplicaSet percebe o desvio da contagem declarada e cria outro.
3. Nó. Se a máquina inteira some, o controlador marca o nó como não pronto e realoca a carga; com autoscaler de cluster, um nó novo é provisionado.

A escalabilidade tem duas dimensões. O HorizontalPodAutoscaler (HPA) aumenta o número de réplicas com base em métricas — uso de CPU, memória ou métricas customizadas como requisições por segundo. O Cluster Autoscaler adiciona ou remove nós quando os Pods não cabem mais nas máquinas existentes.

A combinação é o que entrega a promessa de elasticidade: tráfego sobe, HPA cria réplicas; réplicas não cabem, autoscaler adiciona nós; tráfego cai, o processo se desfaz na ordem inversa. Vale lembrar que o segundo passo custa dinheiro real — e é exatamente aqui que a disciplina de FinOps evita a surpresa no fim do mês.

Exemplo prático: um e-commerce configurou HPA entre 3 e 30 réplicas a 70% de CPU. Na Black Friday, o cluster subiu para 24 réplicas e 6 nós extras às 8h e voltou ao mínimo às 2h da manhã seguinte, sem ninguém tocar em nada.

Quando NÃO usar Kubernetes?

Esta é a seção que a maior parte dos tutoriais omite. Kubernetes é um multiplicador de capacidade operacional — e multiplicar zero continua dando zero. Ele tende a ser a escolha errada quando:

1. A aplicação é um monolito com tráfego estável. Uma VM com Docker Compose e um balanceador entrega o mesmo resultado com uma fração do esforço.
2. O time não tem alguém dedicado à plataforma. Cluster exige manutenção: atualização de versão, gestão de certificados, políticas de rede, controle de acesso. Sem dono, ele degrada silenciosamente.
3. O produto ainda está buscando encaixe de mercado. Complexidade de infraestrutura compete diretamente com velocidade de iteração no estágio em que velocidade é tudo.
4. Existe um PaaS que atende. Cloud Run, App Runner, Render, Fly.io e Vercel resolvem containers gerenciados sem expor você ao YAML — e vários rodam Kubernetes por baixo, sem cobrar a complexidade.

O sinal claro de que chegou a hora é o oposto: muitos serviços independentes, times que precisam implantar sem coordenar, requisitos de escala elástica e ambientes múltiplos que precisam ser idênticos. Nesse cenário, o padrão evolui naturalmente para engenharia de plataforma, com o cluster como base e uma camada de autoatendimento por cima.

Exemplo prático: uma startup de cinco pessoas migrou para Kubernetes "para estar pronta para escalar" e passou seis semanas em problemas de rede e permissões — com o mesmo tráfego de antes. Voltou para um PaaS e recuperou o ritmo de entrega em uma tarde.

Como começar com Kubernetes sem sofrer?

Um roteiro de aprendizado que evita os becos mais comuns:

1. Comece local, com um cluster descartável. kind, k3d ou minikube sobem um cluster em minutos na sua máquina. Quebre à vontade, recrie sem custo.
2. Escreva YAML na mão antes de usar Helm. Entender Deployment, Service e Ingress crus é o que torna o Helm compreensível depois — e não o contrário.
3. Aprenda a depurar antes de aprender a otimizar. kubectl describe pod, kubectl logs --previous e kubectl get events --sort-by=.lastTimestamp resolvem a maioria dos problemas reais.
4. Use um serviço gerenciado no primeiro cluster de produção. GKE, EKS ou AKS eliminam a operação do control plane, que é a parte mais difícil e menos diferenciadora.
5. Trate o cluster como código. Manifests versionados no Git, aplicados por pipeline. Alteração manual em produção é como editar arquivo direto no servidor: funciona até o dia em que ninguém lembra o que foi feito.

Exemplo prático: um time levou seu primeiro serviço a produção assim — kind na máquina por duas semanas, um Deployment escrito à mão, migração para GKE com os mesmos manifests e só então Helm para parametrizar ambientes. Nenhum incidente na estreia.

Conclusão

Kubernetes entrega uma coisa muito específica e muito valiosa: a capacidade de descrever como sua aplicação deve estar e confiar que um sistema vai manter essa descrição verdadeira, mesmo quando máquinas falham e o tráfego oscila. O preço é complexidade operacional real — rede, permissões, atualização, depuração — que só se paga quando existe escala, número de serviços ou independência entre times que justifique. Se você está começando, use um cluster local descartável para entender Pod, Deployment, Service e Ingress na mão, adote um serviço gerenciado na primeira produção e mantenha tudo versionado. E se a resposta honesta para "por que Kubernetes?" for "porque todo mundo usa", a decisão mais madura provavelmente é adiar.