The kubelet is the Kubernetes node agent. It runs on every node as a Linux service, not as a Pod managed by a DaemonSet. On worker nodes, it receives instructions through the control plane API, helps keep containers running in Pods, and reports their status. If a Pod container fails, the kubelet can restart it according to the Pod’s YAML configuration. It does not manage containers outside the scheduler-managed Pods described here. section 1.4.1 section 1.6 section 1.8 section 9.3.1
When a node or workload misbehaves, check the kubelet at the right layer:
- On the node, run `systemctl status kubelet`. Use `systemctl start kubelet` if it is stopped; use `systemctl enable kubelet` if it fails to start after reboot. `kubectl` does not display the kubelet as a Pod. section 1.8 section 9.3.1
- For a failing Pod, run `kubectl get po` and `kubectl describe po nginx`. Inspect container state, restart count, and events; if the kubelet cannot get the container running, it reports status to the API server. section 1.6
- If the API server is unavailable, check `systemctl status kubelet` on the control-plane node, then inspect `/etc/kubernetes/manifests/`. The kubelet starts static Pods from that directory without scheduler involvement; `crictl ps -a` and `crictl logs <containerid>` can expose failed component containers. section 6.8 section 8.2.5
A stopped kubelet in a kind worker
Enter the worker with `docker exec -it kind-worker bash` and check `systemctl status kubelet`. After `systemctl stop kubelet`, `kubectl get no` shows that worker as `NotReady` while other nodes remain `Ready`. Start it again with `systemctl start kubelet`, then recheck node status. In kind, the node is a container, but the kubelet is still inspected as a systemd service inside it. section 2.1.4
root@kind-worker:~# systemctl stop kubelet root@kind-worker:~# exit $ kubectl get no NAME STATUS ROLES AGE VERSION kind-control-plane Ready control-plane 5h27m v1.31.0 kind-worker NotReady <none> 5h27m v1.31.0 kind-worker2 Ready <none> 5h27m v1.31.0
The command output connects stopping the worker’s kubelet to that node becoming `NotReady`, making the node-level consequence visible. section 2.1.4
The kubelet also affects Pod configuration. Its node-local file, `/var/lib/kubelet/config.yaml`, includes cluster DNS settings; the kubelet populates Pods with the CoreDNS Service IP used for name resolution. In a DNS-change exercise, edit the `kubelet-config` ConfigMap, run `kubeadm upgrade node phase kubelet-config`, and create a new Pod. Verify the result in that Pod’s `/etc/resolv.conf` and with `nslookup`. For runtime inspection, `crictl` works with containers through the Container Runtime Interface (CRI), which gives the kubelet a consistent runtime interface. section 6.1 section 6.2.2 section 2.1.4
