2.3 Kubernetes Worker Node Architecture
Kubernetes Worker Node Architecture explains the structure and components of nodes that run containerized applications in a Kubernetes cluster.
Kubernetes Worker Node Architecture is the specific internal arrangement of the components running on a worker node, describing how the kubelet, container runtime, and kube-proxy are layered relative to one another and to the operating system, forming the machinery through which control plane decisions are turned into actually running containers.
Layered Component Structure
kubelet as the Node-Level Coordinator
Architecturally, the kubelet occupies the top layer on a worker node, acting as the single point of contact with the control plane; it receives Pod specifications assigned to its node and is responsible for translating them into concrete actions taken by the layers beneath it.
Container Runtime Beneath the kubelet
Below the kubelet sits the container runtime, which the kubelet communicates with through the Container Runtime Interface (CRI); the runtime is architected as a separate, swappable component, meaning the kubelet does not embed container execution logic directly but instead delegates it through this standardized interface.
Networking Layer on the Node
kube-proxy as an Independent Sibling Component
kube-proxy runs alongside the kubelet as an architecturally independent component, maintaining the networking rules needed to implement Service routing; it does not depend on the kubelet directly but instead watches the API server on its own to keep its rules current.
CNI Plugin Integration
Beneath both the kubelet and kube-proxy, a Container Network Interface (CNI) plugin is architected as the layer responsible for wiring each Pod's network namespace into the broader cluster network, invoked by the container runtime at the point a Pod's sandbox is created.
Operating System Layer
Kernel Primitives as the Foundation
At the base of the node architecture sits the host operating system kernel, providing the namespace and cgroup primitives that the container runtime relies on to create isolated, resource-constrained execution environments for each container.
Communication Path Back to the Control Plane
A Single Outbound Channel
Architecturally, the kubelet is the only node component with an established communication channel back to the control plane's API server; other node components, such as kube-proxy, establish their own independent connections to the API server rather than routing through the kubelet.