Config Controller 分片指南

本文提供相關建議，說明如何將 Config Controller 用量分片。分片是指將 Config Controller 管理的 Google Cloud 資源分散到多個命名空間、叢集或專案的程序。

分片具有下列優點：

  • 減少變更的影響：如果單一分片停止運作，其他分片不會受到影響。
  • 協助您管理安全性：每個分片都可以有專屬的 IAM 和 RBAC 設定。惡意攻擊者即使入侵某個分片，也無法存取其他分片。一個分片的設定錯誤不會影響其他分片。
  • 提升擴充性：單一分片可能會有擴充性瓶頸，例如受管理物件的數量或 API 配額。多個分片可提高 Config Controller 使用的整體擴充性。

搭配 Config Controller 使用分片

實作分片的做法有很多種，最適合的做法取決於您的特定需求和要求。

模型分片

主要有兩種分片模型：

  • 依業務線或應用程式團隊：如果不同團隊使用 Config Controller，通常會採用這個模型。在這個模型中，每個團隊都有自己的分片。
  • 依環境：如果 Config Controller 用於不同環境，通常會使用這個模型。舉例來說，您可能會有開發環境的分片、QA 環境的分片，以及實際工作環境的分片。

盡可能減少跨分片參照的需求

對 Config Controller 用量進行分片時，應盡量減少跨分片參照的需求。跨分片參照可能會使設定更加複雜，難以管理。詳情請參閱「跨執行個體的資源參照」。

分片機制

主要有三種分片機制：

  • 依命名空間：您可以建立其他命名空間，並設定 Config Connector 來管理這些命名空間中的資源。
  • 透過 Config Controller 執行個體：您可以在一個 Google Cloud 專案中建立多個 Config Controller 執行個體。
  • 依專案：您可以在多個 Google Cloud 專案中建立多個 Config Controller 執行個體。如果您在單一專案中遇到配額瓶頸，這個機制有助於解決 API 配額問題。詳情請參閱「將資源分割成多個專案」。

實作分片時的注意事項

為 Config Controller 用途實作分片時，您應留意並規劃緩解措施，以因應一些潛在問題。

跨執行個體的資源參照

對 Config Controller 進行分片的挑戰之一，是處理執行個體間的資源參照。舉例來說，平台團隊可能會在一個執行個體中建立專案，然後應用程式團隊可能會在其他執行個體中建立參照這些專案的資源。這可能會造成下列問題：

  • 複雜度提高：管理跨叢集的資源參照可能會使設定更複雜，難以管理。
  • 風險提高：如果某個分片中的資源遭到刪除，其他分片的資源仍可參照該資源。這可能會導致非預期的行為和資料遺失。
  • 效能降低：跨叢集的資源參照可能會增加設定變更的延遲時間。

您可以透過下列幾種方式解決交互參照問題：

  • 以不需要跨資料分割參照的方式進行分片。這項作業可透過依環境或團隊分片來完成。
  • 使用外部參照。這表示所參照的物件實際上並非由 Config Controller 管理。如果物件不常變更，這會是不錯的選擇。
  • 在所有分片中提供相同的物件。這個選項較為複雜，但如果物件經常變更，這可能是最佳選擇。物件應共用相同的真實資訊來源，避免不同分片中的物件發生對帳衝突。您需要將這些物件的衝突預防政策設為 none。

選擇方法前，請務必仔細考量各種方法的優缺點。

API 配額

分片可能會增加 API 配額。請注意這一點，並據此規劃。如需管理 API 配額限制的最佳做法，請參閱「管理 API 配額限制」。

後續步驟