Kubernetes Architecture

A Kubernetes cluster is made up of a control plane, which makes global decisions about the cluster, and one or more worker nodes, which run the actual application workloads. The control plane consists of several components that together manage cluster state: kube-apiserver, etcd, kube-scheduler, and kube-controller-manager (plus cloud-controller-manager in managed environments). These typically run on dedicated control-plane nodes, though small clusters may share nodes with workloads.

The kube-apiserver is the front door to the cluster. It exposes the Kubernetes REST API, validates and processes requests (from kubectl, controllers, or other clients), and is the only component that talks directly to etcd. Every other component -- including kubectl -- interacts with the cluster exclusively through the API server.

etcd is a distributed, consistent key-value store that holds all cluster state: what objects exist, their desired configuration, and current status. It is the single source of truth for the cluster. Losing etcd data effectively means losing the cluster's state, which is why etcd backups are critical in production.

kube-scheduler watches for newly created pods that have no node assigned and selects a suitable node for them based on resource requirements, constraints, and affinity rules. kube-controller-manager runs the various controller processes (such as the node controller, replication controller, and endpoints controller) that continuously watch cluster state via the API server and take action to drive actual state toward desired state.

Each worker node runs three key components: kubelet, kube-proxy, and a container runtime. kubelet is an agent that ensures containers described in PodSpecs are running and healthy on that node, reporting node and pod status back to the control plane. kube-proxy maintains network rules on each node that enable communication to pods from inside or outside the cluster, implementing the Service abstraction. The container runtime (such as containerd or CRI-O) is the software that actually pulls images and runs containers, communicating with kubelet via the Container Runtime Interface (CRI). In managed services like EKS, GKE, or AKS, the cloud provider operates the control plane and largely hides it from the user.

When you run 'kubectl apply -f pod.yaml', kubectl sends the manifest to kube-apiserver, which authenticates and validates the request, then persists the desired state in etcd. kube-scheduler notices the unscheduled pod, picks a node, and writes that assignment back through the API server. kubelet on the chosen node observes the assignment, and instructs the container runtime to pull the image and start the container. Status updates flow back through kubelet to the API server and into etcd. Never edit etcd data directly or bypass the API server to change cluster state -- doing so can leave the cluster in an inconsistent state that controllers cannot reconcile correctly.