-
Notifications
You must be signed in to change notification settings - Fork 368
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
Update Egress API to support multiple Egress IPs and pools #4603
Conversation
Codecov Report
@@ Coverage Diff @@
## main #4603 +/- ##
==========================================
- Coverage 71.99% 68.87% -3.12%
==========================================
Files 406 403 -3
Lines 60856 59797 -1059
==========================================
- Hits 43812 41187 -2625
- Misses 14132 15773 +1641
+ Partials 2912 2837 -75
*This pull request uses carry forward flags. Click here to find out more.
|
62ccdf8
to
4f70047
Compare
7e3fedc
to
5ee642c
Compare
5e847e1
to
567e2b3
Compare
/test-all |
/test-all |
/test-all |
// ExternalIPPool specifies the IP Pool that the EgressIP should be allocated from. | ||
// If it is empty, the specified EgressIP must be assigned to a Node manually. | ||
// If it is non-empty, the EgressIP will be assigned to a Node specified by the pool automatically and will failover | ||
// to a different Node when the Node becomes unreachable. | ||
ExternalIPPool string `json:"externalIPPool"` | ||
ExternalIPPool string `json:"externalIPPool,omitempty"` |
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.
Maybe we can deprecate this field in a future release?
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 you mean both EgressIP and ExternalIPPool, the singular fields?
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.
Yes.
@@ -213,11 +216,18 @@ type EgressSpec struct { | |||
// If ExternalIPPool is non-empty, it can be empty and will be assigned by Antrea automatically. | |||
// If both ExternalIPPool and EgressIP are non-empty, the IP must be in the pool. | |||
EgressIP string `json:"egressIP,omitempty"` | |||
// EgressIPs specifies multiple SNAT IP addresses for the selected workloads. |
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 require each IP must be from different ExternalIPPools?
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.
We probably should check the uniqueness of the pools because:
- Using same ExternalIPPools multiple times is meaningless
- It may cause trouble to the implementation, e.g. we might use map to track pool -> ip allocation.
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.
Ok. Would you add comments for that?
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 the comment of ExternalIPPools
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.
Should we say IPs must be in ExternalIPPools? And move "Entries with the same index in EgressIPs and ExternalIPPools are correlated." 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.
But we could also support IPs not allocated from pools. For example, users could get HA support when they have two Nodes that have public access and just use two Node IPs as the Egress IPs 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.
@jianjuns If there are more comments about the fields' comment, we could update with a following up PR or when we officially support multiple IPs. I will merge it first to proceed.
Nodes in a cluster could reside in multiple subnets, but the egress IP needs to be routable in the underlay network and usually resides in the same subnet of the Node hosting it. Therefore, there may be a situation where no available nodes are eligible to host an egress IP address if all Nodes in a subnet are down, interrupting egress traffic of the workloads that use the IP. As the first step of supporting the above scenario, the patch extends the Egress IP to support multiple Egress IPs and pools so that one Egress IP can be configured for each subnet, making Egress failover across the whole cluster possible. Besides, it also adds a field, `status.egressIP`, to represent the effective Egress IP. When there is no eligible Node for any of the Egress IPs, the field will be empty. Signed-off-by: Quan Tian <qtian@vmware.com>
@@ -213,11 +216,18 @@ type EgressSpec struct { | |||
// If ExternalIPPool is non-empty, it can be empty and will be assigned by Antrea automatically. | |||
// If both ExternalIPPool and EgressIP are non-empty, the IP must be in the pool. | |||
EgressIP string `json:"egressIP,omitempty"` | |||
// EgressIPs specifies multiple SNAT IP addresses for the selected workloads. |
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.
Should we say IPs must be in ExternalIPPools? And move "Entries with the same index in EgressIPs and ExternalIPPools are correlated." here?
/skip-all |
…#4603) Nodes in a cluster could reside in multiple subnets, but the egress IP needs to be routable in the underlay network and usually resides in the same subnet of the Node hosting it. Therefore, there may be a situation where no available nodes are eligible to host an egress IP address if all Nodes in a subnet are down, interrupting egress traffic of the workloads that use the IP. As the first step of supporting the above scenario, the patch extends the Egress IP to support multiple Egress IPs and pools so that one Egress IP can be configured for each subnet, making Egress failover across the whole cluster possible. Besides, it also adds a field, `status.egressIP`, to represent the effective Egress IP. When there is no eligible Node for any of the Egress IPs, the field will be empty. Signed-off-by: Quan Tian <qtian@vmware.com>
…#4603) Nodes in a cluster could reside in multiple subnets, but the egress IP needs to be routable in the underlay network and usually resides in the same subnet of the Node hosting it. Therefore, there may be a situation where no available nodes are eligible to host an egress IP address if all Nodes in a subnet are down, interrupting egress traffic of the workloads that use the IP. As the first step of supporting the above scenario, the patch extends the Egress IP to support multiple Egress IPs and pools so that one Egress IP can be configured for each subnet, making Egress failover across the whole cluster possible. Besides, it also adds a field, `status.egressIP`, to represent the effective Egress IP. When there is no eligible Node for any of the Egress IPs, the field will be empty. Signed-off-by: Quan Tian <qtian@vmware.com>
Nodes in a cluster could reside in multiple subnets, but the egress IP needs to be routable in the underlay network and usually resides in the same subnet of the Node hosting it. Therefore, there may be a situation where no available nodes are eligible to host an egress IP address if all Nodes in a subnet are down, interrupting egress traffic of the workloads that use the IP.
As the first step of supporting the above scenario, the patch extends the Egress IP to support multiple Egress IPs and pools so that one Egress IP can be configured for each subnet, making Egress failover across the whole cluster possible.
Besides, it also adds a field,
status.egressIP
, to represent the effective Egress IP. When there is no eligible Node for any of the Egress IPs, the field will be empty.