從邊緣到網格：透過 GKE 閘道公開服務網格應用程式

Last reviewed 2026-05-28 UTC

本參考架構說明如何將 Cloud Service Mesh 與 Cloud Load Balancing 結合，向網際網路用戶端公開發布服務網格中的應用程式。

Cloud Service Mesh 是以 Istio 為基礎的代管服務網格，可為應用程式提供安全強化、可觀察且標準化的通訊層。服務網格為網格中通訊的用戶端提供全方位的通訊平台。不過，如何將網格外部的用戶端連線至網格內託管的應用程式，仍是一項挑戰。

視用戶端所在位置而定，您可透過多種方式向用戶端公開應用程式。這項參考架構適用於執行 Cloud Service Mesh 的進階實務工作者，但也可在 Google Kubernetes Engine (GKE) 上使用 Istio。

網格輸入閘道

Istio 0.8 推出網格輸入閘道。閘道提供一組專屬的 Proxy，這些 Proxy 的通訊埠會向來自服務網格外部的流量公開。您可以透過這些網格輸入 Proxy，控管網路曝光行為，與應用程式路由行為分開。

您也可以在流量抵達應用程式 Sidecar 之前，透過 Proxy 將路由和政策套用至網格外部流量。網格 Ingress 會定義流量到達網格中的節點時的處理方式，但外部元件必須定義流量首次到達網格的方式。

如要管理這類外部流量，您需要使用網格外部的負載平衡器。這個參考架構使用透過 GKE Gateway 資源佈建的 Google Cloud Load Balancing，自動部署。

以 Google Cloud為例，這項設定的標準範例是部署公開網路負載平衡器 (L4) 的外部負載平衡服務。該負載平衡器會指向 GKE 叢集的 NodePort。這些 NodePort 會公開 Istio Ingress 閘道 Pod，將流量轉送至下游網格 Sidecar Proxy。

架構

下圖說明瞭這個拓撲。內部私人流量的負載平衡與這個架構類似，但您會改為部署內部直通式網路負載平衡器。

外部負載平衡器會透過 Ingress 閘道 Proxy，將外部用戶端導向網格。

上圖顯示使用 L4 透明負載平衡搭配網格 Ingress 閘道，可帶來下列優勢：

  • 這項設定可簡化負載平衡器的部署作業。
  • 當叢集變更、節點中斷或程序中斷時，負載平衡器會提供穩定的虛擬 IP 位址 (VIP)、健康狀態檢查，以及可靠的流量分配。
  • 所有轉送規則、TLS 終止作業和流量政策，都會在網格輸入閘道中的單一位置處理。

GKE 閘道和服務

您可以透過多種方式，為叢集外部的用戶端提供應用程式存取權。GKE Gateway 是 Kubernetes Gateway API 的實作項目。GKE Gateway 可改良 Ingress 資源並推陳出新。

將 GKE Gateway 資源部署至 GKE 叢集時，Gateway 控制器會監控 Gateway API 資源，並調解 Cloud Load Balancing 資源，以實作 GKE Gateway 資源指定的網路行為。

使用 GKE Gateway 時，用來向用戶端公開應用程式的負載平衡器類型，主要取決於下列因素：

  • 用戶端狀態 (外部或內部)。
  • 負載平衡器的必要功能，包括與 Google Cloud Armor 安全性政策整合的功能。
  • 服務網格的跨度需求。服務網格可跨越多個 GKE 叢集，或包含在單一叢集中。

在 GKE Gateway 中，您可以指定適當的 GatewayClass，控管這項行為。

雖然 Cloud Service Mesh 的預設負載平衡器是網路負載平衡器，但本參考架構著重於外部應用程式負載平衡器 (L7)。外部應用程式負載平衡器可與邊緣服務 (例如 Identity-Aware Proxy 和 Google Cloud Armor)、網址重新導向和重寫，以及全球分散式邊緣 Proxy 網路整合。下一節說明使用兩層 HTTP 負載平衡的架構和優點。

雲端輸入和網格輸入

在網格外部部署外部 L7 負載平衡，並搭配網格 Ingress 層，可帶來顯著優勢，特別是網際網路流量。雖然 Cloud Service Mesh 和 Istio Ingress 閘道可在網格中提供進階的路由和流量管理功能，但部分功能在網路邊緣執行會更有效率。透過Google Cloud's 外部應用程式負載平衡器運用網際網路邊緣網路，與網格型 Ingress 相比，可能在效能、可靠性或安全性方面帶來顯著優勢。這些福利包括：

這個 L7 負載平衡外部層稱為「雲端進入流量」，因為它是以雲端管理的負載平衡器為基礎建構，而非網格進入流量使用的自架主機 Proxy。雲端入口和網格入口的組合會使用 Google Cloud 基礎架構和網格的互補功能。下圖說明如何結合雲端 Ingress (透過 GKE 閘道) 和網格 Ingress，做為網際網路流量的兩個負載平衡層。

雲端輸入流量會透過虛擬私有雲網路，做為網格外部流量的閘道。

在上圖的拓撲中，雲端輸入層會從服務網格外部取得流量，並將該流量導向網格輸入層。網格的 Ingress 層接著會將流量導向網格代管的應用程式後端。

雲端和網格輸入拓撲

本節說明搭配使用時，每個 Ingress 層所扮演的互補角色。這些角色並非具體規則，而是利用各層優勢的指引。視您的用途而定，這個模式可能會有所變化。

  • 雲端入口：搭配網格入口時，雲端入口層最適合用於邊緣安全性和全域負載平衡。由於雲端輸入層與邊緣的 DDoS 防護、雲端防火牆、驗證和加密產品整合，因此這個層非常適合在網格外部執行這些服務。這個層級的路由邏輯通常很簡單，但如果是多叢集和多區域環境，邏輯可能會更複雜。由於面向網際網路的負載平衡器具有重要功能，因此雲端進入層可能由基礎架構團隊管理，該團隊可專門控管應用程式在網際網路上的公開和安全程度。此外，與開發人員主導的基礎架構相比，這項控制項也會降低這個層的彈性和動態性，這項考量可能會影響您提供這個層管理存取權的對象和方式。
  • 網格 Ingress：與 Cloud Ingress 配對時，網格 Ingress 層會提供接近應用程式的彈性路由。由於這項彈性，對於複雜的路由邏輯和應用程式層級的可視性，網格 Ingress 比雲端 Ingress 更適合。此外，由於入口層之間彼此分離，應用程式擁有者可直接控制這個層，不會影響其他團隊。為了保護應用程式安全，透過 L4 負載平衡器公開服務網格應用程式時，應在網格內部的網格 Ingress 層終止用戶端 TLS，而非使用 L7 負載平衡器。

健康狀態檢查

使用兩層 L7 負載平衡時，健康狀態檢查會變得複雜。您必須設定每個負載平衡器，檢查下一層的健康狀態，確保負載平衡器可以接收流量。下圖的拓撲顯示雲端 Ingress 如何檢查網格 Ingress Proxy 的健康狀態，而網格則會檢查應用程式後端的健康狀態。

Cloud Ingress 會檢查網格 Ingress 的健康狀態，網格 Ingress 則會檢查應用程式後端的健康狀態。

上述拓撲有下列注意事項：

  • 雲端 Ingress：在這個參考架構中，您會透過 Gateway 設定Google Cloud 負載平衡器，檢查網格 Ingress Proxy 在公開健康狀態檢查通訊埠上的健康狀態。如果網格 Proxy 停止運作，或是叢集、網格或區域無法使用， Google Cloud負載平衡器會偵測到這種情況，並不會將流量傳送至網格 Proxy。
  • 網格輸入：在網格應用程式中，您可以直接對後端執行健康狀態檢查，以便在本機執行負載平衡和流量管理。

安全性

上述拓撲也涉及多個安全元素。其中一個最關鍵的要素是加密設定和憑證部署方式。GKE Gateway 與 Google 管理的憑證整合。您可以在 Gateway 定義中參照 Certificate Manager CertificateMap。網際網路用戶端會根據公開憑證進行驗證，並連線至虛擬私有雲 (VPC) 中的外部負載平衡器，做為第一個躍點。

Google Front End (GFE) 和網格進入代理伺服器之間的下一個躍點，預設會經過加密。系統會自動套用 GFE 與後端之間的網路層級加密。不過，如果您的安全需求規定平台擁有者必須保留加密金鑰的所有權，則您可以在叢集閘道 (GFE) 和網格入口 (Envoy Proxy 執行個體) 之間，選擇啟用 HTTP/2 和 TLS 加密。為這個路徑啟用 HTTP/2 並使用 TLS 加密時，您可以使用自行簽署或公開憑證加密流量，因為 GFE 不會根據憑證進行驗證。如要瞭解這個額外的加密層，請參閱相關的部署指南。為避免憑證遭到誤用，請勿在其他地方使用公開負載平衡器的公開憑證。建議您改為在服務網格中使用個別憑證。如要為 GFE 對網格連線使用 HTTP/2，但不需要自己的加密，則可以使用 H2C。

如果服務網格強制執行 TLS，則所有流量都會在 Sidecar Proxy 之間加密，並傳送至網格輸入端。下圖說明從用戶端到 Google Cloud 負載平衡器、從負載平衡器到網格 Ingress Proxy，以及從 Ingress Proxy 到 Sidecar Proxy 的 HTTPS 加密程序。

安全防護機制是透過網格外部的代管憑證，以及網格內部的內部憑證來實作。

成本最佳化

在本文件中，您會使用下列 Google Cloud 的計費元件：

部署作業

如要部署此架構，請參閱「從邊緣到網格：透過 GKE Gateway 部署服務網格應用程式」。

後續步驟