the same for the first time when i ran v0.20.1 (the published one)

here is the installation log on my core i5-5200U ubuntu 14.04 3.16 kernel
https://gist.github.com/alexanderguzhva/3fc6c3083f7d4eb20667
this is that console says

nop@linux-xp13:~/k8s/201r/kubernetes/cluster$ ./kube-up.sh > kubenew
Starting cluster using provider: vagrant
... calling verify-prereqs
... calling kube-up
Using credentials: vagrant:vagrant
error: couldn't read version from server: Get https://10.245.1.2/api: dial tcp 10.245.1.2:443: connection refused

See my comment on #10158 (comment)

I think @dchen1107 is probably right. There's a 0.20.2 brewing already (and we should have it out later today), so hang tight.

I just tried this also with Release 0.20.2 Candidate on Ubuntu 14.04 with VirtualBox, Vagrant and I am seeing:

$ cluster/kube-up.sh
...
Each machine instance has been created/updated.
  Now waiting for the Salt provisioning process to complete on each machine.
  This can take some time based on your network, disk, and cpu speed.
  It is possible for an error to occur during Salt provision of cluster and this could loop forever.
Validating master
Validating minion-1
.....
Waiting for each minion to be registered with cloud provider
error: couldn't read version from server: Get https://10.245.1.2/api: dial tcp 10.245.1.2:443: connection refused

@dchen1107 - Is there someone on your team that could take a look?

Honestly no, everyone is busy, and working on either cluster or network related issue. But I talked to @mikedanese briefly, he kindly agree to take a look. @mikedanese The cloud provider here is Vagrant, if you could reproduce the issue, that would be huge help. Feel free to re-assign it to me if you are blocked. Thanks!

cc/ @justinsb since he looked into vagrant issue lately. cc/ @derekwaynecarr on Vagrant.

+1, 0.20.2 still has this issue

+1

The fix for this issue is this PR:

#10492

Assigning issue to me since I am focused today on closing out remaining Vagrant setup issues.

Sigh, I'm sorry. So busy working through unassigned PRs I forgot to work through my own queue.

@derekwaynecarr, I was running into the same issue and cherry picked your changes in #10492, but still have the same issue. Prior to those changes the kubelet never started on the master. With the changes it does start, but I still get:

Waiting for each minion to be registered with cloud provider
error: couldn't read version from server: Get https://10.245.1.2/api: dial tcp 10.245.1.2:443: connection refused

It looks like #10562 also needed before vagrant works correctly.

Yep, I picked #10492 and then merged #10562 and it started to work again... just my 2 cents

this error is gone in 0.21.0 rc (39b013a)

error: couldn't read version from server: Get https://10.245.1.2/api: dial tcp 10.245.1.2:443: connection refused

I am using Mac OSX 10.10.5 / VMWare Fusion / bento/fedora-21/ Vagrant 1.7.4 / and built kubernetes from master (GitVersion:"v1.1.0-alpha.1.687+818946080904c8") and I am seeing this issue when I run ./cluster/kube-up.sh

Each machine instance has been created/updated.
Now waiting for the Salt provisioning process to complete on each machine.
This can take some time based on your network, disk, and cpu speed.
It is possible for an error to occur during Salt provision of cluster and this could loop forever.
Validating master
Connection to 192.168.100.177 closed.
..Validating minion-1
.............
Waiting for each minion to be registered with cloud provider
error: couldn't read version from server: Get https://10.245.1.2/api: dial tcp 10.245.1.2:443: connection refused

I'm running into a similar issue with a Kubernetes cluster on AWS. I set it up last week and now can't connect to the master node:

oamasood@ldmsdloan01:~/src/Talent-Web/web2py$ kubectl cluster-info
error: couldn't read version from server: Get https://11.11.111.111/api: dial tcp 11.11.111.111:443: connection refused

Any help would be appreciated.

I find that if you wait for the master and minion to calm down on activity after a bit (~5 minutes) the kubectl commands work, however the problem is I don't see any nodes running.

I have re-installed virtual box, made sure my .kube directory is clean and I am now pulling just the stock vagrant box cube fedora 21 and kubernetes 1.0.4 release. I do not see any docker processes running on my minion. Other than that it seems that the cluster is running:

$ ./cluster/kubectl.sh get cs
NAME STATUS MESSAGE ERROR
controller-manager Healthy ok nil
scheduler Healthy ok nil
etcd-0 Healthy {"health": "true"} nil

$ ./cluster/kubectl.sh cluster-info
Kubernetes master is running at https://10.245.1.2
KubeDNS is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/kube-dns
KubeUI is running at https://10.245.1.2/api/v1/proxy/namespaces/kube-system/services/kube-ui

yggdrasil:kubernetes jonathantronson$ vagrant ssh master
Last login: Wed Sep 16 23:49:51 2015 from 10.0.2.2
[vagrant@kubernetes-master ~]$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
51a50d5262a2 gcr.io/google_containers/kube-apiserver:d30a4eb51f43f129a5510844388ea554 "/bin/sh -c '/usr/loc" 50 minutes ago Up 50 minutes k8s_kube-apiserver.2abef58b_kube-apiserver-kubernetes-master_kube-system_496e220b4704d4b390883b4b90aa6635_4e41e61f
80a75c988469 gcr.io/google_containers/etcd:2.0.12 "/bin/sh -c '/usr/loc" 50 minutes ago Up 50 minutes k8s_etcd-container.fa2ab1d9_etcd-server-kubernetes-master_kube-system_6ef1b07678064a7edcdbec6f0570e917_59d753f9
acf026e410ac gcr.io/google_containers/kube-scheduler:9e8dbbdf754050032ca246394b184897 "/bin/sh -c '/usr/loc" 53 minutes ago Up 53 minutes k8s_kube-scheduler.ea78c200_kube-scheduler-kubernetes-master_kube-system_3d1ced0542467b566546021cb74d9bdf_9550be6a
6bd1f854913c gcr.io/google_containers/kube-controller-manager:d2b53b6d436229491bf9d2f14f5d8fdf "/bin/sh -c '/usr/loc" 53 minutes ago Up 53 minutes k8s_kube-controller-manager.fd0f0b82_kube-controller-manager-kubernetes-master_kube-system_2f59d05ecb2212d0379dc35dbe40d521_6292ac06
4676293c5620 gcr.io/google_containers/pause:0.8.0 "/pause" 54 minutes ago Up 54 minutes k8s_POD.e4cc795_kube-scheduler-kubernetes-master_kube-system_3d1ced0542467b566546021cb74d9bdf_62e6c529
fc3481ef2ee3 gcr.io/google_containers/pause:0.8.0 "/pause" 54 minutes ago Up 54 minutes k8s_POD.e4cc795_kube-controller-manager-kubernetes-master_kube-system_2f59d05ecb2212d0379dc35dbe40d521_09062f04
b287251a8560 gcr.io/google_containers/pause:0.8.0 "/pause" 54 minutes ago Up 54 minutes k8s_POD.e4cc795_etcd-server-kubernetes-master_kube-system_6ef1b07678064a7edcdbec6f0570e917_3d73246b
be5f65a44977 gcr.io/google_containers/pause:0.8.0 "/pause" 54 minutes ago Up 54 minutes k8s_POD.e4cc795_kube-apiserver-kubernetes-master_kube-system_496e220b4704d4b390883b4b90aa6635_c1bfe2c3

[vagrant@kubernetes-minion-1 ~]$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

The only errors in my minion salt log are:

2015-09-16 23:40:22,049 [salt.loaded.int.module.cmdmod][ERROR ][2668] Command 'systemctl status docker.service' failed with return code: 3

2015-09-16 23:40:22,049 [salt.loaded.int.module.cmdmod][ERROR ][2668] output: * docker.service - Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled)
Active: inactive (dead)
Docs: http://docs.docker.com

Hi,

I am running the latest version of kubernetes tar ball (v1.1.3) and facing issues with ./kube-up.sh
I was unable to fix the issue. Any help would be appreciated.

cluster "vagrant" set.
user "vagrant" set.
context "vagrant" set.
switched to context "vagrant".
Wrote config for vagrant to /home/nagarjung/.kube/config
Each machine instance has been created/updated.
Now waiting for the Salt provisioning process to complete on each machine.
This can take some time based on your network, disk, and cpu speed.
It is possible for an error to occur during Salt provision of cluster and this could loop forever.
Validating master
Connection to 127.0.0.1 closed.
Validating minion-1

Waiting for each minion to be registered with cloud provider
error: couldn't read version from server: Get https://10.245.1.2/api: dial tcp 10.245.1.2:443: connection refused

Thank You

Mac 10.11.2 installing kubernetes 1.1.3 got same issue:

cluster "vagrant" set.
user "vagrant" set.
context "vagrant" set.
switched to context "vagrant".
Wrote config for vagrant to /Users/flin/.kube/config
Each machine instance has been created/updated.
  Now waiting for the Salt provisioning process to complete on each machine.
  This can take some time based on your network, disk, and cpu speed.
  It is possible for an error to occur during Salt provision of cluster and this could loop forever.
Validating master
Validating minion-1
........
Waiting for each minion to be registered with cloud provider
error: couldn't read version from server: Get https://10.245.1.2/api: dial tcp 10.245.1.2:443: connection refused

I think the fix didn't catch the root cause.

same issues on 1.1.7

cluster "vagrant" set.
user "vagrant" set.
context "vagrant" set.
switched to context "vagrant".
Wrote config for vagrant to /Users/HenryWen/.kube/config
Each machine instance has been created/updated.
Now waiting for the Salt provisioning process to complete on each machine.
This can take some time based on your network, disk, and cpu speed.
It is possible for an error to occur during Salt provision of cluster and this could loop forever.
Validating master
^@^@^@^@^@^@^@^@^@^@connection to 127.0.0.1 closed.
Validating minion-1
...^@.......^@.......^@......
Waiting for each minion to be registered with cloud provider
error: couldn't read version from server: Get https://10.245.1.2/api: dial tcp 10.245.1.2:443: connection refused

when I rerun the cluster/kube-up.sh, the error still exist, and can't get nodes/services etc status.

The first time, it works. weird.

@derekwaynecarr can u help to take a look this issues? thanks

@henryon - can you open a new issue and describe what host environment you are using? Are you testing from master or a branch? cc me on the issue.

@derekwaynecarr I used released version 1.1.7.

btw, I tried several times. even at the last step failed. I can run ./cluster/kubectl.sh get pods/services etcs.

seems during verify stage. it will search local kubectl files? I am not sure. as on my Mac , there have some mismatch version kubectl file.

I experience the very same issue on AWS and, usually, I can't connect to my cluster anymore the day after I had set it up - which is a huge blocker. Here's the output from kubectl.sh version:

metmajer$ kubectl.sh version
Client Version: version.Info{Major:"1", Minor:"1", GitVersion:"v1.1.7", GitCommit:"e4e6878293a339e4087dae684647c9e53f1cf9f0", GitTreeState:"clean"}
error: couldn't read version from server: Get https://$IP/api: dial tcp $IP:443: connection refused

I expreience the same issue on Ubuntu.

kubectl version
Client Version: version.Info{Major:"1", Minor:"1", GitVersion:"v1.1.7", GitCommit:"e4e6878293a339e4087dae684647c9e53f1cf9f0", GitTreeState:"clean"}

The issue disappeared for me with the following version:

metmajer$ kubectl.sh version
Client Version: version.Info{Major:"1", Minor:"1", GitVersion:"v1.1.8", GitCommit:"a8af33dc07ee08defa2d503f81e7deea32dd1d3b", GitTreeState:"clean"}
Server Version: version.Info{Major:"1", Minor:"1", GitVersion:"v1.1.8", GitCommit:"a8af33dc07ee08defa2d503f81e7deea32dd1d3b", GitTreeState:"clean"}

I encounter the same problem,can you give me a detail configuration of kuberenetes?

➜ ubuntu /opt/bin/kubectl version
Client Version: version.Info{Major:"1", Minor:"1", GitVersion:"v1.1.8", GitCommit:"a8af33dc07ee08defa2d503f81e7deea32dd1d3b", GitTreeState:"clean"}
error: couldn't read version from server: Get http://localhost:8080/api: dial tcp 127.0.0.1:8080: connection refused