DefaultPath is not always path used for kubeconfig

[kschumy]

What happened?
I'm not sure if this is a bug or intentionally designed this way, but I figured I'd bring it up just in case.

doCreateCluster() uses DefaultPath as the kubeconfig path when calling kubeconfig.Write(). DefaultPath is set to $HOME/.kube/config. However, when it goes to actually write the config file with ModifyConfig() in clientcmd/config.go, precidence is given to the KUBECONFIG env variable(s) and $HOME/.kube/config (ie DefaultPath) is used only if there is nothing assigned to KUBECONFIG.

DefaultPath seems to imply that is the path that will be used, but this isn't always the case. While it seems that most people have $HOME/.kube/config assigned to KUBECONFIG and thus this issue doesn't visibly impact them, having it set to this path is not a requirement.

What you expected to happen?
I expected DefaultPath to be the path that will be used for the kubeconfig.

How to reproduce it?
See gist for possibly too many details and printed logger statements to demonstrate this.

Anything else we need to know?
I discovered this while working on a PR to delete the cluster from the kubeconfig file. Since I was unsure of if this was actually a bug, I opted to treat it as intentional and used the same logic as doCreateCluster() to delete the cluster. Since the logic is similar, removing the cluster from the kubeconfig will have the same impact as described above

Versions
NOTE: I was using a branch off my fork of master

~ $ eksctl version
2018-09-26T12:20:59-07:00 [ℹ]  versionInfo = map[string]string{"gitCommit":"e577962c2a3d25af5dcc7995340339c4cdfee804", "gitTag":"0.1.3", "builtAt":"2018-09-19T16:07:46Z"}
~ $ uname -a
Darwin c4b301c23913.ant.amazon.com 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 21 20:07:39 PDT 2018; root:xnu-3789.73.14~1/RELEASE_X86_64 x86_64
~ $ kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-07-26T20:40:11Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.3-eks", GitCommit:"58c199a59046dbf0a13a387d3491a39213be53df", GitTreeState:"clean", BuildDate:"2018-09-21T21:00:04Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Logs
See gist in "How to reproduce it?" section

[richardcase]

Great spot @kschumy.

My take on this is that we should have the same behaviour as kubectl. With kubectl the --kubeconfig flag takes precendence over the KUBECONFIG environment variable. This makes sense to me.

With just the env var:

KUBECONFIG=env.config  kubectl get nodes --v=10
I0927 11:18:16.684990   25631 loader.go:359] Config loaded from file env.config

With the env var and flag:

KUBECONFIG=env.config  kubectl get nodes --kubeconfig='flag.config' --v=10
I0927 11:19:28.889862   26591 loader.go:359] Config loaded from file flag.config

Would you agree @errordeveloper and @christopherhein ?

[christopherhein]

I would agree, resolving down to the typical kubectl load ordering would cause the least of amount of confusion for customers that are used to the way the standard kubernetes tools work. 💯 @richardcase

[errordeveloper]

@kschumy this is a very nice and detailed bug report, I apologies for a belated response... I'd be keen to see a PR that fixes it, if you need any help - let's chat on Slack.