Kubernetes architecture

High-level view of Kubernetes architecture

Kubernetes is built as a distributed control system that manages containers across many machines. At a high level, the architecture is split into two main logical parts:

• Control plane: the “brain” of the cluster that makes global decisions (scheduling, scaling, health) and exposes the Kubernetes API.
• Worker nodes: the “muscle” of the cluster that actually runs your application containers.

All interaction with the cluster—whether from users, automation, or internal components—goes through the Kubernetes API. Everything else in the system reacts to the desired state stored in this API.

You’ll later see the components of the control plane and worker nodes in their own chapters; here we focus on how they fit together and why the architecture looks the way it does.

Logical vs. physical architecture

It helps to separate two perspectives:

• Logical architecture – how components interact:
• API server at the center
• Persistent cluster state in a key–value store
• Controllers that reconcile state
• Scheduler that assigns work to nodes
• Kubelet and runtimes on nodes that run workloads
• Physical architecture – what runs where:
• One or more control plane nodes running control plane components
• Many worker nodes running pods/containers
• Optional bastion/jump hosts, load balancers, and external services (like storage, identity providers, etc.)

In small demo clusters, control plane and worker roles may live on the same machine. In production, they are usually separated and the control plane is hardened.

The Kubernetes API as the core

At the center of the architecture is the Kubernetes API server and its data store:

• All cluster state is represented as API objects (Pods, Deployments, Nodes, ConfigMaps, etc.).
• Users and tools interact by sending declarative specifications to the API server.
• Other components watch the API for changes and act accordingly.

Conceptually:

1. A user (or CI system) sends a desired state, like “run 3 replicas of this application,” to the API.
2. The API server validates, stores, and exposes this state.
3. Controllers and the scheduler watch this state and make decisions (where to run pods, how to restart them, etc.).
4. Node agents (kubelets) ensure the containers actually run as described.

This “API-centric” architecture is why Kubernetes is easily extensible and why tools like kubectl, CI/CD systems, and operators can all integrate in a consistent way.

Desired state and reconciliation loop

Kubernetes architecture is built around a control loop pattern:

• Users describe the desired state in API objects.
• Current state (what’s actually running) is constantly observed.
• Controllers try to make current state match desired state.

Examples of reconciliation loops:

• A Deployment controller ensures the requested number of pod replicas exist and are updated using the specified strategy.
• A Node controller observes node health; if a node stops reporting, it marks the node as NotReady and may trigger rescheduling.

Key points:

• Controllers do not run one-time scripts; they are long-running loops:
  $$\text{loop: observe} \rightarrow \text{compare} \rightarrow \text{act}$$
• This architecture makes the system self-healing and resilient to transient failures.
• Controllers sit in the control plane; kubelets and runtimes exist on the nodes, but all coordinate via the API.

Control plane vs. data plane

Kubernetes uses a common architectural split:

• Control plane (control logic):
• Makes decisions: scheduling, scaling, replacement, admission.
• Stores cluster configuration and policy.
• Exposes the API and responds to queries/updates.
• Data plane (workload execution):
• Runs the user pods and containers.
• Forwards network traffic to/from pods.
• Mounts and uses storage.

Design consequences:

• The control plane is relatively light on CPU usage but critical for availability. It’s typically run on dedicated, protected nodes.
• Scaling workloads mostly means adding more worker nodes; the control plane can often remain unchanged for a while.
• If worker nodes fail, workloads are rescheduled; if the control plane fails entirely, the cluster cannot make new decisions, even if existing pods keep running for some time.

Cluster topology and components at a glance

A typical production cluster looks roughly like this:

• Multiple control plane nodes
• Each runs the control plane components, with one acting as current leader for certain roles.
• An external or internal load balancer sits in front of them, presenting a single API endpoint.
• Many worker nodes
• Each node runs:
• A node agent (kubelet)
• A container runtime (e.g., CRI-O, containerd)
• The Kubernetes networking component (kube-proxy) and any CNI plugins
• External dependencies
• A storage system (block/file/object) for persistent volumes
• A Certificate Authority or external identity providers
• Optionally, external load balancers or DNS for exposing services

The exact implementation details are deferred to the “Control plane components” and “Worker node components” chapters, but the architectural point is: every piece either provides or consumes the API, stores cluster state, or runs containers.

Networking and service abstraction in the architecture

Kubernetes’ architecture assumes a specific networking model:

• Every pod gets an IP address within a flat, routable cluster network.
• Pods can generally talk to each other without NAT (subject to network policy).
• Nodes can talk to pods and the API server; the API server can reach the nodes.

Within this architecture, Kubernetes provides:

• Services as stable virtual endpoints for a set of pods.
• Load distribution at L4 (and in some setups L7) via service proxies.

Architecturally, this means:

• A component on each node implements service traffic handling (commonly kube-proxy, possibly using iptables or eBPF).
• Additional ingress components may run as pods to provide external HTTP/HTTPS access.

While detailed networking is covered elsewhere, the important architectural takeaway is that networking is implemented as pluggable components attached to the nodes, not hard-coded into the core control plane.

Storage and state in the architecture

From an architectural standpoint, there are two kinds of state:

1. Cluster configuration and metadata state
• Stored in a distributed key–value store behind the API server.
• Contains API objects and configuration.
• Critical to the control plane; typically kept on control plane nodes.
2. Application data (persistent volumes)
• Provided by external storage systems through volume plugins and storage classes.
• Mounted into pods via the node’s kubelet and container runtime.
• Architecturally separate from the control plane store, to avoid mixing application data and cluster metadata.

This separation allows you to back up/restore the control plane independently of bulk application data and plug in different storage solutions without changing the core architecture.

Extensibility in the Kubernetes architecture

The architecture is designed to be extensible without modifying the core:

• Custom Resource Definitions (CRDs) allow new kinds of API objects to be defined.
• Controllers and Operators implement new reconciliation loops for these resources.
• Admission webhooks and mutating webhooks plug into the request flow at the API server level.
• CNI (Container Network Interface) and CSI (Container Storage Interface) define pluggable points for network and storage providers.

Architecturally:

• Everything still talks to the same API server.
• New capabilities are usually added by running more controllers and components as pods on the cluster, rather than changing the core binaries.
• This keeps the core architecture stable, while the behavior of the platform can be customized per environment.

Multi-cluster and higher-level control

While Kubernetes describes the architecture of a single cluster, the same patterns scale outward:

• Multiple clusters can be:
• Managed centrally through higher-level controllers.
• Connected to form hybrid or multi-cloud platforms.
• The basic pattern remains the same:
• Each cluster has its own control plane and data plane.
• External systems orchestrate multiple clusters by talking to each cluster’s API.

For this course, focus on understanding one cluster’s architecture well; later topics such as hybrid workflows and managed OpenShift will build directly on these principles.