KUBECONFIG management for kind v0.6.0+ versus previous releases:

If you just want to use kind for local development, you can skip the export KUBECONFIG="$(kind get kubeconfig-path --name=kind)" step.

KIND now exports / merges kubeconfigs in the same way that kops, minikube, and other tools do. This means that when switching terminals kind will "just work" without remembering to export the KUBECONFIG environment variable in each terminal.

The file selection logic follows kubectl and client-go, which is roughly:

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.

source: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#config

The Kubernetes client credentials will be written by kind create cluster to the path determined by these rules, with a context name like kind-foo where foo is the --name of the cluster.

Like other tools, when exporting the credentials kind will set the current context to the new cluster. If you switch the current context again you can specifically reference the kind cluster by using kubectl with --context=kind-foo.

The instructions output by kind create cluster have been updated to reflect this.

Emulating The Old Behavior

You can emulate the previous behavior by switching from:

kind create cluster --name=foo
export KUBECONFIG="$(kind get kubeconfig-path --name=foo)"

to:

export KUBECONFIG="${HOME}/.kube/kind-config-foo"
kind create cluster --name=foo

This may be useful for some test scripts.

Additional Notes

• Going forward kind clusters will be identified in kubeconfigs by the kind- prefix on entries
• Note that your current context will be set when creating a cluster. If you wish to keep kind seperate from your other clusters, please specify --kubeconfig or KUBECONFIG to point to another file when calling kind create cluster
• kind delete cluster will inspect either --kubeconfig if set or the files in KUBECONFIG and ${HOME}/.kube/config (the kubectl default) to find and remove the matching cluster by KIND --name in each file.