Kubernetes 深度解析：Kubelet

I’m ready to translate the article for you, but I don’t have the body of the text—only the source line you provided. Could you please paste the content you’d like translated (excluding any code blocks or URLs you want to keep unchanged)? Once I have the text, I’ll translate it into Simplified Chinese while preserving the original formatting and markdown.

Introduction

在 Kubernetes 集群中，Kubelet 负责启动和停止容器以及管理节点的状态。它是一个独立的二进制文件，直接运行在节点的操作系统上，通常以 systemd 服务的形式启动。在 kind 等开发环境中，节点本身运行在 Docker 容器内部，kubelet 作为容器 init 系统的子进程被启动。

当 kubelet 停止时，控制平面会将该节点标记为 NotReady，从而阻止新的工作负载调度到该节点上。

Kubelet 责任

Kubelet 持续将节点上实际的容器与从 API 服务器获取的 PodSpec 中定义的期望状态进行调和。它通过几个自主运行的专门管理器来实现：

• Pod 生命周期管理 – 通过 SyncPod 逻辑处理 pod 的创建、更新和删除。
• 存储桥接 – VolumeManager 在主机上挂载外部存储，并使其对容器可用。
• 密钥分发 – TokenManager 和 SecretManager 获取 ServiceAccount 令牌和 secret，注入到相应位置。
• 状态报告 – 定期将节点资源使用情况和 pod 健康状态推送到 API 服务器。
• 健康检查 – 执行存活性和就绪性探针，在必要时重启容器。
• 节点自我防御 – 当资源限制接近时执行 pod 驱逐，保护节点免于整体崩溃。

所有这些组件围绕一个称为 SyncLoop 的中心事件循环协同工作。

Runtime Stack: CRI → containerd → runc

当 kubelet 发出 “create container”（创建容器）命令时，请求会通过以下分层堆栈流转：

1. CRI（Container Runtime Interface） – kubelet 用来与容器运行时通信的协议。
2. containerd（CRI Runtime） – 接收 CRI 命令，处理镜像拉取，并管理更高级别的容器生命周期操作。
3. runc（OCI Runtime） – 直接与内核交互，创建并运行容器进程。

kubelet 指示 containerd，随后 containerd 调用 runc 执行底层操作。

驱逐 vs. OOM Killer

Pod 可能因内存不足而被终止，原因有：

• 违反自身限制 – Pod 超出其请求的资源。
• 节点整体危机 – 整个节点承受压力。

Kubelet 旨在在内核的 OOM Killer 干预之前执行 有序驱逐。

SyncPod 流程（Pod 启动）

1. 上下文准备 – 从 API 服务器检索最新的 pod 定义。
2. 卷挂载 – 指示 VolumeManager 在主机上挂载所需的存储。
3. Secret/ConfigMap 准备 – TokenManager 获取服务账户令牌并将其作为文件放置在主机上。
4. 沙箱创建 – 创建提供 pod 网络和命名空间框架的 “pause” 容器（RunPodSandbox）。
5. 容器启动 –
   • 将准备好的令牌或卷绑定挂载到容器的文件系统中（例如 /var/run/secrets/...）。
   • 启动应用容器。

摘要

Kubelet 不仅是一个简单的代理；它是一个自主的控制系统，具备以下功能：

• 作为进程运行在主机上（或在 kind 节点容器内部）。
• 使用 CRI → containerd → runc 堆栈，将高级 pod 规范转换为具体的容器。
• 通过在内核 OOM Killer 触发前驱逐 pod，维护节点健康。

了解节点的“大脑”对于排查 pod 死亡（OOMKilled 与 Evicted）或卷挂载问题至关重要。