Como aprendi Kubernetes — e o que eu entendi errado no começo

Aprendi Kubernetes achando que era "Docker com orquestração."

Não é. Kubernetes é um sistema de reconciliação de estado desejado. Essa diferença de entendimento custou semanas de confusão.

O modelo mental errado:

"Vou dizer para o Kubernetes: rode esse container."

O modelo correto:

"Vou dizer para o Kubernetes: o estado desejado é ter 3 réplicas desse container rodando. Faça o que for necessário para chegar e manter esse estado."

A diferença parece sutil mas muda tudo na prática.

No modelo errado, você pensa em ações: "inicie isso", "pare aquilo", "reinicie aquele".

No modelo correto, você pensa em estado: "eu quero X, e você garante X — mesmo que alguma coisa caia, mesmo que o nó saia do cluster, mesmo que o container crash".

Os conceitos que ficaram quando entendi o modelo correto:

Pod — a menor unidade. Um ou mais containers que sempre rodam juntos no mesmo nó. A maioria dos casos: um container por Pod.

Deployment — declara o estado desejado para Pods. "Quero 3 réplicas do container minha-api:v2.1. Se algum cair, sobe outro."

apiVersion: apps/v1
kind: Deployment
metadata:
  name: minha-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: minha-api
  template:
    metadata:
      labels:
        app: minha-api
    spec:
      containers:
      - name: api
        image: minha-api:v2.1
        ports:
        - containerPort: 8000

Service — abstrai o acesso aos Pods. Pods têm IP efêmero (morrem e sobem com IP diferente). Service tem IP estável e balanceia entre Pods.

Namespace — separação lógica dentro do cluster. Diferente times ou ambientes (staging/prod) em namespaces separados no mesmo cluster.

O que me confundiu mais tempo: a diferença entre liveness probe e readiness probe.

Liveness: "o container está vivo?" Se não, Kubernetes mata e recria. Readiness: "o container está pronto para receber tráfego?" Se não, Kubernetes não manda tráfego para ele, mas não mata.

Por que importa: quando você faz deploy de nova versão, o novo Pod pode estar "vivo" (processo rodando) mas não "pronto" (ainda inicializando, carregando cache, conectando no banco). Sem readiness probe, Kubernetes manda tráfego durante a inicialização e o usuário recebe erro.

Com readiness probe configurado corretamente, tráfego só chega quando o Pod está realmente pronto.

Em 2021 comecei com EKS (Kubernetes na AWS) e a curva foi íngreme. Mas o modelo de estado desejado é o que tornou tudo mais claro. Quando algo não funciona, a pergunta certa não é "o que aconteceu?" mas "qual é o estado atual e por que difere do estado desejado?"

kubectl describe pod <nome> — mostra eventos e condições. kubectl get events --sort-by='.metadata.creationTimestamp' — linha do tempo do que aconteceu.

Kubernetes é verboso em diagnóstico quando você sabe onde olhar.