Open jabellard opened 1 month ago
Hi @zhzhuang-zju, can you help take a look? /cc @zhzhuang-zju
Hi @jabellard Based on your description, I believe this is a reasonable and valuable requirement. The current method of configuring external etcd certificates is somewhat unfriendly, and the capability you want to add could streamline the process.
Are you proposing to replace the existing solution, or is this a supplement to the existing approach, providing an optional ability to load client credentials for an external Etcd cluster from a secret?
I noticed that the ExternalEtcd
configuration in the Karmada API
doesn't seem to be used currently. Does this mean that the Karmada operator hasn't yet provided the ability to connect to an external etcd cluster? If so, we would also need to implement this capability.
I'm curious, has Bloomberg implemented the ability to load external etcd credentials from a secret? Have you encountered any difficulties in doing so?
Hi @jabellard Based on your description, I believe this is a reasonable and valuable requirement. The current method of configuring external etcd certificates is somewhat unfriendly, and the capability you want to add could streamline the process.
Are you proposing to replace the existing solution, or is this a supplement to the existing approach, providing an optional ability to load client credentials for an external Etcd cluster from a secret?
I noticed that the
ExternalEtcd
configuration in theKarmada API
doesn't seem to be used currently. Does this mean that the Karmada operator hasn't yet provided the ability to connect to an external etcd cluster? If so, we would also need to implement this capability.I'm curious, has Bloomberg implemented the ability to load external etcd credentials from a secret? Have you encountered any difficulties in doing so?
Correct. To ensure we maintain backwards compatibility, my intent is not to replace the current approach, but to provide a new optional alternative.
We haven't implemented that, but want to use that approach and aim to contribute this feature to the community.
I just submitted a proposal to kickstart the process. Please take a look and let me know what you think.
Correct. To ensure we maintain backwards compatibility, my intent is not to replace the current approach, but to provide a new optional alternative.
agree
We haven't implemented that, but want to use that approach and aim to contribute this feature to the community. I just submitted a https://github.com/karmada-io/karmada/pull/5260 to kickstart the process. Please take a look and let me know what you think.
very welcome~, I'll take a look ASAP
What would you like to be added: When creating a Karmada instance to be managed by the Karmada operator, it's possible to use an external Etcd cluster for that instance. As of today, the client credentials for that cluster, including the private key, must be provided inline as part of the Karmada CR. This feature request is for providing the ability to load client credentials for an external Etcd cluster from a secret. This would work very similarlly to how credentials for accessing a member cluster registered via the push strategy are loaded from a secret.
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. To have the ability to manage tenant control plane configurations via GitOps, as part of the Karmada CR, we would like to have the ability to specify the reference to a secret from which the client credentials for an external Etcd cluster can be loaded.