Module 3

Worker nodes

Every node runs three things: a kubelet that makes assigned Pods real, kube-proxy that implements Services, and a container runtime that starts the containers.

Why it matters. Node-level failures (NotReady nodes, evictions, pressure, probe flapping) are the most common production incidents. They all come from the behaviour of these three components.

After this module you can answer

What does the kubelet do all day?
How does the control plane know a node is unhealthy?
What does kube-proxy actually configure?
Why can Kubernetes run any OCI image on any runtime?
What is the full story from kubectl apply to a running container?

What is inside

1kubelet

2Heartbeats and conditions

3kube-proxy and the runtime

4The full journey

5Module infographic

Worker nodes: where containers actually run

Module 3 moves from the brain to the muscle. The control plane records that a Pod should run on node X; the kubelet on node X is the only component that makes that true. It watches the API server for Pods assigned to its node and instructs the container runtime to start them.

We also cover how a node reports its own health, why a missed heartbeat does not instantly evict everything, and how kube-proxy translates Service virtual IPs into real routes. The module ends with the full journey of a request, the single best interview narrative in Kubernetes.

On managed services (GKE, EKS, AKS) the node components come pre-installed on provider images; on bare metal you install containerd and kubelet yourself or let Rancher, kubeadm or Cluster API do it.