2 Kubernetes Cluster Architecture

Kubernetes Cluster Architecture is the arrangement of machines, processes, and communication pathways that together form a working Kubernetes deployment, divided into a control plane that makes decisions and a set of worker nodes that execute those decisions by running containerized workloads.

Two-Tier Structure

Control Plane

The control plane is the brain of the cluster. It does not run application workloads directly; instead, it exposes the API, stores cluster state, schedules work, and continuously reconciles the actual state of the cluster with the desired state declared by users. In production clusters, the control plane is typically replicated across multiple machines for high availability.

Worker Nodes

Worker nodes are the machines, virtual or physical, where application containers actually execute. Each worker node runs the agents necessary to receive instructions from the control plane, start and stop containers, and report status back.

Control Plane Components in Detail

kube-apiserver

The API server is the single entry point for all cluster operations. Every other component, including kubectl, the scheduler, and the controllers, communicates with the cluster exclusively through the API server, which validates requests and persists changes to the cluster store.

etcd

etcd is a distributed, consistent key-value store that holds the entire state of the cluster, including every object definition and its current status. Because etcd is the single source of truth, its availability and consistency are critical to overall cluster health.

kube-scheduler

The scheduler watches for newly created Pods that have not yet been assigned to a node and selects an appropriate node for each one, based on resource availability, constraints, taints and tolerations, and affinity or anti-affinity rules.

kube-controller-manager

The controller manager runs a collection of controller processes bundled into a single binary for operational simplicity, including the node controller, replication controller, endpoints controller, and service account controller, each responsible for a different reconciliation loop.

cloud-controller-manager

When running on a cloud provider, the cloud controller manager integrates cluster operations with provider-specific APIs, such as provisioning load balancers, attaching storage volumes, and labeling nodes with cloud metadata.

Worker Node Components in Detail

kubelet

The kubelet is the primary agent running on every node. It reads Pod specifications assigned to its node and ensures the described containers are running and healthy, reporting node and Pod status back to the control plane.

Container Runtime

The container runtime is the underlying software that pulls container images and executes containers, implementing the Container Runtime Interface (CRI) so Kubernetes can support multiple runtimes such as containerd or CRI-O interchangeably.

kube-proxy

kube-proxy maintains network rules on each node that allow network communication to Pods from inside or outside the cluster, implementing the virtual IP mechanism used by Services.

Communication Flow

All components other than etcd communicate through the API server rather than directly with one another, which keeps the system loosely coupled and makes the API server a natural point for authentication, authorization, and admission control.

High Availability Considerations

Replicated Control Planes

Production clusters typically run at least three control plane nodes so that the loss of a single node does not interrupt cluster operations. etcd itself relies on a quorum-based consensus protocol, meaning an odd number of members is used to avoid split-brain scenarios.

Node Failure Handling

If a worker node stops reporting to the control plane within a configured timeout, the node controller marks it as unhealthy, and any Pods scheduled there are eventually rescheduled onto healthy nodes.

Managed vs. Self-Hosted Architectures

Many organizations run Kubernetes through managed offerings from cloud providers, where the control plane is operated and secured by the provider and users are only responsible for worker nodes and workloads. Self-hosted clusters, by contrast, require operators to manage the full control plane themselves, offering more flexibility at the cost of additional operational responsibility.