WIP: Add support for dual stack load balancers#1313
WIP: Add support for dual stack load balancers#1313nrb wants to merge 6 commits intokubernetes:masterfrom
Conversation
|
Skipping CI for Draft Pull Request. |
|
This issue is currently awaiting triage. If cloud-provider-aws contributors determine this is a relevant issue, they will accept it by applying the The DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/test pull-cloud-provider-aws-test |
|
Hey @kmala do we know what's happening with the Netlify checks? It looks like they are broken across many open PRs. TY |
|
/retest |
1 similar comment
|
/retest |
|
/retest |
|
/test pull-cloud-provider-aws-test One more run to see if this is a rate limiting issue or some sort of genuine issue with my code. |
tthvo
left a comment
There was a problem hiding this comment.
I tested with a simple service below:
apiVersion: v1
kind: Service
metadata:
name: wordpress-mysql
labels:
app: wordpress
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: nlb
service.beta.kubernetes.io/aws-load-balancer-ip-address-type: dualstack
spec:
ipFamilyPolicy: PreferDualStack
ports:
- port: 3306
selector:
app: wordpress
type: LoadBalancerThe CCM does create the dualstack NLB as expected 🚀
$ kubectl -n myns get svc/wordpress-mysql -o yaml | yq .status.loadBalancer.ingress
- hostname: <id>.elb.us-east-1.amazonaws.com
$ nslookup <id>.elb.us-east-1.amazonaws.com
# nslookup shows both public IPv4 EIP and IPv6 GUA addresses
$ aws elbv2 describe-load-balancers --names=<nlb-id> --query='LoadBalancers[0].[Type,IpAddressType,Scheme]'
[
"network",
"dualstack",
"internet-facing"
]|
/test pull-cloud-provider-aws-test |
|
/test pull-cloud-provider-aws-test |
|
/test pull-cloud-provider-aws-check |
|
/test pull-cloud-provider-aws-test |
|
@kmala I'm going to do some manual testing with this PR starting today before I mark it as ready for review, but would you be able to give it a look by any chance? |
tthvo
left a comment
There was a problem hiding this comment.
I just have a few questions 🙏 But overall, I think we are having great progress!
| err = c.updateInstanceSecurityGroupsForNLB(ctx, loadBalancerName, instances, subnetCidrs, sourceRangeCidrs, v2Mappings) | ||
| if err != nil { | ||
| klog.Warningf("Error opening ingress rules for the load balancer to the instances: %q", err) | ||
| return nil, err | ||
| } |
There was a problem hiding this comment.
We should consider/allow IPv6 CIDRs when updating the instance's security groups (to allow traffic from NLB), right? IIUC, there are 2 types of CIDRs here:
sourceRangeCidrs: Already defined on line 2396-2405subnetCidrs: IPv6 CIDRs can be extracted from subnet info returned by AWS.
There was a problem hiding this comment.
I guess that means we need to update the following functions to set the Ipv6Range field correctly?
pkg/providers/v1/aws_loadbalancer.go
Outdated
| if service.Spec.IPFamilyPolicy != nil && *service.Spec.IPFamilyPolicy == v1.IPFamilyPolicySingleStack { | ||
| if serviceRequestsIPv6(service) { | ||
| return nil, fmt.Errorf("single stack IPv6 is not supported for network load balancers") | ||
| } | ||
| } |
There was a problem hiding this comment.
I wonder if we can:
- Place this validation in pkg/providers/v1/aws_validations.go
- Additionally, we should add a validation that only allows dualstack settings (i.e.
ipFamilies: [IPv4, IPv6],ipFamilyPolicy: RequireDualStack) when LB type is NLB.
WDYT?
|
|
||
| Some limitations to be aware of when using dual stack load balancers: | ||
|
|
||
| - The `spec.ipFamilies` field can have a second family added or removed, but the first entry is immutable after Service creation. |
There was a problem hiding this comment.
Maybe, we should mention what would happen if the secondary family is removed? Like what will be the state of:
- The Load Balancer
- The Security Groups (those for LB and those for instances)
- Target Group
- (Optional) Listeners
| - IPv6 | ||
| - IPv4 |
There was a problem hiding this comment.
nit: The list indentation is a lot more than usual. Let's format it a bit 😁
|
/retest |
|
/test pull-cloud-provider-aws-e2e-kubetest2-quick |
1 similar comment
|
/test pull-cloud-provider-aws-e2e-kubetest2-quick |
|
/test pull-cloud-provider-aws-test |
|
Current e2e failure is legit - the provisioned cluster is not set up for IPv6. Will work on getting support for that plumbed in to kubetest-ec2. |
|
I've opened a PR against kubetest2-ec2 in order to provide an IPv6-capable subnet to CI. |
- Create load balancers according to the Kubernetes Service API Signed-off-by: Nolan Brubaker <nolan@nbrubaker.com> Assisted-by: Claude Sonnet 4.5 <noreply@anthropic.com>
Signed-off-by: Nolan Brubaker <nolan@nbrubaker.com>
Signed-off-by: Nolan Brubaker <nolan@nbrubaker.com>
Changing the IP address type would invalidate the target group name, because you cannot have an IPv4 and IPv6 target for the same port/protocol set. Signed-off-by: Nolan Brubaker <nolan@nbrubaker.com>
Signed-off-by: Nolan Brubaker <nolan@nbrubaker.com>
Signed-off-by: Nolan Brubaker <nolan@nbrubaker.com>
|
@nrb: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Adds basic support for configuring the IP address family on Services.
This functionality overlaps with the ALBC somewhat, but the goal here is to provide much more basic functionality, not the full scope of ALBC.
Which issue(s) this PR fixes:
Fixes #1219
Special notes for your reviewer:
Does this PR introduce a user-facing change?: