Introdução ao Kubernetes: por que precisamos dele

1. O cenário antes do Kubernetes: desafios da orquestração manual

Antes do Kubernetes, gerenciar containers em produção era um pesadelo operacional. Imagine que você tem uma aplicação web dividida em três containers: frontend, API e banco de dados. Sem um orquestrador, cada container precisa ser iniciado manualmente, na ordem correta, e monitorado individualmente.

Os problemas surgem rapidamente:

  • Escalabilidade limitada: quando o tráfego aumenta, você precisa criar novas instâncias manualmente. Se o frontend precisa de 5 réplicas e a API de 3, você gerencia tudo na mão.
  • Balanceamento de carga inexistente: sem um serviço de descoberta, os containers morrem e nascem em IPs diferentes, quebrando a comunicação.
  • Atualizações arriscadas: fazer um deploy sem downtime exige scripts complexos. Um rollback significa parar tudo e reverter manualmente.

Docker Compose resolve parte disso para ambientes locais, mas em produção com dezenas de containers, ele não escala. Docker Swarm oferece orquestração básica, mas falta maturidade em auto-healing e service discovery avançado.

2. O que é Kubernetes e como ele resolve os problemas de containerização

Kubernetes (K8s) é uma plataforma open-source para orquestração de containers, originalmente desenvolvida pelo Google e agora mantida pela CNCF. Ele automatiza deploy, scaling e operação de containers em clusters.

Principais capacidades:

  • Auto-healing: se um container morre, o Kubernetes recria automaticamente.
  • Scaling horizontal: aumenta ou diminui réplicas baseado em CPU, memória ou métricas customizadas.
  • Service discovery: cada container recebe um DNS interno estável, mesmo que os IPs mudem.
  • Rolling updates: atualiza gradualmente sem downtime, com rollback automático em falha.

Comparado ao Docker Compose (que gerencia containers em uma única máquina) e ao Swarm (orquestração básica), o Kubernetes oferece resiliência em nível de cluster, balanceamento de carga nativo e abstrações que separam a lógica de deploy da infraestrutura.

3. Conceitos fundamentais: Pods, Services e Deployments

Pod: a menor unidade computacional

Um Pod é o menor objeto no Kubernetes. Ele encapsula um ou mais containers que compartilham rede e armazenamento. Na prática, um Pod geralmente contém um container principal e, opcionalmente, containers sidecar para logging ou proxy.

apiVersion: v1
kind: Pod
metadata:
  name: meu-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

Service: abstração para expor pods

Pods são efêmeros — morrem e nascem com IPs diferentes. O Service fornece um endpoint estável (IP e DNS) que balanceia requisições entre os pods saudáveis.

apiVersion: v1
kind: Service
metadata:
  name: meu-service
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

Deployment: gerenciamento declarativo de réplicas

O Deployment define o estado desejado: quantas réplicas, qual imagem, política de atualização. O Kubernetes garante que o estado real corresponda ao desejado.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

4. Por que Kubernetes é essencial para DevOps

Kubernetes é a base para pipelines CI/CD modernos. Com ele, o deploy se torna um evento declarativo:

GitOps: o estado do cluster é versionado no Git. Um commit altera o manifesto YAML, e um operador (como ArgoCD) sincroniza automaticamente.

Infraestrutura imutável: você nunca altera um container em execução. Sempre substitui por um novo. Isso elimina "configuration drift".

Rollback simplificado: basta aplicar a versão anterior do manifesto:

kubectl rollout undo deployment/nginx-deployment

Versionamento: cada deploy tem um histórico. Você vê quando, quem e o que mudou — essencial para auditoria e troubleshooting.

5. Kubernetes vs. Docker: não são concorrentes, são complementares

Docker é um runtime de containers. Kubernetes é um orquestrador. Eles trabalham juntos:

  • Docker cria e gerencia containers individualmente.
  • Kubernetes gerencia milhares de containers como uma frota.

Para desenvolvimento local:
- Docker Desktop inclui Kubernetes embutido (um nó).
- Minikube cria um cluster local completo para testes.

Quando usar apenas Docker:
- Aplicações monolíticas com poucos containers.
- Ambientes de desenvolvimento simples.
- Projetos pessoais ou POCs.

Quando adicionar Kubernetes:
- Múltiplos microsserviços que precisam se comunicar.
- Necessidade de escalar sob demanda.
- Ambientes de produção com requisitos de alta disponibilidade.

6. Casos práticos: cenários onde Kubernetes faz diferença

E-commerce com picos de demanda (Black Friday): sem Kubernetes, você precisa provisionar servidores extras manualmente. Com K8s, o Horizontal Pod Autoscaler (HPA) aumenta réplicas automaticamente baseado em métricas:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Microsserviços complexos: cada serviço tem seu Deployment e Service. O DNS interno do Kubernetes resolve a comunicação: api-service:8080 sempre encontra o pod correto.

Multi-cloud: você pode rodar o mesmo cluster on-premises e na nuvem (AWS, GCP, Azure). A abstração do Kubernetes torna a migração transparente.

7. Primeiros passos: o que você precisa saber para começar

Para testar localmente, instale o Minikube ou kind (Kubernetes in Docker):

# Instalar Minikube (Linux/macOS)
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

# Iniciar cluster
minikube start --cpus=2 --memory=2048

Comandos essenciais do kubectl:

# Verificar nós do cluster
kubectl get nodes

# Aplicar manifesto YAML
kubectl apply -f deployment.yaml

# Ver pods em execução
kubectl get pods -o wide

# Ver logs de um pod específico
kubectl logs <nome-do-pod>

# Expor serviço para acesso externo (temporário)
kubectl port-forward service/meu-service 8080:80

Exemplo prático completo: deploy de Nginx com 3 réplicas

Salve o manifesto abaixo como nginx-deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
  type: NodePort

Aplique e teste:

kubectl apply -f nginx-deploy.yaml
kubectl get pods
kubectl get svc
minikube service nginx-service

Você verá 3 pods rodando, balanceados pelo Service. Se um pod morrer (kubectl delete pod <nome>), o Deployment recria automaticamente. Isso é auto-healing em ação.

Conclusão

Kubernetes transformou a maneira como gerenciamos containers em produção. Ele resolve problemas reais de escalabilidade, resiliência e deploy contínuo que Docker sozinho não consegue endereçar. Para profissionais DevOps, dominar K8s não é mais opcional — é requisito fundamental para ambientes modernos.

Comece com Minikube, pratique os comandos básicos e explore os conceitos de Pods, Services e Deployments. Em pouco tempo, você entenderá por que o Kubernetes se tornou o padrão de facto para orquestração de containers.

Referências