关于可信来源

本文档介绍了 Config Sync 可以同步的不同类型的可靠来源。

GitOps 工作流中的一个关键概念是可信来源，即存储配置文件的中央代码库。配置文件通常是定义 Kubernetes 资源的 YAML 或 JSON 文件。通常，您可以使用 kubectl 命令行工具手动应用 Kubernetes 对象，但 Config Sync 可以从 Git 代码库等单一可靠来源自动应用这些资源。然后，Config Sync 会监控您指定的可靠来源，并将所有更改自动应用到集群。

Config Sync 可以从三种不同类型的来源同步配置文件：Git 代码库、开放容器倡议 (OCI) 映像和 Helm 图表。本文档将介绍每种来源类型以及 Config Sync 如何与它们互动。阅读本文档有助于您为自己的工作流程和环境选择最佳来源选项。

Git 代码库

Git 是一种广泛用于版本控制和协作的技术。借助 Git，您可以根据需要组织代码库，并根据需要享受版本控制和分支的优势。由于 Git 是一项成熟且被广泛采用的技术，因此您有多种提供商和工具可供选择。

当您将 Config Sync 配置为使用 Git 代码库作为可靠来源时，Config Sync 会使用协调器 Pod 中的 git-sync 容器从 Git 代码库拉取配置。您可以配置代码库网址、分支和修订版本（提交或标记），以便更好地控制从 Git 代码库中的何处拉取配置。

RootSync 配置示例

以下示例展示了一个从 Git 代码库同步的 RootSync 清单：

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/example/my-configs.git
    revision: main
    dir: cluster-configs
    auth: none # replace with your authentication method such as ssh or token
    period: 60s

此配置可设置 Config Sync 以从 Git 代码库同步清单。Config Sync 会监控 https://github.com/example/my-configs.git 代码库的 main 分支中的 cluster-configs 目录，每 60 秒检查一次更新，且不使用身份验证。

使用场景示例：集中式管理

假设您是一位平台管理员，想要使用 Git 代码库在机群中的所有集群中强制执行基准政策。在这种情况下，您可能会将标准 NetworkPolicies、RoleBindings 和 ResourceQuotas 存储在名为 standard-configs 的中央 Git 代码库中。在预配新集群时，Config Sync 会配置为从 standard-configs 代码库进行同步，从而帮助确保所有集群从一开始就符合组织标准。

OCI 映像

OCI 映像是一种用于封装应用及其依赖项的标准格式。此方法将配置视为工件，类似于您处理容器映像的方式。这种方法具有不可变性和大规模快速性能等优势。借助 OCI，您可以使用容器映像基础架构和工具（例如 Artifact Registry）来管理映像，并使用 Workload Identity Federation for GKE 来简化身份验证。

使用 OCI 作为配置源通常需要一个单独的流程，将配置文件构建到 OCI 映像中，然后将其推送到 Artifact Registry 等注册平台。与存储在 Git 代码库中的文件形式的配置相比，这种方法的人类可读性可能较低。

当您将 Config Sync 配置为使用 OCI 映像作为可靠来源时，Config Sync 会使用协调器 Pod 中的 oci-sync 容器从注册表中拉取包含配置的 OCI 映像。

RootSync 配置示例

以下示例展示了一个 RootSync 清单，该清单从存储在 Artifact Registry 中的 OCI 映像进行同步：

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0
    dir: .
    auth: k8sserviceaccount

此配置可将 Config Sync 设置为从 OCI 映像同步。 Config Sync 使用 Kubernetes 服务账号进行身份验证，并从 Artifact Registry 拉取 us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0 映像。

使用情形示例：CI/CD 流水线集成

假设您想将 OCI 映像创建集成到组织的 CI/CD 流水线中。当配置文件的更改合并后，您可以设置流水线来运行验证测试（例如 nomos vet 命令）、将 YAML 文件构建到 OCI 映像中，并将该映像推送到 Artifact Registry。然后，Config Sync 会自动检测并将新版本的映像应用到您的集群，从而确保所有配置更改都经过验证并按版本推出。

Helm 图表

Helm 是 Kubernetes 的热门软件包管理器，它使用一种称为图表的打包格式。Config Sync 可以提取、渲染和同步 Helm 图表中定义的资源。

Helm 提供了一种一致的方式来打包和重用 Kubernetes 应用。您可以使用模板或预构建的 Helm 图表来实现一致且可重复使用的配置。

如果您还不熟悉 Helm，模板化和发布流程可能会为您的配置管理流水线增加额外的复杂性。

当您将 Config Sync 配置为使用 Helm 图表作为可靠来源时，Config Sync 会使用协调器 Pod 中的 helm-sync 容器从 Helm 代码库（例如 Artifact Registry）或 Git 代码库拉取图表，然后渲染该图表以生成 Kubernetes 清单。或者，您也可以将 Config Sync 与 Kustomize 搭配使用来呈现 Helm 图表。如需详细了解此方法，请参阅将 Config Sync 与 Kustomize 和 Helm 搭配使用。

RootSync 配置示例

以下示例展示了一个 RootSync 清单，该清单可从存储在 Artifact Registry 中的 Helm 图表进行同步：

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: helm
  helm:
    repo: oci://us-central1-docker.pkg.dev/my-project/my-helm-repo
    chart: my-chart
    version: 1.2.0
    auth: gcpserviceaccount
    gcpServiceAccountEmail: my-service-account@my-project.iam.gserviceaccount.com
    releaseName: my-chart-release
    namespace: my-app-namespace # Namespace where the chart resources will be deployed

此配置用于设置 Config Sync，以从 OCI 代码库同步 Helm 图表。Config Sync 从 oci://us-central1-docker.pkg.dev/my-project/my-helm-repo 代码库中提取 my-chart 图表的版本 1.2.0，并使用 my-service-account@my-project.iam.gserviceaccount.com 服务账号进行身份验证。此命令会将图表的资源部署到 my-chart-release 发布名称下的 my-app-namespace 命名空间中。

用例示例：部署第三方应用

假设您是应用团队的一员，想要将 Prometheus 部署到集群。您可以配置 Config Sync 以从部署 Prometheus 的预建 Helm 图表中拉取数据。您无需手动运行 Helm 命令，只需在 Config Sync 的 RootSync 或 RepoSync 对象中定义图表来源、版本和任何自定义 values。然后，Config Sync 会使部署与指定的图表版本和配置保持同步。

选择来源类型

最佳来源类型取决于您团队的现有工具、工作流程和偏好。您可以使用下表了解每种来源类型的主要特征，以便做出明智的决策：

功能 Git 代码库 OCI 映像 Helm 图表
适用场景 通用配置管理；灵活性；可读性 不可变、已纳入版本控制的配置；利用容器基础架构 打包和分发复杂应用
可变性 可更改 不可更改 可变（图表版本不可变，但值可以更改）
回滚 还原提交或更改分支 部署之前的映像标记 回滚到之前的图表版本
工具 标准 Git 客户端、CI/CD 流水线 Docker 或 Podman、容器注册表 Helm CLI、Helm 代码库
性能 对于大型代码库，速度可能会较慢 速度更快，尤其是在大规模使用时 从图表仓库提取时速度快
身份验证 灵活（SSH、令牌），设置可能更复杂 使用 Workload Identity Federation for GKE 简化（例如，使用 Artifact Registry） 使用 Workload Identity Federation for GKE 简化（例如，使用 Artifact Registry）

您还可以在同一集群上使用不同的来源类型来实现不同的目的。例如，集群可能具有以下配置：

  • RootSync 从包含平台团队管理的基本集群级资源和政策的 Git 代码库同步。
  • 特定命名空间中的 RepoSync 从 Helm 图表同步，以部署由应用团队管理的 Redis 实例。
  • 另一个 RepoSync 位于不同的命名空间中，从包含一组由单独的 CI/CD 流程构建的应用专用配置的 OCI 映像同步。

后续步骤