2. 控制面架构基础：Kubernetes 控制面组件及其职责

Kubernetes 控制面（Control Plane）是集群的“大脑”，负责维护集群的期望状态、调度工作负载、响应集群事件以及管理所有 API 请求。理解控制面各组件的职责与协作关系，是掌握 Operator SDK 驱动控制面适配的前提。Operator 本质上是通过扩展 API Server 和 Controller Manager 的能力来实现自定义资源的管理。

2.1 控制面核心组件总览

Kubernetes 控制面由四个核心组件构成，它们通常运行在独立的 Master 节点上（生产环境建议高可用部署）。下表总结了各组件的核心功能与通信方式：

2.2 API Server：集群的单一入口

API Server 是 Kubernetes 控制面的前端，所有对集群状态的查询和变更都必须经过它。它负责以下关键职责：

• 认证（Authentication）： 验证请求发起者的身份（客户端证书、、用户名/密码等）。
• 授权（Authorization）： 基于 RBAC、ABAC 或 Webhook 判断请求者是否有权限执行操作。
• 准入控制（Admission Control）： 在对象持久化之前，通过一系列准入插件（Mutating 和 Validating）修改或验证请求。
• RESTful API 服务： 提供标准的 HTTP REST 接口，支持 CRUD 操作（GET、POST、PUT、DELETE、PATCH）。
• etcd 交互： 作为唯一与 etcd 直接通信的组件，将集群状态序列化后存储。

API Server 采用无状态设计，可以水平扩展。所有组件（包括 Scheduler、Controller Manager、kubelet、kube-proxy 以及 Operator）都通过 API Server 进行通信，避免了组件间的直接耦合。

2.3 Controller Manager：状态调节引擎

Controller Manager 是控制面中运行控制器循环的核心组件。它内部包含多个内置控制器（如 Node Controller、Replication Controller、Endpoint Controller、Service Account Controller 等），每个控制器负责将集群的实际状态调节至用户定义的期望状态。

控制器的工作模式遵循“观察-分析-行动”循环：

1. 观察（Watch）： 通过 API Server 的 Watch 接口监听特定资源的变化。
2. 分析（Analyze）： 比较当前状态与期望状态，计算差异。
3. 行动（Act）： 调用 API Server 的接口创建、更新或删除资源，以消除差异。

Operator 本质上是一个自定义控制器，它扩展了 Controller Manager 的能力。Operator SDK 帮助开发者快速构建这种自定义控制器，使其能够监听自定义资源并执行业务逻辑。

2.4 Scheduler：Pod 调度决策者

Scheduler 负责为新创建的 Pod（尚未分配到节点）选择最合适的节点。它通过以下两步完成调度：

• 过滤（Filtering）： 排除不满足 Pod 资源请求、节点亲和性、污点容忍等条件的节点。
• 打分（Scoring）： 对剩余节点进行优先级排序，选择得分最高的节点。

Scheduler 的决策结果通过 API Server 写入 Pod 的 spec.nodeName 字段。Operator 通常不直接与 Scheduler 交互，但 Operator 创建的工作负载（如 Deployment、StatefulSet）最终会由 Scheduler 调度到具体节点。

2.5 etcd：集群状态持久化基石

etcd 是一个分布式、强一致性的键值存储系统，基于 Raft 共识算法实现高可用。它存储了 Kubernetes 集群的所有配置数据、状态数据和元数据，包括：

• 所有 API 对象（Pod、Service、ConfigMap、Secret、CRD 等）的定义和状态。
• 集群的配置信息（如网络策略、RBAC 规则）。
• 集群的当前状态（如节点健康状态、资源使用情况）。

etcd 是控制面的“单点真相源”（Single Source of Truth）。API Server 是唯一直接读写 etcd 的组件，其他组件（包括 Operator）只能通过 API Server 间接访问 etcd。

2.6 控制面组件协作流程

下图展示了用户通过 kubectl 创建一个 Deployment 时，控制面各组件的协作流程：

2.7 控制面组件与 Operator 的关系

Operator 作为控制面的扩展，与各组件的交互关系如下：

• API Server： Operator 通过 API Server 注册 CRD、监听自定义资源事件、读写自定义资源实例。这是 Operator 与控制面交互的主要通道。
• Controller Manager： Operator 的控制器逻辑独立运行，但遵循与 Controller Manager 相同的“调谐循环”模式。Operator SDK 封装了控制器循环的样板代码。
• Scheduler： Operator 通常不直接调度 Pod，但可以通过设置节点亲和性、污点容忍等字段影响调度决策。
• etcd： Operator 不直接访问 etcd，所有数据读写都通过 API Server 完成。etcd 的稳定性直接影响 Operator 的可用性。