Docker vs Kubernetes

They aren't alternatives, and this is the most misunderstood comparison in infrastructure. Docker builds container images and runs containers on one machine. Kubernetes schedules containers across many machines, restarts them when they die, and routes traffic to them. You don't choose between them — you use Docker (or another builder) to produce images, and optionally use Kubernetes to run them at scale.

The question people are actually asking is usually one of two things: "do I need Kubernetes, or is running containers on a server enough?" or "what replaced Docker Swarm?" Both are good questions with real answers, and "Docker vs Kubernetes" isn't the right frame for either.

The short version of the useful answer: most teams don't need Kubernetes. A container image running on a managed platform — Cloud Run, ECS Fargate, Fly.io, Railway, App Runner — gives you the deployment, scaling, and health-checking benefits with a fraction of the operational burden. Kubernetes earns its complexity at a scale and organizational shape that many teams adopting it haven't reached.

TL;DR

What Each One Actually Does

The same app, both ways

Kubernetes now maintains three replicas, restarts failed containers, reschedules onto a healthy node if one dies, load balances across them, and rolls out a new image version gradually. Docker built the artifact; Kubernetes runs it reliably.

The "Docker Was Removed From Kubernetes" Confusion

This caused a great deal of unnecessary alarm and is worth stating plainly.

Kubernetes stopped using the Docker daemon as its container runtime. It never stopped supporting Docker-built images, because those conform to the OCI image specification that containerd, CRI-O, and Podman all implement. Keep using Docker to build.

The Question You're Actually Asking

Do I need Kubernetes?

The honest cost of Kubernetes: a control plane to operate (or pay for), networking and ingress to understand, RBAC, resource requests and limits that are genuinely hard to tune, upgrade cycles every few months, and a body of knowledge that takes months to build. That cost is worth paying at the right scale and is a poor trade for a three-service application.

The middle ground most teams should consider

Managed container platforms are the answer for a large fraction of production workloads and are consistently under-considered. You push an image; the platform handles scaling, health checks, rolling deploys, TLS, and networking. Cloud Run scales to zero, which is transformative for low-traffic services. You give up fine-grained control and the operator ecosystem, and you get most of Kubernetes' operational benefits with none of its operational cost.

Docker Compose vs Kubernetes

A more useful comparison than the title one, because these are alternatives — for local development.

Use Compose locally regardless of what you run in production. Running Kubernetes on a developer laptop to match production is a real practice and usually costs more in friction than the parity is worth — Compose plus good dev/prod parity on the things that matter (same database version, same cache) is a better trade.

What About Docker Swarm?

Best Practices

Use Docker for building, whatever you run in production

Multi-stage builds, a non-root user, a .dockerignore, pinned base image tags, and layer ordering that puts dependency installation before source copying. The image is the artifact every platform consumes, and its quality determines build speed and attack surface. See Docker.

Use Compose for local development, always

One file, the whole stack, health-check-gated startup, and --watch for live reload. It's the highest-value five minutes of developer-experience work available on almost any project.

Consider a managed platform before Kubernetes

Cloud Run, ECS Fargate, Fly.io, App Runner, Railway, Render. Push an image, get scaling and health checks and TLS. For a large fraction of workloads this is where the evaluation should end, and it's frequently skipped because Kubernetes is the default topic of conversation.

If you adopt Kubernetes, set resource requests and limits

Requests drive scheduling; limits prevent one pod starving a node. Omitting them is the most common Kubernetes misconfiguration and produces unpredictable evictions. Note the deliberate absence of a CPU limit — CPU throttling from a limit frequently causes worse latency than the noisy-neighbour problem it prevents.

Separate readiness from liveness probes

Readiness controls whether traffic is routed to a pod; liveness controls whether it's restarted. Conflating them means a slow-starting pod gets killed during startup, in a loop. This trips up nearly everyone once.

Handle SIGTERM, and account for endpoint propagation delay

Kubernetes sends SIGTERM, then SIGKILL after the grace period. Drain in-flight requests — and add a preStop sleep, because the load balancer takes a moment to stop routing to a terminating pod. Handling SIGTERM correctly but exiting immediately still drops requests on every deploy. See The Twelve-Factor App.

Don't run your database in Kubernetes without a strong reason

Managed PostgreSQL removes backups, failover, upgrades, and tuning from your plate. Kubernetes operators for databases have improved a great deal and still represent significant operational responsibility for something where the failure mode is data loss. Stateless workloads in Kubernetes, stateful ones managed, is a defensible default.

Pin image tags; never deploy :latest

Common Mistakes

Treating them as alternatives

Adopting Kubernetes for three services

No resource requests or limits

Liveness probe doing readiness' job

latest tags in production

Running a laptop Kubernetes cluster for local dev

FAQ

Do I need Docker if I use Kubernetes?

You need a way to build images, and Docker is the most common one. Kubernetes runs images via containerd and doesn't build them. Alternatives exist — Buildpacks, Kaniko, Buildah, ko, Bazel — and Docker (or Podman) is what most people use locally. So: yes in practice, and specifically for building rather than running.

Did Kubernetes drop Docker support?

It dropped the dockershim, the adapter that let kubelet talk to the Docker daemon, in v1.24. It runs containers through containerd directly now. Images built with Docker work exactly as before, because container images are an OCI standard. Nothing you need to change.

What's the simplest way to run containers in production?

A managed container platform. Google Cloud Run if you want scale-to-zero and request-based billing. AWS ECS on Fargate if you're on AWS and want no cluster to manage. Fly.io for global distribution with a very good developer experience. Railway or Render for the least configuration. All of them take an image and handle scaling, health checks, rollouts, and TLS.

When is Kubernetes genuinely worth it?

When you have enough services and teams that self-service deployment with isolation becomes the constraint — commonly 15+ services or several teams needing independent deploys. Also when you need the ecosystem specifically: operators for stateful systems, custom controllers, service mesh, complex autoscaling on business metrics, or genuine multi-cloud portability. If you can't name which of those you need, you probably don't need it yet.

Is Docker Swarm still viable?

Technically it works and is still shipped. Practically, no — Kubernetes won decisively, and Swarm has minimal ecosystem, community, or vendor investment. If Kubernetes feels too complex, a managed platform is the better answer. Nomad is the remaining credible simpler orchestrator, with a much smaller ecosystem.

Docker vs Podman?

Podman is a daemonless, rootless-by-default alternative that's largely CLI-compatible with Docker (alias docker=podman works for most commands). It's the default on RHEL and Fedora, and its rootless model is a genuine security improvement. Docker has broader tooling, Docker Desktop, and Compose integration. Either builds OCI images that run anywhere; the choice is largely preference and platform.

Can I move from a managed platform to Kubernetes later?

Yes, and this is the strongest argument for starting simple. Your artifact is a container image and your configuration is environment variables — both portable. Migrating means writing Kubernetes manifests for something already containerized and already stateless, which is a bounded project. Starting on Kubernetes to avoid a hypothetical future migration is optimizing for the wrong risk.

Related Topics

References