Kubernetes Multi-Tenancy for Internal Platforms: 2026 Guide

Q: What does a Kubernetes namespace actually isolate, and what does it leave shared?

A namespace is a name scope and a policy scope. Object names inside it cannot collide with names in other namespaces, and the policies that matter most are namespaced: RBAC roles and role bindings, network policies, resource quotas, limit ranges and persistent volume claims, so a tenant can be fenced with them. Everything else stays shared: the API server and its rate limits, etcd, the scheduler, the kubelet on every node, the kernel under every pod, and the cluster-scoped objects. The Kubernetes multi-tenancy documentation names the cluster-scoped ones that namespace isolation does not apply to: custom resource definitions, storage classes and webhooks, and cluster roles and node pools belong on the same list. Nearly every conflict in a shared internal cluster, a tenant's webhook that fails closed and blocks everyone, two tenants fighting over an operator's CRD version, a tenant editing the default storage class, is a conflict over one of those shared objects, which is why ownership of them is the whole tenancy decision.

Q: When is namespace-per-team the right tenancy model, and what does it need to work?

It is right when the tenants are trusted internal teams whose workloads need only namespaced resources and who accept the platform's Kubernetes version, add-ons and upgrade window. The Kubernetes documentation says namespace isolation is well supported, has a negligible resource cost and lets tenants interact appropriately, and in the same breath that it can be difficult to configure. What it needs to work at scale is a tenant operator such as Capsule, which aggregates namespaces into a Tenant and inherits network and security policies, resource quotas, limit ranges and RBAC to every namespace in it, so forty teams do not drift into forty hand-maintained policy sets. The concrete checklist is a default-deny network policy with a DNS allowance, a storage class per tenant or a Delete reclaim policy on the shared one, Pod Security Standards enforced at admission, cross-namespace DNS restricted in CoreDNS, and no tenant-held cluster-scoped bindings at all. The moment a tenant needs an operator with a CRD, that tenant has outgrown the rung.

Q: What is a virtual control plane per tenant, and what does vCluster actually run?

A virtual control plane gives each tenant its own Kubernetes API server, controller manager and data store while the worker nodes stay shared and are managed by a host cluster the tenant cannot see. The Kubernetes documentation describes the model as extending namespace tenancy with dedicated control plane components so that each tenant gets complete control over cluster-wide resources, which solves noisy neighbours in the control plane, the blast radius of policy misconfiguration and conflicts between cluster-scoped objects such as webhooks and CRDs. vCluster's architecture documentation describes the API server, controller manager, a SQLite data store by default or etcd, and a syncer running as one unified process in a single container in a StatefulSet pod on the host cluster, with CoreDNS as a separate pod, and the host's scheduler reused unless the tenant needs node labels, taints or custom scheduling. The syncer projects the tenant's pods into a host namespace, so from the tenant's side it behaves like a standard cluster, and from the platform's side it is one pod per tenant plus the shared nodes.

Q: Does a virtual control plane solve noisy-neighbour and security problems between tenants?

No, and the Kubernetes documentation is explicit about it: per-tenant control planes do not solve isolation problems in the data plane, such as node-level noisy neighbours or security threats, and these must still be addressed separately. A virtual-cluster tenant whose pods have no quota on the host namespace they sync into can still exhaust memory on a shared node and evict another tenant's pods, no matter how many API servers exist. Containers on any shared kernel are, in the documentation's words, a weaker isolation boundary than virtual machines, so a tenant running untrusted code needs sandboxing with a virtual machine or userspace kernel, or a dedicated cluster. vCluster's own documentation draws the line the same way, positioning its Shared Nodes mode for internal, trusted teams and explicitly not for external or resold tenants, and its Private Nodes mode for hard tenancy such as GPU clouds and regulated platforms. The control-plane question and the data-plane question are independent, and each has its own escalation.

Q: When does a team genuinely need its own cluster rather than a virtual one?

When the conflict is on the node and the threat model excludes sharing either a kernel or a host control plane. That covers tenants running untrusted code where sandboxing is not acceptable, workloads whose regulator or contract forbids shared hardware, and teams that are in effect separate businesses with no trust between them. The Kubernetes documentation says it may be easier or necessary to forgo cluster-level sharing and assign each tenant a dedicated cluster, possibly on dedicated hardware if virtual machines are not considered an adequate boundary, and immediately adds that the benefit must be evaluated against the cost and complexity of managing multiple clusters. For the common intermediate case, GPU and ML teams, data-residency workloads, or tenants that need their own upgrade cadence, a virtual cluster on private nodes or a taint-isolated node pool gives dedicated machines without a dedicated lifecycle. Capsule's maintainers describe cluster-per-team as the path to cluster sprawl and an operational nightmare, and it is the default that most platforms arrive at without having decided anything.

Q: Why does the Kubernetes version and upgrade cadence matter to the tenancy decision?

Because a tenant who will not upgrade on the platform's schedule needs their own control plane whether or not anyone has said so, and in 2026 that tenant has a price. Kubernetes 1.37.1 is the current release and 1.34 reaches end of life on 27 October 2026. Amazon EKS charges $0.10 per cluster-hour for a standard cluster and $0.60 per cluster-hour once a cluster is running a version under extended support, six times the rate. On a shared namespace-per-team cluster, one team that needs the older version for a dependency or the newer one for a feature becomes a blocker for forty teams' upgrade. A virtual control plane lets that tenant run their own version on shared nodes, which is the cheaper answer, and a dedicated cluster lets them run it on their own nodes at the published surcharge. Either way the cadence should be a term the tenant signs, with the cost in front of them, rather than a surprise on the platform's bill.

Q: What are the most common multi-tenancy anti-patterns in internal platforms?

Granting a tenant a cluster-scoped role just for one operator, which the Kubernetes documentation warns lets them disable every other tenant's policies. Letting tenants install admission webhooks on the host, where one broken webhook that fails closed is every tenant's outage. Running namespace-per-team without a tenant operator, so quotas, network policies and RBAC drift by hand across dozens of namespaces, now that the Hierarchical Namespace Controller is archived. Treating a virtual control plane as data-plane isolation when the documentation says it is not. Cluster-per-team by default, which becomes a cluster farm with extended-support surcharges the moment one falls behind. Enforcing one Kubernetes version for everyone on the host instead of letting a virtual-cluster tenant run their own. Leaving DNS resolvable across all namespaces so every tenant can enumerate every other tenant's services. And a shared storage class with a Retain reclaim policy, so a reused persistent volume is another tenant's data.

Q: What does a mature tenancy model for an internal platform look like?

A ladder with a published price per rung rather than a single model. Stage one inventories every cluster-scoped object on each shared cluster and who installed it, because anything tenant-installed is a tenancy decision made by accident. Stage two makes the namespace rung real with a tenant operator inheriting quotas, limit ranges, default-deny network policy with DNS, Pod Security Standards and per-tenant storage, restricted cross-namespace DNS, and no tenant-held cluster-scoped bindings. Stage three adds the virtual-control-plane rung with vCluster or an equivalent for tenants that need their own CRDs, webhooks or version, with shared services provided from the host side and quotas on the host namespace each virtual cluster syncs into, and uses the same rung for preview environments and CI. Stage four adds private-node and dedicated-cluster rungs with their cost, including the extended-support surcharge, published in the developer portal. Stage five operates the ladder: every tenant has a rung, an owner for its cluster-scoped objects and a cadence it signed, promotion between rungs is ticketless, and the count of dedicated clusters is a metric expected to fall.

Satyam Kumar

Volver al Blog

multi-cloud-infrastructure

Multi-Tenancy in Internal Platforms: Namespaces Isolate What Is Namespaced, So Choose the Tenancy Model by Who Owns the Cluster-Scoped Objects (2026)

By Satyam KumarOctober 9, 202619 min read

kubernetes multi-tenancy internal platform namespace per team vs cluster per team vcluster virtual control plane capsule kubernetes tenant operator hierarchical namespace controller archived cluster-scoped resources crd webhook isolation platform engineering tenancy model kubernetes noisy neighbour isolation node isolation taints tolerations tenants pod security standards multi-tenant kubernetes network policy default deny tenants eks extended support pricing kubernetes cluster sprawl shared kubernetes cluster security gpu tenancy private nodes internal developer platform architecture

Multi-Tenancy in Internal Platforms: Namespaces Isolate What Is Namespaced, So Choose the Tenancy Model by Who Owns the Cluster-Scoped Objects (2026)

Frequently Asked Questions

Compartir este artículo

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

Arquitecto de IA y Cloud. Ayudando a equipos a construir sistemas que escalan a millones.

LinkedIn GitHub

Multi-Tenancy in Internal Platforms: Namespaces Isolate What Is Namespaced, So Choose the Tenancy Model by Who Owns the Cluster-Scoped Objects (2026)

Frequently Asked Questions

Compartir este artículo

Comments

Leave a comment