本頁面由 Cloud Translation API 翻譯而成。

對帳策略

使用陳述式設定時，您可以定義系統的所需狀態。系統會持續運作，盡可能維持這種狀態。詳情請參閱「使用設定檔以宣告方式管理 Kubernetes 物件」。

使用 Config Connector 時，您可以依任意順序建立及更新資源，不必考慮依附關係。GKE 會將您宣告的設定朝向最終一致性移動，達到所需狀態。

舉例來說，如果您在對應的 PubSubTopic 之前建立 PubSubSubscription，Config Connector 會等到主題建立完成，再建立相關聯的訂閱項目。

Config Connector 安裝作業保持不一致的時間長度，取決於其管理的資源數量和類型。GKE 叢集的變更通常會在幾秒內執行完畢。不過，建立Google Cloud 資源的時間可能會因資源類型而異。舉例來說，建立單一 PubSubTopic 只需要幾秒鐘。 Google Cloud資源建立完成後才會達到一致性。舉例來說，建立 SQLInstance 和 SQLDatabase 時，系統會在建立資料庫的幾分鐘內不一致。

GKE 和 Config Connector 會在每次更新或經過抖動期後，根據預先設定的預設間隔，以平均值協調各項資源。您可以在各資源的參考頁面中，找到「Config Connector Default Average Reconcile Interval In Seconds」(Config Connector 預設平均調解間隔 (以秒為單位))。如要查看各項資源的連結，請參閱「資源總覽」。如果調解時發生錯誤，Config Connector 會以指數輪詢方式重試，最長輪詢時間為兩分鐘。您可以查看特定資源的「事件」中的任何錯誤。

設定對帳間隔

從 Config Connector 1.102 版開始，您可以使用 cnrm.cloud.google.com/reconcile-interval-in-seconds 註解，為 Config Connector 管理的資源設定平均調解間隔。註解值會覆寫「Config Connector Default Average Reconcile Interval In Seconds」(Config Connector 預設平均調解間隔 (秒)) 的預設值，該值位於資源參考資料頁面。註解值應為非負整數，代表時間 (以秒為單位)。如果值設為 0，Config Connector 會在資源達到 UpToDate 狀態後，停止啟動資源的協調作業。

舉例來說，如果您希望 Config Connector 減少資源的協調次數，避免發生 Google Cloud API 配額問題，可以將平均協調間隔值設為 1 小時。

cnrm.cloud.google.com/reconcile-interval-in-seconds: "3600"

如要讓 Config Connector 更頻繁地調解資源，以便盡快修正漂移，您可以將註解設為較小的值。

您可以使用下列指令碼，為共用相同群組版本類別 (GVK) 的特定類型所有資源加上註解：

#!/bin/bash

KIND=RESOURCE_KIND
NAMESPACE=RESOURCE_NAMESPACE
ANNOTATION_KEY="cnrm.cloud.google.com/reconcile-interval-in-seconds"
ANNOTATION_VALUE=RECONCILE_INTERVAL

kubectl annotate --overwrite --all ${KIND} ${ANNOTATION_KEY}=${ANNOTATION_VALUE} -n ${NAMESPACE}
echo "Annotation added to all ${KIND} RESOURCE"

更改下列內容：

RESOURCE_KIND：要註解的資源種類。
RESOURCE_NAMESPACE：包含要註解資源的命名空間。
RECONCILE_INTERVAL：以秒為單位的協調間隔。

您可以將對帳間隔設為 0，停用資源的漂移修正功能，但這不會停用資源啟動。如果您變更資源 Spec，系統會再次比對資源。

將對帳間隔設為 0 後就無法復原。也就是說，即使將值改回非零數字，Config Connector 也不會再次協調資源。

如要還原 0 調解間隔，請使用下列選項：

使用協調間隔值修改資源規格，啟用新的協調作業。
設定註解 cnrm.cloud.google.com/deletion-policy: "abandon" 即可放棄資源，然後以 0 以外的和解間隔值重新建立資源。

可變更但無法讀取的欄位只會在變更時啟動

部分 API 會公開無法讀取但可變動的欄位 (例如 SQL 使用者的密碼)。由於系統無法判斷這些欄位是否已修改，因此只有在修改自訂資源時，才會更新可變更但無法讀取的欄位。

修改不可變更的欄位時，系統不會重新建立資源

資源中的部分欄位不可變動，如要進行協調，必須先刪除目標資源，然後重新建立。

在這些情況下，Config Connector 會為資源發出「UpdatedFailed」Kubernetes 事件，而不是執行這項重新建立作業。然後刪除並重新建立資源。

範例事件：

Warning  UpdateFailed  37m (x643 over 15d)    computeinstance-controller  Update call failed: the desired mutation for the following field(s) is invalid: [bootDisk.0.InitializeParams.0.Image networkInterface.0.NetworkIp]