筆記。 翻譯。：在 Kubernetes 社群中，一種稱為 GitOps 的趨勢正在明顯流行，正如我們親眼所見， KubeCon Europe 2019。這個名詞相對較新 由 Weaveworks 的負責人 Alexis Richardson 提出，意味著使用開發人員熟悉的工具（主要是 Git，因此得名）來解決操作問題。 特別是，我們討論 Kubernetes 的操作，將其配置儲存在 Git 中並自動將變更推送到叢集。 Matthias Jg 在本文中討論了這種部署的兩種方法。
去年 （事實上，正式這件事發生在 2017 年 XNUMX 月 - 大約翻譯） 有一種在 Kubernetes 中部署應用程式的新方法。 它稱為 GitOps，它基於在 Git 儲存庫的安全環境中追蹤部署版本的基本概念。
這種方法的主要優點如下：:
- 部署版本控制和變更歷史記錄。 整個叢集的狀態儲存在 Git 儲存庫中，並且部署僅透過提交來更新。 此外，可以使用提交歷史記錄來追蹤所有變更。
- 使用熟悉的 Git 指令進行回滾。 簡單的
git reset允許您重置部署中的變更； 過去的狀態總是可用的。 - 準備好存取控制。 通常，Git 系統包含大量敏感數據，因此大多數公司都會特別注意保護它。 因此，這種保護也適用於部署操作。
- 部署策略。 大多數 Git 系統本身就支援逐個分支的策略，例如，只有拉取請求才能更新 master，並且更改必須由其他團隊成員審核和接受。 與存取控制一樣，相同的策略也適用於部署更新。
正如您所看到的，GitOps 方法有許多好處。 在過去的一年裡，有兩種方法特別受歡迎。 一種是基於推式的，另一種是基於拉式的。 在了解它們之前，我們先來看看典型的 Kubernetes 部署是什麼樣的。
部署方式
近年來，Kubernetes 中已經建立了各種部署方法和工具：
- 基於原生 Kubernetes/Kustomize 模板。 這是在 Kubernetes 上部署應用程式最簡單的方法。 開發人員會建立基本 YAML 檔案並套用它們。 為了擺脫不斷重寫相同模板的情況，開發了 Kustomize（它將 Kubernetes 模板轉換為模組）。 筆記。 翻譯。：Kustomize 已整合到 kubectl 中 .
- 舵圖。 Helm 圖表可讓您建立一組範本、初始化容器、sidecar 等，這些範本用於部署應用程序，具有比基於範本的方法更靈活的自訂選項。 此方法基於模板化的 YAML 檔案。 Helm 為它們填充各種參數，然後將它們傳送到 Tiller，Tiller 是一個叢集元件，Tiller 將它們部署到叢集並允許更新和回溯。 重要的是，Helm 本質上只是將所需的值插入到模板中，然後以與傳統方法相同的方式應用它們 （閱讀更多關於它是如何工作的以及如何在我們的 - 大約。 譯）。 有各種各樣的現成 Helm 圖表，涵蓋了廣泛的任務。
- 替代工具。 有許多替代工具。 它們的共同點是，它們將一些模板文件轉換為 Kubernetes 可讀的 YAML 文件，然後使用它們。
在我們的工作中，我們經常使用 Helm 圖表作為重要工具（因為它們已經準備好了很多東西，這讓生活變得更加輕鬆）和「純」Kubernetes YAML 檔案來部署我們自己的應用程式。
拉推
在我最近的一篇部落格文章中，我介紹了該工具 ，它允許您將範本提交到 Git 儲存庫，並在每次提交或推送容器後更新部署。 我的經驗表明，這個工具是推廣拉式方法的主要工具之一，所以我會經常參考它。 如果您想了解更多如何使用它，請點擊這裡 .
NB！ 對於這兩種方法來說，使用 GitOps 的所有好處都是相同的。
基於拉動的方法
拉取方法基於以下事實：所有變更均從叢集內部應用。 叢集內有一名操作員定期檢查關聯的 Git 和 Docker 註冊表儲存庫。 如果它們發生任何變化，叢集的狀態會在內部更新。 此過程通常被認為非常安全，因為外部用戶端無法存取叢集管理員權限。
優點：
- 外部客戶端無權對叢集進行更改；所有更新均從內部推出。
- 有些工具還允許您同步 Helm 圖表更新並將其連結到叢集。
- 可以掃描 Docker 註冊表以取得新版本。 如果有新映像可用，Git 儲存庫和部署將更新到新版本。
- 拉取工具可以分佈在具有不同 Git 儲存庫和權限的不同命名空間中。 因此，可以使用多租戶模型。 例如，團隊 A 可能使用命名空間 A，團隊 B 可能使用命名空間 B，基礎架構團隊可能使用全域空間。
- 一般來說，這些工具非常輕量。
- 與operator等工具結合 ，秘密可以加密儲存在 Git 儲存庫中並在叢集中檢索。
- 由於部署發生在叢集內，因此沒有與 CD 管道的連接。
缺點:
- 從 Helm 圖表管理部署機密比常規部署機密更困難，因為它們首先必須以密封機密的形式生成，然後由內部操作員解密，只有在此之後它們才可供拉取工具使用。 然後，您可以使用已部署的機密中的值在 Helm 中執行發布。 最簡單的方法是使用用於部署的所有 Helm 值來建立一個金鑰，對其進行解密並將其提交到 Git。
- 當您採用拉式方法時，您就會受到拉式工具的束縛。 這限制了在叢集中自訂部署過程的能力。 例如，Kustomize 很複雜，因為它必須在最終模板提交到 Git 之前運行。 我並不是說您不能使用獨立工具，但它們更難以整合到您的部署過程中。
基於推送的方法
在推送方法中，外部系統（主要是 CD 管道）在提交到 Git 儲存庫後或如果先前的 CI 管道成功，則啟動對叢集的部署。 在這種方法中，系統可以存取叢集。
優點:
- 安全性由 Git 儲存庫和建置管道決定。
- 部署 Helm 圖表更容易，並且支援 Helm 插件。
- 秘密更容易管理，因為秘密可以在管道中使用，也可以加密儲存在 Git 中（取決於使用者的偏好）。
- 與特定工具沒有聯繫，因為可以使用任何類型。
- 容器版本更新可以由建置管道啟動。
缺點:
- 叢集存取資料位於建置系統內部。
- 透過拉取過程更新部署容器仍然更容易。
- 嚴重依賴CD系統，因為我們需要的管道最初可能是為Gitlab Runners編寫的，然後團隊決定遷移到Azure DevOps或Jenkins......並且將不得不遷移大量構建管道。
結果：推還是拉？
通常情況下，每種方法都有其優點和缺點。 有些任務用一種方法比較容易完成，用另一種方法則比較困難。 起初我是手動進行部署，但在看到幾篇有關 Weave Flux 的文章後，我決定為所有專案實施 GitOps 流程。 對於基本模板來說，這很容易，但後來我開始在使用 Helm 圖表時遇到困難。 當時，Weave Flux 僅提供了 Helm Chart Operator 的基本版本，但即使現在，由於需要手動建立機密並套用它們，某些任務也變得更加困難。 您可能會說拉取方法更加安全，因為叢集的憑證在叢集外部無法訪問，這使得它更加安全，值得付出額外的努力。
經過一番思考，我得出了意想不到的結論：事實並非如此。 如果我們談論需要最大程度保護的元件，則此清單將包括秘密儲存、CI/CD 系統和 Git 儲存庫。 其中的資訊非常脆弱，需要最大限度的保護。 此外，如果有人進入您的 Git 儲存庫並可以將程式碼推送到那裡，他們就可以部署他們想要的任何內容（無論是拉取還是推送）並滲透叢集的系統。 因此，需要保護的最重要元件是 Git 儲存庫和 CI/CD 系統，而不是叢集憑證。 如果您為這些類型的系統配置了良好的策略和安全控制，並且叢集憑證僅作為機密提取到管道中，則拉取方法所增加的安全性可能沒有最初想像的那麼有價值。
因此，如果拉式方法更加勞動密集並且不能提供安全優勢，那麼僅使用推式方法不是合乎邏輯的嗎？ 但有人可能會說，在推播方法中，您與 CD 系統的連結過於緊密，也許最好不要這樣做，以便將來更容易進行遷移。
在我看來（一如既往），您應該使用最適合特定情況或組合的東西。 就我個人而言，我使用這兩種方法：Weave Flux 用於基於拉取的部署，主要包括我們自己的服務，以及使用Helm 和插件的推送方法，這使得可以輕鬆地將Helm 圖表應用到集群，並允許您無縫創建機密。 我認為永遠不會有一個解決方案適合所有情況，因為總是存在許多細微差別，而且它們取決於特定的應用程式。 話雖這麼說，我強烈推薦 GitOps - 它讓生活變得更加輕鬆並提高安全性。
我希望我在這個主題上的經驗能夠幫助您決定哪種方法更適合您的部署類型，我很高興聽到您的意見。
PS 譯者註
拉取模型的缺點是很難將渲染的清單放入 Git，但是沒有缺點，拉取模型中的 CD 管道與推出分開，本質上成為類別管道 持續申請。 因此，需要付出更多的努力來從所有部署中收集其狀態，並以某種方式提供對日誌/狀態的訪問，最好參考 CD 系統。
從這個意義上說，推送模型允許我們至少為 rollout 提供一些保證，因為可以使 pipeline 的生命週期等於 rollout 的生命週期。
我們嘗試了這兩種模型，並得出了與文章作者相同的結論：
- 拉模型適合我們在大量集群上組織系統組件的更新（參見. ).
- 基於 GitLab CI 的推送模型非常適合使用 Helm 圖表推出應用程式。 同時，使用該工具監控管道內部署的推出 。 順便說一句，在我們這個專案的背景下，當我們在 KubeCon Europe'19 的展位上討論 DevOps 工程師的緊迫問題時，我們聽到了持續不斷的「GitOps」。
來自譯者的PPS
另請閱讀我們的博客：
- «“;
- «“;
- «“;
- «“。
只有註冊用戶才能參與調查。 ， 請。
你在使用 GitOps 嗎？
-
是的，拉式方法
-
是的，推
-
是的，拉+推
-
是的，還有別的東西
-
沒有
30 位用戶投票。 10 名用戶棄權。
來源： www.habr.com