![]() #So now you are telling me virtual clusters are the solution? While this works well, it also has a couple of disadvantages: you need to re-pull all your container images inside the new cluster, communication across your local clusters is often difficult, and there is quite a lot of overhead involved running those clusters side-by-side. The node itself includes everything that is needed for a small Kubernetes setup, including a separate systemd, containerd and usually some other cluster tooling. In case of minikube and KinD this is a container containing the vanilla Kubernetes binaries, and in the case of k3d it’s unsurprisingly k3s. You may have noticed that when creating a new KinD, k3d or minikube (docker driver) cluster, they will create a single node container that runs the whole Kubernetes cluster. The problem stems from the way those tools create Kubernetes clusters. 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). To be honest, without them, probably most CNCF project pipelines would be as useful as most of my hobby projects. They brought me to Kubernetes and still make it a breeze to get started. Don’t get me wrong, I love KinD, k3d and minikube (and all the other super tiny Kubernetes distros). #KinD, k3d and minikube to the rescue?īefore 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. 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?). Since working with a fresh empty cluster is much easier than reusing an existing one, you just reset the whole thing. 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. 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. 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. Oh hey, a blog post about virtual clusters again.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |