Closed dlipovetsky closed 4 years ago
/kind proposal
@dlipovetsky the proposed KubeadmControlPlane
has .spec.kubeadmConfigSpec.clusterConfiguration.controlPlaneEndpoint
. I believe a user should be able to fill that in with any value. How does that figure in to this RFE - does it address it?
@dlipovetsky the proposed
KubeadmControlPlane
has.spec.kubeadmConfigSpec.clusterConfiguration.controlPlaneEndpoint
. I believe a user should be able to fill that in with any value. How does that figure in to this RFE - does it address it?
Yes.
--
We may want to call out the above requirements in the proposal (#1613 . In any case, @detiber asked me to open an issue to anchor the discussion, rather than leaving comments on the PR.
I wonder if we need to at least include something in the CAEP to have kubeadmControlPlane.spec.kubeadmConfigSpec.clusterConfiguration.controlPlaneEndpoint
be populated from cluster.status.apiEndpoints
if the controlPlaneEndpoint
is empty? Or, to ask a related question, how do we envision something like CAPA working with KubeadmControlPlane where CAPA creates the ELB + the cluster's api endpoint when the AWSCluster
is reconciled - how does ...controlPlaneEndpoint
get filled in? Or is that manual?
Or is that manual?
That would be a major regression from previous releases for providers that support Load Balancers...
Right, so until (if) we have a proper LoadBalancer
story, should we update the CAEP to add some text to describe how we maintain the existing behavior w/o requiring manual intervention to set the endpoint?
be populated from
cluster.status.apiEndpoints
if thecontrolPlaneEndpoint
is empty
Why not have the infra provider create the LB and update the controlPlaneEndpoint
if it is empty and then remove cluster.status.apiEndpoints
or make it a read-only mirror of controlPlaneEndpoint
and then you would have consistent behaviour for both user and infra provided LB's
Why not have the infra provider create the LB and update the controlPlaneEndpoint if it is empty and then remove cluster.status.apiEndpoints or make it a read-only mirror of controlPlaneEndpoint and then you would have consistent behaviour for both user and infra provided LB's
I think the concern here is that it would require tight coupling with the kubeadmControlPlane rather than being a more generic mechanism that would work across different controlplane and bootstrapping providers.
Exactly. I'd like there to be an eventual interaction between a LoadBalancer
(LB) resource and the KubeadmControlPlane
(KCP), and maybe the Cluster
too, where the KCP knows to pull the LB's endpoint if it exists (could be KCP pulls from LB, or KCP gets Cluster, see it has an LBRef, and follows that).
So then let's make controlPlaneEndpoint
a first-level field of cluster itself?
KCP could then wait until it is populated by a LB
then you would have consistent behaviour for both user and infra provided LB's
Also, assuming we proceed with your LB proposal @moshloop, I think a natural progression is that there are no more "infra provided LBs" in the sense that the "cluster + machine infra provider" is separate from "LB provider"
xref #1197 - I assume that ties into this
So then let's make
controlPlaneEndpoint
a first-level field of cluster itself?KCP could then wait until it is populated by a LB
This seems reasonable.
If an LB provider did exist, I suppose it would, after creating the load balancer, update the status of a CR that the Cluster object would reference. Until we figure out the schema of that CR and use a reference, an inline field works.
/priority critical-urgent /lifecycle active
User Story
As an operator, I would like to choose my own way to provide a stable API endpoint, as required by the default control plane management implementation.
Detailed Description
The default control plane management implementation requires a stable API endpoint. This endpoint
For reference: Today, the stable API endpoint is provided either by the operator (e.g. using an existing LB, or a VIP backed by keepalived), or by the infra provider (e.g. an ELB created by CAPA). There is a proposal to make an explicit provider for this endpoint: #1250.
/cc @detiber @randomvariable