使用 Kubernetes 在 Wercker 駕駛自動化平台

在 Wercker，我們運行數百萬個容器來執行使用者的 CI/CD 工作。其中絕大多數是暫時性的，僅持續與建置、測試和部署所需的時間一樣長，其餘的也是暫時性的——我們不都是嗎？——但往往持續時間更長一些，並運行我們的基礎架構。由於我們在許多節點上運行許多容器，因此我們需要一個高度可擴展的排程器，以使我們的生活更輕鬆，因此，我們決定實施 Kubernetes。

Wercker 是一個以容器為中心的自動化平台，可幫助開發人員建置、測試和部署他們的應用程式。我們支援任意數量的管道，範圍從建置程式碼、測試微服務之間的 API 契約，到將容器推送到登錄檔，以及部署到排程器。所有這些管道工作都在 Docker 容器內運行，並且每個成品都可以是一個 Docker 容器。

當然，我們也使用 Wercker 來建置 Wercker，並將其自身部署到 Kubernetes 上！

概觀

因為我們是一個用於運行多服務雲原生程式碼的平台，所以我們圍繞隔離做了許多設計決策。在基礎層級，我們使用 CoreOS 和 cloud-init 來引導異質節點叢集，我將其命名為貴族 (Patricians)、平民 (Peasants)，以及沒有酷名稱且僅稱為控制器 (Controllers) 的控制器節點。也許我們應該改用警察 (Constables)。

貴族節點是我們大部分基礎架構運行的位置。這些節點具有適當的網路介面，可以與我們的後端服務通信，並且可以由各種負載平衡器路由。這是我們的日誌被彙總並發送到日誌服務、用於報告和處理工作運行結果的許多微服務，以及用於處理 API 呼叫的許多微服務所在的位置。

在光譜的另一端是平民節點，公共工作在那裡運行。公共工作包括從工作佇列讀取的工作程序 Pod，以及動態生成新的 runner Pod 以處理工作的執行。工作本身是我們的開源 CLI 工具 的化身，與您可以在安裝了 Docker 的筆記型電腦上運行的工具相同。這些節點對基礎架構的其餘部分具有非常有限的訪問權限，並且工作本身運行的容器甚至進一步隔離。

控制器就是控制器，我敢肯定我們的控制器和你們的完全一樣。

動態 Pod

我們對 Kubernetes API 最繁重的使用絕對是我們的動態 Pod 系統，它用作我們實際工作執行的運行時環境。在從佇列中提取工作描述後，我們定義一個新的 Pod，其中包含所有相關環境，用於檢出程式碼、管理快取、執行工作和上傳成品。我們啟動 Pod，監控其進度，並在工作完成後銷毀它。

Ingress

為了為 HTTP API 呼叫提供後端，並允許處理程序的自我註冊，我們使用了 Kubernetes 中的 Ingress 系統。設定它並不是最清楚的事情，但是閱讀足夠多的 nginx 範例 最終使我們達到了一個良好的狀態，可以輕鬆地將服務連接到前端。

1.3 中的即將推出的功能

雖然我們通常將我們所有的 Pod 和容器都視為暫時性的，並期望在故障時快速重新啟動，但我們期待 Pet Sets 和 Init Containers 作為優化我們某些流程的方法。我們也對 Minikube 的官方支援感到高興，因為它改善了我們的本地測試和開發。

結論

Kubernetes 為我們節省了在許多節點上管理許多容器的繁瑣任務。它為檢視這些容器提供了強大的 API 和工具，並且它包含對日誌記錄、指標、監控和偵錯的許多內建支援。僅服務發現和網路就為我們節省了大量時間，並極大地加快了開發速度。

向您致敬 Kubernetes，繼續保持良好的工作 :)

• ←上一篇
下一篇→