2.8 Kubernetes Node Agent Architecture

Kubernetes Node Agent Architecture is the specific internal structure of the kubelet as the primary node agent, describing how its Pod synchronization loop, status reporting mechanism, and interfaces to the container runtime and storage plugins are arranged to keep a single node's actual state aligned with the Pod specifications assigned to it.

The Pod Synchronization Loop

A Per-Node Reconciliation Loop

The kubelet is architected around its own reconciliation loop, structurally similar in spirit to the controllers running in the control plane, but scoped to a single node: it continuously compares the set of Pods assigned to its node against the containers actually running there, taking action to close any gap.

Sources of Truth Feeding the Loop

This loop is architected to draw Pod specifications primarily from the API server, watched through the same mechanism used elsewhere in the cluster, though the kubelet's design also allows for additional, node-local sources of Pod specifications in specialized configurations.

Interfaces to Pluggable Subsystems

Container Runtime Interface

The kubelet is architected to delegate all actual container creation, execution, and teardown to a container runtime, communicating through the standardized Container Runtime Interface (CRI) rather than embedding runtime-specific logic directly.

Container Storage Interface

Similarly, the kubelet's architecture delegates volume attachment and mounting operations to storage drivers through the Container Storage Interface (CSI), keeping the kubelet itself independent of any particular storage backend's implementation details.

Device Plugin Interface

For specialized hardware resources, such as accelerators, the kubelet architecture exposes a device plugin interface, allowing hardware vendors to advertise available devices and have them scheduled and allocated to Pods without the kubelet needing built-in knowledge of every possible device type.

Status Reporting Architecture

Node and Pod Status as Continuous Output

The kubelet is architected to continuously compute and report both node-level status, such as overall health and resource capacity, and Pod-level status, such as container states and readiness, pushing this information back to the API server as part of its ongoing responsibilities.

Heartbeats as a Liveness Signal

Beyond detailed status, the kubelet architecture includes periodic heartbeat updates, allowing the control plane to detect when a node has stopped communicating, distinct from the more detailed status payloads which may be sent less frequently.

Probe Execution Architecture

Locally Executed Health Checks

Liveness, readiness, and startup probes are architected to be executed locally by the kubelet against the containers on its own node, rather than being evaluated centrally by the control plane, minimizing latency and avoiding dependence on control plane availability for basic health monitoring.

Node Agent Architecture Diagram