1. A Namespace Is a Shelf, Not a Boundary
When designing multi-tenancy in Kubernetes, the first idea that comes to mind is usually "just split each tenant into its own namespace." In practice, many teams run multiple business units or client workloads on a single cluster this way.
But the Kubernetes official documentation is explicit about the limits here: the namespace-based isolation model "requires strict adherence to several other Kubernetes resources, network plugins, and security best practices." In other words, a namespace only provides a "scope" for separating resource names and applying RBAC or NetworkPolicy — actually keeping those policies correctly configured for every tenant remains a manual, ongoing operational task.
As the number of tenants grows to 5, 10, or more, this manual consistency starts to break down. A NetworkPolicy gets forgotten in one namespace; a ResourceQuota is left with an outdated limit in another — this kind of policy drift is a common failure mode. Sysdig's blog also points out that each of the three isolation boundaries — control plane/API, host, and network — requires its own explicit RBAC least-privilege design and NetworkPolicy enforcement.
Kubernetes Multi-Tenancy Is a Spectrum
The Kubernetes documentation explains that multi-tenancy shouldn't be framed as a binary choice between "soft" and "hard" isolation, but as a spectrum of isolation techniques to choose from based on requirements. Soft isolation is sufficient for internal teams that already trust each other, while SaaS-style use cases hosting untrusted external customers need stronger (hard) multi-tenancy. Failing to understand this premise — and assuming "splitting namespaces" alone is enough — is exactly what sets the stage for incidents.
This policy management overhead is also something worth reconsidering at the point of choosing a managed Kubernetes platform. With a platform like Kubo, which is built with tenant management as an operational default, you don't need to rebuild this kind of mechanism from scratch.
2. Capsule's Answer — Declaring a "Group of Namespaces" via the Tenant CRD
Capsule, accepted as a CNCF Sandbox project, offers a clear solution to this problem. Capsule was accepted at the CNCF Sandbox level on December 13, 2022 (CNCF Capsule project page), and is an OSS project that implements a "multi-tenant, policy-based environment" on a Kubernetes cluster.
At the core of Capsule is a custom resource (CRD) called Tenant. According to the official GitHub repository, the Tenant CRD groups multiple namespaces into a "lightweight abstraction." Administrators only need to define NetworkPolicy, Security Policy, ResourceQuota, LimitRange, and RBAC settings at the tenant level, and these are automatically inherited by every namespace belonging to that tenant. There's no need to reconfigure policies every time a new namespace is added.
Equally important is the idea of "self-service delegation." Within the boundaries assigned to a tenant, development teams can autonomously create namespaces and deploy applications without cluster administrator intervention. Capsule is designed as "a minimalist, microservice-based ecosystem that leverages only upstream Kubernetes" (CNCF Capsule project page), achieving this purely through admission webhooks and CRDs. Cluster administrators only need to design the tenant framework, while day-to-day namespace management is delegated to each team — making it possible to balance operational load with governance. The FinOps media outlet Zesty also describes Capsule as "an operator that groups multiple namespaces into lightweight virtual clusters called tenants, enabling efficient and secure workload isolation," highlighting its ability to enforce tenant-level policy without handing out cluster administrator privileges.
3. "Soft" vs "Hard" Isolation — How vCluster and HNC Differ
Beyond Capsule, several other OSS projects tackle the Kubernetes multi-tenancy problem, each with a different tradeoff between isolation strength and operational cost, worth laying out clearly.
Capsule — Soft Multi-Tenancy
Capsule takes a "soft" isolation approach centered on namespaces and admission webhooks. vCluster's official blog comparison points out that namespace-based multi-tenancy "lacks true tenant isolation, leaving globally shared resources like ClusterRole and PersistentVolume in place," while positioning Capsule as mitigating this weakness through automatic policy inheritance. Because it shares the same API server and control plane across multiple tenants, its resource overhead stays low.
vCluster — Hard Isolation via a Virtual Control Plane
vCluster, on the other hand, takes the approach of running a dedicated virtual control plane (its own API server, controller-manager, and scheduler) for each tenant inside the host cluster. Workloads themselves are synced back to the host cluster, but each tenant gets its own Kubernetes API, allowing different CRDs or API versions per tenant. The tradeoff is that running multiple control planes increases both resource consumption and operational complexity. For cases like financial institutions or healthcare providers that require per-tenant data sovereignty or fully air-gapped operation, pairing this approach with a platform built for air-gapped environments, such as Kubo On-Premise, becomes a viable option.
HNC — Hierarchical Namespace Inheritance
The Hierarchical Namespace Controller (HNC) gives namespaces parent-child relationships, automatically propagating RBAC RoleBindings and ResourceQuotas down to child namespaces. Like Capsule, it lets you delegate namespace creation — normally requiring cluster-level permissions — down to a team's own namespace. However, as also noted in vCluster's blog comparison, cluster-scoped resources like ClusterRole and PersistentVolume sit outside the hierarchy and remain global. HNC is fundamentally a tool for "structuring and managing namespaces," not a mechanism for enforcing comprehensive tenant boundaries the way Capsule does.
4. Which Approach Should You Choose? — Decision Criteria
The three approaches can be organized along two axes: isolation strength and operational cost.
- HNC: Lowest operational cost, but cannot isolate cluster-scoped resources. Best suited for delegating namespace management among internal teams that already share the same trust level.
- Capsule: Compensates for namespace isolation's weaknesses through automatic policy inheritance, offering a good balance of cost and isolation. Well suited for sharing a cluster across multiple trusted business units or teams.
- vCluster: Provides the strongest isolation (at the virtual control plane level), at the cost of increased operational complexity and resource overhead. Best suited for SaaS-style use cases hosting untrusted external customers, or when tenants need different Kubernetes versions or CRDs.
Google Cloud's GKE multi-tenancy best practices also recommend, as a baseline, the combination of dedicated per-tenant namespaces, NetworkPolicy-based traffic control, Admission Control enforcing security standards, and namespace-level ResourceQuota settings. In other words, what Capsule automates is exactly the set of components that would otherwise need to be manually assembled even on a managed service like GKE.
Designing and operating this setup from scratch is no small amount of engineering work. This is precisely where it becomes valuable to have tenant management built into a managed Kubernetes platform as a core feature. Kubo comes with a Rancher-based management foundation as standard, letting you operate while visualizing multi-cluster, multi-tenant state. Built on K3s, a lightweight Kubernetes distribution, it also offers strong cost efficiency compared to EKS/AKS. For teams that want to build tenant-level policy management into their setup from day one, it's worth considering as an option.
5. Summary
Namespace isolation is a starting point for Kubernetes multi-tenancy, not an endpoint. Unless you solve the design problem of consistently enforcing policy at the tenant level, the risk of incidents keeps compounding as the number of tenants grows.
Capsule offers a practical option: layering a lightweight abstraction — the Tenant CRD — on top of the existing namespace model to achieve automatic inheritance of NetworkPolicy, ResourceQuota, and RBAC, along with self-service delegation. If you need stronger isolation, vCluster is an option; if you just want to structure your existing namespaces hierarchically, HNC is another. Understanding each tradeoff and identifying the isolation strength your cluster actually needs is the first step toward good multi-tenant design.
If you're planning to share a single Kubernetes cluster across multiple business units or clients, it's worth considering handing this kind of tenant isolation over to a managed platform rather than building it from scratch. Reach out via Kubo Cloud, or for environments requiring stricter data sovereignty, Kubo On-Premise — get in touch through our contact page.