協調策略

使用宣告式設定時，您會定義系統的理想狀態。接著，系統會持續運作，盡可能維持在這個狀態。詳情請參閱「使用設定檔以宣告方式管理 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 會以指數輪詢方式重試，最長輪詢時間為 2 分鐘。如果是直接控制器管理的資源，您可以使用 cnrm.cloud.google.com/backoff-max-delay-in-seconds 註解設定這項上限。您可以在特定資源的「Events」(事件) 中查看任何錯誤。

設定協調間隔

從 Config Connector 1.102 開始，您可以使用 cnrm.cloud.google.com/reconcile-interval-in-seconds 註解，設定 Config Connector 管理資源的平均協調間隔。註解的值會覆寫資源參考頁面中「Config Connector Default Average Reconcile Interval In Seconds」的預設值。註解的值應為非負整數，代表時間 (以秒為單位)。如果值設為 0，Config Connector 會在資源達到 UpToDate 狀態後，停止啟動資源協調。這項註解可控制資源達到 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 的協調間隔值重新建立資源。

設定指數輪詢，處理對帳錯誤

如果資源無法協調，Config Connector 會使用指數輪詢重試協調。延遲時間從 250 毫秒開始，每次嘗試失敗後會加倍 (例如 500 毫秒、1 秒、2 秒)，預設上限為 2 分鐘。

cnrm.cloud.google.com/reconcile-interval-in-seconds 註解會控制資源達到 UpToDate 狀態後的定期偏移校正。在 Config Connector 1.160.0 以上版本中，您可以使用 cnrm.cloud.google.com/backoff-max-delay-in-seconds 註解，控管協調失敗時的重試行為。將註解設為下列其中一個值：

  • 正整數 ("1" 以上)：設定重試之間的延遲時間上限 (以秒為單位)。舉例來說，"600" 會將重試間隔上限設為 10 分鐘，"3600" 則會設為 1 小時。
  • "0"：在對帳失敗後停止自動重試。資源會維持在失敗狀態，直到變更觸發協調程序為止，例如更新 spec、metadata.labels、metadata.annotations、參照的資源或 Secret。

舉例來說，如要將重試間隔上限設為 30 分鐘，並減少失敗資源的 Google Cloud API 配額用量，請新增下列註解：

metadata:
  annotations:
    cnrm.cloud.google.com/backoff-max-delay-in-seconds: "1800"

如要停止自動重試協調錯誤，直到您更新資源為止，請新增下列註解：

metadata:
  annotations:
    cnrm.cloud.google.com/backoff-max-delay-in-seconds: "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]