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

“大型项目有很多不那么激动人心但却很辛苦的工作。我们高度重视花费在自动化重复性工作上的时间，胜过繁重的手工劳动。如果这些工作无法自动化，我们的文化是认可并奖励所有类型的贡献。然而，个人英雄主义是不可持续的。” - Kubernetes 社区价值观

与许多开源项目一样，Kubernetes 托管在 GitHub 上。我们认为，如果项目存在于开发者已经工作的地方，并使用他们已经熟悉的工具和流程，参与门槛会最低。因此，该项目完全拥抱了这项服务：它成为我们工作流程、问题跟踪器、文档、博客平台、团队结构等的基础。

这个策略奏效了。它奏效得如此之好，以至于项目规模迅速超出了贡献者作为人类的能力。接下来是一段不可思议的自动化和创新之旅。我们不仅仅需要在不坠毁的情况下在飞行中重建飞机，我们还需要将其改造成火箭并发射入轨。我们需要机器来完成工作。

工作

最初，我们专注于需要支持像 Kubernetes 这样复杂的分布式系统所必需的大量测试。必须通过端到端 (e2e) 测试来模拟现实世界的失败场景，以确保功能正常。不幸的是，e2e 测试容易出现 flaky（随机失败），并且需要花费从一个小时到一天的时间才能完成。

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

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

当我们开发自动化以改善我们的状况时，我们遵循了一些指导原则

• 遵循对 Kubernetes 行之有效的推/拉控制循环模式
• 优先选择无状态、松耦合且能把一件事做好服务
• 优先赋能整个社区，而非赋能少数核心贡献者
• 使用我们自己的产品，避免重复造轮子

Prow 登场

这促使我们创建了 Prow 作为自动化中心组件。Prow 有点像 GitHub 事件的 If This, Then That，内置了 命令、插件 和实用工具库。我们将 Prow 构建在 Kubernetes 之上，从而无需担心资源管理和调度，并确保更愉快的运维体验。

Prow 让我们能够做一些事情，例如

• 允许社区通过评论命令（例如 “/priority critical-urgent”、“/assign mary” 或 “/close”）来分派问题/PR
• 根据更改的代码量或触及的文件自动为 PR 打标签
• 对长时间不活跃的问题/PR 进行老化处理
• 自动合并符合 PR 工作流程要求的 PR
• 运行定义为 Knative Builds、Kubernetes Pod 或 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 缓存，确保我们的 token 使用不会达到 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 个特别兴趣小组 (SIG) 和 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 贡献者体验

• ←上一篇
• 下一篇→