Yeah, I used minikube for local dev on k8s services and ended up just using it for all Docker stuff after a while. It is slightly less ergonomic than Docker for Mac though especially with respect to DNS and network issues. For instance, the minikube VM and any containers running in it cannot by default use the host machines VPN, so if you have to connect to an external service over your corporate VPN then you need to do some extra config (which isn't very well documented) to make it work. And the setup I ended up using was to use the VPNKit socket that was part of Docker for Mac to make it work. Now VPNKit is also OSS so I'm sure you can get it to work without Docker for Mac at all but it's also not trivial.
Before Docker Desktop there existed a solution called docker toolkit that worked exactly like this. The only problem is that occasionally internal corporate networks will use the same ip address and you have to customize that by building your own docker engine.
Beware of VirtualBox. While part of it is free, it's not very useful without the extension package. This package is easy to download on the same website as VirtualBox, but... it's not free.
Even better Oracle tracks the ips that download this extension and after a suitable amount of time they will come knocking on your company's door asking for an insulting amount of money (e.g. more expensive than VMware) or get sued. You need to read the fine print of the additional Eula printed in really small letters on the VirtualBox website to figure out the extension isn't free. It's almost a honeypot tactic. Scummy.
I don't know how Macs fare, but on Linux the extension package is not really a great feat, mostly adds RDP and some faster USB modes, but USB passthrough is marginal at most anyway.
That's a reductive way to phrase it, but more or less yes.
It's arguable if the container is "virtualized linux" as they all share a single linux kernel. In reality there's one virtual machine, one linux kernel, and many linux userspaces (one per container), which is kinda the whole point of containers.
Over docker+linux, the virtual machine is the only additional layer.
fwiw, I personally don't use macOS, so I've only got virtualized linux (containers) run by docker running on linux running on my hardware.
Are you trying to make a point or something here? Like, yes, we've built layers of abstraction that include different types of virtualization (VMs and containers), and they compose. Is that all you're observing?
> Are you trying to make a point or something here?
Nah, just curious/intrigued by how these stack.
OS-level virtualization is very much a thing. I'd be interesting to compare this to the approach taken by Docker Dekstop for Mac. I bet they do something quite similar (hypervisor-based virtualization like Virtualbox) - nothing fancy like WSL1 that I believe runs a sort of "tortured" Linux kernel inside the NT kernel.
WSL1 didn't run a Linux kernel at all - it was implementing the Linux user-space API over the Windows NT kernel. Well, some of it - not enough to run Docker, for example.
Docker on Windows and Mac does the same as what is described above - it runs a Linux VM and runs the docker server inside that, and then does a little magic to expose native OS paths and so on to that VM. On Windows, it uses WSL2 by default now, but WSL2 is also a Hyper-V VM in the end, with some Windows magic to blend it more nicely in Windows workflows.
That’s how it has to work when there’s a kernel mismatch from host to guest. You’re implying more layers than there actually are.
- MacOS running a hypervisor
- A Linux VM with Docker installed.
- A Linux container running on that VMs kernel.
Containers on Linux aren’t virtualized (normally, you could use runV I suppose if you wanted). The only overhead is the extra disk space to extract the root fs of the container image and the namespacing.
I’m also using Hyperkit w/ minikube, and after some heavy setup automation it works pretty great. What I worry about, though, is what I’m going to do when I switch to a Mac w/ Apple Silicon. AFAICT Hyperkit is x64-only.
Minikube sets up a Linux VM using MacOS Hypervisor.
It even has a convenience command to configure docker-cli/docker-client.
For corporate situations where MITM proxies are used, you can inject/trust custom CAs using https://minikube.sigs.k8s.io/docs/handbook/untrusted_certs/