Orquestração de containers: Kubernetes, Swarm ou Nomad?

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: 256Mi

Docker 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_api

Os 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.