Support karmactl config to modifies kubeconfig files

[zhzhuang-zju]

What would you like to be added:
Support karmactl config to modifies kubeconfig files. The specific work items are as follows:

• karmadactl config current-context
• karmadactl config use-context
• karmadactl config get-contexts
• karmadactl config set/unset
• karmadactl config set-contexts
• karmadactl config delete-context
• karmadactl config view
• karmadactl config rename-context

Why is this needed:
Referring to #4291 (comment), each time karmada is installed, the default context is karmada-host. We need use kubectl to modify the current-context before karmadactl can be used normally. As a result, karmadactl cannot be completely independent and the user experience is fragmented.

[zhzhuang-zju]

/assign

[chaunceyjiang]

I believe that karmadactl will only connect to karmada-apiserver, and won't connect to other k8s clusters, so there shouldn't be a scenario of switching context.

If we support switching context, then what would be the meaning of karmadactl get when the context is switched to a member cluster?

[RainbowMango]

each time karmada is installed, the default context is karmada-host

Is that true? How Karmada is installed? By operator , helm or cli?
The default context should be Karmada I think.

[zhzhuang-zju]

each time karmada is installed, the default context is karmada-host

Is that true? How Karmada is installed? By operator , helm or cli? The default context should be Karmada I think.

By hack/local-up-karmada.sh

[zhzhuang-zju]

I believe that karmadactl will only connect to karmada-apiserver, and won't connect to other k8s clusters, so there shouldn't be a scenario of switching context.

If karmadactl will only connect to karmada-apiserver, then we must limit its kubeconfig and hardcode its context to karmada-apiserver, or do you have a better idea?

If we support switching context, then what would be the meaning of karmadactl get when the context is switched to a member cluster?

Good question. In fact, karmadactl can only perform corresponding operations based on the provided kubeconfig and context. It does not know whether the cluster is a member cluster, in other words, each cluster can be a control plane. If the context is switched to a member cluster, then karmadactl will return its resource information and query the resources of its member cluster, merely its member cluster does not exist.

[RainbowMango]

Echo from the output of hack/local-up-karmada.sh:

Local Karmada is running.

To start using your karmada, run:
  export KUBECONFIG=/root/.kube/karmada.config
Please use 'kubectl config use-context karmada-host/karmada-apiserver' to switch the host and control plane cluster.

To manage your member clusters, run:
  export KUBECONFIG=/root/.kube/members.config
Please use 'kubectl config use-context member1/member2/member3' to switch to the different member cluster.

Yes, the default context(current-context) is karmada-host:

contexts:
- context:
    cluster: karmada-apiserver
    user: karmada-apiserver
  name: karmada-apiserver
- context:
    cluster: kind-karmada-host
    user: kind-karmada-host
  name: karmada-host
current-context: karmada-host

Wouldn't it be better to take karmada-apiserver as default?

[zhzhuang-zju]

take karmada-apiserver as default

I guess taking karmada-host as default is because after the installation is complete, we can check whether the karmada components are installed normally by executing command kubectl get pods -nkarmada-system without switching context.

[RainbowMango]

@zhzhuang-zju Any thoughts about the question #4297 (comment) asked by @chaunceyjiang ?

[zhzhuang-zju]

@zhzhuang-zju Any thoughts about the question #4297 (comment) asked by @chaunceyjiang ?

I agree that karmadactl must connect to the karmada-apiserver. The issue is that the current-context of kubeconfig file may not necessarily be the context of the karmada-apiserver. We currently provide the flag --karmada-context to specify the karmada-apiserver, so we effectively have the ability to switch contexts; it just needs to be specified each time the command is executed.
If the concern is about user errors, we can emphasize this in the command naming, for example, changing set-contexts to set-karmada-contexts. Would this be more acceptable?

[zhzhuang-zju]

When Karmada is installed successfully, karmada-context is actually a deterministic value and does not quite fit the semantics of current-context. Could we leverage the extensions field in the kubeconfig file to extend its existing structure, thereby achieving persistent configuration for karmada-context? Like:

$ karmadactl config set-karmada-context karmada-apiserver

# $HOME/.kube/karmada.config
apiVersion: v1
extensions:
- name: karmada-context
  extension:
    karmada-apiserver
...

$ karmadactl config get-karmada-context
karmada-apiserver

• Coordination with current-context
  When karmada-context is not specified in the extensions field, fall back to using current-context as the value for karmada-context.
• Benefit
  Regardless of what value current-context is set to, karmada-context will correctly point to the karmada-apiserver.

WDYT? @chaunceyjiang @RainbowMango