Kubernetes cluster architecture: control plane and nodes

Docker & Containers' Kubernetes lesson showed you how to write a Pod, a Deployment, and a Service — this lesson is about what's actually running the show underneath `kubectl apply`, since every object this domain covers is really just a request handed to this same machinery.

Beginner

3 min read

Two kinds of machines in a cluster

A Kubernetes cluster is made of two categories of machines with completely different jobs:

Control plane — the "brain" of the cluster, making decisions but not running your application containers itself.
Worker nodes — the machines that actually run your Pods.

The control plane's four components

API server — the single front door for every interaction with the cluster. kubectl apply doesn't talk to etcd or the scheduler directly — it sends a request to the API server, which is the only component every other piece of the system (and every kubectl command) actually talks to.
etcd — a distributed key-value store holding the cluster's entire state: every object's current and desired configuration. This is the literal source of truth Kubernetes is reconciling reality toward — if etcd says "3 replicas of my-app should exist," that's the fact every other component is working to make true.
Scheduler — decides which node a newly-created Pod should run on, based on each Pod's resource requests (from Docker & Containers' lesson) and each node's available capacity, along with other constraints (taints, affinity rules) more advanced lessons could add.
Controller manager — runs the reconciliation loops that make Kubernetes "declarative" rather than "imperative": the Deployment controller watching etcd's desired replica count against the actual count and creating or deleting Pods to close the gap is one of many such controllers running continuously here.

What a worker node actually runs

kubelet — the agent running on every node, responsible for actually starting, stopping, and monitoring the containers the control plane has assigned to that node, and reporting their status back to the API server. The kubelet is what turns "the scheduler decided this Pod goes here" into a real running container.
kube-proxy — implements the networking rules that make Services (from Docker & Containers' lesson) actually route traffic to the right Pods, maintaining the mapping as Pods come and go on that node.
The container runtime — the actual software (containerd, CRI-O) that runs containers, which kubelet calls into via a standard interface.

Why understanding this changes how you read `kubectl` output

kubectl get pods and kubectl apply -f deployment.yaml are really just API-server requests — every single kubectl command is a REST call against that same central API. Understanding this reframes what's actually happening when you write a Deployment YAML file and run kubectl apply: you're not directly telling any machine to do anything. You're writing desired state into etcd via the API server, and a controller (running continuously, watching for exactly this kind of change) notices the gap between desired and actual state and starts working to close it. Every object covered in the rest of this domain — ConfigMaps, Ingress, autoscalers, StatefulSets — is just a different kind of desired state written to the same etcd, reconciled by a different controller watching for that kind.

Why this matters when something goes wrong

A Pod stuck Pending almost always means the scheduler can't find a node with enough resources — checking node capacity, not application code, is the correct first move. A Pod's status not updating means either the kubelet on its node is unreachable or the API server itself is degraded — very different problems from an application bug, and kubectl describe node (not kubectl logs) is the right tool to start with. Knowing which component is responsible for which kind of failure is what turns "the cluster is being weird" into a specific, diagnosable problem.

Kubernetes cluster architecture: control plane and nodes

Beginner

3 min read

Two kinds of machines in a cluster

A Kubernetes cluster is made of two categories of machines with completely different jobs:

Control plane — the "brain" of the cluster, making decisions but not running your application containers itself.
Worker nodes — the machines that actually run your Pods.

The control plane's four components

API server — the single front door for every interaction with the cluster. kubectl apply doesn't talk to etcd or the scheduler directly — it sends a request to the API server, which is the only component every other piece of the system (and every kubectl command) actually talks to.
etcd — a distributed key-value store holding the cluster's entire state: every object's current and desired configuration. This is the literal source of truth Kubernetes is reconciling reality toward — if etcd says "3 replicas of my-app should exist," that's the fact every other component is working to make true.
Scheduler — decides which node a newly-created Pod should run on, based on each Pod's resource requests (from Docker & Containers' lesson) and each node's available capacity, along with other constraints (taints, affinity rules) more advanced lessons could add.
Controller manager — runs the reconciliation loops that make Kubernetes "declarative" rather than "imperative": the Deployment controller watching etcd's desired replica count against the actual count and creating or deleting Pods to close the gap is one of many such controllers running continuously here.

What a worker node actually runs

kubelet — the agent running on every node, responsible for actually starting, stopping, and monitoring the containers the control plane has assigned to that node, and reporting their status back to the API server. The kubelet is what turns "the scheduler decided this Pod goes here" into a real running container.
kube-proxy — implements the networking rules that make Services (from Docker & Containers' lesson) actually route traffic to the right Pods, maintaining the mapping as Pods come and go on that node.
The container runtime — the actual software (containerd, CRI-O) that runs containers, which kubelet calls into via a standard interface.

Kubernetes cluster architecture: control plane and nodes

Two kinds of machines in a cluster

The control plane's four components

What a worker node actually runs

Why understanding this changes how you read `kubectl` output

Why this matters when something goes wrong

Further reading

Kubernetes cluster architecture: control plane and nodes

Two kinds of machines in a cluster

The control plane's four components

What a worker node actually runs

Why understanding this changes how you read `kubectl` output

Why this matters when something goes wrong

Further reading

Kubernetes cluster architecture: control plane and nodes

Two kinds of machines in a cluster

The control plane's four components

What a worker node actually runs

Why understanding this changes how you read kubectl output

Why this matters when something goes wrong

Further reading

Kubernetes cluster architecture: control plane and nodes

Two kinds of machines in a cluster

The control plane's four components

What a worker node actually runs

Why understanding this changes how you read kubectl output

Why this matters when something goes wrong

Further reading

Why understanding this changes how you read `kubectl` output

Why understanding this changes how you read `kubectl` output