Kubelet Source Code Deep Dive: Understanding Its Core Workflows

Kubelet Work Principle

The core of Kubelet is a control loop called syncLoop , which drives events such as Pod update events, Pod lifecycle changes, and Kubelet‑configured periodic tasks like garbage collection (GC).

Beyond this main loop, Kubelet maintains many auxiliary control loops (shown as small circles in the diagram), each responsible for a specific aspect of node and pod management:

podManager : stores and manages the desired set of Pods, including regular Pods and mirror Pods.

podWorkers : handles the state machine of Pod lifecycles, processing states such as syncing (calling syncPod), terminating (calling syncTerminatingPod), and terminated (calling syncTerminatedPod).

evictionManager : monitors node health, identifies conditions that could affect stability, and evicts Pods by setting their status to Failed with reason Evicted, relying on podWorkers for authoritative eviction actions.

probeManager : periodically checks container health inside Pods, supporting livenessProbe and readinessProbe.

secretManager : caches and manages Secrets used by Pods, coordinating with podWorkers to fetch and clean up Secrets during Pod start and termination, keeping them up‑to‑date.

configMapManager : similar to secretManager but for ConfigMaps, ensuring Pods receive the correct ConfigMap data throughout their lifecycle.

volumeManager : manages volumes attached to Pods, observing Pod lifecycles to perform necessary volume operations and periodically synchronizing volume status. It handles:

Attaching – connecting a volume to the node.

Mounting – mounting the volume into the Pod’s filesystem.

Unmounting – detaching the volume from the filesystem.

Detaching – disconnecting the volume from the node.

statusManager : updates and manages Pod status, receiving updates from podWorkers and syncing them to the API server. It is the authoritative source for synthesized Pod status; other components should query podWorkers for the latest state to ensure consistency.

imageManager : performs image garbage collection, periodically cleaning unused images to free node disk space.

containerLogManager : collects, stores, rotates, and cleans container logs, preventing log data from exhausting node disk space.

serverCertificateManager : monitors certificate expiration, automatically rotates certificates, and ensures secure cluster communication.

cloudResourceSyncManager : handles requests to cloud service providers, setting request timeouts and processing potential errors.

Runtime fields : containerRuntime – manages container lifecycle and communicates with underlying runtimes such as Docker, containerd, or CRI‑O. streamingRuntime – handles streaming operations like log streaming, exec commands, and port forwarding. runtimeService – internal API that interfaces with the container runtime, typically part of the Container Runtime Interface (CRI), delegating calls to containerRuntime.

PLEG (Pod Lifecycle Event Generator) and eventedPleg :

PLEG uses a periodic polling mechanism to check all Pods and containers, generating events for state changes; this can introduce latency because it waits for the next poll.

eventedPleg is event‑driven, listening to runtime events to report changes immediately, offering lower latency and edge‑driven responses.

containerRefManager : tracks container creation and failure events for reporting.

When Kubelet starts, it creates a syncLoopIteration loop that receives podUpdate objects via a channel sourced from static files, HTTP URLs, or List‑Watch (API). Upon receiving a podUpdate, the flow proceeds as follows:

The update is processed by podWorkers.UpdatePod, then placed onto the podWork channel. podWorkLoop spawns a goroutine for each Pod, invoking syncPod, which handles status updates, container creation via the CRI (pulling images, invoking device‑plugin for device allocation, and creating containers through the CRI container service).

Within syncLoopIteration, additional channels coordinate periodic and event‑driven actions: syncCh and cleanupCh are driven by a time.Ticker to regularly process Pods and perform cleanup. containerCh receives device health information reported by device‑plugins. probeCh aggregates results from liveness, readiness, and startup probes, influencing Pod status updates. plegCh receives Pod lifecycle events from PLEG and decides whether to trigger a sync based on those events.

The article notes that the fields described above represent the core components of the Kubelet struct; many additional fields exist but are omitted for brevity.