-
Notifications
You must be signed in to change notification settings - Fork 386
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
Support NodePortLocal on Antrea Windows Agent and Update NPL annotation #3453
Conversation
Codecov Report
@@ Coverage Diff @@
## main #3453 +/- ##
==========================================
- Coverage 62.20% 57.37% -4.84%
==========================================
Files 281 398 +117
Lines 40096 55954 +15858
==========================================
+ Hits 24941 32102 +7161
- Misses 13190 21351 +8161
- Partials 1965 2501 +536
Flags with carried forward coverage won't be shown. Click here to find out more.
|
c302ab1
to
75c12d5
Compare
/test-e2e |
2764a37
to
720288a
Compare
/test-windows-all |
/test-windows-e2e |
@@ -18,28 +18,31 @@ | |||
package nodeportlocal |
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.
do we still need this file? it seems to be pretty much the same as npl_agent_init.go
now. I think you just need to remove the //go:build !windows
tag in npl_agent_init.go
.
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.
Updated, thanks.
// PrepareAddRule closes socket on Windows before inserting NetNatStaticMapping rules. | ||
func PrepareAddRule(protocolSocketData *ProtocolSocketData) error { | ||
if err := protocolSocketData.socket.Close(); err != nil { | ||
return fmt.Errorf("Windows socket close failed %v", err) | ||
} | ||
return nil | ||
} |
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.
This seems quite hacky to me.
On Linux, we open a socket to ensure that the port is reserved for this specific mapping, as otherwise it would be possible for another process to use the port (the DNAT iptables rule doesn't "reserve" the port).
If on Windows, inserting a NetNatStaticMapping rule means that the port cannot be used by any other process, then there is no need to open a socket at all.
I don't know if it is exactly the same thing, but the inspiration from this comes from the kube-proxy iptables & IPVS implementations, which open a socket to reserve ports. However, there is no equivalent for the kube-proxy winkernel implementation.
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.
@antoninbas NPL will try to listen to a port during getting free port stage.The reason to reserve the port is to make sure the free port is avaliable until inserting NetNatStaticMapping rules. Otherwise other processes are more likely to occupy the allocated port in advance, which causes the rule insertion to fail. I also had an discussion about this implementation with Wenying, @wenyingd do you have other comments here?
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.
I don't understand. I would say that if the NetNatStaticMapping
rule insertion fails, you just need to try with the next port, and so on. This is not so different from trying to open a socket first: if the port is not available, it will fail, and we try with the next port.
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.
If NetNatStaticMapping insertion fails, the reason is not necessarily that the port is invalid. But if the port can be listened and NetNatStaticMapping insertion still fails we can make troubleshooting easier.
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.
So, we cannot know the reason after NetNatStaticMapping fails? I also feel creating a socket is not worthwhile.
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.
I agree to create NetNatStaticMapping directly to for a free port chosen.
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.
Thanks for all comments. After discussion I agree it is not necessary to open socket in Windows. The result of rule insertion/deletion can be used by port reservation. PR updated.
66ce016
to
edeb9bd
Compare
/test-windows-e2e |
/test-integration |
1 similar comment
/test-integration |
This pull request introduces 1 alert and fixes 1 when merging 4ead74e into 7487453 - view on LGTM.com new alerts:
fixed alerts:
|
It feels to me that we are not preserving exactly the Linux legacy behavior though: while we are still allocating the same nodePort value for UDP & TCP when the podPort is the same, we are now generating 2 distinct Pod annotations instead of 1. Given this change, I think it would have been ok to unify the implementations from the get-go. That being said, if you prefer to do it in a follow-up PR, that's fine by me. |
@antoninbas Thanks, the "legacy behavior" I mentioned does mean that allocating the same nodePort value when the podPort is the same, and annotation format is the same for both Linux and Windows. |
This pull request introduces 1 alert and fixes 1 when merging b699ba2 into 9425c61 - view on LGTM.com new alerts:
fixed alerts:
|
@XinShuYang could you resolve conflict so we can merge? |
This pull request introduces 1 alert and fixes 1 when merging e35ac0c into 58f17de - view on LGTM.com new alerts:
fixed alerts:
|
/test-all |
@tnqn Updated, thanks. |
@wenyingd could you confirm code is expected after rebasing? I will merge it with your approval. |
/test-integration |
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.
overall LGTM, one minor comment.
pkg/agent/util/net.go
Outdated
@@ -36,6 +38,8 @@ const ( | |||
|
|||
FamilyIPv4 uint8 = 4 | |||
FamilyIPv6 uint8 = 6 | |||
|
|||
AntreaNatName = "antrea-nat" |
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.
Move it to net_windows.go
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.
Updated, thanks.
* Support NodePortLocal rules on by using NetNatStaticMapping on windows * Support NPL agent on Windows platform * Require the same Antrea NPL configuration as Linux issue antrea-io#3826 Signed-off-by: Shuyang Xin <gavinx@vmware.com>
Currently mutateAntreaConfigMap can only support linux agent configmap. This patch will support windows configmap processing. issue antrea-io#3826 Signed-off-by: Shuyang Xin <gavinx@vmware.com>
Add related image to support more e2e tests on windows. Signed-off-by: Shuyang Xin <gavinx@vmware.com>
* Add NPL Netnat rules check on windows * Replace busybox with agnhost as the client pod * Still skip windows test by default due to the ovs HNSCall issue issue antrea-io#3826 Signed-off-by: Shuyang Xin <gavinx@vmware.com>
* Add protocol string to new NPLAnnotation set the protocols map as a deprecated value. * Support Node port for UDP and TCP using the different number for a single Pod on Windows. issue antrea-io#3826 Signed-off-by: Shuyang Xin <gavinx@vmware.com>
* Update annotation example with new protocol field. * Update NPL windows support feature. Signed-off-by: Shuyang Xin <gavinx@vmware.com>
/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.
LGTM
This pull request introduces 1 alert and fixes 1 when merging a377b57 into f8559ec - view on LGTM.com new alerts:
fixed alerts:
|
/test-windows-networkpolicy |
/test-conformance |
1 similar comment
/test-conformance |
Signed-off-by: Shuyang Xin gavinx@vmware.com