Config Sync 架構

本頁面會介紹 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 物件和資源之間的關係

在 Config Sync 1.20.0 以上版本中，Fleet 服務會直接管理叢集上的 Config Sync 元件，不需要舊版 ConfigManagement Operator 或 ConfigManagement 物件。您可以設定 Fleet 服務自動升級 Config Sync，也可以視需要手動升級 Config Sync。

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

  1. 在叢集上啟用 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 時，系統會自動建立這些資源和物件，請勿直接修改。

  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。

1.19.x 以下版本

圖表：顯示 Config Sync 物件和資源之間的關係

在 Config Sync 1.19.x 版和更早版本中，使用手動升級時，Fleet 服務會管理 ConfigManagement Operator，而後者會管理叢集上的 Config Sync 元件。

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

  1. 在叢集上啟用 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 欄位」。

  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 名稱規則運算式 容器數量 容器名稱
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 元件：

    管理 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

    如要變更 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 Manager 如何控制根協調器 圖表：顯示 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 物件，請參閱「設定從多個單一事實來源進行同步」。

    後續步驟