1. Kubernetes 控制面概述：组件总览与高可用设计原则
Kubernetes 控制面（Control Plane）是集群的“大脑”，负责全局决策、状态管理、调度与响应集群事件。控制面组件的稳定性与性能直接决定集群的可用上限。本章从组件职责、交互关系和高可用设计三个维度展开，为后续选型与压测建立知识基础。
1.1 控制面组件总览
控制面由五个核心组件构成，它们各自独立运行，通过 API 进行松耦合通信。下表列出各组件的核心职责、运行方式与关键端口：
| 组件 | 核心职责 | 运行方式 | 默认端口 |
|---|---|---|---|
| kube-apiserver | 提供 RESTful API，是集群所有操作的入口；认证、授权、准入控制、数据持久化代理 | 无状态，水平扩展 | 6443 (HTTPS) |
| etcd | 分布式键值存储，保存集群全部状态数据（配置、元数据、实际状态） | 有状态，Raft 共识 | 2379 (客户端), 2380 (peer) |
| kube-scheduler | 为新创建的 Pod 选择最合适的 Node；基于资源需求、约束、亲和性等策略 | 无状态，可多实例 | 10259 |
| kube-controller-manager | 运行各类控制器（Node、Replication、Endpoint、ServiceAccount 等），确保实际状态趋近期望状态 | 无状态，多实例需选主 | 10257 |
| cloud-controller-manager | 对接云厂商 API，管理负载均衡、存储卷、节点路由等云资源 | 无状态，多实例需选主 | 10258 |
关键认知： kube-apiserver 是唯一与 etcd 直接交互的组件。所有其他组件（scheduler、controller-manager、kubelet、kube-proxy）都通过 apiserver 读写集群状态，绝不直接访问 etcd。这一设计保证了数据访问的一致性与安全审计的集中性。
1.2 控制面组件交互关系
下图展示了控制面内部组件之间的通信路径与数据流向。箭头方向表示请求发起方向，实线为同步调用，虚线为异步 watch 机制。
交互要点：
- kube-apiserver 是唯一与 etcd 交互的组件，所有状态读写必须经过 apiserver 的认证、授权与准入控制链。
- kube-scheduler 通过 Watch 机制监听未调度的 Pod，结合调度算法选出最优 Node，然后将绑定结果写回 apiserver。
- kube-controller-manager 内部包含 30+ 控制器，每个控制器独立 Watch 特定资源，通过调谐循环（Reconcile Loop）驱动实际状态向期望状态收敛。
- cloud-controller-manager 仅在公有云或混合云场景部署，负责将集群资源与云厂商 API 同步。
1.3 控制面高可用设计原则
生产级集群必须消除控制面的单点故障。高可用设计遵循以下五项核心原则：
- 组件多副本部署：kube-apiserver 为无状态，可部署 2~3 个实例，前端通过负载均衡器分发请求。kube-scheduler 和 kube-controller-manager 虽为无状态，但同一时刻只有一个实例执行（通过选主机制），其余实例处于热备状态。
- etcd 集群化：etcd 使用 Raft 共识算法，推荐 3 或 5 节点奇数成员。集群容忍 (N-1)/2 个节点故障。etcd 节点应跨可用区部署，避免单机房故障导致集群不可用。
- 选主（Leader Election）机制：scheduler 和 controller-manager 通过创建
kube-system命名空间下的 Endpoint 或 Lease 对象实现选主。持有锁的实例为 Leader，负责实际工作；其他实例监听锁变更，在 Leader 失联时快速接管。 - API 流量隔离与限流：kube-apiserver 应配置
--max-requests-inflight和--max-mutating-requests-inflight限制并发请求量。关键场景下可将控制面组件与业务组件部署在独立节点池，通过nodeSelector或taint/toleration隔离资源争抢。 - 健康探测与自动恢复：每个控制面组件应配置
--healthz和--readyz端口，由外部监控系统（如 Prometheus + Alertmanager）或容器编排平台（如 systemd、Kubernetes 自身）定期探测，异常时自动重启或替换。
常见误区： 仅部署多个 apiserver 实例但前端未配置负载均衡器（如 HAProxy、Nginx、云 LB），或 etcd 使用 2 节点（无法形成多数派），均无法实现真正的高可用。etcd 2 节点集群在任意单节点故障时即失去写入能力。
1.4 高可用架构参考
下图展示一个标准的三节点控制面高可用部署方案，包含负载均衡层、无状态组件层和有状态存储层：
1.5 选型与性能验证前置思考
在进入后续章节的组件选型与压测之前，需要明确以下三个前提：
| 维度 | 关键问题 | 对性能的影响 |
|---|---|---|
| etcd 存储 | 使用 SSD 还是 HDD？是否启用数据压缩？后端存储配额是否充足？ | 磁盘 IOPS 和延迟直接影响 apiserver 响应时间；etcd 写入延迟是集群性能的主要瓶颈之一。 |
| apiserver 缓存 | 是否启用 --watch-cache？缓存大小如何设置？ |
缓存命中率决定读请求的 etcd 负载；缓存过小导致频繁回源，增大 etcd 压力。 |
| 调度吞吐 | 集群规模（Node/Pod 数量）？是否启用调度框架扩展点？ | 调度器每秒处理的 Pod 数量（Pods/sec）是衡量控制面性能的核心指标之一。 |
课程路线提示： 本章建立了控制面的整体认知。第 2~5 章将逐一深入每个组件的选型参数与性能基准测试方法，第 6 章开始进行全链路压测与瓶颈分析。