Kubernetes Architecture

Kubernetes Fundamentals

Chapter 2 · Kubernetes Architecture

Chapter 1 covered why Kubernetes exists. This chapter covers what it's actually made of — the components that together make cluster orchestration possible.

The Big Picture — Control Plane vs. Worker Nodes

A cluster is one or more control plane nodes (the "brain," making decisions) plus many worker nodes (where actual application containers run). This split matters practically: losing a worker node only loses the workloads running there. Losing the control plane, without redundancy, threatens the cluster's ability to make new decisions — but already-running workloads on healthy worker nodes keep running even if the control plane is briefly unavailable, a genuinely important operational nuance.

The Control Plane, Component by Component

  • kube-apiserver — the front door. Every piece of communication — kubectl, other control plane components, external tools — goes through it. It validates and processes requests, then persists resulting state to etcd.
  • etcd — a distributed key-value store holding the cluster's entire state — the single source of truth for "what should exist."
  • kube-scheduler — watches for newly created pods with no assigned node, and decides which node each should run on, based on resource requirements and constraints (Chapter 10 goes deeper on this).
  • kube-controller-manager — runs controller processes that continuously watch the cluster's actual state and reconcile it toward the desired state stored in etcd — the concrete mechanism behind Chapter 1's "declarative desired state" promise, explained fully below.

Worker Node Components

  • kubelet — an agent running on every worker node. Talks to the API server, and ensures the containers described for that node are actually running and healthy.
  • kube-proxy — maintains network rules on each node, enabling communication to and from pods and implementing Kubernetes' Service abstraction (Chapter 6) at the node level.
  • The container runtime — containerd, per Chapter 1's own clarification — actually pulls images and starts/stops containers as instructed by the kubelet.

The Reconciliation Loop — Kubernetes' Core Mechanism

Every controller performs the same basic loop, continuously: observe current state → compare it against desired state → act to reconcile any difference → repeat, forever.

The single most important concept in this chapter
This one pattern, repeated across many different controllers for many different resource types, is what makes Kubernetes self-healing and declarative at the same time. Nearly everything covered later in this course — self-healing pods (Chapters 5, 11), rolling updates (Chapter 5), autoscaling (Course 2) — is just this same loop applied to a different kind of resource. Understanding it now pays off repeatedly later.

How a kubectl Command Actually Flows Through the System

1. kubectl sends a request to the API SERVER 2. API server validates it and writes the desired state to ETCD 3. SCHEDULER notices an unscheduled pod, assigns it to a node, writes that decision back via the API server 4. KUBELET on that node notices (watching the API server) it has a new pod assigned 5. Kubelet instructs the CONTAINER RUNTIME to pull the image and start the container 6. Kubelet continuously reports the pod's actual status back through the API server, closing the loop

Every component named earlier in this chapter has a specific, concrete role in that sequence.

High Availability for the Control Plane

Production clusters typically run multiple control plane nodes — particularly multiple etcd instances forming a quorum — specifically to avoid the control plane becoming a single point of failure. Managed Kubernetes services (EKS/AKS/GKE, per cloud1-2's own naming) typically handle this control-plane redundancy for you — a genuinely reassuring point for anyone worried about needing to manage this complexity by hand.

etcd loss is genuinely catastrophic
etcd holds the cluster's entire state. Losing etcd data without a backup means losing the cluster's complete record of what should exist — a real operational risk worth taking seriously from day one, not an abstract architecture detail.

Hands-On Exercises

Exercise 1

If the control plane becomes temporarily unavailable while worker nodes remain healthy, explain what happens to (a) already-running application pods and (b) the ability to schedule new pods — and why these two outcomes differ.

📄 View solution
Exercise 2

Walk through, step by step, what happens architecturally from the moment kubectl apply is run to create a new pod, to that pod actually running on a node.

📄 View solution
Exercise 3

Explain the reconciliation loop concept in your own words, and give an example — not explicitly covered in this chapter — of a scenario where this loop would automatically fix a problem without any human intervention.

📄 View solution

Chapter 2 Quick Reference

  • Control plane (decisions) vs. worker nodes (where containers actually run) — losing the control plane doesn't stop already-running pods
  • API server (front door) · etcd (entire cluster state) · scheduler (assigns pods to nodes) · controller-manager (runs the reconciliation loops)
  • kubelet (per-node agent) · kube-proxy (network rules/Service abstraction) · container runtime (containerd — actually runs containers)
  • The reconciliation loop — observe, compare, act, repeat — is the mechanism behind nearly everything self-healing or declarative in Kubernetes
  • Full request flow: kubectl → API server → etcd → scheduler → kubelet → container runtime → status reported back
  • Production clusters run redundant control planes (multi-node etcd quorum); managed services (EKS/AKS/GKE) typically handle this for you
  • Next chapter: Pods — The Basic Unit — why not just containers directly, single vs. multi-container pods, the sidecar pattern