Kubernetes vs Docker
Docker and Kubernetes are not alternatives, so the honest answer to "which one?" is usually "both, or only Docker". Docker builds container images and runs containers on one host. Kubernetes schedules containers across many hosts and keeps them running when one of those hosts fails. The question underneath is whether you need orchestration at all, and if you do, who runs it.
Two tools at two layers
| Docker | Kubernetes | |
|---|---|---|
| What it does | Builds images, runs containers on the machine it is installed on | Places containers on a cluster of machines and keeps the desired state |
| Scope | One host | Many hosts |
| When a host fails | Its containers stop until the host is back | Workloads are rescheduled on the remaining nodes |
| Updates | You stop and start containers, or script it | Rolling updates and rollbacks are built in |
| Typical file | Dockerfile, compose.yaml |
Deployments, Services, Gateway API routes |
| What you operate | A server and its Docker engine | A control plane, nodes, networking, ingress, storage |
The images are the same on both sides. An image built with docker build works with every container runtime Kubernetes supports, and Kubernetes runs it unchanged. Version 1.24 removed dockershim, the adapter Kubernetes used to have built in for talking to Docker Engine. Clusters now run a runtime such as containerd or CRI-O, and a cluster that still needs Docker Engine connects to it through cri-dockerd, an adapter Mirantis and Docker maintain. None of this changed the images people build with Docker.
If you are comparing Docker's own orchestrator with Kubernetes, that is Docker Swarm, and it is a different question from this one.
When you may not need Kubernetes
If your application is one container, or a handful of them in a compose.yaml, on one server, and a few minutes of downtime while that server restarts is acceptable, you may not need Kubernetes. Docker with a restart policy, a backup of the volumes and a tested way to rebuild the host covers that case with far less to operate.
Since 2021, VSHN works Kubernetes first, not Kubernetes only. Kubernetes is the default where a workload needs what it does, and a single host stays the right answer where it does not.
Kubernetes starts to pay for itself when one of these is true:
- One host is a single point of failure you cannot accept. Rescheduling onto other nodes is what Kubernetes does that Docker on one machine cannot.
- You deploy often and cannot take the service down to do it. Rolling updates and rollbacks are part of the API.
- Several teams or many services share the infrastructure. Namespaces, RBAC and resource quotas give each one its own space on the same cluster.
- You want to move between providers. The same manifests run on a Swiss cloud, a hyperscaler and your own hardware.
The decision you actually have: run Kubernetes yourself, or have it operated for you
Once you need Kubernetes, the next question is who runs it. The Kubernetes project maintains only the three most recent minor versions and patches each for about a year, so a cluster needs a version upgrade at least once a year just to stay supported. Each upgrade has to be checked against the node operating system, the network plugin, the ingress controller and the storage layer, which have their own release cycles. Add OS patching, certificate rotation, etcd backups and someone who answers when a node goes down, and you have a platform team's job, not a side task.
Running it yourself makes sense when that team exists and Kubernetes operations are part of what it is there to do.
With VSHN Managed Kubernetes, the platform is operated for you on one standardized stack: Talos Linux as the immutable OS, Cilium for networking, the Gateway API for ingress and Rook / Ceph for storage, managed through Cluster API on Cloudscale in Switzerland. VSHN runs the Kubernetes version upgrades on a defined maintenance schedule, the Talos updates and the core components. As with any platform you do not operate yourself, your applications stay yours: their compatibility with each Kubernetes and OS update, their scaling and their configuration. If you want that covered too, Application Operations adds it. The service runs during business hours with reactive support.
How the options compare in detail, from do-it-yourself to a cloud provider's control plane to enterprise OpenShift, is on the comparison page.
Next step
Managed Kubernetes is in development. If you are deciding between a single host and a cluster, or between running Kubernetes yourself and having it run, register your interest and tell us what you run today. We will tell you which side of that line your workloads are on.