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

Support Network Endpoint Groups as a load balancer back end #1195

Open
nrb opened this issue Mar 29, 2024 · 1 comment
Open

Support Network Endpoint Groups as a load balancer back end #1195

nrb opened this issue Mar 29, 2024 · 1 comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.

Comments

@nrb
Copy link

nrb commented Mar 29, 2024

/kind feature

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

Right now, CAPG uses unmanaged instance groups to group VMs for load balancing. This mostly works, but has the following limitation, quoted from their docs, emphasis mine:

Don't put a VM in more than one load-balanced instance group. If a VM is a member of two or more unmanaged instance groups, or a member of one managed instance group and one or more unmanaged instance groups, Google Cloud limits you to only using one of those instance groups at a time as a backend for a particular backend service.

This limitation means it is difficult to have nodes participating in multiple load balancers based on Instance Groups. This could happen in the case of workload cluster worker nodes participating in a load balancer managed by a CNI solution for an application hosted on a CAPG cluster, for example.

Network Endpoint Groups, by contrast, allow load balancing by software service rather than the entire VM. This allows more flexibility for end user application load balancing.

Anything else you would like to add:

This came out of a discussion in the GCP cloud provider about re-using an instance group for load balancing. Our (non-CAPG) installation was trying to associate nodes with different instance groups, which resulted in errors.

As we move to Cluster API-based solutions, it would be nice if the cloud provider's more flexible solutions were supported.

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Mar 29, 2024
@k8s-triage-robot
Copy link

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue as fresh with /remove-lifecycle stale
  • Close this issue with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.
Projects
None yet
Development

No branches or pull requests

3 participants