本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

使用 kit 部署到多個 Kubernetes 叢集

作者：Chesley Brown (InVision) |

我們在 InVision 的 Docker 之旅可能聽起來很熟悉。我們從開發環境中的 Docker 開始，首先嚐試在那裡實現一致性。我們將遺留的單體應用整理成 Docker 映象，並簡化了 Dockerfile 以最大限度地減小大小並提高效率。一切看起來都不錯。我們在此過程中學到了很多嗎？當然。但最終，我們整個工程團隊都在本地使用 Docker 進行開發。任務完成了！嗯，不完全是。開發是一回事，但轉向生產則是另一回事。

Kubernetes 的出現

去年 12 月，在我們評估編排器和排程器時，Kubernetes 進入了我們的生活。AWS ECS 仍是新事物，Docker 剛剛釋出了 1.9 版本（網路覆蓋釋出）。我們花了一個月的時間評估我們的選擇，將其範圍縮小到原生的 Docker 工具（Machine、Swarm、Compose）、ECS 和 Kubernetes。毋庸置疑，Kubernetes 顯然是我們的贏家，我們從新的一年開始便全力以赴地利用 Kubernetes 來實現生產。但很快我們就遇到了一個小麻煩……

自動部署的陷阱

在 InVision，我們面臨著獨特的挑戰。我們不僅有一個執行 Kubernetes 的生產環境，而是有幾個，都需要透過我們的 CI/CD 流程進行自動化更新。儘管這些環境中執行的程式碼相似，但配置卻不盡相同。事情需要順利、自動地進行，因為我們無法承受在部署過程中增加摩擦或給我們的工程團隊帶來負擔。

擁有幾個近乎重複的叢集很容易演變成 Kubernetes 清單的噩夢。反模式比比皆是，我們複製貼上 95% 的清單來獲取一個新叢集。可伸縮嗎？不。令人頭疼嗎？是的。讓這些清單保持最新和準確將是一項艱鉅（且容易出錯）的任務。我們需要更簡單的方法，一種允許重用、降低維護成本並且可以融入我們 CI/CD 系統的工具。

因此，在尋找能夠滿足我們需求的專案或工具後，我們一無所獲。在 InVision，我們喜歡建立工具來幫助我們解決問題，考慮到我們可能不是唯一處於這種情況的團隊，我們決定捲起袖子，建立了自己的工具。結果就是我們的開源工具 kit！（Kubernetes + git 的縮寫）

你好，kit！

kit 是一套元件，當整合到您的 CI/CD 系統和原始碼控制中時，它允許您持續部署更新（或全新的服務！）到所需的任意數量的叢集，所有這些都利用 webhook，而無需託管外部服務。

使用 kit 的模板格式，您可以一次定義您的服務檔案，並在多個叢集中重用它們。它的工作原理是在您通常的 Kubernetes 清單檔案之上構建，允許它們只定義一次，然後透過只定義該特定叢集所需的唯一配置，在叢集之間重複使用。這使您可以輕鬆地為您的應用程式構建編排，並將其部署到所需的任意數量的叢集中。它還允許對您的應用程式的不同版本進行分組，這樣您就可以擁有執行應用程式“開發”版本的叢集，而其他叢集執行“生產”版本等等。

開發人員只需像往常一樣將程式碼提交到他們的分支，kit 就會部署到所有執行該服務的叢集。然後，Kit 直接管理更新給定服務所使用的映象和標籤到包含所有 kit 清單模板的儲存庫中。這意味著您叢集中的所有更改，無論是環境變數、配置還是映象更新，都將在原始碼控制歷史中進行跟蹤，為您擁有的每個叢集提供審計跟蹤。

我們已將所有這些開源，您可以檢視 kit 儲存庫！

kit 適合我們嗎？

如果您正在多個叢集（或名稱空間）中執行 Kubernetes，並且都需要持續部署，那您就對了！因為使用 kit 不需要託管任何外部伺服器，您的團隊可以利用您可能已經與 GitHub 和 CI/CD 系統整合的 webhook 來開始使用。然後，您建立一個儲存庫來託管您的 Kubernetes 清單檔案，這些檔案說明了哪些服務部署到哪些叢集。由於 kit 的模板引擎，這些檔案的複雜性大大簡化了。kit-image-deployer 元件被整合到 CI/CD 流程中，每當開發人員將程式碼提交到 master 並且構建透過時，它會自動部署到所有配置的叢集。

那麼元件有哪些？

Kit 由幾個相互構建的元件組成。一般的流程是開發人員將程式碼提交到其儲存庫，構建映象，然後 kit-image-deployer 將新映象和標籤提交到您的清單儲存庫。從那裡，kit-deploymentizer 執行，解析您的所有清單模板以生成原始 Kubernetes 清單檔案。最後，kit-deployer 執行，獲取所有已構建的清單檔案並將其部署到所有相應的叢集。以下是元件和流程的摘要

kit-image-deployer
一種服務，可用於使用新的 Docker 映象路徑更新 Git 儲存庫中給定的 YAML 檔案。這可以與 kit-deploymentizer 和 kit-deployer 協同使用，以自動更新跨多個叢集的服務所使用的映象。

kit-deploymentizer
此服務智慧地構建部署檔案，以實現環境變數和其他形式配置的可重用性。它還支援為多個叢集聚合這些部署。最終，它會生成一個叢集列表和每個叢集的部署檔案列表。最好與 kit-deployer 和 kit-image-deployer 協同使用，以實現持續部署工作流。

kit-deployer
使用此服務將檔案部署到多個 Kubernetes 叢集。只需將您的清單檔案組織到與您的叢集名稱（在您的 kubeconfig 檔案中定義的名稱）匹配的目錄中。然後，您提供一個 kubeconfig 檔案目錄，kit-deployer 將非同步地將所有清單傳送到其相應的叢集。

接下來是什麼？

在不久的將來，我們希望使部署更加智慧化，以處理更新 MongoDB 副本集之類的任務。我們還希望新增智慧監控，以進一步改進 Kubernetes 的自我修復特性。我們還在努力新增額外的整合（例如 Slack）和通知方法。最重要的是，我們正在努力將更多控制權轉移給各個服務的開發人員，方法是允許 kit 清單模板存在於每個單獨的服務儲存庫中，而不是單個主清單儲存庫中。這將使他們能夠完全從開發到生產，跨所有叢集管理他們的服務。

我們希望您能仔細檢視kit，並告訴我們您的想法！檢視我們的InVision Engineering部落格，瞭解更多關於我們在 InVision 所做的精彩事情的帖子。如果您想參與 kit 或其他類似有趣的專案，請點選訪問我們的招聘頁面。我們期待您的來信！