How a cluster works

The control plane decides, the nodes run. Every Kubernetes behaviour comes from controllers comparing what you asked for with what exists.

Also called control loop, declarative

What: You declare objects (a Deployment with three replicas) and controllers loop forever, comparing the declared spec with the observed status and acting to close the gap.
Why: It is why a deleted Pod comes back and why you change the cluster by editing YAML, not by running imperative steps.

Watch out

Fixing a live object by hand with kubectl edit; the next apply from Git undoes it.

Also called kube-apiserver

What: The front door of the cluster. kubectl, controllers, kubelets and CI all read and write objects through its REST API, which authenticates, authorises and validates every request.
Why: Everything in Kubernetes is an API object, so RBAC, admission policies and audit logs all sit at this one point.

What: A consistent, distributed key-value store holding every object in the cluster. Only the API server talks to it.
Why: It is the cluster's source of truth: lose etcd without a backup and you lose the cluster's state.

Watch out

Running a self-managed cluster without etcd snapshots; managed services back it up for you.

Also called kube-scheduler, kube-controller-manager

What: The scheduler assigns each new Pod to a node that fits its resource requests and constraints. The controller manager runs the built-in controllers for Deployments, ReplicaSets, Jobs, nodes and more.
Why: Knowing which component does what tells you where to look: a Pod stuck in Pending is a scheduling question.

What: The agent on every node. It watches for Pods assigned to its node, starts their containers through the container runtime, runs probes and reports status back.
Why: Restarts, probe failures and image pulls all happen in the kubelet, so its events explain most Pod problems.

Also called containerd, CRI, CNI

What: The runtime (usually containerd, through the CRI) runs containers. The CNI plugin gives each Pod an IP. kube-proxy, or a CNI such as Cilium that replaces it, routes Service traffic.
Why: Docker is not needed on nodes: any OCI image runs on containerd. Networking features like NetworkPolicy depend on the CNI you pick.

Also called EKS, GKE, AKS

What: Cloud services run and upgrade the control plane for you; you manage node pools (or let the provider manage them too) and your workloads. kind, k3d and minikube run small clusters locally.
Why: Most teams should not operate etcd and the API server themselves; the managed option frees time for the apps.

Watch out

Letting a cluster fall several minor versions behind, which makes each upgrade riskier as APIs are removed.

Go deeper