排解 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，每個負責管理該命名空間中 Config Connector 資源的控制器 (cnrm-controller-manager) Pod 都會對應到一個命名空間。

您可以執行下列指令，查看負責特定命名空間的控制器 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 (例如 for ContainerCluster) 或 Google Cloud CLI，取得 Google Cloud 資源的狀態。接著，請將該狀態與 Config Connector 資源進行比較。找出值不相符的任何欄位，然後更新 Config Connector 資源以符合需求。特別要找出任何由 Google Cloud重新格式化的值。例如，請參閱 GitHub 問題 #578 和 #294。

請注意，由於設定連接器和Google Cloud 資源模型不同，因此這並非完美的方法，但應該可以讓您找出大部分的非預期差異。

如果無法解決問題，請參閱其他說明。

命名空間刪除作業卡在「終止」狀態

如果您在 命名空間模式下安裝 Config Connector，且在刪除該命名空間中的所有 Config Connector 資源前，先刪除了命名空間的 ConfigConnectorContext，則刪除命名空間的作業可能會卡在 Terminating。刪除命名空間的 ConfigConnectorContext 後，系統會為該命名空間停用 Config Connector，以免刪除該命名空間中任何剩餘的 Config Connector 資源。

如要修正這個問題，您必須執行強制清理作業，然後手動刪除基礎 Google Cloud 資源。

為避免日後發生這個問題，請在從 Kubernetes 刪除其命名空間中的所有 Config Connector 資源後，再刪除 ConfigConnectorContext。請勿在刪除該命名空間中的所有 Config Connector 資源前刪除整個命名空間，因為 ConfigConnectorContext 可能會先遭到刪除。

另外，請瞭解刪除包含專案及其子項或資料夾及其子項的命名空間時，可能會發生卡住的情況。

刪除專案後，資源刪除作業卡在「DeleteFailed」

如果 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 服務帳戶是否存在。

為日後減輕這類問題的影響，請務必按照 設定連接器安裝操作說明操作。

錯誤 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

如要修正這個問題，請使用已啟用 Workload Identity Federation for GKE 的 GKE 叢集。

如果在啟用 Workload Identity Federation for GKE 的 GKE 叢集中，仍看到相同的錯誤，請確認您沒有忘記在叢集的節點集區中啟用 Workload Identity Federation for GKE。進一步瞭解如何在現有節點集區中啟用 Workload Identity Federation for GKE。建議您在所有叢集的節點集區中啟用 Workload Identity Federation for GKE，因為 Config Connector 可以在任何節點集區上執行。

403 Forbidden：呼叫端沒有權限；請參閱 GKE 適用的 Workload Identity Federation 說明文件

如果 Config Connector 資源顯示 UpdateFailed 狀態，並顯示訊息指出因 GKE 適用的工作負載身分聯盟而發生 403 錯誤，則表示 Config Connector 的 Kubernetes 服務帳戶缺少適當的 IAM 權限，無法以 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。進一步瞭解如何為專案範圍資源設定目標專案。

如果仍看到相同的錯誤，請檢查 GKE 叢集是否已啟用 Workload Identity Federation for GKE。

為日後減輕這類問題的影響，請務必按照設定連接器安裝操作說明操作。

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 連接器資源中管理的不可變更欄位。這會導致不可變動欄位的理想狀態與實際狀態不符。

您可以更新 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 1.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

如要解決這個問題，請刪除相關憑證和 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: test.example@example-project.iam
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 "test.example@example-project.iam" is invalid: metadata.name: Invalid value: "test.example@example-project.iam": 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: test.example@example-project.iam

這項設定會導致 Config Connector 使用 resourceID 而非 metadata.name 做為資源名稱。

無法從資源規格中移除欄位

從 Config Connector 資源的規格中移除欄位 (透過更新資源的 .yaml 檔案並重新套用，或使用 kubectl edit 編輯資源規格)，實際上並不會從 Config Connector 資源的規格或底層 Google Cloud 資源中移除該欄位。相反地，從規格中移除欄位只會讓該欄位由外部管理。

如果您想將欄位值變更為空白或基礎Google Cloud 資源中的預設值，就必須在 Config Connector 資源規格中將該欄位設為零：

  • 如為清單類型欄位，請使用 [] 將欄位設為空清單。

    以下範例顯示我們要移除的 targetServiceAccounts 欄位：

    spec:
  targetServiceAccounts:
    - external: "foo-bar@foo-project.iam.gserviceaccount.com"
    - external: "bar@foo-project.iam.gserviceaccount.com"

    如要移除這個欄位，請將值設為空白：

    spec:
  targetServiceAccounts: []

  • 對於基本類型欄位，請使用下列任一方法將欄位設為空白：

    類型 空白值
    字串 ""
    bool 「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 Connector 不會變更 Config Sync 中指定的欄位，但 Config Sync 會忽略未在 Config Sync 中指定，且由 Config Connector 預設的欄位。因此，對於大多數欄位，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 之前移除 Config Connector CRD 時。嘗試解除安裝時，會收到類似下列的錯誤訊息：

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 角色繫結。由於已刪除的服務帳戶會保留 60 天，因此 Google Cloud 角色繫結會保留 60 天。詳情請參閱 Google Cloud 有關「刪除服務帳戶」的 IAM 說明文件。

為避免發生這個問題，請務必在刪除參照的 IAMServiceAccount 之前，先清除 IAMPolicy、IAMPartialPolicy、IAMPolicyMember Config Connector 資源。

Config Connector 刪除的資源

Config Connector 絕不會在沒有外部原因的情況下刪除您的資源。舉例來說，執行 kubectl delete、使用 Argo CD 等設定管理工具，或使用自訂 API 用戶端，都可能導致資源遭到刪除。

常見的誤解是 Config Connector 已啟動並刪除叢集中的部分資源。舉例來說，如果您使用 Config Connector，可能會發現 Config Connector 控制器管理員針對容器記錄訊息或 Kubernetes 叢集稽核記錄中的特定資源提出刪除要求。這些刪除要求是外部觸發事件的結果，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 升級至新版本後，使用 PodSecurityPolicies 可能會導致 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 叢集中移除這些資源，可以刪除其finalizer 來強制刪除。

您可以使用 kubectl edit 編輯資源，刪除 metadata.finalizers 欄位，然後儲存檔案，保留對 Kubernetes API 伺服器所做的變更，藉此刪除資源的 finalizers。

由於刪除資源的 finalizers 可讓資源立即從 Kubernetes 叢集中刪除，Config Connector 可能 (但不一定) 無法刪除底層Google Cloud 資源。這表示您可能需要稍後手動刪除 Google Cloud 資源。

監控

指標

您可以使用 Prometheus 收集並顯示 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 支援團隊聯絡。