配置概览

本页面介绍了配置,Anthos Config Management 从 Git 读取并自动应用到集群的文件。您可以创建配置并将其提交到您的代码库。

Anthos Config Management 使用配置使已注册的集群保持同步。配置是存储在代码库中的 YAML 或 JSON 文件,包含您可以使用 kubectl apply 命令手动应用于集群的相同类型的配置详细信息。本主题介绍了配置如何工作、如何编写配置以及 Anthos Config Management 如何将配置应用于已注册的集群。

Anthos Config Management 专为管理多个集群的集群运营人员而设计。允许 Anthos Config Management 管理整个机群中的 Namespace、Role、RoleBinding、ResourceQuota 和其他重要的 Kubernetes 对象,可以确保您的集群符合业务与合规性标准。您可以为集群中存在的任何 Kubernetes 对象创建配置。

处理一段时间内的配置更改

以下决策树展示了由 Anthos Config Management 管理的一组假设集群在一段时间内发生的不同配置更改的结果。在图表下方,介绍了集群运营人员执行的一些假设操作,以及这些操作的结果,并使用这些内容说明 Anthos Config Management 的工作原理。

此集群使用的是示例代码库。 此集群已在 Operator 中注册。

示例决策树,展示了 Anthos Config Management 在一段时间内执行的操作和相应的结果

  • 只有在满足以下至少一个条件时,Anthos Config Management 才会应用配置:

    • 代码库中存在相关配置
    • 注释 configmanagement.gke.io/managed: enabled 已应用于 Kubernetes 对象

    foo-corp 集群包含一个名为 pod-accountant 的 ClusterRole,其中没有 configmanagement.gke.io/managed: enabled 注释,而且代码库中不存在 ClusterRole 对象的配置。Anthos Config Management 没有配置 pod-accountant ClusterRole。

  • Anthos Config Management 会在提交到代码库时自动应用相关更改。

    集群管理员将配置提交到代码库中的 cluster/quota-viewer-clusterrole.yaml 文件。此配置定义了一个名为 quota-viewer 的 ClusterRole。由于配置是在 cluster/ 目录中创建的,因此会影响所有已注册的集群。Anthos Config Management 检测到新提交的配置并应用此配置。现在,集群中将存在 quota-viewer ClusterRole,此 ClusterRole 具有 configmanagement.gke.io/managed: enabled 注释,并且与 quota-viewer-clusterrole.yaml 的内容保持同步。

    一段时间后,有人从代码库中删除了 cluster/quota-viewer-clusterrole.yaml 文件。Anthos Config Management 检测到此更改并从集群中移除了 quota-viewer ClusterRole。

  • 您可以通过添加 configmanagement.gke.io/managed: enabled 注释来开始管理集群中的现有对象。

    foo-corp 集群有一个名为 shipping-dev 的命名空间目录。在此命名空间目录中,存在一个名为 job-creator 的 Role 的配置,该配置具有 configmanagement.gke.io/managed: enabled 注释。有人更新了 namespaces/dev/shipping-dev/job-creator-role.yaml 文件。Operator 检测到更改并应用更改。

  • 借助 Anthos Config Management,您能够以分组的分层方式将配置更改应用于命名空间。

    foo-corp 集群在代码库中有一个名为 pod-creator 的 RoleBinding 和相应的 /namespaces/pod-creator/pod-creator.yaml 文件。该图表显示,shipping-prodshipping-stagingshipping-dev 都是位于 shipping-dev-backend 抽象命名空间目录中的命名空间(每个命名空间都有一个定义命名空间的 namespace.yaml 文件)。其中的每个命名空间都继承了 pod-creator RoleBinding。

    一段时间后,有人修改了 shipping-prod 命名空间目录中的 pod-creator RoleBinding。Operator 检测到此更改,并更新 pod-creator 以与代码库中的配置匹配。

    最后,有人从代码库中移除了 pod-creator 配置。 Anthos Config Management 检测到此更改,并从所有三个命名空间中移除了 pod-creator RoleBinding。

  • Anthos Config Management 允许您手动应用更改,并且除非对象具有 configmanagement.gke.io/managed: enabled 注释,否则不管理对象。

    有人在 shipping-prod 命名空间中手动创建了一个名为 secret-admin 的新 Role。代码库中不存在 secret-admin Role 的配置。secret-admin Role 没有 configmanagement.gke.io/managed: enabled 注释。Anthos Config Management 不会采取任何措施。

    一段时间后,有人为 secret-admin Role 手动添加了 configmanagement.gke.io/managed:enabled 注释。代码库中仍然没有相应的配置,因此 Anthos Config Management 会从命名空间中删除 secret-admin Role。

  • 如果存在其对应的配置,Anthos Config Management 会创建缺失的命名空间。

    有人为 audit 命名空间提交了新配置,但集群中不存在该命名空间。Anthos Config Management 会在集群中创建 audit 命名空间,并对其应用 configmanagement.gke.io/managed: enabled 注释。

  • Anthos Config Management 可以管理没有 configmanagement.gke.io/managed: enabled 注释的命名空间的配置。

    集群中存在 shipping-dev 命名空间,但该命名空间没有 configmanagement.gke.io/managed: enabled 注释。不过,代码库中的 shipping-dev 命名空间目录包含一个名为 job-creators 的 RoleBinding,它具有 configmanagement.gke.io/managed: enabled 注释。

    有人将 shipping-dev 命名空间的配置添加到代码库,但是 job-creators RoleBinding 没有对应的配置。由于 RoleBinding 没有对应的配置,而 RoleBinding 具有 configmanagement.gke.io/managed: enabled 注释,因此 Anthos Config Management 删除了 RoleBinding。

    后来,有人添加了 job-creators RoleBinding 的配置。系统会使用该配置中定义的属性重新创建 job-creators RoleBinding。

后续步骤