本頁面提供入門資訊,協助您規劃及設計 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。