</>DevOps101
LearnTemplatesToolsBlog
Back to Lessons
Intermediate 30 min

Container Orchestration 101

From Docker Compose to Kubernetes - when to use what, and how to orchestrate without over-engineering.

“Docker Compose is for when you have 3 services. Kubernetes is for when you have 3 services and want 17 more problems.”

What you'll learn

Docker ComposeSwarm vs K8sService discoveryScaling

The question is not 'Kubernetes or nothing'

Orchestration is how you say what should be running, how many, and what happens when a process dies. Docker Compose does that on one host. Swarm does it with less ceremony than Kubernetes and less of the ecosystem. Kubernetes does it when you have enough services, enough people, and enough failure modes to justify a control plane.

Three services on one VM do not become more reliable because you added etcd. They become a second job.

Compose: the honest default

Compose YAML is a service list with opinions about networks and volumes. depends_on does not mean 'wait until healthy' unless you also write a healthcheck and a condition. Most 'it crashed on boot' stories are a web process racing a database that is still running migrations.

Use Compose for local dev, for a single-host edge box, and for anything you can explain on a whiteboard in two minutes. Promote the same service shapes later. Do not invent a parallel universe of names.

Swarm vs Kubernetes, without the brand war

Swarm is still a thing. It is also not where the industry put its documentation, hiring, and managed-service money. If you already run Swarm and it is quiet, do not migrate for a conference talk. If you are starting now and you will need autoscaling, rolling updates with surge, and a marketplace of operators, you are looking at Kubernetes — or a platform that hides it.

The 'vs' is not moral. It is operational cost. Kubernetes gives you primitives. It also gives you a weekly puzzle about CNI, storage classes, and why a Service has no Endpoints.

Service discovery is just DNS until it is not

On Compose, the service name resolves. On Kubernetes, a Service selects Pods by labels and publishes a stable virtual IP. Clients should call the Service, not a Pod IP. Pod IPs are rental cars.

If two services cannot find each other, check labels before you check the mesh. A Service with the wrong selector is a very confident black hole. kubectl get endpoints is the adult conversation.

Scaling is a number with consequences

replicas: 3 is easy to type. It assumes the app is safe to run three times: no sticky local disk, no 'exactly one migrator', no in-memory sessions you pretended were a cache. Horizontal scale without a readiness probe is how you route traffic to a process that is still loading a 400MB JVM.

Scale the bottleneck you measured. Scaling the frontend because the database is sad just gives you a larger crowd at the same locked door.

When to stop orchestrating and start deleting

If your Compose file is a novel, split it or admit you outgrew one host. If your Kubernetes manifests exist to run a cron and a blog, a managed container service or a single VM will return hours to the team.

Orchestration should make the desired state obvious. If nobody can say the desired state out loud, the YAML is not helping. It is hiding.