Kubernetes CI 健康监控实战基于 TestGrid、SpyGlass 与 Triage 的测试失败排查与 Flake 上报指南【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community本篇指南以 Kubernetes 社区 SIG Testing 的官方监控文档为主体系统讲解如何通过 TestGrid 仪表盘监控核心 Kubernetes 的 CI 作业健康状态、如何判断并处理与你的改动无关的 PR 测试失败以及看到 TestGrid 告警后如何按规范完成「沟通发现 → 填写 issue → 迭代排查」的完整闭环。读完本文你将掌握 TestGrid 的 dashboard/job/test 三层结构、SpyGlass 失败日志取证方法、Triage 跨作业规律分析以及符合社区规范的 Flaking/Failing Test issue 填写技巧能够直接参与 Kubernetes 的 flaky 测试排查与上报工作。概述为什么需要监控 Kubernetes CI 的健康本文档所描述的是一整套用于监控校验核心 Kubernetes 代码变更正确性的 CI 作业的工具与方法。Kubernetes 只在单元测试、集成测试与 e2e 测试全部通过时才合并 Pull Request因此 CI 的健康程度直接决定了所有贡献者合并 PR 的等待时长。相关配套文档还包括Flaky Tests 排查指南定义 flaky、zero-flake 策略、deflaking 方法与 flake 报告规范End-to-End Testing in Kubernetese2e 测试框架、kubetest 用法与测试标签体系Testing Guide单元/集成/e2e 测试总览与 CI 故障排查流程Defining a Robust Testing Strategy测试金字塔与 presubmit/postsubmit/periodic 作业类型设计。用 TestGrid 监控 Kubernetes CI 作业健康TestGrid 是什么TestGrid 是一个高度可配置、可交互的测试结果网格查看仪表盘它把大量测试运行结果以「网格」形式平铺展示便于肉眼快速识别波动flake与失败模式。其后端组件是开源的可以在 TestGrid 仓库中查看实现而负责渲染仪表盘的前端代码目前并未开源。Kubernetes 社区自建了自己的TestGrid 实例用于监控与观察整个项目的健康状况。每个 Special Interest GroupSIG 列表都拥有自己的一组 dashboard每个dashboard由不同的job组成构建 build、单元测试 unit test、集成测试 integration test、端到端测试 e2e test 等这些 dashboard 让不同团队能够监控并理解各自负责领域的运行状况。e2e 测试的组织层级与扁平化名称End-to-Ende2e测试 job 本身又由若干**测试阶段stages**构成例如启动一个 Kubernetes 集群、拆除一个 Kubernetes 集群。而 e2e 测试则按「组件Component→ 子类别Subcategory→ 具体测试用例」的层级组织例如Kubectl 客户端组件测试中包含描述Kubectl logs期望行为的测试其中某一条用例被描述为「should be able to retrieve and filter logs应能检索并过滤日志」。需要特别注意的是这个层级结构目前并未在 TestGrid 中体现。一条测试行test row里包含的是把这些字符串全部拼接成一个扁平字符串后的名称——你在排查失败时看到的往往是一长串拼接名。SIG 的定期监控义务社区强烈建议各 SIG 定期监控自己负责子项目的相关 dashboard。如果你发现某个 job 或测试一直在失败请在对应 SIG 的邮件列表或Slack中提出 issue。社区尤其欢迎以下两类贡献Triage分流Flaky 测试为已知波动测试补充证据、归类根因修复 Flaky 测试从kind/flake标签的 issue 入手这是快速积累 Kubernetes 源码经验与社区声望的捷径详见 Flaky Tests 排查指南。重要提醒所有 SIG 都必须定期监控自己的 job 与测试。如果 job 或测试持续失败或波动flaking那么 Pull Request 的合并将变得异常缓慢。关于波动测试如何扰乱 PR 合并以及如何消除它们可参阅 Flaky Tests。应该监控哪些 dashboard这取决于你想为 Kubernetes 的哪个领域做贡献——你应当监控你正在合作的 SIG 所拥有的 dashboard。此外无论如何都应额外关注以下两个 dashboardsig-release-master-blockingsig-release-master-informing因为这两个 dashboard 上的 job 所运行的测试被 SIG Release 用来判断 Kubernetes 的整体质量以及 master 上的提交是否可以被视为适合发布。其中sig-release-master-blocking中 job 的失败测试会直接阻塞一次版本发布sig-release-master-informing则提供发布健康度参考信号。如果你的贡献涉及过去 Kubernetes 版本的代码例如 cherry-pick 或 backport建议你定期检查过去发布版本对应的blocking与informingdashboard。这与 Defining a Robust Testing Strategy 中「SIG Release 维护决定发布健康度的 Blocking/Informing 两类作业集」的描述相互印证若你的特性或领域对发布至关重要需要按流程将 periodic job 提升为 Blocking 或 Informing。PR 测试失败当失败与你的改动无关时怎么办如果测试在你的 PR 上失败且明显与你写的代码无关这实际上是一个改善 CI 信号质量的机会——你在为修复问题积累证据。第一步查找任何看起来相关的已打开 issue标题中包含该测试名、描述了类似错误等。你可以在用于重新触发 job 的评论中把该 issue 链接上可以显式点名某个 job./test pull-kubernetes-foo [在此粘贴相关 issue 链接]也可以只使用 retest./retest [在此粘贴相关 issue 链接]注意上面的.前缀是为了不真正触发 Prow——若不加前缀/test与/retest会真实触发 CI。之后你可以从 issue 反向链接到你遇到该问题的 PR以刷新bumpissue 的最后更新日期。当你这样做时实际上是在为「修复该 issue 的必要性」增添证据——把贡献者正在承受的痛点记录下来。关于 PR 测试失败排查的更多流程可参考 Testing Guide 中的「Running your contribution through Kubernetes CI」一节打开 PR 后 Prow 会运行 pre-submit 测试非 org 成员需要其他成员执行/ok-to-test失败时可点击Details查看工件测试结果、元数据、失败输出、build log、被测试集群的 kubelet/apiserver 日志、junit xml 文件、测试覆盖率文件等。若失败与改动无关应先判断是否为 flake检查是否已有对应 GitHub issue若没有则新建一个并打上kind/flake标签然后执行/retest重新触发。看到 TestGrid 告警后该做什么告警的三种出现途径如果你是某个 SIG 邮件列表的成员偶尔会收到 TestGrid 发送的邮件报告某个 job 或测试最近失败了。此外在 TestGrid dashboard 的Summary 页点击顶部的Show All Alerts按钮可以看到全部告警也可以对单个 job使用Show Alerts查看该 job 的告警。不过在查看 Summary 页时告警只是次要信息——dashboard 中 job 的当前状态被展示得更为醒目主要有三种形态以下截图取自 sig-release-master-blocking dashboard通过Passing绿色对勾标识例如bazel-build-master: PASSING波动Flaky紫色圆形符号例如bazel-test-master: FLAKY失败并显示告警Failing with alert红色警告标识并额外给出失败统计# Fails、First Failed、Last Passed等。注意右侧的元数据列包括 job 运行时间、最后一次绿灯passing运行的 commit id以及页面加载时间刷新浏览器会同时更新页面与更新时间。沟通你的发现Communicate your findings看到告警后的第一要务是沟通你的发现某个测试或 job 正在 flaking 或 failing。如果你是在邮件列表上看到 TestGrid 告警请回复该邮件线程并说明你正在跟进排查在动手之前先在 GitHub 上检查是否已有相关 issue已记录但未分流not triaged的 Flaky 测试 issue已分流triaged的 Flaky 测试 issueCI Signal Board——按问题解决工作流分段的 flaky 测试 issue。如果该测试的 issue 已存在你可以把 issue 中尚未记录的新发现补充进去。例如一个测试间歇性 flaking而你发现了 issue 中未记录的另一次失败事件就把新信息追加到现有 issue 中具体可做两件事添加发生最新失败的那个 Prow job 的链接记录错误消息error message。新证据尤其有价值——当问题的根本原因尚未确定、issue 仍带着needs-triage标签时。如果该 issue 尚未被记录请在 kubernetes/kubernetes 仓库中新建一个 issue并选择合适的模板Failing Test失败测试模板Flaking Test波动测试模板。填写 issueFlaking Test 的五步实战法两个测试 issue 模板本身都相当直观下面给出的是填写要点与技巧。填写 Flaking/Failing 测试 issue 时请遵循引用测试名与 job 名时使用纯文本——不统一的名称格式会让自动化处理 issue 更加困难留意那些包含可被 markdown 解析格式的测试名如果你是测试维护者请避免在用于命名测试与测试组件的字符串中加入 markdown 格式。以下以node-kubelet-master这个 job 为例演示 Flaking Test issue 的完整填写流程。第一步哪些 job 在 flaking以下截图来自 SIG Release dashboardtestgrid-jobs.png可以看到截图时刻以下 job 处于 flaky 状态conformance-ga-onlyskew-cluster-latest-kubectl-stable1-gcegci-gce-ingresskind-master-parallel第二步哪些测试在 flaking进入sig-release-master-blockingdashboard 的node-kubelet-masterjob可以看到在某个时刻07.19 IST以下测试失败对应 Kubernetes commit 为d8f9e4587对应的 test-infra commit 为fe9c22dc8E2eNode Suite.[sig-node] Summary API [NodeConformance] when querying /stats/summary should report resource usage through the stats api [cos-stable2] kubetest.Node Tests [runner]第三步从什么时候开始 flakingflake 的开始时间可以从 TestGrid 页面头部展示所有测试的那一栏获取。网格头部的红字标注了四类关键信息每个 Prow job 的启动时间——网格中每一列代表该 Prow job 的一次运行Prow job 的运行 id 编号本次被测的kubernetes/kubernetes commit id构建并运行该 Prow job 所用的kubernetes/test-infra commit id——test-infra 仓库中包含 CI job 定义 yaml、CI 用容器镜像构建以及 Prow、SpyGlass 等 CI 组件的实现代码。点击网格中的某个单元格会跳转到SpyGlass查看该 Prow job 的结果这些数据也可以在 Triage 工具中找到见下文。第四步失败原因Reason for failure记录 issue 是为了把 flake 或失败暴露给更广泛的社区作为 issue 报告者你不必立刻找出失败原因或解决方案——只需记录测试运行时报出的错误即可。点击失败运行网格中的红色单元格即可在 SpyGlass 中查看结果。以node-kubelet-master为例从 SpyGlass 总览可以看到 2 个测试失败两者都与 node problem detector 相关且e2e.go: Node Tests阶段被标记为失败因为 node problem detector 测试失败了。你经常会看到「stagese2e job 中的步骤」与测试本身混在一起——stages 告诉你错误发生时 e2e job 正在执行什么操作。点击第一个测试错误会看到希望如此有助于定位失败原因的日志页面下方是整个测试运行的全部日志。请把其中有用的信息复制到 issue 中。你还可以点击日志的行号复制带锚点的 URL从而精确引用日志中的特定一行。第五步其他需要知道的信息非常重要的是要利用Triage工具审视该 flaking 测试在一系列 job中的行为——用它判断在某个 job 中失败的测试是否在其他 job 中也失败以及理解各 job 的整体表现。一个关键细节是TestGrid 中 tab 上显示的 job 名往往是别名。job 定义细节job 名、job 定义配置文件、job 描述可以在 TestGrid 的 tab 名下方找到并带有一个指向该 job 配置 yaml 的 URL。例如点击node-kubelet-master的某次测试运行后SpyGlass 页面左上角显示的真实 job 名为ci-kubernetes-node-kubelet-features注意ci-kubernetes-前缀。随后就可以在Triage 的 job 字段中查询ci-kubernetes-node-kubelet-features注意Triage 查询可以收藏bookmark为深链并能添加到 GitHub issue 中帮助测试维护者理解测试出了什么问题。Triage 还支持通过测试名或失败文本过滤或排除结果来优化查询。本例中可以看到该 job 大约每小时失败 2 次——这种频率规律往往能帮助发现根因模式。迭代Iterate填写完 issue 后在对应的邮件列表线程中提及该 issue如果你收到了 TestGrid 关于该 job/测试失败的邮件在 Kubernetes Slack 中把该 issue 分享给对应的 SIG。不必担心自己不确定如何继续深入调试或解决问题——所有 issue 都是独特的需要一定经验才能上手。暂时可以在 Slack 或邮件列表中向他人求助。附Flake 上报与处理的社区规范补充为了让你填写的 issue 更符合社区期待、更快被处理这里补充 Flaky Tests 排查指南 中的核心规范写好一份 flake 报告应包含以下信息该测试是否在多个 job 中 flaking——可用 Kubernetes 聚合测试结果Triage工具搜索测试名或错误消息同一包或套件中是否有多个测试因相同错误失败指向 TestGrid 中该 flaking 测试所在 job 的历史记录过滤到相关测试失败测试输出——这一点至关重要因为它让 issue 可被搜索Triage 查询链接具体失败的链接如果可以确定 对应 SIG。关于零 flake 策略项目实行「zero-flake」政策——测试 job 不得在测试失败时自动重试。这从 2019 年起生效e2e 测试不再使用ginkgo.flakeAttempts2并在 2023 年被确认为正式策略。避免 flakes 的正确姿势是防御性地编写测试容忍并发、资源争抢与超出预期耗时不依赖固定延迟使用wait.ForeverTestTimeout而非轮询 1~10 秒为日志提供足够上下文以便取证。当 flake 无法在短期内修复时可以将单个测试用例通过给测试名添加[Flaky]标记来隔离大多数 CI job 会排除这类测试这通常需要同时存在一个分配给所属 SIG、标记为priority/critical-urgent、lifecycle/frozen、kind/flake的 issue。小结Kubernetes CI 健康监控是一条「观察 → 沟通 → 取证 → 记录 → 迭代」的完整链路用TestGrid观察 job/测试的通过、波动与失败状态通过邮件列表与 Slack沟通发现点击红色单元格进入SpyGlass提取失败日志与阶段上下文用Triage跨 job 交叉验证失败规律最后按 Flaking/Failing Test 模板记录一份包含 job 名、测试名、起始时间、失败原因与深链的规范 issue并持续迭代直到问题被修复或隔离。这套方法论同样适用于任何依赖 Prow/TestGrid 体系的开源 CI 环境值得每一位 Kubernetes 贡献者掌握。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubernetes CI 健康监控实战：基于 TestGrid、SpyGlass 与 Triage 的测试失败排查与 Flake 上报指南
Kubernetes CI 健康监控实战基于 TestGrid、SpyGlass 与 Triage 的测试失败排查与 Flake 上报指南【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community本篇指南以 Kubernetes 社区 SIG Testing 的官方监控文档为主体系统讲解如何通过 TestGrid 仪表盘监控核心 Kubernetes 的 CI 作业健康状态、如何判断并处理与你的改动无关的 PR 测试失败以及看到 TestGrid 告警后如何按规范完成「沟通发现 → 填写 issue → 迭代排查」的完整闭环。读完本文你将掌握 TestGrid 的 dashboard/job/test 三层结构、SpyGlass 失败日志取证方法、Triage 跨作业规律分析以及符合社区规范的 Flaking/Failing Test issue 填写技巧能够直接参与 Kubernetes 的 flaky 测试排查与上报工作。概述为什么需要监控 Kubernetes CI 的健康本文档所描述的是一整套用于监控校验核心 Kubernetes 代码变更正确性的 CI 作业的工具与方法。Kubernetes 只在单元测试、集成测试与 e2e 测试全部通过时才合并 Pull Request因此 CI 的健康程度直接决定了所有贡献者合并 PR 的等待时长。相关配套文档还包括Flaky Tests 排查指南定义 flaky、zero-flake 策略、deflaking 方法与 flake 报告规范End-to-End Testing in Kubernetese2e 测试框架、kubetest 用法与测试标签体系Testing Guide单元/集成/e2e 测试总览与 CI 故障排查流程Defining a Robust Testing Strategy测试金字塔与 presubmit/postsubmit/periodic 作业类型设计。用 TestGrid 监控 Kubernetes CI 作业健康TestGrid 是什么TestGrid 是一个高度可配置、可交互的测试结果网格查看仪表盘它把大量测试运行结果以「网格」形式平铺展示便于肉眼快速识别波动flake与失败模式。其后端组件是开源的可以在 TestGrid 仓库中查看实现而负责渲染仪表盘的前端代码目前并未开源。Kubernetes 社区自建了自己的TestGrid 实例用于监控与观察整个项目的健康状况。每个 Special Interest GroupSIG 列表都拥有自己的一组 dashboard每个dashboard由不同的job组成构建 build、单元测试 unit test、集成测试 integration test、端到端测试 e2e test 等这些 dashboard 让不同团队能够监控并理解各自负责领域的运行状况。e2e 测试的组织层级与扁平化名称End-to-Ende2e测试 job 本身又由若干**测试阶段stages**构成例如启动一个 Kubernetes 集群、拆除一个 Kubernetes 集群。而 e2e 测试则按「组件Component→ 子类别Subcategory→ 具体测试用例」的层级组织例如Kubectl 客户端组件测试中包含描述Kubectl logs期望行为的测试其中某一条用例被描述为「should be able to retrieve and filter logs应能检索并过滤日志」。需要特别注意的是这个层级结构目前并未在 TestGrid 中体现。一条测试行test row里包含的是把这些字符串全部拼接成一个扁平字符串后的名称——你在排查失败时看到的往往是一长串拼接名。SIG 的定期监控义务社区强烈建议各 SIG 定期监控自己负责子项目的相关 dashboard。如果你发现某个 job 或测试一直在失败请在对应 SIG 的邮件列表或Slack中提出 issue。社区尤其欢迎以下两类贡献Triage分流Flaky 测试为已知波动测试补充证据、归类根因修复 Flaky 测试从kind/flake标签的 issue 入手这是快速积累 Kubernetes 源码经验与社区声望的捷径详见 Flaky Tests 排查指南。重要提醒所有 SIG 都必须定期监控自己的 job 与测试。如果 job 或测试持续失败或波动flaking那么 Pull Request 的合并将变得异常缓慢。关于波动测试如何扰乱 PR 合并以及如何消除它们可参阅 Flaky Tests。应该监控哪些 dashboard这取决于你想为 Kubernetes 的哪个领域做贡献——你应当监控你正在合作的 SIG 所拥有的 dashboard。此外无论如何都应额外关注以下两个 dashboardsig-release-master-blockingsig-release-master-informing因为这两个 dashboard 上的 job 所运行的测试被 SIG Release 用来判断 Kubernetes 的整体质量以及 master 上的提交是否可以被视为适合发布。其中sig-release-master-blocking中 job 的失败测试会直接阻塞一次版本发布sig-release-master-informing则提供发布健康度参考信号。如果你的贡献涉及过去 Kubernetes 版本的代码例如 cherry-pick 或 backport建议你定期检查过去发布版本对应的blocking与informingdashboard。这与 Defining a Robust Testing Strategy 中「SIG Release 维护决定发布健康度的 Blocking/Informing 两类作业集」的描述相互印证若你的特性或领域对发布至关重要需要按流程将 periodic job 提升为 Blocking 或 Informing。PR 测试失败当失败与你的改动无关时怎么办如果测试在你的 PR 上失败且明显与你写的代码无关这实际上是一个改善 CI 信号质量的机会——你在为修复问题积累证据。第一步查找任何看起来相关的已打开 issue标题中包含该测试名、描述了类似错误等。你可以在用于重新触发 job 的评论中把该 issue 链接上可以显式点名某个 job./test pull-kubernetes-foo [在此粘贴相关 issue 链接]也可以只使用 retest./retest [在此粘贴相关 issue 链接]注意上面的.前缀是为了不真正触发 Prow——若不加前缀/test与/retest会真实触发 CI。之后你可以从 issue 反向链接到你遇到该问题的 PR以刷新bumpissue 的最后更新日期。当你这样做时实际上是在为「修复该 issue 的必要性」增添证据——把贡献者正在承受的痛点记录下来。关于 PR 测试失败排查的更多流程可参考 Testing Guide 中的「Running your contribution through Kubernetes CI」一节打开 PR 后 Prow 会运行 pre-submit 测试非 org 成员需要其他成员执行/ok-to-test失败时可点击Details查看工件测试结果、元数据、失败输出、build log、被测试集群的 kubelet/apiserver 日志、junit xml 文件、测试覆盖率文件等。若失败与改动无关应先判断是否为 flake检查是否已有对应 GitHub issue若没有则新建一个并打上kind/flake标签然后执行/retest重新触发。看到 TestGrid 告警后该做什么告警的三种出现途径如果你是某个 SIG 邮件列表的成员偶尔会收到 TestGrid 发送的邮件报告某个 job 或测试最近失败了。此外在 TestGrid dashboard 的Summary 页点击顶部的Show All Alerts按钮可以看到全部告警也可以对单个 job使用Show Alerts查看该 job 的告警。不过在查看 Summary 页时告警只是次要信息——dashboard 中 job 的当前状态被展示得更为醒目主要有三种形态以下截图取自 sig-release-master-blocking dashboard通过Passing绿色对勾标识例如bazel-build-master: PASSING波动Flaky紫色圆形符号例如bazel-test-master: FLAKY失败并显示告警Failing with alert红色警告标识并额外给出失败统计# Fails、First Failed、Last Passed等。注意右侧的元数据列包括 job 运行时间、最后一次绿灯passing运行的 commit id以及页面加载时间刷新浏览器会同时更新页面与更新时间。沟通你的发现Communicate your findings看到告警后的第一要务是沟通你的发现某个测试或 job 正在 flaking 或 failing。如果你是在邮件列表上看到 TestGrid 告警请回复该邮件线程并说明你正在跟进排查在动手之前先在 GitHub 上检查是否已有相关 issue已记录但未分流not triaged的 Flaky 测试 issue已分流triaged的 Flaky 测试 issueCI Signal Board——按问题解决工作流分段的 flaky 测试 issue。如果该测试的 issue 已存在你可以把 issue 中尚未记录的新发现补充进去。例如一个测试间歇性 flaking而你发现了 issue 中未记录的另一次失败事件就把新信息追加到现有 issue 中具体可做两件事添加发生最新失败的那个 Prow job 的链接记录错误消息error message。新证据尤其有价值——当问题的根本原因尚未确定、issue 仍带着needs-triage标签时。如果该 issue 尚未被记录请在 kubernetes/kubernetes 仓库中新建一个 issue并选择合适的模板Failing Test失败测试模板Flaking Test波动测试模板。填写 issueFlaking Test 的五步实战法两个测试 issue 模板本身都相当直观下面给出的是填写要点与技巧。填写 Flaking/Failing 测试 issue 时请遵循引用测试名与 job 名时使用纯文本——不统一的名称格式会让自动化处理 issue 更加困难留意那些包含可被 markdown 解析格式的测试名如果你是测试维护者请避免在用于命名测试与测试组件的字符串中加入 markdown 格式。以下以node-kubelet-master这个 job 为例演示 Flaking Test issue 的完整填写流程。第一步哪些 job 在 flaking以下截图来自 SIG Release dashboardtestgrid-jobs.png可以看到截图时刻以下 job 处于 flaky 状态conformance-ga-onlyskew-cluster-latest-kubectl-stable1-gcegci-gce-ingresskind-master-parallel第二步哪些测试在 flaking进入sig-release-master-blockingdashboard 的node-kubelet-masterjob可以看到在某个时刻07.19 IST以下测试失败对应 Kubernetes commit 为d8f9e4587对应的 test-infra commit 为fe9c22dc8E2eNode Suite.[sig-node] Summary API [NodeConformance] when querying /stats/summary should report resource usage through the stats api [cos-stable2] kubetest.Node Tests [runner]第三步从什么时候开始 flakingflake 的开始时间可以从 TestGrid 页面头部展示所有测试的那一栏获取。网格头部的红字标注了四类关键信息每个 Prow job 的启动时间——网格中每一列代表该 Prow job 的一次运行Prow job 的运行 id 编号本次被测的kubernetes/kubernetes commit id构建并运行该 Prow job 所用的kubernetes/test-infra commit id——test-infra 仓库中包含 CI job 定义 yaml、CI 用容器镜像构建以及 Prow、SpyGlass 等 CI 组件的实现代码。点击网格中的某个单元格会跳转到SpyGlass查看该 Prow job 的结果这些数据也可以在 Triage 工具中找到见下文。第四步失败原因Reason for failure记录 issue 是为了把 flake 或失败暴露给更广泛的社区作为 issue 报告者你不必立刻找出失败原因或解决方案——只需记录测试运行时报出的错误即可。点击失败运行网格中的红色单元格即可在 SpyGlass 中查看结果。以node-kubelet-master为例从 SpyGlass 总览可以看到 2 个测试失败两者都与 node problem detector 相关且e2e.go: Node Tests阶段被标记为失败因为 node problem detector 测试失败了。你经常会看到「stagese2e job 中的步骤」与测试本身混在一起——stages 告诉你错误发生时 e2e job 正在执行什么操作。点击第一个测试错误会看到希望如此有助于定位失败原因的日志页面下方是整个测试运行的全部日志。请把其中有用的信息复制到 issue 中。你还可以点击日志的行号复制带锚点的 URL从而精确引用日志中的特定一行。第五步其他需要知道的信息非常重要的是要利用Triage工具审视该 flaking 测试在一系列 job中的行为——用它判断在某个 job 中失败的测试是否在其他 job 中也失败以及理解各 job 的整体表现。一个关键细节是TestGrid 中 tab 上显示的 job 名往往是别名。job 定义细节job 名、job 定义配置文件、job 描述可以在 TestGrid 的 tab 名下方找到并带有一个指向该 job 配置 yaml 的 URL。例如点击node-kubelet-master的某次测试运行后SpyGlass 页面左上角显示的真实 job 名为ci-kubernetes-node-kubelet-features注意ci-kubernetes-前缀。随后就可以在Triage 的 job 字段中查询ci-kubernetes-node-kubelet-features注意Triage 查询可以收藏bookmark为深链并能添加到 GitHub issue 中帮助测试维护者理解测试出了什么问题。Triage 还支持通过测试名或失败文本过滤或排除结果来优化查询。本例中可以看到该 job 大约每小时失败 2 次——这种频率规律往往能帮助发现根因模式。迭代Iterate填写完 issue 后在对应的邮件列表线程中提及该 issue如果你收到了 TestGrid 关于该 job/测试失败的邮件在 Kubernetes Slack 中把该 issue 分享给对应的 SIG。不必担心自己不确定如何继续深入调试或解决问题——所有 issue 都是独特的需要一定经验才能上手。暂时可以在 Slack 或邮件列表中向他人求助。附Flake 上报与处理的社区规范补充为了让你填写的 issue 更符合社区期待、更快被处理这里补充 Flaky Tests 排查指南 中的核心规范写好一份 flake 报告应包含以下信息该测试是否在多个 job 中 flaking——可用 Kubernetes 聚合测试结果Triage工具搜索测试名或错误消息同一包或套件中是否有多个测试因相同错误失败指向 TestGrid 中该 flaking 测试所在 job 的历史记录过滤到相关测试失败测试输出——这一点至关重要因为它让 issue 可被搜索Triage 查询链接具体失败的链接如果可以确定 对应 SIG。关于零 flake 策略项目实行「zero-flake」政策——测试 job 不得在测试失败时自动重试。这从 2019 年起生效e2e 测试不再使用ginkgo.flakeAttempts2并在 2023 年被确认为正式策略。避免 flakes 的正确姿势是防御性地编写测试容忍并发、资源争抢与超出预期耗时不依赖固定延迟使用wait.ForeverTestTimeout而非轮询 1~10 秒为日志提供足够上下文以便取证。当 flake 无法在短期内修复时可以将单个测试用例通过给测试名添加[Flaky]标记来隔离大多数 CI job 会排除这类测试这通常需要同时存在一个分配给所属 SIG、标记为priority/critical-urgent、lifecycle/frozen、kind/flake的 issue。小结Kubernetes CI 健康监控是一条「观察 → 沟通 → 取证 → 记录 → 迭代」的完整链路用TestGrid观察 job/测试的通过、波动与失败状态通过邮件列表与 Slack沟通发现点击红色单元格进入SpyGlass提取失败日志与阶段上下文用Triage跨 job 交叉验证失败规律最后按 Flaking/Failing Test 模板记录一份包含 job 名、测试名、起始时间、失败原因与深链的规范 issue并持续迭代直到问题被修复或隔离。这套方法论同样适用于任何依赖 Prow/TestGrid 体系的开源 CI 环境值得每一位 Kubernetes 贡献者掌握。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
