- O Docker Compose simplifica ambientes locais e testes; o Kubernetes orquestra cargas de trabalho em escala com escalonamento automático, atualizações contínuas e autorrecuperação.
- O Compose opera em um único host e com Docker; o Kubernetes suporta múltiplos ambientes de execução, clusters com vários nós e implantações em nuvem.
- O Kompose acelera a migração do Compose para o Kubernetes; ele oferece suporte a provedores, objetos alternativos e tags para otimizar os serviços.
- Casos de uso: Compose para desenvolvimento/CI; Kubernetes para produção, IoT/edge, big data/ML e cenários de nuvem híbrida/multi-cloud.
Se você trabalha com contêineres, mais cedo ou mais tarde surge a grande questão: Docker Compose ou Kubernetes? Ambas as ferramentas são usadas no ciclo de vida de aplicações conteinerizadas , mas não foram projetadas para resolver exatamente os mesmos problemas ou no mesmo contexto. Neste artigo, comparamos as duas em detalhes, com exemplos práticos, cenários reais e dicas para migrar de uma para a outra sem problemas.
Além do posicionamento tecnológico, a decisão impacta as operações diárias: tempos de implantação, escalabilidade , resiliência, segurança e custos . Ela também afeta casos de uso típicos de engenharia de dados — pipelines, bancos de dados, streaming, processamento em lote, formatos de dados e governança — onde a orquestração faz toda a diferença na produtividade.
O que são Docker e Docker Compose (e para que servem realmente)?
Quando falamos de Docker, na verdade estamos falando de um ecossistema: Docker Engine, Docker Hub, Dockerfile, Docker Compose … O engine cria e executa contêineres a partir de imagens; o Hub facilita o compartilhamento desses contêineres; e o Compose permite definir várias partes da pilha em um arquivo YAML para iniciá-las com um único comando.
O Compose foi criado para nos livrar de scripts intermináveis e comandos isolados. Com um único arquivo docker-compose.yml, você descreve serviços, redes e volumes , e coloca tudo em funcionamento com um único comando "docker compose up" (ou "docker-compose up" na versão 1). Ideal para desenvolvimento local, testes integrados, demonstrações ou ambientes de CI.
Um exemplo clássico de Compose seria este, com uma API e um banco de dados Postgres. Observe como as dependências, variáveis e portas são declaradas em um bloco legível:
version: '3.8'
services:
db:
image: postgres:latest
restart: always
environment:
- POSTGRES_USER=postgres
- POSTGRES_PASSWORD=postgres
- POSTGRES_DB=postgres
ports:
- '5432:5432'
volumes:
- db:/var/lib/postgresql/data
networks:
- mynet
my-api:
container_name: my-api
build:
context: ./
image: my-api
depends_on:
- db
ports:
- '8080:8080'
environment:
DB_HOST: db
DB_PORT: 5432
DB_USER: postgres
DB_PASSWORD: postgres
DB_NAME: postgres
networks:
- mynet
networks:
mynet:
driver: bridge
volumes:
db:
driver: localPara dimensionar manualmente no Compose, você pode usar a opção de dimensionamento do serviço. No Compose V2, é comum fazer isso com `up --scale` (na V1 havia `docker-compose scale`):
docker compose up -d --scale my-api=3Atenção às limitações: o Compose foi projetado para um único host , não realiza balanceamento de carga entre nós nem escalonamento automático, e as atualizações geralmente envolvem recriações manuais de contêineres com os comandos "build" e "up -d".
O que é Kubernetes e o que ele oferece em comparação com o Compose?
O Kubernetes (K8s) é uma plataforma de orquestração de contêineres distribuída. Ele gerencia implantações em escala em clusters de vários nós , com conceitos como Pods, Deployments e Services para operar cargas de trabalho de produção.
No Kubernetes, você não gerencia contêineres individuais; você gerencia Pods (que podem conter um ou mais contêineres). O plano de controle agenda onde cada Pod é executado , expõe serviços, distribui o tráfego, escala horizontalmente e monitora a integridade das cargas de trabalho.
Uma implantação básica poderia ser assim, com 3 réplicas de um serviço web. Defina modelos, rótulos e portas expostas :
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-deployment
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: my-web-image
ports:
- containerPort: 8000Para expô-lo com balanceamento de carga, um serviço LoadBalancer é típico na nuvem. O seletor associa os rótulos do Pod para rotear o tráfego.
apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
selector:
app: web
ports:
- protocol: TCP
port: 80
targetPort: 8000
type: LoadBalancerEm produção, o Kubernetes se destaca com recursos como automação de alto desempenho (HPA), atualizações contínuas e autorrecuperação. O HPA ajusta as réplicas com base em métricas (por exemplo, uso da CPU) :
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: web-hpa
spec:
minReplicas: 1
maxReplicas: 10
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web-deployment
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50A integridade do contêiner é monitorada por meio de sondas; se alguma delas falhar, o Kubernetes reinicia o contêiner. Essa é a base da "auto-recuperação".
apiVersion: v1
kind: Pod
metadata:
name: web-pod
spec:
containers:
- name: web
image: my-web-image
ports:
- containerPort: 8000
livenessProbe:
httpGet:
path: /healthcheck
port: 8000
initialDelaySeconds: 15
periodSeconds: 15
Principais semelhanças e diferenças (o essencial, sem rodeios)
O que elas têm em comum: trabalham com contêineres e definem implantações via YAML. Ambas as soluções são úteis para desenvolvedores e operadores , e se complementam muito bem em um fluxo de trabalho de desenvolvimento para produção.
A diferença crucial reside no escopo: o Compose é centrado no Docker e em um único host ; o Kubernetes suporta múltiplos ambientes de execução e clusters com vários nós, com integração direta em nuvens e serviços gerenciados.
Contrastes mais importantes: o Kubernetes oferece escalonamento automático, atualizações contínuas e autorrecuperação ; o Compose não. O Kubernetes abstrai com Pods; o Compose interage diretamente com contêineres Docker.
Além disso, o Kubernetes inclui Jobs e CronJobs para tarefas pontuais ou agendadas. Isso evita tarefas cron do sistema e processos adicionais em contêineres , mantendo a plataforma como o ambiente natural para definir automações.
Em ambientes locais, o Compose se destaca em termos de velocidade e simplicidade. Para escalabilidade para centenas de nós ou ambientes multicloud, o Kubernetes é a escolha lógica . O Compose pode aproveitar o Docker Swarm para implantações em vários hosts, mas sua taxa de adoção e recursos não correspondem ao ecossistema e à maturidade do Kubernetes.
Por que você precisa de orquestração (e quando cada uma se encaixa melhor)
Um bom orquestrador oferece: provisionamento e implantação unificados, inicializações agendadas, comunicação entre serviços , balanceamento de carga e segurança adicional por meio de governança extra sobre cada serviço.
O Compose aborda os conceitos básicos de forma simplificada e acessível, tornando-se uma ótima ferramenta para desenvolvimento, testes e demonstrações. No entanto, suas limitações ficam evidentes quando você precisa de vários nós, balanceamento de carga nativo e escalonamento automático , ou implantações incrementais sem tempo de inatividade.
O Kubernetes, por outro lado, é "a plataforma" quando a carga aumenta: multi-nós, escalonamento automático, alta disponibilidade e um ecossistema gigantesco , com suporte nativo na AWS, Azure, GCP e opções gerenciadas.
Casos de uso no mundo real (desenvolvimento, dados e muito mais)
O Compose se destaca em: ambientes locais reproduzíveis, testes E2E, CI/CD e treinamento . Definir toda a pilha em YAML e executá-la com um único comando elimina muito ruído.
O Kubernetes é ideal para: aplicações de produção, IoT e computação de borda, big data e aprendizado de máquina , e ambientes de nuvem híbrida/multicloud. Ele gerencia cargas de trabalho distribuídas onde latência, resiliência e observabilidade são essenciais.
Em engenharia de dados, o Kubernetes é perfeito para pipelines de streaming e em lote, bancos de dados, filas e mecanismos analíticos , com controle de recursos por pod e escalonamento automático em picos de demanda.
Se o seu projeto for pequeno e couber em um único host, o Compose dará conta do recado sem problemas. Mas quando sua base de usuários crescer e você precisar de tolerância a falhas e balanceamento de carga robustos , é hora de considerar o Kubernetes.
Redes, escalabilidade e atualizações: uma comparação prática
O Compose cria uma rede por projeto e resolve nomes por serviço. A comunicação com contêineres é trivial e segura dentro do projeto , mas o balanceamento de carga externo e a hospedagem em múltiplos servidores não são recursos nativos.
No Kubernetes, os Serviços oferecem descoberta de DNS e balanceamento de carga dentro do cluster; externamente, você pode usar LoadBalancer, NodePort ou Ingress para rotear o tráfego HTTP/S.
Escalabilidade: O Compose escala manualmente e apenas em um host. O Kubernetes escala horizontalmente com HPA e programaticamente com métricas e/ou eventos. Ele também pode crescer para mais nós se o cluster permitir.
Atualizações: No Compose, geralmente são recriações manuais. O Kubernetes realiza atualizações contínuas com controle de progresso (kubectl rollout) e a possibilidade de reverter caso algo dê errado, minimizando o impacto.
Autocura: O Compose pode reiniciar contêineres, mas não resolve falhas do host ou do ambiente de execução. O Kubernetes realoca os Pods para nós íntegros , de forma transparente para os usuários.
Produtividade do desenvolvedor e experiência operacional
O Compose é uma camada fina sobre o Docker. É rápido de aprender e seu ciclo de feedback é imediato , perfeito para iterações.
O Kubernetes adiciona novos conceitos (Pods, Deployments, Services, Ingress, ConfigMaps, PVCs, etc.). Há uma curva de aprendizado, mas em troca você ganha controle preciso sobre deployments, segurança, observabilidade e escalabilidade.
Em termos de compatibilidade, o Compose prioriza o Docker. O Kubernetes suporta diversos ambientes de execução e se integra a provedores de nuvem , o que é fundamental para empresas com estratégias multicloud ou híbridas.
Migrando do Docker Compose para o Kubernetes sem enlouquecer
Quando migrar? Quando sua aplicação deixa de ser "pequena", precisa de múltiplos nós, observabilidade, escalabilidade e alta disponibilidade , ou quando lhe solicitam implantações canary e blue/green.
Desafios típicos: mapear a rede de serviços, projetar o armazenamento com PV/PVC , separar a configuração em ConfigMaps/Secrets e revisar os padrões de integridade e prontidão de cada contêiner.
A arquitetura também precisa ser repensada: o Pod como unidade de implantação , serviços para expor endpoints e recursos por contêiner (CPU/Memória) para que o agendador possa realizar seu trabalho.
Kompose: do Compose ao K8s em poucos passos
O Kompose converte arquivos docker-compose.yml em manifestos do Kubernetes ou OpenShift. É a maneira mais direta de iniciar uma migração sem precisar reescrever todo o YAML manualmente.
Antes de começar, você precisa de um cluster Kubectl e do kubectl configurado. Recomenda-se pelo menos dois nós de trabalho (não planos de controle) se você estiver testando algo com estado. Verifique sua versão com `kubectl version`.
Instalação: O método recomendado é baixar o binário da versão mais recente do GitHub. Você também pode usar um arquivo tar.gz, o Homebrew no macOS ou o comando "go get" (esta última opção usa a versão master com as alterações em desenvolvimento).
Conversão básica: navegue até o diretório docker-compose.yml e execute :
kompose convert
kubectl apply -f <archivos-generados>O Kompose gera Deployments e Services por padrão. O log geralmente lista cada arquivo criado e, após a aplicação, você verá os Deployments e Services "criados" no cluster.
Acesso: Se você estiver usando o Minikube, poderá expor ou consultar serviços facilmente. Na nuvem, marque "LoadBalancer Ingress" para obter o endereço IP público do serviço LoadBalancer; com o NodePort, você terá uma porta aberta nos nós.
Limpeza: Ao concluir o teste, remova os recursos aplicados. Mantenha seu cluster limpo para evitar conflitos entre iterações.
Opções avançadas do Kompose (provedores, objetos e tags)
O Kompose é compatível com Kubernetes e OpenShift. Se você não especificar "--provider", ele usará o Kubernetes por padrão . Com o OpenShift, ele pode gerar DeploymentConfigs e ImageStreams, e até mesmo BuildConfigs se você usar diretivas de build.
Ele também suporta várias saídas: JSON com "-j", ReplicationControllers, DaemonSets ou Helm Charts . A flag "--replicas" permite alterar o número de réplicas nos RCs; para o Helm, ela gera a estrutura básica do chart.
As tags específicas do Kompose dentro do processo de composição influenciam a conversão. Por exemplo, você pode definir o tipo de serviço ou se um endpoint deve ser exposto por meio de um Ingress/Route.
| Rótulo | Valores |
|---|---|
| kompose.service.type | nodeport/clusterip/balanceador de carga |
| kompose.service.expose | verdadeiro / nome do host |
Detalhes a ter em conta: os nomes com “_” são convertidos em “-” (o Kubernetes não permite sublinhados) e, se um serviço utiliza volumes, a estratégia de implementação muda para “Recriar” para evitar conflitos com vários gravadores.
O Kompose suporta múltiplas versões e arquivos.
O Kompose é compatível com as versões 1, 2 e 3 do Compose (com suporte limitado para as versões 2.1 e 3.2 devido à sua natureza experimental). Se você enviar vários arquivos docker-compose de uma só vez, eles serão mesclados e os elementos em comum serão sobrescritos pelo mais recente, assim como aconteceria em uma sobrescrita.
Durante a conversão para Kubernetes, você verá mensagens como "AVISO: Compilação de chave não suportada – ignorando" caso haja chaves incompatíveis. Não se preocupe, a ferramenta continuará com o que reconhecer e deixará o restante para ajustes manuais posteriores.
Além do Kompose: Move2Kube e migração manual
Se você precisa de mais controle, existem ferramentas como o Move2Kube que analisam seu Compose e geram artefatos Kubernetes mais refinados. Elas são úteis quando você deseja adaptar padrões de negócios ou modelos da sua plataforma.
A migração manual é perfeitamente válida e quase sempre recomendada após a migração inicial. Os passos típicos incluem: converter serviços em Deployments/StatefulSets , redes em Services/Ingress e volumes em PV/PVC com classes de armazenamento.
Um exemplo mínimo de conversão de um serviço Compose para Deployment poderia ser assim: transferir portas, imagem e rótulos para o modelo Pod:
# docker-compose.yml
version: '3'
services:
web:
build: .
ports:
- '8000:8000'
depends_on:
- db
# Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-deployment
spec:
replicas: 1
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: my-web-image
ports:
- containerPort: 8000Para o estado (bancos de dados, filas), considere usar StatefulSets e PersistentVolumes. Nem tudo que foi "integrado" no Compose deve estar no mesmo Pod ; separe as responsabilidades e use Services para a comunicação entre os componentes.
Cenários de dados: streaming, em lote e governança.
Em pipelines de dados complexos, o Kubernetes se encaixa perfeitamente: Jobs para processos em lote, CronJobs para janelas de tempo , Deployments para APIs e operadores para sistemas como Kafka, Spark ou Flink.
Para streaming e bancos de dados, operadores e gráficos da comunidade facilitam a inicialização. A rede Service Mesh e o controle de recursos garantem latências e SLOs mais previsíveis em comparação com uma solução de host único.
Em termos de governança e segurança de dados, o Kubernetes oferece namespaces, políticas e controle RBAC para auditoria e separação de ambientes. Essa é uma vantagem prática em relação à abordagem local do Compose.
Boas práticas e pequenos truques operacionais
No Compose: mantenha seu YAML pequeno e modular ; use variáveis de ambiente e arquivos .env; documente as portas e dependências; e reflita no CI o que você executa localmente.
No Kubernetes: defina as solicitações/limites de CPU e memória , use sondas de prontidão/ativação, separe a configuração em ConfigMaps/Secrets e aplique estratégias de implantação apropriadas a cada serviço.
Para atualizações do Kubernetes: use `kubectl set image` e `kubectl rollout status` para monitorar o progresso e reverter a atualização caso algo dê errado. Isso evitará tempo de inatividade em produção.
Se você precisar de tarefas específicas no Compose, pode simulá-las, mas no Kubernetes é mais organizado usar CronJobs/Jobs ; você não sobrecarrega os contêineres com processos extras ou tarefas cron do host.
Perguntas frequentes rápidas para evitar confusão.
O Compose substitui o Kubernetes? Não. O Compose simplifica stacks com múltiplos contêineres em um único host; o Kubernetes orquestra em escala de cluster com alta disponibilidade.
O Compose ainda é usado? Sim, e muito. É a ferramenta ideal para desenvolvimento e teste , permitindo configurar ambientes completos com apenas alguns comandos.
O Kubernetes é "melhor" que o Docker? São coisas diferentes: o Docker é a plataforma de contêineres ; o Kubernetes os orquestra em um cluster e adiciona operações avançadas.
Posso migrar meu código Compose para o Kubernetes sem reescrevê-lo manualmente? Sim, com a integração do Kompose ou do Docker Desktop. Isso oferece um primeiro passo rápido que você pode refinar posteriormente.
Detalhes importantes: programação, OpenShift e conversões alternativas.
O Kubernetes não se limita à implantação contínua: Jobs e CronJobs abrangem tarefas pontuais ou planejadas, sem que você precise gerenciar os crons do sistema.
No OpenShift, o Kompose pode gerar DeploymentConfigs e ImageStreams, e até mesmo BuildConfigs se o Compose tiver uma build associada a um repositório Git. Os parâmetros “--build-repo” e “--build-branch” são usados para ajustar a origem.
Se você deseja uma saída diferente, o Kompose permite o uso de DaemonSets, ReplicationControllers ou Helm Charts em vez dos Deployments e Services padrão. Ele também pode gerar JSON, não apenas YAML.
Compatibilidade, avisos e problemas menores
As versões V1/V2/V3 do Compose são suportadas pelo Kompose (com limitações nas versões 2.1 e 3.2). Teclas não suportadas são ignoradas com um aviso (WARN) , permitindo ajustes manuais.
Se o seu serviço utiliza volumes, o Kompose altera a estratégia para "Recriar" para evitar concorrência no mesmo volume . Isso é normal para serviços com estado.
Os sublinhados nos nomes são convertidos em hífens. Essa é uma restrição do Kubernetes para nomes de objetos , portanto, certifique-se de nomeá-los corretamente no Compose para evitar surpresas durante a conversão.
Para acessar externamente, verifique o tipo de serviço: ClusterIP (interno), NodePort (porta nos nós) ou LoadBalancer (IP público na nuvem). Com o Ingress, você terá rotas HTTP/S limpas e TLS centralizado.
Se você testar no Minikube, comandos como “minikube service <svc> –url” retornarão uma URL rápida . Na nuvem, observe o campo “LoadBalancer Ingress” ao descrever o serviço.
Um ponto interessante: dentro da comunidade, você encontrará referências a salários para profissionais de Kubernetes e taxas de adoção próximas a 88% em ambientes de produção. Nada de incomum: é o padrão de fato.
Para completar o quadro, o Kubernetes oferece mais do que apenas HTTP: Service Mesh, operadores e CRDs ampliam o alcance do Kubernetes. Se você vem do Compose, é normal se sentir um pouco sobrecarregado no início, mas esse poder extra se traduz em operações mais robustas.
Redefinir políticas: equivalências úteis
O Compose permite a configuração “reiniciar: sempre/em caso de falha/não”. No Kubernetes, dependendo do caso, você terá Pods ou controladores individuais (Deployments ou RC) com políticas de reinicialização apropriadas.
| docker-compose reiniciar | Objeto no K8s | política de reinicialização |
|---|---|---|
| "" / sempre | Controlador (Implantação/RC) | Sempre |
| em caso de falha | Vagem | OnFailure |
| não | Vagem | Nunca |
Se no Compose você tinha contêineres de "cálculo" ou tarefas efêmeras (como um "pi" rápido), basta implementá-las no Kubernetes como um Job ou CronJob com a política apropriada e estará tudo pronto.
Escolha o Compose para implantações locais rápidas e o Kubernetes quando seu ambiente exigir mais poder: suporte a vários nós, escalonamento automático, implantações perfeitas e verdadeira resiliência . Com o Compose, o Move2Kube e um pouco de cuidado, a transição é tranquila.
Em última análise, a escolha depende da escala e da complexidade: o Compose é uma ótima opção para desenvolvimento, testes e ambientes de host único ; o Kubernetes é a melhor escolha para empresas, implantações em várias nuvens e equipes que precisam de automação avançada, alta disponibilidade e um ecossistema com milhares de integrações.
