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.
Cricket analogy: The control plane is like the match officials and scorers making global decisions (DRS calls, over limits), while worker nodes are the two teams actually playing on the pitch; small local matches might combine roles, but big tournaments keep them separate.
kube-apiserver
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.
Cricket analogy: kube-apiserver is like the on-field umpire who is the sole point of contact for every appeal and decision, the only one who consults the third umpire (etcd) directly; every player and coach interacts with the match exclusively through the umpire.
etcd
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.
Cricket analogy: etcd is like the official scorebook that holds the single source of truth for every run, wicket, and over bowled; if the scorebook is lost, the match's entire recorded history is gone, which is why scorers keep backups.
kube-scheduler and kube-controller-manager
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.
Cricket analogy: kube-scheduler is like the team selector assigning an uncapped player to their first match based on form and conditions; kube-controller-manager is like the various team departments (fitness, discipline, replacements) continuously monitoring the squad and taking corrective action.
Worker Node Components
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.
Cricket analogy: Each worker node is like a playing squad with a captain (kubelet) ensuring every named player takes the field and reports fitness, a communications officer (kube-proxy) routing messages between fielders, and the actual playing conditions (container runtime) where the game physically happens; in a franchise league (managed service), the board runs the tournament structure invisibly.
# List the nodes in the cluster along with their role and status
kubectl get nodes -o wide
# Inspect a specific node in detail, including allocated resources
kubectl describe node worker-node-1
# View the control-plane components running as pods (in kubeadm clusters)
kubectl get pods -n kube-systemHow a Request Flows Through the Cluster
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.
Cricket analogy: Running kubectl apply is like a captain submitting a team sheet to match officials, who validate it, log it in the official record, and dispatch the twelfth man to check that every player is on the field, reporting status back through the chain — never editing the official scorebook directly.
- The control plane includes kube-apiserver, etcd, kube-scheduler, and kube-controller-manager.
- kube-apiserver is the sole entry point for all communication with the cluster; it is the only component that talks to etcd.
- etcd is the distributed key-value store holding all cluster state and is critical to back up.
- kube-scheduler assigns unscheduled pods to nodes based on resource needs and constraints.
- Worker nodes run kubelet (manages pod lifecycle), kube-proxy (networking rules), and a container runtime (executes containers).
- All state changes flow through kube-apiserver, which persists them to etcd.
Practice what you learned
1. Which component is the only one that communicates directly with etcd?
2. What is the primary responsibility of kube-scheduler?
3. Which worker node component ensures that containers described in a pod's spec are actually running and healthy?
4. What is etcd's role in a Kubernetes cluster?
5. Which component implements the Service networking abstraction on each worker node?
Was this page helpful?
You May Also Like
What Is Kubernetes?
An introduction to Kubernetes as a container orchestration platform that automates deployment, scaling, and management of containerized applications.
kubectl Basics
A practical introduction to kubectl, the command-line tool used to interact with a Kubernetes cluster's API server.
Pods Explained
An explanation of Pods, the smallest deployable unit in Kubernetes, covering their structure, lifecycle, and a minimal manifest example.
Namespaces and Resource Quotas
Understand how Kubernetes Namespaces provide multi-tenant isolation and how ResourceQuotas and LimitRanges enforce fair compute usage across teams.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics