You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Delegate all base control plane functionality to the Karmada operator
Perform any additional tasks required for provisioning a tenancy such as creating an ingress resource to allow external traffic to the tenancy's API server running in the management cluster
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: