Why cluster architecture matters
Kubernetes runs containerised applications across many machines by splitting responsibilities. The Control Plane records and enforces what the cluster should look like (the desired state). Worker Nodes run the Pods and handle networking so that applications actually serve traffic. When you can trace how a request moves between these parts, everyday tasks like deploying, scaling, and troubleshooting become far more predictable—especially if you are practising alongside devops classes in bangalore.
The Control Plane: where intent becomes desired state
The Control Plane accepts changes, stores cluster state, and continuously reconciles until reality matches intent.
API Server: the entry point for all operations
The API Server (kube-apiserver) is the front door to Kubernetes. Everything goes through it: creating Deployments, reading Pod logs, updating Secrets, and listing Nodes. It performs authentication and authorisation (often via RBAC), validates request schemas, and applies admission controls that can enforce policy.
A key pattern is “watch and reconcile”. Controllers and other components watch the API for changes and react to events, which keeps the system responsive and scalable.
Etcd: the cluster’s source of truth
Etcd is a distributed key–value store that holds the persistent state of the cluster: objects such as Pods, Services, ConfigMaps, and their metadata. The API Server is the primary reader/writer to etcd; most other components interact with etcd indirectly via the API.
Because etcd contains the cluster’s memory, operational discipline matters: run it redundantly, keep latency low, and take regular snapshots. Losing etcd without a restore path often means rebuilding the cluster.
Worker Nodes: where workloads execute
Worker Nodes host your application Pods. Two components make a node participate in the cluster: kubelet and kube-proxy.
Kubelet: the node agent that runs Pods
Kubelet runs on every worker node. It registers the node, watches for Pods assigned to it, and ensures the containers described in each PodSpec are created and kept running. Kubelet uses a container runtime (commonly containerd) via the Kubernetes CRI. It also manages volume mounts and runs health checks (readiness and liveness probes), then reports Pod and node status back to the Control Plane.
Kube-proxy: service traffic routing on each node
Kube-proxy maintains network rules so Services can route traffic to healthy Pods. In many clusters, it programs iptables or IPVS rules. When traffic targets a Service virtual IP, these rules forward it to one of the Service’s Pod endpoints, providing basic internal load balancing.
The interaction flow: from a manifest to running containers
The Control Plane and nodes cooperate through a feedback loop. A typical deployment looks like this:
- You submit a manifest (for example, a Deployment) using kubectl or a CI pipeline. The request reaches the API Server.
- The API Server validates it, checks permissions, and writes the desired state into etcd.
- Controllers notice the change and create the required objects (ReplicaSets and Pods) to satisfy the desired state.
- The scheduler selects a suitable node for each unscheduled Pod and records the binding via the API Server.
- Kubelet on the chosen node sees the assignment, pulls images, creates containers through the runtime, attaches volumes, and starts the Pod.
- As Pods become ready, endpoints update, and kube-proxy refreshes rules so Services route traffic to the new Pods.
The same loop powers self-healing. If a container crashes, the kubelet restarts it. If a node disappears, controllers create replacement Pods and the scheduler places them elsewhere.
Operational implications you can apply immediately
Mapping symptoms to components speeds up diagnosis:
- API calls failing often point to API Server health, certificates, or network reachability.
- Slow rollouts can correlate with etcd latency, because writes and watches depend on it.
- Pods stuck in Pending usually indicate scheduling constraints or resource pressure.
- Pods running but unreachable often involve Services, endpoints, or kube-proxy rules.
Conclusion
Kubernetes cluster architecture is built on a clear contract: the Control Plane (API Server and etcd) stores and enforces the desired state, while Worker Nodes (kubelet and kube-proxy) execute that state and move traffic correctly. When you can follow a change from the API Server into etcd, through scheduling, down to kubelet, and finally through kube-proxy routing, you gain a practical mental model for operating Kubernetes with confidence—skills many learners sharpen through devops classes in bangalore.