Skip to content

Architecture

First PublishedByAtif Alam

A Kubernetes cluster has two layers: the control plane (the brain) and worker nodes (where your containers actually run).

Control Plane

Section titled “Control Plane”

The control plane makes global decisions (scheduling, detecting failures, responding to events). It usually runs on dedicated nodes.

  • API Server (kube-apiserver) — The front door. Every kubectl command, every internal component, and every external integration talks to the cluster through the API server (REST over HTTPS).
  • etcd — A distributed key-value store that holds all cluster state (what pods exist, what nodes are available, config). The single source of truth.
  • Scheduler (kube-scheduler) — Watches for newly created pods with no assigned node and picks the best node based on resource requirements, affinity rules, and constraints.
  • Controller Manager (kube-controller-manager) — Runs a set of controllers (loops) that watch cluster state and make changes to move toward the desired state. Examples: ReplicaSet controller (ensures the right number of pods), Node controller (detects when a node goes down).

Worker Nodes

Section titled “Worker Nodes”

Each worker node runs your application containers and reports back to the control plane.

  • kubelet — An agent on every node. It receives pod specs from the API server and ensures the described containers are running and healthy.
  • kube-proxy — Manages network rules on each node so that traffic to a Service reaches the right pods (via iptables or IPVS).
  • Container Runtime — The software that actually runs containers (e.g. containerd, CRI-O). Kubernetes talks to it through the Container Runtime Interface (CRI).

How They Fit Together

Section titled “How They Fit Together”
                      +---------------------------+
                      |      Control Plane        |
                      |                           |
   kubectl  --------> |  API Server               |
                      |     |                     |
                      |  Scheduler    Controller  |
                      |     |          Manager    |
                      |  etcd (cluster state)     |
                      +---------------------------+
                               |
              +----------------+----------------+
              |                                 |
     +--------v--------+             +----------v------+
     |   Worker Node 1 |             |   Worker Node 2 |
     |                  |             |                  |
     |  kubelet         |             |  kubelet         |
     |  kube-proxy      |             |  kube-proxy      |
     |  container       |             |  container       |
     |   runtime        |             |   runtime        |
     |                  |             |                  |
     |  [Pod] [Pod]     |             |  [Pod] [Pod]     |
     +------------------+             +------------------+
  1. You run kubectl apply -f deployment.yaml.
  2. API Server validates and stores the desired state in etcd.
  3. Scheduler notices unscheduled pods and assigns them to nodes.
  4. kubelet on the chosen node pulls the container image and starts the pod.
  5. Controllers continuously reconcile: if a pod crashes, the ReplicaSet controller creates a replacement.

Key Takeaways

Section titled “Key Takeaways”
  • The control plane is the decision-maker; worker nodes do the actual work.
  • All state lives in etcd; losing etcd means losing cluster state (back it up).
  • The API server is the single point of communication — everything goes through it.
  • Kubernetes is declarative: you describe what you want, and the system converges toward that state.