排查 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 或 Google Cloud 资源（例如 CI/CD 流水线、自定义控制器、cron 作业等）。

如果该行为不是由外部系统引起的，请检查 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 集群和/或节点池启用 Workload Identity Federation for GKE。

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

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

如需解决此问题，请使用启用了 Workload Identity Federation for GKE 的 GKE 集群。

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

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

如果您的 Config Connector 资源的状态为 UpdateFailed，并且出现的消息指出由于 Workload Identity Federation for GKE 而导致 403 错误，则可能意味着 Config Connector 的 Kubernetes 服务账号缺少适当的 IAM 权限，无法以 Workload Identity Federation for GKE 用户的身份模拟您的 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":
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。详细了解如何为项目范围内的资源配置目标项目。

如果您仍然看到相同的错误，请检查 Workload Identity Federation for 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 创建或获取 Google Cloud 资源后不久，您可能会在 Config Connector 资源的状态中看到以下错误：

• 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 文档），了解它们是否支持标签。

Failed calling webhook x509: certificate relies on legacy Common Name field（调用 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 Config Connector 资源。对于 IAMPolicyMember，请删除整个资源。对于 IAMPolicy 和 IAMParitialPolicy，只需移除涉及已删除服务账号的绑定即可。不过，此类清理操作不会立即移除 Google Cloud 角色绑定。由于已删除的服务账号的保留期限， 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 支持团队。