Oh hey, a blog post about virtual clusters again. Maybe you have already heard of those in the context of multi-tenancy, or even jokingly mentioned to someone that some crazy folks are promoting Kubernetes inside Kubernetes.
So now you are probably thinking: why on earth should a developer that already struggles enough with using Kubernetes itself also want to deal with virtual clusters? The answer might surprise you, but I believe virtual clusters are actually a lot easier to handle than separate physical ones, and can have quite some advantages over local k3d, KinD or minikube instances.
If you work regularly with Kubernetes, you probably know the problem: you want to try out a new application, switch to another project to work on, or you didn’t use your local Kubernetes cluster for a while and forgot what was deployed inside it.
Since working with a fresh empty cluster is much easier than reusing an existing one, you just reset the whole thing. For me, this happens quite a lot. I reset my local docker-desktop instance multiple times a day, and sometimes I want to work on multiple projects at the same time that might conflict because of their CRD’s and operator dependencies (usually they aren’t, but who has time to actually figure that out?).