Kubernetes Cluster Architecture Overview

Kubernetes Cluster Architecture Overview is a summary orientation to how the pieces of a Kubernetes cluster fit together: a control plane that observes and decides, a set of worker nodes that execute, and a single, shared API through which every one of those pieces communicates, with no component ever bypassing that API to talk to another directly. This overview exists to give a single, coherent mental picture before descending into the architecture of any individual component, so that later, more detailed material can be understood in terms of the roles established here.

The Two-Layer Shape

Control Plane and Data Plane

Every cluster divides cleanly into two layers: a control plane, responsible for exposing the API, storing state, scheduling, and reconciling, and a data plane of worker nodes, responsible for actually running the containers the control plane has decided should exist. Nothing in the data plane makes decisions about the cluster as a whole; nothing in the control plane runs application workloads.

The API as the Only Connective Tissue

Every interaction between these two layers, and between components within the same layer, passes through the API server. A scheduler binding a Pod to a node, a kubelet reporting that Pod's status, an operator submitting a new manifest, are all, mechanically, the same kind of operation: an authenticated read or write against the API.

Control Plane at a Glance

Its Four Jobs

The control plane's responsibilities reduce to four: exposing the API (kube-apiserver), persisting state (etcd), scheduling Pods to nodes (kube-scheduler), and reconciling actual state toward desired state (kube-controller-manager, and where relevant, cloud-controller-manager).

control_plane_components:
  - kube-apiserver       # exposes the API
  - etcd                 # persists state
  - kube-scheduler        # assigns pods to nodes
  - kube-controller-manager  # reconciles desired vs actual state

Coordination Without Direct Communication

No control plane component calls another directly; each one watches the API server for the objects relevant to its job and writes its results back through the same API server, a design that allows any one of them to be restarted, scaled, or replaced without the others needing to know.

Data Plane at a Glance

Its Three Jobs Per Node

Each worker node's role also reduces to a small set of responsibilities: running containers according to the Pods assigned to it (kubelet, working through a container runtime), routing Service traffic correctly (kube-proxy), and providing Pod-to-Pod network connectivity (a CNI plugin).

node_components:
  - kubelet            # starts/stops containers, reports status
  - container_runtime  # actually runs containers
  - kube-proxy         # implements service routing
  - cni_plugin         # provides pod networking

Nodes Are Interchangeable Capacity

From the control plane's perspective, nodes are largely interchangeable pools of CPU, memory, and storage capacity, distinguished mainly by labels, taints, and available resources; no node has inherent, permanent significance beyond what its current workload assignment gives it.

How a Change Flows Through the Architecture

From Manifest to Running Container

A single illustrative flow ties every layer together: a manifest is submitted to the API server; the API server persists it to etcd after authentication, authorization, and admission; a relevant controller observes the new object and, if it is a workload controller, creates Pods; the scheduler observes unscheduled Pods and binds them to nodes; the kubelet on each selected node observes Pods bound to it and starts their containers via the runtime; kube-proxy and the CNI plugin make the resulting containers reachable.

kubectl apply -f deployment.yaml
kubectl get pods -o wide -w

Every Step Is an Independent Reconciliation

None of the steps above are one continuous operation; each is a separate component independently reacting to a change it observed through its own watch on the API server, which is why the architecture as a whole tolerates individual component restarts without losing correctness, each component simply re-observes current state and resumes reconciling.

Topology Variations Layered on the Same Shape

Single-Node to Highly Available

This same two-layer shape underlies deployments ranging from a single-machine development cluster, where control plane and data plane roles run on the same node, to a highly available production cluster with replicated API servers behind a load balancer and a multi-member etcd cluster; only the degree of replication changes, not the architecture itself.

Managed vs. Self-Managed

Similarly, whether the control plane is operated by a cloud provider or by the cluster's own administrators changes who is responsible for it, but not its functional role within the architecture: it still exposes the same API, persists the same kind of state, and performs the same scheduling and reconciliation duties described here.

Why This Overview Matters

Holding this two-layer, API-mediated shape in mind is what makes the deeper detail of any individual component tractable: every subsequent architectural question, how the scheduler picks a node, how the kubelet enforces resource limits, how etcd maintains consistency, is really a question about how one piece fulfills its narrow role within this same overall structure, not a departure from it.