控制平面组件详解：API Server、etcd、Scheduler 与 Controller Manager

摘要：深入了解 Kubernetes 控制平面的四大核心组件：API Server、etcd、Scheduler、Controller Manager 的工作原理和协作方式。

一、控制平面组件总览

控制平面（Control Plane）是 Kubernetes 集群的管理层，负责集群状态存储、调度决策和编排逻辑。所有组件均通过 API Server 间接或直接交互。

上图展示了控制平面的核心架构：kube-apiserver 作为集群唯一入口，负责认证、授权、准入控制以及请求转发；etcd 存储集群状态；Scheduler 负责 Pod 调度；Controller Manager 运行各类控制器；云环境下可启用 cloud-controller-manager 对接云厂商 API。

二、kube-apiserver — 集群入口与通信枢纽

2.1 职责

API Server 是整个 K8s 集群的唯一入口，所有操作都必须经过它。

API Server 具有四大核心职责：作为 RESTful API 网关提供统一接口；执行认证、授权与准入控制；作为 etcd 的唯一访问层；通过 Watch 机制向其他组件推送资源变更。

2.2 请求处理流程

客户端请求在 API Server 内依次经过认证、授权、准入控制，最后持久化到 etcd。

上述流程保证：先确认请求者身份（认证）、再判断是否被允许执行该操作（授权）、最后校验请求内容是否符合策略（准入控制），通过后再写入 etcd。

2.3 Watch 机制

Watch 是 K8s 实现事件驱动架构的核心机制，各组件通过长期连接订阅资源变更，无需轮询。

当 Pod、Node 等资源发生变化时，API Server 通过 HTTP 长连接主动推送事件给所有 Watcher，实现实时响应。

三、etcd — 分布式键值存储

3.1 什么是 etcd

etcd 是一个分布式键值存储数据库，存储着集群的所有状态数据。

etcd 使用 Raft 协议保证一致性，通过 gRPC 提供服务。存储内容包括 Pod、Service、Deployment、Node、ConfigMap、Secret 等资源的完整状态。只有 API Server 能直接访问 etcd。

3.2 etcd 的 Raft 一致性

etcd 集群采用 Raft 算法实现分布式一致性，多数节点确认后数据才可提交。

Raft 保证：多数节点存活时集群可正常工作。3 节点可容忍 1 个故障，5 节点可容忍 2 个故障。建议使用奇数节点以避免脑裂。

3.3 etcd 备份策略

etcd 数据丢失将导致集群状态全部丢失，必须定期备份并存储到集群外部。

使用 etcdctl snapshot save 创建快照，备份文件应存储到独立存储系统，避免与集群共用故障域。

四、kube-scheduler — 调度器

4.1 调度流程

Scheduler 负责决定新创建的 Pod 应该运行在哪个节点上，分为过滤、打分、绑定三个阶段。

过滤阶段剔除不满足条件的节点（资源不足、亲和性、污点、端口冲突等）；打分阶段对剩余节点评分；绑定阶段选择得分最高的节点并通知 API Server。

4.2 调度考虑因素

Scheduler 在打分时综合考虑：CPU/内存 requests、nodeSelector、亲和性/反亲和性、污点与容忍、节点负载均衡以及数据局部性等因素。

五、kube-controller-manager — 控制器管理器

5.1 控制循环

Controller 通过**控制循环（Reconciliation Loop）**持续确保集群实际状态与期望状态一致。

例如：Deployment 期望 3 个副本，实际仅 2 个 Pod 运行，控制器会创建 1 个新 Pod 直至实际状态与期望一致。

5.2 内置控制器

kube-controller-manager 是单一进程，内部运行多个控制器，分别负责不同资源类型。

此外还包括 Namespace Controller、ServiceAccount Controller，以及 StatefulSet、DaemonSet、CronJob 等控制器。

5.3 Node Controller 工作示例

Node Controller 通过心跳超时检测节点故障，超时后标记为 Unknown，持续无心跳则驱逐该节点上的 Pod。

此流程确保在节点失联时，工作负载能及时迁移到健康节点。

六、cloud-controller-manager

在云环境（AWS、GCP、Azure）中，cloud-controller-manager 负责与云厂商 API 交互。

Node Controller 检查云上 VM 是否已被删除；Route Controller 配置路由；Service Controller 在云环境中创建 LoadBalancer 等资源。自建集群通常不需要此组件。

七、各组件协作全景

从用户创建 Deployment 到 Pod 最终运行，各组件按以下顺序协作：

API Server 接收请求并持久化；Deployment Controller 创建 ReplicaSet；ReplicaSet Controller 创建 Pod；Scheduler 调度 Pod；kubelet 拉取镜像并启动容器，最后汇报状态。

八、常见问题

Q1：API Server 高可用如何实现？

多实例部署 API Server，通过负载均衡器将流量分发到各实例。所有实例共享同一 etcd 集群，保证状态一致。

Q2：etcd 推荐集群规模？

生产环境建议 3 或 5 个节点。单节点仅用于开发测试；7 节点及以上通常无必要，且会增加选举延迟。

Q3：如何自定义调度策略？

可通过配置 Scheduler 的 --policy-config-file 或使用 PodTopologySpread、NodeAffinity 等资源字段实现。Kubernetes 1.25+ 推荐使用 SchedulingProfile 配置。

九、总结