Worker node components

Role of Worker Nodes in Kubernetes

Worker nodes are the machines (virtual or physical) that actually run your application containers. While control plane components decide what should happen in the cluster, worker node components are responsible for doing the work: running Pods, pulling images, attaching storage, and handling network traffic.

This chapter focuses on the key software components that must be present on every Kubernetes worker node and how they interact.

Core Components on a Worker Node

A typical worker node runs at least these core components:

• Kubelet
• Container runtime
• Kube-proxy
• Node-level OS and networking configuration (kernel, CNI plugins, etc.)

Control plane components never run on worker nodes by default in a standard production cluster; instead, they communicate with these worker components through the Kubernetes API.

Kubelet

kubelet is the primary Kubernetes agent running on each node. It acts as a bridge between:

• The control plane (via the API server)
• The node’s container runtime
• The node’s local environment (filesystem, network, cgroups, etc.)

Responsibilities of kubelet

At a high level, kubelet:

• Watches for Pods scheduled to this node
• Ensures containers for those Pods are running and healthy
• Reports status back to the control plane

Concretely, kubelet:

• Registers the node with the API server:
• Sends node capacity info (CPU, memory, GPU, etc.)
• Sends node labels and taints (used by the scheduler)
• Manages Pod lifecycle:
• Pulls Pod specifications from the API server
• Asks the container runtime to create, start, stop containers
• Mounts volumes into Pods
• Handles Pod termination and deletion
• Performs health checks:
• Executes livenessProbe, readinessProbe, and startupProbe defined in Pod specs
• Restarts containers if probes fail (according to Pod policy)
• Collects and reports status:
• Pod status (running, pending, failed)
• Container exit codes and restart counts
• Node conditions (e.g. Ready, DiskPressure, MemoryPressure)
• Executes node-level tasks:
• Handles kubectl exec and kubectl cp operations
• Manages local Pod logs (by default, writing to files on the node)

Kubelet does not make scheduling decisions; it simply enforces the desired state expressed by the control plane for the Pods assigned to its node.

Container Runtime

The container runtime is the software responsible for actually running containers on the node. Kubernetes interacts with it via the Container Runtime Interface (CRI).

Common runtimes:

• containerd
• CRI-O
• (Historically) Docker Engine via a shim – now deprecated in modern Kubernetes

Responsibilities of the container runtime

The runtime handles all low-level container operations, such as:

• Pulling container images from registries
• Creating and starting containers and Pods (as “podsandbox” in CRI terms)
• Managing container namespaces and cgroups
• Providing container logs and basic metrics to kubelet
• Stopping and deleting containers and pod sandboxes

Kubelet communicates with the runtime over a local gRPC API defined by CRI:

• Kubelet tells the runtime: “Create a Pod sandbox with these settings; start containers with these images and commands.”
• The runtime does the work and reports status back to kubelet.

Pods and runtime sandboxes

From the runtime’s perspective, a Pod is often represented as:

• A pod sandbox: shared network namespace, IP address, and basic configuration
• One or more containers: each with its own filesystem, process, and environment, but sharing the Pod sandbox’s network and some volumes

Kubelet orchestrates both sandbox and container lifecycle via CRI.

Kube-proxy

kube-proxy is the network proxy that runs on each worker node. It implements Kubernetes Service networking on the node, making cluster-internal service discovery and basic load balancing work.

Responsibilities of kube-proxy

• Watches Service and Endpoints (or EndpointSlice) objects from the API server
• Programs the node’s networking to send traffic for a Service to the right backend Pods
• Implements simple load balancing across Pod IPs for a Service

Depending on the mode, kube-proxy may:

• Use iptables rules
• Use IPVS (IP Virtual Server) for more scalable load balancing

How kube-proxy handles Service traffic

For a ClusterIP Service:

• The Service has a virtual IP (ClusterIP) and port.
• Kube-proxy adds rules on the node so that:
• Traffic to the Service IP/port is rewritten (DNAT) to one of the backing Pod IPs/ports.
• It chooses a Pod according to the load-balancing method (e.g. round-robin).

For a NodePort Service:

• The Service is exposed on a port of every node.
• Kube-proxy configures node-level rules to forward traffic from the NodePort to the appropriate Pod(s).

Kube-proxy operates at the node level; it does not inspect application protocols. It simply forwards packets based on IP and port, using the Service and Endpoint data from the API server.

CNI Plugins and Node Networking

While kube-proxy implements Service-level load balancing, CNI (Container Network Interface) plugins implement Pod networking on the node.

CNI details are typically configured by the cluster distribution and belong to the networking model chapter, so here we only highlight the worker-node aspect:

• The node has one or more CNI plugins installed (e.g. Flannel, Calico, OVN-Kubernetes).
• When kubelet creates a Pod, it calls the CNI plugin:
• Assign a Pod IP
• Set up network interfaces and routes
• The plugin ensures that:
• Pods can communicate with each other (according to cluster network policies)
• Pods can reach external networks (if configured)
• Node-level firewall and routing rules are consistent

From the worker node’s perspective, CNI plugins are local binaries and configuration that kubelet calls to wire up Pod networking.

Node as a Kubernetes Object vs. Machine

In Kubernetes, a “Node” is also an API object representing the machine. Worker nodes host:

• The physical or virtual machine resources:
• CPU, memory, storage devices, network interfaces
• Operating system and kernel
• The Kubernetes node object:
• Metadata (labels, annotations)
• Status (capacity, conditions)
• Allocatable resources for Pods

Kubelet bridges these two views:

• It inspects the underlying machine and reports capacity to the API server.
• It enforces that Pods scheduled to the node do not exceed allocatable resources (in cooperation with the container runtime and cgroups).

Labels on the node (e.g. node-role.kubernetes.io/worker, topology.kubernetes.io/zone) are critical for scheduling and higher-level features, but they’re stored in the Kubernetes node object, not in kubelet itself.

Resource Enforcement and Isolation

Worker nodes enforce container and Pod resource limits through:

• cgroups (control groups) for CPU, memory, and other resources
• namespaces for process, network, PID, and filesystem isolation

Kubelet configures these via the container runtime based on Pod specs:

• Requests and limits for CPU/memory define the cgroup configuration.
• Security context and Pod-level settings determine which Linux namespaces and capabilities are used.

While the control plane decides “this Pod should get 500m CPU and 512Mi memory,” it is the worker node (via kubelet + runtime + kernel) that enforces these limits.

Node-Level Health and Reporting

Worker nodes continuously report their health to the cluster:

• Node conditions:
• Ready / NotReady
• OutOfDisk, DiskPressure
• MemoryPressure, PIDPressure
• Allocatable resource changes:
• When system daemons or reserved resources change
• When hardware capacity is updated or degraded

Kubelet sends these updates to the API server. Higher-level components (like the scheduler or cluster autoscaler) rely on this information, but the collection and reporting are done on the worker node.

Additionally, worker nodes:

• May run a node problem detector or similar agents to surface hardware or OS issues.
• Are often integrated with node-level logging and monitoring agents that forward metrics and logs. These agents are typically deployed as DaemonSets (Pods running on every node), but from the node’s perspective they’re just regular Pods scheduled by the control plane.

Interaction Summary

Putting it all together on a worker node:

1. Scheduler (control plane) decides a Pod should run on Node A.
2. API server records the Pod’s assignment to Node A.
3. Kubelet on Node A:
• Sees the new Pod assigned to its node.
• Requests the container runtime to create a Pod sandbox and containers.
• Invokes CNI plugins to configure the Pod’s network.
4. Kube-proxy on Node A:
• Updates its rules if the new Pod is an endpoint for a Service.
5. Kubelet:
• Monitors the Pod and containers, runs health probes, enforces limits.
• Reports status back to the API server.
6. If something fails (container crash, health probe failure), kubelet:
• Restarts containers as needed based on the Pod’s restart policy.
• Updates Pod status so higher-level controllers can react.

All of this happens on every worker node, making them the execution backbone of the Kubernetes cluster.