3. 控制面蓝图总览：架构分层与组件交互

多租户运行时日志隔离策略的落地，依赖一个清晰、可扩展的控制面架构。本章从全局视角出发，将整个治理系统拆解为接入层、策略层、执行层、存储层四个逻辑平面，并阐明各层核心组件之间的数据流与控制流交互关系。理解这一分层模型，是后续深入每个模块实现细节的前提。

3.1 四层架构模型

控制面蓝图采用自顶向下的分层设计，每一层职责明确、接口稳定，支持独立演进与水平扩展。下表总结了各层的核心定位与关键组件：

3.2 组件交互流程

下图展示了从租户创建日志隔离策略到日志最终写入隔离存储的完整交互路径。图中使用不同颜色区分四个层级，箭头方向代表控制流与数据流的主要走向。

3.3 关键交互路径详解

为帮助理解组件间的协作细节，以下列出三条核心交互路径，每条路径均对应一个典型的多租户日志隔离场景：

1. 策略创建与下发路径：
   • 租户管理员通过 API Gateway 提交日志隔离策略（YAML/JSON）。
   • Auth Proxy 验证租户身份与 RBAC 权限。
   • Tenant Router 将请求路由至对应集群的 Policy Engine。
   • Conflict Detector 检查新策略是否与同租户或跨租户现有策略冲突。
   • 通过后，Version Controller 生成新版本号并持久化至 etcd。
2. 运行时注入与重定向路径：
   • Sidecar Injector 监听 Pod 创建事件，根据策略为 Pod 注入日志采集 Sidecar。
   • Runtime Hook 通过 CRI 接口修改容器日志输出路径，追加租户标签。
   • Log Agent Controller 动态更新 Fluent Bit 配置，确保日志发往正确的租户 Topic。
3. 日志写入与生命周期路径：
   • 日志数据经 Kafka 缓冲后写入 Tenant Log Store（对象存储桶或独立索引）。
   • Index Manager 按租户 ID + 时间戳构建二级索引，支持跨租户审计查询。
   • Retention Scheduler 根据策略中的 TTL 设置，定期清理过期日志分区。

3.4 组件交互时序示例

以下时序代码片段展示了“创建策略 → 注入 Sidecar → 日志重定向”这一典型场景的调用顺序：

// 伪代码：控制面组件交互时序
1. TenantAdmin  --POST /v1/log-policies--> API Gateway
2. API Gateway  --AuthN/Z--> AuthProxy
3. AuthProxy    --Route--> TenantRouter
4. TenantRouter --Create Policy--> PolicyEngine
5. PolicyEngine --Validate--> ConflictDetector
6. ConflictDetector --OK--> VersionController
7. VersionController --Persist--> etcd (CRD: LogPolicy)
8. SidecarInjector --Watch--> etcd (LogPolicy 变更)
9. SidecarInjector --Mutate--> Pod (注入 Fluent Bit Sidecar)
10. RuntimeHook --CRI Update--> Container (日志路径 + 标签)
11. LogAgentController --Reconfigure--> Fluent Bit (租户 Topic)
12. Fluent Bit --Write--> TenantLogStore (隔离存储)

3.5 架构分层收益总结

采用四层控制面蓝图，为多租户日志隔离带来以下关键收益：