-
Notifications
You must be signed in to change notification settings - Fork 373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NodePort, LoadBalancer and ClusterIP full support for AntreaProxy on Linux #2599
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2599 +/- ##
==========================================
+ Coverage 60.82% 65.88% +5.06%
==========================================
Files 285 284 -1
Lines 23041 26909 +3868
==========================================
+ Hits 14014 17729 +3715
+ Misses 7526 7499 -27
- Partials 1501 1681 +180
Flags with carried forward coverage won't be shown. Click here to find out more.
|
/test-all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not finished yet, but I feel this PR could have been separated by features: a PR to support NodePort, a PR to support host accessing ClusterIPs, a PR to support LoadBalancer IPs, which are not really relevant to each other and can help identify which change is for which feature. Please consider dividing patch for individual features in the future. If other reviewers have the same feeling as me and the review progress goes slowly, I would suggest scoping this PR to NodePort related change only.
25ebfcc
to
8d272a7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the commit message:
localhost -> local host
"There are iptables rules which is used" -> "iptables rules are used"
"virtual Service IP" -> "virtual IP"
"There is a routing entry which is used" -> "A routing entry is added to"
"when new ClusterIP are" -> "When a new ClusterIP Service is"
"the destination IP block of the routing entry will be become large to include the IP address of ClusterIP" -> the destination IP block of the routing entry might be extended to include the ClusterIP address"
"there are main changes of OVS pipeline" -> "main changes of OVS pipeline include:"
984b657
to
3d67f4d
Compare
6d9fc27
to
e7c2b4c
Compare
0190692
to
f6c0c15
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks
3df91d1
to
5b6ce39
Compare
/test-all |
Could we change the title to "NodePort, LoadBalancer and ClusterIP full support for AntreaProxy on Linux" as it's not only for traffic from K8s Node, and a shorter title will look neater in git logs. |
5b6ce39
to
b3f7331
Compare
Updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@jianjuns will you take another look? |
No, no extra comment from me. |
…Linux For NodePort support, an ipset is used to store NodePort IP, port and transparent protocol in an entry IP:port,protocol. Then an iptables entry is used to match the ipset as destination and perform DNAT with a virtual IP. For DNAT'd packets, a routing entry is used to route them to Antrea gateway. For LoadBalancer support, a routing entry will be created for every ingress IP to route the packets from remote or localhost to Antrea gateway. For ClusterIP support, a routing entry is always used to route the packets of all ClusterIPs to Antrea gateway. when a new ClusterIP is created, the destination IP block of the routing entry might be extended to include the ClusterIP address. To support the Service traffic of above cases, the main changes of OVS pipeline include: - Change table serviceHairpinTable ID from 29 to 23. - Change table hairpinSNATTable ID from 106 to 108. - Add table serviceConntrackTable 24 to transform SNAT'd connections. - Add table serviceClassifierTable 35 to classify Service traffic. - Add table serviceConntrackCommitTable 106 to perform SNAT for Service traffic. Signed-off-by: Hongliang Liu <lhongliang@vmware.com> Co-authored-by: Weiqiang Tang <tangweiqiang@hotmail.com>
b3f7331
to
c3705b8
Compare
/test-all |
/test-ipv6-conformance |
Quick question: I noticed that in
And on
Should flows with another two IPs below also need to be installed?
|
@GraysonWu , it may be a little complicated. We can see the flow The above flow is used to match the first packet of NodePort connections from Antrea gateway (the first packet of NodePort has been DNAT'd with the virtual IP For other flows:
The above flows are used to match the first packet of NodePort connections from Pods on local Node. For example, Pod A on Node whose internal IP is 192.168.77.101 accesses a Service NodePort (assumed that the NodePort port is 30000, then the URL should be 192.168.77.101:30000). The first packet of NodePort connections will hit the flow
In sum, NodePort connections from Pods on local Node to NodePort with IPs of the local Node can be done via a quick path within OVS pipeline. Flows in table |
Since a SNAT ct zone is added in PR antrea-io#2599, hairpin Service traffic can make use of the SNAT ct zone instead of current stateless SNAT by modifying source and destination IPs. By removing hairpin table ServiceHairpinTable and HairpinSNATTable, the OVS pipeline can be simpler. Pipeline modifications: - Remove table serviceHairpinTable #23. - Remove table HairpinSNATTable #108. - Add table hairpinMarkTable #81 after table l2ForwardingCalcTable #80. When a local Endpoint is referenced by a Service, then a flow that matches the packet whose input and output interfaces are the same and makes mark HairpinRegMark, will be installed on table hairpinMarkTable. Packets with mark HairpinRegMark will be performed SNAT with Antrea gateway IP on table snatConntrackCommitTable. Signed-off-by: Hongliang Liu <lhongliang@vmware.com>
Since a SNAT ct zone is added in PR antrea-io#2599, hairpin Service traffic can make use of the SNAT ct zone instead of current stateless SNAT by modifying source and destination IPs. By removing hairpin table ServiceHairpinTable and HairpinSNATTable, the OVS pipeline can be simpler. Pipeline modifications: - Remove table serviceHairpinTable #23. - Remove table HairpinSNATTable #108. - Add table hairpinMarkTable #81 after table l2ForwardingCalcTable #80. When a local Endpoint is referenced by a Service, then a flow that matches the packet whose input and output interfaces are the same and makes mark HairpinRegMark, will be installed on table hairpinMarkTable. Packets with mark HairpinRegMark will be performed SNAT with Antrea gateway IP on table snatConntrackCommitTable. Signed-off-by: Hongliang Liu <lhongliang@vmware.com>
Since a SNAT ct zone is added in PR antrea-io#2599, hairpin Service traffic can make use of the SNAT ct zone instead of current stateless SNAT by modifying source and destination IPs. By removing hairpin table ServiceHairpinTable and HairpinSNATTable, the OVS pipeline can be simpler. Pipeline modifications: - Remove table serviceHairpinTable #23. - Remove table HairpinSNATTable #108. - Add table hairpinMarkTable #81 after table l2ForwardingCalcTable #80. When a local Endpoint is referenced by a Service, then a flow that matches the packet whose input and output interfaces are the same and makes mark HairpinRegMark, will be installed on table hairpinMarkTable. Packets with mark HairpinRegMark will be performed SNAT with Antrea gateway IP on table snatConntrackCommitTable. Signed-off-by: Hongliang Liu <lhongliang@vmware.com>
Since a SNAT ct zone is added in PR antrea-io#2599, hairpin Service traffic can make use of the SNAT ct zone instead of current stateless SNAT by modifying source and destination IPs. By removing hairpin table ServiceHairpinTable and HairpinSNATTable, the OVS pipeline can be simpler. Pipeline modifications: - Remove table serviceHairpinTable #23. - Remove table HairpinSNATTable #108. - Add table hairpinMarkTable #81 after table l2ForwardingCalcTable #80. When a local Endpoint is referenced by a Service, then a flow that matches the packet whose input and output interfaces are the same and makes mark HairpinRegMark, will be installed on table hairpinMarkTable. Packets with mark HairpinRegMark will be performed SNAT with Antrea gateway IP on table snatConntrackCommitTable. Signed-off-by: Hongliang Liu <lhongliang@vmware.com>
Since a SNAT ct zone is added in PR antrea-io#2599, hairpin Service traffic can make use of the SNAT ct zone instead of current stateless SNAT by modifying source and destination IPs. By removing hairpin table ServiceHairpinTable and HairpinSNATTable, the OVS pipeline can be simpler. Pipeline modifications: - Remove table serviceHairpinTable #23. - Remove table HairpinSNATTable #108. - Add table hairpinMarkTable #81 after table l2ForwardingCalcTable #80. When a local Endpoint is referenced by a Service, then a flow that matches the packet whose input and output interfaces are the same and makes mark HairpinRegMark, will be installed on table hairpinMarkTable. Packets with mark HairpinRegMark will be performed SNAT with Antrea gateway IP on table snatConntrackCommitTable. Signed-off-by: Hongliang Liu <lhongliang@vmware.com>
For NodePort support, an ipset is used to store NodePort IP, port and
transparent protocol in an entry IP:port,protocol. Then an iptables
entry is used to match the ipset as destination and perform DNAT with
a virtual IP. For DNAT'd packets, a routing entry is used to route
them to Antrea gateway.
For LoadBalancer support, a routing entry will be created for every
ingress IP to route the packets from remote or localhost to Antrea
gateway.
For ClusterIP support, a routing entry is always used to route the
packets of all ClusterIPs to Antrea gateway. when a new ClusterIP is
created, the destination IP block of the routing entry might be
extended to include the ClusterIP address.
To support the Service traffic of above cases, the main changes of
OVS pipeline include:
traffic.