Kubelet & kube-proxy
The two agents that make a worker node useful.
In plain terms
On each worker, the kubelet is the shift worker who actually runs the machines, and kube-proxy is the receptionist who forwards each incoming call to whichever worker is free.
Two agents run on every worker. The kubelet is the node’s hands: it takes pod specs from the API server, tells the container runtime to run them, and reports status back. kube-proxy is the node’s traffic cop: it programs the rules that turn a Service IP into a real pod.
Worker node
kubelet
pods ↔ runtime, reports status
container runtime
containerd via CRI
kube-proxy
Service → endpoint rules
pods
the workloads
The kubelet is the one component the API server does NOT run — it is a systemd service on the node. That is why a NotReady node is nearly always a kubelet problem.
The kubelet also runs static pods and reports node conditions — MemoryPressure, DiskPressure — that the scheduler and the eviction logic depend on. kube-proxy watches Services and Endpoints and rewrites iptables or IPVS rules to match.
NotReady? Check the kubelet first
systemctl status kubelet and journalctl -u kubelet on the node answer most NotReady cases in seconds — a down, misconfigured, or cert-expired kubelet.