liquidmetal-dev / liquidmetal-dev/cluster-api-provider-microvm
Create new external load balancer kind
- Dominant language
- Go
- Stars
- 157
- Forks
- 21
- PR merge metrics
- No merged PRs in 30d
Description
**Describe the solution you'd like:**
Currently in our template we are using [kube-vip](https://github.com/weaveworks/cluster-api-provider-microvm/blob/main/templates/cluster-template.yaml#L60) for load balancing and you supply the VIP upfront. This is also used to fill in the [controlPlaneEndpoint](https://github.com/weaveworks/cluster-api-provider-microvm/blob/main/templates/cluster-template.yaml#L28:L30) on `MicrovmCluster`.
This causes errors in the logs of the controller as `controlPlaneEndpoint` is part of the `Cluster` contract between CAPI and an infra provider. If the `controlPlaneEndpoint` is filled in then CAPI will start to use it but as kube-vip may not be running there is nothing responding on the endpoint (i.e. the vip).
We should only fill in the `controlPlaneEndpoint` on the `MicrovmCluster` when the loadbalancer is available. So its proposed that we introduce a new kind `ExternalLoadBalancer` were the spec has :
- host (in template use ${CONTROL_PLANE_VIP})
- port (optional, default to 6443)
the status will have:
- Ready (bool)
The controller in reconcile will attempt to connect to the load balancer and on success it will set Ready.
The `MicrovmCluster` api will need to be updated to reference the `ExternalLoadBalancer` and its controller in normal reconciliation will wait for the status to be ready of `ExternalLoadBalancer` before it sets the `controlPlaneEndpoint` on `MicrovmCluster`.
**Why do you want this feature:**
To stop errors in the controller logs.
**Anything else you would like to add:**
[Miscellaneous information that will assist in solving the issue.]
Contributor guide
Assessment
This issue has not been assessed yet.