Cloud Service Mesh 總覽

本文件適用於想熟悉 Cloud Service Mesh 及其功能的網路管理員和服務擁有者。這是一份舊版文件,適用於使用負載平衡 API 的設定。

Cloud Service Mesh 是應用程式網路的代管控制層。Cloud Service Mesh 可讓您透過流量管理和可觀察性等進階應用程式網路功能,提供全球高可用性的服務。

隨著部署中的服務和微服務數量增加,您通常會開始遇到常見的應用程式網路挑戰,例如:

  • 如何讓服務具備復原能力?
  • 如何為服務吸引流量?服務如何相互認識並進行溝通?
  • 如何瞭解服務彼此通訊時發生的情況?
  • 如何更新服務,避免服務中斷?
  • 如何管理可讓我部署作業順利進行的基礎架構?
服務需要彼此通訊。
服務需要彼此溝通 (按一下可放大)

Cloud Service Mesh 可協助您在以服務為基礎的現代部署中解決這類問題。Cloud Service Mesh 會使用由 Google Cloud代管的基礎架構,因此您不必自行管理基礎架構。您可以專注於發布可解決業務問題的應用程式程式碼,同時讓 Cloud Service Mesh 管理應用程式網路的複雜性。

Cloud Service Mesh

解決應用程式網路問題的常見模式是使用服務網格。Cloud Service Mesh 支援服務網格和其他符合需求的部署模式。

典型的服務網格。
一般服務網格 (按一下可放大)

在典型的服務中介中,下列情況為真:

  • 將服務部署至 Kubernetes 叢集。
  • 每個服務的 Pod 都有專屬 Proxy (通常是 Envoy),用於執行 補充 Proxy
  • 每個附加元件 Proxy 都會與叢集中安裝的網路基礎架構 (控制層) 通訊。控制層會告知附加元件 Proxy 服務網格中的服務、端點和政策。
  • 當 Pod 傳送或接收要求時,要求會傳送至 Pod 的側邊 Proxy。側邊 Proxy 會處理要求,例如將要求傳送至預期目的地。

在本文件和其他 Cloud Service Mesh 文件的圖表中,六邊形粉紅色圖示代表 Proxy。控制層會連結至每個 Proxy,並提供 Proxy 處理要求所需的資訊。方塊之間的箭頭代表流量流向。例如,Service A 中的應用程式程式碼會傳送要求。Proxy 會處理要求並轉送至 Service B

這個模型可讓您將網路邏輯移出應用程式程式碼。您可以專注於提供商業價值,同時讓基礎架構負責處理應用程式網路。

Cloud Service Mesh 的不同之處

Cloud Service Mesh 的運作方式與該模型類似,但在某些重要方面有所不同。這一切都源自於 Cloud Service Mesh 是Google Cloud代管服務。您不需要安裝,也不需要在叢集中執行,也不需要維護。

在下圖中,Cloud Service Mesh 是控制層。這個 Kubernetes 叢集中有四項服務,每項服務都有連結至 Cloud Service Mesh 的補充 Proxy。Cloud Service Mesh 會提供代理程式需要的資訊,以便將要求路由。舉例來說,屬於 Service A 的 Pod 上的應用程式程式碼會傳送要求。與此 Pod 一併執行的附加 Proxy 會處理要求,並將其轉送至屬於 Service B 的 Pod。

採用 Cloud Service Mesh 的服務網格範例。
使用 Cloud Service Mesh 的服務網狀結構範例 (按一下可放大)

服務網格以外

Cloud Service Mesh 支援的部署類型比一般服務網格更多。

多叢集 Kubernetes

透過 Cloud Service Mesh,您可以取得可在 Kubernetes 叢集中運作的應用程式網路。在下圖中,Cloud Service Mesh 為 us-central1europe-west1 中的 Kubernetes 叢集提供控制層。要求可在 us-central1 中的三個服務之間、europe-west1 中的兩個服務之間,以及兩個叢集中的服務之間轉送。

採用 Cloud Service Mesh 的多叢集 Kubernetes 範例。
使用 Cloud Service Mesh 的多叢集 Kubernetes 示例 (按一下可放大)

服務網格可跨多個Google Cloud 區域的多個 Kubernetes 叢集擴展。一個叢集中的服務可以與另一個叢集中的服務通訊。甚至可以讓服務由多個叢集中的 Pod 組成。

透過 Cloud Service Mesh 的以距離為準全球負載平衡功能,Service B 的目標要求會傳送至最近的 Pod,以便處理要求。您還可獲得無縫容錯功能;如果 Pod 發生故障,要求會自動移轉至可提供要求的其他 Pod,即使這個 Pod 位於不同的 Kubernetes 叢集中也一樣。

虛擬機器

Kubernetes 越來越受歡迎,但許多工作負載都部署至虛擬機器 (VM) 執行個體。Cloud Service Mesh 也能為這些工作負載解決應用程式網路問題;VM 型工作負載可與 Kubernetes 型工作負載互通。

在下圖中,流量會透過外部應用程式負載平衡器進入部署作業。會路由至 asia-southeast1 中 Kubernetes 叢集的 Service A,以及 europe-west1 中 VM 的 Service D

使用 Cloud Service Mesh 的 VM 和 Kubernetes 範例。
VM 和 Kubernetes 搭配 Cloud Service Mesh 的示例 (按一下可放大)

Google 提供無縫機制,可透過 Cloud Service Mesh 設定 VM 型工作負載。您只需在 Compute Engine VM 執行個體範本中新增標記,Google 就會負責基礎架構設定。這項設定包括安裝及設定可提供應用程式網路功能的 Proxy。

無 Proxy gRPC

gRPC 是一款功能豐富的開放原始碼 RPC 架構,可用於編寫高效能微服務。有了 Cloud Service Mesh,您就能為 gRPC 應用程式提供應用程式網路功能 (例如服務探索、負載平衡和流量管理)。詳情請參閱「Cloud Service Mesh 和 gRPC:服務網格無 Proxy 服務」。

在下圖中,gRPC 應用程式會將流量轉送至某個區域的 Kubernetes 叢集中的服務,以及在不同區域的 VM 上執行的服務。其中兩項服務包含附屬 Proxy,其他則是無 Proxy。

使用 Cloud Service Mesh 的無 Proxy gRPC 應用程式範例。
使用 Cloud Service Mesh 的無 Proxy gRPC 應用程式範例 (按一下可放大)

Cloud Service Mesh 支援無 Proxy gRPC 服務。這些服務使用支援 xDS API 的最新版開放原始碼 gRPC 程式庫。gRPC 應用程式可使用 Envoy 使用的相同 xDS API 連線至 Cloud Service Mesh。

應用程式連線後,gRPC 程式庫會負責應用程式網路功能,例如服務探索、負載平衡和流量管理。這些函式會在 gRPC 中原生發生,因此不需要服務 Proxy,這也是為什麼稱為無 Proxy gRPC 應用程式的原因。

Ingress 和閘道

在許多用途中,您需要處理來自未由 Cloud Service Mesh 設定的用戶端的流量。舉例來說,您可能需要將公開網際網路流量導入至微服務。您也可以將負載平衡器設為反向 Proxy,以便在將流量傳送至目的地之前,先處理來自用戶端的流量。

在下圖中,外部應用程式負載平衡器可為外部用戶端啟用輸入,並將流量路由至 Kubernetes 叢集中的服務。內部應用程式負載平衡器會將內部流量轉送至在 VM 上執行的服務。

搭配 Cloud Load Balancing 的 Cloud Service Mesh,用於入站。
Cloud Service Mesh 搭配 Cloud Load Balancing 的入站機制 (按一下可放大)

Cloud Service Mesh 可與 Cloud Load Balancing 搭配使用,提供受控的入口體驗。您可以設定外部或內部負載平衡器,然後設定該負載平衡器,將流量傳送至微服務。在上述圖表中,公用網際網路用戶端會透過外部應用程式負載平衡器存取您的服務。用戶端 (例如位於虛擬私有雲 (VPC) 網路中的微服務) 會使用內部應用程式負載平衡器存取您的服務。

在某些用途中,您可能會想設定 Cloud Service Mesh 來設定閘道。閘道基本上是反向 Proxy,通常是執行在一或多個 VM 上的 Envoy,會監聽傳入要求、處理這些要求,並將要求傳送至目的地。目的地可以位於任何 Google Cloud 區域或 Google Kubernetes Engine (GKE) 叢集中。甚至可以是Google Cloud 以外的目的地,只要使用混合式連線,即可從 Google Cloud 存取。如要進一步瞭解何時使用閘道,請參閱「網格區塊的入站流量」。

在下圖中,europe-west1 區域中的 VM 會執行代理程式,該代理程式會充當三個未執行代理程式的服務的閘道。外部應用程式負載平衡器和內部應用程式負載平衡器的流量都會先傳送至閘道,然後再傳送至三項服務。

用於設定閘道的 Cloud Service Mesh。
用於設定閘道的 Cloud Service Mesh (按一下可放大)

多個環境

無論您在 Google Cloud、內部部署環境、其他雲端或所有這些環境中使用服務,基本應用程式網路問題都會一如往常。您如何為這些服務吸引流量?這些服務如何互相通訊?

在下圖中,Cloud Service Mesh 會將從在 Google Cloud 執行的服務轉送的流量,轉送至在其他公有雲執行的 Service G,以及在內部部署資料中心執行的 Service EService FService AService BService C 使用 Envoy 做為補充 Proxy,而 Service D 則是無 Proxy gRPC 服務。

用於跨環境通訊的 Cloud Service Mesh。
用於跨環境通訊的 Cloud Service Mesh (按一下可放大)

使用 Cloud Service Mesh 時,您可以將要求傳送至Google Cloud以外的目的地。這樣一來,您就能使用 Cloud Interconnect 或 Cloud VPN,將來自 Google Cloud 內部服務的流量私密地路由至其他環境中的服務或閘道。

設定 Cloud Service Mesh

設定 Cloud Service Mesh 包含兩個步驟。完成設定程序後,基礎架構會處理應用程式網路連線,而 Cloud Service Mesh 會根據部署作業的變更,讓一切保持最新狀態。

部署應用程式

首先,您需要將應用程式程式碼部署至容器或 VM。Google 提供機制,可讓您將應用程式網路基礎架構 (通常是 Envoy 代理程式) 新增至 VM 執行個體和 Pod。這項基礎架構會設定為與 Cloud Service Mesh 通訊,並瞭解您的服務。

設定 Cloud Service Mesh

接下來,您將設定全域服務,並定義流量處理方式。如要設定 Cloud Service Mesh,您可以使用 Google Cloud 控制台 (適用於部分功能和設定)、Google Cloud CLI、Traffic Director API 或其他工具 (例如 Terraform)。

完成這些步驟後,Cloud Service Mesh 即可設定應用程式網路基礎架構。

基礎架構可處理應用程式網路

當應用程式向 my-service 傳送要求時,應用程式網路基礎架構 (例如 Envoy 附屬 Proxy) 會根據從 Cloud Service Mesh 收到的資訊處理要求。這樣一來,my-service 的要求就能順利轉送至可接收要求的應用程式執行個體。

監控及持續更新

Cloud Service Mesh 會監控組成服務的應用程式執行個體。這項監控功能可讓 Cloud Service Mesh 偵測服務是否運作正常,或服務的容量是否已變更 (例如,建立新的 Kubernetes Pod 時)。Cloud Service Mesh 會根據這項資訊,持續更新應用程式網路基礎架構。

功能

Cloud Service Mesh 的功能可為微服務提供應用程式網路功能。本節將討論其中幾項重點。

全代管控制平面、健康狀態檢查和負載平衡

您想將時間用於創造業務價值,而非管理基礎架構。Cloud Service Mesh 是全代管解決方案,因此您不必安裝、設定或更新基礎架構。您可以使用 Google 用於健康狀態檢查和全球負載平衡的基礎架構。

以開放原始碼產品為基礎打造

Cloud Service Mesh 使用與熱門開放原始碼專案 (例如 EnvoyIstio) 相同的控制層 (xDS API)。如要查看支援的 API 版本,請參閱 xDS 控制平面 API

提供應用程式網路功能的基礎架構 (Envoy 或 gRPC,視用途而定) 也是開放原始碼,因此您不必擔心會受限於專屬基礎架構。

擴充

無論是一次性的應用程式網路解決方案,還是包含數千項服務的大型服務網格部署作業,Cloud Service Mesh 都能滿足您的擴充需求。

探索服務並追蹤端點和後端

當應用程式將要求傳送至 my-service 時,基礎架構會無縫處理要求,並將其傳送至正確的目的地。應用程式不需要瞭解任何有關 IP 位址、通訊協定或其他網路複雜性的資訊

全球負載平衡和備援

Cloud Service Mesh 會使用 Google 的全球負載平衡和健康狀態檢查功能,根據用戶端和後端位置、後端鄰近性、健康狀態和容量,以最佳方式平衡流量。您可以讓流量自動容錯移轉至有容量的健康後端,藉此提高服務可用性。您可以自訂負載平衡,分配流量,以便妥善支援業務需求。

流量管理

進階流量管理功能 (包括轉送和要求操作,可根據主機名稱、路徑、標頭、Cookie 等) 可讓您決定服務之間的流量流向。您也可以為金絲雀部署作業套用重試、重新導向和以權重為依據的流量分配等動作。容錯植入、流量鏡射和異常值偵測等進階模式可支援 DevOps 用途,提升復原能力。

觀測能力

應用程式網路基礎架構會收集遙測資訊 (例如指標、記錄和追蹤記錄),並集中匯入 Google Cloud Observability。收集這類資訊後,您就能取得洞察資料並建立快訊,以便在發生任何錯誤時收到通知。

VPC Service Controls

您可以使用 VPC Service Controls 為應用程式的資源和服務提供額外的安全防護。您可以將專案加入服務範圍,這樣一來,源自服務範圍外的資源和服務 (例如 Cloud Service Mesh) 就無法存取相關要求。如要進一步瞭解 VPC Service Controls,請參閱 VPC Service Controls 總覽

如要進一步瞭解如何搭配 VPC Service Controls 使用 Cloud Service Mesh,請參閱「支援的產品」頁面。

後續步驟

這是一份舊版文件,主要適用於負載平衡 API。我們強烈建議您不要使用負載平衡 API 設定 Cloud Service Mesh。