beiboot VS vcluster

We recently had a Kubernetes Meetup in Munich. This talk demonstrates a new open-source project called Getdeck Beiboot that helps with creating virtual K8s environments for development and testing. It's based on K3s and will support snapshotting and restoring whole clusters to speed up the creation of temporary K8s-based dev environments. What do you think?

I went on generating K8s YAMLs with Python and a CLI framework for passing options or read in value-files: https://github.com/Getdeck/beiboot/blob/main/client/beiboot/misc/install.py Then it's a `beibootctl install --arg 1 --arg 2 --option=whatever | kubectl apply -f -` which prints the YAML to the console and can be applied or stored from there.

Loft's vCluster is the most popular solution. Creating virtual clusters within your existing physical cluster gives each tenant a complete Kubernetes environment. Operating costs stay low because you're still only running one real cluster, but you gain improved isolation and a simplified tenant onboarding experience.

I was a victim of the IT crisis last summer, and my company fired me, so I no longer work on Apache APISIX. They say that the Chinese ideogram for crisis contains the ideogram for opportunity. I used this opportunity to join LoftLabs. LoftLabs offers a cluster virtualization solution called vCluster.

vCluster is an Open Source product that allows creating of so-called virtual clusters. vCluster is part of the CNCF landscape, specifically a certified Kubernetes distribution. Being a certified distro means a virtual cluster offers every Kubernetes API you can expect, and you can deploy any application to it just like any other Kubernetes cluster.

To compare the approaches and test our work, we can use the minikube ingress addon and vCluster. The former offers a single access point for all three workloads, native, embed, and runtime, while vCluster isolates workloads from each other in their virtual cluster.

If you are hearing about virtual clusters for the first time, then read more here.

For the second item, you can only achieve complete isolation with different clusters, which defeats the purpose. The alternative is vCluster: in the next post, I'll detail how you can leverage it in your GitHub workflow.

curl -L -o vcluster "https://github.com/loft-sh/vcluster/releases/latest/download/vcluster-linux-amd64" && sudo install -c -m 0755 vcluster /usr/local/bin && rm -f vcluster

In the realm of Kubernetes, vClusters have become a popular solution for creating isolated environments within a larger host cluster. Managing these virtual clusters effectively, however, can be a challenge. This is where Sveltos, an open-source event-driven framework, shines. By leveraging Sveltos' event framework and Helm, we can automate the entire lifecycle of vClusters, from provisioning to deprovisioning and even Day 2 operations.

The ideal situation, as the initial quote of this post states, would be to have namespace-scoped CRDs. Unfortunately, it's not the path that Kubernetes chose. The next best thing would be to add a virtual cluster on top of the real one to partition it: that's the promise of vCluster.

Tools like Crossplane, vCluster (for managing multiple clusters), or Cluster API (for provisioning additional clusters) can extend this approach to handle various infrastructure resources beyond Kubernetes. Essentially, Git serves as the single source of truth for your entire infrastructure, with Argo CD functioning as the engine to enforce that truth.