Kubernetes Cluster Architecture

Kubernetes Cluster Architecture is the arrangement of machines, processes, and communication paths that together form a functioning Kubernetes cluster. A cluster is composed of a control plane, which makes and enforces decisions about the state of the system, and a data plane of worker nodes, which run the actual containerized workloads. The architecture is designed so that these two layers remain loosely coupled, communicating only through the Kubernetes API, which allows either layer to scale, fail, or be upgraded with minimal impact on the other.

Control Plane

The control plane is the brain of the cluster. It is typically deployed across multiple machines for fault tolerance, though in small or development clusters it can run on a single node.

kube-apiserver

The API server is the single entry point into the cluster's control plane. It exposes a RESTful interface over HTTPS, validates and processes requests, enforces authentication and authorization, applies admission control, and persists resulting object state to etcd. Every other control plane component, and every external client, interacts with the cluster exclusively through this API server; no component communicates directly with etcd except the API server itself.

etcd

etcd is a distributed, consistent key-value store that serves as the cluster's single source of truth. It stores the complete state of the cluster, including all object specifications and their current status. etcd uses the Raft consensus algorithm to maintain consistency across replicas, and is typically deployed as a cluster of an odd number of members (commonly three or five) to tolerate node failures while retaining quorum.

kube-scheduler

The scheduler watches the API server for Pods that have been created but not yet assigned to a node. For each such Pod, it evaluates the set of available nodes using filtering and scoring plugins, taking into account resource availability, affinity and anti-affinity rules, taints and tolerations, and topology constraints, then binds the Pod to the selected node via the API server.

kube-controller-manager

This component runs a collection of controller loops compiled into a single binary for operational simplicity, including the Node Controller, which monitors node health; the Replication Controller, which maintains the correct number of Pod replicas; the Endpoints Controller, which populates Endpoints objects for Services; and Service Account and Token Controllers, which manage default accounts and API credentials for namespaces.

cloud-controller-manager

Where a cluster runs on a supported cloud provider, this component separates cloud-specific control logic from the core cluster components, managing tasks such as provisioning load balancers, attaching storage volumes, and labeling nodes with region and zone information.

Data Plane

Nodes

A node is a worker machine, virtual or physical, that runs the components necessary to host Pods. Each node registers itself with the control plane and reports its status and capacity, allowing the scheduler to make informed placement decisions.

kubelet

The kubelet is an agent running on every node that ensures the containers described in the PodSpecs it has been assigned are running and healthy. It communicates with the container runtime via the Container Runtime Interface (CRI) to start and stop containers, reports node and Pod status back to the API server, and performs liveness, readiness, and startup probes.

kube-proxy

kube-proxy maintains network rules on each node that implement the Service abstraction, directing traffic destined for a Service's virtual IP to one of the Pods backing it. Depending on the platform, it may implement this using iptables, IPVS, or other packet-forwarding mechanisms.

Container Runtime

The container runtime is the software that actually creates and runs containers on a node, pulling container images, managing container namespaces, and enforcing resource isolation. Kubernetes interacts with any CRI-compliant runtime, such as containerd or CRI-O, through a standardized interface rather than depending on a specific implementation.

Cluster Topology Patterns

Single-Master Clusters

A single control plane node hosts all control plane components. This topology is simple to operate but represents a single point of failure and is generally reserved for development or testing environments.

High-Availability Clusters

Multiple control plane nodes run replicated instances of the API server, controller manager, and scheduler, typically fronted by a load balancer, while etcd runs as a distributed cluster across the same or dedicated nodes. Only one instance of the controller-manager and scheduler is active at a time, coordinated through a leader election mechanism built on etcd, while multiple API server instances can serve requests concurrently since they are stateless with respect to each other.

Managed Clusters

Cloud providers commonly offer managed Kubernetes services in which the control plane is operated entirely by the provider, and users are responsible only for worker nodes. This model shifts the operational burden of upgrading, securing, and scaling the control plane away from the cluster operator.

Communication Flow

# Simplified request flow for creating a Deployment
1_client: kubectl apply -f deployment.yaml
2_apiserver: authenticate, authorize, admission-control, persist-to-etcd
3_controller_manager: observe new Deployment, create ReplicaSet
4_controller_manager: observe new ReplicaSet, create Pods
5_scheduler: observe unscheduled Pods, bind to nodes
6_kubelet: observe Pods bound to its node, start containers
7_kube_proxy: update network rules for new Pod endpoints

This flow illustrates the layered, event-driven nature of cluster architecture: no single component performs the entire operation; instead, each control loop reacts only to the portion of state it is responsible for, and the aggregate effect of many independent loops produces the observed behavior of the cluster.

Network Architecture Within the Cluster

Kubernetes cluster architecture mandates a flat networking model in which every Pod is assigned a unique IP address, routable from every other Pod without network address translation. This requirement is satisfied by a pluggable Container Network Interface (CNI), allowing different networking implementations, overlay networks, routed networks, or provider-native networking, to be substituted without changing the behavior expected by workloads or the kube-proxy rules that route Service traffic to them.