Open nrb opened 4 months ago
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
/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:
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.