haopengzhan
8c0b04db0e
- Editorial web platform built with Node.js, Express, EJS, and Vanilla CSS - Markdown content engine with YAML frontmatter, bilingual variants, and hot-reload watcher - Unified SQLite with FTS5 search indexing, query logging, and schema filters - Centered editorial post layout with margin-docked left TOC and mobile bottom sheet - WordPress-grade comment system with moderation dashboard and bulk operations under /guanli - Complete SEO suite (JSON-LD structured data, RSS/Atom feeds, XML sitemap, robots.txt) - CI/CD workflows for linting, security audits (Gitleaks), automated tests, and Docker releases
2.1 KiB
title, date, author, category, tags, excerpt, cover, lang
| title | date | author | category | tags | excerpt | cover | lang | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Kubelet Source Code Deep Dive: SyncLoop and PLEG | 2025-07-15 | haopengzhan | Tech |
|
An in-depth exploration into the Kubernetes Kubelet runtime architecture, focusing on syncLoop mechanics and Pod Lifecycle Event Generator (PLEG). | images/cover.svg | en |
Kubelet is the primary "node agent" that runs on each Kubernetes worker node. It registers the node with the apiserver, watches for PodSpec changes, and ensures containers described in those PodSpecs are running and healthy1 .
Architectural Overview
At the heart of the Kubelet daemon is the syncLoop. The syncLoop monitors multiple channels for pod changes:
- Config channel: Pods from API server, file manifests, or HTTP endpoints.
- PLEG channel: Pod Lifecycle Event Generator events.
- Probe channel: Liveness and readiness probe results.
- Housekeeping channel: Periodic cleanup tasks.
The SyncLoop Implementation
Here is a simplified view of how Kubelet receives events in Go:
func (kl *Kubelet) syncLoop(updates <-chan kubetypes.PodUpdate, handler SyncHandler) {
klog.InfoS("Starting kubelet main sync loop")
for {
select {
case u, ok := <-updates:
if !ok {
klog.ErrorS(nil, "Updates channel closed")
return
}
handler.HandlePodAdditions(u.Pods)
case e := <-kl.pleg.Watch():
handler.HandlePLEGEvent(e)
}
}
}
Pod Lifecycle Event Generator (PLEG)
PLEG periodically relists containers from the container runtime via CRI:
# Inspecting runtime events with crictl
crictl ps --state Running
If PLEG does not complete within the expected relist period (default 3 minutes), the node becomes NotReady with the condition PLEG is not healthy.
Conclusion
Understanding the syncLoop provides clear insights into why nodes report PLEG issues during disk I/O bottlenecks or heavy container churn.
-
Kubernetes documentation: https://kubernetes.io/docs/concepts/architecture/ ↩︎