Minikube: Speed up minikube start

[mcandre]

minikube start takes 60+ seconds to do its work, which stinks for users who wish to quickly, repeatedly start and tear down several minikube clusters. Can this process be sped up somehow?

[r2d4]

Definitely agreed this should be a focus. Previously, we've been working on the stability of minikube, but now it might make sense to look at performance improvements with starting up.

It might be useful to document the exact startup process that minikube goes through so we can identify what points can be done in parallel or sped up.

[aaron-prindle]

Right now minikube uses docker/libmachine for provisioning VMs and most of the time is spent provisioning the VM and then waiting for all services to be running. If you want to try to profile minikube start you can use the MINIKUBE_ENABLE_PROFILING flag here: https://github.com/kubernetes/minikube#minikube-environment-variables

The only way to speed this process up currently would be to run one of the WIP generic/no-vm drivers which are much faster as they run everything on the host and not in a VM:
https://github.com/kubernetes/minikube/pull/1173
https://github.com/kubernetes/minikube/pull/1152
NOTE: These currently only support linux and require docker to be installed.

[dongsupark]

👍
I also think it takes longer than expected, until minikube start finished. For me it takes mostly up to 120 seconds.
I totally agree that the on-going works mentioned above could really help. However, I'm also wondering, if that's because localkube service wants network-online.target. Is that really necessary?

[aaron-prindle]

Related: #1277

[dlorenc]

We've removed the network-online.target.

[dfee]

I found this issue as it's taking minutes for minikube start to start for me. I see the issue, "Speed up minikube start" has been closed – is that appropriate?

The full workflow looks like this:

minikube delete
minikube start --vm-driver=hyperkit --mount-string=/Users/dfee/code:/code --mount --v=3
minikube stop
minikube start --vm-driver=hyperkit --mount-string=/Users/dfee/code:/code --mount --v=3

The restarting surprisingly takes the longest (5+ min)

[eliot1785]

I'd just like to add on to this, I think it should be reopened. For me it's more like a 10 minute startup (the first time I'm running it). I believe that the main issue is that the download of various images is very slow. For me it was as slow as 1/10 MB/s to download the Minikube ISO... I'm in NYC and I have a 150Mbps connection, and I tested separately with SpeedTest.net and I'm getting my promised speed from my provider. Maybe the files are being hosted in a single server far from me.

Specifically, the slowest steps were:

• Downloading Minikube ISO
• Downloading kubeadm v1.13.4 / Downloading kubelet v1.13.4 (I think these might have been in parallel)
• Pulling images required by Kubernetes v1.13.4

FWIW I'm running a 2015 MacBook Pro with macOS Mojave (10.14.3). I first installed Docker for Mac before I got involved w/ Kubernetes, and as part of the Docker tutorials I installed VirtualBox which is being used by minikube here. Now I'm installing minikube.

[afbjorklund]

There's some work ongoing to be able to do those steps ahead-of-time, like "batteries included".

See --cache-images and the recent --download-only flag that was suggested in #3736

[eliot1785]

Thanks for the note. Although I imagine that even if the work is done ahead of time, it will still need to be done again whenever a version update is performed, right?

[afbjorklund]

If there is a version update, some of the new components will have to be downloaded. Others not. As in: you can re-use the ISO, even with a new Kubernetes version. And some subcomponents are the same.

Anyway, this issue was about speeding up the start of the virtual machine (something that is still slow). What you are describing is mostly related to other issues, about speeding up the initial/second download.

[dgoldssfo]

Using minikube 0.34.1. I'm working remotely today with a rather slow internet connection. minikube start has been stuck on:

🚜 Pulling images required by Kubernetes v1.13.2 ...

for well over an hour now.

I realize you don't expect people to be working on such a slow ISP, and maybe I'll have to go somewhere else to work. But how about some diagnostics to let users know what's going on here. Am I 90% done now? 20% done? Or has the thing had to restart 10 times because it lost a connection somewhere along the way? I have no way of telling.

[afbjorklund]

It would be nice to have image progress bars, but that requires some new feature in the library used.

It might be doable to make one that shows the number of images though, even if not the actual size...