Do You Need Kubernetes? Docker Swarm vs Kubernetes Explained

0:00Do You Need Kubernetes?

You've got an app in containers, a compose file that runs it, and three machines. And somebody — a job post, a conference talk, a colleague — says the word Kubernetes. So: do you need it? In the Docker-versus-Kubernetes video, I said Docker runs the box and Kubernetes runs the fleet. That was true. It was also missing a sentence. Because Docker has had a fleet mode built in since twenty sixteen — it's sitting inside the Docker you installed last week. You've probably heard it's dead. It isn't. And the trick it does is the exact trick I sold you as Kubernetes' big idea. It's not a free question either way. Kubernetes is a platform — something to learn, and then something to run. And the wrong no is a migration later. So this video is one question, answered honestly: when is the Docker you already have enough — and what, exactly, are you buying when it isn't? The answer isn't a verdict. It's a size.

1:06Two Swarms — The One That Died

First, the corpse. There were two things called Docker Swarm. The first was a separate tool — Classic Swarm — that bolted a cluster — a group of machines — on top of Docker. In twenty twenty-one, Docker archived it. Its own page says: no longer actively developed. That's the funeral everyone remembers — and the headline that stuck. The second is swarm mode — not a separate tool; a switch inside the engine itself. One command on the first machine, and its Docker becomes a manager — the one in charge. Docker prints the join command for you; you paste it on each of the other machines, and they join it — and that's a swarm: a handful of Docker engines that agree to act as one. And it's not a leftover. Docker's release notes from last November — engine twenty-nine — carry a list of swarm fixes, and a line about greatly improving the reliability of its networking. Docker's own docs even have a warning: don't confuse swarm mode with Classic Swarm. So when someone tells you Swarm is dead, they're half right. The Swarm that died isn't the one you have. Now — what does the one you have actually do?

2:25Swarm Mode — Three A.M., Again

Here's the sentence from last time. You never tell Kubernetes: start a container. You write down a fact you want to be true — three copies of this app exist — and Kubernetes makes the world match. Now here is swarm mode, in Docker's own words. You define the desired state of your services, and the manager constantly monitors the cluster and reconciles any differences between the actual state and your expressed desired state. Side by side, it's the same trick. In Swarm, the fact is called a service: this image, this many copies, these ports. The command is one line — docker service create, the image, replicas three — and the fact is written down. Each copy is a task, and a task is what the swarm places — one container, on one node — that's one machine. So replay three in the morning. A container dies. The manager's book says three; the world says two. Docker's docs say the orchestrator creates a new replica task that spawns a new container. No alarm, no human, no page. The same thermostat from last time — set the number you want, the machine closes the gap — in the Docker you already had. Publish a port, and every node in the swarm answers on it — even a node with no copy of the app — and routes you to one that has. That's the routing mesh, and every node is in it. Want to deploy the whole app? Docker stack deploy takes a compose file — but the older, version-three flavour, not the newest format — and deploys the lot. So if the trick is the same — what's different?

4:18Two Machine Rooms — Same Idea, Different Size

The size of the machine room. Swarm's room: some of your machines are managers, the rest are workers — and a manager is a worker too, by default. The managers keep one shared book of the whole swarm — who's in it, what services exist, what's running where. They keep that book agreed among themselves with a voting protocol called Raft, so losing one manager doesn't lose the book. Docker's rule of thumb: an odd number of managers, and at most seven. Workers just run tasks. On your three machines that's one manager and two workers — or all three as managers, if you want to lose one and keep going. That's the whole room — and every part of it is the Docker binary. Nothing extra to install. Now Kubernetes' room, from last time: a control plane — a front door, a ledger, a scheduler, a controller manager — plus an agent on every node. Same shape. A book everyone agrees on, a scheduler placing work, agents on the machines. But Kubernetes splits every job into its own component — and it's built to be extended, which its own docs list as a feature. That's not bloat. That's the point. Swarm is the idea, done small, inside a tool you had. Kubernetes is the idea, done as a platform other things get built on.

5:44The Extra Room — What It Buys

So what does the bigger room buy? Put the two feature lists side by side — Docker's for swarm mode, Kubernetes' from its overview page — and most of it matches. Both: declare the fact you want, and scale it by changing a number. Both roll out a new version a bit at a time — update the image, and the copies get swapped a few at a time instead of all at once. Both find services by name and spread traffic across the copies. Both heal: restart what fails, replace what dies. Docker's words for it: if a worker node becomes unavailable, Docker schedules that node's tasks on other nodes. Lose a whole machine, and the copies come back elsewhere. Now the lines that are only on the Kubernetes list. Scale automatically, based on CPU — Swarm scales when you change the number; Kubernetes can change it for you. Storage that mounts itself, from your cloud provider — Kubernetes asks for the disk; you don't. Batch jobs, not just long-running services. And the big one: extensibility — add features without changing Kubernetes itself. That last line is why there's a whole world built on top of it — and why the job post said Kubernetes. Swarm's list doesn't have that line. And that's the honest trade. Swarm gives you the trick, today, with what you have. Kubernetes gives you the trick plus a platform — and a platform is heavier to run than a switch.

7:22When Swarm Is Enough

So, the rule. Don't ask which is better. Ask three questions about your fleet. How big is it? Docker's docs recommend at most seven managers — that's a hint about the scale it's built for: a fleet one team runs. If yours fits in that picture — three machines, one team, one app; a side project, a small company's product — the switch you already have runs it. Who else needs to plug in? If the answer is nobody — it's your app, your compose file, your machines — Swarm is enough. If the answer is your cloud's storage, an autoscaler, a platform team that hands you a cluster, the thing from the job post — that's the extra room, and Kubernetes is what it's for. You're not choosing it; it's already been chosen. And that's fine — it means someone else is carrying the weight of the platform, not you. And — will it grow? A swarm you outgrow is a migration later — a real cost, and only you know the odds. Ten machines next year, one team — still a swarm. A second team and a second data center probably isn't. Three questions. Size, plugs, growth. That's the whole decision, and neither answer is wrong. Last time I told you Kubernetes runs the fleet. Here's the missing sentence. So does Docker — up to a size. Kubernetes is what you buy when the fleet is bigger than the tool.