Running Minikube with `vm-driver=none`

What I learned today — 6 August 2018

Minikube is an indispensable tool for developing applications targeted for Kubernetes. Running such workloads can quickly overwhelm an underpowered developer workstation. In June I wrote about using KVM rather than VirtualBox for a more lightweight environment. Today I’m trying to push the needle even further by running the Kubernetes cluster directly on my local docker host by starting Minikube with the --vm-driver=none option.

I’m using the following:
- Ubuntu 18.04 LTS
- Minikube version v0.27.0
- Docker version 18.03.1-ce

Launch Minikube

sudo minikube start --vm-driver=none --apiserver-ips 127.0.0.1 --apiserver-name localhost

After some time you should see the following output:

WARNING: IT IS RECOMMENDED NOT TO RUN THE NONE DRIVER ON PERSONAL WORKSTATIONS
The 'none' driver will run an insecure kubernetes apiserver as root that may leave the host vulnerable to CSRF attacks
When using the none driver, the kubectl config and credentials generated will be root owned and will appear in the root home directory.
You will need to move the files to the appropriate location and then set the correct permissions. An example of this is below:
 sudo mv /root/.kube $HOME/.kube # this will write over any previous configuration
sudo chown -R $USER $HOME/.kube
sudo chgrp -R $USER $HOME/.kube

sudo mv /root/.minikube $HOME/.minikube # this will write over any previous configuration
sudo chown -R $USER $HOME/.minikube
sudo chgrp -R $USER $HOME/.minikube
This can also be done automatically by setting the env var CHANGE_MINIKUBE_NONE_USER=true
Loading cached images from config file.

With my setup I didn’t need to do most of the above.

Change owner and group

I only changed the owner and group of .minikube/ to belong to $USER (me).

sudo chown -R $USER $HOME/.minikube
sudo chgrp -R $USER $HOME/.minikube

Warning

WARNING: IT IS RECOMMENDED NOT TO RUN THE NONE DRIVER ON PERSONAL WORKSTATIONS
 The ‘none’ driver will run an insecure kubernetes apiserver as root that may leave the host vulnerable to CSRF attacks

At this stage I don’t fully understand why this is a problem on a personal workstation. I’ll update here as soon as I know. Please feel free to enlighten me in the comments.

Conclusion

Launching Minikube completely locally is really simple. Beyond launching it with the correct parameters I only needed to fix ownership on ~/.minikube. So far I haven’t encountered any issues using it.