When we use karmadactl to initialize the cluster, the specified ca certificate is not supported

[guozheng-shen]

What would you like to be added: When we use karmadactl to initialize the cluster, we can use the specified ca certificate

Why is this needed: We want access multiple karmada cluster using one kubeconfig, but now when we use karmadactl init cluster, it will create new ca certificate every times. caCert, caKey, err := NewCACertAndKey("karmada")

Our karmada manages many clusters，If karmada is deployed in only one cluster, it is not highly available。So we deployed karmada in two k8s clusters, but using a common etcd cluster。

When a cluster is unavailable, we can remove its load in vip。So we need access multiple karmada cluster using one kubeconfig

[RainbowMango]

I think this is a reasonable use case that enables specifying each component's certificate.

@guozheng-shen Do you mean you want to specify the ETCD certificate?

Have you noticed the following options which provided at v1.10?

    --external-etcd-ca-cert-path='':
    The path of CA certificate of the external etcd cluster in pem format.

    --external-etcd-client-cert-path='':
    The path of client side certificate to the external etcd cluster in pem format.

    --external-etcd-client-key-path='':
    The path of client side private key to the external etcd cluster in pem format.

    --external-etcd-key-prefix='':
    The key prefix to be configured to kube-apiserver through --etcd-prefix.

    --external-etcd-servers='':
    The server urls of external etcd cluster, to be used by kube-apiserver through --etcd-servers.

[guozheng-shen]

Not specify the ETCD certificate， I want specify root ca， now is func GenCerts(pkiPath string, etcdServerCertCfg, etcdClientCertCfg, karmadaCertCfg, apiserverCertCfg, frontProxyClientCertCfg *CertsConfig) error { caCert, caKey, err := NewCACertAndKey("karmada")}

[RainbowMango]

Yeah, I get it. @liangyuanpeng @chaosi-zju what do you think?

[guozheng-shen]

If this issue is approved, I can complete it, as this change has already been made and applied to the production environment in our company's usage.

[RainbowMango]

Glad to hear that. I'm interested in how you do it. How many options were introduced to karmadactl init?

By the way, as you mentioned, Karmada is already in your production environment, I wonder if your company is present on the adopter list?

[guozheng-shen]

I added two options to karmadactl init， '--ca-cert-path /tmp/ca.crt' and '--ca-key-path /tmp/ca.key', If the options is exists , will directly copy rather then gen new certs。 adopter list is in preparation

[RainbowMango]

I added two options to karmadactl init， '--ca-cert-path /tmp/ca.crt' and '--ca-key-path /tmp/ca.key', If the options is exists , will directly copy rather then gen new certs

Yeah, I think you can send a PR for this. Thanks in advance.

adopter list is in preparation

For the adopter things, all you need is to leave a comment on #4540, the community member will help to get you onboard after that, like https://github.com/karmada-io/community/issues/75.

[liangyuanpeng]

i agree with add some new option for it befor we have a karmadactl init configuration file. PR is welcome !

[chaosi-zju]

I think this feature makes sense, and I'd be interested in reviewing this PR~

[guozheng-shen]

I added two options to karmadactl init， '--ca-cert-path /tmp/ca.crt' and '--ca-key-path /tmp/ca.key', If the options is exists , will directly copy rather then gen new certs

Yeah, I think you can send a PR for this. Thanks in advance.

adopter list is in preparation

For the adopter things, all you need is to leave a comment on #4540, the community member will help to get you onboard after that, like karmada-io/community#75.

The adopter list has been submitted by my colleagues https://github.com/karmada-io/karmada/issues/4540#issuecomment-2190886046