Two teams on our reference estate used to wait forty-five minutes for a Kubernetes cluster. On VKS the same request became a vSphere Namespace they could draw from in under five, and that one change rewrites what multi-tenancy even means on this platform. On TKGI a tenant meant a cluster. You sized it with a plan, isolated it with its own routers, and handed a team the scope to build more. On VKS a tenant means a vSphere Namespace, a slice of the Supervisor with its own quota, roles and network, inside which a team self-serves clusters, VMs and pods. Last part we inventoried who can do what across the estate. This part takes those same teams and gives them a home on the target, mapping every TKGI tenancy construct onto the namespace model before you set a single quota.

Two ways to slice a platform

Every multi-tenant platform answers one question, where does one team stop and the next begin. TKGI drew that line at the cluster. VKS draws it at the vSphere Namespace, one level higher in the stack and one level cheaper to operate. Seeing both hierarchies side by side is the fastest way to understand why a straight port of your tenancy model produces either sprawl or a security gap. On the left, a plan produces a cluster and teams sit inside it. On the right, a Supervisor produces namespaces and teams self-serve underneath.

flowchart TB
  subgraph s1 [TKGI tenancy]
    P1[TKGI plans small medium large] --> C1[Cluster per plan]
    U1[pks.clusters.manage scope] --> C1
    C1 --> N1[k8s namespaces per team]
    C1 --> T1[Per tenant T0 gateway]
  end
  subgraph s2 [VKS tenancy]
    SUP[vSphere Supervisor] --> VN[vSphere Namespace per team]
    VN --> GC[Self service VKS clusters]
    VN --> VM[Self service VMs and pods]
    VN --> QR[Quota, RBAC, VM classes, NSX VPC]
  end

Read the two trees and the saving is obvious. TKGI needed a whole cluster, control plane and worker nodes included, to give a team a hard boundary. VKS gives that boundary with a vSphere Namespace and lets several tenants share the Supervisor and even share guest clusters underneath. A team still gets isolation, quota and its own network, it just no longer needs a dedicated cluster to get them. That single move is where most of the operational cost of TKGI multi-tenancy disappears, and it is also where a careless port throws the saving away by cloning the old one cluster per tenant habit onto new plumbing.

How TKGI carved up tenants

Three mechanisms combined to make TKGI multi-tenant, and each lands somewhere different on VKS, which is why you separate them now instead of during a cutover. Plans came first. A plan was a named template, small, medium or large on the reference estate, that fixed how many control plane and worker nodes a cluster got and how big each node was. A team picked a plan and BOSH built a cluster to match. List them to see the sizing contract your teams currently depend on, because those sizes are about to become VM classes rather than whole clusters.

Scopes came second. Self-service on TKGI lived in UAA, not in Kubernetes. A user holding pks.clusters.manage could create and resize their own clusters through the TKGI API, so onboarding a team meant granting a scope and letting them provision against the plans you published. Isolation came third. For tenants that needed a hard network boundary, TKGI on NSX-T could place each behind its own tier-0 gateway, a multi-T0 topology where one tenant traffic never shared a router with another. Three separate levers, sizing, self-service and isolation, all bolted onto the cluster as the unit of tenancy. Untangling them is the real work of this part, because VKS hands each lever to a different object.

Self-service on vSphere Namespaces

On VKS the vSphere administrator creates a vSphere Namespace and stocks it, then hands it to a team, and everything the team does happens inside that envelope. Four things get attached when the namespace is created, and together they replace all three TKGI levers at once. Resource quotas cap CPU, memory and storage, plus the number of Kubernetes objects, so a runaway tenant cannot starve its neighbours. Storage classes bind the namespace to specific vSphere storage policies with a capacity limit on each. VM classes define the CPU and memory shapes a team may stamp out, which is exactly where the old plan sizing lands. And role bindings grant named users or groups Owner, Edit or View on that namespace, which is where self-service now lives.

With that envelope in place, a team member holding Edit on the namespace runs kubectl to create a VKS cluster, a standalone VM or a pod, and it appears without a platform ticket, bounded only by the quota you set. No UAA scope to grant, no BOSH queue to wait behind. Self-service stops being a special permission on a separate API and becomes the ordinary Kubernetes verbs applied inside a walled garden. That is the model shift worth internalising before you draw a single namespace, because it quietly changes how many clusters you actually need to run. A team that used to justify a whole cluster to get isolation now gets the same isolation from a namespace that costs you almost nothing to create.

Enforcement also moves to a place you can trust. On TKGI a plan capped a cluster at build time, and once a team held pks.clusters.manage they could keep creating clusters until the underlying capacity ran out, which is how a self-service estate quietly overcommits. A vSphere Namespace quota is enforced continuously by Supervisor admission control, so a create that would breach the CPU, memory, storage or object limit is rejected at the API rather than discovered later on a full datastore. Governance stops being a spreadsheet you reconcile after the fact and becomes a limit the platform applies to every request, which is a real gain worth naming to whoever owns capacity.

Tenancy mapping sheet

Here is the artifact to keep from this part, the tenancy mapping sheet. One row per TKGI tenancy construct, resolved to its VKS home, what changes, and the action you take. Build it against your own estate and it tells you exactly how many namespaces, VM classes and VPCs you are about to define. Our reference estate fills in like this.

Two rows carry most of the design risk. Plan to VM class is the row where sizing quietly detaches from the cluster, so a team that thought in whole clusters now thinks in machine shapes it stamps inside a namespace. Cluster per team to namespace per team is the row that decides your whole layout, because it is the moment you choose whether tenants share clusters or each gets its own. Get that second row right and the rest of the sheet follows. Get it wrong and you rebuild the TKGI cost structure on VCF 9.

Namespace design for the reference estate

Design turns on one decision, and it is the decision most teams get wrong on the first pass. Coming off TKGI, where a tenant was a cluster, the reflex is to give each team its own VKS guest cluster and treat the namespace as a formality. That reflex is expensive. Every guest cluster carries its own control plane, its own upgrade cycle and its own node overhead, which is precisely the per cluster tax BOSH imposed and the tax you are migrating to escape. Sharing clusters beneath namespaces is what actually banks the saving.

That onboarding gap is not a feeling, it is measurable, and it is the strongest argument for namespace first tenancy. Wall-clock time from a request to a ready unit tells the story cleanly across the four things a team can ask for on this estate.

My verdict is to make the vSphere Namespace your tenant boundary and share guest clusters beneath it. Give a team its own dedicated VKS cluster only when it has a real reason, a compliance boundary that forbids shared nodes, a wildly different Kubernetes version cadence, or a noisy neighbour risk that quota cannot contain. That default of one cluster per team, carried over from TKGI plans out of habit, is the choice to avoid. It looks familiar and it costs you the very overhead reduction that justified the migration in the first place. Familiar is not the same as correct here, and the numbers above are the reason.

One caution keeps this from becoming dogma. Sharing clusters beneath namespaces concentrates blast radius, so a control plane problem on a shared VKS cluster touches every tenant riding it, where a per team cluster would have contained the damage. Answer that with more than one shared cluster, not with a cluster per team. Our reference estate ran three, splitting production, staging and a mixed development pool, which holds any single failure domain to a third of the tenants while still banking most of the consolidation saving. Balance, not maximum density, is the goal.

Once the boundary is a namespace, the design work is filling in its quota, and these are the dimensions to set for each tenant. Values shown are what our reference estate used for a mid-size production tenant, and they start from measured consumption plus headroom rather than from an old plan size.

For how the target platform presents namespaces, VM classes and self-service in depth, the vSphere Kubernetes Service Complete Guide covers the destination, and this series links to it rather than re-teaching the mechanics. For where this tenancy design sits in the overall plan, the migration guide holds the full sequence.

Consolidate tenants onto namespaces this week

Start by listing your TKGI plans and clusters and marking, for each team, whether it truly needs a dedicated cluster or whether a vSphere Namespace on a shared cluster covers it, and expect most teams to land in the shared column. Turn each plan size into a candidate VM class, and each per tenant T0 gateway into a candidate NSX VPC, using the mapping sheet so nothing is invented twice. Then draft one namespace quota per tenant across the six dimensions in the decision table, starting from current consumption plus headroom rather than from the old plan size, because a plan sized a whole cluster and a quota sizes a tenant. Next part assembles all of this into a target reference architecture, the single diagram that shows Supervisor, namespaces, clusters, storage and network as one design your teams can build against. Open the mapping sheet and mark your first three teams shared or dedicated before you close the laptop.

References

• Broadcom TechDocs, What is a vSphere Namespace, VCF 9
• Broadcom TechDocs, Configuring and Managing vSphere Namespaces, VCF 9
• Broadcom TechDocs, Isolating Tenants with multi-T0, TKGI 1.18

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts