Troubleshooting annoying issues with Minikube
I have recently written two stories about managing Minikube:
I faced some really annoying issues whilst writing them down. So I decided to write this post in order to help myself — and maybe other people — should we face them again someday.
The wifi that stopped working after trying Docker for Windows
During the marvellous experience with Minikube for Windows, I tried to use Docker with Hyper-V.
Then, I started Minikube. It hanged in the message “Waiting for an IP…”.
But the point is …. Docker for Windows will use by default a VM with an external switch called DockerNAT. This swtich has no access to the internet, so no way we can get an IP.
OK, so… after some googling I checked that I needed to configure an external switch in Hyper-V, configuring it to use the Wifi of my PC. And then, I started minikube with the params to use this external switch.
Did it work? No, unfortunately not. Then I saw this tutorial, which uses Docker for Windows with VirtualBox. I told myself “ok, I’m going to do like this”.
Everything worked like a charm but … I didn’t have Wifi connection anymore. It was kind of a weird situation. Cabled internet OK, Wifi not at all. But, every time I did a system restore Wifi came back to life … until I retried Hyper-V.
After days of struggling, I changed the configuration of the external switch I created to use anything but my Wifi, and — shazam! — Wifi came back to life.
Conclusion: be really careful if you use Docker for Windows connected to Hyper-V (I would say: don’t do this for the moment, use Virtual Box instead, even if Docker annoys you asking to enable Hyper-V…)
Docker never switching to Minikube environment in Linux
This one is the typical frustrating issue, whose solution is so simple that it makes you feel like an idiot.
As a typical Linux newbie I was used to run all minikube commands with the sudo prefix (my local user having no permissions to do any of the desired commands).
Then I came to the step where I wanted to switch Docker environment to Minikube’s one.
$ eval $(minikube docker-env)It wasn’t possible to do this. Then I ran the eval command with sudo. I had some weird messages and when I ran docker images command, I could never find myself into minikube environment.
The point is that, the expression $(minikube docker-env) could not be evaluated (OF COURSE).
Solution: running as admin.
Minikube start hangs on “Waiting for SSH to be available…”
I was really happy after finally getting everything to work… switched down my machine and … in the following day I tried restart minikube and I had this REALLY ANNOYING situation of the “Waiting for SSH to be available…” hanging on.
You can google here, google there and find lots of different solutions and none of them helps you. Really annoying…
The point is that it really takes long to get this SSH, and when I ran minikube start and saw that it took long to finish, I pushed Ctrl+C in order to stop and tried again with --v=3 to see the details.
What I didn’t realize is that one instance of minikube was stopped properly (because I had used Ctrl+C) and when I launched a new one everything went to hell.
So I ran a command minikube stop in order to stop everything that was running. After I ran the minikube start --v=3 again and waited. It worked like a charm.
Conclusion: it is highly recommended that you run a ‘minikube stop’ every time you finish your work and want to restart/shut down your machine. Prioritize finishing your work gracefully… for your own health.
Minikube says that machine exists but it doesn’t
This is the classical one that proves how you must be careful when restarting everything from scratch.
After I failed using minikube for Windows with Hyper-V, I decided giving it a try with Virtual Box. Fine…
Then I ran the command “minikube start” and it halted with this kind of error
PS C:\> .\minikube start --show-libmachine-logs --alsologtostderr
...
I1003 15:59:52.800397 12080 notify.go:103] Checking for updates...
Starting local Kubernetes cluster...
I1003 15:59:53.164759 12080 cluster.go:75] Machine exists!
I1003 15:59:54.133728 12080 cluster.go:82] Machine state: Error
E1003 15:59:54.133728 12080 start.go:85] Error starting host: Error getting state for host: machine does not exist. Re
trying.
I1003 15:59:54.243132 12080 cluster.go:75] Machine exists!
I1003 15:59:54.555738 12080 cluster.go:82] Machine state: Error
E1003 15:59:54.555738 12080 start.go:85] Error starting host: Error getting state for host: machine does not exist. Re
trying.
I1003 15:59:54.555738 12080 cluster.go:75] Machine exists!
I1003 15:59:54.790128 12080 cluster.go:82] Machine state: Error
E1003 15:59:54.790128 12080 start.go:85] Error starting host: Error getting state for host: machine does not exist. Re
trying.
E1003 15:59:54.790128 12080 start.go:91] Error starting host: Error getting state for host: machine does not exist
Error getting state for host: machine does not exist
Error getting state for host: machine does not existI switched Hyper-V again because I knew there was a minikube VM there and restarted the machine. I then went to Hyper-V management, deleted the minikube machine, switched off Hyper-V, restarted the machine and retried minikube on VirtualBox…
And the error striked again … what the hell?!
After punching the table in real frustration lots of times and some nervous googling, I discovered that minikube keeps a track of the machines it creates in the .minikube folder. And, of course, the program checked this configuration in order to start. As I decided retrying from scratch, I didn’t realize that … I was not restarting from scratch! I had to delete old config!
Conclusion: if you want to restart minikube from scratch don’t forget not only to delete the corresponding VM, but also to remove the contents of the .minikube folder.
“Endpoint for service is not ready yet “ error
In one of the responses for my story, Jianjun Shen wrote:
As I did not end up on this error, he could find the solution himself. The issue was on firewall between China mainland and the rest of the world.
Here goes his solution:
