代管控制層

<0x0

本文說明已淘汰的 ISTIOD 控制層實作方式與 Google 現代 TRAFFIC_DIRECTOR 控制層實作方式的架構差異，並列出叢集仍使用已淘汰控制層時的後續步驟。

控制層總覽

在服務網格中，控制層提供流量管理、使用 Envoy Proxy 時的 Proxy 管理，以及其他網路功能。

在 GKE 叢集上使用 Istio API 的 Cloud Service Mesh，可提供Istio API 的完整支援實作。這些 API 由全代管的 Cloud Networking 整合式 TRAFFIC_DIRECTOR 控制層實作及支援。先前支援兩種額外的控制平面實作方式：

  • 已淘汰的代管ISTIOD實作，會執行單一叢集專屬的控制層。
  • 已淘汰的叢集內 ISTIOD 實作，會在叢集內執行客戶管理的控制層元件。

TRAFFIC_DIRECTOR 控制層的運作特性

採用 TRAFFIC_DIRECTOR 控制層的 Cloud Service Mesh 會使用 Google Cloud的代管網路基礎架構，而非每個叢集的控制層執行個體。

傳送至 Envoy Sidecar 的 Istio API (CRD) 和 xDS 設定仍可相容，但您應預期會出現下列運作特性：

  • 政策和服務設定傳播：建立新服務或更新路由和安全政策時，系統會先驗證設定，並在 Google Cloud 系統間傳播，然後才會在 Sidecar 上生效。因此，與叢內或 ISTIOD 控制層相比，初始政策和服務傳播所需時間較長。如要瞭解如何最佳化部署工作流程，請參閱「設定傳播」。
  • Pod 調整資源配置和端點更新：工作負載端點的變更 (例如水平自動調度 Pod 資源建立的新 Pod，或以新 IP 位址重新啟動的 Pod) 會由控制層直接傳播，不會發生與政策更新相關的延遲。現有 Pod 會立即開始擷取現有設定。
  • 多叢集端點探索：在多叢集網格中，叢集會直接透過 Google Cloud 共用端點，而不是在每種叢集組合之間逐一同步端點。這可確保網格擴充時，跨叢集端點狀態能更快且更一致地匯聚。

這會對您造成什麼影響？

後續步驟取決於叢集使用的 Cloud Service Mesh 控制層實作方式：

透過 ISTIOD 實作，為代管 Cloud Service Mesh 進行控制層現代化

所有執行已淘汰 ISTIOD 實作方式的受管理車隊，都必須在淘汰通知中指定的支援終止期限前，完成現代化作業並改用 TRAFFIC_DIRECTOR 實作方式。您可以透過客戶觸發的現代化 (建議用於叢集控制和分階段流量轉移)，或由 Google 驅動的現代化 (自動推出適用於符合資格的機群)，更新機群。

如需逐步操作說明，請參閱「Managed control plane modernization」。

檢查控制層相容性

如要根據支援的功能評估機群，並在現代化前找出設定阻礙，請參閱：

附錄：控制層推出和淘汰時間表

從 ISTIOD 控制層轉換為受管理控制層實作的時程如下：TRAFFIC_DIRECTOR

  • 2024 年 5 月 23 日：Anthos 服務網格和 Traffic Director 已整合成 Cloud Service Mesh，並推出 Istio API 的 TRAFFIC_DIRECTOR 控制層實作。
  • 2024 年 7 月 1 日：加入代管 Cloud Service Mesh 的新車隊，預設會開始接收 TRAFFIC_DIRECTOR 實作項目。
  • 2024 年 9 月 8 日：新機群的ISTIOD實作作業已結束正式發布 (許可清單中的特定機構暫時除外狀況)。
  • 2026 年 9 月 28 日：正式宣布淘汰受管理 ISTIOD 控制層實作項目，以及 GKE 上的叢內控制層。