3. 治理控制面蓝图：控制面蓝图概念、核心组件与治理策略注入点
在容器运行时沙箱隔离处置场景中，治理控制面蓝图是定义“如何对运行时行为进行声明式治理”的元控制面。它不直接管理容器生命周期，而是管理治理策略的编排、分发与违约响应。当SLO违约发生时，控制面蓝图负责将违约事件转化为可执行的沙箱隔离动作，并确保整个处置过程可审计、可回滚。
3.1 控制面蓝图核心概念
控制面蓝图借鉴了Kubernetes控制面设计思想，但将关注点从“应用编排”转移到“治理编排”。其核心概念包括：
| 概念 | 定义 | 在沙箱隔离场景中的角色 |
|---|---|---|
| 治理对象 | 被治理的运行时实体（Pod、容器、沙箱、节点） | 违约沙箱实例、违规容器进程 |
| 治理策略 | 声明式的规则集合，定义“什么条件下执行什么动作” | SLO阈值、隔离动作类型（暂停、限流、销毁） |
| 治理状态 | 治理对象当前的健康与合规状态 | 沙箱运行态、违约严重等级、隔离进度 |
| 治理动作 | 策略匹配后触发的原子操作 | 沙箱网络隔离、CPU限流、内存硬限制、沙箱销毁 |
| 治理审计 | 所有治理事件的不可变日志 | 违约时间戳、策略版本、执行结果、回滚凭证 |
设计原则：控制面蓝图与运行时数据面严格分离。蓝图只负责“决策与编排”，不负责“执行与监控”。执行由沙箱代理（Sandbox Agent）在数据面完成，监控由可观测性管道独立采集。
3.2 核心组件
控制面蓝图由三个核心组件构成，它们共同实现了治理策略的声明式生命周期管理：
3.2.1 API Server — 治理策略的单一入口
API Server是控制面蓝图的门面，所有治理策略的创建、更新、删除、查询都通过它完成。它提供：
- 策略注册：接收YAML/JSON格式的治理策略定义，进行语法与语义校验。
- 身份认证与授权：确保只有可信治理员（Operator）或自动化管道可以修改策略。
- 状态持久化：将治理策略、治理对象状态、审计事件写入etcd或等效存储。
- Watch机制：允许Scheduler和Controller Manager订阅策略变更事件。
3.2.2 Scheduler — 治理策略的编排与调度
Scheduler负责将治理策略与治理对象进行匹配，并决定“何时、以何种顺序”执行治理动作。在沙箱隔离场景中，Scheduler的核心职责包括：
- 违约事件路由：接收来自可观测性管道的SLO违约事件，将其映射到对应的治理策略。
- 优先级排序：根据违约严重等级（Critical / Warning / Info）对隔离动作进行排序。
- 资源预算检查：在执行隔离动作前，检查集群剩余资源是否允许执行（例如：避免因隔离操作引发级联故障）。
- 调度决策输出：生成治理动作队列，交由Controller Manager执行。
3.2.3 Controller Manager — 治理动作的执行与状态协调
Controller Manager是控制面蓝图中的“执行引擎”，它持续运行多个控制器循环（Controller Loop），确保治理对象的实际状态与期望状态一致。关键控制器包括：
| 控制器名称 | 职责 | 沙箱隔离场景示例 |
|---|---|---|
| SandboxIsolationController | 执行沙箱隔离动作（暂停、限流、销毁） | 调用沙箱代理API，设置网络规则或cgroup限制 |
| PolicyReconciler | 确保治理策略在集群中一致生效 | 检测策略版本变化，重新下发到所有沙箱代理 |
| AuditController | 收集治理动作执行结果，写入审计日志 | 记录隔离动作开始/完成/失败的时间戳与错误信息 |
| RecoveryController | 处理隔离动作失败后的回滚与重试 | 沙箱销毁失败时，触发二次强制销毁或人工介入告警 |
关键约束：Controller Manager必须实现幂等性。同一治理动作可能因网络抖动被重复触发，控制器必须保证多次执行的结果与一次执行相同，避免沙箱被重复隔离或重复销毁。
3.3 治理策略注入点
治理策略并非一次性全部注入，而是在控制面蓝图的不同阶段、不同层级进行注入。以下是三个核心注入点：
- 策略定义注入点（API Server层）：
- 治理员通过kubectl或治理控制台提交策略YAML。
- API Server进行CRD（Custom Resource Definition）校验，确保策略格式正确。
- 策略被持久化到etcd，并触发Watch通知。
- 策略匹配注入点（Scheduler层）：
- Scheduler监听违约事件流，将事件与策略中的SLO条件进行匹配。
- 匹配成功后，Scheduler将策略中的“动作模板”实例化为具体的“治理任务”。
- 治理任务被注入到Controller Manager的任务队列中。
- 策略执行注入点（Controller Manager层）：
- Controller Manager从任务队列中取出治理任务。
- 调用沙箱代理的gRPC接口，将治理动作注入到目标沙箱。
- 执行结果通过状态回写注入回控制面蓝图，形成闭环。
最佳实践：在策略定义注入点，建议为每个治理策略设置
dryRun: true 模式。在正式生效前，先进行模拟执行，验证策略的匹配逻辑与动作模板是否正确，避免因策略错误导致大规模误隔离。
3.4 控制面蓝图架构总览
下图展示了控制面蓝图的核心组件及其在SLO违约→沙箱隔离处置流程中的交互关系：
3.5 治理策略注入点对比
三个注入点在职责、触发时机与治理粒度上存在显著差异，下表总结了关键对比维度：
| 对比维度 | 注入点①：策略定义 | 注入点②：策略匹配 | 注入点③：策略执行 |
|---|---|---|---|
| 所在组件 | API Server | Scheduler | Controller Manager |
| 触发时机 | 治理员提交策略时 | SLO违约事件到达时 | 治理任务入队后 |
| 治理粒度 | 全局策略模板 | 按违约实例匹配 | 按单个沙箱执行 |
| 失败影响范围 | 策略无法注册，影响所有后续治理 | 违约事件无法匹配，导致漏隔离 | 单个沙箱隔离失败，可触发重试 |
| 可观测性 | 策略版本历史、校验日志 | 匹配延迟、匹配率指标 | 执行延迟、成功率、错误分布 |
| 回滚方式 | 回退策略版本 | 调整匹配优先级或条件 | 调用沙箱代理的回滚接口 |
架构决策：在实现控制面蓝图时，建议将三个注入点分别部署为独立的微服务，通过消息队列（如NATS或Kafka）进行异步通信。这样可以避免单个组件的故障导致整个治理链路中断，同时便于对每个注入点进行独立的扩缩容与故障恢复。