排查 Config Connector 问题

---

本页介绍了问题排查方法，供您用来排查 Config Connector 的问题，以及您在使用产品时可能会遇到的常见问题。

基本问题排查方法

检查 Config Connector 的版本

运行以下命令以获取已安装的 Config Connector 版本，并交叉参考版本说明，以验证运行的版本是否支持您要使用的功能和资源：

kubectl get ns cnrm-system -o jsonpath='{.metadata.annotations.cnrm\.cloud\.google\.com/version}'

检查资源的状态和事件

通常，您可以通过检查 Kubernetes 中的资源状态来确定 Config Connector 资源的问题。检查资源的状态和事件对于确定 Config Connector 是否未能协调资源以及协调失败的原因尤其有用。

检查 Config Connector 是否正在运行

如需检查 Config Connector 是否正在运行，请验证其所有 Pod 是否均为 READY：

kubectl get pod -n cnrm-system

输出示例：

NAME                                            READY   STATUS    RESTARTS   AGE
cnrm-controller-manager-0                       1/1     Running   0          1h
cnrm-deletiondefender-0                         1/1     Running   0          1h
cnrm-resource-stats-recorder-77dc8cc4b6-mgpgp   1/1     Running   0          1h
cnrm-webhook-manager-58496b66f9-pqwhz           1/1     Running   0          1h
cnrm-webhook-manager-58496b66f9-wdcn4           1/1     Running   0          1h

如果您在命名空间模式下安装了 Config Connector，则每个命名空间都有一个控制器 (cnrm-controller-manager) Pod，负责管理该命名空间中的 Config Connector 资源。

您可以通过运行以下命令检查负责特定命名空间的控制器 Pod 的状态：

kubectl get pod -n cnrm-system \
    -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager

将 NAMESPACE 替换为命名空间的名称。

检查控制器日志

控制器 Pod 会记录与 Config Connector 资源协调相关的信息和错误。

您可以通过运行以下命令检查控制器 Pod 的日志：

kubectl logs -n cnrm-system \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -c manager

如果您在命名空间模式下安装了 Config Connector，则上一个命令会集中显示所有控制器 Pod 的日志。您可以通过运行以下命令检查特定命名空间的控制器 Pod 的日志：

kubectl logs -n cnrm-system \
    -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -c manager

将 NAMESPACE 替换为命名空间的名称。

详细了解如何检查和查询 Config Connector 的日志。

放弃并获取资源

在某些情况下，您可能需要更新资源中的不可变字段。由于您无法修改不可变字段，因此必须先放弃资源，然后再获取资源：

1. 更新 Config Connector 资源的 YAML 配置，并将 cnrm.cloud.google.com/deletion-policy 注解设置为 abandon。
2. 应用更新后的 YAML 配置以更新 Config Connector 资源的删除政策。
3. 放弃 Config Connector 资源。
4. 更新 YAML 配置中需要更改的不可变字段。
5. 应用更新后的 YAML 配置以获取被废弃的资源。

常见问题

资源每 5-15 分钟持续更新

如果您的 Config Connector 资源每 5-10 分钟就从 UpToDate 状态切换到 Updating 状态，则可能是因为 Config Connector 检测到资源的预期状态与实际状态之间存在意外差异，从而导致 Config Connector 不断更新资源。

首先，确认您没有任何外部系统在不断修改 Config Connector 或资源（例如 CI/CD 流水线、自定义控制器、cron 作业等）。 Google Cloud

如果该行为不是由外部系统导致的，请检查 Google Cloud 是否会更改 Config Connector 资源中指定的任何值。例如，在某些情况下， Google Cloud 会更改字段值的格式（例如，大小写），导致资源的预期状态与实际状态之间存在差异。

使用 REST API（例如 ContainerCluster）或 Google Cloud CLI 获取资源的状态。 Google Cloud 然后，将该状态与您的 Config Connector 资源进行比较。查找值不匹配的所有字段，然后更新 Config Connector 资源以使其与这些字段匹配。尤其要注意是否有任何值由 Google Cloud重新格式化。例如，请参阅 GitHub 问题 #578 和 #294。

请注意，这并不是一个完美的方法，因为 Config Connector 和Google Cloud 资源模型不同，但它应该可以让您捕获大多数意外差异的情况。

如果您无法解决问题，请参阅其他帮助。

删除命名空间时停留在“Terminating”阶段

如果您在命名空间模式下安装了 Config Connector，并且先删除命名空间的 ConfigConnectorContext，再删除该命名空间中的所有 Config Connector 资源，则删除命名空间时可能会停留在 Terminating 阶段。删除命名空间的 ConfigConnectorContext 后，系统将为该命名空间停用 Config Connector，以防止删除该命名空间中任何剩余的 Config Connector 资源。

要解决此问题，您必须执行强制清理，然后再手动删除底层 Google Cloud 资源。

为了防止日后出现此问题，请仅在从 Kubernetes 中删除其命名空间中的所有 Config Connector 资源后再删除 ConfigConnectorContext。请不要在删除命名空间中的所有 Config Connector 资源之前就删除整个命名空间，因为系统可能会先删除 ConfigConnectorContext。

另请参阅如何删除包含项目及其子项或包含文件夹及其子项的命名空间。

删除项目后，删除资源时停留在“DeleteFailed”阶段

如果先删除 Config Connector 资源的 Google Cloud 项目，则删除 Config Connector 资源时可能无法停留在 DeleteFailed 阶段。

要解决此问题，请在Google Cloud上恢复项目，以便 Config Connector 能够从 Kubernetes 中删除剩余的子资源。您也可以执行强制清理。

为了防止日后出现此问题，请仅在从 Kubernetes 中删除所有子 Config Connector 资源后再删除 Google Cloud 项目。请不要删除可能同时包含 Project 资源及其子 Config Connector 资源的整个命名空间，因为系统可能会先删除 Project 资源。

未定义 Compute Engine 元数据

如果您的 Config Connector 资源的状态为 UpdateFailed，并且出现的消息指出未定义 Compute Engine 元数据，则可能意味着 Config Connector 使用的 IAM 服务账号不存在。

示例 UpdateFailed 消息：

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": Get
"https://spanner.googleapis.com/v1/projects/my-project/instances/my-spanner-instance?alt=json":
metadata: Compute Engine metadata "instance/service-accounts/default/token?
scopes=https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)compute%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSIN
G)auth%!F(MISSING)cloud-platform%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)cloud-identity%!C(MISSING)https%!A(MISSING)%!F(MISS
ING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)ndev.clouddns.readwrite%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSIN
G)devstorage.full_control%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)userinfo.email%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F
(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)drive.readonly" not
defined, detail:

要解决此问题，请确保 Config Connector 使用的 IAM 服务账号已存在。

为了防止日后出现此问题，请务必遵循 Config Connector 安装说明操作。

错误 403：请求没有足够的身份验证范围

如果您的 Config Connector 资源的状态为 UpdateFailed，并且出现的消息指出由于身份验证范围不足而导致 403 错误，则可能意味着 GKE 集群上未启用 Workload Identity。

示例 UpdateFailed 消息：

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner-instance": googleapi: Error 403: Request had
insufficient authentication scopes.

如需进行调查，请完成以下步骤：

1. 将以下 Pod 配置保存为 wi-test.yaml：

   apiVersion: v1
   kind: Pod
   metadata:
     name: workload-identity-test
     namespace: cnrm-system
   spec:
     containers:
     - image: google/cloud-sdk:slim
       name: workload-identity-test
       command: ["sleep","infinity"]
     serviceAccountName: cnrm-controller-manager
   

   如果您使用命名空间模式安装了 Config Connector，serviceAccountName 应为 cnrm-controller-manager-NAMESPACE。将 NAMESPACE 替换为您在安装期间使用的命名空间。

2. 在您的 GKE 集群中创建 Pod：

   kubectl apply -f wi-test.yaml
   

3. 在 Pod 中打开交互式会话：

   kubectl exec -it workload-identity-test \
       --namespace cnrm-system \
       -- /bin/bash
   

4. 列出您的身份：

   gcloud auth list
   

5. 验证列出的身份是否与绑定到您的资源的 Google 服务账号相匹配。

   如果改为显示 Compute Engine 默认服务账号，则说明未在 GKE 集群和/或节点池上启用适用于 GKE 的工作负载身份联合。

6. 退出交互式会话，然后从 GKE 集群中删除 Pod：

   kubectl delete pod workload-identity-test \
       --namespace cnrm-system
   

如需解决此问题，请使用启用了适用于 GKE 的工作负载身份联合的 GKE 集群。

如果您在启用了适用于 GKE 的工作负载身份联合的 GKE 集群上仍然看到相同的错误，请确保您没有忘记在集群的节点池上也启用适用于 GKE 的工作负载身份联合。详细了解如何在现有节点池上启用适用于 GKE 的工作负载身份联合。我们建议在集群的所有节点池上启用适用于 GKE 的工作负载身份联合，因为 Config Connector 可以在任何节点池上运行。

403 禁止使用：调用者没有权限；请参阅 Workload Identity Federation for GKE 文档

如果您的 Config Connector 资源的状态为 UpdateFailed，并且出现的消息指出由于 Workload Identity Federation for GKE 而导致 403 错误，则可能意味着 Config Connector 的 Kubernetes 服务账号缺少适当的 IAM 权限，无法将您的 IAM 服务账号作为 Workload Identity Federation for GKE 用户进行模拟。

示例 UpdateFailed 消息：

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": Get
"https://spanner.googleapis.com/v1/projects/my-project/instances/my-spanner-instance?alt=json":
compute: Received 403 `Unable to generate access token; IAM returned 403
Forbidden: The caller does not have permission
This error could be caused by a missing IAM policy binding on the target IAM
service account.
For more information, refer to the Workload Identity Federation for GKE documentation:
  https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#creating_a_relationship_between_ksas_and_gsas

要解决此问题并防止日后出现此问题，请参阅 Config Connector 安装说明。

错误 403：调用方缺少 IAM 权限

如果您的 Config Connector 资源的状态为 UpdateFailed，并且出现的消息指出调用者缺少 IAM 权限，则可能意味着 Config Connector 使用的 IAM 服务账号缺少消息中所述的 IAM 权限，而管理 Google Cloud 资源需要此权限。

示例 UpdateFailed 消息：

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": googleapi: Error 403: Caller is missing IAM
permission spanner.instances.get on resource
projects/my-project/instances/my-spanner-instance., detail:

如果您在为 IAM 服务账号授予适当的 IAM 权限后仍然看到相同的错误，请检查该资源是否已在正确的项目中创建。检查 Config Connector 资源的 spec.projectRef 字段（如果资源不支持 spec.projectRef 字段，则检查其 cnrm.cloud.google.com/project-id 注释），并验证资源是否引用了正确的项目。请注意，如果资源和命名空间都未指定目标项目，则 Config Connector 会将命名空间名称用作项目 ID。详细了解如何为项目范围内的资源配置目标项目。

如果您仍然看到相同的错误，请检查 您的 GKE 集群是否已启用适用于 GKE 的工作负载身份联合。

为了防止日后出现此问题，请务必遵循 Config Connector 安装说明操作。

Config Connector 插件安装不支持的版本

如果您无法成功启用 Config Connector 插件，则会显示以下错误消息：Node version 1.15.x-gke.x s unsupported。要解决此错误，请验证 GKE 集群版本是否符合版本和功能要求。

如需获取集群的所有有效版本，请运行以下命令：

gcloud container get-server-config --format "yaml(validMasterVersions)" \
    --zone ZONE

将 ZONE 替换为 Compute Engine 区域。

从列表中选择符合要求的版本。

如果停用 Workload Identity Federation for GKE 或 GKE Monitoring，系统也会显示错误消息。请确保启用这些功能，以修复错误。

无法更改不可变字段

Config Connector 会在准入时拒绝不可变字段的更新。

例如，使用 kubectl apply 更新不可变字段会导致命令立即失败。

这意味着如果持续重新应用资源的工具（例如 GitOps）不处理准入错误的话，则在更新资源时这些工具可能会遇到问题。

由于 Config Connector 不允许更新不可变字段，因此执行此类更新的唯一方法是删除并重新创建资源。

在没有更新时更新不可变字段时出错

在使用 Config Connector 创建或获取资源后，您可能会在 Config Connector 资源的状态中看到以下错误： Google Cloud

• Update call failed: error applying desired state: infeasible update: ({true \<nil\>}) would require recreation（示例）

• Update call failed: cannot make changes to immutable field(s)（示例）

这可能并不意味着您实际上更新了资源，而可能是由于 Google Cloud API 更改了您在 Config Connector 资源中管理的不可变字段。这导致了不可变字段的预期状态与实际状态之间不匹配。

您可以通过更新 Config Connector 资源中这些不可变字段的值以使其与实际状态相符来解决此问题。为此，您应完成以下步骤：

1. 更新 Config Connector 资源的 YAML 配置，并将 cnrm.cloud.google.com/deletion-policy 注解设置为 abandon。
2. 应用更新后的 YAML 配置以更新 Config Connector 资源的删除政策。
3. 放弃 Config Connector 资源。
4. 使用 gcloud CLI 输出相应资源的实际状态。 Google Cloud
5. 找出 gcloud CLI 输出与 Config Connector 资源的 YAML 配置之间的不一致之处，并更新 YAML 配置中的这些字段。
6. 应用更新后的 YAML 配置以获取被废弃的资源。

资源没有状态

如果您的资源没有 status 字段，则可能是因为 Config Connector 未正常运行。检查 Config Connector 是否正在运行。

种类“Foo”无匹配项

如果遇到此错误，则表示 Kubernetes 集群未安装 Foo 资源种类的 CRD。

验证该种类是否为 Config Connector 支持的资源种类。

如果该种类受支持，则表示您的 Config Connector 安装已过时或无效。

如果您使用 GKE 插件安装了 Config Connector，则安装内容应会自动升级。如果您手动安装了 Config Connector，则必须手动升级。

检查 GitHub 代码库，以确定哪些 Config Connector 版本支持哪些资源种类（例如，这里列出 Config Connector v1.44.0 支持的种类）。

标签不会传播到 Google Cloud 资源

Config Connector 会将在 metadata.labels 中找到的标签传播到底层Google Cloud 资源。不过，请注意，并非所有 Google Cloud资源都支持标签。请查看资源的 REST API 文档（例如，此处是 PubSubTopic 的 API 文档），了解它们是否支持标签。

调用 webhook 失败 x509：证书依赖于旧版通用名称字段

如果您看到类似于以下示例的错误，则表示您可能遇到了证书问题：

Error from server (InternalError): error when creating "/mnt/set-weaver-dns-record.yml": Internal error occurred: failed calling webhook "annotation-defaulter.cnrm.cloud.google.com": Post "https://cnrm-validating-webhook.cnrm-system.svc:443/annotation-defaulter?timeout=30s": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0

注意： 此问题仅在 Kubernetes 1.19 或更高版本中出现，Config Connector 1.43 及更高版本支持自动生成证书，这应该可以避免您遇到此问题。

如需解决此问题，请删除相关证书和 Pod：

kubectl delete -n cnrm-system secrets cnrm-webhook-cert-abandon-on-uninstall
kubectl delete -n cnrm-system secrets cnrm-webhook-cert-cnrm-validating-webhook
kubectl delete -n cnrm-system pods -l "cnrm.cloud.google.com/component=cnrm-webhook-manager"

删除这些资源后，系统会重新生成正确的证书。

如需详细了解此错误，请参阅 GitHub 问题。

因资源名称中包含特殊字符而导致的错误

Kubernetes metadata.name 字段不允许使用特殊字符。如果您看到类似于以下示例的错误，则表示资源的 metadata.name 可能包含特殊字符的值：

a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

例如，以下 SQLUser 资源的 metadata.name 中包含无效字符：

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLUser
metadata:
  name: [e-mail]
spec:
  instanceRef:
    name: test-cloudsql-db
  type: "CLOUD_IAM_USER"

如果您尝试创建此资源，则会收到以下错误：

Error from server (Invalid): error when creating "sqlusercrd.yaml": SQLUser.sql.cnrm.cloud.google.com "[e-mail]" is invalid: metadata.name: Invalid value: "[e-mail]": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

如果您想为资源指定的名称不是有效的 Kubernetes 名称，而是有效的 Google Cloud 资源名称，则可以使用 resourceID 字段，如以下示例所示：

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLUser
metadata:
  name: 'test'
spec:
  instanceRef:
    name: sqlinstance-sample-postgresql
  host: "%"
  type: CLOUD_IAM_USER
  resourceID: [e-mail]

此配置会导致 Config Connector 使用 resourceID（而非 metadata.name）作为资源的名称。

无法从资源规范中移除字段

从 Config Connector 资源的规范中移除字段（通过更新资源的 .yaml 文件并重新应用，或使用 kubectl edit 修改资源规范）实际上不会从 Config Connector 资源的规范或底层资源中移除该字段。 Google Cloud 相反，从规范中移除字段只会使该字段由外部管理。

注意 ：有一个例外：列表中的字段。列表是原子性的，这意味着 Config Connector 会尝试将底层 Google Cloud中的列表设置为等同于规范中指定的列表。

如果您想将某个字段的值更改为底层Google Cloud 资源中的空值或默认值，则必须在 Config Connector 资源规范中将该字段设为零：

• 对于列表类型字段，请使用 [] 将该字段设置为空列表。

  以下示例展示了我们要移除的 targetServiceAccounts 字段：

  spec:
    targetServiceAccounts:
      - external: "[e-mail]"
      - external: "[e-mail]"
  

  如需移除此字段，请将值设为空：

  spec:
    targetServiceAccounts: []
  

• 对于基元类型字段，请使用以下任一方法将该字段设置为空：

  类型	空值
  字符串	""
  布尔值	“false”
  整数	0

  以下示例展示了我们要移除的 identityNamespace 字段：

  spec:
    workloadIdentityConfig:
      identityNamespace: "foo-project.svc.id.goog"
  

  如需移除此字段，请将值设为空：

  spec:
    workloadIdentityConfig:
      identityNamespace: ""
  

• 对于对象类型字段，目前 Config Connector 中没有简单的方法可以将整个对象类型字段设置为“NULL”。您可以尝试按照上述指南将对象类型的子字段设置为空或默认值，然后验证能否正常运行。

KNV2005：同步器过度更新资源

如果您使用的是 Config Sync，并且看到 Config Connector 资源存在 KNV2005 错误，则可能是因为 Config Sync 和 Config Connector 正在争夺资源。

日志消息示例：

KNV2005: detected excessive object updates, approximately 6 times per
minute. This may indicate Config Sync is fighting with another controller over
the object.

如果 Config Sync 和 Config Connector 不断将同一字段更新为不同的值，则表示它们正在争夺资源。其中一个更新会触发另一个更新并更新资源，这会导致另一个更新并更新资源，以此类推。

对于大多数领域，打架都不是问题。Config Sync 中指定的字段不会被 Config Connector 更改，而 Config Sync 中未指定且由 Config Connector 设为默认值的字段会被 Config Sync 忽略。因此，对于大多数字段，Config Sync 和 Config Connector 绝不应最终将同一字段更新为不同的值。

但有一种例外情况：列表字段。与 Config Connector 可能会在对象字段中设置默认子字段的方式类似，Config Connector 也可能会在列表中的对象中设置默认子字段。不过，由于 Config Connector 资源中的列表字段是原子字段，因此子字段的默认值被视为完全更改了列表的值。

因此，如果 Config Sync 设置列表字段，而 Config Connector 将该列表中的任何子字段设为默认值，Config Sync 和 Config Connector 最终会发生冲突。

如需解决此问题，您可以使用以下方法：

1. 更新 Config Sync 代码库中的资源清单，使其与 Config Connector 尝试将资源设置为的值相匹配。

   为此，您可以暂时停止同步配置，等待 Config Connector 完成资源协调，然后更新资源清单以与 Kubernetes API 服务器上的资源保持一致。

2. 将注解 client.lifecycle.config.k8s.io/mutation 设置为 ignore，以停止 Config Sync 对 Kubernetes API 服务器上资源的更新做出响应。详细了解如何让 Config Sync 忽略对象更改。

3. 通过将资源上的注解 cnrm.cloud.google.com/state-into-spec 设置为 absent，阻止 Config Connector 完全更新资源的规范。并非所有资源都支持此注解。如需了解您的资源是否支持该注解，请参阅相应的资源参考页面。详细了解该注释。

failed calling webhook

Config Connector 可能处于无法卸载的状态。在使用 Config Connector 插件并在 移除 Config Connector CRD 之前停用 Config Connector 时，通常会发生这种情况。尝试卸载时，您收到类似于以下内容的错误：

error during reconciliation: error building deployment objects: error finalizing the deletion of Config Connector system components deployed by ConfigConnector controller: error waiting for CRDs to be deleted: error deleting CRD accesscontextmanageraccesslevels.accesscontextmanager.cnrm.cloud.google.com: Internal error occurred: failed calling webhook "abandon-on-uninstall.cnrm.cloud.google.com": failed to call webhook: Post "https://abandon-on-uninstall.cnrm-system.svc:443/abandon-on-uninstall?timeout=3s": service "abandon-on-uninstall" not found

如需解决此错误，您必须先手动删除相应 webhook：

kubectl delete validatingwebhookconfiguration abandon-on-uninstall.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete validatingwebhookconfiguration validating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete mutatingwebhookconfiguration mutating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true

然后，您可以继续卸载 Config Connector。

更新 IAMPolicy、IAMPartialPolicy 和 IAMPolicyMember 时出错

如果您在清理依赖于该服务账号的 IAMPolicy、IAMPartialPolicy 和 IAMPolicyMember 资源之前删除了 IAMServiceAccount Config Connector 资源，则 Config Connector 在对账期间无法找到这些 IAM 资源中引用的服务账号。这会导致 UpdateFailed 状态并显示如下所示的错误消息：

Update call failed: error setting policy member: error applying changes: summary: Request `Create IAM Members roles/[MYROLE] serviceAccount:[NAME]@[PROJECT_ID].iam.gserviceaccount.com for project \"projects/[PROJECT_ID]\"` returned error: Error applying IAM policy for project \"projects/[PROJECT_ID]\": Error setting IAM policy for project \"projects/[PROJECT_ID]\": googleapi: Error 400: Service account [NAME]@[PROJECT_ID].iam.gserviceaccount.com does not exist., badRequest

如需解决此问题，请检查您的服务账号，看看是否已删除这些 IAM 资源所需的服务账号。如果服务账号被删除，请一并清理相关的 IAM 配置连接器资源。对于 IAMPolicyMember，请删除整个资源。对于 IAMPolicy 和 IAMParitialPolicy，请仅移除涉及已删除的服务账号的绑定。不过，此类清理不会立即移除角色绑定。 Google Cloud 由于已删除的服务账号的保留期限为 60 天，因此 Google Cloud 角色绑定会保留 60 天。如需了解详情，请参阅 Google Cloud 有关删除服务账号的 IAM 文档。

注意 ：如果您在删除过程中遇到任何问题，可能需要执行强制清理。 如果您想立即删除 Google Cloud IAM 绑定，则需要使用 gcloud 手动删除底层 Google Cloud 资源。

为避免此问题，您应始终在删除引用的 IAMServiceAccount 之前清理 IAMPolicy、IAMPartialPolicy、IAMPolicyMember Config Connector 资源。

Config Connector 删除的资源

Config Connector 绝不会在没有外部原因的情况下删除您的资源。例如，运行 kubectl delete、使用 Argo CD 等配置管理工具或使用自定义 API 客户端都可能会导致资源被删除。

一个常见的误解是，Config Connector 已在集群中发起并删除了一些资源。例如，如果您使用的是 Config Connector，则可能会在容器日志消息或 Kubernetes 集群审核日志中注意到 Config Connector 控制器管理器针对特定资源发出的删除请求。这些删除请求是外部触发器的结果，Config Connector 正在尝试协调这些删除请求。

如需确定资源被删除的原因，您需要查看发送到相应资源的第一个删除请求。调查此问题的最佳方法是检查 Kubernetes 集群审核日志。

例如，如果您使用的是 GKE，则可以使用 Cloud Logging 查询 GKE 集群审核日志。例如，如果您想查找命名空间 bar 中名为 foo 的 BigQueryDataset 资源的初始删除请求，则可以运行如下查询：

resource.type="k8s_cluster"
resource.labels.project_id="my-project-id"
resource.labels.cluster_name="my-cluster-name"
protoPayload.methodName="com.google.cloud.cnrm.bigquery.v1beta1.bigquerydatasets.delete"
protoPayload.resourceName="bigquery.cnrm.cloud.google.com/v1beta1/namespaces/bar/bigquerydatasets/foo"

使用此查询，您可以查找第一个删除请求，然后检查该删除日志消息的 authenticationInfo.principalEmail 以确定删除原因。

控制器 Pod 因内存不足而终止

如果您在 Config Connector 控制器 Pod 上看到 OOMKilled 错误，则表示容器或整个 Pod 因使用超出允许的内存而被终止。您可以通过运行 kubectl describe 命令来验证这一点。Pod 的状态可能会显示为 OOMKilled 或 Terminating。此外，仔细检查 Pod 的事件日志可以揭示任何与 OOM 相关的事件。

kubectl describe pod POD_NAME -n cnrm-system

将 POD_NAME 替换为您要排查问题的 Pod。

要解决此问题，您可以使用 ControllerResource 自定义资源来增加 Pod 的内存请求和内存限制。

PodSecurityPolicy 会阻止升级

从 Config Connector 插件改为手动安装并将 Config Connector 升级到新版本后，使用 PodSecurityPolicy 可能会导致 cnrm Pod 无法更新。

如需确认 PodSecurityPolicies 是否阻止了升级，请检查 config-connector-operator 的事件，并查找类似于以下错误的错误：

create Pod configconnector-operator-0 in StatefulSet configconnector-operator failed error: pods "configconnector-operator-0" is forbidden: PodSecurityPolicy: unable to admit pod: [pod.metadata.annotations[seccomp.security.alpha.kubernetes.io/pod]: Forbidden: seccomp may not be set pod.metadata.annotations[container.seccomp.security.alpha.kubernetes.io/manager]: Forbidden: seccomp may not be set]

如需解决此问题，您必须在 PodSecurityPolicy 中指定与错误中提及的注解对应的注解。在前面的示例中，注解为 seccomp.security.alpha.kubernetes.io。

强制清理

如果您的 Config Connector 资源卡在删除阶段，并且您只想将其从 Kubernetes 集群中移除，则可以通过删除其终结器来强制删除这些资源。

警告 ：此操作应作为最后的手段，因为删除终结器超出了 Config Connector 的正常使用范围，并且可能会产生意外后果。具体而言，我们无法保证底层 Google Cloud 资源

会发生什么情况。

您可以通过以下方式删除资源的终结器：使用 kubectl edit 修改资源，删除 metadata.finalizers 字段，然后保存文件以将更改保留到 Kubernetes API 服务器。

由于删除资源的终结器允许将资源立即从 Kubernetes 集群中删除，因此 Config Connector可能不会（但不一定）完成对底层Google Cloud 资源的删除。这意味着您随后需要手动删除 Google Cloud 资源。

监控

指标

您可以使用 Prometheus 从 Config Connector 中收集和显示指标。

日志记录

所有 Config Connector Pod 都会输出 JSON 格式的结构化日志。

控制器 Pod 的日志对调试资源协调问题特别有用。

您可以通过过滤日志消息中的以下字段来查询日志中的特定资源：

• logger：包含小写的资源种类。例如，PubSubTopic 资源的 logger 为 pubsubtopic-controller。
• resource.namespace：包含资源的命名空间。
• resource.name：包含资源的名称。

使用 Cloud Logging 进行高级日志查询

如果您使用的是 GKE，则可以通过以下查询使用 Cloud Logging 查询日志中的特定资源：

注意：查询语法不支持评论。以下查询使用注释惯例 # 注释来提供说明文字，但这些注释不能包含在查询中。

# Filter to include only logs coming from the controller Pods
resource.type="k8s_container"
resource.labels.container_name="manager"
resource.labels.namespace_name="cnrm-system"
labels.k8s-pod/cnrm_cloud_google_com/component="cnrm-controller-manager"

# Filter to include only logs coming from a particular GKE cluster
resource.labels.cluster_name="GKE_CLUSTER_NAME"
resource.labels.location="GKE_CLUSTER_LOCATION"

# Filter to include only logs for a particular Config Connector resource
jsonPayload.logger="RESOURCE_KIND-controller"
jsonPayload.resource.namespace="RESOURCE_NAMESPACE"
jsonPayload.resource.name="RESOURCE_NAME"

请替换以下内容：

• 将 GKE_CLUSTER_NAME 替换为运行 Config Connector 的 GKE 集群的名称
• 将 GKE_CLUSTER_LOCATION 替换为运行 Config Connector 的 GKE 集群的位置。例如 us-central1。
• 将 RESOURCE_KIND 替换为小写的资源种类。例如 pubsubtopic。
• 将 RESOURCE_NAMESPACE 替换为资源的命名空间。
• 将 RESOURCE_NAME 替换为资源的名称。

更多帮助

如需其他帮助，您可以在 GitHub 上提交问题，也可以联系 Google Cloud 支持团队。