上一篇【第64篇】Scheduler深度解析——Pod调度算法的“高考阅卷“预选打分一个不落下一篇【第66篇】CRI深度解析——容器运行时接口标准摘要前面Scheduler给Pod选好了Node写了nodeName。但这只是在档案上写了分配结果真正去机房搬机器、插电、起服务的是kubelet。kubelet是跑在每个Node上的全能管家。它干的事特别杂发现有Pod分配给我了→ 通过CRI叫容器运行时起容器 → 定时跑健康检查探针 → 把节点和Pod状态上报API Server → 资源不够时挑Pod驱逐。这篇文章讲清kubelet的核心职责、它的SyncLoop主循环怎么持续对账、CRI调用链kubelet→containerd→runc以及节点压力驱逐Node Pressure Eviction机制。一、kubelet的定位1.1 它是Node上的Agent【kubelet 在集群里的位置】 每个Node上都有且只有一个 kubelet │ ├── 向上: 连 API Server │ • Watch 分配给本Node的Pod │ • 上报 Node/Pod 状态 │ ├── 向下: 调容器运行时(通过CRI) │ • 创建/删除/启停容器 │ • 管理容器生命周期 │ └── 横向: 管本Node的一切 • 挂载卷(CSI) • 配置网络(CNI) • 跑健康检查 • 资源监控(cAdvisor)要点kubelet是控制平面和节点之间的桥梁。注意它不是控制平面组件control plane而是节点组件node component。但只有它真正和容器运行时打交道——Scheduler、Controller Manager都不直接碰容器。这也解释了为什么kubelet是Node上最关键的进程。二、SyncLoop永不停歇的对账循环2.1 主循环kubelet的核心是一个叫SyncLoop的无限循环和控制器模式同源【kubelet SyncLoop——持续对账】 loop forever: 从多个来源收需要处理的Pod变更: • PodUpdate (API Server分配来的) • PodAdd / PodUpdate / PodDelete • 健康检查失败事件 • 周期性的状态同步 → 调 reconcile - 让节点实际状态 靠拢 期望状态 • 该起的Pod起 • 该删的Pod删 • 该重启的重启 PLEG (Pod Lifecycle Event Generator): • 监控容器运行时里容器的真实状态 • 容器意外退出? → 触发SyncLoop重新对账2.2 PLEG的妙用【PLEG —— 盯着容器运行时的眼睛】 没有PLEG: kubelet靠API Server通知才知道Pod变了 但容器在运行时层面崩了API Server不一定立刻知道 有PLEG: kubelet定期(默认1s)问容器运行时 你那边这些容器还活着吗? → 发现某容器挂了 → 立刻触发重建 → 自愈更快、更准三、CRI调用链3.1 从kubelet到容器【kubelet 起一个容器的完整调用链】 kubelet (Go代码) │ 通过 CRI (gRPC) ▼ containerd (容器运行时中间层) │ 通过 OCI runtime 接口 (runc的命令行) ▼ runc (底层OCI运行时真正创建容器) │ ▼ Linux 容器 (namespace cgroup 文件系统) 另dockershim已移除(见第005篇) 现在 kubelet → containerd → runc 直达# 看节点上kubelet和containerd的状态systemctl status kubelet systemctl status containerd# 看kubelet的运行时配置(通过CRI连的哪个)kubectl get nodes-owide# NAME STATUS VERSION CONTAINER-RUNTIME# node1 Ready v1.29.0 containerd://1.7.0要点kubelet自己不会创建容器——它只发指令。指令通过CRIgRPC发给containerdcontainerd再通过OCI标准调用runc真正建容器。这种分层让K8s可以换运行时containerd/Crio-O见第005/066篇而不用改kubelet。cAdvisor集成在kubelet里负责采集容器资源指标这就是Metrics Server能拿到CPU/内存数据的来源。四、健康检查的执行者4.1 kubelet跑探针【kubelet 执行三种探针(第034篇讲过)】 Liveness Probe (存活): • 失败 → kubelet杀掉容器 → 按restartPolicy重启 Readiness Probe (就绪): • 失败 → kubelet把Pod从Service Endpoints摘掉 • 成功 → 加回Endpoints Startup Probe (启动): • 保护慢启动应用期间其他探针不生效 探针方式: exec / httpGet / tcpSocket / gRPC kubelet定期执行结果影响Pod状态和流量五、节点压力驱逐5.1 资源不够时kubelet动手【Node Pressure Eviction —— 保车弃卒】 当Node出现资源压力: • memory.available 阈值 → 内存压力 • nodefs.available 阈值 → 磁盘压力 • pid.available 阈值 → PID压力 • imagefs.available 阈值 → 镜像盘压力 kubelet的动作(按优先级驱逐): 1. 先驱逐 BestEffort Pod (最低QoS, 第030篇) 2. 再驱逐 Burstable (超配的) 3. Guaranteed 最后才动(通常不动) 还有个 Hard Eviction(硬阈值): • 触及立即驱逐不给宽限# kubelet驱逐相关参数--eviction-hardmemory.available100Mi,nodefs.available10% --eviction-softmemory.available200Mi --eviction-soft-grace-periodmemory.available1m30s --eviction-max-pod-grace-period30要点节点驱逐是kubelet的自我保护机制——当Node资源(内存/磁盘/PID)不够时它按QoS优先级挑Pod杀保住重要应用。这解释了为什么QoS分类第030篇在生产这么重要你给核心服务设Guaranteed资源紧张时kubelet最后才动它。注意驱逐和OOM Killer不同——驱逐是kubelet主动的、按优先级的OOM是内核在内存真耗尽时的最后一击。六、kubelet和API Server失联会怎样【脑洞问题kubelet连不上API Server】 情况API Server挂了 / 网络断了 kubelet行为 • 本地已运行的Pod 继续跑(不删除!) • 无法上报状态(状态变Unknown) • 无法接收新Pod调度 设计原则宁可让Pod继续跑也不盲目删 → 防止API Server抖动导致全集群Pod被误杀 → 等 reconnect 后重新对账本篇小结kubelet是Node上的全能管家Watch分配到本Node的Pod、通过CRI调containerd/runc起容器、跑三种健康检查探针、用cAdvisor采集指标、上报状态、资源紧张时按QoS驱逐Pod。它的SyncLoop主循环持续对账配合PLEG盯容器运行时保证节点实际状态靠拢期望。关键设计kubelet自己不建容器只发CRI指令连不上API Server时宁可让Pod继续跑也不误删防止抖动引发雪崩。节点驱逐按QoS优先级保车弃卒所以核心服务务必设Guaranteed。下篇深入CRI——容器运行时接口标准。上一篇【第64篇】Scheduler深度解析——Pod调度算法的“高考阅卷“预选打分一个不落下一篇【第66篇】CRI深度解析——容器运行时接口标准