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.

Sign up for GitHub

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 51 additions & 0 deletions docs/feature-gates.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,7 @@ example, to enable `AntreaProxy` on Linux, edit the Agent configuration in the
| `FlowExporter` | Agent | `false` | Alpha | v0.9 | N/A | N/A | Yes | |
| `NetworkPolicyStats` | Agent + Controller | `false` | Alpha | v0.10 | N/A | N/A | No | |
| `NodePortLocal` | Agent | `false` | Alpha | v0.13 | N/A | N/A | Yes | |
| `Egress` | Agent + Controller | `false` | Alpha | v1.0 | N/A | N/A | Yes | |

## Description and Requirements of Features

Expand Down Expand Up @@ -188,3 +189,53 @@ Node with IP Address 10.10.10.10.
#### Requirements for this Feature

This feature is currently only supported for Nodes running Linux with IPv4 addresses.

### Egress

`Egress` enables a CRD API for Antrea that supports specifying which egress
(SNAT) IP the traffic from the selected Pods to the external network should use.
When a selected Pod accesses the external network, the egress traffic will be
tunneled to the Node that hosts the egress IP if it's different from the Node
that the Pod runs on and will be SNATed to the egress IP when leaving that Node.
Usage example:

```yaml
apiVersion: crd.antrea.io/v1alpha2
kind: Egress
metadata:
name: egress-web
spec:
appliedTo:
podSelector:
matchLabels:
role: web
namespaceSelector:
matchLabels:
env: prod
egressIP: 10.0.10.8
```

The `appliedTo` field specifies the grouping criteria of Pods to which the
tnqn marked this conversation as resolved.
Show resolved Hide resolved
Egress applies to. Pods can be selected cluster-wide using `podSelector`. If set
with a `namespaceSelector`, Pods from Namespaces selected by the
namespaceSelector will be selected. Empty `appliedTo` selects nothing. The field
is mandatory.

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, and one Node only. It must be reachable from
all Nodes.** For IPv4 cluster, it must be an IPv4 address; for IPv6 cluster, it
must be an IPv6 address. The field is mandatory.

**Note**: If more than one Egress applies to a Pod and they specify different
tnqn marked this conversation as resolved.
Show resolved Hide resolved
`egressIP`, the effective egress IP will be selected randomly.

In the above example, the Egress applies to Pods which match the labels
"role=web" from Namespaces which match the labels "env=prod". The source IPs of
their egress traffic to external network will be translated to 10.0.10.8.

#### 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

future.