Minikube: "Starting cluster components" fails with `TLS handshake timeout` error to master

[bitfield]

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

BUG REPORT

Please provide the following details:

Minikube version (use minikube version):

minikube version: v0.28.0

• OS (e.g. from /etc/os-release):

macOS 10.11.6

• VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName):

virtualbox

• ISO version (e.g. cat ~/.minikube/machines/minikube/config.json | grep -i ISO or minikube ssh cat /etc/VERSION):

"Boot2DockerURL": "file:///Users/john/.minikube/cache/iso/minikube-v0.28.0.iso",

• Install tools:

Installed manually.

What happened:

I installed the latest VirtualBox, installed the latest Minikube, and ran minikube start.

This is the output:

Starting local Kubernetes v1.10.0 cluster...
Starting VM...
Downloading Minikube ISO
 153.08 MB / 153.08 MB [==================================] 100.00% 0s
Getting VM IP address...
Moving files into cluster...
Downloading kubelet v1.10.0
Downloading kubeadm v1.10.0
Finished Downloading kubelet v1.10.0
Finished Downloading kubeadm v1.10.0
Setting up certs...
Connecting to cluster...
Setting up kubeconfig...
Starting cluster components...
E0618 16:41:56.028210    5822 start.go:294] Error starting cluster:  timed out waiting to unmark master: getting node minikube: Get https://192.168.99.100:8443/api/v1/nodes/minikube: net/http: TLS handshake timeout
================================================================================
An error has occurred. Would you like to opt in to sending anonymized crash
information to minikube to help prevent future errors?
To opt out of these messages, run the command:
        minikube config set WantReportErrorPrompt false
================================================================================
Please enter your response [Y/n]:

What you expected to happen:

I expected the cluster to start up correctly.

How to reproduce it (as minimally and precisely as possible):

See above.

Output of minikube logs (if applicable):

Attached.

[bitfield]

minikube-logs.txt

[manodupont]

samething here ...

im on Macos 10.13.5 (17F77)
minikube version: v0.28.0
VirtualBox : Version 5.2.12 r122591 (Qt5.6.3)

minikube logs:

manueldupont@manu-macbook-pro ~ $ minikube logs F0618 21:30:56.577468 28519 logs.go:50] Error getting cluster bootstrapper: getting kubeadm bootstrapper: getting ssh client: Error dialing tcp via ssh client: dial tcp 127.0.0.1:22: getsockopt: connection refused manueldupont@manu-macbook-pro ~ $

[rob-scheepens]

Similar on Mac OSX 10.12.6:

========================================
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
Downloading Minikube ISO
E0725 13:22:01.370547   40448 start.go:174] Error starting host: Error attempting to cache minikube ISO from URL: Error downloading Minikube ISO: failed to download: failed to download to temp file: download failed: 5 error(s) occurred:

* Temporary download error: Get https://storage.googleapis.com/minikube/iso/minikube-v0.28.1.iso: net/http: TLS handshake timeout
* Temporary download error: Get https://storage.googleapis.com/minikube/iso/minikube-v0.28.1.iso: net/http: TLS handshake timeout
* Temporary download error: Get https://storage.googleapis.com/minikube/iso/minikube-v0.28.1.iso: net/http: TLS handshake timeout
* Temporary download error: Get https://storage.googleapis.com/minikube/iso/minikube-v0.28.1.iso: net/http: TLS handshake timeout
* Temporary download error: Get https://storage.googleapis.com/minikube/iso/minikube-v0.28.1.iso: net/http: TLS handshake timeout.

 Retrying.
E0725 13:22:01.371042   40448 start.go:180] Error starting host:  Error attempting to cache minikube ISO from URL: Error downloading Minikube ISO: failed to download: failed to download to temp file: download failed: 5 error(s) occurred:

* Temporary download error: Get https://storage.googleapis.com/minikube/iso/minikube-v0.28.1.iso: net/http: TLS handshake timeout
* Temporary download error: Get https://storage.googleapis.com/minikube/iso/minikube-v0.28.1.iso: net/http: TLS handshake timeout
* Temporary download error: Get https://storage.googleapis.com/minikube/iso/minikube-v0.28.1.iso: net/http: TLS handshake timeout
* Temporary download error: Get https://storage.googleapis.com/minikube/iso/minikube-v0.28.1.iso: net/http: TLS handshake timeout
* Temporary download error: Get https://storage.googleapis.com/minikube/iso/minikube-v0.28.1.iso: net/http: TLS handshake timeout
================================================================================
An error has occurred. Would you like to opt in to sending anonymized crash
information to minikube to help prevent future errors?
To opt out of these messages, run the command:
    minikube config set WantReportErrorPrompt false
================================================================================
Please enter your response [Y/n]: 
Y
E0725 13:22:14.291704   40448 util.go:151] Error uploading error message: : Post https://clouderrorreporting.googleapis.com/v1beta1/projects/k8s-minikube/events:report?key=AIzaSyACUwzG0dEPcl-eOgpDKnyKoUFgHdfoFuA: net/http: TLS handshake timeout

Manually downloading using the URL in Chrome/Safari works.

[tstromberg]

Sounds like a networking issue. Any kind of firewall or VPN software involved?

[joeapearson]

I investigated with @manodupont and we found the issue was caused by Cisco AnyConnect VPN https://www.virtualbox.org/ticket/14293 (I know this ticket is closed but it appears the bug still occurs in some circumstances).

I suppose this therefore isn't a minikube issue per se but it was pretty difficult to track down.

[bitfield]

That would make sense: I was probably running a sshuttle VPN at the time.

[gbraad]

did sshuttle work for you?

On Thu, Sep 20, 2018 at 11:09 PM John Arundel [e-mail]
wrote:

That would make sense: I was probably running a sshuttle VPN at the time.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/minikube/issues/2910#issuecomment-423219474,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAHZvW8ttugeT9giE6cYDpaAGbHvzdEks5uc6_EgaJpZM4UsBFA
.

--

Gerard Braad | http://gbraad.nl
[ Doing Open Source Matters ]

[manodupont]

Unfortunately its been a while now I would need to get back to the same environment and im to sure its possible actually :(

But its definitely a VPN problem as it looked.

On Sep 20, 2018, at 5:22 PM, Gerard Braad <[email protected][e-mail]> wrote:

did sshuttle work for you?

On Thu, Sep 20, 2018 at 11:09 PM John Arundel <[email protected][e-mail]>
wrote:

That would make sense: I was probably running a sshuttle VPN at the time.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/minikube/issues/2910#issuecomment-423219474,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAHZvW8ttugeT9giE6cYDpaAGbHvzdEks5uc6_EgaJpZM4UsBFA
.

--

Gerard Braad | http://gbraad.nl
[ Doing Open Source Matters ]

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/kubernetes/minikube/issues/2910#issuecomment-423223750, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AHN6oXrUjvBSYCV4KS7FDQ8-p6LOkGa4ks5uc7K2gaJpZM4UsBFA.

[joeapearson]

Next time you see this issue, try running this on the host machine:

netstat -rn | grep vboxnet

You should see some routing output. I found that, in the cases where this issue appeared, Cisco AnyConnect was blowing away all the routes completely (that command would return nothing). As soon as you disconnect VPN they all get restored.

Anyway I think this isn't a Minikube issue, nor even (perhaps) a VirtualBox issue.

[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-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten