2. 控制平面基础：核心职责、与数据平面的区别、在 Kubernetes 中的角色
控制平面是分布式系统和云原生架构的“大脑”。在 Kubernetes 与 Service Catalog 的基线核验通信机制中，控制平面负责全局决策、状态协调与策略下发。理解其核心职责、与数据平面的边界，以及在 Kubernetes 中的具体角色，是掌握后续核验通信机制的前提。
2.1 控制平面的核心职责
控制平面不直接处理业务流量或数据负载，而是专注于以下四项关键任务：
- 状态协调（Reconciliation）：持续观测当前集群状态，通过控制器循环（Control Loop）将其向期望状态（Spec）驱动。这是 Kubernetes 声明式模型的核心。
- 策略决策与调度（Scheduling & Policy）：根据资源请求、约束条件（如亲和性、污点）和全局策略，决定工作负载的放置位置（如 kube-scheduler）。
- 身份与访问管理（AuthN/AuthZ）：验证请求者身份（如 Service Account、用户证书），并基于 RBAC 或 ABAC 策略授权操作。在 Service Catalog 场景中，控制平面还负责 Broker 凭证的核验。
- API 聚合与注册（API Aggregation）：作为所有组件和扩展（如 CRD、Aggregated API Server）的统一入口，提供一致的 API 语义和版本管理。
关键认知： 控制平面是“有状态”的决策中心，而数据平面是“无状态”的执行管道。在基线核验中，控制平面负责“核验逻辑”，数据平面负责“通信转发”。
2.2 控制平面 vs. 数据平面：核心区别
在云原生架构（包括 Service Mesh、API Gateway 和 Kubernetes 自身）中，控制平面与数据平面有明确的职责分离。下表从多个维度进行对比：
| 对比维度 | 控制平面 | 数据平面 |
|---|---|---|
| 核心职责 | 决策、协调、策略下发、状态管理 | 转发、负载均衡、流量处理、数据加密 |
| 处理对象 | API 请求、资源对象（Pod/Service/CRD） | 业务数据包、HTTP 请求、gRPC 流 |
| 性能要求 | 低延迟（毫秒级决策）、高可用（强一致性） | 极高吞吐（微秒级转发）、低抖动 |
| 状态模型 | 有状态（etcd 存储、控制器缓存） | 无状态或最终一致（Sidecar 缓存） |
| 扩展方式 | Operator、Webhook、CRD、Aggregated API | Sidecar 注入、eBPF、DPDK、自定义 Filter |
| 典型组件 | kube-apiserver, kube-controller-manager, kube-scheduler | kube-proxy, Envoy, CoreDNS, CRI 运行时 |
基线核验视角： 在 Service Catalog 通信中，控制平面负责校验 Broker 的 TLS 证书、OAuth2 和 API 版本兼容性；数据平面则负责将校验通过的请求透明地转发到外部 Broker 端点。
2.3 在 Kubernetes 中的具体角色
Kubernetes 控制平面由多个协同工作的组件构成。下图展示了核心组件及其在基线核验通信中的交互关系：
2.4 控制平面在基线核验中的关键角色
在 Service Catalog 基线核验通信机制中，控制平面承担以下三个具体角色：
- 策略定义者：通过 CRD（如
ClusterServiceBroker、ServiceInstance）定义核验基线，包括允许的 Broker 端点、TLS 版本、 颁发者。 - 凭证管理者：管理 Broker 访问所需的 Secret（如 、TLS 证书），并通过控制器自动轮换和分发。
- 合规审计者：记录所有核验通过/失败的事件，生成审计日志，并触发告警（如核验失败次数超过阈值）。
常见误区： 不要将核验逻辑放在数据平面的 Sidecar 中独立实现。控制平面必须集中管理核验策略，否则会导致策略碎片化，难以统一审计和升级。
2.5 控制平面组件与核验流程的映射
下表将 Kubernetes 控制平面组件与基线核验的具体步骤进行映射：
| 核验步骤 | 负责组件 | 关键操作 |
|---|---|---|
| 1. 策略注册 | kube-apiserver + CRD Controller | 接收 ClusterServiceBroker 资源，校验 CRD schema 合法性 |
| 2. 凭证注入 | kube-controller-manager (Service Catalog Controller) | 从 Secret 中读取 Broker 凭证，注入到核验配置 |
| 3. 核验执行 | kube-apiserver (Admission Webhook) | 调用外部核验 Webhook，检查 TLS 证书链和 有效性 |
| 4. 结果持久化 | etcd | 存储核验结果（通过/失败/超时）及关联的审计事件 |
| 5. 策略下发 | kube-apiserver → Sidecar Injector | 将核验通过的策略配置（如允许的 SNI 列表）下发到数据平面 |
通过以上职责划分和组件映射，控制平面为 Service Catalog 基线核验提供了统一的策略入口、安全的凭证管理和可审计的合规记录，确保数据平面只执行经过核验的通信。