Config Sync 架構

本頁面將介紹 Config Sync 的架構，包括在 Google Cloud 中執行的代管元件，以及在 Google Kubernetes Engine 叢集上執行的開放原始碼元件。瞭解架構可加深對 Config Sync 的認識，並協助您偵錯及修正遇到的問題。

下一節將說明 Config Sync 的架構，包括在 GKE 叢集內和叢集上的元件和依附元件： Google Cloud

機群服務會直接管理叢集上的 Config Sync 元件，不需要舊版 ConfigManagement 運算子或 ConfigManagement 物件。您必須視需要手動升級 Config Sync。

安裝 Config Sync 的步驟有很多，每個步驟都會在叢集上部署其他元件：

1. 在叢集上啟用 Config Sync 會新增下列元件：

   • ConfigSync 自訂資源定義 (CRD)
   • 名為 config-sync 的 ConfigSync 物件。
   • 名為 reconciler-manager 的部署中的 Reconciler Manager。
   • 名為 resource-group-controller-manager 的部署中的 ResourceGroup 控制器。
   • 部署作業 (名為 otel-collector) 中的 OpenTelemetry Collector。
   • 選用：名為「admission-webhook」的 Deployment 中的 Config Sync 許可 Webhook。只有在啟用漂移防護時，系統才會安裝 Config Sync 准入 Webhook。

   安裝 Config Sync 時，系統會自動建立這些資源和物件，請勿直接修改。

2. 建立 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 名稱規則運算式	容器數量	容器名稱
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 - 5^1	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 - 5^1	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 物件，並根據商品目錄中每個物件目前的對帳狀態更新這些物件。系統會為每個 RootSync 和 RepoSync 物件建立 ResourceGroup 物件，以清查調解器從單一事實來源套用的物件清單。	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

¹ 如要瞭解這些容器的建立時間，請參閱「協調器容器」。

部署資源要求

下表列出 Config Sync 元件的 Kubernetes 資源需求。詳情請參閱 Kubernetes 說明文件的「Pod 和容器的資源管理」一節。

所有支援的 Config Sync 版本都使用相同的資源要求。

部署作業名稱	每個副本的 CPU 要求 (毫核心)	每個副本的記憶體要求 (Mi)
config-management-operator	100	200
resource-group-controller-manager	110	300
admission-webhook^1	10	100
otel-collector	200	400
reconciler-manager	20	150
reconciler (每個 RootSync 和 RepoSync 各一個)	詳情請參閱協調器資源要求。

¹ 許可 Webhook 有兩個副本。如果您使用准入 Webhook，且需要計算資源要求總數，請將值加倍。預設會停用准入 Webhook。

重要元件

下列各節會詳細說明重要的 Config Sync 元件。

車隊服務和 ConfigSync 物件

在 Config Sync 1.20.0 以上版本中，Hub Fleet 服務會直接管理叢集中的 Config Sync 元件：

機群服務也會管理叢集中的 ConfigSync 物件。Fleet 服務會根據您在 Google Cloud API 中的輸入內容，更新 ConfigSync 物件的規格，並更新其狀態，以反映 Config Sync 元件的狀態。

如要變更 Config Sync 安裝設定，請使用 Google Cloud API。不過，您可以使用 Google CloudAPI 或 Kubernetes API 監控 Config Sync 安裝作業的設定和健康狀態。

對帳管理員和對帳員

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 容器。

協調器資源要求

針對每個 RootSync 和 RepoSync 物件，Config Sync 會建立獨立的協調器 Deployment 來處理同步作業。調解器部署作業包含多個容器。如要進一步瞭解這些容器，請參閱「協調器容器」。

所有支援的 Config Sync 版本都使用相同的資源要求。

下表列出標準叢集的資源要求：

容器名稱	CPU 請求 (m)	記憶體要求 (Mi)
reconciler	50	200
otel-agent	10	100
hydration-controller (選用)	10	100
git-sync	10	16
gcenode-askpass-sidecar (選用)	10	20
helm-sync	75	128
oci-sync	25	32

下表列出 Autopilot 叢集的資源要求：

容器名稱	CPU 要求和限制 (m)	記憶體要求和限制 (Mi)
reconciler	700	512
otel-agent	10	64
hydration-controller (選用)	200	256
git-sync	20	32
gcenode-askpass-sidecar (選用)	50	64
helm-sync	250	384
oci-sync	50	64

如要進一步瞭解如何覆寫預設資源要求和限制，請參閱「覆寫資源要求和限制」。

隨附的 Helm 和 Kustomize 版本

Config Sync 會利用 Helm 和 Kustomize 可執行檔轉譯設定。下表列出支援顯示功能的 Config Sync 版本，以及隨附的 Helm 和 Kustomize 版本。

Config Sync 版本	Helm 版本	Kustomize 版本
1.22.0	v3.15.3	v5.3.0
1.21.0	v3.15.3	v5.3.0
1.20.0	v3.15.3	v5.3.0

如要瞭解如何透過 Kustomize 轉譯 Helm，請參閱「透過 Kustomize 設定 Kubernetes」。如要瞭解如何使用 Helm API，請參閱「從 Artifact Registry 同步處理 Helm chart」。

ResourceGroup 控制器和 ResourceGroup 物件

根和命名空間協調器會為您設定的每個 RootSync 和 RepoSync 物件建立 ResourceGroup 目錄物件。每個 ResourceGroup 物件都包含一份物件清單，這些物件是由該 RootSync 或 RepoSync 物件的協調器，從真理來源同步至叢集。接著，ResourceGroupController 會監控 ResourceGroup 物件中的所有物件，並使用已同步物件的目前協調狀態，更新 ResourceGroup 物件的狀態。這樣一來，您就能檢查 ResourceGroup 物件的狀態，概略瞭解同步狀態，不必自行查詢每個物件的狀態。

ResourceGroup 物件的名稱和命名空間與對應的 RootSync 或 RepoSync 物件相同。舉例來說，如果命名空間 config-management-system 中的 RootSync 物件名稱為 root-sync，則對應的 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 物件，透過 GitOps 管理其他 RootSync 或 RepoSync 物件，方法是將這些物件的 YAML 資訊清單新增至 root-sync 設定為同步處理的單一事實來源。這個方法無法用於管理初始 root-sync 的設定，因為部分欄位是由 Fleet 服務管理。如要使用 GitOps 管理 root-sync 物件，請使用 Config Connector 或 Terraform。如要進一步瞭解如何建立其他 RootSync 和 RepoSync 物件，請參閱「設定從多個單一事實來源進行同步」。

後續步驟

• 您可能需要監控 Config Sync 元件或查看記錄。如需簡介，請參閱「使用監控和記錄」。
• 瞭解 Config Sync 元件的資源要求。