防止配置偏移

Config Sync 通过自动自我修复、定期重新同步和可选的偏移防范功能来降低“影子操作”的风险。当 Config Sync 检测到集群与可靠来源之间存在偏移时，系统将允许 Config Sync 快速还原偏移内容或者完全拒绝偏移内容。

自我修复功能会监控代管资源，以及检测与可靠来源之间的偏移并还原该偏移。自我修复功能始终处于启用状态。

定期重新同步功能会在上次成功同步一小时后自动同步，即使未对可靠来源进行任何更改也是如此。定期重新同步功能始终处于启用状态。

虽然自我修复和定期重新同步功能都有助于修复偏移，不过偏移防范功能还会拦截想要更改代管对象的请求，并验证是否应该允许更改请求。如果更改内容与可靠来源不一致，则更改请求会被拒绝。偏移防范功能默认处于停用状态。如果启用，偏移防范功能默认会保护 RootSync 对象，并且还可以配置为保护 RepoSync 对象。

如需使用偏移防范功能，您必须启用 RootSync 和 RepoSync API。

启用偏移防范

  1. 将配置文件中的 preventDrift 字段设置为 true，并应用配置文件：

    gcloud

    如果您使用 Google Cloud Console 或 gcloud CLI 安装了 Config Sync，请使用 gcloud CLI 启用偏移预防。请务必将 gcloud CLI 更新到最新版本。将 gcloud 配置文件的 spec.configSync.preventDrift 字段设置为 true，然后应用 gcloud 配置文件。

    kubectl

    如果您使用 kubectl 手动安装 Config Sync，请使用 kubectl 启用偏移防范。将 ConfigManagement 对象的 spec.preventDrift 字段设置为 true，然后应用 ConfigManagement 对象。

  2. 等待 ConfigManagement Operator 创建 Config Sync ValidateWebhookConfiguration 对象：

    kubectl get validatingwebhookconfiguration admission-webhook.configsync.gke.io

    您应该会看到类似于以下示例的输出：

    NAME                                  WEBHOOKS   AGE
admission-webhook.configsync.gke.io   0          2m15s

  3. 提交要同步的可靠来源的新更改，以便 root-reconciler 部署可以将 webhook 添加到 Config Sync ValidatingWebhookConfiguration 对象中。另一种方法是删除 root-reconcilier 部署以触发协调。新的 root-reconciler 部署将更新 Config Sync ValidatingWebhookConfiguration 对象。

  4. 等待网络钩子服务器准备就绪。Config Sync 准入网络钩子 Deployment 日志应包含 serving webhook server。此过程可能耗时几分钟。

    kubectl logs -n config-management-system -l app=admission-webhook --tail=-1 | grep "serving webhook server"

    您应该会看到类似于以下示例的输出：

    I1201 18:05:41.805531       1 deleg.go:130] controller-runtime/webhook "level"=0 "msg"="serving webhook server"  "host"="" "port"=10250
I1201 18:07:04.626199       1 deleg.go:130] controller-runtime/webhook "level"=0 "msg"="serving webhook server"  "host"="" "port"=10250

停用偏移防范

gcloud

如果您使用 Google Cloud Console 或 gcloud CLI 安装了 Config Sync，请使用 gcloud CLI 停用偏移预防。请务必将 gcloud CLI 更新到最新版本。将 gcloud 配置文件的 spec.configSync.preventDrift 字段设置为 false 或移除该字段，然后应用 gcloud 配置文件。

kubectl

如果您使用 kubectl 手动安装 Config Sync，请使用 kubectl 停用偏移防范。将 ConfigManagement 对象的 spec.preventDrift 字段设置为 false，或移除该字段，然后应用 ConfigManagement 对象。

这将删除所有 Config Sync 准入 webhook 资源。由于 Config Sync ValidatingWebhookConfiguration 对象已不存在，因此 Config Sync 协调器不再为代管式资源生成 webhook 配置。

在命名空间级来源中启用准入 webhook

webhook 不会对命名空间级可靠来源进行全面保护。每个命名空间来源的 Config Sync 协调器无权读取或更新集群级层的 ValidatingWebhookConfiguration 对象。

这种权限不足会导致命名空间协调器的日志中出现类似于以下示例的错误：

Failed to update admission webhook: KNV2013: applying changes to
admission webhook: Insufficient permission. To fix, make sure the reconciler has
sufficient permissions.:
validatingwebhookconfigurations.admissionregistration.k8s.io "admission-
webhook.configsync.gke.io" is forbidden: User "system:serviceaccount:config-
management-system:ns-reconciler-NAMESPACE" cannot update resource
"validatingwebhookconfigurations" in API group "admissionregistration.k8s.io" at
the cluster scope

如果您不想对命名空间级可靠来源使用 webhook 保护，则可以忽略此错误。但是，如果要使用 webhook，请在配置从多个可靠来源同步后向协调器授予对每个命名空间级可靠来源的相应权限。如果 ns-reconciler-NAMESPACE 的 RoleBinding 已存在且具有 ClusterRole cluster-admin 权限，则可能无需执行这些步骤。

  1. 在根可靠来源中，声明一个新的 ClusterRole 配置，以授予对 Config Sync 准入 webhook 的相应权限。此 ClusterRole 只需要每个集群定义一次：

    # ROOT_SOURCE/cluster-roles/webhook-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: admission-webhook-role
rules:
- apiGroups: ["admissionregistration.k8s.io"]
  resources: ["validatingwebhookconfigurations"]
  resourceNames: ["admission-webhook.configsync.gke.io"]
  verbs: ["get", "update"]

  2. 对于需要向其授予准入 webhook 相应权限的每个命名空间级来源，为其声明一个 ClusterRoleBinding 配置，以授予对准入 webhook 的访问权限：

    # ROOT_SOURCE/NAMESPACE/sync-webhook-rolebinding.yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-webhook
subjects:
- kind: ServiceAccount
  name: ns-reconciler-NAMESPACE
  namespace: config-management-system
roleRef:
  kind: ClusterRole
  name: admission-webhook-role
  apiGroup: rbac.authorization.k8s.io

    将 NAMESPACE 替换为在其中创建了命名空间级来源的命名空间。

  3. 将更改提交到根可靠来源，例如，如果是从 Git 代码库同步，请执行以下命令：

    git add .
git commit -m 'Providing namespace repository the permission to update the admission webhook.'
git push

  4. 如需进行验证，请使用 kubectl get 确保 ClusterRole 和 ClusterRoleBinding 已创建完毕：

    kubectl get clusterrole admission-webhook-role
kubectl get clusterrolebindings syncs-webhook

为已弃用的资源停用偏移防范

删除 RootSync 或 RepoSync 对象时，默认情况下，Config Sync 不会修改之前由该 RootSync 或 RepoSync 对象管理的资源。这可能会导致 Config Sync 用来跟踪这些资源对象的多个标签和注解被遗留下来。如果启用了偏移保护，则可能会导致对先前代管资源的任何更改都被拒绝。

如果您未使用删除传播选项，则遗留下来的资源对象可能仍会保留 Config Sync 添加的标签和注解。

如果要保留这些代管资源，请在删除 RootSync 或 RepoSync 对象之前，在可靠来源中声明的每个代管资源上将 configmanagement.gke.io/managed 注解设置为 disabled，以取消管理这些资源。这会指示 Config Sync 从代管资源中移除其标签和注解，而不删除这些资源。同步完成后，您便可以移除 RootSync 或 RepoSync 对象。

如果要删除这些代管资源，有两种方法：

  • 从可靠来源中删除代管资源。然后，Config Sync 将从集群中删除代管对象。同步完成后，您便可以移除 RootSync 或 RepoSync 对象。
  • 在删除 RootSync 或 RepoSync 对象之前，为其启用删除传播选项。然后，Config Sync 将从集群中删除代管对象。

如果在删除 RootSync 或 RepoSync 对象之前没有取消管理或删除其代管资源，您可以重新创建 RootSync 或 RepoSync 对象，它们会采用集群上与可靠来源一致的资源。然后，您可以取消管理或删除资源，等待更改同步，然后再次删除 RootSync 或 RepoSync 对象。

后续步骤