机器可以完成工作，Kubernetes 测试、CI 和自动化贡献者体验的故事

“大型项目有很多不太令人兴奋但却很辛苦的工作。我们认为，在自动化重复性工作上花费的时间比劳累更有价值。如果这些工作无法自动化，我们的文化是认可并奖励所有类型的贡献。然而，英雄主义是不可持续的。” - Kubernetes 社区价值观

像许多开源项目一样，Kubernetes 托管在 GitHub 上。我们认为，如果项目位于开发人员已经工作的地方，使用开发人员已经知道的工具和流程，那么参与的门槛将是最低的。因此，该项目完全采用了该服务：它是我们工作流程、问题跟踪器、文档、博客平台、团队结构等的基础。

这个策略奏效了。它如此奏效，以至于该项目迅速扩展到超出其贡献者作为人类的能力范围。随之而来的是自动化和创新的不可思议的旅程。我们不仅需要在飞行中重建我们的飞机而不坠毁，还需要将其改造成火箭飞船并送入轨道。我们需要机器来完成这项工作。

工作

最初，我们专注于这样一个事实：我们需要支持像 Kubernetes 这样复杂的分布式系统所要求的巨大测试量。必须通过端到端 (e2e) 测试来执行真实世界的故障场景，以确保正常的功能。不幸的是，e2e 测试容易出现抖动（随机故障），并且需要一个小时到一天的时间才能完成。

进一步的经验揭示了机器可以为我们完成工作的其他领域

• PR 工作流程
  • 贡献者是否签署了我们的 CLA？
  • PR 是否通过了测试？
  • PR 是否可以合并？
  • 合并提交是否通过了测试？
• 分类
  • 谁应该审查 PR？
  • 是否有足够的信息将问题路由给合适的人？
  • 问题是否仍然相关？
• 项目健康
  • 项目中正在发生什么？
  • 我们应该关注什么？

当我们开发自动化来改善我们的处境时，我们遵循了一些指导原则

• 遵循适用于 Kubernetes 的推送/轮询控制循环模式
• 首选无状态、松散耦合的服务，这些服务可以很好地完成一件事情
• 首选赋予整个社区权力，而不是赋予少数核心贡献者权力
• 吃自己的狗粮，避免重复造轮子

进入 Prow

这促使我们创建 Prow 作为我们自动化的核心组件。Prow 有点像一个用于 GitHub 事件的 If This, Then That，它内置了一个 命令、插件和实用程序的库。我们在 Kubernetes 之上构建了 Prow，以使我们摆脱对资源管理和调度的担忧，并确保更愉快的运营体验。

Prow 让我们能够做以下事情

• 允许我们的社区通过注释诸如“/priority critical-urgent”、“/assign mary”或“/close”之类的命令来对问题/PR 进行分类
• 根据它们更改的代码量或它们触及的文件自动标记 PR
• 使长时间保持不活动的问题/PR 过期
• 自动合并满足我们 PR 工作流程要求的 PR
• 运行定义为 Knative Builds、Kubernetes Pods 或 Jenkins 作业的 CI 作业
• 强制执行组织范围和每个存储库的 GitHub 策略，例如 分支保护 和 GitHub 标签

Prow 最初由构建 Google Kubernetes Engine 的工程生产力团队开发，并且 Kubernetes SIG Testing 的多个成员积极贡献。Prow 已被其他几个开源项目采用，包括 Istio、JetStack、Knative 和 OpenShift。 Prow 入门需要一个 Kubernetes 集群和 kubectl apply starter.yaml（在 Kubernetes 集群上运行 pod）。

一旦我们有了 Prow，我们开始遇到其他扩展瓶颈，因此产生了额外的工具来支持 Kubernetes 所需规模的测试，包括

• Boskos：管理池中的作业资源（例如 GCP 项目），检查作业的资源并自动清理它们（带有监控）
• ghProxy：一个针对 GitHub API 优化的反向代理 HTTP 缓存，以确保我们的令牌使用不会达到 API 限制（带有监控）
• Greenhouse：允许我们使用远程 bazel 缓存，为 PR 提供更快的构建和测试结果（带有监控）
• Splice：允许我们批量测试和合并 PR，确保我们的合并速度不受测试速度的限制
• Tide：允许我们合并通过 GitHub 查询选择的 PR，而不是按队列排序，从而与 splice 结合使用时，可以显着提高合并速度

扩展项目健康

在解决工作流程自动化后，我们将注意力转向项目健康。我们选择使用 Google Cloud Storage (GCS) 作为所有测试数据的真实来源，从而可以依靠已建立的基础设施，并允许社区贡献结果。然后，我们构建了各种工具来帮助个人和整个项目理解这些数据，包括

• Gubernator：显示给定 PR 的结果和测试历史
• Kettle：将数据从 GCS 传输到可公开访问的 bigquery 数据集
• PR 仪表板：一个感知工作流程的仪表板，允许贡献者了解哪些 PR 需要关注以及原因
• Triage：识别在所有作业和测试中发生的常见故障
• Testgrid：显示给定作业在所有运行中的测试结果，总结跨作业组的测试结果

我们联系了云原生计算基金会 (CNCF) 来开发 DevStats，以从我们的 GitHub 事件中收集见解，例如

• 人们最积极使用的 prow 命令是什么
• 贡献者随时间推移的 PR 审查
• PR 工作流程的每个阶段所花费的时间

走向超越

今天，Kubernetes 项目跨越五个组织的 125 多个存储库。项目中有 31 个特别兴趣小组和 10 个工作组协调开发。去年，该项目在 GitHub 上有超过 13,800 名唯一开发人员的参与。

在任何给定的工作日，我们的 Prow 实例运行超过 10,000 个 CI 作业；从 2017 年 3 月到 2018 年 3 月，它运行了 430 万个作业。这些作业中的大多数都涉及启动整个 Kubernetes 集群，并使用真实世界的场景对其进行练习。它们使我们能够确保所有受支持的 Kubernetes 版本都可以在云提供商、容器引擎和网络插件上正常工作。它们确保最新的 Kubernetes 版本可以使用各种可选功能启用、安全升级、满足性能要求并在各种架构上运行。

通过今天的CNCF 公告 – 指出 Google Cloud 已开始将 Kubernetes 项目的云资源的所有权和管理权转移给 CNCF 社区贡献者，我们很高兴开始另一段旅程。这是一个允许项目基础设施由贡献者社区拥有和运营的旅程，遵循与项目其余部分相同的开放治理模式。您是否觉得很令人兴奋？请在 kubernetes.slack.com 上的 #sig-testing 中与我们交流。

想了解更多信息吗？请查看以下资源

• Prow：测试通往 Kubernetes 下一步的方法
• 自动化和 Kubernetes 贡献者体验

• ←上一篇
下一篇→