Kubelet: The Node Agent of Kubernetes
The kubelet is the primary agent on each Kubernetes node, ensuring containers described in PodSpecs are running and healthy. It watches the API server for work and reports status back. The footgun is trying to manage it directly; always use the API server.
WHY IT EXISTS: A distributed system like Kubernetes needs a way to command and control individual machines from a central point. The kubelet is the agent that runs on every machine, making it a manageable 'node' and allowing the control plane to delegate work.
THE MENTAL MODEL: Think of the kubelet as a foreman on a construction site (a node). The central architect (the API server) sends blueprints (PodSpecs) for what needs to be built. The kubelet reads these blueprints and directs the local workers (the container runtime) to create and maintain the structures (containers). It's responsible for everything on its site, reporting progress and problems back to the architect.
HOW IT WORKS: The kubelet is a daemon that runs on every node. First, it registers its node with the control plane's API server. Then, it continuously watches the API server for Pods that have been scheduled to its node. When it sees a new Pod assignment, it reads the specification and uses the Container Runtime Interface (CRI) to command the container runtime (like containerd) to pull the required images and start the containers. It also executes liveness and readiness probes, mounts volumes, and reports the status of the node and its Pods back to the API server.
WHEN TO USE IT: The kubelet is a mandatory component of every Kubernetes node. You don't choose to use it; a machine cannot function as a node within a Kubernetes cluster without a running and correctly configured kubelet. Its configuration is a key step in bootstrapping a new node.
WHEN NOT TO USE IT: A kubelet is not a general-purpose process manager like systemd. You would not run a kubelet on a machine that is not intended to be part of a Kubernetes cluster. Its sole purpose is to integrate a host into the Kubernetes ecosystem.
ONE CANONICAL EXAMPLE: A developer runs kubectl apply -f my-app.yaml. The Kubernetes scheduler assigns the resulting Pod to node-01. The kubelet on node-01 sees this assignment via the API server. It reads the Pod's spec, instructs the container runtime to pull the my-app:v2 image, and starts the container. If the Pod's container crashes, the kubelet will restart it according to the Pod's restart policy, attempting to enforce the desired state without any manual intervention.
Read the original → kubernetes.io
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.