Lesson: What Kubernetes Is and Why

What you'll learn

The problems Kubernetes (often shortened to "k8s") solves that plain docker run cannot.
What "declarative desired state" means and how the control loop keeps your apps running.
The pieces of a cluster: the control plane and the worker nodes.
The basic kubectl commands you will use every day.

Skill gained: you can explain why a cluster exists and talk to the lab cluster with kubectl.

The lesson

You already know how to run a container with docker run. That is great for one container on one machine. But real systems need many containers, on many machines, that restart when they crash, scale when traffic grows, and survive a server reboot. Doing that by hand does not work. Kubernetes is the tool that does it for you.

1. The problem with running containers by hand

Imagine you run docker run myapp on a server. Now answer these questions:

The container crashes at 3 a.m. — who restarts it?
Traffic triples — who starts 5 more copies and shares traffic between them?
The whole server dies — who moves your app to another server?
You ship a new version — who replaces the old containers without downtime?

By hand, you do all of that, awake, forever. Kubernetes is a system whose entire job is to answer those questions automatically, across a group of machines (a "cluster").

2. Declarative desired state + the control loop

This is the single most important idea in Kubernetes, so slow down here.

With docker run you give imperative commands: "start this container now." With Kubernetes you write a declarative description: "I want 3 copies of myapp running, always." You hand that desired state to the cluster and walk away.

Kubernetes then runs a control loop: it constantly compares what you asked for (desired state) against what is actually running (current state) and takes action to close the gap. This loop never stops.

   You declare desired state
            |
            v
   +------------------+        observe
   |  Control loop    |<-------------------+
   |  desired == ?    |                    |
   |  current         |---> take action ---> cluster
   +------------------+   (start/stop pods)

So if you said "3 copies" and one crashes, the loop sees current=2, desired=3 and starts a replacement. You never told it to restart anything — you only ever declare the end state you want.

3. `docker run` vs a cluster

Plain `docker run`	A Kubernetes cluster
One machine	Many machines pooled together
You restart crashes	Cluster restarts them
You scale manually	Declare a number; cluster matches it
You pick the machine	Scheduler picks a healthy node
Imperative ("do X now")	Declarative ("keep state X")

4. Control plane and nodes

A cluster has two kinds of machines.

The control plane is the brain. It holds the desired state and runs the control loops. Its main parts:

API server — the front door. Every command and every component talks to it.
etcd — the database that stores the whole cluster state.
scheduler — decides which node a new Pod should run on.
controller-manager — runs the control loops that fix drift.

The worker nodes are the muscle — they actually run your containers. Each node runs:

kubelet — the agent that starts/stops containers and reports health.
container runtime — the thing that runs containers (the lab uses containerd).
kube-proxy — wires up networking so traffic reaches your containers.

            CONTROL PLANE
   +------------------------------+
   | api-server  etcd             |
   | scheduler   controller-mgr   |
   +---------------+--------------+
                   | (all talk through api-server)
       +-----------+-----------+-----------+
       v           v           v           v
   +--------+  +--------+  +--------+  +--------+
   | node   |  | node   |  | node   |  |  ...   |
   | kubelet|  | kubelet|  | kubelet|  |        |
   | runtime|  | runtime|  | runtime|  |        |
   +--------+  +--------+  +--------+  +--------+

In the lab the control plane lives on the master at 10.100.100.7, and the workers are 10.100.100.8, 10.100.100.9, and 10.100.100.10. The cluster runs Kubernetes v1.36 with the Calico network plugin and the containerd runtime. You administer it from the Jumpbox, where kubectl, helm, and k9s are already installed and the kubeconfig (the file that tells kubectl how to reach the cluster) is ready.

5. kubectl basics

kubectl is the command-line client that talks to the API server. From the Jumpbox, try these read-only commands — they are safe.

# Are we connected? List the nodes (machines) in the cluster.
kubectl get nodes

# See everything running in the default namespace.
kubectl get pods

# A "namespace" is a folder that groups resources. List them.
kubectl get namespaces

# Full detail about one node, including health conditions.
kubectl describe node <node-name>

# What version are client and cluster?
kubectl version

The pattern is almost always kubectl <verb> <resource> [name]. Common verbs: get (list), describe (detail), apply (create/update from a file), delete, logs, exec.

You will create things by writing YAML files and running kubectl apply -f file.yaml. Apply is declarative: you describe the desired state in the file, and the cluster makes it so. Here is the smallest possible object just to see the shape:

apiVersion: v1
kind: Pod
metadata:
  name: hello
spec:
  containers:
    - name: hello
      image: nginx:1.27

kubectl apply -f hello.yaml   # create it
kubectl get pods              # watch it appear
kubectl delete -f hello.yaml  # remove it

You do not need to understand Pods fully yet — the next lesson covers them. For now the takeaway is the workflow: write desired state in YAML, apply it, and the control loop keeps it true.

Dig deeper

Search terms

what is kubernetes for beginners
kubernetes declarative vs imperative
kubernetes control plane vs worker node
kubectl get nodes explained
kubernetes reconciliation loop

Check yourself

Name two things a cluster does automatically that you would have to do by hand with docker run.
In your own words, what is the difference between desired state and current state?
Which control-plane component is the "front door" that everything talks through?
Which lab IP is the control-plane master, and which are the workers?
What does kubectl apply -f file.yaml do, and why is it called declarative?