在 Kubernetes 的日常使用中，我们经常会看到这样一条调用链：

kubectl → API Server → kubelet（对应节点）

但一个长期被忽略、却极其关键的问题是： kubelet 在这条链路中，到底起什么作用？

一开始，笔者只知道它“在节点上跑”，却说不清：

• kubelet 什么时候被调用
• 谁在调用它
• 它和 API Server、container runtime、CNI/CSI 的真实分工是什么

这篇文章，我们不堆砌概念，而是沿着真实请求路径，一步步拆解 kubelet 在 Kubernetes 架构中的角色定位、职责边界和运行机制。

---

文章开头，先给大家一个概述性的结论：

kubelet 是运行在每个 Node 上的 Node Agent（节点执行代理），专门负责把 API Server 中的“Pod 期望状态”，变成节点上“真实运行的容器”，并持续汇报真实状态。

• 跟 API Server 打交道
• 把 “Pod 规范” 变成真正跑起来的容器
• 上报节点和 Pod 的真实状态
• 提供日志、exec 等接口给 API Server 用

我们可以把 kubelet 理解成：“Kubernetes 控制面的远程执行器 + 节点状态汇报员 + Pod 生命周期经理”。

---

1️⃣ kubectl → API Server → kubelet 调用链路

以这条调用链为例：

kubectl  →  API Server  →  kubelet（对应节点）

• kubectl get pods
  • kubectl 只请求 API Server
  • API Server 从 etcd 读 “期望状态 + 当前状态”
  • 不直接找 kubelet（除非需要实时拉状态）
• kubectl logs / kubectl exec / 端口转发
  • kubectl 请求 API Server
  • API Server 再通过 HTTPS 去调用 对应 Node 上的 kubelet API
  • kubelet 去和容器 runtime 通信（比如 containerd），拿日志 / 开交互 / 转发数据

这条链上的分工角色如下：

组件	角色
kubectl	用户 CLI 客户端
API Server	控制面入口 / 网关
kubelet	每台节点上的 “执行代理”

我们可以用一句话记住： 凡是“跟节点上容器打交道”的具体动作，都是 kubelet 在干。

---

2️⃣ kubelet 的核心职责

kubelet 本质上是一个「Node 级别的控制器」，它不断做同一件事：“把 API Server 中分配给本节点的 Pod 的 期望状态，收敛成节点上真实存在的 运行状态。”

① 接收 “期望状态”：PodSpec → 真正容器

控制平面通过 API Server 下发：

• “在 Node X 上应该跑哪些 Pod（以及怎么跑）”

kubelet 在本节点做的事：

1. 持续 watch API Server 中调度到本节点的 Pod 对象（spec.nodeName == 本节点），
2. 对比：
   • 当前节点上“实际运行”的容器情况
   • 与 Pod 对象里“期望状态”是否一致
3. 如果发现：
   • 当期望的 Pod / 容器不存在时，调用 CRI 创建并启动容器
   • 当不再期望存在的 Pod 仍在运行时，优雅终止并清理资源
   • 当 PodSpec 发生变化导致运行状态不再符合期望时，通过重建容器使状态重新收敛

在 Kubernetes 架构中，kubelet 是唯一直接与容器运行时交互的组件。Control Plane 仅以声明式方式描述期望的 Pod 状态并完成调度决策，而 kubelet 作为节点级执行代理，负责将这些期望转化为节点上的实际运行结果。

kubelet 通过 CRI gRPC 接口与 containerd、CRI-O 等运行时通信，执行包括镜像拉取、Pod sandbox 创建、容器创建与启动、状态查询与资源清理等所有与容器生命周期相关的操作。

因此，“在哪个节点启动哪个容器、如何启动” 并非由控制面直接完成，而是由 kubelet 在本节点结合容器运行时协同完成。

---

② 管理 Pod 生命周期与健康检测

kubelet 负责：

• 创建 / 启动 / 停止 容器
• 挂载 Volume（本地目录、NFS、CSI 存储等）
• 设置环境变量、secret、configMap 注入
• 处理 probe：
  • livenessProbe
  • readinessProbe
  • startupProbe

探针也是 kubelet 执行的：

• HTTP GET /exec / TCP check
• 失败次数超阈值 → 杀容器、重启
• 结果上报给 API Server（Pod 是否 Ready/Running）

---

③ 上报 Node 和 Pod 状态（NodeStatus / PodStatus）

kubelet 周期性地：

• 向 API Server 上报 Node 状态：
  • 当前 CPU / 内存 容量与使用情况
  • Conditions（Ready / NotReady / DiskPressure / MemoryPressure 等）
  • 节点标签、污点变化等
• 上报 PodStatus：
  • 容器状态（Running / Waiting / Terminated）
  • 重启次数
  • ExitCode
  • 最后一次退出原因 / 消息

调度器（kube-scheduler）和控制器都是基于这些状态做决策的。如果没有 kubelet 的上报，控制面就看不到真实世界里发生了什么。

---

④ 作为 “节点 API” 被 API Server 调用

我们使用的：

• kubectl logs
• kubectl exec
• kubectl port-forward

背后都是：

1. kubectl 请求 API Server
2. API Server 建立到 对应 Node 上 kubelet 的连接
3. kubelet 再去跟容器 runtime 通信，执行相应操作
   • 读容器日志
   • 建立 tty 通道
   • 建立端口转发隧道

这条链路里：

• kubelet 暴露一个 HTTPS 服务（kubelet API）
• API Server 用 apiserver-kubelet-client.crt/key 以客户端证书身份访问
• kubelet 的 --client-ca-file 校验“对方是否是合法 API Server”

这里 kubelet 相当于“节点上的本地代理控制器”，外面所有对容器的操作必须通过它。

---

⑤ 集成 CNI / CSI / 其他插件

kubelet 并不“直接配置网络或存储”，但它是统一调度者。

• 网络（CNI）：
  • Pod 创建时，kubelet 调 CNI 插件（如 calico、flannel、cilium）
  • 为 Pod 设置网络命名空间与 IP
  • Pod 删除时调用 CNI cleanup
• 存储（CSI）：
  • 按照 PVC / PV 绑定结果
  • 调 CSI driver 完成卷的 attach / mount / unmount / detach

它自己不会直接“配置网卡 / 存储”，而是负责调度相应的插件。

---

⑥ TLS 引导、证书轮换、安全接入

kubelet 负责节点级的安全接入：

• Bootstrap Token 加入集群
• 自生成私钥 + CSR
• 提交 CSR 给 API Server
• 获得 kubelet-client 证书
• 定期自动轮换证书

运行期通信全部基于 mTLS：

kubelet ↔ API Server

这是 Kubernetes 安全模型中非常关键的一环。

---

3️⃣ 整体架构视角：kubelet 在 Kubernetes 里的位置

从全局视角看，kubelet 处在一个极其关键的中间层：

注：Control Plane 严格来说仅指 Kubernetes 集群内部的控制组件（如 kube-apiserver、kube-scheduler、kube-controller-manager、etcd）。图中 User 与 kubectl 为集群外部的控制入口，用于表示控制请求的来源，而非 Control Plane 的组成部分。

• 向上：只信任 API Server
• 向下：掌控容器、网络、存储
• 对外：所有节点级操作的唯一入口

---

4️⃣ 如果 kubelet 出问题，会发生什么？

常见现象：

• Node 变成 NotReady
• Pod 无法调度到该 Node
• 已有 Pod 状态不更新 / 重启不生效
• kubectl logs/exec 失败：
  • Error from server: error dialing backend
• 控制面仍然可以工作（其它节点正常）

排查方式通常为：

systemctl status kubelet
journalctl -u kubelet -f

---

5️⃣ 总结

kubelet 是 Kubernetes 在每个节点上的“执行引擎 + 状态感知器”：

• 接收 API Server 下发的 Pod 期望状态
• 调用 container runtime / CNI / CSI 让 Pod 真正跑起来
• 周期性上报 Node 和 Pod 状态
• 提供日志、exec、端口转发等能力（给 API Server 用）
• 通过 mTLS 与 API Server 建立安全信任关系

没有 kubelet，控制面就只剩 “期望的 YAML”，和真实的机器、容器世界完全脱节。