Config Sync 架构

本页面介绍了 Config Sync 的架构。了解 Config Sync 创建的组件可以让您更深入地了解 Config Sync，并且可能有助于您调试和修复您遇到的问题。

下图显示了 Google Kubernetes Engine (GKE) Enterprise 版本集群上的 Config Sync 及其相关资源的架构：

显示 Config Sync 对象和资源之间的关系的图表

在此图中，用户创建了可信来源并使用 Feature Manager 安装 Config Sync。

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

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

    • 名为 config-management-operator 的 Deployment 中的 ConfigManagement Operator。
    • ConfigManagement 自定义资源定义 (CRD) 和名为 config-management 的对象。
    • 名为 reconciler-manager 的 Deployment 中的协调器管理器。
    • 名为 resource-group-controller-manager 的 Deployment 中的 ResourceGroup 控制器。
    • 名为 otel-collector 的 Deployment 中的 OpenTelemetry 收集器。
    • 可选：名为 admission-webhook 的 Deployment 中的 Config Sync 准入 Webhook。

    大多数这些资源和对象都是在安装 Config Sync 时自动创建的，您无需修改它们。

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

    • 对于每个 RootSync，一个名为 root-reconciler-ROOTSYNC_NAME 的协调器 Deployment。
    • 对于每个 RepoSync，一个名为 ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH 的协调器 Deployment。

Config Sync 部署、Pod 和容器

下表提供了有关 Config Sync 部署、Pod 和容器的更多信息：

部署名称 部署命名空间 部署说明 副本数 Pod 名称正则表达式 容器数量 容器名称
config-management-operator config-management-system ConfigManagement Operator 会在安装了 Config Sync 的每个集群上运行。它会监视 ConfigManagement 对象并管理 Config Sync 组件，例如协调器管理器和 OpenTelemetry 收集器。 1 config-management-operator-.* 1
  • manager
    		•
    reconciler-manager config-management-system 协调器管理器会在 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 - 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 收集器会在 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
  • reconciler-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 组件。

    ConfigManagement 运算符和对象

    ConfigManagement Operator 监控 ConfigManagement 对象，以及创建和管理 Config Sync 正常工作所需的其他组件：

    运算符执行

    由于 ConfigManagement Operator 安装了一些需要 cluster-admin 权限的组件，因此 ConfigManagement Operator 也需要 cluster-admin 权限。

    协调器管理器和调节器

    协调器管理器负责创建和管理各个协调器，以确保集群配置保持同步。

    协调器管理器会为每个 RootSync 对象创建一个根协调器，并为每个 RepoSync 对象创建一个命名空间协调器。Config Sync 采用这种设计而不是共用单个调节器，因为它可以通过减少单点故障来提高可靠性，并且允许单独扩缩各个调节器。

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

    下图展示了协调器管理器如何控制每个根协调器和命名空间协调器的生命周期：

    显示协调器管理器如何控制根协调器的示意图 显示协调器管理器如何控制命名空间协调器的图表

    协调器容器

    协调器 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 中的容器数量应该为三到五个。reconciler 和 otel-agent 容器始终存在。为可信来源指定类型决定了要添加哪个同步容器。此外，如果您进行了表中提到的配置更改，系统会创建 hydration-controller 和 gcenode-askpass-sidecar 容器。

    ResourceGroup Controller 和 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 安装由舰队服务管理，您还可以选择让该服务管理您的初始 RootSync 对象（名为 root-sync）。这样，您就可以在集群上引导 GitOps，而无需直接手动对集群应用任何内容。如果您决定不让舰队服务管理您的初始 RootSync 对象，您仍然可以将所需的任何 RootSync 和 RepoSync 对象直接应用于集群。

    名为 root-sync 的 RootSync 对象是根据您对 Google Cloud API 的输入（具体来说是 config-management apply API 的 spec.configSync 部分）创建的。由于此 API 仅公开部分 RootSync 字段，因此这些字段在 root-sync 中被视为受管理字段，而其他字段则被视为不受管理。受管字段只能使用 Google Cloud API 进行修改。您可以使用 kubectl 或任何其他 Kubernetes 客户端修改非托管字段。如需查看有关如何导出 root-sync YAML、在本地修改以及重新应用该文件的示例，请参阅创建和修改 RootSync 配置文件。

    对于手动安装，您可以使用 kubectl 命令行工具或任何其他 Kubernetes 客户端管理 Config Sync。

    其他 RootSync 和 RepoSync 对象

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

    后续步骤