 All right. Hi. My name is Rich Burroughs. I'm here to talk to you about how to level up from namespace isolation using Vcluster. My name is Rich. I'm creator and host of the podcast called CubeCuttle, where I interview people from the Kubernetes community. I've talked with people like Joe Beda and Kelsey Hightower and Liz Rice. So if that sounds interesting to you, look that up in your podcast player. Before getting into developer relations, I worked in operations roles for over 20 years. And as a result, I have seen some things. So primarily in the past, we've had two Kubernetes multi-tenancy models. We've had namespace based isolation and cluster based isolation. Namespace based isolation, tenants are restricted to one or more namespaces. Most of you are probably familiar with this stuff, but it cuts down on cluster sprawl. There's less wasted resources. Some of the cons are that users can't manage global objects, which might be a problem for dev environments. And users may need multiple namespaces, and then things can get kind of ugly with exceptions for network policies, stuff like that. Meanwhile, the other option is to give everybody their own cluster. You've got a lot better isolation there. There's less complexity in each individual cluster, but it's difficult to manage all these clusters. And you probably have more wasted resources, and you're probably going to pay a lot more money. So which of those two buttons do you want to push? Thankfully now, there's another option. There's a thing called virtual Kubernetes clusters. A virtual cluster runs inside of a shared host cluster but appears to the user as if it's a standalone dedicated cluster. We're going to talk about the cluster, which is an open source software. It's the most popular implementation of virtual clusters by far, and it's really fast and easy to use. So how does it work? It runs in a namespace on a host cluster. It contains a Kubernetes API server and some other tools, and it saves its date in a database. And that's SQLite by default, but you can point it at SCD or even Postgres or MySQL. So here's a quick look at the architecture. We've got our underlying host cluster here. It's an EKS cluster in this example, but it could be any Kubernetes cluster. The admin of the cluster is going to control its context, but we can create a namespace in there and have the cluster inside of that. And V Cluster has the API server and the data store that I told you about already. It also has a controller manager, and it has this thing called the V Cluster Syncer, and we'll talk about that in a second. Now, as a tenant in this cluster, I'm going to connect to the API server of the V Cluster, not the underlying host cluster. So I connect to the V Cluster. I control its context. I can create namespaces inside of the virtual cluster and have deployments and pods and custom resources, all of the stuff that I normally would. A lot of this stuff is managed just inside the namespace by V Cluster itself, but pods get synced down to the underlying host cluster, and they get scheduled there. So that's how it works. You'll notice on the V Cluster line, there's not a scheduler. All the scheduling is done by the underlying host cluster. So that's basically how V Cluster works. So what about V Cluster isolation? It's somewhere between those two things we talked about earlier, right? It's somewhere between the namespace-based isolation and the cluster-based. There is an API server per virtual cluster, so you're getting some API server federation there. You can also do some things like there are users out there who use node groups per virtual cluster to try to increase the isolation. But you still want to do the things that you normally would, like you want to do admission control on the underlying host cluster. I do have a hot take for you, and that is that isolation doesn't equal security. When we talk about multi-tenancy, people talk about isolation a lot, and it's very, very important, but it's just one aspect of security. It's one thing to consider. We have to look at the whole picture. If you have a lot of poorly managed clusters laying around, that's also a security problem, so you have to keep all these things in mind when you're coming up with a plan. V Cluster also has a thing called isolated mode, and it's off by default, but it's really easy to enable. It automatically improves isolation for the virtual clusters, and it has sensible defaults, but you can customize those using Helm values. So isolated mode creates these objects per virtual cluster, a pod security standard, and that prevents things like launching privilege pods or mounting a host path. It creates a resource quota in a limit range, which allows you to restrict the resources the virtual cluster uses, and it creates a network policy, which restricts access to both the workloads and the control plane of the virtual cluster. That only works if your host cluster CNI supports network policies. So that's basically how the isolated mode works. If you would like to learn more about this stuff, the place to go is vcluster.com. If you just remember one thing, there's links to all the other stuff there. There's a GitHub repo, of course, for vcluster, and we welcome contributions. And if you want to talk to folks, there's a loft community Slack that has a vcluster channel in it. The maintainers are in there, and lots of other users. And yeah, that's it. So thank you very much.