Confusing error message when no kubeconfig is provided

[mlevesquedion]

I observed this issue when using the latest kubectl, but I believe it is relevant to client-go (and maybe cli-runtime).

When running kubectl commands without a config file (no --kubeconfig flag, no KUBECONFIG environment variable, no ~/.kube/config), I get the following error message:

 The connection to the server localhost:8080 was refused - did you specify the right host or port?

Since I didn't provide any configuration, I would expect to see the following error message, defined in cli-runtime/pkg/genericclioptions/client_config.go:

var (
	ErrEmptyConfig = clientcmd.NewEmptyConfigError(`Missing or incomplete configuration info.  Please point to an existing, complete config file:


  1. Via the command-line flag --kubeconfig
  2. Via the KUBECONFIG environment variable
  3. In your home directory as ~/.kube/config

To view or setup config directly use the 'config' command.`)
)

I did some digging, and it looks like because of the following code in client-go/pkg/tools/clientcmd/client_config.go ...

var (
	// ClusterDefaults has the same behavior as the old EnvVar and DefaultCluster fields
	// DEPRECATED will be replaced
	ClusterDefaults = clientcmdapi.Cluster{Server: getDefaultServer()}
	// DefaultClientConfig represents the legacy behavior of this package for defaulting
	// DEPRECATED will be replace
	DefaultClientConfig = DirectClientConfig{*clientcmdapi.NewConfig(), "", &ConfigOverrides{
		ClusterDefaults: ClusterDefaults,
	}, nil, NewDefaultClientConfigLoadingRules(), promptedCredentials{}}
)

// getDefaultServer returns a default setting for DefaultClientConfig
// DEPRECATED
func getDefaultServer() string {
	if server := os.Getenv("KUBERNETES_MASTER"); len(server) > 0 {
		return server
	}
	return "http://localhost:8080"
}

... the server defaults to http://localhost:8080 when creating the config, which prevents the config from being identified as empty later on.

Judging by the DEPRECATED in the comments, it looks like this behavior is going to change soon? Is there an ETA on this?

In any case, if this is indeed an issue and not WAI, I would be interested in helping with the fix.

[comerford]

Similarly, I received this error when I had neglected to set automountServiceAccountToken to true with the bitnami/kubectl container running in an existing cluster (all the environment variables were set correctly). I even wrote it up on serverfault to hopefully stop someone else from wasting hours over a cryptic error message:

https://serverfault.com/q/1050696/108132

If a valid config exists, it would be very helpful if the error message carped about the lack of credentials or at least in some way indicated that the connection to localhost:8080 is a failure after a fallback to defaults

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[furkhat]

/remove-lifecycle stale

It's kind of weird to me that client go executes kubectl under the hood. Because If you build go program that uses client go and run it in an environment without kubectl it won't work

[liggitt]

If you build go program that uses client go and run it in an environment without kubectl it won't work

do you have more details of what you are observing? client-go does not invoke kubectl. it's possible some of the error messages when misconfigured reference command line flags that are typically associated with kubectl, but there's no runtime dependency on a kubectl binary.

[furkhat]

Turns out in my case it was expected behavior. client-go was invoking kubectl because from client-go's perspective it's just exec provider from kubeconfig

users:
- name: kubernetes-admin
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      command: kubectl
      args:

[k8s-triage-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

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.