The kubelet turns "this Pod is assigned to me" into running, healthy containers.

It is the only node component that talks to the API server. It watches, starts, probes and reports back, continuously.

Always reconciling

The kubelet compares "Pods that should run here" with "containers running here" and fixes the difference, exactly like any controller.

Static Pods

It can also run Pods from files in /etc/kubernetes/manifests. That is how kubeadm starts the API server and etcd themselves.

Security-critical port 10250

Its API powers exec and logs. Require authentication and webhook authorization; never allow anonymous access.

The kubelet is the node's local agent

The kubelet runs on every node and is its local agent. It watches the API server for Pods whose spec.nodeName is its own node, asks the container runtime to pull images and start the containers, mounts volumes, runs liveness, readiness and startup probes, and reports Pod and node status back. Everything it does is a reconciliation between the Pods that should run here and the containers that actually do.

Reveal the five stages with the right arrow: the assignment arrives from the API server, the kubelet decides, the runtime starts containers through the standard CRI interface, the kubelet probes them, and it reports status and node health back. Because it works from the API server's record, a kubelet that restarts simply resumes reconciling.

Two details are worth knowing. Static Pods are defined by files on the node rather than the API; kubeadm uses this to run the control plane components themselves. And the kubelet's HTTPS port (10250) is powerful: exec, logs and port-forward all go through it, so it must require authentication and authorization.

Resource enforcement also lives here. The kubelet configures cgroups so that CPU limits throttle and memory limits trigger the kernel OOM killer, and it evicts Pods when the node comes under memory, disk or PID pressure.