Add an option to update kubeconfig

[barkbay]

This feature is motivated by the fact that most of our current deployments (minikube, gke ...) are managed through the default kubeconfig file.
It might also be convenient for people that use tools like kubecxt.
With this PR user can add --set-context when a cluster is created to import the new context to its kubeconfig.

Note that it does not remove the context when the cluster is deleted, but it can be done in an other PR (I wanted to keep this one small).
Also I'm not sure about the unit test policy, I can add some of them to at least cover the merge with the current kubeconfig (could also be done in an other PR)

Let me know your thoughts.

This PR supersedes:

• Feat/kubeconfig multi cluster #512
• Modify kubeconfig by using client-go, not regex #520
• Introduce the --use flag when creating a cluster #517

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: barkbay
To complete the pull request process, please assign munnerz
You can assign the PR to them by writing /assign @munnerz in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Hi @barkbay. Thanks for your PR.

I'm waiting for a kubernetes-sigs or kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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/test-infra repository.

[BenTheElder]

We should discuss this in an issue I think, there's some design and tradeoffs involved.

The users field is going to collide if multiple kind clusters are created IIRC.
This re-introduces a direct dependency on client-go which may make kind harder to depend on in test harnesses.
The flag name is not quite clear in versus actually happens.
Maybe this should be the new default?

This is definitely a neat feature, but it can also be accomplished with a tiny bit of kubectl in the meantime, other than the merging issue which we need to settle on a solution for.

[barkbay]

We should discuss this in an issue I think, there's some design and tradeoffs involved.

I have created #802

The users field is going to collide if multiple kind clusters are created IIRC.

Yes, this PR takes care of that by adding the cluster name as a suffix.

This re-introduces a direct dependency on client-go which may make kind harder to depend on in test harnesses.

👍 makes sense

The flag name is not quite clear in versus actually happens.
Maybe this should be the new default?

Agreed

[BenTheElder]

This is done by default now in a way that closely marches other tools. Ref #850
Thanks for the PR 🙃