Kubernetes vs Docker: Stop Comparing the Wrong Things

Every few months, someone posts "Should I use Docker or Kubernetes?" — and the comment section turns into a shouting match between people who've fully automated their five-service startup and someone who just wants to run a Flask app on a VPS.

The comparison itself is the problem. Docker and Kubernetes don't occupy the same slot. Framing them as rivals is like asking whether you need a knife or a cutting board. You probably need both. The question is when and how much.

What Each Tool Actually Does

Docker packages your application and its dependencies into a container image. That's it. You run docker build, you get an image. You run docker run, a container starts. The whole pitch is that the thing running on your laptop is identical to the thing running in production.

Kubernetes takes containers that already exist and decides where, when, and how many of them run across a cluster of machines. It handles scheduling, self-healing, scaling, rolling updates, secrets, config — the full operational surface of running software at scale.

So the real question is never "Docker or Kubernetes?" It's "Do I need container orchestration? And if I do, which one?"

The Case for Just Using Docker (and Staying There)

Docker Swarm is Docker's built-in orchestration layer. docker swarm init is a single command. If you already know Docker Compose, deploying a stack with Swarm is barely a step up. Same YAML format, same mental model.

For a lot of indie projects and small SaaS products, Swarm is enough. A 2024 analysis found Swarm achieves similar response times with 40-60% lower resource consumption for clusters under 20 nodes. Someone ran 24 containers across two continents on two VPS instances totaling $166/year with zero container crashes over ten years. That's not an edge case — that's the majority of actual indie workloads.

The numbers back this up. Docker Compose and Swarm usage among working developers grew from 17% to 24% between 2024 and 2025. Kubernetes dropped roughly 1% in the same period. Swarm is gaining ground among people who ship products, not manage platforms.

If your app is a handful of services, your team is small, and you don't need horizontal pod autoscaling or custom resource definitions — Swarm will handle it without demanding a dedicated DevOps engineer to maintain the cluster.

When Kubernetes Actually Makes Sense

Kubernetes is the right choice once you have real operational complexity. Not anticipated complexity. Real complexity that already exists.

Specifically:

• You need autoscaling. Kubernetes has a Horizontal Pod Autoscaler that adjusts replica counts based on CPU, memory, or custom metrics. Swarm can scale, but it's manual or scripted. If your traffic spikes unpredictably and you're paying for idle capacity, HPA pays for itself.
• You're running on managed cloud. EKS on AWS, GKE on Google Cloud, AKS on Azure — these abstract away the control plane entirely. You pay for it, but you're not running etcd yourself. At that point, Kubernetes gets much easier to justify.
• You have multiple teams deploying into the same cluster. Kubernetes namespaces, RBAC, and network policies give you proper multi-tenancy. Swarm doesn't have a namespace concept.
• You need operators and CRDs. Complex stateful systems like databases (Postgres Operator, MongoDB Operator) or message queues benefit from Kubernetes operators that codify operational runbooks into controllers. That kind of extensibility doesn't exist in Swarm.

Kubernetes owns about 92% of the container orchestration market. But 91% of its users are organizations with 1,000+ employees. The mismatch between who Kubernetes is built for and who adopts it because it's the "industry standard" is real.

A Practical Decision Framework

Here's how I actually think about it: Are you running containers on more than 3 nodes?

• No → Docker + Docker Compose. Done.
• Yes → Do you need autoscaling, multi-tenancy, or advanced networking?
• No → Docker Swarm.
• Yes → Kubernetes (managed if possible).

The nuance is in that middle tier. Docker Swarm is a legitimate production choice — not a stepping stone, not "Docker for people who don't know Kubernetes." Mirantis committed to Swarm support through at least 2030. It's in active use across defense, manufacturing, and financial services. It is not dead.

The complexity tax Kubernetes charges is real. You need to learn kubectl, YAML manifests that look nothing like Compose files, namespaces, ingress controllers, storage classes, and how to think in terms of Pods, ReplicaSets, and Deployments instead of just "a service running somewhere." That's a legitimate cost. Don't pay it until you have to.

How Docker and Kubernetes Work Together

When you do move to Kubernetes, Docker doesn't leave the picture. It's still your build tool. You write a Dockerfile, build an image, push it to a registry (Docker Hub, ECR, GCR), and Kubernetes pulls it when scheduling pods. The workflow is:

# Build and push
docker build -t myapp:v1.2.0 .
docker push registry.example.com/myapp:v1.2.0

# Deploy to Kubernetes
kubectl set image deployment/myapp container=registry.example.com/myapp:v1.2.0

Kubernetes doesn't build images. It runs them. Docker (or more precisely, containerd which Kubernetes uses under the hood) handles the actual container runtime. The two aren't in competition — they're in sequence.

My Take

The framing of "Kubernetes vs Docker" has done real damage to how developers think about deployment. It pushes people toward Kubernetes before they need it, because it sounds more professional. That's backwards.

Start with the simplest thing that works. Docker Compose on a single server is genuinely fine until you outgrow it. Swarm is fine until you need autoscaling or multi-tenancy. Kubernetes is the right choice for the specific set of problems it solves — but those problems don't exist at every scale.

Most indie makers and early SaaS products will never need Kubernetes. The ones that do will know it clearly when they get there, because Swarm will start breaking under specific, identifiable pressure. That's the right time to migrate.

Don't pay the complexity tax early. Build something people use first.