2. 环境总览与架构设计:测试验证环境的整体架构图
在正式搭建资源配额模型的测试验证环境之前,必须先理解整个环境的宏观架构。本章将定义各核心组件的职责、交互关系以及数据流向,为后续的动手部署提供清晰的蓝图。
2.1 整体架构概览
测试验证环境采用分层解耦的设计思想,将策略定义、策略执行、资源模拟、结果监控与报告生成分离为独立的模块。这种架构允许我们单独升级或替换某一组件,而不会影响整个验证链路。
2.2 核心组件职责矩阵
下表详细列出了每个组件的核心职责、输入输出以及关键技术选型。这是后续章节中配置和调试的直接依据。
| 组件 | 核心职责 | 主要输入 | 主要输出 | 推荐技术 |
|---|---|---|---|---|
| 策略引擎 | 加载配额策略,对资源请求做出允许/拒绝决策 | Rego 策略、资源请求 JSON | 决策结果 (allow/deny) + 决策日志 | OPA (Open Policy Agent) |
| 资源模拟器 | 模拟 Kubernetes 集群的资源分配与调度行为 | 模拟命名空间、Pod 规格、配额限制 | 资源分配状态、模拟事件流 | kube-scheduler-simulator / 自研模拟器 |
| 监控系统 | 采集策略决策指标、资源使用率、模拟器状态 | 指标端点 (metrics endpoint) | 时序指标数据 | Prometheus + cAdvisor |
| 报告系统 | 聚合测试结果,生成合规性报告与可视化仪表盘 | Prometheus 查询结果、决策日志 | HTML/PDF 报告、Grafana 仪表盘 | Grafana + 自研报告脚本 |
2.3 组件交互关系与数据流
各组件之间通过事件驱动和拉取/推送两种模式进行通信。理解这些交互关系是排查测试环境故障的关键。
2.4 关键交互流程说明
- 测试触发阶段:测试脚本或 CI 管道构造一个资源请求(例如:创建一个需要 4 核 CPU、8Gi 内存的 Pod),并将其发送给策略引擎。
- 策略决策阶段:策略引擎加载预定义的配额模型(Rego 策略),对请求进行校验。如果请求超出配额,引擎返回
deny并附带拒绝原因;否则返回allow。 - 资源模拟阶段:资源模拟器接收允许通过的请求,在模拟集群中执行资源分配,并更新当前资源使用状态。模拟器会持续暴露资源使用指标。
- 监控采集阶段:监控系统定期从模拟器和策略引擎拉取指标(如决策延迟、拒绝率、资源饱和度),并存储为时序数据。
- 报告生成阶段:报告系统从监控系统查询聚合数据,生成包含通过率、失败原因分布、资源使用趋势的合规报告,供测试人员分析。
设计要点: 策略引擎与资源模拟器之间采用异步解耦设计。即使模拟器暂时不可用,策略引擎仍可独立完成决策并缓存结果,避免单点故障影响整个测试链路。
2.5 环境部署清单
在开始搭建之前,请确保以下基础设施就绪。这份清单也是后续章节的部署索引。
| 序号 | 组件 | 部署方式 | 依赖项 | 章节索引 |
|---|---|---|---|---|
| 1 | OPA 策略引擎 | Docker 容器 / 二进制 | Rego 策略文件 | 第 3 章 |
| 2 | 资源模拟器 | Kubernetes Deployment | 模拟集群配置 | 第 4 章 |
| 3 | Prometheus 监控 | Helm Chart | 指标端点配置 | 第 5 章 |
| 4 | Grafana 报告 | Helm Chart | Prometheus 数据源 | 第 6 章 |
| 5 | 测试脚本框架 | Python / Shell | OPA REST API | 第 7 章 |
注意: 所有组件应部署在同一网络平面内(例如同一个 Docker 网络或 Kubernetes 命名空间),以确保低延迟通信。如果使用跨主机部署,请提前配置好网络策略和 DNS 解析。