Kubernetes Architecture — Control Plane, Nodes, and How They Talk

Quick recap from Post 1: Kubernetes constantly checks what's actually happening in your cluster against what you asked for, and fixes any gap it finds. That's the whole game. But something has to do that checking, and something has to actually run your containers. Today we open the hood and meet the real pieces that do this work — and by the end, you'll point at each one running live on your own minikube cluster.

The big picture: two kinds of machines

A Kubernetes cluster is a group of machines. Each machine is called a node. Every node plays one of two roles.

The control plane is the brain of the cluster. In simple words, it makes decisions — but it never runs your application containers itself. The worker nodes are the muscle. In simple words, they run your containers, but they don't decide anything on their own. They just do what the control plane tells them to do.

On minikube, one single machine plays both roles at once, which is why it's such a good way to learn. In a real production cluster, the control plane usually runs on its own dedicated machine(s), kept separate from the worker nodes. That way, a noisy application on a worker node can never starve the brain of the cluster.

Control plane: the decision-makers

The control plane isn't one single program. It's a handful of small components, each doing exactly one job. Let's meet them one at a time, and give each one its restaurant-chain job title.

kube-apiserver — the front desk. kube-apiserver is short for Kubernetes API server. In simple words, it is the front door of the cluster. Every request goes through it: you typing a kubectl command, the scheduler assigning a pod, a kubelet reporting status. Nothing talks to any other control plane component without going through the front desk first. In the restaurant chain, kube-apiserver is the receptionist at Head Office — nobody talks directly to the filing cabinet or to a manager, everyone talks to the receptionist first. It's also the only component allowed to talk directly to the cluster's data store; every other piece reaches that data indirectly, through the API server.

etcd — the filing cabinet. etcd is a key-value store. In simple words, it is a database that holds the entire state of the cluster: what pods should exist, what nodes are registered, what configuration exists. In the restaurant chain, etcd is the filing cabinet in the back room — the one master record Head Office writes everything down in. If etcd is lost or corrupted, the cluster loses its memory. That's exactly why backing it up matters in production, and why the CKA exam cares about it.

kube-scheduler — the dispatcher. kube-scheduler decides which worker node a new pod should run on. In simple words: when a pod needs a home and hasn't been assigned to a node yet, the scheduler picks the best node for it, based on things like available CPU/memory and any rules you've set. In the restaurant chain, it's the dispatcher: "branch #3 has capacity, send this order there." The scheduler only makes the decision and writes it down through the API server — it doesn't start anything itself.

kube-controller-manager — the loop of area managers. Quick recap from Post 1: the reconciliation loop is Kubernetes constantly checking what's actually happening against what you asked for, and fixing any gap. kube-controller-manager is the control plane component that actually runs that check-and-fix loop. In simple words, it is a bundle of small controllers all running inside one process — a node controller that keeps asking "are all nodes healthy?", a replication controller that keeps asking "do I have as many pod copies as requested?" — each one endlessly comparing reality to desired state and issuing a fix the moment something's off. In the restaurant chain, picture a set of area managers at Head Office, each walking the floor with a clipboard, checking one thing, and issuing a correction order the moment something's wrong.

cloud-controller-manager — the outside-vendor liaison. cloud-controller-manager talks to your cloud provider's own APIs (AWS, GCP, Azure) — for things like creating a load balancer or recognizing cloud-specific nodes. Worth knowing the name, but minikube barely touches it. It'll matter more once you're running on GCP later in this series.

Worker nodes: where the cooking happens

Now walk over to a branch kitchen. Each worker node runs a much simpler set of components, because their job is to execute, not to decide.

kubelet — the branch manager. kubelet runs on every worker node. In simple words, it's the agent that makes things actually happen locally. It constantly asks the API server one question: "what pods am I supposed to be running right now?" Then it makes sure those containers actually start — and stops any that shouldn't be running. It also reports node and pod health back to the control plane, exactly like a branch manager phoning Head Office with "order's out" or "we're low on flour." kubelet is the component that turns a control plane decision into an actual running container.

kube-proxy — the traffic rules on the ground. kube-proxy also runs on every worker node. In simple words, it sets up the networking rules that let traffic find the right pod through a Kubernetes Service. Think of it as the branch's order-routing system — it makes sure an order lands at the right counter even as staff shuffle around. We'll go deep on Services in Post 5; for now just know the name, and know it lives on every worker node.

Container runtime — the stove. The kubelet doesn't cook. It doesn't run containers itself — it delegates that job to a container runtime, most commonly containerd today. In simple words, the container runtime is the literal stove: it pulls the container image and starts and stops the actual container process. kubelet gives the instructions; the container runtime does the physical cooking.

Seeing it for real on minikube

This isn't just theory — you can see every piece of it running right now. Make sure minikube is up from Post 1, then check your nodes:

$ kubectl get nodes -o wide
NAME       STATUS   ROLES           AGE   VERSION   INTERNAL-IP   OS-IMAGE
minikube   Ready    control-plane   10d   v1.29.0   192.168.49.2  Ubuntu 22.04

Look at the ROLES column: it says control-plane. On minikube, this one machine plays both roles at once — that's exactly why it's such a good learning setup. Next, ask the cluster to describe its own control plane:

$ kubectl cluster-info
Kubernetes control plane is running at https://192.168.49.2:8443
CoreDNS is running at https://192.168.49.2:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Now for the part that makes this click. The control plane components you just read about aren't abstract theory — on minikube, and on most real clusters, they run as actual pods, tucked into a special namespace called kube-system. A namespace is just a way of grouping resources inside a cluster; kube-system is the one reserved for the cluster's own internal machinery.

$ kubectl get pods -n kube-system
NAME                               READY   STATUS    RESTARTS   AGE
etcd-minikube                      1/1     Running   0          10d
kube-apiserver-minikube             1/1     Running   0          10d
kube-controller-manager-minikube   1/1     Running   0          10d
kube-scheduler-minikube             1/1     Running   0          10d
kube-proxy-abcde                   1/1     Running   0          10d
coredns-76f75df574-xyz12           1/1     Running   0          10d

Look at those pod names: etcd-minikube, kube-apiserver-minikube, kube-scheduler-minikube, kube-controller-manager-minikube. These are the exact components you just read about, each one packaged as an ordinary pod, quietly running the reconciliation loop right now. They're pods, just like anything else you'll run in Kubernetes, living in kube-system.

Next up: Pods — the smallest thing you'll actually deploy in Kubernetes, and why it's a pod and not a container.