機器可以完成工作，一個關於 Kubernetes 測試、CI 和自動化貢獻者體驗的故事

“大型專案有很多不那麼令人興奮但卻很辛苦的工作。我們更看重自動化重複工作所花費的時間，而不是勞累。如果工作無法自動化，我們的文化是承認並獎勵所有型別的貢獻。然而，英雄主義是不可持續的。” - Kubernetes 社群價值觀

與許多開源專案一樣，Kubernetes 託管在 GitHub 上。我們認為，如果專案存在於開發人員已經工作的地方，使用開發人員已經熟悉的工具和流程，那麼參與的門檻將是最低的。因此，專案完全採用了這項服務：它是我們工作流程、問題跟蹤器、文件、部落格平臺、團隊結構等的基礎。

這個策略奏效了。它奏效得如此之好，以至於專案很快就超越了貢獻者作為人類的能力。接下來是一段不可思議的自動化和創新之旅。我們不僅需要在不墜毀的情況下在飛行中重建飛機，我們還需要將其改造成火箭飛船並送入軌道。我們需要機器來完成這項工作。

工作內容

最初，我們專注於需要支援像 Kubernetes 這樣複雜的分散式系統所要求的巨大測試量。必須透過端到端 (e2e) 測試來執行實際故障場景，以確保功能正常。不幸的是，e2e 測試容易出現偶然失敗 (flakes)，並且需要一小時到一天才能完成。

進一步的經驗揭示了機器可以為我們完成工作的其他領域

• 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 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 貢獻者體驗

• ←上一篇
• 下一篇→