📚 课程目录第2章 Kubernetes控制平面核心组件

2. Kubernetes 控制平面核心组件：API Server、etcd、Controller Manager、Scheduler 的角色与通信机制

Kubernetes 控制平面（Control Plane）是集群的“大脑”，负责全局决策与状态管理。其四个核心组件——API Server、etcd、Controller Manager、Scheduler——通过严格定义的接口与通信协议协同工作，共同维护集群的期望状态。理解它们的角色与交互机制，是掌握控制平面接口调用与安全策略集成的基础。

2.1 核心组件角色总览

下表从功能定位、数据流向、安全边界三个维度，对比四个核心组件的职责差异：

组件	核心职责	数据流向	安全关注点
API Server (kube-apiserver)	集群网关，所有组件与外部请求的唯一入口；提供 RESTful API 进行资源操作；执行认证、授权、准入控制。	双向：接收请求 → 写入 etcd；监听 etcd 变化 → 通知客户端。	TLS 终止、RBAC 鉴权、Admission Webhook 集成、审计日志。
etcd	分布式键值存储，保存集群所有资源对象（Pod、Service、Secret 等）的完整状态。	仅接受 API Server 的读写请求；通过 Watch 机制推送变更。	数据加密（静态加密 + TLS 传输）、访问控制（仅 API Server 可直连）。
Controller Manager (kube-controller-manager)	运行多个控制器（如 Node Controller、ReplicaSet Controller），通过控制循环将当前状态调整为期望状态。	单向：通过 API Server 读取状态 → 对比期望 → 通过 API Server 写入调整指令。	ServiceAccount 权限最小化、避免控制器间资源竞争。
Scheduler (kube-scheduler)	为新创建的 Pod 选择最合适的 Node；基于资源需求、约束、亲和性等策略进行调度决策。	单向：通过 API Server 读取未调度 Pod → 写入绑定结果到 API Server。	调度策略配置安全、避免特权 Pod 绕过调度约束。

2.2 组件间通信机制

所有组件间的通信都遵循“以 API Server 为中心”的星型模型。etcd 是唯一不与 API Server 之外的组件直接通信的存储层。这种架构设计保证了状态一致性与安全边界清晰。

  关键原则：Controller Manager 和 Scheduler 从不直接访问 etcd；它们的所有读写操作都通过 API Server 的 REST API 完成。这确保了 etcd 的访问权限可以被 API Server 集中管控。

2.2.1 通信路径与协议

API Server ↔ etcd：使用 gRPC 协议，通过 TLS 双向认证。API Server 是 etcd 的唯一合法客户端。
Controller Manager ↔ API Server：使用 HTTPS，通过 ServiceAccount 或客户端证书认证。Controller Manager 内部各控制器使用 Informer 机制（基于 List+Watch）高效同步资源。
Scheduler ↔ API Server：使用 HTTPS，同样通过 ServiceAccount 认证。Scheduler 通过 Watch 机制监听未调度的 Pod 队列。
外部用户/组件 ↔ API Server：使用 HTTPS，支持多种认证方式（X.509 证书、Bearer 、OIDC 等）。

2.2.2 核心通信流程：Pod 创建与调度

以下流程展示了控制平面组件如何协作完成一个 Pod 的创建与调度：

用户提交 Pod 定义（通过 kubectl 或 API 调用）到 API Server。
API Server 执行认证、授权、准入控制（包括 Secret 挂载策略检查），验证通过后将 Pod 对象写入 etcd。
Scheduler 通过 Watch 机制发现未绑定 Node 的 Pod，执行调度算法，将 Pod 与目标 Node 的绑定关系写回 API Server。
API Server 更新 etcd 中的 Pod 状态，并通知目标 Node 上的 kubelet。
Controller Manager 中的相关控制器（如 ReplicaSet Controller）持续监控 Pod 状态，确保副本数符合期望。

2.3 控制平面组件交互架构图

下图展示了四个核心组件之间的通信关系与数据流向：

2.4 API Server 的 Watch 机制与 Informer 模式

Controller Manager 和 Scheduler 的高效运行依赖于 API Server 提供的 Watch 机制。该机制允许客户端（如控制器）建立长连接，实时接收资源对象的变更事件（ADDED、MODIFIED、DELETED），而无需频繁轮询。

最佳实践：生产环境中，Controller Manager 和 Scheduler 内部使用 Informer（基于 List+Watch 的本地缓存库）来减少对 API Server 的直接请求压力。Informer 将资源对象缓存在本地内存中，仅通过 Watch 事件增量更新，大幅提升性能。

2.4.1 Watch 事件流示例

以下代码片段展示了 Scheduler 如何通过 Watch 监听未调度的 Pod：

# Scheduler 内部逻辑（伪代码）
watcher, err := clientset.CoreV1().Pods("").Watch(context.TODO(), metav1.ListOptions{
    FieldSelector: "spec.nodeName=",  # 仅监听未绑定 Node 的 Pod
})
for event := range watcher.ResultChan() {
    pod := event.Object.(*v1.Pod)
    switch event.Type {
    case watch.Added:
        // 将 Pod 加入调度队列
        scheduleQueue.Add(pod)
    case watch.Modified:
        // 更新 Pod 状态
        scheduleQueue.Update(pod)
    case watch.Deleted:
        // 从调度队列移除
        scheduleQueue.Delete(pod)
    }
}

2.5 控制平面通信的安全边界

在《控制平面接口调用与 Secrets 管理准入策略集成》课程中，理解通信安全边界至关重要。以下是各组件通信的安全控制要点：

通信路径	认证方式	授权方式	传输加密
外部用户 → API Server	X.509 证书 / Bearer / OIDC	RBAC（Role-Based Access Control）	TLS 1.2+
Controller Manager → API Server	ServiceAccount （自动挂载）	RBAC（系统预置 ClusterRole）	TLS 1.2+
Scheduler → API Server	ServiceAccount （自动挂载）	RBAC（系统预置 ClusterRole）	TLS 1.2+
API Server → etcd	双向 TLS 证书认证	etcd 角色权限（仅允许 API Server 用户）	TLS 1.2+

安全风险提示：如果 etcd 的 TLS 配置不当或 API Server 的 etcd 客户端证书泄露，攻击者可能直接读取 etcd 中的 Secrets 数据。在生产环境中，务必启用 etcd 的静态数据加密（Encryption at Rest），并严格限制 etcd 的网络访问来源。

2.6 组件角色与 Secrets 管理的关系

在后续章节中，我们将深入探讨 Secrets 管理准入策略。这里先建立控制平面组件与 Secrets 生命周期的关联：

API Server：Secrets 的创建、读取、更新、删除均通过 API Server 进行。准入控制器（如 SecretMutation 或自定义 Webhook）可以在写入 etcd 前对 Secrets 进行校验或转换。
etcd：Secrets 的持久化存储位置。未加密的 etcd 数据是 Secrets 泄露的最大风险点。
Controller Manager：某些控制器（如 ServiceAccount Controller）会自动创建和管理 Secrets（如 ServiceAccount Secret）。
Scheduler：调度决策不直接操作 Secrets，但 Pod 的调度结果会影响 Secrets 被挂载到哪个 Node 上，间接影响 Secrets 的物理分布。

理解这些组件的角色与通信机制，为后续设计 Secrets 管理准入策略（如强制加密、限制挂载范围、审计访问日志）奠定了架构基础。