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

使用 kit 部署到多個 Kubernetes 叢集

作者：Chesley Brown (InVision) |

我們在 InVision 的 Docker 之旅聽起來可能很熟悉。我們從開發環境中的 Docker 開始，首先嘗試在那裡獲得一致性。我們將舊有的單體應用程式整合到 Docker 映像中，並簡化了 Dockerfiles 以盡量縮小尺寸並提高效率。情況看起來不錯。我們一路上學到了很多嗎？當然。但在這一切結束時，我們的整個工程團隊都在本地使用 Docker 來進行開發環境。任務完成！嗯，不完全是。開發是一回事，但轉移到生產環境又是另一回事。

Kubernetes 的出現

Kubernetes 在去年 12 月我們評估協調器和排程器時進入了我們的生活。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 將非同步地將所有清單發送到它們對應的叢集。

那麼下一步是什麼？

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

我們希望您仔細看看 kit 並告訴我們您的想法！查看我們的 InVision Engineering 部落格，了解更多關於我們在 InVision 正在進行的酷事的文章。如果您想從事 kit 或其他類似的有趣事情，請點擊進入我們的職位頁面。我們很樂意收到您的來信！