If you already know how to build an image with Docker and run a container, you are halfway there: you know how to package software. What Kubernetes solves is the other half, the half that shows up when that container is no longer alone on your laptop and becomes one of forty that must be alive, reachable and up to date at three in the morning on the Friday of a bank-holiday weekend. This lesson explains exactly what problem container orchestration solves, where Kubernetes comes from, what it offers compared with the alternatives and —just as important— when it is not the right choice. It is the lesson that gives meaning to all the others: without understanding the problem, the solutions in the next eleven modules look like gratuitous complications.

1. From a single container to a fleet
2. The leap from Docker and Docker Compose
3. A short history: from Borg to the CNCF
4. What Kubernetes actually gives you
5. Kubernetes compared with the alternatives
6. When Kubernetes is NOT a good idea
7. The course scenario: Rutas Norte S.L.

A container solves one very specific problem: packaging an application together with its dependencies so that it runs identically on any machine with a container runtime. That is huge, but it is only the packaging.

As soon as you move to production, questions appear that the container alone does not answer:

• Placement: I have 5 servers and 40 containers. Which one goes where? And when I add a sixth server?
• Survival: the process died at 03:14. Who brings it back up? And if the whole machine has shut down?
• Scaling: today I need 3 replicas of the API, and on Easter Friday I will need 20. Who starts them and who shuts them down afterwards?
• Discovery: the API has restarted and now has a different IP. How does the frontend find out?
• Load distribution: with 20 replicas, who decides which one serves each request?
• Deployment without downtime: I want to release version 2.4.0 without a single customer seeing a 502 error.
• Configuration and secrets: the database password cannot live inside the image, nor in the git log.
• Resources: one container going haywire must not take down the other nine on the same machine.

Each of those questions, solved by hand, turns into a script. The sum of those scripts, maintained by one person who then goes on holiday, is the reason container orchestration exists.

An orchestrator is, in a single sentence: a system you tell what state you want, and which then works permanently to make reality match that description. You say "I want 5 replicas of the API on version 2.4.0, reachable at api.rutasnorte.example"; the orchestrator works out where they fit, starts them, watches them, replaces the ones that die and routes traffic to them.

This is the concept that is hardest at first and pays off most later.

Docker is fundamentally imperative (docker run). Kubernetes is fundamentally declarative: you write a file describing what you want, you hand it to the cluster, and from then on the cluster works for you permanently. If somebody deletes a container, it comes back. If a server goes down, its workloads reappear elsewhere. This mechanism is called the reconciliation loop and we will study it in depth in Kubernetes Architecture.

One very common confusion is worth clearing up straight away: Kubernetes does not replace Docker, it replaces what you used to do around Docker.

• Docker (or any OCI-compatible tool) is still what you use to build images.
• The image registry still exists.
• What changes is who runs and governs those containers.

Docker Compose is the natural intermediate step. With a docker-compose.yml you describe several services, their networks and volumes, and one command brings the whole stack up. It is declarative... within a single machine. That is exactly its ceiling:

What this file cannot do:

1. Spread those services across 5 machines.
2. Bring the stack back up on another server if the current one shuts down.
3. Scale bookings-api to 20 replicas, distributed and load-balanced.
4. Replace image 2.3.1 with 2.4.0 gradually, rolling back automatically if it fails.
5. Isolate environments (dev, pre, pro) with different permissions and quotas.

Kubernetes does exactly those five things, and that is the leap. The price is a learning curve and a layer of new concepts, which is precisely what this course is going to give you.

Kubernetes was not born as an experiment. It is the third generation of an idea proven over more than a decade.

The point that matters to you as a professional: because it sits under the CNCF with neutral governance, Kubernetes is the only orchestration layer that runs practically the same way on your laptop, in your own data centre and on AWS, Azure or Google Cloud. That portability is a business argument, not just a technical one.

Let us get specific about the capabilities, because "orchestrating" is far too vague.

You describe the outcome in a YAML file and the cluster maintains it. You do not execute steps: you publish intentions. Everything else on this list follows from that.

• If a container exits with an error, it is restarted.
• If a container is alive but unresponsive (detected by probes, module 7), it is restarted.
• If a whole node stops responding, its workloads are recreated on other nodes.
• If somebody deletes a replica by hand, it comes back.

You can go from 3 to 20 replicas with a single command, or let the cluster do it on its own based on CPU, memory or business metrics (module 9). For Rutas Norte, whose traffic peaks fall on bank-holiday weekends and holidays, this translates directly into money: you do not pay for idle capacity in February just to survive August.

Replicas are born and die with different IPs. Kubernetes gives you a stable name (bookings-api) that resolves through internal DNS and spreads traffic across the healthy replicas. The frontend never knows an IP. You will see this in module 4.

You change the image version and the cluster replaces the replicas little by little, checking that the new ones are healthy before retiring the old ones. If something goes wrong, rollback to the previous version. Module 2.

Configuration is kept separate from the image (ConfigMaps) and credentials are handled apart, with access control (Secrets). Since bookings-postgres stores customers' personal data, this is not optional for Rutas Norte: it is regulatory compliance. Module 3.

The same manifests work on minikube, on a self-managed cluster built with kubeadm, or on EKS/AKS/GKE. What changes are the infrastructure details (storage type, load balancer), not the description of the application.

You can add your own object types (CRDs) and your own reconciliation logic (operators, module 6). Kubernetes is not just an orchestrator: it is a platform for building platforms.

No tool is the best in the abstract. This table will help you justify a decision to a team or a client.

Quick readings of the table:

• Docker Compose does not compete with Kubernetes: it coexists with it. You will keep using it locally.
• Swarm is simpler, but its community and ecosystem have shrunk drastically; starting a new project on Swarm today means taking on debt.
• Nomad is the serious alternative if you have workloads that are not containers.
• A PaaS may well be the right answer, and admitting it is not a failure. You pay more per unit of compute, but you save on people.

A professional is recognised by knowing when not to apply a tool. Clear signs that Kubernetes is overkill:

1. A small team with no platform skills. Kubernetes needs somebody to look after it: upgrades every few months, certificates, monitoring, permissions. If nobody has that time assigned, the cluster degrades.
2. A single monolithic application with steady traffic. If two machines and a load balancer cover your load all year round, a cluster only adds pieces that can fail.
3. Trivial or short-lived workloads. A daily cron job that takes 40 seconds does not justify a control plane.
4. A need for immediate results. The migration is a project of weeks or months. If the business needs to deliver in two weeks, a PaaS delivers sooner.
5. Applications tightly bound to one specific server (per-machine licences, special hardware, state on local disk with no replication). It can be done, but you are fighting the design.
6. Real cost badly estimated. A managed cluster costs money for the control plane, nodes with reserved capacity, traffic and storage. For three containers, it works out expensive.

Rule of thumb: Kubernetes starts to pay off when you have several services, several environments and more than one person deploying. Before that, it is usually a solution looking for a problem.

The whole course revolves around a fictional company: Rutas Norte S.L., which sells coach tickets online through the Rutas Norte platform. Here we only introduce it; the full detail is in the lesson The Course Project: the Rutas Norte Platform.

Its starting point is the one many real companies find themselves in:

• The platform runs on Docker Compose across two rented machines.
• Deployments are manual: somebody logs in over SSH and runs docker compose pull and up -d. There is a service outage of one or two minutes, so releases happen at night.
• On bank-holiday weekends and during the holidays traffic multiplies; the website slows down and some bookings are lost. The only answer so far has been to rent a bigger machine and leave it idle the rest of the year.
• When a container dies in the small hours, nobody brings it back until the next morning.
• The database password lives in a .env file that has been emailed around more times than anybody wants to admit; and that database stores customers' personal data.

The technical leadership has decided to migrate to Kubernetes for four reasons, which are exactly the capabilities in section 4:

From the next lesson onwards we will build that platform piece by piece, and every new concept will be justified by a concrete Rutas Norte need.

• "Kubernetes replaces Docker". It does not. You still build images the same way. What Kubernetes replaces is docker run, the start-up scripts and the hand-rolled load balancer. Since version 1.24 the cluster talks to containerd or CRI-O through the CRI interface, not to the Docker daemon: that is why dockershim disappeared.
• Translating docker-compose.yml mechanically. Conversion tools exist, but the result is usually a poor deployment: no probes, no resource limits, no externalised configuration. It pays to redesign, not to translate.
• Starting with the production cluster. The right order is: local environment (module 1), understand objects (modules 2 and 3), and only then think about production.
• Believing Kubernetes makes your application resilient. The cluster restarts containers; it does not fix an application that loses data on restart or cannot tolerate running several instances. Kubernetes rewards well-designed applications and punishes the ones that are not.
• Ignoring the cost of people. A cluster's budget is not just infrastructure: it is training, on-call rotas and maintenance. Put it in writing before proposing the migration.
• Vocabulary tip: get into the habit, starting today, of saying "desired state" and "reconciliation". When something does not work in the cluster, the right question is almost always: what state have I declared, and why can the cluster not reach it?

Without writing a single manifest, draw up a table with the five operational problems Rutas Norte suffers today and, for each one, state: (a) which Kubernetes capability would solve it, and (b) what would happen if the company decided not to migrate and simply rented bigger servers.

For each of these three cases, decide whether you would recommend Kubernetes, a PaaS or Docker Compose, and justify the decision in three lines:

1. A two-person startup with one web application and one database, that needs to reach the market within a month.
2. An insurance company with 60 microservices, three environments, audit requirements and teams in two countries.
3. A static corporate blog with 200 visits a day.

Write a paragraph of at most 150 words addressed to the non-technical leadership of Rutas Norte explaining why the company should migrate to Kubernetes, without using the words "pod", "container" or "cluster". It must mention cost, availability and customer data.

Solution 1

Solution 2

1. PaaS. Two people cannot maintain a cluster and reach the market within a month. The priority is to ship; vendor lock-in is an acceptable problem to solve later if the product works.
2. Kubernetes. 60 microservices, three environments and auditing are exactly the point where the operational cost pays for itself: RBAC, a namespace per environment, network policies and consistent deployments across teams and countries.
3. None of the three, or Docker Compose at most. 200 visits a day on a static site are served by static hosting or a CDN. Any orchestrator is pure cost with no benefit.

Solution 3 (example of a valid answer)

Today, ticket sales depend on two machines we manage by hand. When something fails at night, it is not recovered until the next morning, and on bank holidays and during the holiday season —exactly when we sell the most— the website slows down and we lose bookings. On top of that, we pay all year for capacity we only need for a few weeks. The new platform we are proposing watches the service continuously and restores it by itself if it fails, expands capacity automatically when demand rises and reduces it when demand falls, and lets us publish improvements without taking the website down. It also separates the keys that unlock our customers' data from the code and records who may consult them, which strengthens our position in a data protection audit. The initial cost is training and setup; the saving is in capacity not wasted and in sales we lose today.

Kubernetes is a container orchestrator: a system to which you declare the state you want and which works continuously to maintain it, providing self-healing, scaling, service discovery, downtime-free deployments and portability across clouds. It grew out of Google's experience with Borg, it is today a neutral CNCF project and it has become the de facto standard, but it carries a real operational cost that makes it a poor fit for small teams and trivial workloads. Rutas Norte falls squarely into the profile that does justify it: several services, several environments, pronounced demand peaks and personal data to protect.

You now know what Kubernetes does. The next question is how it does it: which pieces make up a cluster, what the reconciliation loop that underpins the whole declarative model looks like, and what happens exactly, step by step, from the moment you submit a manifest until a container is running on a node. That is what we will see in Kubernetes Architecture.