1. 控制面组件总览：API Server、etcd、Scheduler、Controller Manager 的核心职责与资源消耗特征
Kubernetes 控制面由四个核心组件构成，它们共同维护集群的期望状态、调度工作负载并响应故障。理解每个组件的职责与资源消耗模式，是进行容量规划与性能优化的前提。
1.1 组件职责速览
| 组件 | 核心职责 | 关键接口/协议 | 状态存储 |
|---|---|---|---|
| kube-apiserver | 所有 API 请求的入口，认证/授权/准入控制，CRUD 操作代理至 etcd | HTTPS RESTful (JSON/Protobuf) | 无状态（依赖 etcd） |
| etcd | 分布式键值存储，保存集群全部资源对象（Pod、Service、ConfigMap 等） | gRPC (etcd v3 API) | 有状态（Raft 共识） |
| kube-scheduler | 为未调度的 Pod 选择最优 Node，执行过滤与打分算法 | Watch + List API | 无状态（调度队列在内存） |
| kube-controller-manager | 运行多个控制器循环（Deployment、ReplicaSet、Node Lifecycle 等），调和实际状态至期望状态 | Watch + List API | 无状态（领导者选举使用 Lease） |
1.2 资源消耗特征对比
四个组件的资源消耗模式差异显著，直接影响节点规格选型与扩缩容策略。
| 组件 | CPU 消耗特征 | 内存消耗特征 | 网络 I/O | 磁盘 I/O |
|---|---|---|---|---|
| kube-apiserver | 请求并发数驱动，TLS 解密与 JSON/Protobuf 序列化是主要开销 | Watch 连接缓存、请求体缓冲、准入插件缓存 | 高（所有客户端流量汇聚点） | 低（不直接写盘） |
| etcd | 低～中（Raft 日志复制与 WAL 写入） | 内存数据库（MVCC 历史版本 + 缓存），随对象数量线性增长 | 中（Raft 节点间心跳与日志同步） | 高（WAL 顺序写 + 快照写） |
| kube-scheduler | 突发型（调度周期内执行过滤/打分算法） | 调度缓存（Node 信息 + Pod 队列） | 中（Watch 全量 Node/Pod） | 低 |
| kube-controller-manager | 稳定型（控制器循环持续运行） | 各控制器的 Informer 缓存（对象副本） | 中（Watch 各类资源） | 低 |
关键观察：etcd 是唯一有状态且对磁盘延迟敏感的组件；API Server 是吞吐瓶颈；Scheduler 和 Controller Manager 的缓存大小与集群规模（Node/Pod 数量）成正比。
1.3 控制面组件交互架构
下图展示了控制面组件之间的数据流与依赖关系。所有写操作最终由 API Server 代理至 etcd，而 Scheduler 与 Controller Manager 通过 Watch 机制从 API Server 获取状态变更。
1.4 资源消耗的规模驱动因素
控制面组件的资源消耗并非固定值，而是随集群规模与工作负载特征动态变化。以下列出每个组件的主要驱动因素：
- kube-apiserver：并发请求数（尤其是 LIST 与 WATCH 请求）、资源对象数量（影响缓存大小）、准入插件链长度、TLS 握手频率。
- etcd：资源对象总数（直接影响内存占用）、变更速率（影响 WAL 写入与压缩频率）、历史版本保留数（MVCC 堆积）、快照大小。
- kube-scheduler：集群 Node 数量（过滤/打分算法复杂度 O(N)）、待调度 Pod 队列深度、调度策略复杂度（自定义扩展点）。
- kube-controller-manager：受管资源对象数量（每个控制器维护独立 Informer 缓存）、控制器循环频率、领导者选举开销。
容量规划提示：在集群规模超过 500 Node 或 15,000 Pod 时，API Server 的内存与 etcd 的磁盘 I/O 通常最先成为瓶颈。建议提前配置资源配额（ResourceQuota）与 API 优先级（Priority & Fairness）以保护控制面。
1.5 组件故障隔离与高可用设计
生产环境通常采用以下部署模式来保证控制面可用性：
| 组件 | 高可用部署 | 故障影响范围 | 恢复方式 |
|---|---|---|---|
| kube-apiserver | 多副本 + 负载均衡（水平扩展） | 所有 API 请求中断 | 无状态，快速重启或滚动更新 |
| etcd | 3/5/7 节点 Raft 集群 | 集群状态无法读写（脑裂风险） | 需多数节点在线，恢复依赖快照+WAL |
| kube-scheduler | 多副本 + 领导者选举 | 新 Pod 无法调度 | 备用副本自动接管 |
| kube-controller-manager | 多副本 + 领导者选举 | 控制器循环停止（Deployment 不扩缩容、Node 心跳超时） | 备用副本自动接管 |
注意：etcd 是控制面中唯一无法通过简单水平扩展提升性能的组件。Raft 共识机制要求多数节点在线，且写入延迟受最慢节点影响。etcd 的磁盘性能（尤其是 fsync 延迟）直接决定集群的 API 响应延迟上限。