How Virtual Kubernetes Clusters Can Speed Up Your Local Development

KinD, k3d and minikube to the rescue?

Before you tell me that I’m doing it awfully wrong and should use a separate KinD, k3d or minikube cluster per project instead of resetting the docker-desktop instance over and over, I need to let you know that this approach also has its problems. Don’t get me wrong, I love KinD, k3d and minikube (and all the other super tiny Kubernetes distros). They brought me to Kubernetes and still make it a breeze to get started. To be honest, without them, probably most CNCF project pipelines would be as useful as most of my hobby projects. However, if you regularly reset those or even run multiple clusters at the same time, you will have a hard time fighting disk space and resource overhead in your local docker installation (shout out to docker system prune).

So now you are telling me virtual clusters are the solution?

Obviously this blog post is about development with virtual clusters, so unsurprisingly yes, I do think that virtual Kubernetes clusters can be an improvement here. Let’s take a look at what virtual Kubernetes clusters do differently than KinD, k3d and minikube to understand why they could be a good replacement.

Show me or I don’t believe it

If I have spiked your interest, you are probably now thinking: this sounds nice, but I don’t want a solution that is difficult to use, I just want to run a single simple command to create and delete a cluster like KinD or minikube are doing. Good news, in the newest v0.10.0 release of vcluster, which is fully open-source and the most popular virtual cluster implementation, we have simplified the handling of virtual clusters to super simple one line commands.

$ vcluster create my-vcluster
$ kubectl get namespacesNAME              STATUS   AGE

kube-system Active 40s

default Active 40s

kube-public Active 40s

kube-node-lease Active 40s
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook/all-in-one/guestbook-all-in-one.yaml
$ kubectl wait --for=condition=ready pod -l app=guestbook
$ kubectl port-forward service/frontend 9080:80
$ kubectl get pods -n vcluster-my-vclusterNAME                                                     READY   STATUS    RESTARTS   AGE

coredns-76dd5485df-75jgf-x-kube-system-x-my-vcluster 1/1 Running 0 7m25s

frontend-f7d9c57d4-8wp44-x-default-x-my-vcluster 1/1 Running 0 7m13s

frontend-f7d9c57d4-d2trf-x-default-x-my-vcluster 1/1 Running 0 7m13s

frontend-f7d9c57d4-k6sb6-x-default-x-my-vcluster 1/1 Running 0 7m13s

my-vcluster-0 2/2 Running 0 7m35s

redis-master-857d99cc8-tr949-x-default-x-my-vcluster 1/1 Running 0 7m13s

redis-replica-6fd587fb56-gjht5-x-default-x-my-vcluster 1/1 Running 0 7m13s

redis-replica-6fd587fb56-mksx4-x-default-x-my-vcluster 1/1 Running 0 7m13s
vcluster delete my-vcluster

Let’s wrap it up

A fresh Kubernetes cluster is always nicer to work with than an already existing one. Virtual clusters now make it quite easy to use them not only in complex multi-tenancy environments, but also locally in your testing or development cluster.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Loft Labs

Loft Labs

637 Followers

>> www.loft.sh << Build Your Internal Kubernetes Platform With Virtual Clusters, Namespace Self-Service & Secure Multi-Tenancy