機器代勞：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 工作流程要求的 PR
• 運行定義為 Knative Builds、Kubernetes Pod 或 Jenkins jobs 的 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，而不是在佇列中排序的 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 Next 的道路
• 自動化與 Kubernetes 貢獻者體驗

• ←上一篇
下一篇→