Kubernetes multi-tenancy in 2026: revisit vCluster, Capsule and Kamaji before you hand another team its own cluster

Sooner or later a platform team gets the same request again. A product squad wants “its own cluster” because it needs to install an operator with cluster-scoped CRDs, a data team wants admin rights to try a new scheduler, and a customer-facing team asks for hard isolation because an auditor said so. Saying yes every time leads to cluster sprawl: more control planes to upgrade and more bills to explain. Saying no every time pushes everyone into one shared cluster where one ClusterRole mistake or a noisy neighbour hurts all teams.

Kubernetes gives you namespaces, RBAC, ResourceQuota, LimitRange and NetworkPolicy, but no “tenant” object, no self-service namespace creation without cluster rights, and no cheap way to hand someone a full API server. This post revisits three open-source projects that fill those gaps in very different ways: vCluster, Capsule and Kamaji. The aim is not to crown a winner, but to decide which kind of tenancy a team actually needs.

The short version

• vCluster: Apache-2.0 project from the company behind vCluster (repo under loft-sh). Gives each tenant a virtual cluster with its own API server, CRDs and RBAC, while workloads usually run on a shared host cluster through a syncer. Strong when tenants need cluster-admin style freedom without a real cluster each.
• Capsule: Apache-2.0 multi-tenancy operator, CNCF Sandbox since 13 December 2022. Groups namespaces into a cluster-scoped Tenant with owners, quotas, rules and replicated resources. Strong when teams need self-service namespaces on one shared API server, not their own cluster.
• Kamaji: Apache-2.0 hosted control plane manager from CLASTIX. Runs real, upstream Kubernetes control planes as pods in a management cluster, and tenants bring their own worker nodes. Strong when tenants truly need separate clusters, but you want to run many control planes cheaply.

A note on a fourth name you may still see in older guides: the Hierarchical Namespace Controller (HNC) has been moved to the kubernetes-retired GitHub organisation and the repository is archived. Its last release was v1.1.0 on 23 June 2023. Do not start a new design on HNC in 2026.

What the multi-tenancy job actually is

Before comparing tools, separate the layers that often get mixed in one meeting.

• Control plane isolation answers “does each tenant get its own API server, CRDs and cluster-scoped objects”. Namespaces alone never give this.
• Data plane isolation answers “do tenant pods share nodes, kernel, CNI and storage with other tenants”. This is about node pools, runtime sandboxes and network policy, not only about the API.
• Self-service answers “can a team create namespaces, grant access and install what it needs without a ticket to the platform team”.
• Guardrails answer “what stops a tenant from consuming the whole cluster or breaking someone else”. Quotas, admission policy and network policy live here.

The official Kubernetes multi-tenancy page makes a similar point: trusted internal teams and untrusted tenants or customers need different controls. Pick the model from the trust level, not from the tool you saw at a conference.

A small Indian example helps. A Bengaluru fintech runs one shared production cluster for about a dozen squads. The payments squad is happy with namespaces. The risk analytics team in Chennai wants an operator that needs cluster-scoped CRDs. A new B2B product must separate each enterprise customer because security reviews ask for a dedicated cluster. Namespaces with guardrails may suit the squads, a virtual cluster the analytics team, and a dedicated control plane the B2B customers.

vCluster: a full virtual cluster inside a namespace

History and licence. vCluster started in 2021 (the loft-sh/vcluster repository was created in April 2021) and is developed by the company behind vCluster, originally known as Loft Labs. The code is under the Apache License 2.0. It is not a CNCF-hosted project; the CNCF landscape lists it as a certified Kubernetes distribution and platform product. There is also a commercial vCluster Platform on top of the open-source engine, and the project README describes a free tier for the platform. Docs are at vcluster.com/docs.

How it works. By default, each virtual cluster (now called a “tenant cluster” in the docs) runs inside one namespace of a host cluster. Its control plane runs as a StatefulSet pod containing an API server, controller manager, data store and a syncer. The default data store is embedded SQLite, with etcd, MySQL and PostgreSQL as options. The tenant talks to its own API server, so it can create CRDs, namespaces and cluster roles freely. The syncer copies low-level objects such as pods to the host namespace, where the host scheduler places them on real nodes. Deleting the virtual cluster or its namespace cleans up synced resources through owner references.

The current docs describe several placements, with isolation growing step by step:

• Shared nodes: tenant pods run on the host cluster’s normal nodes. Best density, weakest isolation.
• Dedicated nodes: tenant pods are pinned to labelled node pools on the host.
• Private nodes (v0.27 and later): external nodes join the tenant cluster directly with their own CNI and CSI.
• Standalone (v0.29 and later): the control plane runs as a binary on VMs or bare metal, with no host cluster.

At the time of writing, the latest stable release on GitHub is v0.37.6 (31 October 2026, IST). Release candidates for v0.38.0 are also on the releases page; prefer the stable line for production. Older minor lines are marked end of support or end of life in the docs, so plan regular upgrades.

Where it is strong.

• Tenants that need cluster-admin style freedom: their own CRDs, operators and namespaces.
• Short-lived environments for CI and preview builds, where a real cluster is too slow or costly.

What to watch.

• With shared nodes, tenants still share kernels, the CNI and often storage classes on the host. Add network policy, pod security and node isolation where trust is low.
• The syncer is a translation layer; some resources need explicit sync settings, so test the operators tenants plan to install.
• Some capabilities shown on the vCluster site are part of vCluster Platform rather than the open-source engine. Check which ones your design depends on before you commit.
• Adoption numbers on the README are the vendor’s own figures.

Capsule: tenants made of namespaces

History and licence. Capsule began at CLASTIX in 2020 (the repository was created in June 2020) and was accepted into the CNCF as a Sandbox project on 13 December 2022. It now lives in the projectcapsule GitHub organisation under the Apache License 2.0, with a project governance page on projectcapsule.dev. The FAQ says the community edition targets the latest vanilla Kubernetes release; OpenShift and older versions are covered by an enterprise offering.

How it works. Capsule is an operator plus admission webhooks. A cluster administrator creates a cluster-scoped Tenant resource that names its owners (users, groups or service accounts) and sets rules. Tenant owners can then create ordinary namespaces themselves, without cluster-admin rights, and every namespace in the tenant inherits:

• RBAC bindings for owners and members.
• Resource budgets, through resource pools or custom quotas at tenant level instead of only fixed per-namespace quotas.
• Admission rules such as allowed image registries, pull policies and namespace metadata.
• Replicated resources such as NetworkPolicies, image pull secrets and LimitRanges, using Go templates for values like namespace or tenant name.

There is only one real API server. Kubernetes RBAC cannot filter cluster-scoped list calls, so a tenant user normally cannot run kubectl get namespaces. The optional Capsule Proxy sits in front of the API server and returns only the namespaces and cluster-scoped objects that belong to the user’s tenant, so normal tools keep working.

At the time of writing, the latest release on GitHub is v0.15.2 (26 October 2026). The project is active, with releases every few weeks.

Where it is strong.

• Internal teams with soft multi-tenancy needs: they trust each other, but need budgets, self-service and clean boundaries.
• Platform teams that want one cluster, one set of add-ons and one upgrade, with no extra control planes.

What to watch.

• Tenants cannot install their own cluster-scoped CRDs or pick a Kubernetes version. If that is the need, Capsule is the wrong layer.
• All tenants share one API server and etcd, so a tenant flooding the API can still affect others.
• Capsule complements, not replaces, an admission policy engine. See our earlier post on Kyverno, Gatekeeper and ValidatingAdmissionPolicy for that layer.
• Read upgrade notes before you jump minor versions; the API group has moved through versions such as v1beta2.

Kamaji: real control planes as pods

History and licence. Kamaji is developed by CLASTIX, the same company that started Capsule. The clastix/kamaji repository was created in December 2021 and the code is under the Apache License 2.0. Kamaji is not a CNCF-hosted project. One licensing detail matters: the Kamaji versioning page says that since July 2024 CLASTIX no longer publishes semantically versioned stable artifacts in the open-source project. The open-source project ships monthly edge releases (format {year}.{month}.{n}-edge), and stable OCI images and Helm charts are available on a CLASTIX subscription. The same page says edge releases are generally considered production ready, with specific releases marked “not recommended” if bugs appear. Docs are at kamaji.clastix.io.

How it works. Kamaji adds two main APIs to a management cluster:

• TenantControlPlane: a namespace-scoped resource that describes a tenant’s control plane. Kamaji runs the API server, controller manager and scheduler as pods, and exposes them through ClusterIP, NodePort or LoadBalancer.
• DataStore: a cluster-scoped resource for the backing store. It can be etcd, or MySQL, PostgreSQL or NATS through kine, and one data store can serve several control planes.

Worker nodes are real machines or VMs that join the tenant control plane, with Konnectivity so nodes can sit in a different network. Kamaji also manages kube-proxy and CoreDNS, rotates certificates, and has a Cluster API control plane provider. The project states that its tenant clusters are CNCF conformant because they use upstream Kubernetes binaries. The README quotes provisioning and upgrade timings; treat those as the vendor’s own runs, not as a benchmark for your setup.

At the time of writing, the latest release on GitHub is 26.11.2-edge (2 November 2026).

Where it is strong.

• Tenants that need a real, separate cluster with their own nodes, for compliance or customer contracts.
• Teams building a private “managed Kubernetes” service on OpenStack, vSphere, Proxmox or bare metal.

What to watch.

• You still operate worker nodes, CNI and CSI per tenant. Kamaji makes control planes cheap, not whole clusters free.
• The management cluster and data stores become critical shared infrastructure; back them up like a production database.
• Decide early whether edge releases are acceptable for you or whether you need the paid stable channel.

Side by side, without a table

What a tenant receives

• vCluster: its own API server inside a namespace of a host cluster; pods usually run on host nodes.
• Capsule: a group of namespaces on the shared API server, with self-service and inherited rules.
• Kamaji: a dedicated, upstream control plane, with worker nodes that belong to that tenant.

Isolation level (rough guide)

• Capsule: soft tenancy at the namespace layer; strength depends on your policy, quota and network setup.
• vCluster: control plane isolation by default; data plane isolation grows with dedicated or private nodes.
• Kamaji: control plane and node isolation by design, with a shared management cluster and possibly shared data stores.

Licence, governance and release channel (as stated upstream)

• vCluster: Apache-2.0; vendor-led; commercial vCluster Platform on top; stable v0.37.6 checked for this post.
• Capsule: Apache-2.0; CNCF Sandbox (accepted 13 December 2022); v0.15.2 checked for this post; enterprise support offered separately.
• Kamaji: Apache-2.0; vendor-led by CLASTIX; open-source edge releases (26.11.2-edge checked), stable artifacts by subscription.

Operational cost

• Capsule: one operator and webhooks on an existing cluster. Lowest.
• vCluster: one control plane pod plus CoreDNS per tenant. Moderate.
• Kamaji: one control plane plus nodes and add-ons per tenant. Highest of the three.

How to choose

• If teams trust each other and mainly need self-service namespaces, quotas and shared rules, start with Capsule.
• If a team needs its own CRDs, operators or cluster-admin rights, but not its own nodes, start with vCluster.
• If a tenant needs a separate cluster with its own nodes, for a customer contract or compliance, and you will run many such clusters, evaluate Kamaji.
• If you are still on HNC, plan a migration; Capsule is the closest fit for namespace grouping.
• If someone asks for “a new cluster” by default, ask what they cannot do today in a namespace. Often the answer is “install one CRD”.

Common mistakes

• Treating namespaces as a security boundary without NetworkPolicy, pod security and quotas.
• Giving a tenant a virtual cluster on shared nodes and calling it hard isolation for an external customer.
• Letting tenant owners create namespaces without a naming rule, then fighting collisions in DNS, monitoring and cost reports.
• Forgetting that observability, backups and cost tracking must also be tenant-aware. Labels for tenant name should be decided on day one.

A practical way to start this week

1. List current tenancy requests and group them: namespace needs, CRD or admin needs, and separate cluster needs.
2. Write down the trust level for each group: internal team, partner, or external customer.
3. Namespace group: trial Capsule on staging with one Tenant, a quota, a replicated default-deny NetworkPolicy and Capsule Proxy.
4. CRD or admin group: trial vCluster in one namespace, install the operator they asked for, and note any sync settings needed.
5. Separate cluster group: follow the Kamaji kind guide, create one TenantControlPlane, join one worker, and decide on edge versus subscription releases.
6. Agree on tenant labels for cost, logs and alerts, review after two weeks, then write the tenancy policy.

Revisit checklist

• What is the trust level of each tenant, and does our model match it?
• Which teams really need cluster-scoped rights, and which only need self-service namespaces?
• Do tenant namespaces get default network policy, quotas and pod security automatically?
• Are we depending on a paid feature or release channel without knowing it?
• Can every tenant be identified in cost, logging and backup reports?
• Is anything still running on HNC, and when will it move?

No hands-on drill was run for this post. Versions, dates and features come from the repositories and official docs listed below, checked in November 2026. Try each tool on a non-production cluster first.

Closing

“Give them their own cluster” is a habit worth unlearning. Revisit multi-tenancy with the mindset of this site: learn which layer each tool isolates, unlearn the idea that a namespace or a new cluster is the only choice, re-learn the trust level of each tenant, practise with Capsule, vCluster or Kamaji on staging, and apply the right model team by team instead of creating one more cluster by default.

Sources

• Kubernetes multi-tenancy concepts: https://kubernetes.io/docs/concepts/security/multi-tenancy/
• vCluster repository (Apache-2.0): https://github.com/loft-sh/vcluster
• vCluster releases (v0.37.6 stable, v0.38.0 release candidates): https://github.com/loft-sh/vcluster/releases
• vCluster architecture docs: https://www.vcluster.com/docs/vcluster/introduction/architecture/
• vCluster docs home: https://www.vcluster.com/docs/
• Capsule repository (Apache-2.0): https://github.com/projectcapsule/capsule
• Capsule releases (v0.15.2): https://github.com/projectcapsule/capsule/releases
• Capsule overview: https://projectcapsule.dev/docs/overview/
• Capsule Proxy: https://projectcapsule.dev/docs/proxy/
• Capsule governance: https://projectcapsule.dev/project/governance/
• Capsule on CNCF (Sandbox): https://www.cncf.io/projects/capsule/
• CNCF landscape data (Capsule accepted 13 December 2022): https://github.com/cncf/landscape/blob/master/landscape.yml
• Kamaji repository (Apache-2.0): https://github.com/clastix/kamaji
• Kamaji releases (26.11.2-edge): https://github.com/clastix/kamaji/releases
• Kamaji releases and versions (edge and stable channels): https://kamaji.clastix.io/reference/versioning/
• Kamaji docs: https://kamaji.clastix.io/
• HNC repository (archived): https://github.com/kubernetes-retired/hierarchical-namespaces
• HNC releases (v1.1.0, 23 June 2023): https://github.com/kubernetes-retired/hierarchical-namespaces/releases