2. 控制平面架构基础：控制平面组件、etcd 存储与租户隔离的挑战
在云原生多租户集群中，控制平面是集群的“大脑”，负责所有全局决策与状态管理。理解其核心组件（API Server、Scheduler、Controller Manager）以及底层存储 etcd 的协作机制，是设计高性能租户隔离蓝图的前提。本章将逐一拆解各组件的职责、资源模型交互路径，并揭示在共享控制平面下实现租户隔离所面临的核心挑战。
2.1 控制平面核心组件与职责
控制平面由一组独立但协作的进程组成，每个进程负责集群状态的一个特定方面。下表总结了三大核心组件与 etcd 的关键职责与资源交互特点：
| 组件 | 核心职责 | 资源模型交互特点 | 租户隔离关注点 |
|---|---|---|---|
| API Server (kube-apiserver) | 所有 REST 操作的入口；认证、授权、准入控制；资源验证与持久化。 | 无状态水平扩展；直接与 etcd 交互；是唯一与 etcd 通信的组件。 | 请求认证鉴权粒度、API 优先级与公平性、Watch 连接数隔离。 |
| Scheduler (kube-scheduler) | 为未调度的 Pod 选择最优节点；基于调度策略与资源可用性打分。 | 通过 API Server 读取 Pod 与 Node 资源；写入绑定决策。 | 调度队列隔离、节点资源抢占公平性、自定义调度器扩展。 |
| Controller Manager (kube-controller-manager) | 运行各种控制器（Deployment、StatefulSet、Node 等）；确保实际状态趋近期望状态。 | 通过 API Server 监听资源变化；执行调和循环。 | 控制器并发度、List-Watch 资源开销、租户级控制器资源配额。 |
| etcd | 分布式键值存储；集群所有资源数据的最终持久化后端。 | 强一致性（Raft）；存储所有 API 对象；Watch 机制驱动组件状态同步。 | 存储空间隔离、请求吞吐隔离、Watch 流风暴防护。 |
2.2 控制平面组件协作流程与资源模型路径
下图展示了当用户提交一个 Deployment 资源时，控制平面各组件之间的典型协作流程与数据路径。理解这一路径是定位性能瓶颈和设计隔离策略的基础。
2.3 租户隔离的核心挑战
在共享控制平面架构下，实现租户隔离面临一系列系统性挑战。这些挑战主要集中在资源竞争、安全边界和性能干扰三个维度。
核心挑战矩阵：
- API Server 资源竞争： 大量租户的并发请求（List-Watch、Create、Update）可能导致 API Server CPU、内存和网络连接耗尽。Watch 连接数过多会引发 etcd 和 API Server 的 goroutine 泄漏风险。
- etcd 存储与吞吐瓶颈： 所有租户的资源对象存储在同一个 etcd 集群中。单个租户的异常写入（如大量创建 ConfigMap）可能填满 etcd 存储配额，或导致 Raft 写入延迟升高，影响全局。
- Scheduler 调度公平性： 默认调度器使用全局队列，一个租户的大量 Pod 创建可能阻塞其他租户的调度请求。抢占策略（PriorityClass）若未合理规划，可能导致高优先级租户无限抢占资源。
- Controller Manager 调和风暴： 当某个租户的控制器出现故障（如 Deployment 滚动更新卡住），可能触发频繁的调和循环，消耗 API Server 和 etcd 的请求资源，影响其他租户的控制器正常运作。
- Watch 流风暴： 每个组件和控制器都通过 Watch 监听资源变化。当集群中资源数量巨大（如 10 万个 Pod），Watch 事件的分发和序列化开销会显著增加 API Server 和 etcd 的负载。
2.4 挑战的根源：共享资源模型与无差别竞争
上述挑战的根源在于：控制平面的所有组件共享同一个资源模型和底层存储，且默认缺乏租户维度的优先级与配额隔离机制。 下图展示了这种共享架构下的竞争关系。