Kubernetes in plain words, and when you don’t need it

Kubernetes is a container orchestrator: given a description of the state wanted, its controllers restart and update copies until the real state matches.

When there are many containers

Docker solved the problem of “one box everywhere”. But imagine your project has grown: ten boxes (the site, a request receiver, a database, a queue, a mail service…) on three machines. Questions appear at once that Docker alone doesn’t answer.

• A machine fell over at night. Who will notice and start its containers on another one?
• A lot of people came. Who will add copies of the site, and take the extra ones away when they leave?
• A new version came out. How do you replace the copies one by one so the site is never gone for a second?
• One container has to find another. But containers’ addresses change at every start. How?

A program that answers these questions is called an orchestrator: like a conductor, it plays nothing itself but sees that every musician comes in on time. The best-known orchestrator is Kubernetes (written K8s: “K”, eight letters and “s”). Google open-sourced it in 2014, having built it from the experience of its own internal system, and today an independent foundation, the CNCF, looks after it.

The idea: wanted and real

The main idea of Kubernetes is simple. You don’t start copies one by one. You describe the desired state: “I want three copies of this image.” After that controllers work: they keep comparing what is wanted with what is real, and fixing the gap. A copy fell, and a controller starts a new one. A node vanished, and copies appear on the others. You changed the desired version, and copies are replaced one at a time.

Try it yourself. It is a simplified model: three nodes as runways, copies as airplanes, and a dispatcher who keeps their number. Take down a node, raise the stream of visitors, roll out a new version and watch the picture change. Under the diagram is a short questionnaire about your own project: do you need such a dispatcher?

Copies wanted: 3

Take down node 1Take down node 2Take down node 3 A rush of visitors Roll out a new version Start over

Node 1

Node 2

Node 3

Copies running: 0 of 3. Versions: none.

1. 3 copies are wanted, version 1.

Do you need one?

Services in the project: 2 Downtime you can accept: none at allminutesup to an houra day is fine

The load is very uneven (empty, then a rush) People who can run a cluster: 1

For the action “Main action”: You don’t need an orchestrator. Static hosting or one server is cheaper and more reliable, and it isn’t laziness: you have none of the problems it solves.

Check yourself: what does Kubernetes do when a node holding two copies of the site goes down?

A controller notices that there are fewer copies than wanted and starts the missing ones on the remaining nodes. You don’t have to do anything.

The vocabulary

Five words are enough to follow the talk about it.

• Cluster: the whole estate together. A node is one machine (or virtual machine) of the cluster.
• Pod: the smallest unit Kubernetes runs: one container, and sometimes several closely tied ones. A copy of the site is a pod.
• Deployment: a description of what you want: “keep three pods of this version, update them one at a time.” It is what you write most often.
• Service: a permanent address and name in front of a group of pods. Pods come and go while the service stays the same, so other programs talk to it.
• Ingress: the entrance from outside: a rule such as “send requests to example.com/api to such-and-such a service.” It also usually handles HTTPS.

All this is written in YAML files. Here are a Deployment and a Service for the request receiver from the last lesson. You don’t need to memorize the lines. Look at the meaning: how many copies, which image, which port, and how to find them.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: receiver
spec:
  replicas: 2
  selector:
    matchLabels:
      app: receiver
  template:
    metadata:
      labels:
        app: receiver
    spec:
      containers:
        - name: receiver
          image: registry.example.com/receiver:1.0
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: receiver
spec:
  selector:
    app: receiver
  ports:
    - port: 80
      targetPort: 8080

The command kubectl apply -f file.yaml hands this description to the cluster, and kubectl get pods shows what is running.

What an orchestrator gives you

• Self-healing: what fell is restarted, and what was lost with a node moves.
• Updates with no downtime (a rolling update), and a rollback to the previous version with one command.
• Scaling: by hand (change the number of copies) or automatically by load.
• Service discovery and balancing: pods find each other by name, and the load is shared between copies.
• Settings and secrets apart from the images.

This is a huge benefit when you have many services, several teams and a load that jumps about. Now the price.

The price

Kubernetes is a big system in itself. A cluster has to be updated: new versions come out every few months, and each is supported for a limited time (roughly fourteen months, according to the project’s own patch-release policy, checked October 2026), so updates are regular. You have to set up the network, access rights, data storage, monitoring (logs, metrics, alerts) and backups. A mistake in the settings easily opens up more than you meant. Someone has to understand the cluster: even in the managed kind, where a provider (AWS, Google Cloud, Microsoft Azure and others) runs the cluster’s “brain” for you, your applications, their settings and the responsibility stay with you.

So experienced engineers repeat a rule: Kubernetes solves problems of scale, and to bring it where there is no such scale is to buy a freight train to fetch bread.

Check yourself: why does a provider’s managed Kubernetes not make a cluster “free” in labor?

The provider runs the cluster’s control part, but your applications, their settings, permissions, image updates and monitoring stay with you. You still need to know what is going on.

A ladder, not a jump

A good habit is to climb only when you’ve hit a real limit.

1. Static hosting. Pages and a form service. For most projects this is the whole infrastructure.
2. A platform (PaaS) that runs the application from a repository or an image and restarts it, so you don’t think about servers.
3. One server with Compose. The containers of the site, the receiver and the database on one machine, with restart: unless-stopped and copies of the data. Docker restarts after a crash by itself, and a server at a provider usually runs for years.
4. Managed running of containers at a cloud (with no cluster of your own).
5. Kubernetes, managed by a provider; for small setups there are also lighter versions such as k3s, and alternatives such as Nomad. This step is for a real load: dozens of services, uneven traffic, strict demands on downtime, and people to run the cluster.

The questionnaire under the diagram asks the same questions. Turn the knobs: with two services and an acceptable downtime of “up to an hour”, you don’t need an orchestrator, and that is the right answer.

Practice

You assess your project the way an engineer does. Enter the number of services, the acceptable downtime and who would run the cluster, then write a verdict (“needed” or “not needed”) with arguments from those figures and the project’s main action. Name the cheap option without Kubernetes. And spell out three words (pod, service, deployment) with your own project as the example: what in it would be what. This is needed even by those who decided “not needed”: the words will still be useful when you meet them in other people’s projects.

What was wrong before

In 2010 this problem hardly existed: one server, and if it went down, the admin drove to the data center at night. When services multiplied, people built their own “orchestrators” from scripts, different in every team and understood only by their author. Kubernetes became a common language, and with it came the fashionable idea that a “real” project must live in a cluster. That is a mistake: most projects don’t need it, and an honest refusal is not falling behind but saving effort.