這份參考架構說明透過 Google Kubernetes Engine (GKE) Gateway 將應用程式公開至外部的優點。這些 Gateway 會在服務網格內的多個 GKE 叢集上執行。本指南適用於平台管理員。
您可以跨多個 GKE 叢集一致地部署應用程式,讓每個叢集都成為額外的故障網域,進而提高服務的彈性和備援能力。舉例來說,如果服務的運算基礎架構部署在單一 GKE 叢集,服務水準目標 (SLO) 為 99.9%,則部署在兩個 GKE 叢集時,SLO 可達到 99.9999% (1 - (0.001)2)。您也可以為使用者提供體驗,讓傳入的要求自動導向延遲時間最短且可用的網格 Ingress 閘道。
如要瞭解公開在單一叢集上執行的服務網格應用程式有哪些好處,請參閱「從邊緣到網格:透過 GKE 閘道開放服務網格應用程式」。
架構
下圖的架構圖顯示資料如何透過雲端入口和網格入口流動:
上圖顯示下列資料流情境:
- 用戶端在 Google Cloud 負載平衡器終止連線,並使用自己的 Google 代管 TLS 憑證。
- 從 Google Cloud 負載平衡器到網格 Ingress Proxy,使用自己的自行簽署 TLS 憑證。
- 從網格 Ingress 閘道 Proxy 到工作負載補充 Proxy,使用啟用服務網格的 mTLS。
這個參考架構包含下列兩個 Ingress 層:
- Cloud Ingress:在本參考架構中,您可以使用 Kubernetes Gateway API (和 GKE Gateway 控制器),程式化外部多叢集 HTTP(S) 負載平衡層。負載平衡器會檢查多個區域的網格 Ingress Proxy,並將要求傳送至最近的健康狀態良好叢集。此外,這項功能還會實作 Google Cloud Armor 安全性政策。
- 網格 Ingress:在網格中,您可以直接對後端執行健康狀態檢查,以便在本機執行負載平衡和流量管理。
同時使用這兩個層時,每個層都有互補的角色。為達成下列目標, Google Cloud 會從雲端進入層和網格進入層,最佳化最合適的功能:
- 提供低延遲服務。
- 提高可用性。
- 使用雲端進入層的安全功能。
- 使用網格 Ingress 層的安全防護、授權和觀測功能。
雲端輸入
搭配網格 Ingress 使用時,雲端 Ingress 層最適合用於邊緣安全性和全域負載平衡。由於雲端輸入層與下列服務整合,因此非常適合在網格外部的邊緣執行這些服務:
- DDoS 防護
- Cloud 防火牆
- 驗證及授權
- 加密
雲端進入層的轉送邏輯通常很簡單。 不過,在多叢集和多區域環境中,這項作業可能會比較複雜。
由於面向網際網路的負載平衡器具有重要功能,雲端 Ingress 層可能由平台團隊管理,該團隊專門負責控管應用程式在網際網路上的公開和安全程度。與開發人員主導的基礎架構相比,這項控制項會降低這個層的彈性和動態程度。決定這個圖層的管理員存取權和提供方式時,請考量這些因素。
網格輸入
搭配雲端 Ingress 使用時,網格 Ingress 層可做為流量進入服務網格的進入點。這個層也提供後端 mTLS、授權政策和彈性的 regex 比對。
在網格外部部署外部應用程式負載平衡,並搭配網格 Ingress 層,可帶來顯著優勢,特別是網際網路流量管理。雖然服務網格和 Istio Ingress 閘道可在網格中提供進階的路由和流量管理功能,但有些功能在網路邊緣執行會比較好。透過Google Cloud的外部應用程式負載平衡器善用網際網路邊緣網路,與網格型 Ingress 相比,可能在效能、可靠性或安全性方面帶來顯著優勢。
使用的產品和功能
以下列出這項參考架構使用的所有 Google Cloud 產品和功能:
- GKE Enterprise: 這項代管 Kubernetes 服務可讓您透過 Google 基礎架構,大規模部署及操作容器化應用程式。就本參考架構而言,提供應用程式服務的每個 GKE 叢集都必須位於同一個機群中。
- 車隊和多叢集閘道: 這些服務可讓您使用 Google 的基礎架構和 GKE Enterprise,以企業規模建立容器化應用程式。
- Google Cloud Armor: 這項服務可協助您保護應用程式和網站,防範阻斷服務和網路攻擊。
- Cloud Service Mesh: 以 Envoy 和 Istio 為基礎的全代管服務網格
- 應用程式負載平衡器: 以 Proxy 為基礎的第 7 層負載平衡器,可讓您執行及調度服務資源。
- Certificate Manager: 這項服務可讓您取得及管理 TLS 憑證,以便搭配 Cloud Load Balancing 使用。
機群
如要管理多叢集部署作業,GKE Enterprise 和 Google Cloud 會使用機群,以邏輯方式分組及正規化 Kubernetes 叢集。
使用一或多個機群,可將管理單位從個別叢集提升為整個叢集群組。如要減少叢集管理摩擦,請使用命名空間相同性的機群原則。在車隊中,請務必以相同方式設定每個 GKE 叢集的所有網格 Ingress 閘道。
此外,請持續部署應用程式服務,確保命名空間帳戶中的服務 balance-reader 與艦隊中每個 GKE 叢集內的相同服務相關。機群內假設的相同性和信任原則,可讓您在 GKE Enterprise 和 Google Cloud中使用全系列支援機群的功能。
服務網格內的東向/西向轉送規則和流量政策,會在網格輸入層級處理。網格 Ingress 層會部署在機群中的每個 GKE 叢集。以相同方式設定每個網格 Ingress 閘道,並遵守叢集命名空間相同的原則。
雖然 GKE Gateway 只有一個設定叢集,但您應在機群中的所有 GKE 叢集之間,同步處理 GKE Gateway 設定。
如要指派新的設定叢集,請使用 ConfigSync。 ConfigSync 可確保所有這類設定都會在機群中的所有 GKE 叢集之間同步處理,並避免與非目前的設定進行協調。
網格輸入閘道
Istio 0.8 推出網格輸入閘道。閘道提供一組專屬的 Proxy,這些 Proxy 的通訊埠會向來自服務網格外部的流量公開。您可以透過這些網格輸入 Proxy,控管網路曝光行為,與應用程式的路由行為分開。
此外,您也可以在流量抵達應用程式 Sidecar 之前,透過 Proxy 將路由和政策套用至網格外部流量。網格 Ingress 會定義流量到達網格中的節點時的處理方式,但外部元件必須定義流量首次到達網格的方式。
如要管理外部流量,您需要網格外部的負載平衡器。為自動化部署作業,這項參考架構使用 Cloud Load Balancing,該服務是透過 GKE Gateway 資源佈建。
GKE 閘道和多叢集服務
您可以透過多種方式,讓叢集外部的用戶端存取應用程式。GKE Gateway 是 Kubernetes Gateway API 的實作項目。GKE 閘道改良 Ingress 資源並推陳出新。
將 GKE Gateway 資源部署至 GKE 叢集時,Gateway 控制器會監控 Gateway API 資源。控制器會調解 Cloud Load Balancing 資源,以實作 Gateway 資源指定的網路行為。
使用 GKE Gateway 時,用來向用戶端公開應用程式的負載平衡器類型,主要取決於下列因素:
- 後端服務位於單一 GKE 叢集,還是分布在多個 GKE 叢集 (位於相同機群中)。
- 用戶端 (外部或內部) 的狀態。
- 負載平衡器的必要功能,包括與 Cloud Armor 安全性政策整合的功能。
- 服務網格的跨度需求。服務網格可跨越多個 GKE 叢集,或包含在單一叢集中。
在 Gateway 中,您可以指定適當的 GatewayClass,控管這項行為。如要參照 Gateway 類別,可用於多叢集情境的類別名稱會以 -mc
結尾。
本參考架構說明如何透過外部應用程式負載平衡器,在外部公開應用程式服務。不過,使用 Gateway 時,您也可以建立多叢集區域內部應用程式負載平衡器。
如要在多叢集情境中部署應用程式服務,可以透過下列兩種方式定義Google Cloud 負載平衡器元件:
如要進一步瞭解這兩種部署應用程式服務的方法,請參閱「為 GKE 選擇多叢集負載平衡 API」。
多叢集 Ingress 依賴建立 MultiClusterService
資源。多叢集閘道會建立 ServiceExport
資源,並參照 ServiceImport
資源。
使用多叢集閘道時,您可以建立政策,啟用基礎 Google Cloud 負載平衡器的其他功能。與本參考架構相關聯的部署指南,說明如何設定 Google Cloud Armor 安全性政策,協助保護後端服務免受跨網站指令碼攻擊。
這些政策資源的目標是機群中跨多個叢集公開的後端服務。在多叢集情境中,所有這類政策都必須參照ServiceImport
資源和 API 群組。
健康狀態檢查
使用兩層 L7 負載平衡時,健康狀態檢查會變得較為複雜。您必須設定每個負載平衡器,檢查下一層的健康狀態。GKE Gateway 會檢查網格入口代理程式的健康狀態,而網格則會檢查應用程式後端的健康狀態。
- 雲端 Ingress:在本參考架構中,您會透過 GKE Gateway 設定Google Cloud 負載平衡器,檢查網格 Ingress 代理程式在公開健康狀態檢查通訊埠上的健康狀態。如果網格 Proxy 停止運作,或叢集、網格或區域無法使用, Google Cloud 負載平衡器會偵測到這種情況,並不會將流量傳送至網格 Proxy。在這種情況下,流量會轉送至其他 GKE 叢集或區域中的替代網格 Proxy。
- 網格輸入:在網格應用程式中,您可以直接對後端執行健康狀態檢查,以便在本機執行負載平衡和流量管理。
設計須知
本節提供相關指引,協助您運用這項參考架構,開發符合特定安全性、法規遵循、可靠性和成本需求的架構。
安全性、隱私權和法規遵循
本文中的架構圖包含多個安全元素。最關鍵的元素是加密設定和憑證部署方式。GKE Gateway 會整合 Certificate Manager,以達到上述安全防護目的。
網際網路用戶端會根據公開憑證進行驗證,並連線至虛擬私有雲 (VPC) 中的外部負載平衡器,做為第一個躍點。您可以參閱 Gateway 定義中的憑證管理員 CertificateMap
。下一個躍點是 Google Front End (GFE) 和網格進入代理伺服器之間。
該躍點預設會加密。
GFE 與後端之間的網路層級加密會自動套用。如果安全規定要求平台擁有者保留加密金鑰擁有權,您可以在叢集閘道 (GFE) 和網格 Ingress (Envoy Proxy 執行個體) 之間啟用 HTTP/2,並使用 TLS 加密。
在叢集閘道和網格 Ingress 之間啟用 HTTP/2 和 TLS 加密時,可以使用自行簽署或公開憑證加密流量。您可以使用自行簽署或公開憑證,因為 GFE 不會根據憑證進行驗證。如要瞭解這個額外加密層,請參閱與此參考架構相關聯的部署指南。
為避免憑證遭到誤用,請勿重複使用公開憑證。在服務網格中,為每個負載平衡器使用個別憑證。
為協助建立外部 DNS 項目和 TLS 憑證,這項參考架構的部署指南會使用 Cloud Endpoints。使用 Cloud Endpoints 可建立對外開放的 cloud.goog
子網域。在企業級情境中,請使用更合適的網域名稱,並在 DNS 服務供應商中建立指向全域應用程式負載平衡器 IP 位址的 A 記錄。
如果您使用的服務網格強制執行 TLS,則側車代理程式之間的所有流量,以及網格輸入的所有流量都會經過加密。架構圖顯示從用戶端到 Google Cloud 負載平衡器、從負載平衡器到網格 Ingress Proxy,以及從 Ingress Proxy 到 Sidecar Proxy 的 HTTPS 加密。
可靠性和應變能力
多叢集多區域邊緣至網格模式的主要優點,是可將服務網格的所有功能用於東西向負載平衡,例如應用程式服務之間的流量。
這個參考架構使用多叢集 GKE Gateway,將傳入的雲端 Ingress 流量轉送至 GKE 叢集。系統會根據與使用者的距離 (以延遲時間為依據),以及 GKE 叢集的可用性和健康狀態,選取叢集。流量抵達 Istio 輸入閘道 (網格輸入) 時,會透過服務網格轉送至適當的後端。
處理東西向流量的替代方法,是透過多叢集服務,處理部署在 GKE 叢集的所有應用程式服務。在艦隊的 GKE 叢集使用多叢集服務時,服務端點會收集在 ClusterSet
中。如果某項服務需要呼叫另一項服務,則可以指定第二項服務的任何正常端點。由於端點是輪流選取,因此所選端點可能位於不同可用區或不同區域。
相較於使用多叢集服務,使用服務網格處理東西向流量的主要優點是,服務網格可以採用區域負載平衡。區域負載平衡不是多叢集服務的功能,但您可以透過 DestinationRule
進行設定。
設定完成後,從某項服務呼叫另一項服務時,系統會先嘗試連線至相同區域的服務端點,然後嘗試連線至與呼叫服務相同的區域。最後,只有在相同區域或可用區的服務端點無法使用時,呼叫才會以其他區域的端點為目標。
成本最佳化
在企業中廣泛採用這項多叢集架構時,Cloud Service Mesh 和多叢集閘道會納入 Google Kubernetes Engine (GKE) Enterprise 版。此外,GKE Enterprise 包含許多功能,可讓您大規模管理及控管 GKE 叢集、應用程式和其他程序。
部署作業
如要部署這個架構,請參閱「從邊緣到多叢集網格:透過 GKE 閘道和 Cloud Service Mesh 部署全球分散式應用程式」。
後續步驟
- 瞭解更多 GKE 閘道提供的功能,可與服務網格搭配使用。
- 瞭解適用於 GKE 的不同類型 Cloud Load Balancing。
- 瞭解 Cloud Service Mesh 提供的功能。
- 如需更多參考架構、圖表和最佳做法,請瀏覽 Cloud 架構中心。
貢獻者
作者:
- Alex Mattson | 應用程式專員工程師
- Mark Chilvers | 應用程式專員工程師
其他貢獻者:
- Abdelfettah Sghiouar | 雲端開發人員服務代表
- Arunkumar Jayaraman | 首席工程師
- Greg Bray | 客戶工程師
- Megan Yahya | 產品經理
- Paul Revello | 雲端解決方案架構師
- Valavan Rajakumar | 主要企業架構師
- Maridi (Raju) Makaraju | 支援能力技術主管