Closed jabellard closed 1 day ago
@RainbowMango , any thoughts?
Similarly, I think it'd be useful to also include the name of the service for the control plane's API server in the status.
Sounds reasonable to me. Something like after the provision, tells how and where to access the APIServer.
Is it enough with a service name? Could you please give an example of how it looks?
Similarly, I think it'd be useful to also include the name of the service for the control plane's API server in the status.
Sounds reasonable to me. Something like after the provision, tells how and where to access the APIServer.
Is it enough with a service name? Could you please give an example of how it looks?
@RainbowMango , you asked some great questions! I just submitted a proposal for this which contains all the details.
Great thanks. Then let's discuss this on the proposal.
What would you like to be added: Once a Karmada instance has been provisioned by the operator, it's status will contain a ref to the secret that contains the admin kubeconfig for the control plane. As such, there's no need to guess where that secret is stored. Similarly, I think it'd be useful to also include the name of the service for the control plane's API server in the status.
Why is this needed: At Bloomberg, we're currently building a managed Karmada platform and want to use the Karmada operator to manage the entire lifecycle of managed Karmada instances. Tenant control planes will run in our management clusters. As such, the Karmada operator will be running in those clusters. Additionally, we'll also have a higher level operator running in those clusters that, at a very high level, will do the following:
As of now, when creating an ingress for an API server, we have to guess the name of the service for that server. Although it seems like there's some convention used for generating the service names, relying on that is a brittle approach as it depends on knowledge of an implementation detail that may likely change in the future.