Kubernetes Architecture

Every Kubernetes cluster is really two very different populations of machine working together: a small control plane that decides what should be running, and a larger set of nodes that actually run it. What Is Kubernetes, and Why covered why that split exists at all; this page opens the box and names every part inside it. On the control-plane side that's kube-apiserver (the single front door), etcd (the one place state is durably stored), kube-scheduler (which node a new Pod lands on), kube-controller-manager (the control loops that keep reality honest), and cloud-controller-manager (the seam to whatever cloud the cluster runs on). On every node that's kubelet, kube-proxy, and a container runtime reached through the CRI. None of these eight names are optional vocabulary — CKA's very first exam domain is built entirely on knowing what each one does and doesn't do.

The shape of a cluster: control plane and nodes

☺ Like you're 10: A cluster is a school with one office that plans the day and a bunch of classrooms that actually run it — lose the office for an hour and every class already in session keeps right on going.

A control-plane machine and a worker node run the same underlying software (a kubelet, a container runtime) but do fundamentally different jobs. The control plane holds the cluster's decisions — what should exist, where it should run — while nodes hold the cluster's work, the actual containers serving traffic. A lab cluster (kind, minikube) can squeeze both roles onto one machine; a real production cluster keeps them apart, and by default a control-plane node carries a taint (node-role.kubernetes.io/control-plane:NoSchedule) specifically so ordinary workloads don't land on it and compete with the components that run the whole cluster.

Whether you ever see the control plane at all depends on who manages it. Self-managed clusters built with kubeadm run every control-plane component as an ordinary-looking Pod in the kube-system namespace, visible to kubectl get pods like anything else. Managed offerings — EKS, GKE, AKS — run the control plane in infrastructure you don't have SSH access to and never see with kubectl at all; you get an API endpoint and a bill, and the cloud vendor owns everything behind it. Both are "Kubernetes architecture" in the sense this page describes — only who operates the five boxes on the left of the diagram below changes.

kube-apiserver: the one front door

☺ Like you're 10: The apiserver is the front-desk clerk everyone has to go through — nobody else is allowed to walk into the archive room and change the master script themselves.

kube-apiserver is a stateless HTTP server that implements the Kubernetes API. Every read and every write in the cluster — a person running kubectl, the scheduler, a controller, a kubelet, another cluster's federation tooling — goes through it, and it is the only component with a client connection to etcd. Nothing else, not even kube-scheduler, is allowed to read or write cluster state directly; that single choke point is what makes the rest of the architecture enforceable.

A request passing through kube-apiserver goes through the same pipeline every time: authentication (who are you — client certificate, bearer token, OIDC), authorization (are you allowed to do this — almost always RBAC on a modern cluster, see RBAC & admission control), admission control (built-in and webhook plugins that can mutate or outright reject an otherwise-valid object — NodeRestriction, ResourceQuota, a policy engine like Kyverno or OPA Gatekeeper), and finally schema validation against the object's OpenAPI definition. Only an object that survives all four stages ever reaches etcd. Because kube-apiserver keeps no state of its own between requests, it's trivial to scale horizontally — production clusters run several replicas behind a load balancer purely for availability, with no coordination needed between them.

etcd: the cluster's one source of truth

☺ Like you're 10: etcd is the filing cabinet with every fact about the cluster in it, and the clerk (apiserver) is the only one with a key.

etcd is a distributed, strongly-consistent key-value store, and it holds every object in the cluster — every Pod, Deployment, Secret, and Node — as a key under a path like /registry/pods/default/checkout-api-7d4f9. It reaches consistency across its members using the Raft algorithm: a write is only acknowledged once a majority of etcd members have durably recorded it, which is exactly why etcd runs with an odd number of members — three tolerates one member's loss, five tolerates two, and an even number buys you nothing extra while adding a member that can vote in ties. Because every write requires a majority round-trip and a disk fsync, etcd is unusually sensitive to slow storage; production guidance is a dedicated fast SSD, low network latency between members, and ideally etcd on its own machines separate from the rest of the control plane once a cluster gets large.

etcd is also the cluster's single point of total failure in a way nothing else is: lose a majority of etcd members permanently and you lose the cluster's entire memory of what should exist, even though the Pods that were already running keep running for a while. That's why etcdctl snapshot save — and practicing the matching snapshot restore — is genuinely operational, not academic, and shows up directly in CKA's Cluster Architecture, Installation & Configuration domain.

# On a kubeadm cluster, control-plane components are ordinary Pods in kube-system
kubectl get pods -n kube-system -o wide

# The kubelet on a control-plane node starts them straight from static manifests
# on disk — no scheduler involved, because at bootstrap there's nothing to
# schedule onto yet.
ls /etc/kubernetes/manifests/
# etcd.yaml  kube-apiserver.yaml  kube-controller-manager.yaml  kube-scheduler.yaml

# etcd's own health, queried through its client port on that node
kubectl -n kube-system exec etcd-control-plane-1 -- \
  etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint health

# A real backup — the single most important control-plane habit to automate
etcdctl snapshot save /backup/etcd-$(date +%F).db

kube-scheduler: deciding where a Pod runs

☺ Like you're 10: The scheduler is the director picking which soundstage shoots a scene — it never picks up a camera itself, it just writes the stage number on the call sheet.

kube-scheduler watches kube-apiserver for Pods whose .spec.nodeName is still empty — "unscheduled" Pods — and runs each one through two phases: filtering, which throws out every node that can't possibly work (not enough free CPU or memory for the Pod's requests, a taint the Pod doesn't tolerate, a node selector or required affinity rule that doesn't match, a hostPort already in use), and scoring, which ranks the nodes that survive filtering by things like how evenly resources would end up spread and how far the Pod sits from others it should stay near or away from. The scheduler then does exactly one thing with the winner: it writes a Binding back through kube-apiserver, setting nodeName. It never contacts a node directly, never starts a container, and has no idea whether the Pod it just placed will actually come up healthy — that's someone else's job, covered in full in Scheduling & Resource Management.

kube-controller-manager: the control loops

☺ Like you're 10: The floor manager doesn't do the filming — it just keeps walking the lot, comparing "what should be shooting" against "what's actually shooting," and fixing any gap it finds.

kube-controller-manager is a single binary that bundles dozens of independent control loops, each one watching kube-apiserver for one kind of object, comparing its recorded desired state against the observed actual state, and issuing further API calls to close any gap — the same reconciliation pattern the object model and the API & controller pattern cover in depth. A Deployment controller turns a Deployment into the right number of ReplicaSets; a ReplicaSet controller turns each of those into the right number of Pods; a Job controller tracks completions; an endpoint controller keeps Service membership current. The Node controller deserves a special mention: it watches the Lease object each kubelet renews as a heartbeat, marks a Node NotReady once heartbeats stop arriving past a grace period, and — after a further wait — starts evicting that node's Pods so they get rescheduled elsewhere, the mechanism underneath most "a node went dark and my Pods moved" incidents covered in the troubleshooting methodology page.

cloud-controller-manager: the seam to the cloud

☺ Like you're 10: This is the liaison who deals with the landlord — if your studio doesn't rent a lot from anybody, you don't need one.

Cloud-specific logic used to live inside kube-controller-manager itself, which meant every cloud vendor's code shipped inside core Kubernetes. cloud-controller-manager was split out specifically to end that: it's a separate binary that bundles only the controllers that need to call out to a cloud provider's own API — a node controller that checks whether a Node's backing VM still exists and removes the Node object if it doesn't, a route controller that programs cloud-network routing for Pod CIDRs where the cloud needs that, and a service controller that provisions an actual cloud load balancer the moment someone creates a Service of type LoadBalancer.

Unlike the other four components, cloud-controller-manager is genuinely optional. A bare-metal kubeadm cluster runs correctly with none at all — you simply lose the automatic cloud load balancer, which is exactly the gap tools like Cilium or MetalLB step into for on-prem clusters. On EKS, GKE, and AKS it runs as an invisible part of the managed control plane, quietly turning your Service objects into real load balancers in the background.

Node components: kubelet, kube-proxy, and the container runtime

☺ Like you're 10: The stage manager reads the call sheet and gets the cameras rolling; the mail router makes sure "Stage 3" always finds Stage 3; the crew with the actual equipment is who presses record.

Every node — control-plane or worker — runs the same three pieces, and none of them are Pods themselves; they're processes the operating system starts directly (typically as systemd units), because something has to exist before there's anything to run Pods with in the first place.

• kubelet registers its Node with kube-apiserver, then watches for any Pod whose nodeName now matches its own — the Binding kube-scheduler wrote. For each one it drives the container runtime to pull images and start containers, continuously runs the Pod's liveness, readiness, and startup probes, and reports both Node and Pod status back to kube-apiserver. It also terminates the proxied exec/logs/port-forward connections mentioned above. What kubelet is not is a controller in the etcd-reconciling sense — it only ever concerns itself with Pods bound to its own node, never the whole cluster.
• kube-proxy runs on every node and watches kube-apiserver for Service and EndpointSlice objects, then programs that node's packet-forwarding rules — historically iptables, increasingly IPVS or eBPF, and on some clusters replaced entirely by the CNI in "kube-proxy-replacement" mode — so traffic sent to a Service's stable ClusterIP gets load-balanced to whichever backing Pods are currently healthy, wherever they've most recently been rescheduled. The full mechanics of that, plus the CNI plugin that gives every Pod its IP in the first place, live in Networking & the CNI.
• Container runtime is the thing that actually creates the Linux namespaces and cgroups and starts a container process — containerd or CRI-O today (Kubernetes dropped built-in support for talking to plain Docker, "dockershim," in version 1.24). It speaks the Container Runtime Interface (CRI), a gRPC API, to kubelet, and typically shells out to a lower-level OCI runtime like runc to do the actual isolation work — the same namespaces-and-cgroups mechanism covered from the container side in DevOps' containers & orchestration page.

Putting it together: a Pod's journey through the architecture

☺ Like you're 10: One request touches almost every box on this page, in order, and the last box calls all the way back to the first one to say "done."

Run kubectl apply -f pod.yaml and here's everywhere that request actually goes before a container is running: kube-apiserver authenticates, authorizes, and admission-controls the request, then commits the new Pod object to etcd with no nodeName set. kube-scheduler, watching for exactly that, filters and scores the nodes and writes a Binding back through kube-apiserver, which persists the chosen nodeName to etcd. The kubelet on that specific node — watching kube-apiserver for Pods bound to itself — notices the new assignment and calls the container runtime over CRI to pull the image and start the container. Once it's up, kubelet reports the Pod's status back to kube-apiserver, which writes that final state to etcd too. Nine hops, one Pod, and etcd is the only thing any of them ever touched directly — always through apiserver.

This page is the map, not the territory underneath it. Control Plane Internals walks the same five components at implementation depth — watch mechanics, leader election, the reconciler pattern in code — and if you want to see this whole architecture treated as the foundation you build an internal developer platform on top of, Platform Engineering's Kubernetes as the Platform Substrate goes further still. If Pod, Deployment, and Service are still unfamiliar words rather than architecture, The Object Model is the very next page, and covers them from Kubernetes' own declarative-API side.