本頁面提供入門資訊，協助您規劃及設計 Kubernetes 的 CI/CD GitOps 管道。GitOps 和 Config Sync 等工具可提升程式碼穩定性、可讀性及自動化程度。
GitOps 是管理 Kubernetes 設定的熱門方法，視 CI/CD pipeline 的需求而定，您可選擇多種方式來架構及整理應用程式和設定程式碼。瞭解一些 GitOps 最佳做法，即可建立穩定、井然有序且安全的架構。
本頁內容適用於想在環境中導入 GitOps 的管理員、架構師和營運人員。如要進一步瞭解我們在 Google Cloud 內容中提及的常見角色和範例工作，請參閱「常見的 GKE Enterprise 使用者角色和工作」。
整理存放區
設定 GitOps 架構時，請根據每個存放區中儲存的設定檔類型，將存放區分開。從高層次來看，您可能會考慮至少四種存放區：
- 相關設定群組的套件存放區。
- 平台存放區，用於叢集和命名空間的機群層級設定。
- 應用程式設定存放區。
- 應用程式程式碼存放區。
下圖顯示這些存放區的版面配置：
圖 2：
- 開發團隊將應用程式和應用程式設定的程式碼推送至存放區。
- 應用程式和設定的程式碼都儲存在相同位置，且應用程式團隊可控管這些存放區。
- 應用程式團隊將程式碼推送至建構作業。
使用集中式私人套件存放區
使用公用或內部套件的中央存放區 (例如 Helm 圖表)，協助團隊尋找套件。舉例來說，如果存放區的結構符合邏輯，或包含 readme，使用集中式私人套件存放區可協助團隊快速找到資訊。您可以使用 Artifact Registry 或 Git 存放區等服務來整理中央存放區。
舉例來說，貴機構的平台團隊可以實作政策，規定應用程式團隊只能使用中央存放區中的套件。
您可以將存放區的寫入權限限制在少數工程師身上，機構中的其他使用者則可擁有讀取權限。建議您實作將套件升級至中央存放區，以及播送更新的程序。
雖然管理中央存放區可能會增加一些額外負擔，因為必須有人維護中央存放區，且應用程式團隊會增加額外程序，但這種做法有許多優點：
- 中央團隊可以選擇以定義的頻率新增公開套件，避免因連線或上游流失而中斷。
- 自動化系統和人工審查員會共同檢查套件是否有問題，確認沒問題後才會廣泛發布。
- 中央存放區可讓團隊瞭解目前使用和支援的內容。舉例來說，團隊可以找到儲存在中央存放區的標準 Redis 部署作業。
- 您可以自動變更上游套件，確保這些套件符合內部標準，例如預設值、新增標籤和容器映像檔存放區。
建立 WET 存放區
WET 代表「Write Everything Twice」(所有內容都寫兩次)。這與 DRY 相反，DRY 代表「不要重複」。這些方法代表兩種不同的設定檔：
- DRY 設定：單一設定檔會經過轉換動作，為不同環境填入不同值。舉例來說，您可以設定共用叢集設定，並為不同環境填入不同區域或安全性設定。
- WET (或有時稱為「完全水合」) 設定，其中每個設定檔都代表結束狀態。
雖然 WET 存放區可能會導致部分設定檔重複，但對於 GitOps 工作流程而言，仍有下列優點：
- 團隊成員可以更輕鬆地查看變更。
- 查看設定檔的預期狀態時，不需要進行任何處理。
驗證設定時提早測試
等待 Config Sync 開始同步處理，再檢查問題，可能會造成不必要的 Git 提交，以及漫長的意見回饋循環。使用 kpt 驗證器函式，即可在設定套用至叢集前找出許多問題。
雖然您必須在提交程序中新增其他工具和邏輯，但在套用設定前進行測試有下列好處：
- 在變更要求中顯示設定變更，有助於避免錯誤進入存放區。
- 減少共用設定中的問題所造成的影響。
使用資料夾而非分支
請使用資料夾存放設定檔變體，而非分支。使用資料夾時，你可以使用 tree 指令查看變體。使用分支時，您無法判斷生產和開發分支之間的差異，是即將發生的設定變更，還是 prod 和 dev 環境之間應有的永久差異。
這個方法的主要缺點是，使用資料夾時，您無法透過變更要求，將設定變更項目升級至相同檔案。不過，使用資料夾而非分支有以下好處：
- 資料夾比分支機構更容易探索。
- 許多 CLI 和 GUI 工具都能比較資料夾，但除了 Git 供應商外，比較分支的工具較少見。
- 使用資料夾可輕鬆區分永久差異和未升級的差異。
- 您可以在一個變更要求中，將變更部署至多個叢集和命名空間，但分支需要對不同分支提出多個變更要求。
盡量減少使用 ClusterSelectors
ClusterSelectors 可讓您將設定的特定部分套用至叢集子集。您可以修改要套用的資源，或為叢集新增標籤，而不必設定 RootSync 或 RepoSync 物件。雖然這是將特徵新增至叢集的輕量級方式，但隨著 ClusterSelectors 數量隨時間增加，瞭解叢集的最終狀態可能會變得複雜。
由於 Config Sync 可讓您一次同步多個 RootSync 和 RepoSync 物件，因此您可以將相關設定新增至個別存放區，然後同步至所需叢集。這樣一來，您就能更輕鬆地瞭解叢集的最終狀態，並將叢集的設定組合成資料夾，而不是直接在叢集上套用這些設定決策。
避免使用 Config Sync 管理 Job
在大多數情況下，Job 和其他情境工作應由處理生命週期管理的服務管理。然後，您就可以使用 Config Sync 管理該服務，而不是管理 Job 本身。
雖然 Config Sync 可以為您套用 Job，但 Job 不適合用於 GitOps 部署作業，原因如下：
不可變更的欄位：許多職缺欄位都無法變更。如要變更不可變更的欄位，必須刪除並重新建立物件。不過，除非您從來源中移除物件，否則 Config Sync 不會刪除物件。
工作意外執行：如果您使用 Config Sync 同步處理工作，然後從叢集中刪除該工作，Config Sync 會將此視為與所選狀態的差異，並重新建立工作。如果您指定工作存留時間 (TTL)，Config Sync 會自動刪除工作，並自動重新建立及重新啟動工作，直到您從真理來源刪除工作為止。
對帳問題：Config Sync 通常會在套用物件後，等待物件完成對帳。不過，工作開始執行後，系統就會視為已完成調解。這表示 Config Sync 不會等待 Job 完成，就會繼續套用其他物件。不過，如果 Job 後來失敗，則視為無法調解。在某些情況下，這可能會導致其他資源無法同步處理，並在修正問題前發生錯誤。在其他情況下，同步作業可能會成功，但對帳作業會失敗。
基於上述原因，我們不建議使用 Config Sync 同步處理 Job。
使用非結構化存放區
Config Sync 支援兩種存放區結構：非結構化和階層式。
建議採用非結構化方法，因為這樣您就能以最方便的方式整理存放區。相較之下，階層式存放區會強制執行特定結構，例如 cluster 目錄中的自訂資源定義 (CRD)。這可能會導致您無法分享設定。舉例來說，如果某個團隊發布的套件包含 CRD，需要使用該套件的團隊就必須將 CRD 移至 cluster 目錄，進而增加流程的負擔。
使用非結構化存放區後，就能更輕鬆地共用及重複使用設定套件。不過，如果沒有定義存放區的整理程序或指南，各團隊的存放區結構可能會有所不同，這會導致難以實作全車隊工具。
如要瞭解如何轉換階層式存放區，請參閱「將階層式存放區轉換為非結構化存放區」。
將程式碼和設定存放區分開
擴大單一存放區時，需要為每個資料夾建立專屬版本。一般來說，處理程式碼和叢集設定的人員權限和考量點不同。
將程式碼和設定檔存放區分開有下列好處：
- 避免「迴圈」提交。舉例來說，提交至程式碼存放區可能會觸發 CI 要求，進而產生映像檔，然後需要提交程式碼。
- 如果需要提交的次數過多，可能會造成團隊成員的負擔。
- 您可以為處理應用程式程式碼和叢集設定的人員設定不同權限。
將程式碼和設定存放區分開有以下缺點：
- 減少應用程式設定的探索作業，因為應用程式設定與應用程式程式碼不在同一個存放區。
- 管理大量存放區可能相當耗時。
使用個別存放區來隔離變更
擴充單一存放區時，不同資料夾需要不同權限。因此，將存放區分開可讓安全性、平台和應用程式設定之間有安全界線。此外，建議您將正式版和非正式版存放區分開。
雖然管理大量存放區本身就是一項龐大的工作，但在不同存放區中隔離不同類型的設定，可帶來下列好處：
- 在擁有平台、安全性和應用程式團隊的機構中，變更和權限的頻率有所不同。
- 權限仍維持在存放區層級。
CODEOWNERS檔案，讓機構限制寫入權限，同時允許讀取權限。 - Config Sync 支援每個命名空間的多個同步作業，可達到與從多個存放區取得檔案類似的效果。
釘選套件版本
無論使用 Helm 或 Git，您都應將設定套件版本固定在某個版本，以免在沒有明確推出作業的情況下，意外向前移動。
雖然這會在共用設定更新時，為推出作業新增額外檢查，但可降低共用更新造成超出預期影響的風險。
使用 Workload Identity Federation for GKE
您可以在 GKE 叢集上啟用 Workload Identity Federation for GKE，讓 Kubernetes 工作負載以安全可控的方式存取 Google 服務。
雖然部分非Google Cloud 服務 (例如 GitHub 和 GitLab) 不支援 GKE 的 Workload Identity Federation，但由於可提高安全性，並簡化機密和密碼的管理作業，因此建議您盡可能使用 GKE 的 Workload Identity Federation。