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

Last reviewed 2023-10-24 UTC

這個參考架構說明如何將 Cloud Service Mesh 與 Cloud Load Balancing 結合,將服務網格中的應用程式公開給網際網路用戶端。

Cloud Service Mesh 是基於 Istio 的受管理服務網格,可為應用程式提供安全強化、可觀測且標準化的通訊層。服務網格可為在網格中通訊的用戶端提供完整的通訊平台。不過,如何將位於網格外部的用戶端連結至網格內部代管的應用程式,仍是一項挑戰。

您可以透過多種方式將應用程式公開給用戶端,具體取決於用戶端的位置。這份參考架構適用於執行 Cloud Service Mesh 的進階實作人員,但也適用於 Google Kubernetes Engine (GKE) 上的 Istio。

網格輸入閘道

Istio 0.8 推出了網格 ingress gateway。閘道會提供一組專屬 Proxy,這些 Proxy 的通訊埠會公開給來自服務網狀網路外部的流量。這些網格輸入代理程式可讓您分別控管網路曝光行為和應用程式路由行為。

您也可以在網格外部流量抵達應用程式附屬程式之前,透過 Proxy 套用轉送和政策。網格入口定義流量到達網格中的節點時的處理方式,但外部元件必須定義流量如何首次抵達網格。

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

對於 Google Cloud,此設定的標準範例是外部負載平衡服務,可部署公開網路負載平衡器 (L4)。該負載平衡器會指向 GKE 叢集的 NodePort。這些 NodePort 會公開 Istio 輸入閘道 Pod,並將流量路由至下游網格側邊代理程式。

架構

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

外部負載平衡器會透過入口閘道 Proxy 將外部用戶端轉送至網格。

上圖顯示,使用 L4 透明負載平衡機制搭配網格入口閘道可享有下列優勢:

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

GKE 閘道和服務

您可以透過多種方式,為叢集外部的用戶端提供應用程式存取權。GKE Gateway 是 Kubernetes Gateway API 的實作項目。GKE 閘道可改良 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 負載平衡架構的優點。

雲端入口和網狀結構入口

在網狀結構外部部署外部第 7 層負載平衡器,並搭配網狀結構入口層,可帶來顯著優勢,特別是對於網際網路流量而言。雖然 Cloud Service Mesh 和 Istio 入口網關可在網格中提供進階路由和流量管理功能,但某些功能在網路邊緣運作會更有效率。透過Google Cloud的外部應用程式負載平衡器,充分利用網際網路邊緣網路,可能會比以網格為基礎的入口提供更出色的效能、可靠性或安全性相關優勢。這些優點包括:

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

Cloud ingress 會做為閘道,讓透過虛擬私有雲網路的對等互連外部流量得以傳送。

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

雲端和網格輸入拓撲

本節將說明各個入口層在搭配使用時,所扮演的互補角色。這些角色並非具體規則,而是利用各層優點的規範。視用途而定,這類模式可能會有所變化。

  • 雲端入口:搭配使用網格入口時,雲端入口層最適合用於邊緣安全性和全域負載平衡。由於雲端入口層已整合邊緣的 DDoS 防護、雲端防火牆、驗證和加密產品,因此非常適合在非網格區域中執行這些服務。在這個層級,路由邏輯通常很簡單,但在多叢集和多區域環境中,邏輯可能會變得更複雜。由於面向網際網路的負載平衡器具有重要功能,雲端入口層很可能由基礎架構團隊管理,該團隊擁有應用程式在網際網路上曝光和安全性方面的專屬控管權限。這項控制項也讓這個層級的彈性和動態性不如開發人員主導的基礎架構,這項考量因素可能會影響您提供此層級管理存取權的對象和方式。
  • 網格入口:搭配雲端入口時,網格入口層會提供與應用程式相近的彈性路由。由於這種彈性,在複雜的路由邏輯和應用程式層級可視性方面,網格入口比雲端入口更勝一籌。入口層之間的區隔也讓應用程式擁有者能直接控制這個層級,而不會影響其他團隊。為確保應用程式安全,如果您透過 L4 負載平衡器 (而非 L7 負載平衡器) 公開服務網狀結構應用程式,請在網狀結構內的網狀結構入口層終止用戶端 TLS。

健康狀態檢查

使用兩層 L7 負載平衡功能時,健康狀態檢查是其中一個複雜的部分。您必須設定每個負載平衡器,以便檢查下一層的健康狀態,確保負載平衡器能接收流量。下圖中的拓撲圖顯示雲端入口如何檢查網格入口 Proxy 的健康狀態,而網格則會檢查應用程式後端的健康狀態。

Cloud Ingress 會檢查網格入口的健康狀態,而網格入口會檢查應用程式後端的健康狀態。

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

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

安全性

上述拓樸圖也涉及多個安全元素。其中最重要的一項元素,就是如何設定加密機制和部署憑證。GKE GatewayGoogle 管理的憑證整合。您可以在 Gateway 定義中參照 Certificate Manager CertificateMap。網際網路用戶端會根據公開憑證進行驗證,並連線至虛擬私有雲 (VPC) 中的外部負載平衡器,做為第一個中繼。

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

如果服務網格規定使用 TLS,則會在 sidecar 代理程式和網格輸入端之間,對所有流量進行加密。下圖說明從用戶端到 Google Cloud 負載平衡器、從負載平衡器到網格入口 Proxy,以及從入口 Proxy 到側邊 Proxy 的 HTTPS 加密。

安全性則是透過網格外部的受管理憑證和網格內部的內部憑證實作。

成本最佳化

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

部署作業

如要部署這項架構,請參閱「從邊緣到網格:透過 GKE 閘道部署服務網格應用程式」。

後續步驟