CODEWITHSUNDEEP
kubernetes
smugcloud
smugcloud

Reputation: 627

error: couldn't read version from server

I am getting the following error when trying to run kubectl locally.

error: couldn't read version from server: Get http://localhost:8080/api: dial tcp 127.0.0.1:8080: connection refused

I know this relates to the kubectl config but I'm at a loss in how to resolve it. 2 days ago, I was experimenting with GKE and did set the config to point to GCE. I tried deleting this config file and then getting Vagrant with CoreOS locally. This vagrant up throws a similar error complaining about not being able to connect.

What is the appropriate way to instrument kubectl so it can connect to the API and return information?

Upvotes: 15

Views: 9577

Answers (6)

srcspider
srcspider

Reputation: 11205

tl;dr gcloud container get-credentials --cluster=CLUSTER_ID --zone=YOURZONE

So a little background: the kubectl tool is developed by google but isn't actually integrated into google cloud directly, the google cloud just helps you get a compatible version with it when you tell it to install the component.

If you're getting the Get http://localhost:8080/api: dial tcp 127.0.0.1:8080: connection refused it is likely due to the kubectl tool not being configured at all or misconfigured. What I believe it's trying to do is assuming you have kubernetes somehow setup locally only, which you don't in this case since it's all on the google cloud (hence the cryptic error).

You can verify your kubectl is misconfigured by running kubectl config view. If it's correctly configured you should see things like a few entries in cluster, with ip addresses, and in users you should see a user for each project, etc. If you see nothing of the sort (ie. empty clusters, and empty users) then you are misconfigured; you will also encounter cryptic issues if you dont see entries for the specific cluster you are trying to work on.

Annoyingly a lot of gcloud commands will silently auto-configure it for you, so if you follow something like a hello wordpress tutorial it will look like you dont have to do this and that somehow kubectl communicates with gcloud, but nothing of the sort happens. It's also very easy to lose that configuration.

To tell gcloud to give you the kubectl config run the following:

gcloud container get-credentials --cluster=CLUSTER_ID --zone=YOURZONE

For cluster id run gcloud container clusters list

Zone is "europe-west1-d" or whatever you've chosen.

Upvotes: 15

Vanchev
Vanchev

Reputation: 1584

This used to be beta, but that is no longer the case. So the command now is:

gcloud container clusters get-credentials <cluster-name> --zone=<zone-of-cluster> --project=<project-id>

If you try to run it with the beta command you get the following error message:

WARNING: You invoked gcloud beta, but with current configuration Kubernetes Engine v1 API will be used instead of v1beta1 API. gcloud beta will switch to use Kubernetes Engine v1beta1 API by default by the end of March 2018.

Later on if you wish to switch between clusters via kubectl (only for ones that you have already authenticated for), you can use:

kubectl config use-context gke_<project-name>_<zone>_<cluster>

Example:

kubectl config use-context gke_my-project_europe-west1-c_my-cluster

To see where you currently are:

kubectl config current-context

Cheers

Upvotes: 9

Carlin
Carlin

Reputation: 51

I also got this error when deploying locally with a mostly default configuration on Ubuntu Trusty. Turns out the api-server was not starting due to some bug with DenyEscalatingExec particular to ubuntu in k8s v1.1.7

https://github.com/kubernetes/kubernetes/issues/14474 https://github.com/kubernetes/kubernetes/issues/14627

I rebuilt the cluster without it by removing the directive from the file ~/kubernetes-1.1.7/cluster/ubuntu/config-default.sh before executing kube-up.sh

# Admission Controllers to invoke prior to persisting objects in cluster
export ADMISSION_CONTROL=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,DenyEscalatingExec,SecurityContextDeny

DenyEscalatingExec needs to be removed from that line, and as a result, it won't be a flag in your /etc/default/kube-apiserver after starting the cluster.

Disclaimer: I'm not sure what DenyEscalatingExec does, I just found that this worked for me to solve this particular problem.

Upvotes: 0

Kirk Strobeck
Kirk Strobeck

Reputation: 18629

This is in flux, just reference the documentation. It is currently ...

gcloud container clusters get-credentials NAME [--zone ZONE, -z ZONE] [GLOBAL-FLAG …]

Upvotes: -1

Tim Swena
Tim Swena

Reputation: 14786

I was using Google Container Engine (GKE) and got this error, too. In my case, it was because I forgot to create a container cluster first.

If you create a cluster using the gcloud command, it sets the config for the you.

gcloud container clusters create my-cluster-name

Upvotes: 0

Simon Williamson
Simon Williamson

Reputation: 61

The above solution no longer works. You need to do the following instead:

gcloud container clusters get-credentials <cluster-name> \
    [--zone=<zone-of-cluster> --project=<project-id>]

Upvotes: 6

Related Questions