本文說明負載平衡的兩種 Dataplane V2 轉送模式,以及如何為 Google Distributed Cloud 啟用這些模式。Dataplane V2 支援兩種負載平衡轉送模式:
來源網路位址轉譯 (SNAT)
伺服器直接回傳 (DSR)
您只能在建立叢集時設定負載平衡的轉送模式。
SNAT 負載平衡
來源網路位址轉譯 (SNAT) 是 Dataplane V2 負載平衡的預設轉送模式。不過,在 SNAT 模式下,系統不會為後端 Pod 保留用戶端 IP 位址。當用戶端的封包抵達負載平衡器節點時,系統會翻譯並轉送至目的地工作站節點,其中包含後端 Pod。後端 Pod 會發現要求來自負載平衡器節點,而非用戶端位置。因此,回覆會傳回負載平衡器節點,並經過反向翻譯,然後傳回給用戶端。
LoadBalancer 類型的 Service 會指派給負載平衡器節點,而該節點上執行的 MetalLB speaker 會宣傳其 IP 位址 172.16.20.16。
資料平面 V2 會使用 SNAT 將來源 IP 位址和通訊埠轉譯為 <LB_NODE_IP>:52000,並將封包轉送至工作站節點。
回應會傳回負載平衡器節點,並反向轉譯目的地地址。
下圖顯示 SNAT 模式的封包流程:
DSR 負載平衡
伺服器直接回傳 (DSR) 可解決 SNAT 負載平衡的問題。在 DSR 模式中,負載平衡器節點會使用 IP 選項儲存用戶端來源位址。工作站節點可以復原原始封包,並轉送至後端 Pod。後端 Pod 可以看出封包來自用戶端 IP 位址,而非負載平衡器節點 IP 位址。因此,傳回封包會直接傳回至用戶端 IP 位址,而不會傳回負載平衡器節點。
這個模式不僅解決了用戶端 IP 位址可視性問題,還能節省負載平衡器節點的頻寬。回程流量不必經過負載平衡器節點,負載平衡器節點也不必再追蹤連線。這種做法可節省記憶體,並釋出轉送埠。對於非對稱工作負載 (下載流量遠高於要求流量),DSR 流程可大幅減少頻寬。
apiVersion:baremetal.cluster.gke.io/v1kind:Clustermetadata:name:lb-modenamespace:cluster-lb-mode...spec:clusterNetwork:forwardMode:dsr# valid options are dsr or snatpods:cidrBlocks:-192.168.0.0/16services:cidrBlocks:-10.96.0.0/20...
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-01 (世界標準時間)。"],[],[],null,["This document describes the two Dataplane V2 forwarding modes for load balancing\nand how to enable them for Google Distributed Cloud. Dataplane V2 supports two\nforwarding modes for load balancing:\n\n- Source network address translation (SNAT)\n- Direct Server Return (DSR)\n\nThe forwarding mode for load balancing can be configured when you create a\ncluster only.\n\nSNAT load balancing\n\nSource network address translation (SNAT) is the default forwarding mode for\nDataplane V2 load balancing. However, in SNAT mode, the client IP address isn't\npreserved for backend Pods. When the packet from the client arrives at the load\nbalancer node, it's translated and forwarded to the destination worker node with\nthe backend Pod. The backend Pod sees that the request is coming from the load\nbalancer node, instead of the client location. As a result, the reply is\nreturned to the load balancer node and reversed translated and sent back to the\nclient.\n\nPacket flow for SNAT\n\nWith SNAT forwarding mode for Dataplane V2 load balancing, here's the packet\nflow from an external client to a backend Pod and back:\n\n- Service of type LoadBalancer is assigned to a load balancer node and its IP\n address `172.16.20.16` is advertised by the MetalLB speaker running on that\n node.\n\n- Dataplane V2 translates the source IP address and port with SNAT to\n `\u003cLB_NODE_IP\u003e:52000` and forwards the packet to the worker node.\n\n- The response is sent back to the load balancer node and the destination\n address is reverse translated.\n\nThe following diagram shows the packet flow for SNAT mode:\n\nDSR load balancing\n\nDirect Server Return (DSR) overcomes issues with SNAT load balancing. In DSR\nmode, the load balancer node uses IP Options to save the client source address.\nThe worker node can recover the original packet and forward it to the backend\nPod. The backend Pod can see that the packet is coming from client IP address\ninstead of the load balancer node IP address. As a result, the return packet\ndirectly returns to the client IP address instead of traveling back to the load\nbalancer node.\n\nThis mode not only solves the client IP address visibility problem, it also\nsaves the bandwidth for the load balancer node. Return traffic doesn't have to\ngo through the load balancer node, and the load balancer node doesn't have to do\nconnection tracking anymore. This approach saves memory and frees the forwarding\nport. For asymmetric workloads, where download traffic is much higher than\nrequest traffic, the DSR flow reduces bandwidth significantly.\n\nPacket flow for DSR\n\nWith DSR forwarding mode for Dataplane V2 load balancing, here's the packet flow\nfrom and external client to a backend Pod and back:\n\n- Service of type LoadBalancer is assigned to the load balancer node and its\n IP address `172.16.20.16` is advertised by the MetalLB speaker running on\n that node.\n\n- Dataplane V2 forwards the packet to the worker node and uses IP Options to\n save the original client source IP address and port.\n\n- Dataplane V2 on the worker node forwards the packet to the backend Pod.\n\n- The backend Pod recovers the source IP address and port and replies to the\n client.\n\nThe following diagram shows the packet flow for DSR mode:\n\nEnable DSR mode\n\nTo enable DSR mode, add the\n[`spec.clusterNetwork.forwardMode`](/kubernetes-engine/distributed-cloud/bare-metal/docs/reference/cluster-config-ref#clusternetwork-forwardmode)\nfield to your cluster configuration file and set it to `dsr`. As noted earlier,\nSNAT mode is enabled by default. You can specify SNAT mode explicitly by setting\n`forwardMode` to `snat`. The forwarding mode for Dataplane V2 load balancing can\nbe configured at cluster creation time only.\n| **Note:** For version 1.16 clusters, the ability to configure Dataplane V2 forwarding mode for load balancing is a ([Preview](/products#product-launch-stages)) capability. While in Preview, this feature uses an annotation `preview.baremetal.cluster.gke.io/dpv2-lbmode-dsr:\nenable` to enable DSR mode. For cluster upgrades from version 1.16 to 1.28.0 and higher, Google Distributed Cloud honors the annotation and sets `forwardMode` in the cluster spec accordingly. \n\n apiVersion: baremetal.cluster.gke.io/v1\n kind: Cluster\n metadata:\n name: lb-mode\n namespace: cluster-lb-mode\n ...\n spec:\n\n clusterNetwork:forwardMode: dsr # valid options are dsr or snat\n pods:\n cidrBlocks:\n - 192.168.0.0/16\n services:\n cidrBlocks:\n - 10.96.0.0/20\n ...\n\nThe `forwardMode` value can't be modified after the cluster is created. Make sure you've\nconfigured the correct option for your needs before you create the cluster."]]