Add The Ability to Retrieve External Etcd Client Credentials From Secret

[jabellard]

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.

[XiShanYongYe-Chang]

Hi @zhzhuang-zju, can you help take a look?
/cc @zhzhuang-zju

[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?

[jabellard]

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?

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.

[zhzhuang-zju]

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 #5260 to kickstart the process. Please take a look and let me know what you think.

very welcome~, I'll take a look ASAP

[RainbowMango]

/reopen
Still waiting for #5536

[karmada-bot]

@RainbowMango: Reopened this issue.

In response to this:

/reopen
Still waiting for #5536

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.