Load Balancer Provider

[moshloop]

/kind feature

One of the long-standing issues in CAPV is the lack of a default/standard load balancer for vSphere environments - Many options exist (VMC ELB, F5, NSX, IPVS, Client-Side) but nothing would apply to all environments.

We, therefore, need a mechanism to support arbitrary load balancer implementations.

The first question that needs to be answered is where does this belong as a high-level provider similar to the bootstrap provider, or as an implementation detail in CAPV?

Note: This refers to the load balancer for control plane endpoints, not Service Type Load Balancer

kubernetes-sigs/cluster-api-provider-vsphere#491

[moshloop]

/assign @timothysc @akutz @yastij

[moshloop]

Potential implications for: #1197

[detiber]

@moshloop this aligns with my original ideas around how we should rework the "Cluster Infrastructure" when we first started discussing v1alpha2 changes. This also extends beyond just vSphere, but also affects bare metal and even OpenStack environments.

My thought was that we should split the existing monolithic cluster infrastructure into 3 separate components:

• Load Balancer provider
• Network provider
• Firewall provider

What we are lacking is a CAEP/design doc around how we could implement this on top of v1alpha2.

[vincepri]

/kind design

If there is enough interest, this functionality should be spec'd in a CAEP.

[moshloop]

I will try and create a CAEP for this.
/assign

[yastij]

@detiber - If there's enough traction on this then I'm happy to help on this.
one question that comes to my mind, if we want to have cluster infrastructure "composability" we'd need some new APIs to support this, would this be for v1a3 ?

[detiber]

@yastij it would definitely be post v1alpha2, whether it would be included in v1alpha3 would need to still be determined based on community planning.

[yastij]

cc @akutz

[timothysc]

After reading through the spec several times, I don't see a reason to keep this open in the main CAPI repo as a POC can be done independently. Once the POC is complete and if folks think that it is generally useful we can revisit later.

[ncdc]

/reopen
Reopening to continue the discussion. Discussed in the 10/23 meeting.

[k8s-ci-robot]

@ncdc: Reopened this issue.

In response to this:

/reopen
Reopening to continue the discussion. Discussed in the 10/23 meeting.

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.

[vincepri]

/milestone Next

[vincepri]

/assign @randomvariable

[fabriziopandini]

/triage accepted

Still a valid idea, hopefully someone will volunteer for the work
/help

[k8s-ci-robot]

@fabriziopandini:
This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/triage accepted

Still a valid idea, hopefully someone will volunteer for the work
/help

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.

[fabriziopandini]

/unassign @randomvariable

[jayunit100]

So , since this was made 3 years ago. Thought I'd just add some thoughts i had about how things work, today. Overall it seems like this is the right thing to add to CAPI in a general way.

Currently, in the real world, i guess my mental model is "you inject loadbalancing logic into something that runs orthogonal to CAPIs data model "..... at least, thats what it seems like for Vsphere.

To me since : A loadbalancer VIP is such a common problem in all K8s providers - - this seems like it has to end up, in CAPI, somehow eventually..

Tanzu supports AVI or kube vip as a loadbalancer. And in the kube-vip case, we embed yaml for kube vip into our kubeadm file bootstrapping.

A more declarative way to do this would be cool, because it would be more understandable and then easier to separate out "LB UX / config problems" from "CAPI installation problems" from "infra" problems related to unrouteable IPs and so on.

[lubronzhan]

Hi @detiber Looks like the google doc is no longer available Referenced here #4389 (comment)
https://docs.google.com/document/d/1wJrtd3hgVrUnZsdHDXQLXmZE3cbXVB5KChqmNusBGpE/edit#
Do you still have the original doc?

[vincepri]

Closing this in favor of #8500 and future endeavors

/close

[k8s-ci-robot]

@vincepri: Closing this issue.

In response to this:

Closing this in favor of #8500 and future endeavors

/close

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.