反无人机系统工程：低慢小目标检测与软硬杀伤技术解析
2026/9/17 4:51:10
Kubernetes SIG Testing 2021 年度报告全解读：kubetest2 成熟、Prow 能力演进与 Bazel 移除
【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community
本篇技术文章以 Kubernetes 社区仓库中 sig-testing/annual-report-2021.md 为主体骨架，系统解读 SIG Testing 在 2021 年的核心工作：kubetest2 测试框架走向成熟、Prow 为外部开源社区输出 CI/CD 能力（GitHub Apps、配置分片、多租户等）、以及构建系统 Bazel 的彻底移除。同时结合仓库内 SIG Testing 章程、子项目清单、sigs.yaml 以及 端到端测试实战文档 等源码与文档证据，为读者还原 2021 年 Kubernetes 测试基础设施的真实演进路径，并给出可直接落地的 kubetest2 使用方法。
一、SIG Testing 的使命与 2021 年度定位
在深入年度报告之前，先明确 SIG Testing 在 Kubernetes 项目中的职责边界。根据 sig-testing/charter.md 的定义，SIG Testing 关注 Kubernetes 的有效测试与"自动化消除项目苦差事（automating away project toil）"：
- 在范围内：项目 CI 与工作流自动化（prow、tide）、大规模运行 CI 的基础设施（boskos、ghproxy）、测试结果的上传与展示（kettle、testgrid、triage）、作业配置管理（job configs、kubetest）、GitHub 配置管理（peribolos、label_sync）、本地测试工具（kind）以及面向 Kubernetes 的测试框架（e2e 测试框架等）；
- 在范围外：不为其他 SIG 所拥有的特性测试编写、修复或排障，也不负责项目 CI Signal 的日常维护——但会产出去噪工具帮助提升信号质量。
该使命在 sigs.yaml 中被精炼为一句 mission statement："让社区更容易运行测试并贡献测试结果，确保 Kubernetes 在各种集群配置和云提供商之上保持稳定"。2021 年年度报告的所有内容，本质上都是这句话的落地执行。
二、2021 年核心工作亮点盘点
1. kubetest2 框架走向成熟
报告将"kubetest2 is maturing"列为年度首要成果。kubetest2 是 kubetest 的下一代迭代，目标是"启动并运行 Kubernetes 端到端测试的框架"，kubetest 后续将被弃用。在 sig-testing/README.md 的子项目清单中，kubetest2 明确标注为：
Kubetest2 is the framework for launching and running end-to-end tests on kubernetes. It is the next significant iteration of kubetest. We will be deprecating kubetest going forward.
仓库中的 e2e-tests-kubetest2.md 记录了 kubetest2 的具体用法（详见本文第六节），其插件体系覆盖 Google Cloud Compute Engine（kubetest2-gce）、Google Cloud Kubernetes Engine（kubetest2-gke）与 KIND（kubetest2-kind）三类部署目标，支撑起本地开发与云端 CI 的同一套入口。
2. Prow 的秘密同步自动化
报告提到为 ProwJob secrets 实现了自动化的 secret syncing。这是 Prow 运维层面的重要改进：Prow 作业往往需要访问各类凭证，通过自动化同步机制替代人工维护，降低了多集群、多仓库场景下凭证配置漂移的风险。这是 Prow 作为"基于 Kubernetes 的 CI/CD 系统"（见 sig-testing/README.md 中 prow 子项目描述）在自我运维能力上的增强。
3. Prow 对外输出：服务更多开源项目与社区
2021 年 Prow 的另一条主线是"为其他开源项目和社区提供 CI/CD 能力"，年度报告列举了七项具体改进：
| 能力项 | 说明 |
|---|---|
| GitHub Apps 支持 | 允许 Prow 以 GitHub App 而非传统 bot 账号身份接入，提升权限粒度与安全性 |
| 作业配置校验增强 | 严格字段检查、构建集群存在性校验，将配置错误前置到加载阶段 |
| In-repo 配置支持与性能改进 | 支持在仓库内直接维护 Prow 配置，并优化其解析与热加载性能 |
| 配置文件分片 | 支持将配置文件拆分，从而更好地管理审批（approval）权限边界 |
| 新监控栈 | 采用 GKE Workload Metrics + Cloud Monitoring，摆脱对 Grafana 的依赖 |
| OSS-Fuzz 集成 | 接入 OSS-Fuzz，为 Prow 相关组件提供持续模糊测试能力 |
| 私有仓库多租户 | 支持多个私有前端（multiple private front ends），满足私有化部署场景 |
这些能力使得 Prow 从一个"Kubernetes 专用 CI"逐步进化为可被其他社区直接复用的通用 CI/CD 平台，这一点与后续 2022 年度报告中"发布 Prow 文档站点、Prow API 服务（Gangway 组件）合入"等进展形成了清晰的演进脉络（见 sig-testing/annual-report-2022.md）。
4. Bazel 的彻底移除
2021 年完成了两项与 Bazel 相关的里程碑：
- kubernetes/kubernetes 仓库的 Bazel 移除达到 GA：这正是 KEP 2420 - Reducing Kubernetes Build Maintenance（1.23.stable）的目标，标志着 Kubernetes 主仓构建维护成本的显著下降；
- kubernetes/test-infra 仓库的 Bazel 移除接近完成：测试基础设施自身也摆脱了 Bazel，进一步简化依赖与构建流程。
三、KEP 工作与治理讨论
1. 2021 年 KEP 状态一览
年度报告记录了三个与 SIG Testing 直接相关的 KEP 进展：
- Stable：KEP 2420 - Reducing Kubernetes Build Maintenance（随 v1.23 达成 stable）——即上文提到的 Bazel 移除 GA；
- Beta：KEP 2539 - Continuously Deploy K8s Prow（v1.21.beta）——推动 Prow 自身的持续部署，让 Prow 的发布流程也由 Prow 自己驱动；
- Beta：KEP 2464 - kubetest2 CI migration（v1.23.beta）——将 Kubernetes 项目自身的 CI 逐步迁移到 kubetest2 之上，是 kubetest2 成熟度的重要验证场景。
2. 关于"未被 KEP 跟踪的工作"的自我反思
报告坦诚指出：SIG Testing 的大部分工作并未通过 KEP 跟踪，并认为"现有 KEP 流程更适合最终用户特性，更多面向终端用户而非贡献者"。这实际上反映了 SIG Testing 工作性质的特殊性——大量工作是测试基础设施与贡献者体验层面的，很难用面向用户特性的 KEP 模板来表达。报告中明确表达了改进意愿："We need to do better with bringing issues to groups and individuals to gain consensus."（需要在把议题带给相关小组和个人、达成共识方面做得更好。）
这一自我认知与 sig-testing/charter.md 中的治理条款相互印证——章程允许"在不使用 KEP 的前提下提出并做出决策，只要决策被记录在可链接的媒介中"（优先使用 kubernetes/test-infra 上的 issue 记录技术决策），说明 SIG Testing 的治理风格本就是"轻 KEP、重 issue 共识"。
四、项目健康度：风险点与社区健康指标
1. 需要帮助的领域
年度报告以"任何拥有 2 个或更少 OWNER 的领域"为标准，识别出五个健康度风险点：
| 子项目/工具 | 风险描述 |
|---|---|
| Boskos | 功能稳定，但"一旦坏了，项目 CI 就陷入困境"，是项目 CI 的单点依赖 |
| K8s GSM Tool | 实习项目，未获足够牵引力，建议考虑归档并与相关负责人讨论（后续 2022 年度报告 确认其在 2022 年被 Retired） |
| kubetest2 | 仅有一位活跃的 reviewer/approver（报告点名 Ben），存在单点维护风险 |
| Prow | 由于 Grafana 许可变更，Google 无法继续维护 monitoring.prow.k8s.io；已切换至 Google Cloud Monitoring，但仪表盘无法公开可见，需要 SIG-k8s-infra 接管，否则公共监控仪表盘可能很快丢失；其中 boskos 指标仪表盘是最显著的损失，当前 Grafana 实例已被冻结 |
| Triage + Kettle | 优先级不高，但在排查 flaky 测试时被广泛使用 |
这些工具在 sig-testing/README.md 与 sig-testing/charter.md 中均有对应描述：boskos 是"管理各类资源并在不同状态间迁移的资源管理器服务，Kubernetes 项目用它管理 CI/CD 所需的 GCP 项目池"；triage/kettle 属于"测试产物提取、展示与分析"链路。
2. 社区健康指标
SIG Testing 在 2021 年关注的社区健康指标主要是Reviewers 与 Approvers 的数量——这与贡献者梯队（contributor ladder）直接挂钩，参见 community-membership.md。
3. 贡献者引导现状
报告坦承：sig-testing/CONTRIBUTING.md 当时并不存在。当前仓库中的 sig-testing/CONTRIBUTING.md 已补上该文件，内容直接指向 kubernetes/test-infra 的 CONTRIBUTING 文档，说明该缺口已在后续得到弥补。
4. 多公司参与情况
报告确认 SIG Testing 的 OWNERS 以 Google 和 Red Hat 为主力，同时也有来自 ii.co、VMware 等公司的贡献者。在 sigs.yaml 中可以看到当前领导团队同样呈现多公司构成：chairs 来自 Red Hat 与 Google，tech leads 来自 Google 与 Intel，印证了"跨公司协作"是 SIG Testing 的常态。
5. 对社区参与的呼吁
报告明确发出呼吁："We need folks to show up and stick around to climb the contributor ladder."（我们需要有人持续参与、留下来，沿着贡献者阶梯向上攀登。）这意味着除代码贡献外，持续参与评审、担任 reviewer/approver 是 SIG 最需要的外部支持。
五、社区规模数据（2021 年）
年度报告给出的 Membership 数据如下：
| 指标 | 数值 |
|---|---|
| 主 Slack 频道成员数 | 2117 |
| 主邮件列表成员数 | 341 |
| 主会议参会人数（估算） | 10 |
| 主会议互动人数（估算） | 6 |
| SIG 所属包唯一 reviewers 数 | 未填写（后续 2022 年报告给出 24） |
| SIG 所属包唯一 approvers 数 | 未填写（后续 2022 年报告给出 26） |
对照 sig-testing/annual-report-2022.md，次年 Slack 成员增至 2452、邮件列表增至 407，并首次披露了 24 名唯一 reviewers 与 26 名唯一 approvers 的量化指标，可见年度报告模板本身也在逐步完善统计口径。
六、2021 年成果的实战落地：kubetest2 使用速览
kubetest2 的"成熟"并非停留在口号上——仓库中的 e2e-tests-kubetest2.md 给出了完整可用的操作流程，这正是 2021 年 kubetest2 能力建设成果的直观呈现。Kubernetes 的端到端测试基于 Ginkgo/Gomega（BDD 测试框架）构建，kubetest2 是管理这些测试的辅助工具。
安装 kubetest2 及插件：
go install sigs.k8s.io/kubetest2/...@latest可用插件包括 Google Cloud Compute Engine（kubetest2-gce）、Google Cloud Kubernetes Engine（kubetest2-gke）与 KIND（kubetest2-kind）。
构建与启停集群：
# 构建 Kubernetes（legacy 模式） kubetest2 gce --build --legacy-mode # 拉起并启动测试集群 kubetest2 gce --gcp-project <project> --up # 关闭并销毁测试集群 kubetest2 gce --gcp-project <project> --down运行测试与传递 Ginkgo 参数：在--之后的所有参数都会原样传给 Ginkgo，例如：
# 运行匹配 [Feature:Performance] 的测试 kubetest2 gce --test ginkgo -- --focus-regex "\[Feature:Performance\]" # 排除匹配 Pods.*env 的测试 kubetest2 gce --test ginkgo -- --skip-regex "Pods.*env" # 跳过 [Serial] 并开启 2 个并行测试 kubetest2 gce --test ginkgo -- --skip-regex "\[Serial\]" --parallel 2 # 指定测试特定版本（如 v1.26.0-alpha.2） kubetest2 gce --test ginkgo -- --test-package-version v1.18.0调试与清理：测试集群的 kubeconfig 保存在工作目录的_artifacts/kubetest2-kubeconfig，可用KUBECONFIG=./_artifacts/kubetest2-kubeconfig kubectl cluster-info dump收集集群状态；kubetest2在--up时还会自动把日志转储到_artifacts/cluster-logs/。若出现异常遗留资源，执行kubetest2 gce --gcp-project <project> --down即可有序清理。
七、2021 年报告与后续年度的连续性验证
作为佐证，sig-testing/annual-report-2022.md 中的多项条目与 2021 年报告形成前后呼应：
- 2021 年"kubetest2 成熟"→ 2022 年仍在推动 kubetest2 相关维护，并延续对更多 reviewer/approver 的呼吁；
- 2021 年"Prow 监控脱离 Grafana"→ 2022 年 TestGrid API 上线（testgrid-data.k8s.io）、Prow API 服务（Gangway）合入，Prow 的平台化路线持续深化；
- 2021 年"k8s-gsm-tools 建议归档"→ 2022 年正式 Retired；
- 2021 年"CONTRIBUTING.md 缺失"→ 2022 年报告确认该文件已就绪，指向 test-infra 的 Issue Triage 流程。
这组对照说明：年度报告不仅是单年成绩单，更是观察 SIG Testing 长期技术路线（测试框架换代、CI 平台化、构建系统瘦身、监控栈重构）的连续档案。结合仓库内 flaky-tests.md（triage/testgrid 工具链的使用）、testing-strategy.md（测试金字塔与 CI 作业类型）以及 sig-governance.md（治理规范），读者可以在本仓库内完成从"年度成果"到"工程实践"再到"治理机制"的完整知识闭环。
【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考