What Is Kubernetes? A Guide From a Team That Runs It in Production

Most articles explaining Kubernetes stop in the same place: the definition, the architecture, a few kubectl commands, a list of benefits. That is useful and incomplete, because the two questions we actually get asked in client meetings are elsewhere: what does it cost, and do we really need it.

We run Kubernetes in production: a fleet of Go microservices on GKE, with Traefik and Cloud SQL. We have also moved workloads off Kubernetes because it was the wrong tool for them, and we have the numbers. This covers the fundamentals, then the two parts almost nobody writes.

Contents

• What is Kubernetes?
• What is the role of Kubernetes?
• What is the difference between Kubernetes and Docker?
• What is Kubernetes actually used for?
• How much does a Kubernetes cluster cost?
• When Kubernetes is the wrong choice
• Where to actually start

---

What is Kubernetes?

Kubernetes is a container orchestrator. You describe the desired state of your application: which image, how many replicas, what memory and CPU limits, how it is reached from outside. It then keeps that state true.

That last part is what separates it from a deployment script. Kubernetes does not deploy and stop. It continuously compares actual state to declared state and closes the gap. A container that crashes is restarted. A machine that vanishes has its containers placed elsewhere. A new version replaces the old one replica at a time.

This is usually summarised as "declarative", which is accurate but abstract. The concrete version is more useful: you describe the outcome, not the steps, and you accept that the system makes placement decisions on your behalf.

What is the role of Kubernetes?

Its role is to make a fleet of machines interchangeable. Without an orchestrator, a service lives on one specific server, and that server becomes precious: you know which machine runs what, you back it up, you avoid touching it. With an orchestrator, machines become a pool of capacity, and which one hosts what stops being interesting information.

Concretely it takes on four things you would otherwise write yourself:

• Placement. Choosing which machine has enough free capacity for a container.
• Healing. Restarting what dies, replacing what stops answering health probes.
• Internal networking. Giving a stable name to a service whose replicas come and go.
• Progressive rollout. Replacing one version with another without downtime, and rolling back when the new one fails.

These are real problems. The question is not whether they exist, but whether you have enough of them to justify operating a cluster.

What is the difference between Kubernetes and Docker?

This is the most common confusion, and it comes from the two words always appearing together. They are not competitors, they are stacked.

Docker builds and runs a container on one machine. You write a Dockerfile, you get an image, you run it.

Kubernetes decides where that container runs, in how many copies, and what happens when the machine dies. It does not build images and does not run them directly.

One technical detail many articles get wrong: Kubernetes has not used the Docker engine internally since version 1.24. It talks to containerd through a standard interface. This changes nothing for you, because the image format is standardised, so images built with Docker still work. But "Kubernetes uses Docker" is now false, and it is the kind of detail that gives away a copied article.

The useful mental model: Docker is the shipping container, Kubernetes is the port deciding where each one gets unloaded.

What is Kubernetes actually used for?

The cases where it earns its place share one trait: several services, and load steady enough that the machines are on anyway.

For us that means a fleet of Go microservices talking over gRPC, fronted by Traefik, with managed PostgreSQL behind. There are dozens of services, they ship several times a week, each has its own secrets and resource limits, and traffic never drops to zero. That is the nominal case.

It also serves something less discussed and very useful day to day: standardising how a service declares its secrets, health probes and resources, so the tenth service deploys like the first. A good part of the value of Kubernetes is not technical but organisational. It imposes a common shape.

How much does a Kubernetes cluster cost?

Almost no article answers this, though it comes up every time. Here is the real cost structure.

The control plane (the part the provider manages) costs little: on the order of tens of euros per month per cluster with the major providers, sometimes free on a first cluster. It is never the painful line.

Machines cost money, and idle machines cost exactly as much as busy ones. That is where the bill is decided, and it is independent of Kubernetes: a node that is on gets billed whether it works or not. Kubernetes does not make this worse, but it does make it easy to ignore, precisely because it hides the machines behind an abstraction.

Two measured numbers from our own workloads:

The diarization service became twenty-five times cheaper off Kubernetes. Not because Kubernetes is expensive, but because both workloads were bursty: traffic during business hours, near nothing overnight. We were paying for permanent capacity to serve intermittent demand.

So the right cost question is not "what does Kubernetes cost" but "what is my utilisation rate". If your machines are busy, Kubernetes is an excellent way to keep them full. If they are waiting, you are paying for idle capacity with an abstraction layer on top.

When Kubernetes is the wrong choice

We moved both compute services from GKE to Cloud Run, and we would do it again. The cases where Kubernetes is the wrong tool, based on that:

Bursty load with quiet periods. This was us. A model that works two hours a day does not need a node on for twenty-four. Serverless scales to zero and you pay per use. The price is cold starts: about 30 seconds for our GPU service, about 10 seconds for the CPU one. For asynchronous voice-message processing that is painless. For an interactive API it would be unacceptable.

One service, modest traffic. Operating a cluster for a single application means adding a discipline (running the cluster) to solve a problem you do not have yet. A managed platform does the same job without that discipline.

No team to operate it. Kubernetes moves complexity, it does not remove it. Misconfigured health probes, memory limits set too low, regional quotas: these are problems someone has to be able to diagnose. We lost time on exactly those three. If nobody on the team wants that responsibility, the cluster becomes debt.

A hard regional constraint. Not specific to Kubernetes, but hardware availability sometimes decides your architecture before you do. L4 GPUs were not available in the Paris region for the service we wanted there, which forced us to deploy in Belgium and bridge the two networks. Check availability before designing, not after.

None of this says Kubernetes is a bad tool. Our main platform runs on it. It says it solves a specific problem, and you need to have that problem.

Where to actually start

If you want to learn this properly rather than follow a five-minute tutorial, we published our full course openly: 22 hours, eleven sessions, under CC BY-NC.

It is built for a competent backend developer who wants to become self-sufficient over a weekend, which is exactly the gap between the kubectl run demo and the forty-hour certification grind. Everything runs on a local cluster, so there is no cloud bill to start. The later sessions go through to Terraform for provisioning a real GKE cluster, secrets via an external secret manager, and production concerns: probes, limits, autoscaling.

You can fork it, run it, and teach from it.

For the surrounding architecture, see our European AI infrastructure, the costed detail of the serverless move in running on-demand GPU inference in Europe, and the workload that most needs a cluster you control: self-hosted AI meeting notes for confidential meetings.