Architecture: Control Plane vs Worker Nodes

In one line

Every Kubernetes cluster splits into a control plane (the brain, making decisions) and worker nodes (the muscle, actually running your containers) — understanding this split explains where every component you'll learn actually lives.

0/4 · 0%

Think of it like this

A restaurant chain's head office (the CONTROL PLANE — deciding staffing levels, menu changes, where new locations open) versus the actual restaurant locations (WORKER NODES — where food is actually cooked and served). The head office doesn't cook anything itself; it makes decisions that the locations carry out.

Key ideas

01
The CONTROL PLANE is the cluster's brain, made up of several components: the API SERVER (the single front door — every single interaction with the cluster, including your own kubectl commands, goes through it), ETCD (a reliable, distributed key-value store holding the cluster's entire actual and desired state), the SCHEDULER (decides which worker node should run each new container), and the CONTROLLER MANAGER (runs the reconciliation loops from Topic 0.1, constantly working to match actual state to desired state).
02
A WORKER NODE is a machine (physical or virtual) that actually runs your containers — each one runs a KUBELET (an agent that talks to the API server, and starts/stops containers on that node as instructed), a CONTAINER RUNTIME (the actual engine running containers, commonly containerd, which sits below Docker in the stack Docker's own course covered), and KUBE-PROXY (handles network routing so traffic can reach containers running on that node).
03
A genuinely important insight: the control plane makes DECISIONS but doesn't run YOUR containers at all — a Deployment you create never runs on the control plane's own machines, only on worker nodes. In a real production cluster, the control plane and worker nodes are almost always entirely separate machines, so a workload spike on your application can never accidentally starve the cluster's own brain of resources.
04
kubectl is a command-line client that talks to the API SERVER over HTTP — it's not magic, and it's not talking directly to any other component. Every single kubectl get, kubectl apply, or kubectl delete is, underneath, an HTTP request to the API server, which then updates etcd and lets the relevant controllers react to the change.
05
On a MANAGED cluster (EKS, GKE, AKS), the cloud provider runs and maintains the entire control plane for you, often with no visible 'control plane machine' at all — you interact with it purely through its API endpoint, and you're typically only responsible for the worker nodes (or, with 'serverless' options like EKS Fargate, not even those).

Code & diagrams

KubernetesArchitecturediagram

Every kubectl command is an HTTP request to the API Server — nothing talks to any other component directly.

Rendering diagram…

explore-a-cluster.shmarkdown

See the architecture directly, on any real cluster you have access to (including a local one like minikube or kind).

# See every node in the cluster and its role
kubectl get nodes
# NAME           STATUS   ROLES           AGE   VERSION
# node-1         Ready    control-plane   10d   v1.29.0
# node-2         Ready    <none>          10d   v1.29.0    <- a worker node
# node-3         Ready    <none>          10d   v1.29.0    <- a worker node

# See detailed info about one node, including its resources
kubectl describe node node-2

# See the control plane's own components (on a self-managed cluster —
# on EKS/GKE/AKS these are typically hidden from you entirely)
kubectl get pods -n kube-system
# often shows etcd, kube-apiserver, kube-scheduler, kube-controller-manager
# running as pods themselves, plus kube-proxy and a CNI plugin per node

# Confirm kubectl really is just talking to the API server over HTTP
kubectl get --raw / | head -20

Explain it without notes

Why does kubectl work identically regardless of which specific cluster you point it at — a local minikube cluster, a self-managed cluster, or a managed EKS cluster?

Why do production clusters keep the control plane and worker nodes on entirely separate machines, rather than mixing them together?

Practice

On any cluster you have access to, run kubectl get nodes and identify which node(s) are control-plane and which are workers based on the ROLES column.

Run kubectl get pods -n kube-system (if available on your cluster) and try to match what you see against the control-plane components this topic describes (API server, scheduler, controller manager, etcd).

Trade-offs

↔
A self-managed control plane gives you full visibility and control over every component (useful for genuinely understanding how the pieces fit together, which is exactly why this topic encourages trying it on a local cluster) — but running and maintaining etcd, the API server, and the scheduler reliably yourself is real, ongoing operational work; a managed service (EKS/GKE/AKS) trades that visibility and control for the provider handling the control plane's reliability and upgrades entirely, which is the right trade for the vast majority of real production use.

Done when you can

I can name the four main control plane components and what each one does.
I can name the three main worker node components and what each one does.
I understand kubectl only ever talks to the API server, regardless of which cluster it's pointed at.