What Is Kubernetes and Why Orchestration

If you went through the Docker series, you know how to package an application into an image and run it as a container. One container, on one machine — everything is tidy. The trouble starts when the application grows: you need ten copies of the container to handle the load, spread across three servers, and when one machine dies the containers on it must be rebuilt on another machine — automatically, at 3 a.m., without anyone waking up. Managing that by hand is impossible. This is exactly the gap Kubernetes fills.

This series learns Kubernetes from the fundamentals, hands-on with minikube — a miniature Kubernetes cluster running right on your machine. We deliberately avoid digging too deep into the internals (etcd's inner mechanics, the controller runtime, CNI...) — that's reserved for a later "Kubernetes from scratch" series. The goal here: get a solid grasp of the core concepts and be able to do real work.

From container to cluster: the real problem

Docker solves "how does my application run". But once you go to production, a flood of new questions appears that Docker itself doesn't answer:

• A container dies in the middle of the night — who rebuilds it?
• The load doubles — who starts more copies, then scales down when it drops?
• You have 3 servers — which container should run on which machine to stay balanced?
• Deploying a new version — how do you roll it out gradually, without disruption, and roll back if it breaks?
• 10 copies of one service — how do you reach them through one stable address, when each container's IP keeps changing?

Answering all of these automatically is exactly the job of a container orchestrator. Kubernetes (commonly abbreviated K8s — "K", eight letters, "s") is the most popular orchestrator, originating at Google and now part of the CNCF (Cloud Native Computing Foundation).

   Docker             →   Kubernetes
   ───────                ──────────
   "Run 1 container        "Keep 10 copies of this container
    on this machine"        always running, spread evenly across
                            the cluster, rebuild them when they die,
                            reachable through a stable address,
                            deploy with no downtime"

The core idea: desired state

If you keep only one idea about Kubernetes, keep this one. You don't command Kubernetes step by step like "create a container, if it dies recreate it, if the load is high then...". Instead you declare the desired state: "I want 3 copies of this application always running". Then Kubernetes takes care of the rest.

Internally, a loop called the control loop continuously compares:

   DESIRED state          ──►  [ compare ]  ◄──   ACTUAL state
   "want 3 copies"                                "have 2 (1 just died)"
                              │
                              ▼
                    Kubernetes acts:
                    spin up 1 more copy → back to 3

This is declarative thinking, not imperative — exactly the spirit of Ansible in the previous series, but applied to the whole container lifecycle at cluster scale. You describe the "destination", the system finds its own way there and keeps it there. A container dies, a server fails, someone accidentally deletes a pod — the control loop pulls the system back to the exact state you declared. This "self-healing" property is no magic; it's just that comparison loop running endlessly.

minikube: a cluster to learn on, right on your machine

A real Kubernetes cluster needs many servers — too heavy to stand up just for learning. minikube solves this: it stands up a fully functional Kubernetes cluster inside a container (or VM) on your machine. One node, but with a real control plane, a real API, a real kubectl. Every concept you learn here applies unchanged to a multi-node production cluster.

   Your machine (Mac/Linux/Windows)
   └── minikube  (1 "node" container via Docker)
        └── a complete Kubernetes cluster
             ├── control plane (the brain)
             └── where your application runs

Once you're done with a lesson, minikube delete wipes it all — no cloud bills, no leftover junk. This is why minikube is the standard starting point for learning K8s, recommended by the kubernetes.io docs themselves.

Series roadmap

Fifteen articles, from "what is K8s" to deploying a complete multi-component application:

• Fundamentals (Articles 0–4): cluster architecture, installing minikube, then the first three building blocks — Pod, Deployment, and how to scale/roll out.
• Connectivity & configuration (Articles 5–9): Service (stable address), Namespace/Label, ConfigMap/Secret (separating configuration), storage (PV/PVC), and Ingress (bringing HTTP into the cluster).
• Operations (Articles 10–14): health checks (probes), resource limits & autoscaling, the other workload types (StatefulSet, DaemonSet, Job), troubleshooting, and a capstone project.

By the end of the series, you won't just be able to run kubectl commands — you'll understand why each object exists and how they fit together, enough of a foundation to step into production Kubernetes and move on to deeper topics.

Article 1 lifts the hood: what a Kubernetes cluster's architecture consists of, and how the "brain" that coordinates everything works.