Do Docker Compose ao Kubernetes — a migração que não precisa ser dolorosa

A maioria dos guias «migre do Compose para o Kubernetes» pula a pergunta de se você deveria — e depois estraga o como. Eles dizem para você rodar kompose convert, empurrar o YAML para o cluster e considerar feito.

A migração de verdade cobre quatro preocupações: quando migrar, o que migrar primeiro, o que não traduz de forma limpa, e como escalonar o cutover.

Você deveria migrar afinal? Nem sempre. Uma stack Compose de cinco serviços em uma VM robusta, implantada via SSH e um git pull, sobreviverá à maioria dos clusters Kubernetes por um décimo do custo operacional. Migre quando precisar de autoscaling que o Compose não consegue prover, controle de acesso mais fino entre serviços, ou uma frota além de ~3 nós.

O que traduz limpo — e o que não traduz

# Mapeamento Compose → Kubernetes
services      → Deployment / StatefulSet
ports         → Service (ClusterIP / LoadBalancer)
depends_on    → Init containers + readiness probes
volumes       → PVC + storageClass
healthcheck   → livenessProbe + readinessProbe

Os 20 % que precisam de repensar: depends_on: service_healthy (sua app precisa de lógica de retry no startup), volumes compartilhados entre replicas (a maioria do storage de blocos em nuvem é ReadWriteOnce) e network_mode: host.

O artigo completo cobre:

• O plano de migração em quatro estágios (lift-and-shift → paridade → cutover → ganhar os features do K8s)
• Padrões de depends_on e a lógica de retry da app que os corrige
• A dor do storage ReadWriteOnce e as três rotas de fuga
• O trabalho de preparação de DNS/TTL na semana antes do cutover
• Manter a stack Compose aquecida como caminho de rollback por 72 horas
• Os features que não adicionar na primeira semana (Istio, etc.)

Fale conosco se estiver prestes a encarar isso.