Skip to content
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

Merged
merged 1 commit into from
Apr 8, 2021
Merged

Document Egress feature #2041

merged 1 commit into from
Apr 8, 2021

Conversation

tnqn
Copy link
Member

@tnqn tnqn commented Apr 7, 2021

For #1924

antoninbas
antoninbas previously approved these changes Apr 7, 2021
Copy link
Contributor

@antoninbas antoninbas left a 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?


#### Requirements for this Feature

This feature could only be used in "encap" mode.
Copy link
Contributor

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done, thanks

Copy link
Contributor

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.

Copy link
Member Author

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.

@antoninbas antoninbas added the kind/documentation Categorizes issue or PR as related to a documentation. label Apr 7, 2021
@antoninbas antoninbas added this to the Antrea v1.0 release milestone Apr 7, 2021
docs/feature-gates.md Show resolved Hide resolved

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
Copy link
Contributor

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?

Copy link
Member Author

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 Show resolved Hide resolved

#### Requirements for this Feature

This feature could only be used in "encap" mode.
Copy link
Contributor

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.


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.
Copy link
Contributor

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

Copy link
Contributor

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).

Copy link
Contributor

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.

Copy link
Member Author

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.

jianjuns
jianjuns previously approved these changes Apr 7, 2021
docs/feature-gates.md Show resolved Hide resolved
#### 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
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good!

Copy link
Member Author

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:

  1. 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.
  2. 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?

Copy link
Contributor

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure

@jianjuns
Copy link
Contributor

jianjuns commented Apr 8, 2021

/skip-all

@tnqn
Copy link
Member Author

tnqn commented Apr 8, 2021

Appended a newline at end of file to fix "Verify docs and spelling"

@tnqn
Copy link
Member Author

tnqn commented Apr 8, 2021

/skip-all

@tnqn tnqn merged commit bc470bf into antrea-io:main Apr 8, 2021
@tnqn tnqn deleted the egress-doc branch April 8, 2021 17:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/documentation Categorizes issue or PR as related to a documentation.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants