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

作者:Aaron Crickenberger(Google)和Benjamin Elder(Google)

“大型项目没有那么令人兴奋的努力工作。我们重视花费在重复工作自动化上的时间比辛劳。在无法自动完成这项工作的地方,我们的文化是承认和奖励所有类型的贡献。但是,英雄主义是不可持续的。” - Kubernetes社区价值观

像许多开源项目一样,Kubernetes托管在GitHub上。我们认为,如果项目生活在开发人员已经工作过的地方,并且使用开发人员已经知道的工具和流程,那么参与的障碍将是最低的。因此,该项目完全包含了服务:这是我们工作流程,问题跟踪程序,文档,博客平台,团队结构等的基础。

此策略有效。效果如此之好,该项目很快就超出了其贡献者的能力。随后发生了令人难以置信的自动化和创新之旅。我们不仅需要在飞行途中重建飞机而不会坠毁,还需要将其转变为火箭飞船并发射进入轨道。我们需要机器来完成这项工作。

工作

最初,我们专注于以下事实:我们需要支持由复杂的分布式系统(例如Kubernetes)强制进行的大量测试。现实世界中的故障场景必须通过端到端(e2e)测试进行,以确保功能正常。不幸的是,e2e测试容易剥落(随机失败),并且需要一个小时到一天才能完成。

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

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

在开发自动化以改善我们的状况时,我们遵循一些指导原则:

  • 遵循适用于Kubernetes的推送/轮询控制循环模式
  • 首选无状态的松散耦合服务,可以很好地完成一件事
  • 优先于授权整个社区,而不是授权一些核心贡献者
  • 吃我们自己的狗粮,避免重新发明轮子

输入前进

这导致我们创造 船首 作为我们自动化的核心组件。船首有点像 如果这,那么那 用于GitHub活动的内置库 命令, 外挂程式和实用程序。我们在Kubernetes上构建了Prow,以免除对资源管理和调度的担忧,并确保获得更愉快的操作体验。

船首让我们可以执行以下操作:

  • 允许我们的社区通过注释命令(例如“ / prioritycritical-urgent”,“ / assign mary”或“ / close”)对问题/ PR进行分类。
  • 根据更改的代码量或接触的文件自动标记PR
  • 淘汰长时间不活动的问题/ PR
  • 满足我们PR工作流程要求的自动合并PR
  • 运行定义为的CI作业 基建,Kubernetes Pods或Jenkins职位
  • 实施组织范围和每个仓库的GitHub策略,例如 分支机构保护GitHub标签

船首最初由构建Google Kubernetes Engine的工程生产力团队开发,并由Kubernetes SIG Testing的多个成员积极贡献。 船首已被其他几个开源项目采用,包括Istio,JetStack,Knative和OpenShift。 船首入门 takes a Kubernetes cluster 和 kubectl apply starter.yaml (running pods on a Kubernetes cluster).

有了Prow之后,我们就开始遇到其他扩展瓶颈,因此产生了额外的工具来支持Kubernetes要求的规模的测试,包括:

  • 博斯科斯:管理池中的作业资源(例如GCP项目),将其检出并自动清理(带监控)
  • ghProxy:针对GitHub API进行了优化的反向代理HTTP缓存,以确保我们的令牌使用不会达到API限制(带监控)
  • 温室:允许我们使用远程bazel缓存为PR提供更快的构建和测试结果(带监控)
  • 拼接:允许我们批量测试和合并PR,确保我们的合并速度不限于我们的测试速度
  • 浪潮:允许我们合并通过GitHub查询选择的PR,而不是按队列排序,从而使拼接时的合并速度大大提高

扩展项目健康

解决了工作流自动化问题后,我们将注意力转向了项目运行状况。我们选择使用Google Cloud Storage(GCS)作为所有测试数据的真实来源,从而使我们能够依靠已建立的基础架构,并允许社区贡献结果。然后,我们构建了各种工具来帮助个人和整个项目理解这些数据,包括:

  • 古伯纳特:显示给定PR的结果和测试历史记录
  • 水壶:将数据从GCS传输到可公开访问的bigquery数据集
  • 公关仪表板:可识别工作流程的仪表板,使贡献者能够了解需要关注的PR以及原因
  • 分流:确定所有作业和测试中发生的常见故障
  • 测试网格:显示所有运行中给定作业的测试结果,汇总各组作业的测试结果

我们与Cloud Native Computing Foundation(CNCF)接触以开发DevStats,以从GitHub事件中收集见解,例如:

超越

今天,Kubernetes项目跨越五个组织的125个存储库。该项目中有31个特殊利益小组和10个工作小组来协调发展。去年该项目 来自13,800多位独特开发商的参与 在GitHub上。

在任何给定的工作日,我们的Prow实例 运行超过10,000个CI工作;从2017年3月到2018年3月,它创造了430万个工作岗位。这些工作大多数涉及建立整个Kubernetes集群,并使用实际场景进行锻炼。它们使我们能够确保所有受支持的Kubernetes发行版都能在云提供商,容器引擎和网络插件之间运行。他们确保最新版本的Kubernetes具有启用的各种可选功能,安全升级,满足性能要求以及跨体系结构工作。

今天的 CNCF公告 –注意到Google Cloud已开始将Kubernetes项目的云资源的所有权和管理权转让给CNCF社区贡献者,我们很高兴踏上新的旅程。允许项目基础结构由贡献者社区拥有和运营的项目,遵循适用于项目其余部分的相同开放治理模型。听起来令人兴奋吗?来kubernetes.slack.com上的#sig-testing与我们交谈。

想了解更多?快来看看这些资源: