Virtual clusters: the future of Kubernetes multi-tenancy

Bart: What's your name, what's your role, and where do you work?

Lukas: Hi, I'm Lukas. I'm the CEO and one of the founders of Loft Labs. We're the maintainers of vCluster, DevPod, and a couple of other open-source projects.

Bart: What are three Kubernetes emerging tools that you're keeping an eye on?

Lukas: I think there are a couple of really interesting tools in the space right now. KCP is one of the lesser-known tools, probably. They just entered Sandbox with the CNCF, and it's definitely a tool worth checking out. It takes a very different approach to using Kubernetes, focusing less on pods and more on what the Kubernetes API could be. If I had to think of two more tools, OpenCost is an interesting one. It has a condensed focus on making Kubernetes more efficient, and tracking cost is a good starting point for that. KubeVirt is another project that's gained a lot of attention recently, bringing virtual machines closer to Kubernetes and allowing you to manage virtual machines with Kubernetes. I think that's a pretty fascinating project too.

Bart: One of our guests, Artem, shared that between a single cluster with multiple environments and dedicated clusters per environment, the latter is easier to manage for a small team. When you share a cluster with multiple teams, should you share a single cluster or offer a dedicated cluster per tenant? What does your choice depend on?

Lukas: The single cluster versus multi-tenant clusters problem is a difficult one. In the earlier years of Kubernetes, the focus was on how big a cluster could get. Then, we shifted our focus and created a whole bunch of little clusters. I think cloud providers made it too easy to spin up clusters, which contributed to this shift. However, it's a valid question to reflect on when to share a cluster and when to have a separate cluster. My standpoint is to look at vCluster, which offers a middle ground. It gives you the feeling of having a real cluster while running on an underlying multi-tenant cluster, providing the best of both worlds.

Bart: One of our guests, Steven, shared some simple but effective advice on building Kubernetes Operators: keep it simple and use multiple Custom Resource Definitions (CRDs). Do you have any advice on building operators?

Lukas: Operators are amazing. In the Kubernetes space, they're a game changer, allowing you to extend the Kubernetes API. This is part of the power of Kubernetes - it's not just what's baked into the code and core, but what's made possible through extension layers. Building Custom Resource Definitions (CRDs) is about optimizing the way to ship new versions of these Kubernetes Operators and CRDs quickly. We all know it's tough to build this because you need a separate cluster to work on it. Having a lightweight setup allows you to work on a local cluster like Kind or on Rancher Desktop, which has a Kubernetes cluster built-in, or tools like that. If you need more cloud power or a direct connection to a cloud provider and don't want to create multiple EKS clusters in AWS, then it's a good idea to have one EKS cluster but not work in that shared cluster, as you'll probably get in each other's way because CRDs are global objects. This is another good use case for using a vCluster. Spin up multiple vClusters, and your CRDs will be isolated, but you'll still run in the same EKS cluster, improving efficiency when working together.

Bart: Our guest Lukas prefers Karpenter over Cluster Autoscaler for cluster autoscaling, highlighting its benefits and reliability. In particular, Lukas and his team use Karpenter to consolidate workloads and save around 40% of their cloud bill, which can be tracked with tools like OpenCost. Karpenter was also donated from AWS to the Kubernetes project. How do you think this will shape the future of autoscaling in Kubernetes?

Lukas: I think Karpenter is amazing. We use it internally and recommend it to our vCluster user base because it's ideal for large multi-tenant clusters. When you have idle resources that are turned off, Karpenter allows users to dynamically launch more resources and add nodes as needed. The beauty of Karpenter lies in its flexibility, especially when compared to static node pools. Previously, I saw many discussions about determining the right node size, but with Karpenter, you can provide a range of node sizes and let the algorithm decide. This is not a decision that should be made statically at one point in time; instead, Karpenter can figure it out for you. I would definitely recommend checking out this project.

Bart: Kubernetes turned 10 years old this year. What should we expect in the next 10 years to come?

Lukas: Hopefully, there will be a lot more development in Kubernetes. The landscape is already pretty large, but I think there's still a lot of attention on Kubernetes, and it's such a fundamental technology. So, I don't think the work ever stops. I hope we won't see a version two of Kubernetes. Hopefully, we'll have version 137 in 10 years, because version two would mean breaking changes, which would probably not be a great idea for any operator who runs a lot of Kubernetes clusters today. So, hopefully, there will be a lot of new features and new development, but please, no breaking changes on a version two.

Bart: What's next for you?

Lukas: What's next for us? We're making vCluster the de facto solution for multi-tenant Kubernetes clusters. We hope to see it in a lot more use cases. Most recently, I saw someone use it in CI pipelines, spinning up five different clusters or five different Kubernetes versions to test an operator. Because a vCluster starts in five or six seconds, something you couldn't even do with a traditional cluster, which would take 30 minutes plus to start. Nobody wants to do that in CI, especially if you have to spin up five or six of these clusters. I'm curious to see what other use cases are out there. Recently, I saw another user use it for sharding the Kubernetes API. If you have a really large cluster and the control plane is under a lot of load, having the idea of splitting it up into smaller clusters, but still tying it back to one underlying cluster, is fascinating to me. So, I think exploring more of these use cases is what I'm really excited about.

Bart: How can people get in touch with you?

Lukas: You can find me on LinkedIn. I'm also in our community Slack channel; head to slack.vcluster.com. Don't be shy - if you see me at KubeCon, just say hi and we'll have a chat.