Minikube: Unable to connect to the server: dial tcp 192.168.99.100:8443: i/o timeout

[kdurston]

Problem statement and error:
After starting minikube on my mac, I cannot connect to the server using kubectl version.

minikube reports status is OK:
$ minikube status
minikube: Running
cluster: Running
kubectl: Correctly Configured: pointing to minikube-vm at 192.168.99.100
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3", GitCommit:"d2835416544f298c919e2ead3be3d0864b52323b", GitTreeState:"clean", BuildDate:"2018-02-07T12:22:21Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"}
Unable to connect to the server: dial tcp 192.168.99.100:8443: i/o timeout

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

Please provide the following details:

Environment:

Minikube version (use minikube version): v0.25.0

• OS (e.g. from /etc/os-release): MacOS High Sierra v. 10.13.2
• VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName): "DriverName": "virtualbox",
• ISO version (e.g. cat ~/.minikube/machines/minikube/config.json | grep -i ISO or minikube ssh cat /etc/VERSION): "Boot2DockerURL": "file:///Users/[email protected]/.minikube/cache/iso/minikube-v0.25.1.iso",
• Install tools
  
  N/A
• Others:
  
  $VBoxManage --version
  5.1.14r112924

This is similar to closed #1224. Following suggestions in there, I tried the following without luck:

• disable firewall
• disable VPN
• restarted my machine
• reinstalled kubectl and minikube

What happened:
$ kubectl cluster-info dump
Unable to connect to the server: dial tcp 192.168.99.100:8443: i/o timeout
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3", GitCommit:"d2835416544f298c919e2ead3be3d0864b52323b", GitTreeState:"clean", BuildDate:"2018-02-07T12:22:21Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"}
Unable to connect to the server: dial tcp 192.168.99.100:8443: i/o timeout
$ kubectl cluster-info
Kubernetes master is running at https://192.168.99.100:8443

What you expected to happen:
I was hoping the command would be able to connect to the service.

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

Output of minikube logs (if applicable):

Anything else do we need to know:

[kdurston]

I do have vmware fusion installed on the machine but I am configured to use built-in driver as shown above.

Results of minikube ssh systemctl status localkube
diagnostics.txt

[kdurston]

Since minikube status says the server is running, I am considering scenarios in which the problem is access. How would I verify security certificates are not causing an access issue?

[wvxvw-traiana]

I'm not sure, but I may be seeing a similar problem. In the most recent version, the IP allocated to Minikube dashboard service is different on each run (for me, it increases by one each time). But few minutes after the initial cluster has been completely started, Minikube decides that it needs to do something with the VM, and so it declares it "stale". Once that happens, you may run minikube update-context only to discover that a new IP was allocated to the dashboard. Alas, you will not be able to use most of Minikube API, nor kubectl, since when Minikube started the initial VM it issued a certificate, and it only issued it to the initial IP.

Combined with how often Minikube crashes simply when it's idle... this is a tremendous productivity boost! While waiting for Minikube to restart, so far I finished reading a lengthy instruction manual and am thinking about re-reading "The Brave New World"... You guys save me about two hours every working day :)

Here's how it looks:

$ minikube service list
|-------------|------------------------|--------------------------------|
|  NAMESPACE  |          NAME          |              URL               |
|-------------|------------------------|--------------------------------|
| default     | kubernetes             | No node port                   |
| ...         |                        |                                |
| kube-system | kube-dns               | No node port                   |
| kube-system | kubernetes-dashboard   | http://192.168.99.106:30000    |
|-------------|------------------------|--------------------------------|
# Few minutes later, Minikube crashed
$ minikube service list
Get https://192.168.99.106:8443/api/v1/services: dial tcp 192.168.99.106:8443: getsockopt: no route to host
Check that minikube is running and that you have specified the correct namespace (-n flag) if required.
$ minikube status
minikube: Running
cluster: Running
kubectl: Misconfigured: pointing to stale minikube-vm.
To fix the kubectl context, run minikube update-context
$ minikube update-context
Reconfigured kubeconfig IP, now pointing at 192.168.99.105
$ minikube status
minikube: Running
cluster: Running
kubectl: Correctly Configured: pointing to minikube-vm at 192.168.99.105
$ minikube service list
Get https://192.168.99.105:8443/api/v1/services: x509: certificate is valid for 192.168.99.106, 10.96.0.1, 10.0.0.1, not 192.168.99.105
Check that minikube is running and that you have specified the correct namespace (-n flag) if required.

Ouch, there may be a way around it :( #1974

Nope, doesn't help. After minikube update-context the IP is set randomly.

[jagraj]

I had a working session with Karen yesterday and she had a problem with virtual adapter where VMWare fusion and Virtual Box was stepping on each other for same virtual adapter. After uninstalling everything and rebooted Mac to clean up both installs.

After uninstall everything, reboot Mac and reinstalling Virtual Box and Minikube worked fine. Based on my understanding VMWare fusion and Virtual Box can not co-exist.

@kdurston you can add your input as well to this issue.

[kdurston]

Many thanks to my colleague Jag Gangaraju for resolving this issue. As he says, the root cause was that I had installed VMware Fusion prior to minikube and Virtual Box. the issue was on the networking level - all the upper level configuration was OK- ifconfig was the diagnostic that helped.
I am closing this issue.

[kjonnala]

Had a similar issue on my mac ( High Seirra ) . After re-installing virtualbox things started working. Did not have to restart the mac though, I still have my VMWare sitting there for now.
Steps:

1. Install virtualbox
2. minikube start
3. kubectl config view
4. minikube dashboard

[leapingbytes]

I am pretty sure that this is due to untrusted certificate... try to connect to https://192.168.99.100:8443 with the browser... you will see...

now how to convince kubectl to trust this cert?

[manodupont]

Anymore help on that. I don't have VMware, only VBox ... i still can't connect.... this is crazy. I think i rebooted 20 times, reinstalling minikube, vbox, tried other versions too etc . I still never can't connect.

manueldupont@manu-macbook-perso ~ $ minikube start
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
Getting VM IP address...
Moving files into cluster...
Setting up certs...
Connecting to cluster...
Setting up kubeconfig...
Starting cluster components...
E0628 16:59:26.250125   60189 start.go:299] Error restarting cluster:  restarting kube-proxy: waiting for kube-proxy to be up for configmap update: timed out waiting for the condition
================================================================================
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]:

[leapingbytes]

@manodupont have you tried minikube start --vm-driver hyperkit (you need to install hyperkit first)... in my case this option works the best.

[manodupont]

So I just discovered that if I uninstall (not turning off), but uninstalling complement my VPN client (Cisco AnyConnect in my case), it ‘finally’ worked. After like a month of research. But still, this is not good. I DO need my VPN :).

So, is the driver will change anything compared to VBox you think ? Any warnings ?

On Jun 28, 2018, at 6:00 PM, Andrei Tchijov <[email protected][e-mail]> wrote:

@manoduponthttps://github.com/manodupont have you tried minikube start --vm-driver hyperkit (you need to install hyperkit first)... in my case this option works the best.

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

[hejhj]

on windows 10+ virtual box, tried run following commands 3 times, now issue gone.
minishift.exe start --vm-driver virtualbox

[ChenYang-ChenYang]

@manodupont I have the similar situation with you that it works if I turn off Cisco AnyConnect. I also need the VPN. I'm still trying to see how to resolve it. Anyway, your finding saved lots of research time for me. Thanks.

[RafaelIoT]

'minikube start' solved it for me

[dyyce]

@RafaelIoT
thank you! it was as simple as that.

[jsaevitzon]

minikube start and reinstalling virtual box worked for me

[basiszwo]

@manodupont @ChenYang-ChenYang I also have cisco anyconnect. Even shutting it down didn't work for me. I am trying to use vbox as well.

[ntippabhatla]

@manodupont @ChenYang-ChenYang I also have cisco anyconnect. Even shutting it down didn't work for me. I am trying to use vbox as well.

Hey hi did your issue resolve?

[AchalGupta277]

In my case on minikube status output is

_minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Stopped
kubeconfig: Configured_

i.e my api server was not running, on starting minikube again (minikube start) I got

_minikube is unable to connect to the VM: dial tcp 192.168.99.101:22: i/o timeout
This is likely due to one of two reasons:
- VPN or firewall interference
- virtualbox network configuration issue_

And the reason was VPN interference, on stopping vpn and starting again (minikube start) it worked perfectly.