De Docker a Kubernetes: o Caminho que Todo Dev Eventualmente Descobre na Marra

A infraestrutura moderna não nasceu pronta, e muita gente esquece disso. Antes dos contêineres, vivíamos em um mundo de bastiões monolíticos, servidores "pet" que tratávamos como se fossem animais de estimação. Se desse problema, a gente cuidava, alimentava, fazia carinho, aplicava patch. A chegada do Docker virou isso de cabeça para baixo, puxando o mercado inteiro para uma cultura de "gado": se morrer, sobe outro.

Neste texto, quero te levar por essa transição, não só a parte técnica, mas o contexto, os tropeços comuns, e as decisões que moldaram como rodamos software hoje.

1. Um Pouco de História Para Entender Por Que Docker Mudou Tudo

Durante décadas, a virtualização tradicional resolveu um problema real: isolar aplicações. O problema é que ela fazia isso emulando hardware inteiro. Pesado. Lento. Ineficiente. Se você já subiu um stack em VMware ou Hyper-V, sabe do que estou falando.

A containerização veio com uma ideia mais ousada:

“E se, em vez de fingir que temos computadores diferentes, a gente apenas isolasse processos dentro do mesmo kernel?”

O Linux já tinha os ingredientes (cgroups, namespaces, chroot), mas ninguém tinha unido tudo em algo simples de usar. Quando o Docker apareceu em 2013, ele entregou essa simplicidade na bandeja: docker build, docker run, e pronto. De repente, time de dev não precisava mais brigar com "funciona na minha máquina".

E olha… até hoje tem empresa gigantesca que só descobriu Docker em 2020 pra frente. E ainda errando o básico.

2. Docker: O Jeito Moderno de Congelar o Seu Ambiente

A beleza do Docker é a imutabilidade. Um contêiner é um ambiente previamente congelado, com dependências e runtime sempre iguais. Isso elimina diferenças entre máquinas, entre staging e produção, e entre o seu notebook e o servidor.

Um Dockerfile bem feito já te salva de muitos problemas. Mas o que vemos no mundo real?

Dev copiando o projeto inteiro antes de copiar package.json
Imagens gigantes e lentas
Builds que invalidam cache à toa
latest usado como se fosse seguro

O exemplo abaixo já é o “mínimo decente” para Node.js:

FROM node:18-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

EXPOSE 3000
CMD ["npm", "start"]

Isso aqui parece básico? É. Mas a maioria das equipes ainda erra. Especialmente o cache: instalar dependências antes de copiar o código faz uma diferença absurda em builds CI/CD.

3. E Quando a Aplicação Cresce? Docker Não Orquestra Ninguém

Docker resolveu um problema. Mas criou outro: como gerenciar dezenas ou centenas de contêineres?

Quando você tem:

1 app → Docker resolve
3 serviços → ainda dá pra controlar
30 microsserviços → caos
300 serviços → você precisa de socorro

Sem orquestração, você fica manualmente:

reiniciando serviços que caem
distribuindo carga na mão
criando DNS interno no amor
dando rollback como quem reza pedindo pra não quebrar nada

Foi nesse caos que o Kubernetes brilhou.

4. Kubernetes: O Control Plane Que Virou Padrão Global

O Kubernetes (ou K8s pros íntimos) nasceu dentro do Google inspirado no Borg, o sistema que já orquestrava milhões de contêineres desde os anos 2000. Em 2014 resolveram abrir o jogo para o mundo: “tá aqui, se virem”.

A ideia central é simples:

Você diz o estado desejado; o Kubernetes garante o estado real.

Isso é o famoso modelo declarativo. E é justamente aí que muita equipe tropeça, tentando usar Kubernetes como se fosse Docker com esteroides.

As principais habilidades do K8s:

✔ Escalabilidade automática

Aumenta ou reduz réplicas baseado em métricas reais.

✔ Auto-cura (self-healing)

Contêiner caiu? Reinicia.
Node morreu? Reagenda.
Imagem bugada? Tenta rollback.

✔ Balanceamento inteligente

Nada daquela gambiarra com Nginx duplicado e regra mal escrita.

✔ Atualizações rolling

Sem downtime, isso quando não configuram errado.

E sim, ainda hoje tem time colocando replicas: 1 em produção. É inacreditável.

5. Conceitos-Chave Que Todo Dev Deveria Saber Antes de Falar “Manjo de K8s”

Aqui vai uma taxonomia rápida, sem enrolação:

Conceito	O que realmente significa (sem marketing)
Pod	Unidade mínima. Pode ter 1+ contêineres colados juntos.
Service	Endereço estável para acessar pods voláteis.
Deployment	O gerente que garante que sempre existam X réplicas.
ConfigMap	Configuração não sensível (e muita gente usa errado).
Secret	Configuração sensível, e muita gente usa pior ainda.

Tem empresa que põe senha no ConfigMap e acha que está tudo certo. Não está.

6. Infra Declarativa na Prática

Um manifesto Kubernetes expressa sua intenção. O Control Plane cuida do resto.

Exemplo direto de um Deployment simples:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app:latest
        ports:
          - containerPort: 3000
        resources:
          limits:
            memory: "128Mi"
            cpu: "500m"

O segredo aqui é entender que isso define o estado desejado.
Se um pod cair, o Kubernetes nem pergunta, ele sobe outro.

7. Ambiente Local: Onde Todo Dev Deveria Ter Começado

Se você nunca rodou MiniKube ou Kind localmente, comece amanhã.
É o jeito mais seguro de quebrar tudo sem derrubar produção.

minikube start
kubectl apply -f deployment.yaml
kubectl get pods -o wide

Entender kubectl é metade do jogo. Quem domina o CLI domina o Kubernetes.

8. Conclusão: Docker é o Tijolo, Kubernetes é o Arquitetônico

Docker padroniza e empacota.
Kubernetes orquestra e escala.

Um não substitui o outro. São peças diferentes de um quebra-cabeça maior.

E, honestamente, por mais que pareça básico, a maioria dos times ainda tropeça em práticas fundamentais: imagens enormes, deployments inseguros, ambientes sem limites de recursos, secrets expostos… tudo por falta dessa base.

Dominar Docker e Kubernetes não é opcional em 2025, é o mínimo pra trabalhar com sistemas modernos.