在 Wercker 使用 Kubernetes 引導自動化平臺

在Wercker，我們執行著數百萬個容器，這些容器執行著我們使用者的CI/CD任務。絕大多數容器是短暫的，只持續到構建、測試和部署執行完成，其餘的也是短暫的——我們不都是這樣嗎——但往往持續時間稍長，執行我們的基礎設施。由於我們在許多節點上執行著許多容器，我們需要一個高度可伸縮的排程器，以簡化我們的工作，因此決定實施Kubernetes。

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

當然，我們使用Wercker來構建Wercker，並將其部署到Kubernetes上！

概述

因為我們是一個執行多服務雲原生程式碼的平臺，所以我們圍繞隔離做了許多設計決策。在底層，我們使用CoreOS和cloud-init來引導一個由異構節點組成的叢集，我將這些節點命名為“貴族”（Patricians）、“農民”（Peasants），以及沒有酷炫名稱只被稱為“控制器”（Controllers）的控制器節點。也許我們應該改名為“治安官”（Constables）。

貴族節點是我們大部分基礎設施執行的地方。這些節點具有適當的網路介面，可以與我們的後端服務通訊，並可透過各種負載均衡器路由。這裡彙集日誌併發送到日誌服務，這裡執行著我們許多用於報告和處理任務執行結果的微服務，以及我們許多用於處理API呼叫的微服務。

另一方面是農民節點，執行公共任務。公共任務由從任務佇列讀取的工作者Pod組成，並動態生成新的runner Pod來處理任務執行。任務本身是我們開源CLI工具的一個例項，與您在安裝了Docker的筆記型電腦上執行的工具相同。這些節點對基礎設施其餘部分的訪問許可權非常有限，而任務本身執行的容器則進一步隔離。

控制器就是控制器，我相信我們的控制器看起來和您的控制器一模一樣。

動態 Pod

我們對 Kubernetes API 最重度的使用無疑是建立動態 Pods 作為實際任務執行的執行時環境。從佇列中拉取任務描述後，我們定義一個新 Pod，其中包含用於程式碼檢出、快取管理、任務執行和上傳工件的所有相關環境。我們啟動 Pod，監控其進度，並在任務完成後將其銷燬。

Ingresses

為了為 HTTP API 呼叫提供後端並允許處理程式的自注冊，我們利用了 Kubernetes 中的 Ingress 系統。設定起來並不算最清晰明瞭，但閱讀了足夠多的 nginx 示例 後，我們最終達到了一個很好的狀態，可以輕鬆地將服務連線到前端。

1.3 版本即將推出的功能

雖然我們通常將所有 Pod 和容器視為短暫的，並期望在故障時快速重啟，但我們期待 Pet Sets 和 Init Containers 能夠最佳化我們的一些流程。我們也很高興看到 Minikube 的官方支援，因為它改進了我們的本地測試和開發。

結論

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

為 Kubernetes 乾杯，繼續保持良好的工作！:)

• ←上一篇
• 下一篇→