總覽
您可以使用 GKE 服務導引功能，控管 GKE 叢集內的網路流量。您可以定義規則，將特定類型的流量導向叢集中部署的網路功能。GKE 服務導引功能與策略路由類似，可覆寫網路流量的一般路徑。
術語與概念
本頁面會使用下列概念：
服務功能 (SF)
「服務函式」是軟體元件，可處理收到的資料封包。服務層可以在 OSI 模型的任何層級運作，從第 2 層 (資料連結層) 開始。
服務函式大致可分為以下幾類：
- 安全防火牆
- 控管存取權的 Proxy
- WAN 加速功能，可提升速度
- 深度封包檢查 (DPI) 分析內容
- 合法攔截 (LI)，用於監控和調查
- 私有和公有 IP 位址的網路位址轉譯器 (NAT)
- HTTP 標頭擴充
- 負載平衡器，可有效分配流量
服務函式的其他術語包括：
- 容器家電
- 虛擬設備
- 虛擬化網路功能 (NFV)
- 容器化網路功能 (CNF)
- 雲端原生網路功能 (CNF)
在服務導向中，服務物件代表服務函式 (SF)。
服務功能鏈 (SFC)
服務函式鏈結 (SFC) 是一系列服務函式，例如防火牆、Proxy 或負載平衡器，這些函式會連結在一起，以特定順序處理網路流量。這個鏈結就像管道，每個服務函式都會對流量執行特定工作，然後再傳遞至下一個函式。
服務功能鏈 (SFC) 也稱為服務鏈 (SC)。
在服務導向中，ServiceFunctionChain 物件代表服務函式鏈結 (SFC)。
服務功能獨立運作，不受任何服務功能鏈影響。服務函式通常不會知道自己屬於哪個服務函式鏈。
服務導引
服務導向會將封包轉送至所選服務功能，來源和目的地完全不會察覺。這個概念有時稱為「策略路由」、「流量重新導向」或「服務功能轉送」。Service Steering 使用 Geneve + NSH 封裝技術，實現透明轉送 (請參閱 RFC 8926、RFC 8300、Geneve + NSH IETF 草案)。
服務轉向的重要特性包括：
- 在服務函式的後端 Pod 之間平衡負載：服務函式通常會在多個 Pod 上執行，以確保擴充性和可靠性。服務導向功能會將傳入的網路流量平均分配到這些 Pod，避免單一 Pod 過載。
- 支援 5 元組流量親和性 (所有中繼躍點必須在特定流量中保持穩定)：5 元組流量是一種根據來源 IP 位址、來源通訊埠、目的地 IP 位址、目標通訊埠和通訊協定，識別特定網路流量串流的方法。服務導向功能可確保同一流程中的所有封包，都會持續導向同一組服務函式 (躍點)。
- 啟用對稱傳回資料路徑：對稱傳回資料路徑是指回應流量會沿著與原始要求流量相同的路徑傳回來源。服務轉向可確保這種對稱性，這對某些網路通訊協定和應用程式來說非常重要。
對於任何受服務導向的網路流量，中繼服務函式 Pod 會處理該特定網路流量的所有封包，確保中繼躍點一致且路徑可預測。相同的服務函式 Pod 會接收回傳流量，確保流量對稱。如果原始流量傳送至相同叢集內的目的地，回傳流量會自動透過相同的服務鏈結返回。如果原始流量位於叢集外部，鏈結中的最終服務函式會使用來源網路位址轉譯 (SNAT) 或 Proxy (做為中介)，將流量吸引回自身。
用途
GKE 服務導引功能會將策略路由整合至叢集。這可實現下列主要用途：
自行管理的安全防護服務：
機構可使用虛擬防火牆 (vFW)、虛擬新一代防火牆 (vNG-FW) 和虛擬入侵偵測系統 (vIDS) 等容器化網路功能 (CNF)，建構自己的安全基礎架構。服務導向功能可確保流量在到達預定目的地之前，會先透過這些 CNF 轉送，提供一層保護和控管機制。
代管安全服務供應商 (MSP)：
MSP 可以運用 GKE 服務導引功能，透過雲端式安全服務鏈路徑，轉送您的流量。因此能提供全方位的安全防護解決方案，包括安全網路閘道 (SWG)、安全存取服務邊緣 (SASE) 和軟體定義廣域網路 (SD-WAN) 功能。
電信和 5G 網路：
服務導向功能可管理電信和 5G 基礎架構中各種網路功能的流量。您可以自動調度虛擬路由器 (vRouter)、虛擬會話邊界控制器 (vSBC) 和 5G 核心網路功能，確保有效管理流量、平衡負載，以及強制執行特定安全或服務品質政策。
服務導引的運作方式
本節說明 Service Steering 各項元件的運作方式。
服務函式
識別網路流量：GKE 服務導向功能會使用不重複的流量 ID，以及封包來源 IP 位址、來源通訊埠、目的地 IP 位址、目的地通訊埠和通訊協定的 5 元組雜湊，識別每個網路連線。
確保流程親和性：服務導向功能會將所有具有相同流程 ID 的封包導向服務功能 (SF) 的相同路徑，確保流程親和性。
修改封包以建立新流程：如果服務函式修改封包中的任何 5 元組欄位，舉例來說，NAT 變更來源 IP 位址時，會建立新的流程。
為新流程選取流量：流量選取程序會評估新流程，判斷其通過其餘
Service Functions的路徑，可能與原始流程的路徑不同。將 Proxy 和 NAT 視為兩個流程：系統會將通過 Proxy 或 NAT 的流量視為兩個獨立流程：來源到 Proxy/NAT，以及 Proxy/NAT 到目的地。服務導向功能無法保證這兩個流程會採用相同路徑。
驗證來源地址：即使流量並非由服務導向功能導向，SF 仍一律須通過來源地址驗證。如果服務函式發起來源 IP 位址不符的新流程，除非明確允許，否則這些封包會遭到捨棄。
維持封裝透明度：服務導向功能會使用 Geneve 封裝，在 SF 之間傳輸流量，但服務功能 Pod 本身並不會察覺到這點。封包會在進入 Pod 前解封，簡化服務函式開發作業。
現有連結
建立 TrafficSelector 時，Service Steering 會自動將其套用至符合選取器條件的現有連線。並將這些連線的封包重新導向至適當的服務函式。服務函式本身負責管理這些傳輸中的連線。常見做法是捨棄封包，並讓用戶端啟動新連線，然後從頭開始無縫整合至服務鏈。
資源生命週期
TrafficSelector 和 ServiceFunctionChain 資源標示為待刪除後，會立即刪除。沒有會阻止或延遲刪除資源的 Webhook 或終結器。
Pod 對 Service 的流量
服務導向功能會在解析服務虛擬 IP 位址後，選取流量。如果虛擬 IP 位址解析後，目的地 Pod 的 IP 位址落在 .egress.to.ipBlock 欄位指定的 CIDR 範圍內，則可選取使用 ClusterIP 導向 Service 的流量進行 Service Steering。
強制執行 NetworkPolicy
服務轉向不會略過 NetworkPolicy。來源 Pod 的輸出政策和目的地 Pod 的輸入政策，仍會套用至為 Service Steering 選取的流量。不過，在服務函式的輸入或輸出端，NetworkPolicy 強制執行不適用於這項政策。這是因為 NetworkPolicy 的輸入或輸出規則已明確定義來源和目的地 Pod，但未定義封包轉送器。
優點
採用 GKE 服務導引功能，並改用雲端原生技術，可帶來下列優點：
- Marketplace 產品：第三方可以在 Google Cloud Marketplace 提供容器化產品，並使用 Service Steering API。他們可以根據 GKE 提供和管理的 Kubernetes 內建 API，提供部署指南。
- Kubernetes 精細程度：您可以控管 Kubernetes 叢集內的流量。您可以分類要轉送的流量。您可以選取要選擇性套用服務導引功能的特定工作負載。
- 雙向性：GKE 的服務導向本質上是雙向的。也就是說，對於特定流程，傳回路徑與傳出路徑對稱。如果服務函式 (SF) 是以副本群組的形式部署，這項功能就相當重要。請確保相同的流量會通過同一組副本，以維持有狀態。
- 支援多重網路：大多數服務功能都需要多個 Pod 介面，才能將資料平面與控制及管理平面分離。部分服務函式的架構包含多個介面。GKE 的服務導向功能整合了 Pod 上的多重網路。這樣一來，使用者就能在特定 Pod 網路上建立服務導向。
- 將原始封包傳送至應用程式：GKE 的服務導向功能會封裝原始封包，並直接傳送至 Pod。這樣一來，您就不必執行任何解封裝作業，應用程式可以直接對原始封包執行操作。