Config Sync 已知問題

本頁列出支援的 Config Sync 版本已知問題。

這裡列出的許多問題都已修正。「修正版本」欄會指出導入修正措施的版本。如要取得這項修正，請升級至列出的版本或更新版本。

如果您是 Google Developer Program 成員，請儲存這個頁面，以便在發布與這個頁面相關的版本資訊時收到通知。詳情請參閱「儲存的頁面」。

如要依產品版本或問題類別篩選已知問題，請從下列下拉式選單中選取篩選條件。

選取 Config Sync 版本：

選取問題類別：

或者，篩選已知問題：

類別 已識別版本 已修正的版本 問題和解決方法
元件健康狀態 1.24.0

在 Hub 遷移的叢集上，升級至 1.24.0 版時，Config Sync Pod 會停止運作

升級至 Config Sync 1.24.0 後，已移除的欄位 (例如 readinessProbe 和 otel-agent Sidecar 的健康狀態檢查) 可能會保留在已遷移至 Hub 管理的叢集上。由於 readinessProbe 後方的健康狀態檢查元件已移除，otel-agent 容器無法啟動，導致 Config Sync Pod 停滯。

只有先前使用 kubectl 手動安裝 Config Sync，後來改用中樞叢集管理的叢集會受到影響。這是因為遷移程序處理欄位管理的方式，與新安裝程序不同。如果是手動安裝的叢集，或是最初由 Hub 安裝的叢集，系統會如預期移除這些欄位。

解決方法：

如要解決這個問題，請按照指示解除安裝 Config Sync，然後透過 Hub 重新安裝 Config Sync。
指標 1.5.0 1.21.0

已修正：系統會為已刪除的套件回報指標

如果您刪除 RootSync 或 RepoSync 物件，但未刪除同名的 ResourceGroup 物件，Config Sync 會繼續回報該 ResourceGroup 物件的下列指標：

  • rg_reconcile_duration_seconds
  • resource_group_total
  • resource_count
  • ready_resource_count
  • resource_ns_count
  • cluster_scoped_resource_count
  • crd_count
  • kcc_resource_count
  • pipeline_error_observed
只有在刪除 RootSync 或 RepoSync 物件前啟用刪除作業傳播，ResourceGroup 物件才會自動刪除。

解決方法：

刪除 ResourceGroup 物件：

kubectl delete resourcegroup RESOURCE_GROUP_NAME -n config-management-system

將 RESOURCE_GROUP_NAME 替換為要刪除的 ResourceGroup 物件名稱。如要進一步瞭解命名方式，請參閱「ResourceGroupResourceGroup 控制器和 ResourceGroup 物件」。
元件健康狀態 1.15.0

無法排定協調器

Config Sync 調解器需要不同數量的資源，具體取決於 RootSync 或 RepoSync 的設定。某些設定需要的資源比其他設定多。

如果無法排定協調器，可能是因為要求的資源超出節點可用資源。

如果您使用標準模式 GKE 叢集，協調器資源要求會設得很低。我們選擇這項設定，是為了盡可能允許排程，即使這會導致節流和效能緩慢，也要讓 Config Sync 在小型叢集和小型節點上運作。不過，在 GKE Autopilot 叢集上，協調器要求會設得較高，以便在同步處理時更如實地呈現用量。

解決方法：

啟用自動佈建節點功能的 GKE Autopilot 或標準叢集，應能查看要求的資源數量，並建立適當大小的節點以利排程。不過，如果您是手動設定節點或節點執行個體大小，可能需要調整這些設定，以符合協調器 Pod 的資源需求。
指標 1.15.0

匯出失敗，權限遭拒

根據預設，當 reconciler-manager 偵測到應用程式預設憑證時，otel-collector 會設定為將指標匯出至 Prometheus、Cloud Monitoring 和 Monarch。

解決方法：

如果尚未設定 Cloud Monitoring 或自訂指標篩選器和 Cloud Monarch，otel-collector 會記錄錯誤。
指標 1.15.0

otel-collector 發生當機，且使用自訂設定

如果您嘗試修改或刪除其中一個預設 ConfigMap (otel-collector 或 otel-collector-google-cloud)，otel-collector 可能會因無法載入必要 ConfigMap 而發生錯誤或當機。

解決方法：

如要自訂指標匯出設定，請在 config-management-monitoring 命名空間中建立名為 otel-collector-custom 的 ConfigMap。
修復

Config Sync 互相衝突

Config Sync 可能會出現控制器爭用的情況。與自身進行比較。如果在 Git 存放區中為資源的選用欄位設定預設值，就會發生這個問題。舉例來說，為 RoleBinding 的主體設定 apiGroup: "" 會觸發這項作業，因為 apiGroup 欄位為選填，而空白字串是預設值。字串、布林值和整數字段的預設值分別為 ""、false 和 0。

解決方法：

從資源宣告中移除該欄位。
修復

Config Sync 與 Config Connector 資源發生衝突

Config Sync 可能會與 Config Connector 爭奪資源的控制權，例如 StorageBucket。如果未在單一事實來源中設定資源 spec.lifecycleRule.condition.withState 的選填欄位值，就會發生這個問題。

解決方法：

如要避免這個問題，請在資源宣告中加入 withState=ANY 欄位。或者，您也可以放棄並重新取得具有 cnrm.cloud.google.com/state-into-spec: absent 註解的資源。
可靠資料來源 1.20.0 1.21.3

Git 鎖定檔案成為孤立檔案後，git-sync 容器會進入當機迴圈

如果 git-sync 容器發生當機迴圈，且 git-sync 容器記錄檔中出現類似下列內容的錯誤，可能是先前的 git 叫用作業失敗，並在容器中留下孤立的鎖定檔案：

    {"logger":""..."msg":"repo contains lock file","error":null,"path":"/repo/source/.git/shallow.lock"}
    ...runtime error: invalid memory address or nil pointer dereference

解決方法：

如要解決這個問題，請重新啟動受影響的協調器 Pod，為其提供新的暫時性磁碟區：

    kubectl delete pod -n config-management-system RECONCILER_NAME
將 RECONCILER_NAME 替換為 RootSync 或 RepoSync 物件的協調器名稱。
同步處理 1.7.0 1.21.0

已修正：系統未遵守突變註解

Config Sync 調解器中的錯誤會導致即使存在 client.lifecycle.config.k8s.io/mutation 註解，系統仍會套用宣告設定中的變更。這可能會導致叢集中的物件狀態遭到覆寫。

解決方法：

您可以新增 configmanagement.gke.io/managed: disabled 註解，停止管理受管理物件。不過，如果停用管理功能，Config Sync 就不會在物件從叢集刪除後重新建立。此外，系統也不會再套用來源的更新。
同步處理 1.15.0

稽核記錄中無效的 PATCH 請求數量偏高

Config Sync 修正工具會使用模擬執行來偵測偏移。這可能會導致稽核記錄中顯示 PATCH 要求，即使 PATCH 未保留也一樣，因為稽核記錄不會區分試執行和一般要求。

解決方法：

由於稽核記錄無法區分試執行和非試執行要求，因此您可以忽略 PATCH 要求。
同步處理 1.7.0 1.21.0

已修正：無法將更新後的目錄寫入叢集

如果 Config Sync 無法更新 ResourceGroup 物件的狀態，調解器記錄中可能會出現類似下列的間歇性錯誤：

    KNV2009: task failed (action: "Inventory", name: "inventory-set-0"): failed to write updated inventory to cluster: Operation cannot be fulfilled on resourcegroups.kpt.dev "root-sync": the object has been modified; please apply your changes to the latest version and try again

這項錯誤是因調解器與 ResourceGroup 控制器之間的競爭狀況所致。ResourceGroup 控制器可能會在調解器更新 ResourceGroup 規格之前，先更新 ResourceGroup 狀態，導致 KNV2009 錯誤。

解決方法：

這個問題沒有解決方法。錯誤應會自動解決。
Terraform Terraform 5.41.0 版

無法使用 Terraform 安裝或升級 Config Sync

Terraform 5.41.0 版在 google_gke_hub_feature_membership 資源中導入了新欄位：config_sync.enabled。由於這個欄位的預設值為 false，如果未明確將這個欄位設為 true，使用 Terraform 5.41.0 以上版本時，Config Sync 安裝或升級作業就會失敗。如果發生這個問題，您也可能會看到 git spec not included in configmanagement spec 錯誤訊息。

解決方法：

  • 如果您使用 google_gke_hub_feature_membership 資源，請手動將 config_sync.enabled 設為 true。
  • 如果您使用 acm 子模組，建議改用其他方式安裝 Config Sync。 如果無法切換，請升級至 v33.0.0。
Google Cloud 控制台

Config Sync 資訊主頁在 Google Cloud 控制台中缺少資料錯誤

在 Google Cloud 控制台的資訊主頁上，您可能會看到 Config Sync 叢集的錯誤，例如「缺少資料」或「叢集憑證無效」。如果未登入 GDC (VMware) 或 GDC (裸機) 集群，就可能發生這個問題。

解決方法：

如果在 GDC (VMware) 或 GDC (裸機) 叢集的控制台中看到這類錯誤，請確認您已透過 GKE 身分認證服務 或連結閘道登入叢集。 Google Cloud

同步處理 1.21.0

已修正：Config Sync 會阻止更新已捨棄的資源

在 1.21.0 版之前，刪除 RootSync 或 RepoSync 物件可能會留下多個 標籤和註解，Config Sync 會使用這些標籤和註解追蹤資源物件。

刪除 RootSync 或 RepoSync 物件後，這些標籤和註解可能會導致下列副作用：

  • 其他 RepoSync 物件無法接管先前管理的物件。
  • 如果啟用偏移防止功能，Config Sync 可能會拒絕變更已捨棄的資源。
nomos 指令列工具 1.17.0

nomos CLI 不支援 oidc 驗證外掛程式

使用 nomos 指令列工具時，您可能會看到 no Auth Provider found for name "oidc" 等錯誤。使用 oidc 驗證外掛程式時，可能會發生這個問題。

解決方法：

目前沒有解決方法。我們會在後續版本中重新加入 oidc 驗證外掛程式。

返回頁首

後續步驟

  • 如果無法在文件中找到問題的解決方案，請參閱「取得支援」，瞭解如何取得進一步協助，包括下列主題的建議：