📖 Read-only preview — lessons, diagrams, and quizzes only. The hands-on labs, live grading, and progress tracking require running the real course locally against a Kubernetes cluster.Run it locally →

Module 1 · Lesson 1.1

Control Plane vs Nodes

You've run servers before: a box with an OS, some processes, maybe behind a load balancer. Kubernetes takes that same idea and splits it cleanly into two roles.

Control plane vs. nodes

Control PlaneAPI serveretcdSchedulerControllersNode 1kubelet + podsNode 2kubelet + podsNode 3kubelet + pods
Blue dots: instructions flowing down from the control plane to kubelet on each node. Green dots: status flowing back up. This never stops — it's the reconciliation loop, running continuously.

The control plane: the "management layer"

The control plane is the brain. It doesn't run your application — it decides where things should run and remembers what you asked for. It's made of a few cooperating processes, usually on dedicated machines (or, in kind/EKS, containers acting as machines):

  • API server — the front door. Every kubectl command, every internal component, talks to Kubernetes exclusively through this HTTP API. Think of it as the single reception desk for a building with many departments.
  • etcd — a small, consistent key-value database. This is the cluster's only source of truth: every object you create is a record in etcd. If etcd is gone, the cluster's memory is gone.
  • Scheduler — watches for newly created pods with nowhere to run yet, and assigns each one to a node based on resources, constraints, and policy.
  • Controller manager — runs the control loops (more on this in the next lesson) that keep reality matching what you declared.

Nodes: where work actually happens

A node is a worker machine — a VM or physical box — running your containers. Every node runs a kubelet, a background process (a daemon, in Linux terms — the same category as a Windows service: it starts at boot and just keeps running) that takes instructions from the control plane and talks to the local container runtime to actually start and stop containers. Nodes also run kube-proxy, which programs the network rules Services rely on.

The infrastructure analogy

If you've run a traditional web tier: the control plane is like your orchestration and config-management layer (think a very opinionated, self-driving combination of a load balancer's control plane + a CMDB + an auto-remediation script), and nodes are your fleet of app servers. The crucial difference: in Kubernetes, that orchestration layer is always running, continuously comparing what you asked for against what's real — not something you invoke by hand.

In the lab, you'll stand up a real 3-node cluster and go look at both halves with your own kubectl.

🧪 Lab: lab-01-explore-control-plane

Preview only

Goal

Stand up the real cluster you'll use for the rest of the course, and look at both halves of it — control plane and nodes — with your own eyes.

This lab has no manifests to apply. It's pure exploration, plus a working cluster at the end, which every later lab depends on.

Tasks

  1. From the repo root, run scripts/setup.sh. Fix anything it reports as missing, then re-run it until everything is ✅.
  2. Run scripts/cluster-up.sh. This creates a 3-node kind cluster named k8s-course (1 control-plane + 2 workers) and switches your kubectl context to it.
  3. Run kubectl cluster-info — note the API server address it prints.
  4. Run kubectl get nodes -o wide — you should see 3 nodes, all Ready.
  5. Run kubectl get pods -n kube-system — this is the control plane itself (and a couple of node-level daemons), running as ordinary pods.
  6. Pick the control-plane node's name from step 4 and run kubectl describe node <name> — scroll to the Conditions and Allocated resources sections.

Check

Run the check once all 3 nodes show Ready in step 4.

This lab runs against a real local Kubernetes cluster with an automated grader — clone the repo and run make start to do it for real.

📝 Quiz

1. Which component is the single entry point that every other piece — kubectl, the scheduler, the kubelet — talks through?

2. Where does Kubernetes actually store the state of every object (every Pod, Deployment, Service you create)?

3. A Pod has just been created but has no node assigned yet. Which component's job is it to pick one?

4. You SSH onto a worker node and kill the kubelet process. What happens to the containers that node was already running?scenario

5. In the traditional-infrastructure analogy, the control plane is closest to:

Progress isn't saved in this preview — run the course locally to track completion and grade labs for real.