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

Create an Internal Load Balancer if configured #1222

Merged
merged 1 commit into from
May 29, 2024

Conversation

bfournie
Copy link
Contributor

@bfournie bfournie commented May 1, 2024

What type of PR is this?
/kind feature

What this PR does / why we need it:
Provide the ability to configure the types of Load Balancers to be created (Internal and/or External). By default, an External Proxy Load Balancer will be created per the current implementation. If set for an Internal Load Balancer, an Internal Passthrough Load Balancer will be created using resources in the specified region.

Which issue(s) this PR fixes :
Fixes #1221

Special notes for your reviewer:

TODOs:

  • [x ] squashed commits
  • [x ] includes documentation
  • [ x] adds unit tests

Release note:
-->

Added a new `LoadBalancerTypes` field to `LoadBalancerSpec` that defines the type of Load Balancers (External or Internal) which should be created. By default a Global External Proxy Load Balancer will be created as is currently implemented. 
Also added an `InternalLoadBalancer` field to optionally configure the name and subnet of the Internal Load Balancer.

@k8s-ci-robot k8s-ci-robot added kind/feature Categorizes issue or PR as related to a new feature. do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels May 1, 2024
@k8s-ci-robot
Copy link
Contributor

Hi @bfournie. 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.

@k8s-ci-robot k8s-ci-robot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label May 1, 2024
@k8s-ci-robot k8s-ci-robot requested review from cpanato and dims May 1, 2024 15:42
@k8s-ci-robot k8s-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label May 1, 2024
Copy link

netlify bot commented May 1, 2024

Deploy Preview for kubernetes-sigs-cluster-api-gcp ready!

Name Link
🔨 Latest commit 1a8192b
🔍 Latest deploy log https://app.netlify.com/sites/kubernetes-sigs-cluster-api-gcp/deploys/665728d33ad9e600085b37ff
😎 Deploy Preview https://deploy-preview-1222--kubernetes-sigs-cluster-api-gcp.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. labels May 1, 2024
Copy link
Member

@cpanato cpanato left a comment

Choose a reason for hiding this comment

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

/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 May 2, 2024
@bfournie bfournie force-pushed the internal-load-balancer branch 3 times, most recently from 2d101b7 to e312d9c Compare May 2, 2024 20:19
// APIInternalAddress is the IPV4 regional address assigned to the
// internal Load Balancer.
// +optional
APIInternalAddress *string `json:"apiInternalIpAddress,omitempty"`
Copy link

Choose a reason for hiding this comment

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

I understand that this is a breaking change, but should we consider a structure to hold these values? The added values are the same as those for the api server, so a lot of duplicated values appear.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The main reason I didn't do that was because it is a breaking change, I tried to keep the same API for consistency and just add the additional fields.

If the consensus is that its OK to change this API I can make it an array.

Copy link
Member

Choose a reason for hiding this comment

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

make sense as we are adding this to add as a struct

wdyt @damdo

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, how would we handle the API in this case though? Would the existing fields - APIServerAddress, APIServerHealthCheck etc need to be marked as deprecated but still handled for a few releases until the deprecation is complete? It seems like it will add a lot of complexity to this API.

Copy link
Member

Choose a reason for hiding this comment

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

I tend to agree with @bfournie here.
I'd probably stick with a non-breaking change, and then schedule a full API re-review for a new v1beta2 where we can improve the situation and plan the breaking changes we want to make to the API to clean it up.

api/v1beta1/types.go Outdated Show resolved Hide resolved
api/v1beta1/types.go Outdated Show resolved Hide resolved
cloud/scope/cluster.go Outdated Show resolved Hide resolved
@damdo
Copy link
Member

damdo commented May 9, 2024

cc. @nrb

@bfournie
Copy link
Contributor Author

/hold

@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 May 14, 2024
@bfournie bfournie force-pushed the internal-load-balancer branch 4 times, most recently from 6db2752 to f5670bf Compare May 15, 2024 19:26
bfournie added a commit to bfournie/installer that referenced this pull request May 15, 2024
Remove the configuration of the GCP Internal Load Balancer from the
installer as its now being done in the CAPG provider. This allows
only the Internal LB to be created to support Private Clusters.

This depends on kubernetes-sigs/cluster-api-provider-gcp#1222
which is still under review.
@bfournie
Copy link
Contributor Author

/unhold

@bfournie
Copy link
Contributor Author

i am always happy :)

just a question; this will not break any existing clusters that eventually upgrade to this version, correct?

Correct, it will not break existing clusters on upgrade which will not have LoadBalancerType set so only an External LB will created which is the current behavior, see https://github.com/kubernetes-sigs/cluster-api-provider-gcp/pull/1222/files#diff-a7274316ed5d60f25cc61e1bcb771a612c3566832a59ecc3a13b279a849c95ebR61

@cpanato
Copy link
Member

cpanato commented May 29, 2024

/approve
/lgtm

thanks!

@cpanato
Copy link
Member

cpanato commented May 29, 2024

will wait for the e2e tests :)

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bfournie, cpanato

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 May 29, 2024
@bfournie
Copy link
Contributor Author

will wait for the e2e tests :)

Thanks @cpanato! I created a separate PR for the e2e tests with some questions #1245

Can we merge this first and then focus on the e2e test in #1245 ?

@cpanato
Copy link
Member

cpanato commented May 29, 2024

/unhold

@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 May 29, 2024
@k8s-ci-robot k8s-ci-robot merged commit e5efa79 into kubernetes-sigs:main May 29, 2024
17 of 18 checks passed
@k8s-ci-robot k8s-ci-robot added this to the v1.1.0 milestone May 29, 2024
@bfournie
Copy link
Contributor Author

/unhold

Thank you

bfournie added a commit to bfournie/cluster-api-provider-gcp that referenced this pull request May 31, 2024
Adds an e2e test when the internal load balancer is configured.
This requires kubernetes-sigs#1222
bfournie added a commit to bfournie/cluster-api-provider-gcp that referenced this pull request May 31, 2024
Adds an e2e test when the internal load balancer is configured.
This requires kubernetes-sigs#1222
bfournie added a commit to bfournie/cluster-api-provider-gcp that referenced this pull request May 31, 2024
Adds an e2e test when the internal load balancer is configured.
This requires kubernetes-sigs#1222
bfournie added a commit to bfournie/cluster-api-provider-gcp that referenced this pull request May 31, 2024
Adds an e2e test when the internal load balancer is configured.
This requires kubernetes-sigs#1222
bfournie added a commit to bfournie/cluster-api-provider-gcp that referenced this pull request May 31, 2024
Adds an e2e test when the internal load balancer is configured.
This requires kubernetes-sigs#1222
bfournie added a commit to bfournie/cluster-api-provider-gcp that referenced this pull request May 31, 2024
Adds an e2e test when the internal load balancer is configured.
This requires kubernetes-sigs#1222
bfournie added a commit to bfournie/cluster-api-provider-gcp that referenced this pull request May 31, 2024
Adds an e2e test when the internal load balancer is configured.
This requires kubernetes-sigs#1222
bfournie added a commit to bfournie/cluster-api-provider-gcp that referenced this pull request May 31, 2024
Adds an e2e test when the internal load balancer is configured.
This requires kubernetes-sigs#1222
bfournie added a commit to bfournie/cluster-api-provider-gcp that referenced this pull request Jun 2, 2024
Adds an e2e test when the internal load balancer is configured.
This requires kubernetes-sigs#1222
bfournie added a commit to bfournie/cluster-api-provider-gcp that referenced this pull request Jun 3, 2024
Adds an e2e test when the internal load balancer is configured.
This requires kubernetes-sigs#1222
bfournie added a commit to bfournie/cluster-api-provider-gcp that referenced this pull request Jun 3, 2024
Adds an e2e test when the internal load balancer is configured.
This requires kubernetes-sigs#1222
bfournie added a commit to bfournie/cluster-api-provider-gcp that referenced this pull request Jun 3, 2024
Adds an e2e test when the internal load balancer is configured.
This requires kubernetes-sigs#1222
bfournie added a commit to bfournie/cluster-api-provider-gcp that referenced this pull request Jun 3, 2024
Adds an e2e test when the internal load balancer is configured.
This requires kubernetes-sigs#1222
@bfournie bfournie deleted the internal-load-balancer branch June 4, 2024 12:54
@jwmay2012
Copy link
Contributor

I'm having an issue with the Internal only loadbalancer type. When cluster-api brings everything up, the LB never passes the healthcheck.
I can get the LB to be healthy by:

  • deleting the "frontend/Forwardingrule" and allowing CAPG to recreate it. immediately healthy when it is recreated.
  • OR manually creating a second internal passthrough LB, identically configured (or slightly different, but 'correct') to the one created by CAPG. Both LB's become healthy. After deleting the new LB, the original stays healthy.

Seems super weird. Creating a new identical frontend/forwardingrule or recreating the old one causes the healthcheck to start passing and the LB to start accepting requests.

This is for a 1 node cluster.

If there's a better place to post this, I can do that.

@bfournie
Copy link
Contributor Author

bfournie commented Jun 5, 2024

I'm having an issue with the Internal only loadbalancer type. When cluster-api brings everything up, the LB never passes the healthcheck. I can get the LB to be healthy by:

  • deleting the "frontend/Forwardingrule" and allowing CAPG to recreate it. immediately healthy when it is recreated.
  • OR manually creating a second internal passthrough LB, identically configured (or slightly different, but 'correct') to the one created by CAPG. Both LB's become healthy. After deleting the new LB, the original stays healthy.

Seems super weird. Creating a new identical frontend/forwardingrule or recreating the old one causes the healthcheck to start passing and the LB to start accepting requests.

This is for a 1 node cluster.

If there's a better place to post this, I can do that.

So this was with just the Internal LB or both External and Internal LB?
We have a test now for both External and Internal. I haven't seen that issue with the
healthcheck not passing. For Internal only most of my testing has been using this as a provider of Openshift, I haven't seen this in particular but will investigate it.

Probably best to create a Issue under https://github.com/kubernetes-sigs/cluster-api-provider-gcp/issues so we can track it.

@jwmay2012
Copy link
Contributor

Internal Only LB. No external. I'll work to create an issue soon.

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/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow for creation of additional load balancer for internal traffic
8 participants