What is the Kubelet and What Does It Do?
Learn what the kubelet does — running containers per node, CRI, health probes, and heartbeats — with a clear DevOps interview answer.
Expected Interview Answer
The kubelet is the node-level agent that runs on every worker node, watches the API server for Pods assigned to its node, and ensures the containers described in those Pod specs are actually running and healthy via the container runtime.
The kubelet does not talk to other nodes; it only watches the API server for Pod specs scheduled to itself, then calls the container runtime (via the Container Runtime Interface, CRI) to pull images and start containers matching that spec. It continuously runs liveness, readiness, and startup probes against those containers, restarting a container that fails its liveness probe and reporting readiness status back to the API server so Services know whether to route traffic to it. The kubelet also reports node-level status — CPU, memory, disk pressure — back to the API server as periodic heartbeats, which is how the control plane detects a node has gone unresponsive. It mounts the volumes a Pod spec requests using the Container Storage Interface and manages Pod lifecycle events like termination grace periods when a Pod is deleted.
- Keeps each node self-sufficient — no direct node-to-node coordination needed
- Continuously enforces that running containers match the desired Pod spec
- Surfaces node and Pod health back to the control plane
- Abstracts the underlying container runtime via CRI
AI Mentor Explanation
The kubelet is like a ground curator stationed at one specific stadium who only checks the fixture list for matches assigned to their venue, never other stadiums. When a match is listed, the curator arranges the pitch and personnel to match exactly what was scheduled, using the local groundstaff (the container runtime) to prepare it. The curator continuously checks that the match is actually being played as planned and reports the ground’s condition back to the league office every few minutes. If the ground becomes unplayable, that heartbeat stops and the league knows to reroute future fixtures elsewhere.
Step-by-Step Explanation
Step 1
Watch the API server
The kubelet subscribes to Pod specs assigned to its own node, ignoring Pods scheduled elsewhere.
Step 2
Start containers via CRI
It calls the container runtime through the Container Runtime Interface to pull images and start containers.
Step 3
Run probes and mount volumes
It continuously runs liveness/readiness probes and mounts requested volumes via CSI.
Step 4
Report status
It sends periodic heartbeats with node and Pod health back to the API server.
What Interviewer Expects
- Understanding the kubelet runs per-node and only manages its own node
- Knowledge of CRI as the interface to the container runtime
- Awareness of liveness/readiness probes being enforced by the kubelet
- Understanding node heartbeats and how node NotReady is detected
Common Mistakes
- Confusing the kubelet with the scheduler (kubelet does not decide placement)
- Thinking the kubelet talks directly to other nodes
- Forgetting the kubelet is what actually restarts a failed container
- Not knowing CRI decouples the kubelet from a specific runtime like containerd
Best Answer (HR Friendly)
“The kubelet is the agent running on every worker machine in a Kubernetes cluster. Its job is simple: watch for any workload assigned to that specific machine, make sure the containers for it are actually running and healthy, and keep reporting status back so the rest of the cluster knows that machine is doing its job.”
Code Example
# Check kubelet service status on a node
systemctl status kubelet
# View kubelet logs for probe failures
journalctl -u kubelet -f | grep -i probe
# See node conditions reported via kubelet heartbeats
kubectl describe node worker-node-1 | grep -A5 Conditions
# Check which container runtime the kubelet is using
kubectl get node worker-node-1 -o jsonpath="{.status.nodeInfo.containerRuntimeVersion}"Follow-up Questions
- What happens when a liveness probe fails repeatedly?
- How does the kubelet decide a node should be marked NotReady?
- What is the Container Runtime Interface and why does it exist?
- How does the kubelet interact with kube-proxy on the same node?
MCQ Practice
1. What does the kubelet primarily do?
The kubelet runs on each node and makes sure the containers described in its assigned Pod specs are actually running and healthy.
2. How does the kubelet start containers?
The kubelet uses CRI to communicate with a pluggable container runtime such as containerd, decoupling it from a specific runtime implementation.
3. What triggers a node being marked NotReady?
The control plane marks a node NotReady when its kubelet stops sending the expected periodic status heartbeat.
Flash Cards
What is the kubelet? — The per-node agent that ensures assigned Pods actually run and stay healthy.
How does the kubelet start containers? — Via the Container Runtime Interface (CRI) to a pluggable container runtime.
What does the kubelet run continuously? — Liveness, readiness, and startup probes on its containers.
How does the control plane know a node is healthy? — Periodic heartbeats the kubelet reports to the API server.