kind create cluster should print which kubeconfig file got updated

[dims]

[BenTheElder]

IMO this is not a bug, can you show an example of another tool that does this @dims :-)

When building this UX I pretty extensively researched the state of cluster management tooling and found that they do not do this.

The user also totally controls which file is updated by way of KUBECONFIG / --kubeconfig unless it is the default file.

[dims]

i did not say it was a bug :) someone was showing me a demo of what they were doing yesterday and commented that they frequently end up not knowing what got updated when they SSH into different environments (or switch between terminals) with different KUBECONFIG and commented that it would be handy to know which file got updated.

[dims]

the kind/bug was automatically added i think!

[BenTheElder]

the kind/bug was automatically added i think!

there are different templates depending on the issue type, which include the labels :sweat_smile:

someone was showing me a demo of what they were doing yesterday and commented that they frequently end up not knowing what got updated when they SSH into different environments (or switch between terminals) with different KUBECONFIG and commented that it would be handy to know which file got updated.

hmm, unless you specify --kubeconfig, it should be the same one as kubectl etc.?
kubectl config has help for this and we follow the standard from there:

$ kubectl config
Modify kubeconfig files using subcommands like "kubectl config set current-context my-context"

 The loading order follows these rules:

  1.  If the --kubeconfig flag is set, then only that file is loaded. The flag may only be set once and no merging takes
place.
  2.  If $KUBECONFIG environment variable is set, then it is used as a list of paths (normal path delimiting rules for
your system). These paths are merged. When a value is modified, it is modified in the file that defines the stanza. When
a value is created, it is created in the first file that exists. If no files in the chain exist, then it creates the
last file in the list.
  3.  Otherwise, ${HOME}/.kube/config is used and no merging takes place.

this is also true for GKE, kops, minikube, ...

If you want tight control you can specify it, and you can also re-grab credentials later with kind export kubeconfig or kind get kubeconfig.

[dims]

@BenTheElder ah (yes, i clicked on the first link and cleared out the template text!)

Let me ask @soumyapanigrahi-k8s to chime in here as he made the comment!

[soumyapanigrahi-github]

@dims thanks for opening the issue.
@BenTheElder it would be a nice feature if we can output the exact command to set the kubernetes context. It may not be an issue for experienced users but would surely be a helpful for new K8S for whom KIND clusters have become the de-facto today.

[BenTheElder]

@BenTheElder it would be a nice feature if we can output the exact command to set the kubernetes context.

we show how to use it with the context in the output today, the same kubectl command will have e.g. kubectl --context kind-kind ...

It may not be an issue for experienced users but would surely be a helpful for new K8S for whom KIND clusters have become the de-facto today.

it's an issue for all users 😅 -- but the standard is to use this predictable $HOME/.kube/config path unless otherwise instructed (by KUBECONFIG or --kubeconfig in which case the user has already chosen the path themselves).

[BenTheElder]

s/same kubectl/sample kubectl/*

we don't show _setting_ the context again (we do show _specifying_ it) because we've already set it, and in general I don't think we want to put all of the help content into a frequently run command like kind create cluster and make the output overly verbose etc., at least some of it should be in a help command or the docs instead (for now the docs).

kind export kubeconfig will re-do this though (get the credentials, update kubeconfig, set the current context)

[soumyapanigrahi-github]

Thanks for the update @BenTheElder, earlier setting up a KIND cluster provided the exact command to set the KUBECONFIG which I feel was very useful for new users.
I think the change in UX is causing this confusion.

@dims based on what Ben has to say, I guess we can close the issue

[BenTheElder]

Thanks for the update @BenTheElder, earlier setting up a KIND cluster provided the exact command to set the KUBECONFIG which I feel was very useful for new users.

I mostly liked this UX myself, but it was inconsistent with nearly the entire rest of the ecosystem including kubectl which generally assumes that $HOME/.kube/config will be used by default (and not be per-cluster).

I think it's better to be consistent with typical production tools etc. so that users don't need to learn different flows, for many users they will never need to use any file other than $HOME/.kube/config but it's really up to the user and kubectl has mostly defined how this is managed, we're just following them.

[BenTheElder]

we conversely had a LOT of complaints about the whole export KUBECONFIG=$(kind get kubeconfig-path) thing and users interacting with the wrong cluster when switching to another terminal etc. I ran into this a lot myself, create kind in one shell, open another, forget to export ... 🙃

mimic-ing minikube, kops, gke, etc. at least brings some normalcy to the UX, and it does not have this problem unless you opt-into customizing the kubeconfig path or switch users on the host..

[BenTheElder]

aside: I meant to add ~kind/enhancement~ kind/feature not triage/support

[BenTheElder]

One last note before closing ...

I think the change in UX is causing this confusion.

Sorry about that. We did have pretty thorough release notes for this and a migration guide for how to maintain the existing behavior though...

I'll keep this feedback in mind, but we did try to collect feedback and take our time with this change, and I think ultimately sticking to what the rest of the ecosystem does will produce the least total confusion.