Docker vs Kubernetes

Docker takes your application, its libraries, its runtime and its configuration, and produces an image: a specific, addressable artefact that behaves the same on a laptop, on a build runner and on a server. It will then run containers from that image on the machine you asked. That is a genuinely large amount of value, and for most teams it removes an entire category of problems on the first day, which is why containerisation is close to universal now regardless of what anybody runs on top.

What Docker does not do is decide which machine a container should run on, notice that a machine has died and start the workload somewhere else, roll a new version out gradually while watching health checks and stop if something looks wrong, give a service a stable network identity while individual replicas come and go, or balance traffic across instances. Every one of those is a fleet concern. When a team tries to cover that ground with Docker alone, the result is recognisable: a set of shell scripts, a cron job, an undocumented convention about which server runs what, and an arrangement that works right up until the evening a host disappears and nobody has ever tested what happens next.

Kubernetes exists precisely to cover that ground, and it does it through one idea applied consistently: you declare the state you want, and control loops work continuously to make reality match. You do not instruct it to restart something, you change what should be true and controllers close the gap. That is why a manual change to a running resource is quietly reverted and why deleting a pod produces a new one. Once that model lands, the platform is predictable. Until it does, it feels capricious, and that gap is where a great deal of early Kubernetes frustration lives.

The point of drawing the boundary this precisely is that it shows the two things are complementary rather than competing. Kubernetes runs images. Docker builds them. The quality of the image determines how well the orchestration layer behaves, and most orchestration pain we are called in to diagnose traces back to an image that was never designed to be orchestrated: bloated so every pull and every scale-up event is slow, with a health check that reports success before the application is ready, or started through a shell wrapper that swallows the termination signal so the process is killed abruptly with requests in flight. Those are Docker-layer problems presenting as Kubernetes problems.

The reason this comparison misleads people is that it presents two options when there are at least five, and the useful ones sit between them. Naming them concretely is the most valuable thing this page can do, because most teams considering Kubernetes have never seriously evaluated the alternatives and assume the choice is a cluster or chaos.

The simplest is a single well-provisioned host running Docker Compose, with a process supervisor to bring things back after a reboot, resource limits so containers do not starve each other, and backups that somebody has tested by restoring from them. This is a legitimate production architecture for a small internal system or an early product, and it is considerably more reliable than the same system spread across infrastructure nobody understands. Its honest limits are that a host failure is downtime and a deployment is a brief interruption unless you put effort into it, so it suits systems where those are acceptable and it stops suiting them the moment they are not.

The next step up, and the one that fits the largest number of teams, is a managed container service. Amazon ECS with Fargate, Google Cloud Run and Azure Container Apps all take an image and handle scheduling, health checking, scaling, rolling deployments and load balancing, without you operating a control plane, upgrading nodes, maintaining add-ons or learning a large vocabulary of objects. You get most of what teams actually want from Kubernetes and you skip nearly all of the standing operational cost. We recommend this more often than any other answer in this area, and it is consistently the option that surprises teams who arrived expecting a cluster.

Further along, a platform-as-a-service such as Render, Fly.io or Vercel takes your code rather than your image and handles more still, which suits teams who want to think about infrastructure as little as possible. It gives up some control in exchange, and for a product team shipping a conventional application that is frequently a good trade.

Only past all of that does a cluster start to earn its place, and when it does the recommendation is nearly always a managed control plane, EKS, GKE or AKS, rather than running the API server and etcd yourself. That removes a category of thankless, high-consequence work while leaving you with workloads, networking, security, storage, upgrades above the control plane and cost, which is more than enough to be getting on with.

The reason to walk the ladder deliberately is that each rung costs more to operate than the one below it, permanently, and the increment is paid whether or not you are using the capability it buys. Pick the lowest rung that meets your requirements, and be honest that "we might need more later" is not a requirement. You can move up a rung later, and because the image is the same artefact at every level, moving up is a smaller piece of work than it sounds.

It is worth being precise about what makes Kubernetes the right answer, because the usual justifications are vaguer than they should be and vagueness is how teams talk themselves into it. There are five conditions we look for, and the strongest signal is several of them holding at once rather than one holding loosely.

The first is service count with independent release. Not how much traffic you serve, and not how many repositories you have, but how many services genuinely need to be deployed, scaled and rolled back independently of each other by different people. Dozens of them, released on their own schedules, is the canonical case, because at that point the alternative to Kubernetes is not simplicity, it is a growing collection of bespoke deployment scripts that only their authors understand. Replacing that with one declarative model everyone can read is where the complexity starts paying for itself.

The second is multiple teams sharing infrastructure. When several teams ship onto the same platform, you need boundaries that hold: namespaces with quotas so one team cannot consume everything, role-based access so identities reach only what they should, network policy so a compromised workload cannot explore freely, and admission policy enforcing standards centrally rather than by convention. Kubernetes has genuinely strong primitives for this, and building the equivalent yourself is a large project. If you are one team, none of this applies to you.

The third is a real portability requirement. The same manifests running on managed Kubernetes at any of the major providers, on OpenShift and on hardware in your own building is a capability nothing simpler offers, and for organisations with a residency obligation, a regulator, an acquisition to absorb or a customer contract specifying where things run, it is the strongest single argument available. The word doing the work is real. Portability as insurance against a hypothetical future is not the same thing, and it is usually a way of paying now for an option nobody exercises.

The fourth is workload shape. Bursty and batch-heavy work fits Kubernetes well: jobs and cron jobs, custom autoscaling metrics such as queue depth rather than CPU, and node pools that scale to zero so idle capacity costs almost nothing. If your system needs a hundred pods for twenty minutes a day and nothing otherwise, that shape is handled better here than by most simpler platforms and it can be substantially cheaper than keeping capacity warm.

The fifth is ownership, and it is the one that vetoes everything else. Somebody must own the platform as their job. If the honest answer to "who runs this" is that the busiest engineer will look after it alongside their other work, the answer to the whole question is no, regardless of how well the first four conditions fit. An unowned cluster is not a neutral outcome, it is a liability that accumulates quietly and presents its bill during your first serious incident.

Docker has a modest standing cost and it is mostly build-side. Somebody owns the registry and its credentials, keeps base images current on a rebuild cadence because an image that was clean when it was built is not clean months later, maintains the build pipeline and its caching, and watches image size because every megabyte is pulled on every deployment and every scale-up event. For larger organisations there is also Docker Desktop licensing to be aware of, which is a procurement question rather than a technical one but catches teams by surprise often enough to mention. None of this is a full-time role, and it is work you will do regardless of what runs your containers.

A managed container service adds a modest amount on top: the platform’s own configuration model, its scaling and health check behaviour, and its integration with networking and identity. There is a learning curve and it is measured in days rather than months, because the surface you are exposed to is deliberately small. You do not upgrade a control plane, you do not maintain add-ons, and you are not exposed to deprecated APIs breaking your configuration between releases.

Kubernetes adds a permanent engineering commitment, and this is the honest centre of the comparison. Control plane and node upgrades arrive on a cycle you do not control. Deprecated APIs break manifests between versions, so upgrades are a real piece of work rather than a button. Every ecosystem add-on you install, ingress controller, secrets integration, observability stack, delivery tooling, has its own release cadence and its own upgrade path. Security policy has to be maintained rather than configured once, because the defaults are permissive by design. Resource requests drift from reality unless somebody revisits them. And somebody has to be on call who understands the networking well enough to diagnose why a pod will not schedule at an inconvenient hour.

The compute bill deserves a mention too, though it is rarely the dominant number. Clusters are almost always over-provisioned, because resource requests are set generously when a service is new and never revisited, so the scheduler reserves capacity that nothing uses across every replica of every service. Correcting that is usually the largest single cost improvement available in an inherited cluster and it is straightforward once there is data. But the dominant cost across the life of the system is human, and it does not decrease once the platform is built. That is the number to put in the comparison when you are weighing a cluster against a managed service, and it is the one most often left out.

Because the image is the contract between the build and whatever runtime you choose, it is worth stating what a good one looks like. This applies identically whether you end up on a single host, a managed container service or a cluster, which is another reason the packaging decision is safe to make before the runtime decision.

Use a multi-stage build so the final image contains the application artefact and nothing else: no compilers, no package manager, no build caches, no source. Choose the base deliberately and pin it to a digest rather than a mutable tag, so a build is reproducible and the base cannot shift under you between two builds of the same commit. Order the instructions so the layer cache actually works, which usually means installing dependencies from a lockfile before copying the source. Keep a strict ignore file so a large local directory is not sent to the build context on every run.

Then harden it, because the defaults do not. Run as a non-root user. Mount the root filesystem read-only and give the process a writable volume only where it genuinely needs one. Drop the Linux capabilities the workload does not use. Never pass a secret as a build argument or copy one into a layer, because it stays in the image history permanently and rebuilding without it does not remove it from images already distributed. Scan in the pipeline so a known critical vulnerability fails the build, and rebuild on a cadence rather than waiting for an audit.

And make it well behaved at runtime, because this is where orchestration problems are actually born. Give it a health check that reflects whether the application can serve traffic rather than whether a process exists, and distinguish readiness from liveness so a slow start is not mistaken for a failure. Make sure the process receives the termination signal rather than a shell wrapper swallowing it, and drain in-flight requests before exiting. Keep the image small, because pull time is deployment latency and it is scale-up latency too. Get these right and any runtime you choose will do its job easily. Get them wrong and you will spend your first months blaming the orchestrator for problems the image created.

Going from Docker on a host to a managed container service is usually the easiest move in this whole area, and it is the one we recommend most often. The image is already the artefact, so the work is defining the service in the platform’s model, moving configuration and secrets to the platform’s mechanisms, putting a load balancer in front, sorting out networking and identity, and pointing traffic at it. The thing that most often needs fixing first is state: anything written to a container filesystem or a local volume has to move to object storage or a managed database, because the platform will replace your containers whenever it likes. That is a healthy piece of work to do at this point rather than later.

Going from a managed container service or a single host to Kubernetes is a bigger step and it should be taken incrementally. Establish the platform before anybody deploys onto it: managed control plane, node pools, default-deny network policy, role-based access federated to your identity provider, external secrets, admission policy, delivery through a repository as the source of truth, and observability wired in before the first real workload lands. Then move services one at a time, stateless first, shifting traffic gradually with a route back at every step. Resource requests, health checks and shutdown behaviour get corrected as each workload arrives rather than in a tidy-up phase that never happens. Stateful systems are designed deliberately or, more often, pointed at managed data services outside the cluster.

The mistake to avoid is a big-bang cutover onto a platform your team has not operated. The point at which people learn Kubernetes should not be the point at which production traffic depends on it, and teams that go live on day one start learning during their first incident, which is the most expensive classroom available.

Moving down the ladder happens more than people admit, and it is not a failure. An inherited cluster running three services that would be happier and cheaper on a managed container service is a common finding. The move is mostly a simplification: take the same images, express the workloads in the target platform’s model, move secrets and configuration, replicate the networking and ingress arrangement, migrate anything stateful to a managed service, run both in parallel and shift traffic. The genuine work is usually in untangling cluster-specific dependencies that accumulated quietly, in-cluster service discovery patterns, sidecars, custom resources, and anything relying on cluster-internal networking. Budget for discovering those rather than assuming an inventory exists.

One honest note before any of this. If you are considering a move because deployments are painful or unreliable, find out where the pain actually comes from first. A surprising share of it lives in the image and the pipeline rather than in the runtime: slow builds from poor layer ordering, large images that take an age to pull, health checks that lie, processes that ignore the termination signal and drop requests on every deployment. Those problems follow you to a new platform, and fixing them is a fraction of the cost of a migration. If deployment speed and reliability are the problem you are solving, look at your build and your image before you look at your orchestrator.