Why Orchestration Is Needed
Running a handful of containers by hand with docker run does not scale: you need automatic restarts on failure, scheduling across many machines, service discovery, rolling updates, and self-healing. Orchestrators solve these problems by taking a declarative description of desired state ('run 5 replicas of this image') and continuously reconciling the actual cluster state to match it.
Cricket analogy: A club captain manually deciding every substitution and fielding position by shouting instructions ball by ball doesn't scale past one match; a proper team management system instead just states the desired lineup and formation, and staff continuously adjust the actual team to match it automatically.
Kubernetes vs Docker Swarm vs Nomad
Kubernetes is the dominant orchestrator: it has the richest ecosystem (Helm, operators, service meshes, extensive CRDs) but the steepest learning curve and operational overhead. Docker Swarm is simpler to set up (built into the Docker CLI via docker swarm init) and is a reasonable fit for small teams or simple workloads, but it has a smaller ecosystem and slower feature velocity, and its long-term community momentum has declined relative to Kubernetes. HashiCorp Nomad is a lightweight, single-binary orchestrator that can schedule not just containers but also VMs and raw binaries, and integrates well with Consul (service discovery) and Vault (secrets); it trades some of Kubernetes' ecosystem depth for operational simplicity.
Cricket analogy: The IPL (Kubernetes) has the richest ecosystem — auctions, franchises, broadcasters — but running a franchise takes serious operational effort; a local club league (Docker Swarm) is far simpler to set up and fine for casual teams, though its scale keeps shrinking; a lightweight regional T10 circuit (Nomad) can host cricket, football, and kabaddi under one lightweight banner.
Rule of thumb: choose Swarm for small, simple deployments where operational simplicity matters most; choose Nomad if you need to orchestrate mixed workloads (containers + non-containerized jobs) with minimal operational overhead; choose Kubernetes when you need the broadest ecosystem, autoscaling sophistication, and are willing to invest in the operational learning curve.
Self-Managed vs Managed Kubernetes
Self-managed Kubernetes (e.g. kubeadm on your own VMs, or kOps) gives full control over the control plane, networking plugins, and upgrade cadence, but the team is responsible for etcd backups, control-plane HA, and applying security patches to master nodes. Managed offerings — Amazon EKS, Google GKE, Azure AKS — run and patch the control plane for you, typically expose it via an SLA, and integrate with the cloud provider's IAM, load balancers, and storage classes, at the cost of some vendor lock-in and a per-cluster control-plane fee.
Cricket analogy: Building and maintaining your own private cricket ground gives full control over pitch conditions and scheduling, but you're responsible for groundskeeping, drainage repairs, and floodlight maintenance yourself; renting a professional stadium (managed offering) handles all that upkeep for you with a service guarantee, at the cost of booking fees and less scheduling control.
# Comparing cluster creation across managed providers (illustrative, not exhaustive)
# Amazon EKS via eksctl
eksctl create cluster \
--name prod-cluster \
--region us-east-1 \
--nodes 3 \
--node-type m5.large
# Google GKE
gcloud container clusters create prod-cluster \
--num-nodes=3 \
--machine-type=e2-standard-4 \
--region=us-central1
# Azure AKS
az aks create \
--resource-group prod-rg \
--name prod-cluster \
--node-count 3 \
--node-vm-size Standard_D4s_v3 \
--generate-ssh-keysScheduling and Self-Healing
All major orchestrators share the same core loop: a scheduler places workloads on nodes based on resource requests/limits and constraints (affinity, taints/tolerations in Kubernetes), and a controller continuously compares desired vs actual state, restarting or rescheduling failed containers automatically. In Kubernetes this is implemented by the kube-scheduler and the controller-manager watching the API server; in Swarm, the manager nodes handle scheduling; in Nomad, the servers handle it via the Nomad scheduler.
Cricket analogy: Every league's selection process shares the same core loop: a selection committee (scheduler) places players onto teams based on skill level and specific role needs (like requiring a left-arm spinner), while a team manager (controller) continuously checks the actual squad against the required XI and calls up replacements the moment someone is injured.
Do not run an even number of control-plane/manager nodes for HA (e.g. 2 or 4). etcd (Kubernetes) and Swarm's Raft consensus both require a quorum majority; an even count increases the chance of a split-brain tie during a network partition. Use 3 or 5 control-plane nodes.
Multi-Cluster and Hybrid Strategies
Larger organizations often run multiple clusters for blast-radius isolation (per region, per environment, or per compliance boundary) rather than one giant cluster. Tools like Cluster API, Karmada, or a fleet manager help provision and keep configuration consistent across clusters, while a service mesh or global load balancer routes traffic between them.
Cricket analogy: A national cricket board runs separate regional academies rather than one giant central academy, so a scandal or injury outbreak at one academy doesn't affect the others; a central curriculum office (fleet manager) keeps training standards consistent across all academies, while national selectors (global load balancer) route talent between them.
- Kubernetes has the richest ecosystem; Swarm is simplest to operate; Nomad is lightweight and supports mixed (non-container) workloads.
- Managed Kubernetes (EKS/GKE/AKS) offloads control-plane operations to the cloud provider at the cost of some lock-in and fees.
- Self-managed Kubernetes gives full control but requires the team to handle etcd backups and control-plane patching.
- Always run an odd number of control-plane/manager/server nodes (3 or 5) to maintain quorum during partitions.
- All orchestrators reconcile desired vs actual state continuously — this is what enables self-healing.
Practice what you learned
1. Why should a Kubernetes cluster typically run 3 or 5 control-plane nodes instead of 2 or 4?
2. What is a key advantage of managed Kubernetes offerings like EKS, GKE, or AKS?
3. Which orchestrator is notable for being able to schedule non-containerized workloads (VMs, raw binaries) alongside containers?
4. What is the primary trade-off of choosing Docker Swarm over Kubernetes?
5. What is the shared core mechanism behind self-healing in Kubernetes, Swarm, and Nomad?
Was this page helpful?
You May Also Like
What Is Kubernetes?
An introduction to Kubernetes as a container orchestration platform that automates deployment, scaling, and management of containerized applications.
Kubernetes Architecture
A tour of Kubernetes cluster architecture, covering control plane components and worker node components and how they interact.
Deployments and ReplicaSets
Learn how Deployments manage ReplicaSets to declaratively run, scale, and update stateless Pod replicas in Kubernetes.
Namespaces and Resource Quotas
Understand how Kubernetes Namespaces provide multi-tenant isolation and how ResourceQuotas and LimitRanges enforce fair compute usage across teams.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics