防止配置偏移

Config Sync 提供两种管理偏移的方式：

• 使用 Config Sync 的内置自我修复功能（推荐，无需配置）：Config Sync 会自动检测并还原偏移。您无法停用 Config Sync 的自我修复功能。自愈对性能的影响极小。
• 启用偏移防范功能（本页）：偏移防范功能使用准入网络钩子来阻止冲突的更改。此功能可能会导致内存使用率过高和内存不足 (OOM) 错误，尤其是在具有许多 CustomResourceDefinition (CRD) 的集群中。

为何不建议使用偏移防范

准入网络钩子需要 Config Sync 加载 Kubernetes OpenAPI 架构才能验证请求。在具有许多资源或 CRD 的集群中，此架构处理可能会超出内存限制，从而导致组件故障。对于大多数使用情形，Config Sync 的内置自我修复功能可提供偏移保护，而不会带来网络钩子的稳定性风险。

如果启用，偏移防范功能默认会保护 RootSync 对象。您可以配置该功能以保护 RepoSync 对象。如需使用偏移防范功能，您必须启用 RootSync 和 RepoSync API。

注意：所有这些功能都采用服务器端应用，这意味着它们只会阻止或还原对可靠来源中明确指定的字段所做的更改。未指定的字段允许偏移。这是有必要的，因为许多 Kubernetes 控制器会在运行时更新元数据和规范字段，而不仅仅是状态字段。

准备工作

如果您之前安装了 Google Cloud CLI，请通过运行 gcloud components update 命令来获取最新版本。

启用偏移防范

您可以使用 gcloud CLI 来启用漂移防护功能。您无法在 Google Cloud 控制台中启用漂移防护功能。

如需启用漂移防护功能，请完成以下步骤：

1. 更新您的 apply spec 清单，将 spec.configSync.preventDrift 字段设置为 true：

   applySpecVersion: 1
   spec:
     configSync:
       enabled: true
       ... existing content ...
       preventDrift: true
   

2. 应用更新后的清单：

   gcloud beta container fleet config-management apply \
       --membership=MEMBERSHIP_NAME \
       --config=MANIFEST_NAME  \
       --project=PROJECT_ID
   

   替换以下内容：

   • MEMBERSHIP_NAME：您在注册集群时选择的舰队成员资格名称。使用 gcloud container fleet memberships list 命令获取名称。
   • MANIFEST_NAME：apply spec 清单的名称，通常为 apply-spec.yaml。
   • PROJECT_ID：您的项目 ID。

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

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

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

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

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

5. 等待网络钩子服务器准备就绪。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
   

停用偏移防范

停用漂移防护功能后，Config Sync 会删除所有 Config Sync 准入 webhook 资源。由于 Config Sync ValidatingWebhookConfiguration 对象已不存在，因此 Config Sync 协调器不再为代管式资源生成 webhook 配置。

如需停用漂移防护功能，请完成以下步骤：

1. 更新您的 apply spec 清单，将 spec.configSync.preventDrift 字段设置为 false：

   applySpecVersion: 1
   spec:
     configSync:
       enabled: false
       ... existing content ...
       preventDrift: false
   

2. 应用更新后的清单：

   gcloud beta container fleet config-management apply \
       --membership=MEMBERSHIP_NAME \
       --config=MANIFEST_NAME  \
       --project=PROJECT_ID
   

   替换以下内容：

   • MEMBERSHIP_NAME：您在注册集群时选择的舰队成员资格名称。使用 gcloud container fleet memberships list 命令获取名称。
   • MANIFEST_NAME：apply spec 清单的名称，通常为 apply-spec.yaml。
   • PROJECT_ID：您的项目 ID。

在命名空间级来源中启用准入 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 权限，则可能无需执行这些步骤。

注意：向命名空间级可靠来源授予读取或更新 ValidatingWebhookConfiguration 对象的权限意味着，命名空间级来源所有者可以更改集群中的 Config Sync 准入 webhook 配置。

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
   

后续步骤

• 了解如何排查 webhook 问题。