GitOps 原則的存在是為了解決在使用 Kubernetes 這樣復雜系統時可見性和協作方面的實際問題。這些原則強調聲明式期望狀態和持續調和的重要性。然而，它們在具體實施上留有很大的解釋空間。我們經常收到關于如何構建 Git 倉庫、使用什么配置管理工具以及如何使用分支等問題。

你使用的配置管理工具不會對實施 GitOps 的能力產生重大影響。Helm 和 Kustomize 都滿足了標準化清單集合的需求，并且能夠根據特定部署環境修改這些清單。這種抽象對于保持清單的 DRY^[1](不重復原則)非常方便。

然而，這些抽象也帶來了新的問題。GitOps 工具通常直接引用它們來確定期望狀態。對 Helm Chart 或 Kustomization 基礎的更改就是對抽象的更改；這種更改對部署到環境中的清單的真實影響并不明確。

Argo CD 在運行時渲染清單的示意圖

核心前提

Kubernetes 集群的期望狀態不是一個 Helm Chart 或 Kustomization；而是由這些配置管理工具渲染出的清單。遺憾的是，大多數組織在實踐 GitOps 時通常會將其抽象出來存儲在 Git 中。在 git 和 kubectl 之間的任何抽象都可能產生意外效果；你不應該在應用之前修改你的真實來源。

存儲在 Git 中并經過審批的期望狀態不應該包含任何與將要應用到集群的內容不同的抽象。它應該像容器鏡像一樣被對待，是不可變的并按原樣應用到集群中。讓 GitOps 工具在將清單應用到集群時運行 Helm 或 Kustomize，就像讓你的容器在啟動時運行 apt-get install 一樣。

解決方案就是渲染清單模式。對 GitOps 倉庫主干(即 main 分支)的每次更改都會觸發 CI 工作流來渲染清單，并將渲染后的清單按原樣存儲在 Git 中。這個制品代表了集群的期望狀態，沒有任何混淆。

渲染后的清單應該被分離到特定環境的分支中。當這些分支發生更改時，提交之間的清單差異將完全透明。你可以清楚地看到 main 分支上的更改對每個環境的影響。

Argo CD 應用在 CI 中渲染的清單的示意圖

渲染清單模式的優勢一目了然:

• 消除配置管理工具(如 Helm、Kustomize)引入的混淆，提高期望狀態的可見性。
• 通過真正不可變的期望狀態降低內置工具帶來的風險。
• 通過一次性渲染清單提高 Argo CD 的性能。
• 基于環境設置部署和保護策略。

值得注意的是，這種模式有兩個缺點:

• 將清單渲染轉移到 CI 引擎增加了復雜性。
• 它與渲染明文密鑰的工具(如 Sealed Secrets)配合不好。

你可能仍然持懷疑態度，讓我們詳細分析一下。

這不就是 Gitflow 嗎?

讓我們先解決這個問題。表面上看，渲染清單模式可能聽起來像 Gitflow^[2]，但實際上并不是。你可以繼續在 GitOps 倉庫中使用短期特性分支或主干開發模式。

特定環境的分支并不用于環境之間的 promotion[3] - 一個環境分支中的更改不會被合并到另一個分支中。相反，這些分支的內容由自動化工作流維護，并基于 main 分支的內容生成。

可以將這些分支的內容視為一個發布包，其中包含了環境期望狀態的純(渲染后的)清單。就像貢獻者永遠不應該拉取容器鏡像、修改內容并推回注冊表一樣，任何人都不應該直接提交到特定環境的分支。它們是基于 main 分支內容生成的制品。

消除混淆以提高可見性

看看下面這個在 GitOps 倉庫中維護的 Helm Umbrella chart^[4] 更改的例子:


看這個差異，很難直觀地知道結果會是什么。你只知道 Helm chart 依賴的版本在改變。它沒有提供渲染并應用到集群的清單變更的上下文。

再看一個使用 Kustomize 的例子:

顯示 Kustomization 基礎更改的截圖

要了解會發生什么變化，你需要檢查使用這個 Kustomize 基礎的每個環境。

如果你想確定最終的清單(實際部署到集群中的資源)，你需要運行 helm template 或 kustomize build。在 Argo CD 中，repo server 執行這個功能。每當 Application 的源發生變化或緩存過期時，它就會運行 helm template、kustomize build 或使用 CMP 的任何自定義工具來生成清單。然后這些清單被傳遞給 application controller 執行 kubectl apply。

清單的更改應該被持續集成并產生不可變的制品，就像代碼一樣。將清單生成移到 CI 工作流中并存儲在特定環境的分支上，將提供一個不可變的期望狀態，其中的更改清晰可見。

使用上面的 Helm chart 例子，這就是使用渲染清單模式時差異的樣子。chart 版本的一行更改導致生成的清單中有近 1，000 行的變化。

通過不可變期望狀態降低工具風險

GitOps 工具的升級可能會導致內置工具鏈[5](即 Kustomize、Helm)的升級，這可能會影響它管理的每個環境。記住 - git 和 kubectl 之間的任何抽象都可能產生意外效果。

當升級 Argo CD 的差異看起來是這樣的...

...你怎么能確定這對這個 Argo CD 實例中每個 Application 渲染的清單有什么影響?(在這個例子中，從 5.42.0 升級到 5.43.0 的 argo-cd Helm chart 將 Argo CD 升級到 v2.8.0，其中包括將 helm 版本升級到 3.12.0。)

持續集成的核心前提是快速反饋，在問題進入生產系統之前發現它們。這個原則同樣適用于描述 Kubernetes 集群期望狀態的清單。當 GitOps 工具負責生成清單時，問題直到更改被批準、合并到 main 并嘗試應用到集群后才會被發現。在這個時候，修復它需要重復整個過程。

通過將清單生成移到 CI 工作流中并將清單存儲在特定環境的分支中，你可以為集群的期望狀態獲得保證的穩定性。原始 YAML 被捕獲在一個不可變的版本(提交)中。Argo CD 不再轉換 Git 中的內容；它直接將其應用到集群中而不做修改。

提升 Argo CD 的性能

在 Argo CD 中運行 Kustomize 和 Helm 是很消耗資源的。每次 Application 的目標版本發生變化、緩存過期或有人執行強制刷新時，repo server 都需要重新生成清單。

當你查看大型 Argo CD 部署中 repo server 的資源請求時，很容易看出清單生成有多消耗資源。我見過 repo server 被分配 32 個 CPU 和 200GiB 內存的情況!

這在單體倉庫中尤其明顯，其中一個文件夾中清單的更改可能會不必要地導致 Argo CD 為許多 Application 重新生成清單。

通過利用 CI 引擎生成原始清單并將其存儲在特定環境的分支上，這個過程只需要使用按需計算資源執行一次(而不是持續為 repo server 預留資源)。

自動化開發環境并保護生產環境

到目前為止，這種模式的優勢主要可以歸因于"你應該在 CI 中渲染清單"這一部分。第二部分"并將它們存儲在特定環境的分支中"現在發揮作用了。

將渲染后的清單分離到分支中，可以為每個環境設置不同的策略。

再次考慮顯示 Kustomize 基礎更改的差異。

如果不使用渲染清單模式并使用自動同步策略，這個更改將同時應用到每個環境。

使用渲染清單模式，在主分支上更改 kustomize 基礎將導致在 CI 中渲染清單。對于非生產環境，清單可能會被自動部署，所以它們會直接推送到特定環境的分支。

大多數組織對生產環境做同樣的事情感到不舒服(很少有組織成熟到可以實踐持續部署)。相反，為生產環境渲染的清單可以推送到一個短期分支。然后，創建一個 PR，提議對包含現有期望狀態的特定環境分支進行更改。

因為清單已經渲染完成，PR 中顯示的差異將代表沒有混淆或抽象的更改。那些審查和批準 PR 的人可以輕松理解更改的真實影響。

大多數源代碼管理(SCM)提供商都有廣泛的分支權限控制^[6]。使用這些控制，你可以確保對生產環境期望狀態的任何更改都遵循了正確的流程。例如，代碼所有者已經給出批準審查，所有需要的檢查都已成功運行，并且永遠不會直接推送到生產分支。

你可能會想，"好吧，我可以在 Argo CD 中對生產環境的 Application 使用手動同步來獲得類似的解決方案。"雖然這是對的，但缺點是當你的 Application 處于未同步狀態時，期望狀態是模糊的。Argo CD 顯示了差異，但在執行同步時生成的清單可能會有所不同。

缺點

增加了 CI 復雜性

不可否認，這種模式增加了額外的 CI 自動化要求。不應低估使用 Argo CD 進行清單生成的簡單性。Argo CD 在集成 Helm 和 Kustomize 并提供可靠的清單生成方面做了大量工作。

對于 Argo CD，已經有幾次嘗試將 Application 渲染清單的差異添加到 pull request 中。我創建了一個名為 argocd-diff-action 的 GitHub Action 來解決這個問題(它目前已經停止維護，因為我選擇使用渲染清單模式為我的 Kubernetes 集群的期望狀態生成不可變的制品，并提供清晰和信息豐富的差異)。Zapier 最近開源了他們的內部工具 `kubechecks`^[7]，它執行類似的功能，并添加了策略檢查等功能。

在 Akuity，我們創建了一個內部使用的工具來采用渲染清單模式。雖然該項目仍在積極開發中，但目標是將其開源，這樣 Argo CD 用戶就可以使用他們現有的清單渲染定義(即 Application 清單)，并使用該工具在 CI 中而不是在 Argo CD 中渲染它們。

渲染明文密鑰

像 Kustomize + SOPS 這樣的 Kubernetes Secrets 管理工具與渲染清單模式不兼容。它們允許用戶在 Git 中存儲加密的密鑰，并依賴在集群中運行的工具來渲染清單和解密密鑰。

這對于渲染清單模式來說并不理想，因為解密后的密鑰會以明文形式出現在特定環境的分支中。

在采用這種模式之前，建議使用像 External Secrets Operator^[8] 這樣的工具，它使用 ExternalSecret^[9] 資源，這些資源包含對 SecretStore 中數據的引用，可以安全地存儲在 Git 中。然后它使用集群內控制器基于 ExternalSecrets 生成 Kubernetes Secret。在我們的博客文章 如何使用 GitOps 管理 Kubernetes 密鑰?^[10] 中，我們解釋了為什么這是我們首選的方法，無論你是否使用渲染清單模式。

結論

雖然 GitOps 原則強調聲明式期望狀態和持續調和，但在構建 Git 倉庫、選擇配置管理工具和管理分支方面留下了很大的解釋空間。渲染清單模式通過確保存儲在 Git 中的期望狀態保持清晰和不可變，并且在應用到集群時不進行轉換或抽象，解決了這些問題。

這種模式通過提高可見性、消除混淆和降低工具風險，實現了更好的安全性和更安全的變更管理。它通過將清單生成過程轉移到 CI 工作流中，提高了性能，特別是在大型 Argo CD 部署中。再加上為每個環境設置不同策略的能力，為你的 GitOps 工作流增加了靈活性和控制，同時保護生產環境。

大多數源代碼管理(SCM)提供商都有廣泛的分支權限控制^[11]。使用這些控制，你可以確保對生產環境期望狀態的任何更改都遵循了正確的流程。例如，代碼所有者已經給出批準審查，所有需要的檢查都已成功運行，并且永遠不會直接推送到生產分支。

你可能會想，"好吧，我可以在 Argo CD 中對生產環境的 Application 使用手動同步來獲得類似的解決方案。"雖然這是對的，但缺點是當你的 Application 處于未同步狀態時，期望狀態是模糊的。Argo CD 顯示了差異，但在執行同步時生成的清單可能會有所不同。

缺點

增加了 CI 復雜性

不可否認，這種模式增加了額外的 CI 自動化要求。不應低估使用 Argo CD 進行清單生成的簡單性。Argo CD 在集成 Helm 和 Kustomize 并提供可靠的清單生成方面做了大量工作。

對于 Argo CD，已經有幾次嘗試將 Application 渲染清單的差異添加到 pull request 中。我創建了一個名為 argocd-diff-action 的 GitHub Action 來解決這個問題(它目前已經停止維護，因為我選擇使用渲染清單模式為我的 Kubernetes 集群的期望狀態生成不可變的制品，并提供清晰和信息豐富的差異)。Zapier 最近開源了他們的內部工具 `kubechecks`[12]，它執行類似的功能，并添加了策略檢查等功能。

在 Akuity，我們創建了一個內部使用的工具來采用渲染清單模式。雖然該項目仍在積極開發中，但目標是將其開源，這樣 Argo CD 用戶就可以使用他們現有的清單渲染定義(即 Application 清單)，并使用該工具在 CI 中而不是在 Argo CD 中渲染它們。

渲染明文密鑰

像 Kustomize + SOPS 這樣的 Kubernetes Secrets 管理工具與渲染清單模式不兼容。它們允許用戶在 Git 中存儲加密的密鑰，并依賴在集群中運行的工具來渲染清單和解密密鑰。

這對于渲染清單模式來說并不理想，因為解密后的密鑰會以明文形式出現在特定環境的分支中。

在采用這種模式之前，建議使用像 External Secrets Operator^[13] 這樣的工具，它使用 ExternalSecret^[14] 資源，這些資源包含對 SecretStore 中數據的引用，可以安全地存儲在 Git 中。然后它使用集群內控制器基于 ExternalSecrets 生成 Kubernetes Secret。在我們的博客文章 如何使用 GitOps 管理 Kubernetes 密鑰?^[15] 中，我們解釋了為什么這是我們首選的方法，無論你是否使用渲染清單模式。

結論

雖然 GitOps 原則強調聲明式期望狀態和持續調和，但在構建 Git 倉庫、選擇配置管理工具和管理分支方面留下了很大的解釋空間。渲染清單模式通過確保存儲在 Git 中的期望狀態保持清晰和不可變，并且在應用到集群時不進行轉換或抽象，解決了這些問題。

這種模式通過提高可見性、消除混淆和降低工具風險，實現了更好的安全性和更安全的變更管理。它通過將清單生成過程轉移到 CI 工作流中，提高了性能，特別是在大型 Argo CD 部署中。再加上為每個環境設置不同策略的能力，為你的 GitOps 工作流增加了靈活性和控制，同時保護生產環境。

本文使用 Cursor 轉譯，原文地址：https://akuity.io/blog/the-rendered-manifests-pattern

參考資料

[1]DRY: https://en.wikipedia.org/wiki/Don%27t_repeat_yourself。

[2]Gitflow: https://nvie.com/posts/a-successful-git-branching-model/。

[3]環境之間的 promotion: https://developers.redhat.com/articles/2022/07/20/git-workflows-best-practices-gitops-deployments。

[4]Helm Umbrella chart: https://www.youtube.com/watch?v=MlAWr8bVr0I&t=170s。

[5]內置工具鏈: https://github.com/argoproj/argo-cd/blob/e37ff6f0ae02db0739bc480e987c19bd4573e082/hack/tool-versions.sh。

[6]分支權限控制: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule。

[7]kubechecks: https://github.com/zapier/kubechecks。

[8]External Secrets Operator: https://external-secrets.io/latest/。

[9]ExternalSecret: https://external-secrets.io/latest/api/externalsecret/。

[10]如何使用 GitOps 管理 Kubernetes 密鑰?: https://akuity.io/blog/how-to-manage-kubernetes-secrets-gitops/。

[11]分支權限控制: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule。

[12]kubechecks: https://github.com/zapier/kubechecks。

[13]External Secrets Operator: https://external-secrets.io/latest/。

[14]ExternalSecret: https://external-secrets.io/latest/api/externalsecret/。

[15]如何使用 GitOps 管理 Kubernetes 密鑰?: https://akuity.io/blog/how-to-manage-kubernetes-secrets-gitops/。