Kubernetes won the container orchestration war. Docker Swarm still exists, is still maintained, and remains the simplest way to orchestrate containers. But the ecosystem, job market, and cloud providers all chose Kubernetes.
Feature comparison
| Feature | Kubernetes | Docker Swarm |
|---|---|---|
| Setup complexity | High (kubeadm, or managed) | Low (docker swarm init) |
| Learning curve | Steep (6-12 months) | Gentle (hours to days) |
| Scaling | Horizontal + vertical + cluster autoscaler | Horizontal (docker service scale) |
| Load balancing | Services + Ingress + Gateway API | Built-in routing mesh |
| Service discovery | DNS + Services | DNS (built-in) |
| Storage | PV/PVC + CSI drivers | Docker volumes |
| Networking | CNI plugins (complex, powerful) | Overlay network (simple) |
| Health checks | Liveness, readiness, startup probes | Health checks |
| Rolling updates | Deployments (fine-grained control) | docker service update |
| Secrets | Kubernetes Secrets, CSI | Docker Secrets (encrypted at rest) |
| RBAC | Full (namespace-scoped) | Limited |
| Extensibility | CRDs, operators (1,000+) | None |
| Managed offerings | EKS, GKE, AKS, DOKS, etc. | None |
| GPU scheduling | Device plugins | Not supported |
| Ecosystem | Massive (CNCF) | Minimal |
Installation
Docker Swarm
# Manager node
docker swarm init --advertise-addr 192.168.1.10
# Worker nodes
docker swarm join --token SWMTKN-1-xxx 192.168.1.10:2377
# Deploy a service
docker service create --name web --replicas 3 -p 80:80 nginx
# Scale
docker service scale web=10
# Done. That's the entire orchestrator.Kubernetes
# See the full installation guide β it takes 20+ commands
# Or use a managed service:
gcloud container clusters create my-cluster
aws eks create-cluster --name my-cluster
az aks create --name my-cluster
# Deploy
kubectl create deployment web --image=nginx --replicas=3
kubectl expose deployment web --port=80 --type=LoadBalancerWhen Docker Swarm still makes sense
Swarm is not dead. It makes sense for:
- Small teams (1-5 developers) who need basic orchestration
- Simple applications β a few services, no complex networking
- Docker Compose users β
docker stack deploy -c docker-compose.yml myapp - Resource-constrained β Swarm overhead is negligible vs Kubernetes
- No cloud β bare-metal servers where managed K8s is not available and running kubeadm is overkill
# docker-compose.yml works directly as a Swarm stack
version: "3.8"
services:
web:
image: nginx
deploy:
replicas: 3
update_config:
parallelism: 1
delay: 10s
ports:
- "80:80"
api:
image: myapi:latest
deploy:
replicas: 2
environment:
- DATABASE_URL=postgres://db:5432/appWhy Kubernetes won
- Ecosystem β 1,000+ operators, CNCF projects, every major tool supports K8s
- Cloud providers β managed Kubernetes from every provider, no managed Swarm
- Extensibility β CRDs let you extend Kubernetes for any workload
- Job market β Kubernetes skills are in demand, Swarm skills are not
- Enterprise features β RBAC, network policies, PodSecurityStandards, audit logging
- AI/ML β GPU scheduling, NVIDIA NIM, KubeFlow, Kueue
Decision guide
Choose Kubernetes when:
- You are building for production at scale
- You need managed Kubernetes (EKS, GKE, AKS)
- GPU workloads, AI/ML, or complex networking is required
- Ecosystem tools (Helm, ArgoCD, Prometheus, Istio) are part of your stack
- Your team is investing in cloud-native skills
Choose Docker Swarm when:
- Simplicity is paramount β small team, simple app
- You already use Docker Compose and want minimal orchestration
- Under 10 nodes, no complex networking or GPU needs
- You want orchestration in 5 minutes, not 5 days
- Kubernetes is genuinely overkill for your use case


