-
Notifications
You must be signed in to change notification settings - Fork 368
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Support DSR mode for Service's external addresses (#5202)
This commit adds support for DSR mode for Service's external addresses, including LoadBalancerIPs and ExternalIPs. A configuration option, `antreaProxy.defaultLoadBalancerMode` is added to determine how external traffic is processed when it's load balanced across Nodes by default. It has two options: `nat` (default) and `dsr`. In NAT mode, external traffic is SNAT'd when it's load balanced across Nodes to ensure symmetric path. In DSR mode, external traffic is never SNAT'd and backend Pods running on Nodes that are not the ingress Node can reply to clients directly, bypassing the ingress Node. Additionally, a Service's load balancer mode can be overridden by annotating it with `service.antrea.io/load-balancer-mode`. A feature gate, `LoadBalancerModeDSR` is added to control whether it's allowed to use DSR mode. When a Service's LoadBalancerMode is DSR, the following changes will be applied to the OpenFlow flows and groups: 1. ClusterGroup will be used by traffic working in DSR mode on ingress Node. * If a local Endpoint is selected, it will just be handled normally as DSR is not applicable in this case. * If a remote Endpoint is selected, it will be sent to the backend Node that hosts the Endpoint without being NAT'd, the eventual Endpoint will be determined on the backend Node and may be different from the one selected here. 2. LocalGroup will be used by traffic working in DSR mode on backend Node. In this way, each Endpoint has the same chance to be selected eventually. 3. Traffic working in DSR mode on ingress Node will be marked and treated specially, e.g. bypassing SNAT. 4. Learned flow will be created for each connection to ensure consistent load balance decision for a connection of DSR mode. Learned flow is necessary because connections of DSR mode will remain invalid on ingress Node as it can only see requests and not responses. And OVS doesn't provide ct_state and ct_label for invalid connections. Thus, we can't store the load balance decision of the connection to ct_state or ct_label. To ensure consistent load balancing decision for packets of a connection, we use "learn" action to generate a learned flow when processing the first packet of a connection, and rely on the learned flow to process subsequent packets of the same connection. DSR mode usually means lower latency, higher output bandwidth, and preserved client IP. However, due to the use of learned flow, creating new connections may be slightly slower than NAT mode, this may be improved in the future. The benchmark of the current implementation is as below: ``` Test NAT DSR delta TCP_CRR 1105.69 1007.82 -8.86% TCP_RR 6802.55 9054.44 +33.1% ``` This feature is currently only supported for Linux Nodes, `encap` mode, and IPv4 cluster. The support for Windows and IPv6 can be added in the future. Signed-off-by: Quan Tian <[email protected]>
- Loading branch information
Showing
48 changed files
with
2,597 additions
and
855 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.