本頁面說明在運作高可用性服務或管理多個 Google Cloud 區域中的資源時，如何充分運用 Config Controller。
本頁面適用於管理基礎技術基礎架構生命週期，以及規劃容量和基礎架構需求的管理員、架構師和營運人員。如要進一步瞭解我們在 Google Cloud 內容中提及的常見角色和範例工作，請參閱「常見的 GKE Enterprise 使用者角色和工作」。
Config Controller 會在單一區域中執行，因此可以容許可用區發生故障，但如果整個區域發生故障，Config Controller 就會失去可用性。有兩種不同的策略可處理區域性故障，選擇哪種策略取決於區域發生故障時的因應方式：
如要因應區域性故障而變更設定，請建立第二個 Config Controller 執行個體。
如果您不會變更設定，請使用單一 Config Controller 執行個體。
瞭解失敗情境
Config Controller 會使用區域性 GKE 叢集。雖然區域叢集可以容許區域中單一可用區發生故障，但如果區域中的多個可用區發生故障，叢集就會無法使用。
如果 Config Controller 執行個體發生故障，現有 Google Cloud資源會維持目前狀態。不過，即使應用程式仍在執行，您也無法在 Config Controller 無法使用時變更其設定。這適用於同一區域的資源，以及您從無法使用的區域中，透過 Config Controller 管理的其他區域資源。
由於您無法在同一個區域中重新設定資源，如果區域性故障確實影響 Config Controller 區域中的現有 Google Cloud 資源，您就無法修復這些資源。
由於您也無法重新設定其他區域的資源，因此一個區域發生故障，現在會影響您在另一個區域進行變更的能力。
也可能發生其他失敗情況。舉例來說，如果您將 Config Sync 設定為從外部 Git 供應商提取資料，就應考量該 Git 供應商的故障模式。您可能無法變更設定，因為無法將變更推送至該 Git 供應商。或者，如果 Config Sync 無法從 Git 讀取資料，任何 Git 變更都不會套用至叢集，因此 Config Connector 也不會套用這些變更。不過，區域性故障通常是最重要的故障情境，因為其他故障情境通常與 Config Controller 故障無關。
使用單一叢集確保區域可用性
在許多情況下，如果某個區域發生故障，您不需要執行任何重新設定。在這種情況下，您可能會選擇接受區域故障導致設定控制層無法使用的情況。
舉例來說，如果您只在單一區域運作，該區域發生故障時，可能無法進行任何有用的重新設定。同樣地，如果您在單一區域中擁有單點故障資料庫，可能要等到該區域恢復運作，才能進行復原。對於不需要絕對最高可用性的應用程式，這種情況可以合理地在成本和複雜度之間取得平衡。
在相同區域中找到 Config Controller 執行個體，可讓您共用命運：只要主要區域可用，Config Controller 就能使用。在不同區域中尋找 Config Controller 執行個體也是不錯的選擇；雖然您現在必須考慮兩個區域中可能發生的故障，但可以避免設定控制平面與主要區域故障相關的故障。
或者，如果您有多區域備援設定，系統可能會自動避開發生故障的區域。同樣地，如果某個區域發生故障，您可能也不想重新設定。在這種情況下，您可能會選擇單一 Config Controller 執行個體。
手動容錯移轉至第二個 Config Controller 執行個體
如果區域發生故障，您可能需要重新設定，才能修正故障問題。即使 Config Controller 執行個體位於失敗的區域，您可能也想繼續在其他區域中設定資源。在這種情況下，建議在第二個區域使用第二個 Config Controller 執行個體。
雖然不建議這麼做，但兩個 Config Controller 執行個體可以採用相同的設定。兩個執行個體會爭相從同一個 Git 存放區讀取資料，並將相同的變更套用至 Google Cloud。不過，由於有許多極端情況，這項設定並不可靠。這兩個 Config Controller 執行個體會稍微錯開時間觀察 Git 存放區，因此可能會嘗試套用略有不同的 Google Cloud 設定版本。多個有效寫入者， Google Cloud 更容易達到配額或速率限制。少數 Config Connector 資源也不是等冪，需要特別注意，詳情請參閱本節其餘內容。因此，我們不建議讓兩個 Config Controller 叢集同時主動進行協調。
如果執行 Config Controller 的區域發生故障，建議您在第二個區域執行另一個 Config Controller。新的 Config Controller 執行個體應與第一個執行個體設定相同，並從同一個 Git 存放區讀取資料。在這種情況下，預先準備好指令碼，以啟動及設定 Config Controller 執行個體，可能會很有幫助。建立新的 Config Controller 執行個體時，Config Sync 會從 Git 讀取所需狀態並套用至 Kubernetes；Config Connector 則會將所需狀態同步至 Google Cloud。
在這種情況下，請注意以下兩件事：
如果第一個 Config Controller 叢集仍在執行，或在第一個區域復原時開始執行，則可能會嘗試將舊狀態套用至 Google Cloud。如果您可以在啟動第二個 Config Controller 叢集之前，停止第一個區域中的 Config Controller 叢集，就能避免這個潛在衝突。
並非所有 Config Connector 資源都能從 Git 無縫重新套用。 如需需要特別注意的資源清單，請參閱取得限制相關資源。 我們特別建議您謹慎使用
Folder資源，並避免使用IAMServiceAccountKey資源 (例如改用 GKE 適用的 Workload Identity 聯盟)。
每個區域一個 Config Controller 執行個體
如要避免某個區域的 Config Controller 執行個體影響其他區域，您也可以考慮為每個區域執行一個 Config Controller 執行個體，讓每個執行個體管理該區域的資源。
這種設定方式可行，但我們不建議採用，原因如下：
部分資源會跨越多個區域 (例如 Cloud DNS)，因此這項策略的適用範圍有限。
一般來說，如果 Config Controller 叢集位於同一區域，就會遇到相關失敗問題：當區域性故障影響該區域的 Config Controller 時，您會想要重新設定資源。
您必須依區域分割 Config Connector 資源。
Config Controller 目前僅在部分地區推出。
直接設定 Google Cloud 資源
在特殊情況下，您可能會直接變更基礎 Google Cloud 資源，而不透過 Git 或 Config Connector。Config Connector 會嘗試修正任何「漂移」問題，因此如果 Config Controller 執行個體仍在執行，Config Connector 會將您手動進行的任何變更視為「漂移」，並嘗試還原這些變更。
不過，如果您停止 Config Controller 執行個體，或區域離線，這項措施就很有用。
Config Controller 執行個體復原後，Config Connector 可能會嘗試還原您手動變更的內容。為避免這種情況，您可以針對手動進行的任何變更，在 Git 中做出相應變更。