Config Sync 架构

本页面介绍了 Config Sync 的架构，包括在 Google Cloud 中运行的托管组件以及在 Google Kubernetes Engine 集群上运行的开源组件。了解架构有助于您更深入地了解 Config Sync，并且可以帮助您调试和解决遇到的问题。

以下部分展示了 Config Sync 的架构，包括其组件和依赖项（无论是在 Google Cloud 中还是在 GKE 集群上）：

舰队服务直接管理集群上的 Config Sync 组件，而不使用旧版 ConfigManagement Operator 或 ConfigManagement 对象。您必须根据需要手动升级 Config Sync。

安装 Config Sync 需要执行多个步骤，其中每个步骤都会在集群上部署其他组件：

1. 在集群上启用 Config Sync 会添加以下组件：

   • ConfigSync 自定义资源定义 (CRD)
   • 名为 config-sync 的 ConfigSync 对象。
   • 名为 reconciler-manager 的 Deployment 中的 Reconciler Manager。
   • 名为 resource-group-controller-manager 的 Deployment 中的 ResourceGroup 控制器。
   • 名为 otel-collector 的 Deployment 中的 OpenTelemetry 收集器。
   • 可选：Deployment 中的 Config Sync 准入 webhook，名为 admission-webhook。仅当您启用偏移防范时，系统才会安装 Config Sync 准入 webhook。

   这些资源和对象会在您安装 Config Sync 时自动创建，不应直接修改。

2. 创建 RootSync 和 RepoSync 对象会添加以下组件：

   • 对于每个 RootSync，会添加名为 root-reconciler-ROOTSYNC_NAME 的协调器 Deployment。对于名为 root-sync 的 RootSync 对象，会添加名为 root-reconciler 的协调器 Deployment。
   • 对于每个 RepoSync，会添加名为 ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH 的协调器 Deployment。对于名为 repo-sync 的 RepoSync 对象，会添加名为 ns-reconciler 的协调器 Deployment。

Config Sync Deployment、Pod 和容器

下表提供了有关 Config Sync Deployment、Pod 和容器的详细信息：

部署名称	Deployment 命名空间	部署说明	副本数	Pod 名称正则表达式	容器数量	容器名称
reconciler-manager	config-management-system	Reconciler Manager 会在 ConfigManagement 对象中启用了 Config Sync 的每个集群上运行。它会监控 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 收集器会在 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 准入 Webhook 会在 ConfigManagement 对象中启用了偏移防范功能的每个集群上运行。它会监控 Kubernetes API 请求并防止修改或删除由 Config Sync 管理的资源。Config Sync 准入 webhook 默认处于停用状态。	2	admission-webhook-.*	1	admission-webhook

¹ 如需详细了解何时创建这些容器，请参阅协调器容器。

部署资源请求

下表列出了 Config Sync 组件的 Kubernetes 资源要求。如需了解详情，请参阅 Kubernetes 文档中的针对 Pod 和容器的资源管理。

对于所有受支持的 Config Sync 版本，资源请求都是相同的。

部署名称	每个副本的 CPU 请求 (m)	每个副本的内存请求 (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 舰队服务直接管理集群上的 Config Sync 组件：

舰队服务还管理集群上的 ConfigSync 对象。舰队服务会根据您对 Google Cloud API 的输入更新 ConfigSync 对象的规范，并更新其状态以反映 Config Sync 组件的状态。

如需更改 Config Sync 安装配置，您必须使用 Google Cloud API。不过，您可以使用 Google CloudAPI 或 Kubernetes API 来监控 Config Sync 安装的配置和健康状况。

Reconciler Manager 和协调器

Reconciler Manager 负责创建和管理用于确保集群配置保持同步的各个协调器。

Reconciler Manager 会为每个 RootSync 对象创建一个根协调器，并为每个 RepoSync 对象创建一个命名空间协调器。Config Sync 采用这种设计，而不是共享单个单体协调器的原因在于，可通过减少单点故障来提高可靠性，并允许各个协调器独立扩缩。

根协调器和命名空间协调器会自动从可靠来源提取配置，并应用这些配置以在集群中强制执行所需的状态。

以下图表显示了 Reconciler Manager 如何负责控制每个根协调器和命名空间协调器的生命周期：

协调器容器

协调器 Pod 中部署的特定容器取决于您所做的配置选择。下表详细说明了各个协调器容器的用途以及导致 Config Sync 创建这些容器的条件：

容器名称	说明	条件
reconciler	处理同步和偏移修复。	始终启用。
otel-agent	从其他协调器容器接收指标并将它们发送到 OpenTelemetry 收集器。	始终启用。
git-sync	将配置从 Git 代码库拉取到协调器容器可以读取的本地目录。	在 spec.sourceType 为 git 时启用。
helm-sync	将 Helm 图表从图表代码库拉取到协调器容器可以读取的本地目录并进行呈现。	在 spec.sourceType 为 helm 时启用。
oci-sync	将包含配置的 OCI 映像从 Container Registry 拉取到协调器容器可以读取的本地目录。	在 spec.sourceType 为 oci 时启用。
gcenode-askpass-sidecar	从 GKE 元数据服务缓存 Git 凭据，以供 git-sync 容器使用。	在 spec.sourceType 为 git 且 spec.git.auth 为 gcenode 或 gcpserviceaccount 时启用。
hydration-controller	负责将 Kustomize 配置构建到协调器容器可以读取的本地目录。	在来源包含 kustomize.yaml 文件时启用。

如上表所示，每个协调器 Pod 中通常可以有 3 到 5 个容器。reconciler 和 otel-agent 容器始终存在。为可靠来源指定类型可决定所添加的同步容器。此外，如果您进行了表中提到的配置更改，则系统会创建 hydration-controller 和 gcenode-askpass-sidecar 容器。

协调器资源请求

对于每个 RootSync 和 RepoSync 对象，Config Sync 会创建一个独立的协调器部署来处理同步。协调器部署包含多个容器。如需详细了解这些容器，请参阅协调器容器。

对于所有受支持的 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 图表。

ResourceGroup 控制器和 ResourceGroup 对象

根协调器和命名空间协调器会为您设置的每个 RootSync 和 RepoSync 对象创建一个 ResourceGroup 清单对象。每个 ResourceGroup 对象都包含一个由相应协调器为该 RootSync 或 RepoSync 对象从可靠来源同步到集群的对象列表。ResourceGroup 控制器随后会监控 ResourceGroup 对象中的所有对象，并使用已同步对象的当前协调状态更新 ResourceGroup 对象的状态。这样，您便可以检查 ResourceGroup 对象的状态以了解同步状态的大致情况，而无需自行查询每个对象的状态。

ResourceGroup 对象与其对应的 RootSync 或 RepoSync 对象具有相同的名称和命名空间。例如，对于命名空间 config-management-system 中名为 root-sync 的 RootSync 对象，对应的 ResourceGroup 对象也在 config-management-system 命名空间中并且名称为 root-sync。

请勿创建或修改 ResourceGroup 对象，因为这可能会干扰 Config Sync 的运行。

准入 Webhook

当您启用偏移防范功能时，系统会创建 Config Sync 准入 Webhook。偏移防范功能会主动拦截修改请求，从而确保这些请求与可靠来源一致，然后才允许进行更改。

如果您未启用偏移防范功能，Config Sync 仍会使用自我修复机制来还原配置偏移。通过自我修复，Config Sync 会持续监控托管对象，并自动撤销偏离预期状态的任何更改。

RootSync 和 RepoSync 对象

RootSync 对象会配置 Config Sync 以创建根协调器，该协调器可监控指定的可靠来源，并将来自该来源的对象应用于集群。默认情况下，每个 RootSync 对象的根协调器都具有 cluster-admin 权限。借助此默认权限，根协调器可以同步集群级资源和命名空间级资源。如果需要，您可以通过配置 spec.override.roleRefs 字段来更改这些权限。RootSync 对象旨在供集群管理员使用。

RepoSync 对象会配置 Config Sync 以创建命名空间协调器，该协调器可监控指定来源，并将来自该来源的对象应用于集群中的特定命名空间。命名空间协调器可以通过用户指定的自定义权限，同步该命名空间中的任何命名空间级资源。RepoSync 对象旨在供命名空间租户使用。

舰队服务如何管理 RootSync 对象

使用 Google Cloud 控制台、Google Cloud CLI、Config Connector 或 Terraform 安装 Config Sync 时，Config Sync 由舰队服务根据您对 Google Cloud API 的输入进行管理。

如果您的 Config Sync 安装由舰队服务进行管理，您还可以选择让它管理名为 root-sync 的初始 RootSync 对象。这样，您就可以在集群上引导 GitOps，而无需直接手动将任何内容应用于集群。如果您决定不让舰队服务管理初始 RootSync 对象，仍然可以将所需的任何 RootSync 和 RepoSync 对象直接应用于集群。

系统会根据您对Google Cloud API 的输入（特别是 config-management apply API 的 spec.configSync 部分），创建名为 root-sync 的 RootSync 对象。由于此 API 仅公开一部分 RootSync 字段，因此这些字段被视为在 root-sync 中托管，而其他字段被视为非托管。托管字段只能使用Google Cloud API 进行修改。您可以使用 kubectl 或任何其他 Kubernetes 客户端修改非托管字段。

其他 RootSync 和 RepoSync 对象

如需创建其他 RootSync 或 RepoSync 对象，您可以使用 kubectl 命令行工具或其他 Kubernetes 客户端。您还可以将 YAML 清单添加到配置为 root-sync 的同步源的可靠来源，使用初始 root-sync 通过 GitOps 管理其他 RootSync 和 RepoSync 对象。此方法不能用于管理初始 root-sync 的配置，因为它的某些字段由舰队服务管理。如需使用 GitOps 管理 root-sync 对象，请使用 Config Connector 或 Terraform。如需详细了解如何创建其他 RootSync 和 RepoSync 对象，请参阅配置从多个可靠来源同步。

后续步骤

• 您可能需要监控 Config Sync 组件或检查其日志。如需了解说明，请参阅使用监控和日志。
• 了解 Config Sync 组件的资源请求。