The kubelet is the agent on a Kubernetes node that manages applications assigned to that node. It talks to the API server, reports the status of the node and its applications, and instructs the container runtime to run containers. The kubelet does not choose which node receives a pod; the scheduler makes that assignment. section 1.2.3 section 1.2.4
When you deploy an application, the kubelet acts after the control plane has prepared its pod:
- You submit a manifest through the Kubernetes API. A controller creates an object for the application instance, and the scheduler assigns it to a node. section 1.2.4
- The kubelet on that node notices the assignment and uses the container runtime to start the instance. In the Docker example, it tells Docker to pull the image, create a container, and execute it. section 1.2.4 section 3.3.1
- The kubelet and controllers continue monitoring the system to keep the application running. section 1.2.4
Check what happened to a pod
Run `kubectl describe pod` and read the events at the bottom. After a pod is scheduled, events can show the kubelet pulling its image, creating its container, and starting it. This is a useful first check when a pod has not started as expected. section 3.3.1
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 25s default-scheduler Successfully assigned
default/kiada-9d785b578-p449x
to kind-worker2
Normal Pulling 23s kubelet, kind-worker2 Pulling image "luksa/kiada:0.1"
Normal Pulled 21s kubelet, kind-worker2 Successfully pulled image
Normal Created 21s kubelet, kind-worker2 Created container kiada
Normal Started 21s kubelet, kind-worker2 Started container kiada
The event listing separates the scheduler’s assignment from the kubelet’s image-pull, container-creation, and start actions. section 3.3.1
A kubelet also normally registers its host by creating a Node object in the API. When a pod is deleted, the kubelet shuts down its containers, removes associated resources such as log files, and notifies the API server; the Pod object is then removed. The detailed container shutdown sequence is a separate lifecycle topic. section 4.2 section 5.6.1
Loss of contact with the API server matters. A node can become `NotReady` while its pods still appear `Running`. If Kubernetes later marks those pods for deletion, a ReplicaSet can create replacements elsewhere, but the disconnected kubelet cannot learn that it should terminate the original containers. It does so when contact is restored. section 14.3.2
