Agreed, esp because the author is on macOS and using docker relies on having a VM running. iirc on macOS, Docker uses hyperkit by default, and minikube can be configured to use hyperkit instead of vbox as well. A deep dive into the differences between running minikube on hyperkit vs vbox would’ve been far more interesting, since that likely was part of the problem affecting the article author.
I too have said my goodbyes to minikube. Although in my case it was not so much minikube’s fault. I was on Windows 10 Home and minikube was working fine for me. Then I upgraded to Windows 10 Pro. In Pro when you have Hyper-V enabled, then VirtualBox works extremely slowly if at all. You have to disable Hyper-V for VirtualBox to work. But I upgraded because I wanted WSL2 and this requires Hyper-V (or so I understand; if it does not maybe my decision to upgrade was in error).
Yes, you can have minikube work with the docker driver, but it just does not feel the same. So since I upgraded to Pro dropped minikube and started using the Kubernetes distribution that comes with Docker Desktop. It is OK for me most of the time.
And when I want to experiment with different versions of Kubernetes, I launch a machine with multipass and use RKE (within the VM) for example. The issue I am facing with Multipass is that I have to delete c:\windows\system32\drivers\etc\hosts.ics from time to time.
Kind and microk8s could be alternatives too, but I have not used them.
But I upgraded because I wanted WSL2 and this requires Hyper-V (or so I understand; if it does not maybe my decision to upgrade was in error).
FWIW, I can confirm that you don’t need Pro to use WSL2. In my understanding, when you activate WSL2 in Home, some parts of Hyper-V get installed but you can’t use it yourself to boot a VM.
However that’s indeed enough to cause problems with VirtualBox. A recent VBox update was supposed to fix this, but I haven’t tried yet.
TL;DR: “minikube was slow so I swapped it out for an alternative called kind that runs in docker”
I expected some kind of investigation or profiling on why minikube was slow, a bit disappointing.
Right? What happens if kind starts being slow one day before a demo? Does the author just abandon orchestration and find a new niche?
This is Devops.
Agreed, esp because the author is on macOS and using docker relies on having a VM running. iirc on macOS, Docker uses hyperkit by default, and minikube can be configured to use hyperkit instead of vbox as well. A deep dive into the differences between running minikube on hyperkit vs vbox would’ve been far more interesting, since that likely was part of the problem affecting the article author.
Edit: Moreover, minikube can also run in docker if configured as such.
This article was deeply disappointing, there was no investigation on reasoning on why Minikube was slow.
I too have said my goodbyes to minikube. Although in my case it was not so much minikube’s fault. I was on Windows 10 Home and minikube was working fine for me. Then I upgraded to Windows 10 Pro. In Pro when you have Hyper-V enabled, then VirtualBox works extremely slowly if at all. You have to disable Hyper-V for VirtualBox to work. But I upgraded because I wanted WSL2 and this requires Hyper-V (or so I understand; if it does not maybe my decision to upgrade was in error).
Yes, you can have minikube work with the docker driver, but it just does not feel the same. So since I upgraded to Pro dropped minikube and started using the Kubernetes distribution that comes with Docker Desktop. It is OK for me most of the time.
And when I want to experiment with different versions of Kubernetes, I launch a machine with multipass and use RKE (within the VM) for example. The issue I am facing with Multipass is that I have to delete
c:\windows\system32\drivers\etc\hosts.icsfrom time to time.Kind and microk8s could be alternatives too, but I have not used them.
FWIW, I can confirm that you don’t need Pro to use WSL2. In my understanding, when you activate WSL2 in Home, some parts of Hyper-V get installed but you can’t use it yourself to boot a VM.
However that’s indeed enough to cause problems with VirtualBox. A recent VBox update was supposed to fix this, but I haven’t tried yet.