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 中的 Reconciler Manager。
    • 名为 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 Deployment、Pod 和容器

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

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

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

    关键组件

    以下部分更详细地探讨了重要的 Config Sync 组件。

    ConfigManagement Operator 和对象

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

    运算符执行

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

    Reconciler Manager 和协调器

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

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

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

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

    显示 Reconciler Manager 如何控制根协调器的图表 显示 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 容器。

    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 客户端修改非托管字段。如需查看有关如何导出 root-sync YAML、在本地修改和重新应用它的示例，请参阅创建和修改 RootSync 配置文件。

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

    其他 RootSync 和 RepoSync 对象

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

    后续步骤