2.2 Worker Node Architecture & Node Components

2.2 Worker Node Architecture & Node Components

Worker nodes form the execution layer of a Kubernetes cluster. While the control plane manages cluster state and scheduling decisions, worker nodes provide the underlying compute, memory, storage, and networking resources required to run containerized workloads. Each worker node runs three core runtime components: the Kubelet, kube-proxy, and an Open Container Initiative (OCI) compliant container runtime.

---

1. Kubelet (Primary Node Agent)

The Kubelet is the primary node-level daemon that runs on every worker node. Unlike most Kubernetes workloads, the Kubelet runs directly on the host operating system as a systemd service rather than inside a container.

Core Functions & Workflow

1. Node Registration: Upon startup, the Kubelet registers the host worker node with kube-apiserver, reporting host hardware specs, allocatable resources, kernel versions, and architecture.
2. PodSpec Reconciliation: The Kubelet listens to kube-apiserver for PodSpecs assigned to its host (spec.nodeName == hostName). It ensures that containers defined in the PodSpec are created, started, and maintained in the running state.
3. CRI Interfacing: The Kubelet communicates with the local container runtime over a local Unix domain socket using the gRPC-based Container Runtime Interface (CRI).
4. Health Probe Execution: The Kubelet actively monitors container health by executing configured Liveness, Readiness, and Startup probes, taking action (such as restarting failed containers) when probes fail.
5. Status Reporting: Periodically updates the API Server with Pod status changes (e.g., Running, Failed, Terminated) and resource usage metrics.

Static Pods

While most Pods are created by control plane controllers and assigned by kube-scheduler, Static Pods are managed directly by the Kubelet on a specific node without control plane intervention.

• Configuration: The Kubelet watches a designated host directory (configured via the staticPodPath parameter in kubelet-config.yaml, typically /etc/kubernetes/manifests).
• Lifecycle: Any valid Pod YAML file placed in this directory is automatically instantiated as a Pod by the Kubelet. If the file is removed, the Kubelet terminates the Pod.
• Use Case: Bootstrapping tools like kubeadm rely on Static Pods to launch self-hosted control plane components (kube-apiserver, etcd, kube-scheduler, kube-controller-manager) on master nodes.
• Mirror Pods: The Kubelet automatically creates a read-only Mirror Pod in kube-apiserver for each static pod so it remains visible via kubectl get pods.

---

2. kube-proxy (Network Proxy)

kube-proxy is the network agent running on each node (typically deployed as a DaemonSet). It maintains network rules on the host to implement the Kubernetes Service abstraction, enabling load balanced communication across Pod endpoints.

Operational Modes

kube-proxy supports several backends. On Linux nodes the current modes are iptables, ipvs, and nftables; Windows nodes use kernelspace. The legacy userspace mode was removed in Kubernetes v1.26, and the ipvs mode was deprecated in v1.35.

                    +------------------------------------+ 
                    |         Service ClusterIP          | 
                    |            10.96.0.10              | 
                    +-----------------+------------------+ 
                                      | 
                       kube-proxy Rule Translation 
                                      | 
            +-------------------------+-------------------------+ 
            | (iptables / IPVS / eBPF Kernel Redirection)       | 
            v                                                   v 
  +-------------------+                               +-------------------+ 
  |   Pod Endpoint 1  |                               |   Pod Endpoint 2  | 
  |    10.244.1.15    |                               |    10.244.2.28    | 
  +-------------------+                               +-------------------+ 

1. iptables mode (the long-standing Linux default): kube-proxy writes Linux iptables rules into the host kernel. When traffic targets a ClusterIP, Netfilter hooks perform random target selection and forward packets directly to backing Pod IPs without entering user space. Rules are evaluated sequentially in roughly O(n) time, so rule-set updates and packet processing degrade in clusters with many thousands of Services.
2. IPVS mode (IP Virtual Server): Built on Netfilter hooks like iptables, but backed by kernel hash tables giving roughly O(1) lookup regardless of Service count. It supports several load-balancing algorithms (round-robin, least connection, destination hashing). IPVS was deprecated in Kubernetes v1.35 in favour of the nftables backend.
3. nftables mode: The modern successor to the iptables backend, using the kernel's nftables subsystem for far better scaling of both rule updates and packet processing on large clusters.
4. kernelspace mode: The Windows-node equivalent, programming forwarding rules in the Windows kernel.
5. eBPF dataplanes (kube-proxy replacement): Strictly speaking not a kube-proxy mode. CNI plugins such as Cilium can replace kube-proxy entirely, attaching eBPF programs to kernel socket and network hooks and eliminating the iptables/nftables rule set altogether.

The legacy userspace mode — which proxied every packet through a user-space socket managed by kube-proxy — was removed in Kubernetes v1.26. It still appears in older study material as "the slow mode"; it is no longer a valid answer for a current cluster.

---

3. Container Runtime Interface (CRI)

The Container Runtime Interface (CRI) is a plugin API that enables the Kubelet to use a variety of container runtimes without needing to recompile the Kubernetes codebase.

Architecture & Services

CRI standardizes gRPC service calls over Unix sockets into two primary interfaces:

• RuntimeService: Handles pod sandbox creation, container lifecycle operations (start, stop, remove), and execution commands (exec, attach, port-forward).
• ImageService: Manages container image operations (pulling, listing, inspecting, and deleting images).

Runtime Layers

• High-Level Runtimes: Manage image pulling, unpacking, container supervision, and storage hooks. Prominent implementations include containerd (CNCF graduated runtime derived from Docker) and CRI-O (lightweight runtime purpose-built for Kubernetes).
• Low-Level Runtimes: Implement Open Container Initiative (OCI) runtime specs to interact with Linux kernel cgroups and namespaces. The standard implementation is runc. Sandboxed low-level runtimes include gVisor (Google application kernel sandbox) and Kata Containers (lightweight VM isolation).

---

4. Container Network Interface (CNI)

Kubernetes requires a flat, non-NAT network model where:

1. Every Pod receives its own unique IP address.
2. Pods on any node can communicate with Pods on all other nodes without Network Address Translation (NAT).
3. Node agents (Kubelet) can communicate with all Pods on that node.

The Container Network Interface (CNI) is a CNCF specification that standardizes how network plugins configure network interfaces when containers are created or destroyed.

---

5. Node Status & Conditions

The Kubelet periodically reports host health status to kube-apiserver. Node health is represented via Node Conditions:

• Ready: True if the node is healthy and ready to accept Pods; False or Unknown if the node is uncommunicative.
• MemoryPressure: True if host memory falls below the eviction threshold.
• DiskPressure: True if root filesystem or image filesystem capacity is critically low.
• PIDPressure: True if process IDs on the host are exhausted.
• NetworkUnavailable: True if node networking overlay is incorrectly configured.

To optimize control plane performance, Kubernetes uses Node Leases (stored in the kube-node-lease namespace). The Kubelet renews its Lease every 10 seconds by default — a very small write compared with a full NodeStatus update — and the control plane treats the node as unhealthy once the Lease goes unrenewed for the lease duration (40 seconds by default). Heavier NodeStatus object updates are reserved for significant state transitions.