本頁面會介紹 Config Sync 的架構,包括在 Google Cloud 中執行的代管元件,以及在 Google Kubernetes Engine (GKE) Enterprise 版叢集上執行的開放原始碼元件。瞭解架構可加深對 Config Sync 的認識,並協助您偵錯及修正遇到的問題。
Config Sync 的架構會隨著時間演進:
- Config Sync 1.5.1 版新增了多存放區模式。這個模式採用更具擴充性的多租戶架構,每個 RootSync 和 RepoSync 物件都有一個調解器,可獨立管理權限、獨立擴充,以及提供多個獨立的故障網域。
- Config Sync 1.18.0 版新增了自動升級功能。啟用自動升級後,系統會從叢集移除 ConfigManagement Operator 和
ConfigManagement
物件。而是由 Fleet (GKE Hub) 服務直接管理叢集上的開放原始碼元件。即使停用自動升級功能,系統仍會使用 ConfigManagement Operator。 - 在 Config Sync 1.19.0 版中,我們移除了選用的單一存放區模式。這個模式的架構較簡單,元件較少,但難以擴充,且不支援多重租戶。因此,我們以全新的多存放區模式取代了單一存放區模式。詳情請參閱遷移至多存放區模式。
- 在 Config Sync 1.20.0 版中,即使停用自動升級功能,ConfigManagement Operator 和
ConfigManagement
物件也會完全移除。而是由 Fleet (GKE Hub) 服務直接管理叢集上的開放原始碼元件。
以下章節說明 Config Sync 的架構,包括在 Google Cloud 和 Google Kubernetes Engine (GKE) Enterprise 版叢集中的元件和依附元件,適用於各種版本的 Config Sync:
1.20.0 以上版本
在 Config Sync 1.20.0 以上版本中,Fleet 服務會直接管理叢集上的 Config Sync 元件,不需要舊版 ConfigManagement Operator 或 ConfigManagement
物件。您可以設定 Fleet 服務自動升級 Config Sync,也可以視需要手動升級 Config Sync。
安裝 Config Sync 的步驟有很多,每個步驟都會在叢集上部署其他元件:
在叢集上啟用 Config Sync 會新增下列元件:
ConfigSync
自訂資源定義 (CRD)- 名為
config-sync
的ConfigSync
物件。 - 名為
reconciler-manager
的 Deployment 中的 Reconciler Manager。 - 名為
resource-group-controller-manager
的部署中的 ResourceGroup 控制器。 - 部署作業 (名為
otel-collector
) 中的 OpenTelemetry Collector。 - 選用:名為
admission-webhook
的 Deployment 中的 Config Sync 許可 Webhook。只有在啟用漂移防護時,系統才會安裝 Config Sync 准入 Webhook。
安裝 Config Sync 時,系統會自動建立這些資源和物件,請勿直接修改。
建立
RootSync
和RepoSync
物件會新增下列元件:- 針對每個
RootSync
物件,系統會建立名為root-reconciler-ROOTSYNC_NAME
的協調器 Deployment。對於名為root-sync
的物件,協調器 Deployment 名為root-reconciler
。RootSync
- 針對每個
RepoSync
物件,系統會建立名為ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH
的協調器 Deployment。對於名為repo-sync
的RepoSync
物件,協調器 Deployment 名稱為ns-reconciler
。
- 針對每個
1.19.x 以下版本
在 Config Sync 1.19.x 版和更早版本中,使用手動升級時,Fleet 服務會管理 ConfigManagement Operator,而後者會管理叢集上的 Config Sync 元件。
安裝 Config Sync 的步驟有很多,每個步驟都會在叢集上部署其他元件:
在叢集上啟用 Config Sync 會新增下列元件:
- 名為「
config-management-operator
」的 Deployment 中的 ConfigManagement Operator。 ConfigManagement
自訂資源定義 (CRD)。- 名為
config-management
的ConfigManagement
物件。 - 名為
reconciler-manager
的 Deployment 中的 Reconciler Manager。 - 名為
resource-group-controller-manager
的部署中的 ResourceGroup 控制器。 - 部署作業 (名為
otel-collector
) 中的 OpenTelemetry Collector。 - 選用:名為
admission-webhook
的 Deployment 中的 Config Sync 許可 Webhook。只有在啟用漂移防護時,系統才會安裝 Config Sync 准入 Webhook。
安裝 Config Sync 時,系統會自動建立大部分的資源和物件,請勿直接修改。不過,
ConfigManagement
物件的部分欄位可直接修改。詳情請參閱「ConfigManagement 欄位」。- 名為「
建立
RootSync
和RepoSync
物件會新增下列元件:- 針對每個
RootSync
物件,系統會建立名為root-reconciler-ROOTSYNC_NAME
的協調器 Deployment。對於名為root-sync
的物件,協調器 Deployment 名為root-reconciler
。RootSync
- 針對每個
RepoSync
物件,系統會建立名為ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH
的協調器 Deployment。對於名為repo-sync
的RepoSync
物件,協調器 Deployment 名稱為ns-reconciler
。
- 針對每個
Config Sync 部署作業、Pod 和容器
下表提供有關 Config Sync 部署作業、Pod 和容器的詳細資訊:
部署作業名稱 | 部署命名空間 | 部署項目說明 | 備用資源數量 | Pod 名稱規則運算式 | 容器數量 | 容器名稱 |
---|---|---|---|---|---|---|
config-management-operator |
config-management-system |
使用手動升級時,ConfigManagement Operator 會在安裝 Config Sync 1.19.x 版和更早版本的叢集上執行。這個物件會監控 ConfigManagement 物件,並管理其他 Config Sync 元件,例如 Reconciler Manager 和 OpenTelemetry Collector。在 Config Sync 1.20.0 以上版本中,ConfigManagement 運算子已由 Fleet (GKE Hub) 服務的擴充功能取代。 |
1 | config-management-operator-.* |
1 | manager |
reconciler-manager |
config-management-system |
如果 ConfigManagement 物件已啟用 Config Sync,Reconciler Manager 就會在每個叢集上執行。它會監控 RootSync 和 RepoSync 物件,並為每個物件管理協調器 Deployment。 |
1 | reconciler-manager-.* |
2 | reconciler-manager otel-agent |
root-reconciler |
config-management-system |
系統會為每個 RootSync 物件建立根協調器 Deployment。 |
1 | root-reconciler-.* |
3 - 51 |
reconciler otel-agent git-sync helm-sync oci-sync gcenode-askpass-sidecar hydration-controller |
ns-reconciler |
config-management-system |
系統會為每個 RepoSync 物件建立命名空間調解器 Deployment。 |
1 | ns-reconciler-.* |
3 - 51 |
reconciler otel-agent git-sync helm-sync oci-sync gcenode-askpass-sidecar hydration-controller |
otel-collector |
config-management-monitoring |
OpenTelemetry Collector 會在每個叢集上執行,並在 ConfigManagement 物件中啟用 Config Sync。
這個外掛程式會從 config-management-system 和 resource-group-system 命名空間下執行的 Config Sync 元件收集指標,並將這些指標匯出至 Prometheus 和 Cloud Monitoring。 |
1 | otel-collector-.* |
1 | otel-collector |
resource-group-controller-manager |
resource-group-system |
ResourceGroup 控制器會在每個叢集上執行,且叢集已在 ConfigManagement 物件中啟用 Config Sync。這項服務會監控 ResourceGroup 物件,並根據商品目錄中每個物件目前的對帳狀態更新這些物件。系統會為每個 ResourceGroup 和 RepoSync 物件建立 ResourceGroup 物件,以清查調和工具從單一事實來源套用的物件清單。RootSync |
1 | resource-group-controller-manager-.* |
2 | manager otel-agent |
admission-webhook |
config-management-system |
Config Sync Admission Webhook 會在每個叢集上執行,並在 ConfigManagement 物件中啟用防止偏移功能。這項服務會監控 Kubernetes API 要求,並防止修改或刪除 Config Sync 管理的資源。Config Sync 許可控制器 Webhook 預設為停用。 |
2 | admission-webhook-.* |
1 | admission-webhook |
1 如要進一步瞭解這些容器的建立時間,請參閱「協調器容器」。
重要元件
下列各節會詳細說明重要的 Config Sync 元件。
車隊服務和 ConfigSync
物件
在 Config Sync 1.20.0 以上版本中,GKE Fleet 服務會直接管理叢集中的 Config Sync 元件:
機群服務也會管理叢集中的 ConfigSync
物件。Fleet 服務會根據您在 Google Cloud API 中的輸入內容,更新 ConfigSync
物件的規格,並更新其狀態,以反映 Config Sync 元件的狀態。
如要變更 Config Sync 安裝設定,請使用 Google Cloud API。不過,您可以使用 Google CloudAPI 或 Kubernetes API 監控 Config Sync 安裝作業的設定和健康狀態。
ConfigManagement Operator 和 ConfigManagement
物件
在 Config Sync 1.19.x 版和更早版本中,使用手動升級時,GKE Fleet 服務會管理 ConfigManagement Operator,而後者會管理叢集中的 Config Sync 元件:
如要變更 Config Sync 安裝設定,主要使用 Google Cloud API。不過,您也可以使用 Kubernetes API,對 ConfigManagement
物件進行部分變更。詳情請參閱「ConfigManagement 欄位」。
ConfigManagement Operator 會監控 ConfigManagement
物件的規格變更,管理叢集上的 Config Sync 元件以反映規格,並更新 ConfigManagement
物件的狀態,以反映 Config Sync 元件的狀態。
由於 ConfigManagement Operator 會安裝需要 cluster-admin
權限的元件,因此 ConfigManagement Operator 也需要 cluster-admin
權限。
對帳管理員和對帳員
Reconciler Manager 負責建立及管理個別的調解器,確保叢集設定保持同步。
Reconciler Manager 會為每個 RootSync
物件建立根層級的協調器,並為每個 RepoSync
物件建立命名空間協調器。Config Sync 使用這種設計,而不是共用單一的單體協調器,因為這樣可減少單一故障點,進而提升可靠性,並允許個別協調器獨立擴充。
根命名空間和命名空間調解器會自動從真實來源擷取設定,並套用這些設定,在叢集中強制執行所需狀態。
下圖顯示 Reconciler Manager 如何控管每個根調解器和命名空間調解器的生命週期:
Reconciler 容器
部署在協調器 Pod 中的特定容器取決於您所做的設定選擇。下表進一步說明每個協調器容器的功能,以及導致 Config Sync 建立這些容器的條件:
容器名稱 | 說明 | 條件 |
---|---|---|
reconciler |
處理同步和偏移修正作業。 | 一律啟用。 |
otel-agent |
接收來自其他協調器容器的指標,並傳送至 OpenTelemetry Collector。 | 一律啟用。 |
git-sync |
從 Git 存放區提取設定至本機目錄,以供協調器容器讀取。 | 當「spec.sourceType 」為「git 」時啟用。 |
helm-sync |
從圖表存放區提取 Helm 圖表,並將其算繪至調解器容器可讀取的本機目錄。 | 當「spec.sourceType 」為「helm 」時啟用。 |
oci-sync |
從容器登錄檔提取含有設定的 OCI 映像檔,並放到調解器容器可讀取的本機目錄。 | 當「spec.sourceType 」為「oci 」時啟用。 |
gcenode-askpass-sidecar |
從 GKE 中繼資料服務快取 Git 憑證,供 git-sync 容器使用。 |
當 spec.sourceType 為 git 且 spec.git.auth 為 gcenode 或 gcpserviceaccount 時,此屬性會啟用。 |
hydration-controller |
負責將 Kustomize 設定建構至協調器容器可讀取的本機目錄。 | 如果來源包含 kustomize.yaml 檔案,就會啟用這項功能。 |
如上表所示,每個協調器 Pod 通常會有三到五個容器。reconciler
和 otel-agent
容器一律存在。指定真實來源的類型會決定要新增哪個同步容器。此外,如果您進行表格中提及的設定變更,系統會建立 hydration-controller
和 gcenode-askpass-sidecar
容器。
ResourceGroup 控制器和 ResourceGroup 物件
根和命名空間協調器會為您設定的每個 RootSync
和 RepoSync
物件建立 ResourceGroup
目錄物件。每個 ResourceGroup
物件都包含一份物件清單,這些物件是由該 RootSync
或 RepoSync
物件的協調器,從真理來源同步至叢集。接著,ResourceGroupController 會監控 ResourceGroup
物件中的所有物件,並使用已同步物件的目前協調狀態,更新 ResourceGroup
物件的狀態。這樣一來,您就能查看 ResourceGroup
物件的狀態,瞭解同步狀態的概況,不必自行查詢每個物件的狀態。
ResourceGroup
物件的名稱和命名空間與對應的 RootSync
或 RepoSync
物件相同。舉例來說,如果命名空間 config-management-system
中有名為 root-sync
的 RootSync
物件,則對應的 ResourceGroup
物件在 config-management-system
命名空間中也會命名為 root-sync
。
請勿建立或修改 ResourceGroup
物件,否則可能會干擾 Config Sync 的運作。
Admission Webhook
啟用漂移防護時,系統會建立 Config Sync Admission Webhook。防止漂移:主動攔截修改要求,確保要求與事實來源一致,再允許變更。
如果未啟用偏誤防範功能,Config Sync 仍會使用自我修復機制還原設定偏誤。透過自我修復功能,Config Sync 會持續監控受管理物件,並自動還原與預期狀態不符的任何變更。
RootSync 和 RepoSync 物件
RootSync
物件會設定 Config Sync,建立根協調器,監控指定的單一事實來源,並將該來源的物件套用至叢集。根據預設,每個 RootSync
物件的根協調器都具有 cluster-admin
權限。有了這項預設權限,根協調器就能同步處理叢集範圍和命名空間範圍的資源。如有需要,您可以設定 spec.override.roleRefs
欄位,變更這些權限。RootSync
物件是專為叢集管理員設計。
RepoSync
物件會設定 Config Sync,建立命名空間協調器,監控指定來源,並將該來源的物件套用至叢集中的特定命名空間。命名空間調解器可使用自訂使用者指定的權限,同步處理該命名空間中任何命名空間範圍內的資源。RepoSync
物件專供命名空間租戶使用。
Fleet 服務管理 RootSync 物件的方式
使用 Google Cloud 控制台、Google Cloud CLI、Config Connector 或 Terraform 安裝 Config Sync 時,系統會根據您在 Google Cloud API 中的輸入內容,透過 Fleet 服務管理 Config Sync。
如果 Config Sync 安裝作業是由 Fleet 服務管理,您也可以選擇讓該服務管理初始 RootSync
物件 (名為 root-sync
)。這樣一來,您就能在叢集上啟動 GitOps,而不必直接手動將任何內容套用至叢集。如果您決定不讓 Fleet 服務管理初始 RootSync
物件,仍可直接將所需的 RootSync
和 RepoSync
物件套用至叢集。
系統會根據您在Google Cloud API 中的輸入內容 (特別是 config-management apply APIspec.configSync
部分),建立名為 root-sync
的 RootSync
物件。由於這個 API 只會公開RootSync
欄位的子集,因此這些欄位在 root-sync
中視為受管理,其他欄位則視為不受管理。您只能使用Google Cloud API 編輯受管理欄位。未受管理欄位可使用 kubectl
編輯,或使用任何其他 Kubernetes 用戶端編輯。
其他 RootSync 和 RepoSync 物件
如要建立其他 RootSync
或 RepoSync
物件,可以使用 kubectl
指令列工具或其他 Kubernetes 用戶端。您也可以使用初始 root-sync
物件,將 YAML 資訊清單新增至 root-sync
設定為從中同步處理的單一事實來源,藉此透過 GitOps 管理其他 RootSync
或 RepoSync
物件。這個方法無法用於管理初始 root-sync
的設定,因為部分欄位是由 Fleet 服務管理。如要使用 GitOps 管理 root-sync
物件,請使用 Config Connector 或 Terraform。如要進一步瞭解如何建立其他 RootSync
和 RepoSync
物件,請參閱「設定從多個單一事實來源進行同步」。