Change:
- kubernetes-master runtime_config: '$(echo "$RUNTIME_CONFIG" | sed -e "s/'/''/g")' docker_opts: '$(echo "$DOCKER_OPTS" | sed -e "s/'/''/g")' <ins> master_extra_sans: '$(echo "$MASTER_EXTRA_SANS" | sed -e "s/'/''/g")' </ins> EOF mkdir -p /srv/salt-overlay/pillar cat <<EOF >/srv/salt-overlay/pillar/cluster-params.sls service_cluster_ip_range: '$(echo "$SERVICE_CLUSTER_IP_RANGE" | sed -e "s/'/''/g")' <del> cert_ip: '$(echo "$MASTER_IP" | sed -e "s/'/''/g")' </del> enable_cluster_monitoring: '$(echo "$ENABLE_CLUSTER_MONITORING" | sed -e "s/'/''/g")' enable_cluster_logging: '$(echo "$ENABLE_CLUSTER_LOGGING" | sed -e "s/'/''/g")' enable_node_logging: '$(echo "$ENABLE_NODE_LOGGING" | sed -e "s/'/''/g")'

Discussion:
On latest Kubernetes version Release 0.20.1 Candidate I get the following when you setup cluster with "./cluster/kube-". This is on Mac OSX with VirtualBox, Vagrant Any ideas, thanks .... ==minion-3:  INFO: Running daemons_running() ==minion-3:  INFO: Salt installed! Wrote config for vagrant to 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 Validating minion-2 Validating minion-3 ..... 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 kubernetes user1$ get nodes error: couldn't read version from server: Get https://10.245.1.2/api: dial tcp 10.245.1.2:443: connection refused
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 this is that console says
See my comment on
I think 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:
- 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 briefly, he kindly agree to take a look. 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/ since he looked into vagrant issue lately. cc/ on Vagrant.

+1, 0.20.2 still has this issue
+1
The fix for this issue is this PR:
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.
I was running into the same issue and cherry picked your changes in , 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: It looks like also needed before vagrant works correctly.
Yep, I picked and then merged and it started to work again... just my 2 cents
this error is gone in 0.21.0 rc ()
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+") and I am seeing this issue when I run ./cluster/kube- 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 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: $ get cs NAME STATUS MESSAGE ERROR controller-manager Healthy ok nil scheduler Healthy ok nil etcd-0 Healthy {"health": "true"} nil $ 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 ~]$ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES "/bin/sh -c '/usr/loc" 50 minutes ago Up 50 minutes k8skube-apiserver.2abef58bkube-apiserver-kubernetes-masterkube-system496e220b4704d4b390883b4b90aa66354e41e61f "/bin/sh -c '/usr/loc" 50 minutes ago Up 50 minutes k8setcd-container.fa2ab1d9etcd-server-kubernetes-masterkube-system6ef1b07678064a7edcdbec6f0570e91759d753f9 "/bin/sh -c '/usr/loc" 53 minutes ago Up 53 minutes k8skube-scheduler.ea78c200kube-scheduler-kubernetes-masterkube-system3d1ced0542467b566546021cb74d9bdf9550be6a "/bin/sh -c '/usr/loc" 53 minutes ago Up 53 minutes k8skube-controller-manager.fd0f0b82kube-controller-manager-kubernetes-masterkube-system2f59d05ecb2212d0379dc35dbe40d5216292ac06 "/pause" 54 minutes ago Up 54 minutes k8sPOD.

e4cc795kube-scheduler-kubernetes-masterkube-system3d1ced0542467b566546021cb74d9bdf62e6c529 "/pause" 54 minutes ago Up 54 minutes k8sPOD.e4cc795kube-controller-manager-kubernetes-masterkube-system2f59d05ecb2212d0379dc35dbe40d52109062f04 "/pause" 54 minutes ago Up 54 minutes k8sPOD.e4cc795etcd-server-kubernetes-masterkube-system6ef1b07678064a7edcdbec6f0570e9173d73246b "/pause" 54 minutes ago Up 54 minutes k8sPOD.e4cc795kube-apiserver-kubernetes-masterkube-system496e220b4704d4b390883b4b90aa6635c1bfe2c3 [vagrant ~]$ 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 [][ERROR ][2668] Command 'systemctl status docker.service' failed with return code: 3 2015-09-16 23:40:22,049 [][ERROR ][2668] output: * docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled) Active: inactive (dead) Docs:
Hi, I am running the latest version of kubernetes tar ball (v1.1.3) and facing issues with ./kube- 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 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: 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 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 ^ 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-, the error still exist, and can't get nodes/services etc status. The first time, it works. weird.
can u help to take a look this issues? thanks
- 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.
I used released version 1.1.7. btw, I tried several times. even at the last step failed. I can run 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 :
I expreience the same issue on Ubuntu.
The issue disappeared for me with the following version:
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:"", GitTreeState:"clean"} error: couldn't read version from server: Get http://localhost:8080/api: dial tcp 127.0.0.1:8080: connection refused