Kubernetes Architecture Explained: Nodes, Pods, and Clusters

Kubernetes Architecture Explained: Nodes, Pods, and Clusters

Modern cloud-native applications demand orchestration platforms that can manage deployment, scaling, and resilience at scale. Kubernetes has become the de facto standard for container orchestration, but its architecture—rooted in Google’s Borg system—can seem opaque without a clear mental model. This article dissects the core building blocks: Clusters, Nodes, and Pods. Understanding how these components interact is essential for designing robust, production-grade systems, whether you are a developer, SRE, or DevOps engineer.

The Kubernetes Cluster: The Logical Control Plane

A Kubernetes Cluster is the foundational unit of the platform. It is not a single machine but a logical set of machines (physical or virtual) working together as a single entity. Every cluster has two primary planes: the Control Plane (formerly called the master node) and the Data Plane (worker nodes).

The Control Plane is the brain of the cluster. It hosts critical components that make global decisions about the cluster state:

• kube-apiserver: The front door to the cluster. All administrative operations, whether via kubectl, the Kubernetes dashboard, or an API call, pass through this component. It validates and processes RESTful requests, updates the cluster state in the underlying data store, and is the only component that communicates directly with that store.
• etcd: A highly-consistent, distributed key-value store. It holds the complete state of the cluster: which Pods are running, which Nodes are healthy, ConfigMaps, Secrets, and all resource definitions. etcd is the source of truth and must be backed up regularly. In production, a three- or five-node etcd cluster is standard for fault tolerance.
• kube-scheduler: Watches for newly created Pods that have no assigned Node. It selects an appropriate Node for each Pod based on resource constraints (CPU, memory), affinity/anti-affinity rules, data locality, and custom scheduling policies. The scheduler does not run the Pod; it only assigns it to a Node.
• kube-controller-manager: A collection of controller processes bundled into a single binary. Each controller watches the current state via the API server and reconciles it towards the desired state. Key controllers include the Node Controller (managing Node health), Replication Controller (maintaining Pod replica counts), and Endpoint Controller (populating Service endpoints).

For high availability (HA), production clusters run multiple replicas of control plane components (typically three or five) across different physical or availability-zone boundaries. This ensures that if one control plane node fails, another takes over without downtime for the entire cluster.

Nodes: The Workhorses of the Cluster

Nodes are the worker machines that run your containerized applications. Each Node is a member of the Cluster and registers itself (or is registered by an administrator) with the Control Plane. A Node can be a bare-metal server, a virtual machine in a public cloud (EC2, GCE, Azure VM), or even a powerful Raspberry Pi in an edge setup.

Every Node runs three essential agents:

• kubelet: The primary node agent. It acts as the bridge between the Control Plane and the Node. The kubelet registers the Node with the API server, receives Pod specifications (PodSpecs) from the API server, ensures the containers described in those PodSpecs are running and healthy, and reports status back to the Control Plane. It does not manage containers directly; it relies on the container runtime below it.
• Container Runtime Interface (CRI): The software responsible for running containers. Kubernetes is container-runtime agnostic thanks to the CRI abstraction layer. Common runtimes include containerd (the default in many distributions), CRI-O, and Mirantis Container Runtime. Docker was historically popular but is now deprecated as a runtime from a Kubernetes perspective (though Docker images remain fully compatible).
• kube-proxy: A network proxy that runs on every Node. It maintains network rules (iptables, IPVS, or userspace) that allow communication to Pods from inside or outside the cluster. kube-proxy watches the API server for changes to Services and Endpoints, updating Node-level rules so that traffic directed to a Service IP is load-balanced across the correct backend Pods.

Node resources are CPU (measured in millicores, e.g., 500m = half a core), memory (bytes), ephemeral storage, and optionally GPUs or persistent volumes. The kubelet reports these capacities to the Control Plane. When the scheduler assigns a Pod, it considers the allocatable resources (total capacity minus system overhead).

Pods: The Atomic Unit of Deployment

A Pod is the smallest and most fundamental deployable object in Kubernetes. It represents a single instance of a running process in your cluster. Critically, a Pod is not a container—it is an envelope that wraps one or more containers.

Single-Container vs. Multi-Container Pods

Most Pods contain a single container. However, Pods are designed to support multiple tightly-coupled co-located containers that share resources. This pattern is vital for specific use cases:

• Sidecar: A helper container (e.g., a log shipper, service mesh proxy, or configuration reloader) that augments the primary application container. The sidecar shares the Pod’s network namespace and volumes.
• Ambassador: A proxy container that handles network communication to external services on behalf of the primary container.
• Adapter: A container that transforms data or output from the primary container for external consumption (e.g., reformatting logs for a monitoring system).

Pod Lifecycle and Shared Resources

Every Pod shares two key namespaces:

1. Network Namespace: All containers in a Pod share the same IP address and port space. They can communicate with each other using localhost. This is why multi-container Pods must coordinate port assignments.
2. Storage Volumes: Pods can mount Kubernetes Volumes (e.g., emptyDir, hostPath, PersistentVolumeClaim) that are accessible to all containers within that Pod. Data persists across container restarts within the Pod but not across Pod restarts (unless using persistent storage).

A Pod goes through distinct phases: Pending (accepted but not yet running), Running (at least one container is running), Succeeded (all containers terminated without error), Failed (at least one container terminated with error), and Unknown (node communication lost). Containers within a Pod can also have probes (liveness, readiness, startup) that allow Kubernetes to manage their health automatically.

How They Work Together: Scheduling and Communication

The interaction between Clusters, Nodes, and Pods defines the operational rhythm of Kubernetes.

1. Desired State Submission: A developer or CI/CD pipeline submits a Deployment manifest to the kube-apiserver. This manifest declares a desired state: “Run three replicas of a web server Pod, each requiring 250m CPU and 512Mi memory.”
2. Scheduling: The kube-scheduler sees the three unassigned Pods. It filters out Nodes that lack sufficient resources or violate taints/tolerations. It then scores the remaining Nodes based on policies (e.g., spreading Pods across nodes for fault tolerance). The scheduler assigns each Pod to a specific Node.
3. Node Assignment: The API server records the Pod-to-Node binding. The kubelet on the target Node reads the PodSpec and instructs the container runtime (e.g., containerd) to pull the required image and start the containers.
4. Networking: As containers start, the Pod receives its own IP address from the cluster’s CNI plugin (e.g., Calico, Flannel, Cilium). kube-proxy on every Node programs iptables/IPVS rules so that a Service (a stable virtual IP) can route traffic to the correct Pod IP, even as Pods are created or destroyed.
5. Continuous Reconciliation: The controllers in the control plane (e.g., the ReplicaSet controller) continuously compare the current state (how many Pods are running) with the desired state. If a Node fails and its Pods disappear, the controller creates replacement Pods on healthy Nodes, restarting the cycle.

Cluster Networking: The Invisible Glue

Three distinct networking problems are solved to make Nodes and Pods work fluidly:

• Pod-to-Pod Communication: Every Pod receives a unique, routable IP address (within the cluster network). The CNI plugin ensures Pods on different Nodes can communicate directly without Network Address Translation (NAT).
• Pod-to-Service Communication: Services provide a stable virtual IP (ClusterIP) or DNS name. kube-proxy intercepts traffic to Services and load-balances it across Pod endpoints. This abstracts away Pod IP volatility.
• External-to-Pod Communication: Ingress controllers or LoadBalancer Services expose specific Pods or applications to external traffic. They terminate external connections and route them to the appropriate internal Service and Pod.

Understanding this interplay—the control plane’s orchestration, the node’s execution, and the pod’s encapsulation—is the foundation for mastering Kubernetes. Each component is designed with a specific purpose, and their interactions create a self-healing, scalable, and portable platform that has reshaped how modern infrastructure is built and operated.