测试云原生质量保障【免费下载链接】originConformance test suite for OpenShift项目地址https://gitcode.com/gh_mirrors/or/origin点击查看免费下载MonitorTests 是 OpenShift origin 测试框架中的一类特殊测试它们不直接验证某个功能点而是在一个 TestSuite 运行期间持续观测集群状态测试结束后将观测结果转化为monitorapi.Intervals时间区间和 JUnit 测试用例直接影响整次 JobRun 的成败判定。本文以 pkg/monitortests/README.md 为主线结合 pkg/monitortestframework 框架接口与 pkg/monitor 控制器源码完整讲清 MonitorTests 的定义、选择机制、七阶段生命周期、数据模型与资源管理约束帮助读者理解 OpenShift 一致性测试中“边跑测试、边守门”的实现原理。什么是 MonitorTests按照 pkg/monitortests/README.md 的定义MonitorTests are tests that run while a set of tests (TestSuite) is running and observe the cluster during this time. Once the TestSuite is finished, the MonitorTests can producemonitorapi.Intervals(these feed the timelines) and produce junit (succeeded, failed, or skipped). The junit are represented as TestCases in the job run and influence the pass/fail of the job run.即 MonitorTests 是一组“伴随测试”在 TestSuite如 conformance、升级conformance 作业执行期间启动负责收集集群在压力下的行为证据TestSuite 结束后它们输出两类产物——monitorapi.Intervals描述“某对象在某时间段内处于某种状态/发生了某事件”的时间区间最终汇入各时间线timeline图表JUnit 测试用例succeeded / failed / skipped 三种状态作为 TestCases 进入 JobRun 统计直接决定作业通过与否。仓库中所有 MonitorTest 实现集中在 pkg/monitortests 目录下按子系统划分为 authentication、clusterversionoperator、etcd、kubeapiserver、network、node、storage、testframework 等子包文档首行的 “To be renamed to MonitorTests” 表明该目录命名正在向“MonitorTests”这一正式术语收敛。监控集的选择Stability 等级、精确列表与禁用列表生命周期第一步是“TestSuite 指示一个稳定性等级stability level以此控制本套 TestSuite 运行期间执行哪些 MonitorTests”。源码中该机制由 pkg/monitortestframework/types.go 中的两个类型承载type ClusterStabilityDuringTest string var ( Stable ClusterStabilityDuringTest Stable // 测试期间不预期任何组件停机也不发生升级 Disruptive ClusterStabilityDuringTest Disruptive // 作业预期会主动制造集群中断 SpotCheck ClusterStabilityDuringTest SpotCheck // 最小化、低敏感性的快速健康检查 )Stable全部监控测试以硬失败hard fail方式运行是标准 conformance 作业使用的完整集合Disruptive破坏性测试会主动打断集群因此一些更敏感的监控项仍要运行以收集信息但其 JUnit 结果会被转换为 flake——在 CI 中可见、但不会使作业失败见 types.go 注释SpotCheck只运行一个精选子集敏感项同样转为 flake。选择逻辑实现在 pkg/defaultmonitortests/types.go 的NewMonitorTestsFor中先按 stability 等级取基础注册表newDefaultMonitorTests/newDisruptiveMonitorTests/newSpotCheckMonitorTests再用MonitorTestInitializationInfo中的ExactMonitorTests只保留列出的测试或DisableMonitorTests从全集移除列出的测试做二次过滤。对应到 pkg/test/ginkgo/cmd_runsuite.go 的命令行参数参数作用默认值--cluster-stability指定稳定性等级取值Stable、Disruptive、SpotCheck空按Stable处理--monitor精确指定只运行这些 MonitorTests空按 stability 等级取默认集--disable-monitor从默认集中禁用指定 MonitorTests其余默认值不受影响空三个稳定性集合的具体差异可以从注册表源码直接读出例如 Stable 集合在 newDefaultMonitorTests 中注册了audit-log-analyzer、pod-network-avalibility、ingress-availability、image-registry-availability等约 50 个监控项而 Disruptive 集合L229-L282把etcd-log-analyzer与告警监控以monitortestframework.AsFlake模式注册“etcd-log-analyzer flaked due to intentional disruption”并整体省略了网络/注册机/监控 API 等对破坏性作业价值不大的项SpotCheck 集合L288-L322则只保留 CVO 状态、etcd 日志flaked、节点/Pod 生命周期、集群 Operator 与事件收集器以及必要的序列化器。注册调用形如monitorTestRegistry.AddMonitorTestOrDie(etcd-log-analyzer, etcd, etcdloganalyzer.NewEtcdLogAnalyzer(monitortestframework.HardFail))第二个参数是Jira 组件名框架会把它强制注入该测试产出的每一个 JUnitTestCase见 pkg/monitortestframework/types.go 中AddMonitorTest的注释“The jira component will be forced into every JunitTestCase”便于 CI 按组件归集失败。MonitorTests 的完整生命周期README 给出的 8 步生命周期与 pkg/monitor/monitor.go 中Monitor控制器的Start/Stop/SerializeResults三个方法一一对应。逐步对照如下。1. 选择并初始化 Monitor 控制器TestSuite 二进制按 stability 等级选出 MonitorTests 集合用它初始化一个名为Monitor的控制器。对应NewMonitor(recorder, adminKubeConfig, storageDir, monitorTestRegistry)monitor.go#L48-L59四个输入分别是共享的记录器、admin kubeconfig、存储目录、以及前面章节讲到的注册表。2. 先于 TestSuite 启动PrepareCollection StartCollection在 TestSuite 开始前Monitor.Start(ctx)依次调用注册表的PrepareCollection和StartCollectionmonitor.go#L64-L87。两者都传入 admin kubeconfig 和 Recorder两个要点值得注意PrepareCollection负责在集群上预先布置好收集数据所需的一切资源并返回StartCollection可以阻塞直至 context 被取消即它代表“持续观测”阶段每个 MonitorTest 的 StartCollection 是在 pkg/monitortestframework/impl.go 中并发每个测试一个 goroutine运行的且包了 panic 保护。README 特别强调同一集群上可能同时运行多个 TestSuite因此每个 MonitorTest 用 admin kubeconfig 创建资源时必须保证不与其他套件冲突并自行跟踪资源以便后续清理。此外MonitorTest 允许保存 admin kubeconfig 备用、派生 goroutine并通过 Recorder 在整个测试过程中随时写入 Intervals。README 中列举的StartCollection用途在代码里同样有体现它可以“利用 admin kubeconfig 在集群上创建任何必要资源”。3. TestSuite 执行期间TestSuite 内部的 TestCases 此时开始运行有时并行有时串行。MonitorTests 在此期间只做两件事向 Recorder 写 Intervals/资源以及维持自己的 watch、日志流、采样器等后台协程。4. TestSuite 结束Stop 阶段四个函数的严格串行顺序当 TestSuite 跑完Monitor.Stop(ctx)按 README 第 7 步的要求执行收尾。关键在于所有 MonitorTest 都会先完成同一个阶段再进入下一个阶段README 原文“all MonitorTests complete CollectData before any is called with ConstructComputedIntervals”源码在 monitor.go#L89-L169CollectData(beginning, end)传入起止时间可访问集群或做其他任何必要操作返回一组 Intervals。典型实现包括流式抓取节点/Pod 日志中的特定消息、查询 Prometheus。此时产出的每个 Interval 都被视为源区间source interval——不可由其他数据重算得到的原始证据。注册表层面各测试并发执行impl.go#L198-L289收集到的 intervals 汇入 Recorder。ConstructComputedIntervals(所有 CollectedData, 记录的 resources, beginning, end)输入是全部源区间加 TestSuite 期间记录的资源状态MonitorTest 据此生成派生computed区间。常见用法是把 Pod/Node 状态的瞬时变化创建、Ready、重启、删除等单点事件聚合成描述“某活动持续时段”的构造区间。注意各 MonitorTest 之间此阶段的调用顺序不保证types.go#L140-L144且应只返回新构造的区间。EvaluateTestsFromConstructedIntervals(最终 Intervals 集合)基于最终区间集合判定各项具体测试通过或失败例如“中断时间是否过长”“Pod 重启是否过多”。Cleanup清理本 MonitorTest 在集群上创建的资源。这是第一次也是可能多次的清理——中断interrupt路径同样会调用 Cleanup因此实现必须幂等容忍多次串行或并发的调用。Monitor.Stop还会在评估前把用于判定 JUnit 的完整事件集落盘到events_used_for_junits_时间戳.jsonmonitor.go#L130-L134方便事后审计“判定依据到底是哪些事件”。5. 落盘WriteContentToStorage 与 JUnit 输出Monitor 停止后SerializeResults先按起止时间截取最终区间monitor.go#L182-L184注释解释了为何要用起止时间限界让 e2e 阶段与升级阶段的监控各自只看得到本阶段的区间然后逐个调用WriteContentToStorage(storageDir)让每个 MonitorTest 写入会被 JobRun 归档保存的数据。README 对此有明确禁区Do not write Intervals, RecordedResources, or junit xml files. You can do things like write summary or metadata files for the run, like how many requests a particular client made.即 Intervals、被跟踪资源、JUnit XML 均由框架统一负责写入MonitorTest 只应写摘要/元数据类文件例如某客户端发出了多少请求。随后Monitor.serializeJunit把所有结果写成e2e-monitor-tests_suffix.xmlmonitor.go#L232-L268未带前缀的用例名会被自动补上默认的[Monitor:Unknown]前缀。MonitorTest 接口七个方法的职责契约上述生命周期在框架中被形式化为 pkg/monitortestframework/types.go 的MonitorTest接口每个方法上的注释就是对新作者的硬约束方法签名要点框架注释的核心约束PrepareCollection(ctx, adminRESTConfig, recorderWriter) error准备收集数据所需的全部资源出错不会中止流程但会产生一个使 JobRun 失败的 JUnit 失败项StartCollection(ctx, adminRESTConfig, recorderWriter) error可阻塞至 context 取消出错同样转为 JUnit 失败CollectData(ctx, storageDir, beginning, end) (Intervals, []JUnitTestCase, error)storageDir 在此阶段只读不写返回的 JUnitTestCase 名称在不同运行中必须稳定CI 按聚合通过率统计避免使用会随时间变化的具体数字ConstructComputedIntervals(ctx, startingIntervals, recordedResources, beginning, end) (Intervals, error)各测试间调用顺序不保证只返回构造出的区间EvaluateTestsFromConstructedIntervals(ctx, finalIntervals) ([]JUnitTestCase, error)基于最终区间产出 JUnit用例名同样要求跨运行稳定WriteContentToStorage(ctx, storageDir, timeSuffix, finalIntervals, finalResourceState) error不写 JUnit/区间/跟踪资源可把 CollectData 阶段暂存的状态持久化如审计日志 top actors 摘要Cleanup(ctx) error必须幂等多个 defer、多个 abort handler、并发与计划内关机的竞态都可能触发多次调用错误会导致 JobRun 失败以确保清理逻辑可靠数据模型Interval、Recorder 与“观察计数”MonitorTests 的产出统一落在monitorapi包pkg/monitor/monitorapi/types.goIntervalL401-L412内嵌ConditionLevelLocatorMessage外加Source标识来源如SourceEtcdLog、SourcePodMonitor、Display是否提示 UI 默认展示的粗略标记和From/To两个时间点Condition.LevelInfo/Warning/Error三级Locator结构化定位器TypePod、Node、Alert、ClusterOperator、Disruption、KubeEvent 等 20 余种Keys键值对namespace、pod、uid、container、node、machine 等让区间能精确锚定到集群中的具体对象MessageReason如PodReasonReady、UpgradeStartedReason、ContainerReasonRestarted等数十个常量CauseHumanMessageAnnotations。Recorder是贯穿生命周期的共享写入/读取端点monitorapi/types.go#L16-L40Record/RecordAt/AddIntervals/StartInterval/EndInterval供写入Intervals(from, to)/CurrentResourceState()供读取。其实现 pkg/monitor/recorder.go 中有一个值得注意的细节RecordResource会用两个内部注解monitor.openshift.io/observed-update-count与monitor.openshift.io/observed-recreation-counttypes.go#L42-L51跟踪同一资源在观测期内被更新了若干次、被重建UID 变化了若干次——这两个计数只存在于 monitor 侧供后处理识别“热资源”但不会写回集群。Intervals类型自身实现了排序、Filter/Cut/Slice/Clamp等时间操作types.go#L778-L881供各 MonitorTest 做区间运算。错误语义NotSupported、Flake 与“失败即失败”README 强调 MonitorTest 的成败会直接影响 JobRun框架用三种错误语义精细控制这一行为pkg/monitortestframework/errors.go普通 error该阶段的 JUnit 记为失败JobRun 失败——用于让“设置失败”本身可见NotSupportedError表示“当前环境不支持该监控”对应 JUnit 记为skip带原因不失败这正是 README 中“不能跑就明确说明不能跑”的代码化FlakeError表示该失败应呈现为 flake用于 Disruptive/SpotCheck 作业中那些因主动破坏而预期“可能失败”的敏感监控项。配套机制是JUnitsToFlakestypes.go#L64-L110为每个“有失败、无通过”的测试名追加一条通过记录使失败在 CI 结果中可见但不会拉挂作业。这与newDisruptiveMonitorTests/newSpotCheckMonitorTests中传monitortestframework.AsFlake的注册方式配合使用而“关键不变量”critical invariants仍保持HardFail任何情况下硬失败。另一个框架级保证是panic 保护注册表对每个阶段的每个测试都包裹了...WithPanicProtection如 impl.go#L144 的startCollectionWithPanicProtection单个 MonitorTest 的 panic 会被转化为 JUnit 失败而不是拖垮整个监控进程。资源管理与“我的 MonitorTest 在 X 上不运行”README 最后两节是实践约束的精华值得原文继承资源不冲突原则StartCollection中用 admin kubeconfig 创建资源时同一集群会同时承载多个 TestSuite 的监控因此必须确保资源命名不冲突、并自行跟踪以便 Cleanup。结合生命周期可看出这是一个“自建、自盯、自清”的闭环PrepareCollection 建、StartCollection 用、Cleanup 清且 Cleanup 幂等。不支持环境时的正确姿势README “My MonitorTest doesnt run on X” 一节This is a problem for each MonitorTest, not a larger piece of logic. Do not try to add different subsets of MonitorTests that are going to run for different TestSuites. The only distinction we have is for those TestSuites that take etcd offline and time-travel the cluster by restoring from backup. Every other situation should be handled by logic inside the individual MonitorTest to know whether it can work or not. If you cannot determine it with an admin kubeconfig, neither can a customer and this indicates a platform failure that needs correction.即不要为不同 TestSuite 维护不同的 MonitorTests 子集框架层面唯一的例外是会把 etcd 下线并通过备份恢复“时间旅行”的测试套件除该例外外的所有“某环境跑不了”的情况都应写在单个 MonitorTest 内部用 admin kubeconfig 自行探测并返回NotSupportedError。其潜台词是如果连 admin 都探测不出环境是否可用客户同样做不到这是平台缺陷应当修复平台而不是给框架打补丁。目录结构与延伸阅读pkg/monitortests/全部 MonitorTest 实现按子系统分目录authentication、clusterversionoperator、etcd、kubeapiserver、network、node、testframework 等pkg/monitortestframework/MonitorTest/MonitorTestRegistry接口、注册表实现与错误类型pkg/defaultmonitortests/types.go三个 stability 等级的默认注册表是“当前集群到底会跑哪些监控项”的权威清单pkg/monitor/monitor.goMonitor 控制器生命周期各阶段调度与 JUnit/事件落盘pkg/monitor/monitorapi/types.goInterval/Condition/Locator 数据模型与过滤工具函数pkg/test/ginkgo/cmd_runsuite.go--cluster-stability、--monitor、--disable-monitor命令行入口。新增一个 MonitorTest 的标准路径是在 pkg/monitortests 下对应子系统包中实现MonitorTest接口的七个方法无法探测环境时返回NotSupportedError清理务必幂等然后在 pkg/defaultmonitortests/types.go 的相应 stability 注册表中以AddMonitorTestOrDie(name, jiraComponent, test)注册并为其 JUnit 用例名保持稳定、避免易变数字即可被--cluster-stability选中的作业自动纳入观测。赞分享测试云原生质量保障【免费下载链接】originConformance test suite for OpenShift项目地址https://gitcode.com/gh_mirrors/or/origin点击查看免费下载相关推荐Emscripten集成测试并行化加速测试套件执行Emscripten集成测试并行化加速测试套件执行 随着Emscripten项目规模扩大测试套件执行时间成为开发效率瓶颈。本文将详细介绍Emscripten编译器WebAssembly开发工具构建工具Hermes 测试运行器Test Runner完全指南test262 / mjsunit / esprima / flow / CVE 测试套件集成运行与 Skiplist 管理Hermes 测试运行器Test Runner完全指南test262 / mjsunit / esprima / flow / CVE 测试套件集成运行与语言运行时编译器移动开发Whisky在macOS上运行Windows应用的终极解决方案Whisky在macOS上运行Windows应用的终极解决方案 你是否曾经因为某个必备的Windows软件无法在Mac上运行而感到困扰或者想要在macOS上桌面应用上一篇Toggl Track浏览器扩展常见问题解决方案下一篇Turbo Boost Switcher 项目常见问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考