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

IPv6 Support #1587

Merged
merged 8 commits into from
Sep 20, 2021
Merged

IPv6 Support #1587

merged 8 commits into from
Sep 20, 2021

Conversation

achevuru
Copy link
Contributor

What type of PR is this?
Feature

Which issue does this PR fix:
PR introduces IPv6 support for AWS VPC CNI.

What does this PR do / Why do we need it:
VPC CNI currently doesn't have the capability to support IPv6 based workloads/pods. PR introduces AWS VPC native IPv6 networking support for K8S Pods. It also provides the capability for Egress v4 access for IPv6 enabled pods.

If an issue # is not available please add repro steps and logs from IPAMD/CNI showing the issue:
N/A

Testing done on this change:
Below scenarios are tests in IPv6 Mode.

  • Pod to Pod.
  • Pod to Node and vice versa.
  • Pod to API Server over IPv6.
  • Pod to Service endpoints (ClusterIP Mode).
  • Node Port support
  • Pod to Egress v6 and v4 endpoints.

Automation added to e2e:
PR includes UT support. Will send out a separate PR for e2e automation tests.

Will this break upgrades or downgrades. Has updating a running cluster been tested?:
Upgrading a current IPv4 cluster to IPv6 mode will not be supported.

Does this change require updates to the CNI daemonset config files to work?:
Yes.

If this change does not work with a "kubectl patch" of the image tag, please explain why.
PR introduces support for two new environment variables - ENABLE_IPv4 and ENABLE_IPv6. These env variables have to be configured based on the requirement.

Does this PR introduce any user-facing change?:
Yes. User has to explicitly enable either IPv4 or IPv6 mode. Default VPC CNI manifests will enable IPv4 by default.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Copy link
Contributor

@anguslees anguslees left a comment

Choose a reason for hiding this comment

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

This is a big chunk of code, nice work.

cmd/routed-eni-cni-plugin/driver/driver.go Outdated Show resolved Hide resolved
cmd/routed-eni-cni-plugin/driver/driver.go Outdated Show resolved Hide resolved
cmd/routed-eni-cni-plugin/driver/driver.go Outdated Show resolved Hide resolved
cmd/routed-eni-cni-plugin/driver/driver.go Outdated Show resolved Hide resolved
cmd/routed-eni-cni-plugin/driver/driver.go Outdated Show resolved Hide resolved
pkg/awsutils/imds_test.go Show resolved Hide resolved
pkg/awsutils/awsutils.go Show resolved Hide resolved
pkg/awsutils/awsutils.go Outdated Show resolved Hide resolved
cmd/egress-v4-cni-plugin/snat/snat.go Outdated Show resolved Hide resolved
cmd/egress-v4-cni-plugin/cni.go Outdated Show resolved Hide resolved
Copy link
Contributor

@anguslees anguslees left a comment

Choose a reason for hiding this comment

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

Looks good to me. One minor-but-important compatibility issue for the rpc proto field numbers, then I think we're good to merge 🎉

rpc/rpc.proto Outdated Show resolved Hide resolved
rpc/rpc.proto Outdated
@@ -34,7 +38,9 @@ message AddNetworkReply {
int32 ParentIfIndex = 10;
// end of pod-eni parameters

// next field: 11
repeated string VPCv6CIDRs = 11;
Copy link
Contributor

Choose a reason for hiding this comment

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

Super-minor: I wouldn't bother mentioning it, but if you're going to edit this file again anyway (to give IPv6Addr a new field ID), then it would be nice to put VPCv6CIDRs next to VPCv4CIDRs for readability (still with =6 and =11 field IDs)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, I can do that.

Copy link
Contributor

@anguslees anguslees left a comment

Choose a reason for hiding this comment

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

🎉

@achevuru achevuru merged commit 88c1223 into aws:master Sep 20, 2021
c.enableIpv4PrefixDelegation = false
//Let's validate if the configured combination of env variables is supported before we
//proceed any further
if !c.isConfigValid() {
Copy link
Contributor

@jayanthvn jayanthvn Sep 20, 2021

Choose a reason for hiding this comment

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

We might either have to set ENABLE_IPv4 -> true by default or generate two manifests for v4 and v6 with ENABLE_IPv4=true in v4 manifest and ENABLE_IPv6=true in v6 manifest. Since if anyone builds based of master then aws-node will fail to start because both variables will be missing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We will include the new env vars in the default manifest.

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed but this will fail nightly integration test :(

Copy link
Contributor

Choose a reason for hiding this comment

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

So the default manifest will have v4 set to true?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, v4 will be enabled by default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants