Kubernetes Architecture

The API Server is the single entry point for everything in Kubernetes. Every single request — from you running a kubectl command, from the scheduler placing a Pod, from the controller manager checking state — goes through the API Server first.

It's a REST API. When you type kubectl get pods, kubectl is really making an HTTP GET request to the API Server. The API Server authenticates your request, checks if you have permission to do it, and then reads from or writes to etcd.

etcd (pronounced "et-see-dee") is the cluster's single source of truth. Every piece of state in your Kubernetes cluster — every Pod, every Deployment, every ConfigMap, every Service, every node — is stored as a key-value pair inside etcd.

Only the API Server talks to etcd directly. No other component is allowed to read or write to it — they all have to go through the API Server. This keeps etcd consistent and protected.

etcd is distributed, which means it typically runs as a cluster of three or five nodes itself. If one of them fails, the others can still serve reads and elect a new leader. Losing etcd without a backup means losing your entire cluster's state — which is why backing up etcd is one of the most important operational habits you'll learn in Lesson 57.

The Scheduler has one job: when a new Pod needs to run, the Scheduler decides which worker node it goes on. It looks at each Pod's resource requirements (how much CPU and memory it needs), checks which nodes have enough spare capacity, considers any rules you've set (like "this Pod must run in a specific zone"), and then assigns the Pod to the best available node.

Importantly, the Scheduler doesn't start the Pod. It just writes the assignment into etcd via the API Server. The kubelet on the chosen node notices this assignment and actually starts the container.

The Controller Manager runs a collection of background processes called controllers. Each controller watches a specific type of Kubernetes object and makes sure reality matches what you declared. The most important ones are:

The kubelet is the main agent that runs on every worker node. It's the only control plane component that runs on worker nodes rather than the dedicated control plane machines.

The kubelet watches the API Server for any Pods that have been assigned to its node. When it sees a new assignment, it tells the container runtime (containerd or Docker) to pull the image and start the container. It then monitors the container's health, reports back to the API Server regularly, and restarts containers that fail their health checks.

If the kubelet on a node stops responding, the control plane assumes that node is dead and begins rescheduling its Pods to other healthy nodes.

kube-proxy runs on every node and maintains the network rules that allow Pods to communicate with each other across the cluster — and allow traffic from outside the cluster to reach your Pods.

When you create a Kubernetes Service (a stable address for a group of Pods), kube-proxy sets up routing rules on every node so that any Pod on any node can reach that Service. It also handles load balancing — spreading traffic across all the healthy Pods behind a Service.

In modern clusters, kube-proxy often works using iptables or ipvs rules in the Linux kernel — it's doing all of this at a very low level, which is what makes it fast.

The container runtime is the software that actually pulls container images and starts containers on the node. The kubelet tells it what to do — the runtime does the low-level work of creating isolated processes, setting up the filesystem, and managing network namespaces.

Most clusters today use containerd. It's lightweight, fast, and purpose-built for this job. You as a developer rarely interact with it directly — the kubelet handles that layer.

Notice that at no point did any component directly tell another component what to do in real time. Every component just watches the API Server (which reads from etcd) and reacts to what it sees. The Scheduler doesn't call the kubelet. The kubelet doesn't call containerd and wait for confirmation. They all independently watch for their piece of the puzzle.

This pattern is called level-triggered reconciliation — each component continuously checks "is reality matching what etcd says it should be?" and takes action when it's not. This is what makes Kubernetes resilient — any component can crash and restart without losing state, because the state lives in etcd, not in the components themselves.

A lot of people learn the component names and think they understand the architecture. The deeper insight is this: Kubernetes never directly issues commands. It stores intentions in etcd, and every component independently acts to make reality match those intentions. There's no central orchestrator barking orders in real time.

This is why Kubernetes is so resilient. You can lose the Scheduler, restart it, and it just picks up where it left off. You can lose the Controller Manager and restart it — same thing. Even if the entire control plane goes offline temporarily, all the containers already running on worker nodes keep running. The kubelet doesn't need the control plane to keep existing containers alive — it only needs it to receive new instructions.

Up Next · Lesson 5

Master Node Components

We zoom right in on the control plane and go deep on each component — how they're configured, how they fail, and how to keep them healthy in production.