3、控制平面组件概览：kubelet、kube-apiserver、kube-scheduler 与 Containerd 的协同工作流
Kubernetes 控制平面与容器运行时的协同是集群调度的核心执行链路。理解 kubelet、kube-apiserver、kube-scheduler 与 Containerd 之间的交互流程，是后续参数调优的基础。本章从组件职责、调用时序和数据流三个维度拆解这一协同机制。
3.1 组件职责边界
四个组件在 Pod 生命周期中承担不同角色，下表概括了各自的核心职责与关键接口：
| 组件 | 核心职责 | 关键接口/协议 | 与 Containerd 的关系 |
|---|---|---|---|
| kube-apiserver | 状态存储、认证授权、RESTful API 网关 | HTTPS / etcd watch | 间接：通过 kubelet 上报状态 |
| kube-scheduler | Pod 调度决策、节点绑定 | ListWatch / Binding API | 无直接交互 |
| kubelet | Pod 生命周期管理、健康探针、资源报告 | CRI (gRPC) / cAdvisor | 直接调用 Containerd |
| Containerd | 容器执行、镜像管理、存储挂载 | CRI / CNI / CSI | 被 kubelet 调用 |
调优视角： kubelet 是控制平面与容器运行时之间的“翻译层”，其 CRI 调用频率、超时设置和缓存策略直接影响 Pod 启动延迟和节点稳定性。
3.2 协同工作流：Pod 创建全链路
一个典型 Pod 从提交到运行的完整流程包含 6 个关键步骤，每一步都涉及组件间的同步或异步通信：
- 提交与持久化： 用户通过 kubectl 或 API 调用向 kube-apiserver 提交 Pod 对象，apiserver 将其写入 etcd 并返回成功。
- 调度决策： kube-scheduler 通过 watch 机制发现未调度的 Pod，执行过滤和打分，选出最优节点，通过 Binding API 将 Pod 与节点绑定。
- 节点感知： kubelet 通过 ListWatch 从 apiserver 获取分配到本节点的 Pod 列表，发现新 Pod 后进入创建流程。
- CRI 调用： kubelet 调用 Containerd 的 CRI 接口（RunPodSandbox → CreateContainer → StartContainer），Containerd 负责拉取镜像、创建沙箱和启动容器。
- 状态上报： Containerd 通过 CRI 返回容器状态，kubelet 将 Pod 状态（Pending → Running）写入 apiserver。
- 持续监控： kubelet 定期执行存活/就绪探针，并通过 cAdvisor 收集资源指标，上报至 apiserver 供调度器和 HPA 使用。
关键时序点： 步骤 4 中的 CRI 调用链是性能瓶颈高发区。镜像拉取时间、沙箱初始化延迟、CNI 网络配置耗时均在此阶段累积。
3.3 协同工作流架构图
下图展示了四个组件在 Pod 创建过程中的交互关系与数据流向：
3.4 关键交互协议与性能敏感点
协同工作流中，以下三个交互环节对性能影响最大，也是参数调优的主要目标：
| 交互环节 | 协议/方式 | 性能敏感点 | 调优方向 |
|---|---|---|---|
| kubelet ↔ kube-apiserver | HTTP/2 (gRPC) ListWatch | Watch 连接数、资源版本号、分页大小 | 调整 kubeAPIQPS / kubeAPIBurst |
| kubelet ↔ Containerd | CRI (gRPC over Unix Socket) | 序列化开销、超时设置、并发调用数 | 调整 CRI 超时、镜像拉取并发度 |
| kube-scheduler ↔ kube-apiserver | HTTP/2 ListWatch + POST | 调度队列深度、抢占策略、节点缓存 | 调整调度周期、抢占策略参数 |
3.5 协同工作流中的状态机视角
从 Pod 状态机角度看，组件协同可以映射为以下状态转换路径。理解这一路径有助于定位故障和性能瓶颈：
常见误区： 很多运维人员将 Pod 启动慢归因于 Containerd，但实际瓶颈往往在 kubelet 的 CRI 调用并发度限制（
maxPods、serializeImagePulls）或 kube-scheduler 的调度队列积压。调优前应先通过链路追踪定位耗时阶段。
3.6 协同工作流中的关键参数映射
以下参数直接控制组件间的交互行为，是后续章节深入调优的入口：
- kubelet → kube-apiserver：
--kube-api-qps、--kube-api-burst、--node-status-update-frequency - kubelet → Containerd：
--container-runtime-endpoint、--runtime-request-timeout、--serialize-image-pulls - kube-scheduler → kube-apiserver：
--kube-api-qps、--kube-api-burst、--permit-wait-timeout - Containerd 自身：
containerd.toml中的[grpc] max_recv_message_size、[plugins."io.containerd.grpc.v1.cri"]下的sandbox_image、max_container_log_line_size