管理现有集群对象

当 Anthos Config Management 管理集群对象时，它会监视该对象以及代码库中影响该对象的配置集，并确保它们保持同步。本主题介绍如何开始管理现有对象以及如何停止管理当前受管理的对象而不删除该对象。

概览

如果集群中的对象具有注释 configmanagement.gke.io/managed: enabled，则该对象由 Anthos Config Management 管理。

如果某个对象根本没有标签 configmanagement.gke.io/managed 或者设置为除 enabled 以外的任何值，则该对象未受管理。

以下流程图描述了导致对象变为受管或非受管对象的一些情况：

如何使用 Anthos Config Management 管理或取消管理 Kubernetes 对象

该图包含三个独立的流：开始管理对象、停止管理对象和删除受管对象。

  1. 我想管理对象。a. 此对象在代码库中是否有配置？
    • 否：为此对象创建配置。Anthos Config Management 设置注释 configmanagement.gke.io/managed: enabled 并开始管理对象。
    • 是：配置是否设置了注释 configmanagement.gke.io/managed: disabled？
      • 否：默认情况下管理该对象。
      • 是：修改配置以移除 configmanagement.gke.io/managed: disabled 注释。将更改推送到源代码库后，Anthos Config Management 会注意到更改，应用注释 configmanagement.gke.io/managed: enabled，然后应用配置。
  2. 我想停止管理对象，但不想将其删除。
    • 在代码库中修改该对象的配置，并设置注释 configmanagement.gke.io/managed: disabled。检测到配置更改时，Anthos Config Management 会停止管理该对象。
  3. 我想停止管理对象并将其删除。
    • 从代码库中删除该对象的配置。当您删除先前管理的对象的配置时，Anthos Config Management 将从该配置适用的所有集群或命名空间中删除该对象。

除了 configmanagement.gke.io/managed: enabled 注释之外，Anthos Config Management 还将标签 app.kubernetes.io/managed-by: configmanagement.gke.io 应用于其管理的所有对象。使用此标签，您可以轻松列出 Anthos Config Management 管理的所有对象。

为什么不手动应用注释？

Anthos Config Management 使用声明式模型，通过从代码库中读取所需的配置，将配置更改应用于集群。如果您尝试手动应用注释（使用 kubectl 命令或 Kubernetes API），Anthos Config Management 会自动使用代码库中的内容覆盖手动应用的注释。

准备工作

以下示例根据快速入门构建。 在开始执行以下步骤之前，请按照快速入门执行操作并完成检查集群和代码库之前的所有步骤。

列出所有受管对象

要列出给定集群或命名空间上由 Anthos Config Management 管理的所有对象，请使用如下所示的标签选择器：

kubectl get object-type -l "app.kubernetes.io/managed-by=configmanagement.gke.io"

要列出不受 Anthos Config Management 管理的所有对象，请使用如下所示的标签选择器：

kubectl get object-type -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"

例如，以下命令会列出 shipping-dev 命名空间中受 Anthos Config Management 管理的 RoleBinding：

kubectl get rolebindings -n shipping-dev \
    -l "app.kubernetes.io/managed-by=configmanagement.gke.io"

NAME           AGE
job-creators   12m
pod-creators   12m
sre-admin      12m
viewers        12m

以下命令会列出 kube-system 命名空间中不受 Anthos Config Management 管理的 RoleBinding：

kubectl get rolebindings -n kube-system \
    -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"

NAME                                             AGE
fluentd-gcp-scaler-binding                       2d21h
gce:cloud-provider                               2d21h
heapster-binding                                 2d21h
metrics-server-auth-reader                       2d21h
system::leader-locking-kube-controller-manager   2d21h
system::leader-locking-kube-scheduler            2d21h
system:controller:bootstrap-signer               2d21h
system:controller:cloud-provider                 2d21h
system:controller:token-cleaner                  2d21h

开始管理现有对象

在本示例中，您将手动创建一个角色，然后开始使用 Anthos Config Management 对其进行管理。

  1. 在 audit 命名空间中创建 myrole 角色：

    kubectl create role -n audit myrole --verb=get --resource=pods

  2. 查看 myrole 角色授予的权限：

    kubectl describe role -n audit myrole
    Name:         myrole
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get]

    此角色仅有权 get Pod。

  3. 此时，该角色存在于集群中，但 Anthos Config Management 并不知道。

    1. 在终端中，转到您的代码库的本地克隆。

    2. 使用以下命令为 myrole 创建 YAML 清单，并将此清单保存到名为 namespaces/audit/myrole.yaml 的新文件中。

      kubectl get role myrole -n audit -o yaml > namespaces/audit/myrole.yaml

    3. 修改 myrole.yaml 文件。

      1. 移除 metadata 键下除 name 和 namespace 以外的其他所有字段。
      2. 在 rules.verbs 列表字段中的 get 后添加 list 谓词。

      保存更改。生成的文件包含以下内容：

      apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: myrole
  namespace: audit
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list

    4. 将更改提交至代码库。

    5. Config Management Operator 注意到提交需要一些时间，请稍等片刻。要验证 myrole 角色现在是否受 Anthos Config Management 管理，请再次运行 kubectl describe。

      kubectl describe role myrole -n audit

请注意注释 configmanagement.gke.io/managed: enabled，它表示该对象受 Anthos Config Management 管理。另请注意显示代码库中路径和文件名的注释（对象最近发生的配置更改由这些注释导致）以及表示提交的 Git 哈希。

Name:         myrole
Labels:       app.kubernetes.io/managed-by=configmanagement.gke.io
Annotations:  configmanagement.gke.io/cluster-name: example-cluster-name
              configmanagement.gke.io/managed: enabled
              configmanagement.gke.io/source-path: namespaces/audit/myrole.yaml
              configmanagement.gke.io/token: 0836805a09f160f12aa934b9042527e7283c7030
PolicyRule:
Resources  Non-Resource URLs  Resource Names  Verbs
---------  -----------------  --------------  -----
pods       []                 []              [get list]

停止管理代管式对象

本示例说明如何停止管理 Anthos Config Management 当前正在管理的对象，例如开始管理现有对象中的 myrole 角色。

  1. 修改您的代码库本地克隆中的 namespaces/online/shipping-app-backend/shipping-dev/job-creator-rolebinding.yaml 文件，然后添加与以下粗体字匹配的 annotations: 部分：

     kind: RoleBinding
 apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: job-creators
 subjects:
 - kind: User
   name: sam@foo-corp.com
   apiGroup: rbac.authorization.k8s.io
 roleRef:
   kind: Role
   name: job-creator
   apiGroup: rbac.authorization.k8s.io
 annotations:
   configmanagement.gke.io/managed: disabled

    保存文件。

  2. 根据您的更改创建 Git 提交，并将提交推送到您的代码库。

  3. Anthos Config Management 发现和应用新提交需要一些时间，请稍等片刻。

  4. 使用以下命令列出 job-creators RoleBinding 上的所有注释。为便于阅读，输出已经过截断处理。

    kubectl get rolebinding job-creators -n audit -o yaml
    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  annotations:
    configmanagement.gke.io/cluster-name: my-cluster
    configmanagement.gke.io/managed: disabled
    configmanagement.gke.io/source-path: namespaces/viewers-rolebinding.yaml
    configmanagement.gke.io/sync-token: fabdb51587d51a81c7e419eeb983aafcf293dc83
...

验证该对象现已停用后，您可以移除该配置，并验证这个当前不受管理的对象是否未从命名空间中删除。如果要再次管理该对象，则必须重新创建其配置。因此，您可能要取消管理对象，并将其配置保留在代码库中。

由于对象不受管理，因此新集群或现有集群上不会创建或重新创建对象，并且即使对象已存在也不会被移除。如需继续管理您先前已停止管理的对象，请参阅下一个示例：继续管理先前已停止管理的对象。

继续管理先前已停止管理的对象

此示例演示如何继续管理如停止管理现有对象部分中所述，先前从管理中移除的对象。此示例假设您未移除 job-creators RoleBinding 的配置。

  1. 如果您在上次提交时从您的代码库中删除了 job-creators RoleBinding，请执行以下步骤。

    1. 使用 git revert 还原上次提交：

      git revert HEAD~1

      系统会要求您确认还原操作。

    2. 将还原提交推送到您的代码库中。

      git push

  2. 修改您的代码库本地克隆中的 namespaces/online/shipping-app-backend/shipping-dev/job-creator-rolebinding.yaml 文件并移除 configmanagement.gke.io/managed: disabled 注释。保存文件。

  3. 提交并推送您的更改。Anthos Config Management 执行以下操作：

    • 注意更改
    • 应用 configmanagement.gke.io/managed: enabled 注释（此对象现已受管理）。
    • 应用配置，正如任何受管对象一样。

  4. 如需验证该对象现在是否已经受到管理，请列出其注释：

    kubectl get rolebinding job-creators -n audit -o yaml
    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  annotations:
    configmanagement.gke.io/cluster-name: my-cluster
    configmanagement.gke.io/managed: enabled
...

停止管理命名空间

您可以采用与停止管理任意类型的对象相同的方式停止管理命名空间。如果要停止管理命名空间中的其他资源，请执行以下步骤：

  1. 将 configmanagement.gke.io/managed:disabled 注释添加到命名空间配置和同一命名空间中的所有配置。

  2. 提交更改并将更改推送到代码库。等待 Operator 与代码库同步。

  3. 从代码库中删除不受管理的资源。

如果受管配置的配置存在于不受管命名空间目录中，则 Syncer 会记录错误，但其他配置会继续正常同步。

后续步骤