Kubernetes Architecture
Kubernetes (often shortened to “K8s” — the 8 stands for the eight letters between K and s) is a system that runs and manages your containers across many machines for you. To use it well, you need a mental model of its parts: a “brain” that decides what should run, and “workers” that actually run it. This page walks through every component so the rest of the Kubernetes docs make sense.
A cluster is the whole thing — a group of machines (called nodes) working together. Each node is a server, usually a Linux box running Ubuntu. The cluster splits into two roles: the control plane (the brain that makes decisions) and the worker nodes (the muscle that runs your apps). Small clusters can put both roles on one machine; production clusters keep them separate.
The cluster in words (a diagram you can read)
Picture it like this, top to bottom:
┌─────────────────────────────────────┐
│ CONTROL PLANE │
│ (the brain — one or more machines) │
│ │
│ kube-apiserver ── etcd │
│ kube-scheduler │
│ kube-controller-manager │
└──────────────────┬───────────────────┘
│ (instructions over the network)
┌──────────────────────────┼──────────────────────────┐
▼ ▼ ▼
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ WORKER NODE 1 │ │ WORKER NODE 2 │ │ WORKER NODE 3 │
│ kubelet │ │ kubelet │ │ kubelet │
│ kube-proxy │ │ kube-proxy │ │ kube-proxy │
│ containerd │ │ containerd │ │ containerd │
│ [ your Pods ] │ │ [ your Pods ] │ │ [ your Pods ] │
└────────────────┘ └────────────────┘ └────────────────┘You talk to the control plane (with a tool called kubectl). The control plane decides which worker should run your app, and each worker reports back on what it is actually running. That constant back-and-forth — “here’s what I want” versus “here’s what’s real” — is the heart of how Kubernetes works.
The control plane
The control plane is the brain. It never runs your application containers (in a well-set-up cluster). Its only job is to decide what should happen and keep the cluster in the state you asked for. It has four core components.
kube-apiserver
The API server is the front door to the cluster. An API (Application Programming Interface) is a defined way for programs to talk to each other. Every action — from kubectl, from the dashboard, from other components — goes through the API server. It validates requests, checks permissions, and writes the desired state into the database. Nothing in Kubernetes talks to the database directly; everything goes through the API server.
Lock the API server down. It is the single entry point to your whole cluster — if an attacker reaches it with admin rights, they own everything. Use authentication, RBAC (Role-Based Access Control), and never expose it to the public internet without TLS and tight firewall rules.
etcd
etcd is the cluster’s memory — a fast, consistent key-value store (a database that stores simple “key = value” pairs). It holds the entire state of the cluster: every Pod, every config, every secret. If etcd is lost and you have no backup, the cluster’s memory is gone. This is why backing up etcd is the single most important backup task in a self-managed cluster.
kube-scheduler
The scheduler decides which worker node a new Pod should run on. When you ask for a Pod, it starts out unassigned. The scheduler looks at every node — how much CPU and memory is free, any rules you set (like “only run on nodes with an SSD”) — and picks the best fit. It does not start the Pod; it just writes down the chosen node. The kubelet on that node takes it from there.
kube-controller-manager
A controller is a loop that watches the cluster and nudges reality toward your desired state. The controller manager runs many of these loops in one process. For example, if you asked for 3 copies of your app and one crashes, a controller notices only 2 are running and creates a replacement. This “watch, compare, fix” pattern is called a reconciliation loop, and it is why Kubernetes self-heals.
The worker nodes
Worker nodes do the real work — they run your application containers. Each worker runs three things.
Container runtime
The container runtime is the software that actually starts and stops containers. The modern default is containerd. (Docker’s old built-in runtime, dockershim, was removed in Kubernetes 1.24, so plain Docker is no longer used as the runtime — containerd or CRI-O are standard in 2026.)
kubelet
The kubelet is the agent on each node that talks to the control plane. It asks the API server “what Pods should I be running?”, then tells the container runtime to start them. It constantly reports the node’s health and each Pod’s status back up. If the kubelet on a node goes silent, the control plane assumes the node is dead and reschedules its Pods elsewhere.
kube-proxy
kube-proxy handles networking on the node. It makes sure traffic sent to a Kubernetes Service (a stable address for a set of Pods) reaches a healthy Pod, even as Pods come and go. It does this by programming the Linux networking rules (using iptables or the newer, faster nftables/IPVS).
Control plane vs worker node — quick reference
| Component | Lives on | Job |
|---|---|---|
| kube-apiserver | Control plane | Front door; every request goes through it |
| etcd | Control plane | Stores the entire cluster state |
| kube-scheduler | Control plane | Picks which node runs a new Pod |
| kube-controller-manager | Control plane | Self-healing reconciliation loops |
| kubelet | Worker node | Starts/monitors Pods on its node |
| kube-proxy | Worker node | Routes Service traffic on its node |
| containerd | Worker node | Actually runs the containers |
Seeing the components yourself
If you have a running cluster (for example a local one from local-kubernetes), you can list the nodes and the control plane components, which themselves run as Pods in the kube-system namespace:
kubectl get nodes -o wide
kubectl get pods -n kube-systemOutput:
NAME STATUS ROLES AGE VERSION
k8s-control Ready control-plane 12d v1.31.2
k8s-worker-1 Ready <none> 12d v1.31.2
k8s-worker-2 Ready <none> 12d v1.31.2
NAME READY STATUS RESTARTS AGE
etcd-k8s-control 1/1 Running 0 12d
kube-apiserver-k8s-control 1/1 Running 0 12d
kube-controller-manager-k8s-control 1/1 Running 1 12d
kube-scheduler-k8s-control 1/1 Running 1 12d
kube-proxy-7xq2v 1/1 Running 0 12dWhen to run your own control plane (and when not to)
Running the control plane yourself means installing and patching the API server, scheduler, and especially etcd, plus backing up etcd, rotating certificates, and surviving a control-plane machine failure. That is real, ongoing work.
| Approach | When to use it |
|---|---|
| Self-managed control plane | You need full control, on-prem hardware, or strict data-residency rules — and you have an ops team |
| Managed Kubernetes (EKS, GKE, AKS) | Almost everyone else — the cloud runs and backs up the control plane for you |
For most teams the answer is managed Kubernetes: you only manage the worker nodes and your apps, and the provider handles the control plane and etcd backups.
Best Practices
- Treat etcd backups as critical — schedule them and test that you can actually restore.
- Never run application Pods on control-plane nodes in production; keep the brain isolated.
- Lock down the API server with TLS, RBAC, and firewall rules; never expose it publicly.
- Run at least three control-plane nodes in production so the cluster survives one failing (etcd needs a majority to stay healthy).
- Keep the control plane and worker nodes on the same Kubernetes minor version, and upgrade the control plane first.
- Use a managed Kubernetes service unless you have a specific reason and the staff to run the control plane yourself.