Kubernetes is an open source system that distributes containers across many servers, monitors them and restarts them when something fails. In Kubernetes you describe what the cluster should run, say three copies of your web shop, and the system makes sure that exactly this state comes about and stays that way. That is the core. Everything else, from scaling to rollouts without downtime, follows from this one principle.
I have worked with Kubernetes since 2017, ran several clusters in an operations team and published the book "Kubernetes: Practical Guide for Developers and DevOps Teams" with Rheinwerk Computing in 2024. Today I run production clusters for mid-sized companies and for my own website, which itself runs as a container in Kubernetes. All my articles on the topic are collected on the Kubernetes page.
This article is the entry point: the basics, a first Deployment you can follow along with, and an honest assessment of who Kubernetes is worth it for and who it is not.
What is Kubernetes and which problem does it solve?
To understand Kubernetes, it helps to look at where it comes from. According to kubernetes.io, Google has been running containerized workloads in production for more than a decade and built its own management system for that: Borg. It placed containers on servers, started them, watched them, restarted them and packed the hardware so tightly that as little computing power as possible sat idle. Kubernetes is the reimplementation of those ideas as an open source project. The first public commit dates from June 2014, and with version 1.0 Google handed the project over to the Cloud Native Computing Foundation. The post about Borg as the predecessor of Kubernetes on kubernetes.io tells that story.
Why do you need such a system at all? Because containers are lightweight and portable, but nobody tells you which server they should run on. As long as you have one application on one server, Docker is enough. As soon as you run twenty services in three copies each across five servers, you need answers to questions like: Where is there still room? Who restarts the container when it crashes? How does the web server find the database after it moved to another machine? What happens at three in the morning when a server dies?
That is exactly what container orchestration means, and Kubernetes is the tool that has won this space. In my first Kubernetes years, at a company that wanted to migrate every application to the cloud, I saw how it changes the work in operations: before, a traffic peak for the Christmas campaign needed weeks of capacity planning, afterwards it was one line in a file.
Declarative: you describe the state, Kubernetes makes it happen
The most important concept in Kubernetes is the desired state. You do not say "start container A on server 3", you say "three copies of application A should be running". Kubernetes then continuously compares the actual state with the desired state and corrects any deviation. If a server dies, the three copies are running on the remaining servers shortly after. If someone deletes a container by accident, a new one is there a few seconds later.
This way of working changes how you treat servers. In the world of classic applications, servers are pets: they have names, they get looked after and they must never die. In Kubernetes, servers are cattle with numbers: if one fails, another takes over and nobody grieves. The term for this is pets versus cattle, and it applies to the containers themselves as well. The question to ask about every application is: would a user notice if this particular container disappeared right now? If the answer is yes, the application is not ready for Kubernetes yet.
One thing to keep expectations straight: the self-healing in Kubernetes is, in the end, a very reliable off-and-on switch. A container that crashes because of a bug gets restarted and crashes again. Kubernetes keeps the system alive, but it does not fix your code.
Kubernetes basics: cluster, control plane, node, Pod
A Kubernetes cluster consists of two kinds of machines. The control plane is the brain: it accepts your descriptions, stores them and decides which container runs where. The worker nodes are the muscles: this is where the actual containers run. In my clusters on Hetzner, three control plane nodes run in three different data centers so that losing one data center does not take the cluster down. For getting started, a single machine that plays both roles at once is enough.
On top of that there is a handful of objects you really need at the beginning:
| Object |
What it is for |
One sentence to remember |
| Pod |
Smallest unit, one or more containers sharing an IP |
Kubernetes schedules and deploys Pods, not single containers |
| Deployment |
Keeps a desired number of identical Pods alive and rolls out new versions |
The object you will write yourself 90 percent of the time |
| Service |
Stable address and load balancing in front of changing Pods |
The phone number that stays the same no matter who picks up |
| Ingress |
Routes HTTP requests from outside to Services |
The reception desk with the signposts |
| ConfigMap and Secret |
Configuration and credentials kept out of the image |
Never bake passwords into an image |
In practice you do not create Pods directly but through a Deployment. The reason: a single Pod is not replaced after a node failure, a Deployment takes care of that. How the control plane components work together in detail, from the API server to the scheduler, is covered in Kubernetes architecture: the components.
A first Deployment in 19 lines
Theory is good, a manifest is better. The following Deployment describes three copies of an Nginx web server. Save it as webshop.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: webshop
spec:
replicas: 3
selector:
matchLabels:
app: webshop
template:
metadata:
labels:
app: webshop
spec:
containers:
- name: webshop
image: nginx:stable
ports:
- containerPort: 80
Read the manifest top to bottom: kind says which object you are describing. replicas: 3 is the desired state. The selector tells the Deployment which Pods belong to it, and the template is the blueprint for every single Pod, here one container with the image nginx:stable on port 80. The selector and the labels in the template have to match, otherwise Kubernetes rejects the manifest.
You bring the file into the cluster with kubectl apply. A few seconds later you see three Pods:
$ kubectl apply -f webshop.yaml
deployment.apps/webshop created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
webshop-7c9f6d5b8d-2xk4q 1/1 Running 0 12s
webshop-7c9f6d5b8d-hs7pl 1/1 Running 0 12s
webshop-7c9f6d5b8d-vq2mn 1/1 Running 0 12s
Now for the moment when Kubernetes first clicked for me. Delete one of the Pods and look again right away:
$ kubectl delete pod webshop-7c9f6d5b8d-2xk4q
pod "webshop-7c9f6d5b8d-2xk4q" deleted
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
webshop-7c9f6d5b8d-hs7pl 1/1 Running 0 2m
webshop-7c9f6d5b8d-9tqvw 1/1 Running 0 3s
webshop-7c9f6d5b8d-vq2mn 1/1 Running 0 2m
The deleted Pod is gone, a new one with a different name has appeared, and there are three again. You did not restart anything. The Deployment compared the desired state with the actual state and closed the gap. An update works the same way: you change the image in the manifest, run kubectl apply again, and Kubernetes swaps the Pods one after another without the service going down. The details on strategies and rollbacks are in the Deployment documentation.
Kubernetes vs. Docker in three sentences
Docker builds and starts containers on a single machine, Kubernetes runs containers across many machines. The two are not competitors: you build the image with Docker, Kubernetes starts Pods from it, and for that it uses a leaner container runtime such as containerd today and no longer needs Docker itself inside the cluster. For development on your laptop, Docker remains the tool of choice, for running things in production Kubernetes takes over.
If you are working with Docker Compose right now and wondering whether a cluster is the next step, I have described the distinction with examples in Kubernetes vs Docker: the difference.
When Kubernetes makes sense and when it does not
The first question I ask clients who want to introduce Kubernetes is: "What goal do you want to reach with it?" Kubernetes is a tool, not a goal. In my experience it pays off when at least two of the following points apply, and it is dead weight when none of them do.
| Kubernetes pays off when |
Kubernetes is too much when |
| Your application consists of several services that should scale independently |
You run a classic three-tier application with a small number of users |
| Failures of individual servers must stay invisible to users |
An hour of downtime hurts nobody |
| You want to release several times a week without downtime |
Releases happen every few months in a maintenance window |
| Several teams or customers each get their own stack |
There is one team and one application |
| You need cloud, your own data center or both at the same time |
The application needs a fixed IP or other server-specific quirks |
Along with its advantages, Kubernetes brings obligations: expertise you have to build or buy, ongoing costs for the control plane, which needs computing power of its own, and a changed way of working in operations. For a startup with frontend, backend and database and a handful of customers, a single server with Docker Compose or a container service from the cloud provider is usually the better choice. I say that as someone who earns his living with Kubernetes.
And when Kubernetes does fit, the question of the operating model remains. The big cloud providers offer managed Kubernetes: they run the control plane, you take care of your applications. For small teams without their own operations experience, that is usually the right path. I run my clusters myself, with k3s on Hetzner in German data centers, because for my clients data sovereignty and predictable costs matter more than a one-click setup. That is a deliberate decision with effort behind it, not the default recommendation.
Frequently asked questions
What does K8s mean?
K8s is the short form of Kubernetes: K, then eight letters, then s. The word itself comes from Greek and means helmsman, which is why the logo is a ship's wheel. Both spellings mean exactly the same system.
Is Kubernetes only for large companies?
No, but it is for companies with several services and a need for resilience. The size of the company matters less than the structure of the applications. A mid-sized company with ten services and three customer stacks benefits more than a corporation with one monolithic application.
Do I still need Docker if I use Kubernetes?
On your development machine yes, for building and testing images. In the cluster no: Kubernetes uses its own container runtime such as containerd, which runs Docker images without Docker. The image format is an open standard, which is why the two fit together.
What does Kubernetes cost?
The software is free and open source. Costs come from the servers the cluster runs on, from the control plane, which needs resources of its own, and above all from the people who build and operate it. With managed Kubernetes there is a fee from the cloud provider for the control plane, and in return a large part of the operational effort goes away.
Does Kubernetes replace a server?
No, Kubernetes needs servers. It sits as a layer on top of several machines and distributes containers across them. The difference from a classic server is that you no longer have to care which machine your application is running on right now.
Where to go next
If you want to try the Deployment from above in a cluster of your own, the fastest way is a local cluster on your computer. How to approach learning in a structured way, from the first installation to certification, is described in Learning Kubernetes. To understand what happens behind the scenes during kubectl apply, I recommend Kubernetes architecture: the components next. And if you are still torn between Compose and a cluster, Kubernetes vs Docker has the decision guide.
In full detail with all examples, from the origins at Google through stateless and stateful to the question of which companies Kubernetes is right for, this is covered in chapter 2 of my book "Kubernetes: Practical Guide for Developers and DevOps Teams" (Rheinwerk Computing). You can find all the information about the book on my Kubernetes page.
