-
Notifications
You must be signed in to change notification settings - Fork 372
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
Document Egress feature #2041
Document Egress feature #2041
Conversation
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
I think I would just recommend clarifying what "IP configured on one Node" means by just saying that it means an IP assign to an arbitrary interface of the Node (and that it is unrelated to the Node Addresses in the K8s API).
I know this is more of an implementation detail, but since this is our only documentation for this so far, do you think we should add a sentence about how egress traffic will be forwarded on the overlay to the Node configured with the egress IP?
docs/feature-gates.md
Outdated
|
||
#### Requirements for this Feature | ||
|
||
This feature could only be used in "encap" mode. |
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.
s/could only/can only
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.
done, thanks
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.
Hybrid mode should work too? Even noEncap and policyOnly if we tunnel egress traffic, and reduce MTU.
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.
Sure, updated the doc to say it's just "currently" not supported.
docs/feature-gates.md
Outdated
|
||
The `egressIP` field specifies the egress (SNAT) IP the traffic from the | ||
selected Pods to the external network should use. **The IP must be configured | ||
on one and only one Node of the cluster.** It can be an IPv4 address or IPv6 |
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.
For IPv4 cluster, it must be IPv4; for IPv6 it must be IPv6.
Do we support dual-stack?
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 theory it supports dual-stack but I haven't verified it.
docs/feature-gates.md
Outdated
|
||
#### Requirements for this Feature | ||
|
||
This feature could only be used in "encap" mode. |
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.
Hybrid mode should work too? Even noEncap and policyOnly if we tunnel egress traffic, and reduce MTU.
docs/feature-gates.md
Outdated
|
||
The `egressIP` field specifies the egress (SNAT) IP the traffic from the | ||
selected Pods to the external network should use. **The IP must be assigned to | ||
an arbitrary interface of one Node.** It can be an IPv4 address or IPv6 address. |
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.
The IP must be assigned to an arbitrary interface of one Node, and one Node only
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 assume we need an another user doc? There can be other details to add. For example, the IP must be reachable from all Nodes (as we tunnel to that IP).
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 this is a requirement we should list here. I'm unfamiliar with the implementation so I was assuming we were tunneling using the K8s Node IP, not the SNAT IP.
Another more detailed document (with a diagram for example) may be useful, but it's fine to tackle that after the release IMO.
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.
Added the requirement about reachability, agree we could have a separate doc to describe the implementation later.
#### Requirements for this Feature | ||
|
||
This feature is currently only supported for Nodes running Linux and "encap" | ||
mode. The support for Windows and other traffic modes will be added in the |
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 you believe it does not work for hybrid now? I thought it should work.
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 think it again and agree it should work. I could test it later and update the doc after verifying it.
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.
Sounds good!
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.
@jianjuns It didn't work for two Nodes in same subnet in hybrid case. The reason is:
- After the request packet is tunneled to the Egress Node and sent to its host network, reverse path filtering will drop the packet as the traffic comes from antrea-gw0 while it's on a route of one physical interface like eth0. rp_filter is set to strict mode in some distributions like ubuntu. Changing it to loose mode can resolve this.
- After the reply packet is received on the Egress Node, it will output the packet to the physical interface that has route to the Pod network, e.g. eth0, instead of antrea-gw0, leading to asymmetric path.
I will file an issue to discuss how to make it work for hybrid mode, and maybe route mode together. For this release, guess we don't have time to support it for hybrid mode. Do you agree?
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.
Got it. Let us think about any solution. I think the feature can be useful for hybrid mode and encap mode too.
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.
sure
/skip-all |
Appended a newline at end of file to fix "Verify docs and spelling" |
/skip-all |
For #1924