Change:
{% set test_args=pillar['kubeproxy_test_args'] %} {% endif -%} <del> DAEMON_ARGS="{{daemon_args}} {{api_servers_with_port}} {{kubeconfig}} {{pillar['log_level']}}" </del> # test_args has to be kept at the end, so they'll overwrite any prior configuration <del> DAEMON_ARGS="$DAEMON_ARGS + {{test_args}}" </del> <ins> DAEMON_ARGS="{{daemon_args}} {{api_servers_with_port}} {{kubeconfig}} {{pillar['log_level']}} {{test_args}}" </ins>

Discussion:
I follwed the Getting Started guide from and tried deploying a vagrant based cluster on RHEL 7, first by building the source code and then when that didn't work, using the curl script. In both cases the cluster seems to be set up and I can do a vagrant ssh to the master and a minion, but running kubectl get pods or for that matter almost all kubectl commands return: error: couldn't read version from server: Get https://10.245.1.2/api: dial tcp 10.245.1.2:443: no route to host I read somewhere that this could happen if your config was faulty, so I tried config info and this is what I get: config view apiVersion: v1 clusters: cluster: insecure-skip-tls-verify: true server: http://127.0.0.1:8080 name: local cluster: certificate-authority-data: REDACTED server: https://10.245.1.2 name: vagrant contexts: context: cluster: local user: "" name: local context: cluster: vagrant user: vagrant name: vagrant current-context: vagrant kind: Config preferences: {} users: name: vagrant user: client-certificate-data: REDACTED client-key-data: REDACTED password: vagrant username: vagrant I'd gotten this to work in a different machine successfully with v1beta3. Unfortunately I don't have access to that machine any more so don't know what the configuration had been set to. Any help would be much appreciated. Cheers --Rupa
Looking at the config-default .sh file in the vagrant folder, I see that MASTERIP and KUBEMASTER_IP is set to 10.245.1.2. However pinging the IP address doesn't work. When I do a vagrant ssh master, and an ifconfig, the eth0 inet address is not 10.245.1.2. either.
I am having the same problem. Running with ends with: are you seeing this on latest master? Edit: this just recently occurred when rebasing my working branch to upstream, I'm not sure exactly when this occured however as I have been working on the networking, but yesterday morning this worked fine.

There was a bug in the v1 release that caused network manager to control the eth1 device when it should not have been doing so. The fix for that was merged in HEAD a few weeks ago, and the cherry pick to go in the 1.0 release was made last night here: As for e2e, it had passed conformance tests, but I will see if I can reproduce the issue you are seeing now to determine the cause if I can reproduce at HEAD.
- I was able to reproduce your error just now. There must have been some kind of regression in the last day. I see the kubelet starts on the master, and docker is running, but doing a shows no attempt to start the api server container. I will need to do some digging into what caused the regression in the last day.
- think I found the offending PR that broke the setup here:
thanks for checking this out, Is there anything I can do to help sort out the regression? Edit: read , looks like you have it covered already. Thanks again!
See fix above.
Once there's a fix, downloading the latest source from MASTER or using the curl script again should both work ?
Latest source from MASTER should work fine. Please confirm. , rupsee wrote:
Confirmed that latest master is again working, sorry it took so long to get back to you.
I'll try it and post here tomorrow, it's the end of my day here now. Thanks a bunch for the quick turnaround.
I still see a similar issue with a somewhat different error message, "connection refused" instead of "no route to host". Here's what I did: git clone cd kubernetes make quick-release export KUBERNETES_PROVIDER=vagrant ./cluster/kube- At the bottom of the master and minion updates I see this: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 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 ...... 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 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Then I tried: [root kubernetes]# 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
here's part of what I get from ifconfig from the master: .................................................................................................. cbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICASTmtu 1500 inet 10.246.0.1 netmask 255.255.255.0 broadcast 10.246.0.255 .................................................................................................. eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICASTmtu 1500 inet 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255 .................................................................................................. eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICASTmtu 1500 inet 10.245.1.2 netmask 255.255.255.0 broadcast 10.245.1.255
Here's what " config view" returns: apiVersion: v1 clusters: cluster: insecure-skip-tls-verify: true server: http://127.0.0.1:8080 name: local cluster: certificate-authority-data: REDACTED server: https://10.245.1.2 name: vagrant contexts: context: cluster: local user: "" name: local context: cluster: vagrant user: vagrant name: vagrant current-context: vagrant kind: Config preferences: {} users: name: vagrant user: client-certificate-data: REDACTED client-key-data: REDACTED password: vagrant username: vagrant
And finally,I'm on a RHEL 7 box - don't know if that matters. lsb_release -i -r Distributor ID: RedHatEnterpriseServer Release: 7.0
- I am closing this issue since vagrant should be stable now on HEAD and in the release branches.

Your connection refused error is most likely not being connected to the vboxnet device on your host to your VM that Virtual Box launches. To check, open Virtual Box and look at the Network Adapter setting for kubernetes-master. You should see something like the following: ! Make sure your host is connected to that adapter (in my case its vboxnet5) The other alternative is to just ssh into the master box and use kubectl from there: $ vagrant ssh master $ kubectl get nodes Either way should work well. Reopen if you continue to have issues.
Hi Derek, thanks for getting back. I should have closed this one ... It was because I hadn't set the KUBERNETRS_MASTER environment variable. None of the documentation talks about it though. I'd to figure it out from the cluster scripts in the back folder. Cheers Rupa On Sep 11, 2015 12:40 AM, "Derek Carr" wrote:
I meant the hack folder, Swype seems to think it knows best! On Sep 11, 2015 6:43 AM, "Sreerupa Sen" wrote: