Node Components: Roles and Responsibilities

The Anatomy of a Worker Node

While the control plane orchestrates, the worker nodes execute. For a machine to join a Kubernetes cluster as a worker node, it must run specific software that allows it to be managed by the control plane and to run containerized workloads. These are known as the node components.

Let's begin with a video that provides a quick overview of these three components before we dive into each one individually.

Now that you have a high-level picture, let's examine each component's responsibilities in detail. For a definitive, high-level summary, you can also refer to the official Kubernetes documentation.

1. The kubelet: The Node's Agent

The kubelet is the primary "node agent." It's the bridge between the control plane and the worker node. After the kube-scheduler assigns a Pod to a node, it's the kubelet on that node that takes over to bring the Pod to life.

Key Responsibilities:

• Registers the Node: When a node starts, the kubelet registers it with the control plane's API server, making it available for scheduling workloads.
• Watches for Pods: It constantly watches the API server for Pods that have been scheduled to its node.
• Manages Container Lifecycles: For each Pod, the kubelet reads the container specifications (the PodSpec) and instructs the container runtime to pull the required images and run the containers.
• Health Monitoring: It continuously monitors the health of the containers and the Pod, running any configured liveness and readiness probes. If a container fails, the kubelet can restart it based on the Pod's restart policy.
• Status Reporting: It reports the status of the node and its running Pods back to the API server, updating the cluster's "actual state."

Think of the kubelet as the on-site foreman for each worker node, carrying out the architectural plans sent down from the central office (the control plane).

For a deeper look into the many hats the kubelet wears, the following video provides an excellent breakdown.

2. The Container Runtime: The Engine

Kubernetes itself does not run containers. Instead, it relies on a separate piece of software called a container runtime. Your extensive experience with Docker means you're already very familiar with the most famous container runtime.

Key Responsibilities:

• Image Management: Pulling container images from registries (like Docker Hub, ACR, or ECR).
• Container Execution: Running and managing the lifecycle of containers (start, stop, pause) based on instructions from the kubelet.
• Resource Isolation: Utilizing low-level Linux kernel features like namespaces and cgroups to isolate container processes, filesystems, and networking.

A crucial concept here is the Container Runtime Interface (CRI). In the past, Kubernetes was tightly coupled with Docker. To support a wider ecosystem, Kubernetes introduced the CRI, a standardized API that allows any compatible container runtime to plug into the kubelet.

This is why modern Kubernetes clusters often use runtimes like containerd or CRI-O directly. They are lightweight runtimes designed to implement the CRI standard efficiently. Your Docker installation actually uses containerd under the hood.

3. kube-proxy: The Network Plumber

The kube-proxy is a network proxy that runs on each node and is a key component in enabling Kubernetes networking. Its primary job is to make sure network traffic gets to the right Pods.

Key Responsibilities:

• Service Discovery: It watches the API server for the creation and removal of Service and Endpoint objects. (Endpoints are the lists of Pod IPs that back a Service).
• Network Rule Management: When a Service changes, kube-proxy updates network rules on the node itself. These rules capture traffic destined for a Service's virtual IP (ClusterIP) and redirect it to one of the backing Pods.
• Load Balancing: By distributing traffic across all the Pods that are part of a Service, kube-proxy provides basic load balancing.

It typically does this using one of three modes: iptables, IPVS, or userspace. iptables and IPVS are both built-in Linux kernel features, making them highly efficient. IPVS is generally preferred for very large clusters with thousands of services.

Your experience with Envoy proxy is relevant here. While kube-proxy is simpler, they share the fundamental goal of intelligently routing traffic based on a dynamic configuration. kube-proxy handles the basic L4 (TCP/UDP) routing for Services, while tools like Envoy are often used for more advanced L7 (HTTP) routing, which we'll touch on when we discuss Ingress.

The following reading provides excellent scenarios that illustrate how kube-proxy enables service communication and handles failures.

Conclusion

In this lesson, we've detailed the components that make a worker node functional within a Kubernetes cluster. You now understand how the control plane's decisions are translated into running applications.

Key Takeaways:

• kubelet: The essential node agent that acts as the control plane's representative, managing the Pod lifecycle on the node.
• container runtime: The underlying engine responsible for pulling images and running the containers themselves, abstracted via the Container Runtime Interface (CRI).
• kube-proxy: The network utility that manages network rules on each node, enabling reliable service discovery and load balancing by routing traffic to the correct Pods.

Together, these three components provide the robust, manageable runtime environment that is the foundation of Kubernetes' power at the node level.

In our next lesson, we will take a deeper look at the heart of the control plane: the API server and etcd. We'll explore the mechanics of how API requests are handled and how etcd ensures the cluster state is stored consistently and reliably.