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