防止配置偏移

借助 Config Sync,您可以防止配置偏移,以便集群资源与中央可靠来源保持一致。默认情况下,Config Sync 中的内置自我修复功能会自动检测并还原偏移,同时尽可能降低对集群性能的影响。

如果您的环境要求在集群应用有冲突的更改之前阻止这些更改,您可以启用 Config Sync 准入 webhook 以防止偏移。由于此网络钩子会增加内存开销,并可能导致内存不足 (OOM) 错误,因此在大多数使用场景中,请依赖内置的自我修复功能。

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

如果启用,偏移防范功能默认会保护 RootSync 对象。您可以将该功能配置为保护 RepoSync 对象。如需使用偏移防范功能,您必须启用 RootSync 和 RepoSync API。如需了解详情,请参阅 RootSync 和 RepoSync 字段。

准备工作

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

启用偏移防范

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

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

  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 权限,则可能无需执行这些步骤。

  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
    

后续步骤