Chapter 54 — The control plane and the node: Kubernetes' architecture

In one sentence

Every Kubernetes cluster splits into the control plane (the brain — decides what SHOULD be running, where) and one or more nodes (the muscle — actually RUN the containers), and this split is exactly why a cluster can survive real, partial failures gracefully.

Why this matters

"Why did my app keep running even though the control plane had an issue" and "why doesn't the API server itself run my containers" are both answered by this one architectural split.

How it actually works

   THE CONTROL PLANE (the "brain," typically running on dedicated
   control-plane nodes):
     API SERVER          the front door -- EVERYTHING (kubectl, every
                        other control-plane component, every kubelet)
                        talks to Kubernetes ONLY through this REST API.
                        Nothing bypasses it.
     etcd                  a distributed, consistent key-value store --
                        the SOURCE OF TRUTH for the ENTIRE cluster's
                        state (every object's desired configuration,
                        current status).
     SCHEDULER              watches for newly-created pods with no node
                        assigned yet, and DECIDES which node they should
                        run on (based on resource availability,
                        constraints -- Chapter 58 covers this properly).
     CONTROLLER MANAGER      runs the actual "reconcile actual state
                        toward desired state" LOOPS (Chapter 53's core
                        idea) -- a Deployment controller noticing "I
                        should have 5 replicas but only 3 are running"
                        and creating 2 more, for example.

   THE NODE (the "muscle," where your actual containers run -- a
   cluster typically has many of these):
     KUBELET                 the agent running on EVERY node -- talks
                        to the API server, and makes sure the
                        containers THIS node has been assigned are
                        actually running, restarting them locally if
                        they crash (Chapter 33's systemd `Restart=`
                        idea, one layer up).
     CONTAINER RUNTIME         the actual thing running containers on
                        this node -- `containerd` (very commonly, these
                        days) or another compatible runtime -- doing
                        the literal Chapter 44/47 work.
     KUBE-PROXY                handles the networking rules that make
                        Services (Chapter 56) actually route traffic to
                        the right pods on this node.

   THE ARCHITECTURAL PAYOFF: because the CONTROL PLANE decides "what
   should run" and NODES independently, locally, keep "what's actually
   running" matching their OWN last-known assignment (via the kubelet),
   a TEMPORARY control-plane disruption does NOT immediately stop
   already-scheduled, already-running pods from continuing to run and
   serve traffic on healthy nodes -- the kubelet keeps enforcing the
   last instruction it received, even if it can't currently reach the
   API server for a NEW one. This graceful-degradation property is a
   deliberate, well-documented design characteristic, not an accident.

Real-world example

   This exact resilience property -- already-running workloads
   surviving a control-plane disruption -- is explicitly, deliberately
   documented in Kubernetes' own official architecture documentation as
   intentional design, not a lucky side effect: the kubelet is built to
   operate with a degree of AUTONOMY specifically so that a control-
   plane issue (a temporary API-server outage, a networking partition
   between a node and the control plane, a slow etcd) doesn't
   IMMEDIATELY translate into an application-facing outage for workloads
   that are ALREADY scheduled and running. Real operators managing
   Kubernetes at scale rely on this property directly: it changes how
   URGENTLY a control-plane issue needs to be treated (still urgent --
   NEW deployments, scaling, and self-healing from node failures all
   stop working until it's fixed -- but not an instant, cluster-wide
   application outage the moment it happens), and it's a genuinely
   important distinction for anyone doing on-call for a Kubernetes-based
   system to understand precisely, rather than treating "control plane
   is unhealthy" and "my application is down" as automatically the same
   incident.

Try it yourself

# See the control plane and node(s) in your own cluster
kubectl get nodes -o wide
kubectl get pods -n kube-system     # the control-plane components
                                    # themselves ARE pods (on a `kind`
                                    # cluster, running as containers) --
                                    # a genuinely nice, concrete
                                    # illustration that Kubernetes
                                    # itself is largely "Kubernetes,
                                    # bootstrapped, running Kubernetes"

kubectl get pods -n kube-system -o wide | grep -E "etcd|apiserver|scheduler|controller"

# See the API server directly (everything really does go through it)
kubectl get --raw /healthz
kubectl proxy &                      # expose the API server locally
sleep 1
curl -s localhost:8001/version       # a raw HTTP call to the API
                                     # server -- exactly what `kubectl`
                                     # itself does, under the hood
kill %1

Common mistakes

Assuming the control plane runs your application containers. It DECIDES what should run — the actual container processes run on nodes, managed by each node's kubelet.
Treating "control plane down" and "application down" as automatically the same incident. Already-running workloads often keep serving traffic — verify what's ACTUALLY affected before escalating as a full outage.
Forgetting etcd is the actual source of truth. Every other component is, in a sense, working FROM what's recorded in etcd — its health is foundational to the whole cluster's.

Check yourself

What's the difference between the control plane and a node, in one sentence each?
What does the kubelet actually do, and why does it matter for resilience during a control-plane issue?
Why does "the control plane had an issue" not automatically mean "the application was down"?