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

Default set NATGatway for outbound traffic if cluster is not using IPv6 #3365

Merged
merged 1 commit into from
Apr 11, 2023

Conversation

xiujuanx
Copy link
Contributor

@xiujuanx xiujuanx commented Mar 27, 2023

What type of PR is this?
/kind feature

What this PR does / why we need it:
This PR sets the default subnet to be NAT gateway if the cluster is not using IPv6. It both sets AzureCluster and AzureClusterTemplate.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #1532

Special notes for your reviewer:

Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

TODOs:

  • squashed commits
  • includes documentation
  • adds unit tests

Release note:

Default use the NAT gateway for the node outbound connection if cluster is not using IPv6

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. kind/feature Categorizes issue or PR as related to a new feature. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Mar 27, 2023
@k8s-ci-robot
Copy link
Contributor

Hi @xiujuanx. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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.

@xiujuanx xiujuanx force-pushed the default-set-natgateway branch from 37b3948 to 4e4db5a Compare March 27, 2023 08:35
@willie-yao
Copy link
Contributor

/ok-to-test

@k8s-ci-robot k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Mar 27, 2023
@@ -128,6 +130,12 @@ func (c *AzureCluster) setSubnetDefaults() {
if subnet.NatGateway.NatGatewayIP.Name == "" {
subnet.NatGateway.NatGatewayIP.Name = generateNatGatewayIPName(c.ObjectMeta.Name, subnet.Name)
}
} else {
if !subnet.IsIPv6Enabled() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this if statement be outside of the else block? Looking through the issue details, it looks like the intended behavior is to set NAT Gateway by default if not using IPv6, regardless of whether a name has been provided or not.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks @willie-yao for your review! I think put the statement be outside of the else block is ok.
For a subnet, if the NAT gateway name is provided, this means NAT gateway has beed enabled, we don't need to set it again. If the NAT gateway name doesn't be provided, then I will go to check if it's using IPv6, if not, then I will set NAT gateway by default, otherwise, I will keep the original subnet settings and do nothing.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah that makes sense, thanks for the detailed explanation!

Copy link
Contributor

Choose a reason for hiding this comment

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

instead of adding an else condition here with another nested if loop, have you considered directly modifying the conditions for which IsNatGatewayEnabled returns true? and setting the name in NAT gateway name in the block above when it's not already set. This would avoid duplicate code of setting the IP name and nested if/else statements.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@CecileRobertMichon Thanks for your review! Indeed, there has a duplicate code for setting NAT gateway IP name. But if I modify the condition of IsNatGatewayEnabled and set the name of NAT gateway name if it's not set yet in this func, then I need to call generateNatGatewayName func in type.go file. This will cause an inconsistency from current CAPZ codes in main branch. Although this does not cause any logical problems, it just looks less elegant formally. So I prefer to judge if this is a IPv6 cluster first, then go to judge if IsNatGatewayEnabled or not. This will also avoid duplication. Does this make sense?

@xiujuanx xiujuanx force-pushed the default-set-natgateway branch 2 times, most recently from 6d78d72 to 950a4b1 Compare March 28, 2023 02:41
@xiujuanx xiujuanx requested review from willie-yao and removed request for Jont828 March 28, 2023 02:42
@xiujuanx xiujuanx force-pushed the default-set-natgateway branch from 950a4b1 to 81f8811 Compare March 28, 2023 07:34
@willie-yao
Copy link
Contributor

/lgtm

Apologies for the delay. Thanks for getting back to me about the tests! This looks great and thanks for the great work on this @xiujuanx

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Apr 3, 2023
@k8s-ci-robot
Copy link
Contributor

LGTM label has been added.

Git tree hash: 06fdafa7548ee8271626444a141eec984b95f517

@xiujuanx
Copy link
Contributor Author

xiujuanx commented Apr 4, 2023

@willie-yao Thanks for your kind review! Does this pr can be approved now?

@willie-yao
Copy link
Contributor

@xiujuanx Yes, pinging approvers for a review. @CecileRobertMichon @mboersma @jackfrancis

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. and removed cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Apr 9, 2023
@xiujuanx xiujuanx force-pushed the default-set-natgateway branch from 1cb71ab to e60f052 Compare April 9, 2023 08:24
@k8s-ci-robot k8s-ci-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Apr 9, 2023
@xiujuanx
Copy link
Contributor Author

xiujuanx commented Apr 9, 2023

/test pull-cluster-api-provider-azure-capi-e2e

1 similar comment
@xiujuanx
Copy link
Contributor Author

/test pull-cluster-api-provider-azure-capi-e2e

Copy link
Contributor

@CecileRobertMichon CecileRobertMichon left a comment

Choose a reason for hiding this comment

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

/retest

#3403 should fix the broken test

/lgtm
/approve

Thanks @xiujuanx, great work!

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Apr 10, 2023
@k8s-ci-robot
Copy link
Contributor

LGTM label has been added.

Git tree hash: 94d9a623e850934f5343b9da8f99f8c1f94570bf

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: CecileRobertMichon

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 10, 2023
@sonasingh46
Copy link
Contributor

Late to party on this PR.
What happens in upgrade scenario when the cluster already have chosen a load balancer. Does it silently ignore it?

@CecileRobertMichon
Copy link
Contributor

/hold

to answer @sonasingh46's question above

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 10, 2023
@CecileRobertMichon
Copy link
Contributor

What happens in upgrade scenario when the cluster already have chosen a load balancer. Does it silently ignore it?

This is only changing the webhook default so it shouldn't affect existing clusters AFAIK

Copy link
Contributor

@willie-yao willie-yao left a comment

Choose a reason for hiding this comment

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

/lgtm

Thanks again for all the great work on this PR! 🚀

@sonasingh46
Copy link
Contributor

@CecileRobertMichon -- Thanks. I am just thinking about the following scenario.

  • Prior to this change, a user can have an existing cluster that uses load balancer because of the defaults. If NAT gateway is not specified by default then load balancer is chosen.

  • With this change, if NAT gateway is not specified and if it is not IPV6 then it uses NAT gateway by default now.

  • So as far as compatibility is concerned, nothing breaks and all works fine but I am thinking if we should have a way to migrate away from load balancer and choose NAT gateway.

  • Now, IIRC the migration was not possible earlier also so I think this discussion is out of scope of the PR.

@sonasingh46
Copy link
Contributor

/lgtm

@CecileRobertMichon
Copy link
Contributor

@sonasingh46 I think the migration would be possible but the user would have to opt in (i.e. edit the resource and specify a NAT), have not tested this though.

agree it's out of scope for this PR

/hold cancel

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 10, 2023
@CecileRobertMichon
Copy link
Contributor

@sonasingh46 I think the migration would be possible but the user would have to opt in (i.e. edit the resource and specify a NAT), have not tested this though.

agree it's out of scope for this PR

/hold cancel

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/feature Categorizes issue or PR as related to a new feature. lgtm "Looks good to me", indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Use only nat gateway for outbound connections
6 participants