本參考架構提供 Google Distributed Cloud (GDC) 實體隔離方案中，客戶自行管理的第 7 層負載平衡解決方案。只要在 GDC 標準叢集上部署 HAProxy Kubernetes Ingress 或 NGINX Gateway Fabric 等熱門開放原始碼控制器，客戶就能將 L7 流量順暢轉送至混合環境。這個架構使用 TLS 終止 (Ingress/HTTPRoute)，根據伺服器名稱指示 (SNI)，將流量轉送至內建容器化 Pod 和託管於外部虛擬機器的應用程式。
特點與功能
- 進階第 7 層轉送：支援主機轉送、路徑轉送，以及標頭比對和流量加權等進階流量管理。
- 集中式 TLS 管理：提供集中式 TLS 管理和終止功能。
- 支援混合環境：順暢地將 L7 流量轉送至內建容器化 Pod，以及託管於外部虛擬機器的應用程式。
- 彈性控制器選項：可選擇新式 NGINX Gateway Fabric (使用 Gateway API) 或成熟的 HAProxy Ingress 控制器。
- 實體隔離準備：與 Harbor Registry 整合，在私人、中斷連線的環境中儲存及提供 Proxy 和應用程式映像檔。
- 複雜的流量拆分：可為現代化應用程式推送作業，啟用進階流量分配策略。
架構原則
- 雙層負載平衡模式：這個架構結合 GDC 內建的 L4 負載平衡器 (做為進入點)，以及部署在 Kubernetes 內、由客戶管理的 L7 閘道。
- 角色導向區隔：採用特定資源 (例如
GatewayClass、Gateway和HTTPRoute或Ingress)，區隔基礎架構供應商、叢集運算子和開發人員的職責。 - 轉換至現代標準：這個架構優先採用 Gateway API，提供現代化轉送功能，同時仍支援舊版 Ingress API，確保特定控制器穩定運作。
- 客戶自行管理的彈性：部署自行管理的控制器後，客戶就能控管 GDC 代管 L4 平衡器未原生提供的 L7 功能和設定。
- 工作負載位置抽象化：架構透過 Kubernetes Service 抽象化 (標準或無頭)，一致處理容器化和 VM 型工作負載。
概念架構
邏輯架構
邏輯架構由多個功能元件組成，這些元件會協同運作，將外部流量轉送至內部或外部後端：
- Ingress/閘道進入點：用戶端發出 HTTPS 要求，首先會到達 GDC L4 負載平衡器。這個內建平衡器會做為進入點，將 TCP/443 流量分配給 L7 負載平衡器。
- 控制層：Ingress 或閘道控制器 (HAProxy 或 NGINX 運算子) 會監控 Kubernetes 資源，例如
Ingress、Gateway和HTTPRoute - 資料層：控制器會根據觀測到的資源，動態更新基礎 Proxy，並根據 SNI 主機路由規則和 TLS 終止，執行實際的流量轉送。
- 後端服務：
- 容器化 Pod：以標準 Deployment 的形式管理，並透過一般 Kubernetes Service 公開。
- 外部 VM：透過無頭 Kubernetes Service 和包含 VM 直接 IP 的自訂端點 (或
EndpointSlice)，整合至叢集
- 構件管理：Proxy 和應用程式的所有映像檔都由本機 Harbor Registry 提供，確保在實體隔離環境中正常運作
核心概念和技術
這個架構採用雙層負載平衡模式，結合 GDC 內建的 L4 負載平衡器，以及部署在 Kubernetes 中的客戶自行管理 L7 閘道。主要元件包括：
- 用戶端：發出 HTTPS 要求，與應用程式互動的實體。
- GDC 標準叢集：GDC 提供內建方式，可建立 Kubernetes Vanilla 叢集。在這個解決方案中，叢集會託管 L7 LB 及其控制器，以及外部 VM 的工作負載和無頭服務
- GDC L4 負載平衡器：內建的 L4 負載平衡器，可做為進入點，將 TCP/443 流量直接分配給執行 Ingress 或閘道控制器的 Kubernetes Pod。
- Ingress 和閘道控制器：在標準叢集中執行的 HAProxy 或 NGINX 運算子。以 Nginx 來說，他們會監控 Gateway API 資源 (例如
Gateway和HTTPRoute)，並動態更新基礎 Proxy。如果是 HAProxy，則會監控Ingress資源，並動態更新基礎 Proxy。- HAProxy Ingress 控制器：Kubernetes 的 Ingress 控制器，使用 HAProxy 做為反向 Proxy 和第 7 層負載平衡器，同時處理 TLS 終止。
- Nginx Gateway Fabric：使用 NGINX 做為資料層的 Gateway API 實作。
- Ingress 和閘道 (含 HTTPRoute)：標準化 Kubernetes 資源，定義實體監聽通訊埠 (443) 和採用 TLS 終止的 SNI 主機路由規則。
- 容器化工作負載 (Pod)：使用一般 Kubernetes
Service在內部公開的標準 Kubernetes Deployment。 - VM 型工作負載 (外部)：託管於專案網路外部 VM 的工作負載，透過無頭 Kubernetes
Service和包含 VM 直接 IP 的自訂端點，向 Proxy 公開。 - Harbor Registry：用於在實體隔離環境中儲存及提供 Proxy 和應用程式映像檔的私人 Container Registry。
Ingress 與 Gateway API
Kubernetes 網路環境正從舊版 Ingress API 轉換為新版 Gateway API。瞭解兩者之間的差異，是為工作負載選擇合適架構的關鍵。
Ingress API：Ingress 向來是管理 HTTP 服務外部存取權的標準。雖然提供主機型和路徑型轉送功能，但設計相對基本，且不支援內建的進階流量管理 (例如標頭比對或流量加權)，除非依賴供應商專屬註解。重要的是，Kubernetes 社群現在認為 Ingress API 功能已凍結 (Ingress 限制和 Kubernetes 網路演進)。
Gateway API：通常稱為 Ingress 的 V2，Gateway API 是一組自訂資源定義 (CRD)，可為服務網路提供更強大且可擴充的模型。這項 API 採用角色導向設計，可區分基礎架構供應商 (
GatewayClass)、叢集運算子 (Gateway) 和開發人員 (HTTPRoute/TLSRoute) 的責任 (GKE 中的 Gateway API)。這種劃分方式可提供更精細的控制，並更完善地支援多用戶群架構。
在這個 GDC 實體隔離方案中，我們刻意為兩個精選控制器選擇不同的 API：
- NGINX (Gateway API)：NGINX 實作項目採用 NGINX Gateway Fabric，這是 Gateway API 的成熟內建實作項目。客戶可透過 NGINX 運用 Gateway API，享有 API 內建的現代標準和進階轉送功能 (例如
HTTPRoute)。 - HAProxy (Ingress API)：雖然 Gateway API 是策略方向，但在本指南中，我們為 HAProxy 選取了 Ingress API。這是因為 HAProxy 的 Gateway API 整合功能尚未成熟。我們採用成熟的 HAProxy Ingress 控制器，為偏好 HAProxy 的客戶提供穩定可靠的 L7 解決方案，同時仍提供現代化 L7 功能。
假設和限制
假設
- 基礎架構準備就緒：部署作業假設 GDC 實體隔離方案 1.15.x 標準叢集可用。
- 本機註冊資料庫：假設本機 Harbor 註冊資料庫已正確設定，可在實體隔離環境中儲存及提供 Proxy 和應用程式映像檔。
- 原生進入點：假設流量會先到達內建的 GDC L4 負載平衡器，然後由該負載平衡器將流量分配給 L7 Proxy。
限制
- 客戶自行管理的解決方案：GDC 中沒有受管理且受服務水準協議保障的 L7 服務，這項實作完全由客戶自行管理。
- 僅限標準叢集：共用使用者叢集不在範圍內，因為部署 Ingress 和閘道控制器需要較高權限。
- API 成熟度：NGINX 使用現代化的 Gateway API，而 HAProxy 則受限於 Ingress API，因為其 Gateway API 整合尚未成熟。
- 實體隔離維護：所有容器映像檔都必須在本機 Harbor 登錄檔中手動推送及管理。
- 社群版本：此架構專為 Nginx 和 HAProxy 的開放原始碼社群版本設計。Enterprise 版本可能適用，但尚未經過明確測試。
- 作業擁有權：客戶必須自行管理第三方控制器的資源調度、高可用性和修補作業。
- 支援範圍：Google 支援僅涵蓋基礎 GDC 基礎架構；HAProxy 或 NGINX 軟體本身的問題由客戶或供應商負責。
- API 淘汰：Ingress API (用於 HAProxy) 的功能已由 Kubernetes 社群凍結，未來可能無法提供路由功能。
授權
- 社群版本：此架構專為開放原始碼社群版本 (通常是 Apache 2.0 或類似版本) 設計，可免費使用，但由客戶管理。
- 企業採購：客戶須自行負責採購及管理商業授權，例如 NGINX Plus 或 HAProxy Enterprise。