A escolha de orquestração de containers define como seu time vai fazer deploy, escalar e se recuperar de falhas pelos próximos anos. Kubernetes é o padrão de mercado, mas não é a resposta automática para todo cenário. Docker Swarm e HashiCorp Nomad continuam sendo alternativas reais quando o objetivo é operar menos peças. Neste comparativo, olho para arquitetura, operação e trade-offs, sem benchmarks inventados.
O que a orquestração de containers resolve de fato
Um orquestrador transforma um conjunto de hosts em um pool de recursos. Você declara o estado desejado (imagem, réplicas, portas, limites) e o sistema reconcilia o estado real com ele. Sem orquestração de containers, o time acaba escrevendo scripts de deploy, health checks e restart que reinventam, mal, o que esses sistemas já entregam.
As responsabilidades centrais são:
- Scheduling: decidir em qual nó cada workload roda, considerando CPU, memória e restrições.
- Service discovery e balanceamento: permitir que serviços se encontrem sem IPs fixos.
- Self-healing: reiniciar ou realocar workloads quando um container ou nó falha.
- Rolling updates e rollback: trocar versões sem derrubar o serviço.
- Gestão de configuração e segredos: separar código de ambiente.
Kubernetes: poder, ecossistema e custo operacional
O Kubernetes separa um control plane (kube-apiserver, etcd, scheduler e controller manager) dos nós de trabalho, que rodam o kubelet e um container runtime compatível com CRI, como containerd. A rede é delegada a plugins CNI e o armazenamento a drivers CSI. Essa modularidade explica tanto a flexibilidade quanto a complexidade.
Em orquestração de containers, o Kubernetes se destaca por:
- API declarativa e extensível via CRDs e operators, que permitem automatizar bancos, filas e certificados.
- Autoscaling nativo (HPA, e VPA e cluster autoscaler via componentes adicionais).
- Ecossistema enorme: Helm, Argo CD, Prometheus, cert-manager, Ingress e Gateway API.
- Oferta madura de serviços gerenciados, que terceirizam o control plane.
Os contras são concretos. A curva de aprendizado é alta, e o número de conceitos (Pod, Deployment, Service, Ingress, PVC, RBAC, NetworkPolicy) exige disciplina. Upgrades de versão precisam de planejamento, e o etcd precisa de backup e atenção. Para uma equipe de três pessoas rodando dois serviços, o overhead pode superar o benefício.
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 3
strategy:
type: RollingUpdate
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api
spec:
containers:
- name: api
image: registry.exemplo.com/api:1.4.2
readinessProbe:
httpGet:
path: /health
port: 8080
resources:
requests:
cpu: 250m
memory: 256MiDocker Swarm: simplicidade com limites claros
O Swarm vem embutido no Docker Engine. Os nós managers formam um quorum baseado em Raft, e os workers executam tarefas. A rede overlay e o roteamento interno (routing mesh) funcionam com pouca configuração, e o formato de stack reaproveita a sintaxe do Compose. Para quem já domina Compose, a transição é curta. Se esse é seu caso, vale revisar o tutorial Docker Compose em Produção: Tutorial Passo a Passo para Times de TI antes de decidir.
docker swarm init
docker stack deploy -c compose.yml minha-stack
docker service update --image registry.exemplo.com/api:1.4.3 minha-stack_apiOs prós são setup rápido, baixo consumo de recursos e pouca superfície de operação. Os contras também pesam: ecossistema bem menor, ritmo de evolução mais lento, poucos recursos de extensibilidade e autoscaling que depende de soluções externas. Se você prevê crescimento em complexidade, o Swarm pode virar um teto.
Nomad: um scheduler generalista
O Nomad é distribuído como um único binário, com servidores que usam Raft e clientes que executam workloads. A diferença filosófica é que ele não é só de containers: via task drivers, agenda também binários isolados, aplicações Java e outros tipos de carga. Essa abordagem de orquestração de containers mais enxuta combina bem com Consul para service discovery e Vault para segredos.
Os pontos fortes são a operação simples do cluster e a capacidade de rodar cargas heterogêneas, o que ajuda em migrações graduais de legado. Os pontos de atenção: o ecossistema é muito menor que o do Kubernetes, é comum precisar combinar Nomad, Consul e Vault para chegar a um conjunto equivalente, e a mudança de licença da HashiCorp para BSL em 2023 exige análise jurídica e de política interna.
Como decidir: critérios práticos
Em vez de escolher pela popularidade, avalie a orquestração de containers pelos critérios abaixo:
- Tamanho e senioridade do time: quem vai operar o cluster às 3h da manhã?
- Diversidade de workloads: stateless simples ou bancos, jobs batch e cargas legadas?
- Dependência de ecossistema: você precisa de operators, GitOps e service mesh?
- Modelo de hospedagem: control plane gerenciado ou infraestrutura própria?
- Custo total: horas de engenharia pesam tanto quanto a fatura de infraestrutura.
Esse último ponto conecta com custo de nuvem. Um cluster superdimensionado ou mal operado pode consumir o orçamento em dólar sem entregar valor. Escrevi sobre isso em Custo de Cloud Estrangeiro: o que eu mudaria hoje para cortar até 70%.
Um caminho pragmático: times pequenos com poucos serviços começam com Compose ou Swarm; times com múltiplos serviços, requisitos de multi-tenant e necessidade de ecossistema vão de Kubernetes, preferencialmente gerenciado; ambientes heterogêneos com forte base HashiCorp consideram Nomad.
Conclusão
Não existe vencedor universal em orquestração de containers. Kubernetes entrega o ecossistema mais completo ao custo de complexidade, Swarm vence em simplicidade com limites de crescimento, e Nomad equilibra operação enxuta com flexibilidade de workloads. Defina seus requisitos, teste com um serviço real e meça o esforço operacional antes de padronizar a stack.
