#DOCKER FOR MAC KUBERNETES VS MINIKUBE WINDOWS#

Here are some notes I have, from digging into the various xhyve/hyperkit/docker-machine-dryver-xhyve drivers. We would then have the choice of using one or both parts. Maybe minikube should be layered and the container could be provided and supported for multiple version of docker and the VM part use that container. Kmachine has the same problem since the client and server must be in sync but it only controls the server part, a problem docker doesn't have as it controls both parts. The coexistence setup (docker-toolbox and Docker for Mac) works as is as long as your VirtualBox VMs provisioned with docker-machine run the same version of Docker Engine as Docker for Mac. Using a VM doesn't not necessarily solves the docker issue (assuming that we want to connect to the hosted daemon, which might not be the case) since from the official docker documentation: It could be somewhat of a letdown to see that we are moving forward with one tool only to be brought backward with another tool.Īre there any major technical constraint to move to a container based approach? So far I have seen the DNS mentioned and shielding from docker upgrade. I expect that lots of user are thinking the same way: we now have native docker app, all we need is a container and we are off and running.

#DOCKER FOR MAC KUBERNETES VS MINIKUBE WINDOWS#

Investigation led me to this project and was somewhat disappointed with the direction for Windows and Mac. I actually, naively tried to use localkube with the docker for mac assuming that it would work since it is using docker. I feel that minikube is somewhat repeating this history. That is what docker did when they moved from docker-toolbox (docker-machine using a VM) to the 'native' application. The expectation of people using docker for mac (or windows) is that we should be able to run a container without having to setup a VM.

Docker for mac kubernetes vs minikube