-
Notifications
You must be signed in to change notification settings - Fork 314
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
Add support for IPv6 Fargate nodes #565
Conversation
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 Instructions 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/test-infra repository. |
Hi @HusainZafar. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions 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/test-infra repository. |
/lgtm |
@rsumukha: changing LGTM is restricted to collaborators In response to this:
Instructions 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/test-infra repository. |
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.
Fargate is dualstack isn't it? So I think I'd like to see more cases for that behaving consistently with EC2.
pkg/providers/v1/aws.go
Outdated
return getNodeAddressesForFargateNode(aws.StringValue(eni.PrivateDnsName), aws.StringValue(eni.PrivateIpAddress)), nil | ||
|
||
// Assign NodeInternalIP based on IP family | ||
if eni.Ipv6Addresses != nil { |
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.
Does this mean node IPs are either/or? I think this needs to respect c.cfg.Global.NodeIPFamilies
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 PR to set the IP based on NodeIPFamilies consistent with EC2 nodes and verified that the addresses field with cloud provider is consistent with addresses field without cloud provider enabled for Fargate nodes
/ok-to-test |
nodeAddresses := getNodeAddressesForFargateNode(aws.StringValue(eni.PrivateDnsName), aws.StringValue(eni.PrivateIpAddress)) | ||
addresses = append(addresses, nodeAddresses...) | ||
case "ipv6": | ||
internalIPv6Address := eni.Ipv6Addresses[0].Ipv6Address |
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.
Even if the NodeIPFamily is set to ipv6, I wonder if its possible for the ENI to not have IPv6 addresses due to a misconfiguration or something. Can we check to make sure the addresses exist and handle a failure case before referencing the first item in the list 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.
Ack, added a check to make sure Ipv6Addresses is not missing or empty
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 sounds good, but one more question... is it better to return an error here or to just log it and move forward with non-ipv6 addresses? I'm thinking maybe best effort is better here because in some world (even if not supported today with fargate) could there be both ipv4 and ipv6 address NodeIPFamilies set, and in that case we'd still want to return the ipv4 addresses.
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.
Valid point for that use case, I have updated to log the error and return the existing addresses
/release-note-none |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: nckturner The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/hold |
@HusainZafar will you squash you commits please? |
102f59f
to
3997ec7
Compare
/lgtm |
/unhold |
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR adds support for IPv6 Fargate nodes by assigning the right NodeInternalIP based on IP family
Which issue(s) this PR fixes:
NONE
Special notes for your reviewer:
This code doesn't change anything for EC2 worker nodes
Does this PR introduce a user-facing change?:
No