TL;DR · Key Takeaways
- VKS is not a new product. It is Tanzu Kubernetes Grid Service renamed, the same runtime lineage, now the native Kubernetes service of VMware Cloud Foundation 9.
- The unified VKS name landed with the 3.3 release on 4 March 2025. The deprecated
TanzuKubernetesClusterAPI and the old TKr naming are the trail of breadcrumbs that confuse people on older builds. - VKS is a Supervisor Service: it provisions conformant, upstream-aligned clusters whose nodes are VMs on the same ESX hosts as everything else you run.
- It is deliberately not a PaaS. No built-in developer portal, no opinionated CI/CD. It hands you governed clusters and gets out of the way.
- Choose it when you already run VCF and want Kubernetes owned by the same team, policies and infrastructure as the rest of the estate, not when you want a turnkey app platform.
If you have been around the VMware ecosystem for a few years, you have watched the same Kubernetes runtime get renamed more than once. It was Tanzu Kubernetes Grid Service. Then everyone shortened it to TKGS. Now, in VMware Cloud Foundation 9, it is vSphere Kubernetes Service, VKS. The names changed faster than the technology did, and that single fact is responsible for most of the confusion I see in the field: teams genuinely cannot tell whether they are looking at a new product, a new edition, or just a new sticker on a box they already own.
So before we enable anything or argue about node pools, let us be precise about three things: what VKS actually is, where it sits in VCF 9, and who it is genuinely for. Get those straight and every later decision in this 17-part series, sizing, networking, GPUs, the lot, becomes a much shorter conversation.
The rename, and what actually changed underneath it
Here is the honest version. VKS is Tanzu Kubernetes Grid Service. VMware unified the naming so the service, its clusters and its Kubernetes distribution all carry one consistent “vSphere Kubernetes” identity, and that unified name shipped with the 3.3 release on 4 March 2025. Nothing was re-architected. The Supervisor still embeds a Kubernetes control plane into the vSphere cluster, and the service still provisions full, conformant clusters on top.
What did change is the surface you touch. The old TanzuKubernetesCluster (TKC) API was deprecated with the 3.2.0 release in October 2024 in favour of the standard upstream Cluster API, and the Tanzu Kubernetes release (TKr) was renamed the vSphere Kubernetes release (VKr). If you are running an older VCF or vSphere build, you will still see “Tanzu” and “TKG” scattered through menus, CLI output and YAML. That is expected. It is also the number one reason people think VKS and TKGS are different things. They are not, they are the same runtime at different points on a renaming timeline.
| You used to see | Now it is | What it means for you |
|---|---|---|
| Tanzu Kubernetes Grid Service (TKGS) | vSphere Kubernetes Service (VKS) | Same service; just the new name in VCF 9 |
TanzuKubernetesCluster API | Cluster API + ClusterClass | Define new clusters the standard way (Part 4) |
| Tanzu Kubernetes release (TKr) | vSphere Kubernetes release (VKr) | Same signed K8s images in your content library |
| Tanzu CLI workflows | kubectl / VCF CLI | Mostly muscle memory; the verbs are familiar |
Where VKS actually sits: a service, not a stack
The mental model that prevents most early mistakes is this: VKS does not float free. It is a Supervisor Service, which means it runs on the vSphere Supervisor, which is itself a capability of the VCF platform. Stack it from the bottom and it reads cleanly, your certified hardware, the VCF 9 platform on top, the Supervisor turning a vSphere cluster into a Kubernetes control plane, and VKS provisioning the workload clusters your developers actually consume. Every one of those workload-cluster nodes ends up as a VM, scheduled by DRS across the same ESX hosts as the rest of your estate. There is no separate Kubernetes silo bolted on the side.
I unpack these layers properly in Part 2, and the platform-level reference design lives in the VCF 9 Series piece on Supervisor and VKS architecture. The takeaway for now is structural: VKS is the Kubernetes runtime, and everything beneath it is infrastructure you are likely already responsible for. That is the entire pitch, and it is a stronger one than the marketing usually makes.
What it gives you, and what it pointedly does not
What you get is upstream-aligned, CNCF-conformant Kubernetes whose entire lifecycle, provisioning, scaling, upgrade, is driven declaratively and wired into vSphere. Clusters draw compute from VM classes, storage from vSphere storage policies, and networking from NSX or VDS. The VKr gives you a Kubernetes distribution that is signed, tested and supported by VMware. Conformance matters here: because the clusters are standard Kubernetes, your existing tooling, kubectl, Helm, Argo CD, Prometheus, transfers without translation. And because VKS 3.6 added bring-your-own-CNI, you are not even locked to Antrea if a workload genuinely needs Calico or Cilium.
What you do not get is an application platform. There is no built-in developer portal, no opinionated pipeline, no service mesh switched on for you. VKS removes the infrastructure toil of running Kubernetes on vSphere. It does not remove the work of building a platform on top, and a team that expects a batteries-included PaaS the moment a cluster appears is going to spend month two surprised that they are still wiring up ingress and registries themselves. That is not a flaw; it is a scope decision. But you have to scope to it.
Who it is for, versus DIY upstream and OpenShift
VKS occupies a deliberate middle ground, and seeing the three options side by side is the fastest way to know whether it is your tool. Rolling your own upstream Kubernetes on vSphere gives maximum flexibility and maximum operational burden, you own the control plane, the upgrades, the CNI, all of it. OpenShift sits at the opposite end: a full application platform with its own opinions, lifecycle and licensing that runs on vSphere but does not particularly care that it is vSphere. VKS is in between, more managed and more integrated than DIY, far less of a standalone PaaS than OpenShift.
| DIY upstream on vSphere | VKS | OpenShift | |
|---|---|---|---|
| Who runs the control plane | You, entirely | The platform (Supervisor) | The platform |
| vSphere integration | Whatever you build | Deep and native | Abstracted away |
| Developer experience | Bring your own | Bring your own | Rich, built in |
| Best fit | Niche control needs | Kubernetes on the VCF you run | Turnkey app platform, any infra |
VKS is for organisations that already run VCF and want their Kubernetes governed by the same teams, policies and infrastructure as the rest of the estate. If your virtualization team owns compute, storage and network, VKS lets them offer Kubernetes as a self-service resource without standing up a parallel platform org. Part 17 returns to this with a full verdict once you have seen what the service actually does; for now, that one sentence is the filter.
Decoding the version labels you will actually meet
The rename only confuses people because the old and new names coexist in the wild, and which one you see depends entirely on which release you are standing on. If you can place a label on the timeline, you stop wondering whether you have the wrong product. The short version: the further back the platform, the more “Tanzu” you see, and on VCF 9.1 you are fully in VKS and VKr territory.
On vSphere 7 and 8
Here the service is TKGS, clusters are often defined with the TanzuKubernetesCluster API, and the Kubernetes images are TKr. None of that is wrong or unsupported on those platforms; it is just the older surface of the same runtime. If you are operating one of these, do not feel pressure to chase the new names. Plan the move when you move the platform, and treat the rename as something that happens on the way to VCF 9, not a thing to retrofit onto vSphere 8.
On VCF 9.0 and 9.1
VCF 9.0 is the transitional release where the VKS name is in use and the Cluster API is the path, but you can still encounter the deprecated TKC class for backward compatibility. VCF 9.1 is the clean state: VKS and VKr throughout, the Cluster API as the only provisioning model, and VDS or NSX VPC as the only supported networking. The practical rule for anyone reading documentation or a blog is to check which version it targets first, because a 9.0 article and a 9.1 article can give genuinely different answers on networking and API defaults, and that single habit prevents a surprising amount of wasted time.
In practice
The teams that struggle most with the rename are the ones running a mixed estate, some clusters on vSphere 8 TKGS, some on VCF 9 VKS, and treating the two surfaces as different products. They are not. Document internally that TKGS and VKS are the same runtime at different versions, and the support calls that start with “is our Tanzu cluster even supported anymore” largely stop.
What conformance actually buys you
The word “conformant” gets used a lot and skipped over, but it is the quiet centre of the whole value case, so it is worth being concrete about what it means and does not. A conformant cluster passes the CNCF conformance suite, which means the Kubernetes API behaves the way upstream Kubernetes behaves, no proprietary fork of the API, no surprise omissions.
Your tooling transfers unchanged
Because the API is standard, everything your team already runs against Kubernetes works against VKS without translation: kubectl, Helm, Argo CD and Flux, Prometheus and Grafana, kustomize, the operators you depend on. There is no VKS dialect to learn and no adapter layer to maintain. That is a different proposition from a platform that wraps Kubernetes in its own abstractions, where your existing manifests and pipelines need rework. On VKS, a manifest that runs on EKS or on a laptop kind cluster runs here too, which makes both adoption and exit far cheaper than a platform you are locked into.
Your skills and your hires transfer too
The same portability applies to people. An engineer who knows Kubernetes is productive on VKS on day one, because what they know is the thing VKS gives them, not a proprietary variant they must relearn. You can hire for Kubernetes, not for VKS specifically, and the knowledge in the wider community, the Stack Overflow answers, the upstream docs, the conference talks, all applies. That is a real operational advantage that rarely makes it into a feature comparison, and it is one of the strongest arguments for choosing a conformant distribution over an opinionated platform when your team already has Kubernetes skills.
Worked example
A team moving a workload off a managed cloud Kubernetes service onto VKS expected a porting effort and budgeted weeks for it. Because both clusters are conformant, the actual work was repointing their GitOps repo at the new cluster, fixing the StorageClass and ingress names to match the VKS environment, and recreating their image pull secrets. The application manifests themselves were unchanged. The migration that was scoped as a re-platform turned out to be a reconfiguration, which is exactly what conformance is supposed to buy and exactly why it belongs in the decision rather than the footnotes.
What I’d Do
If you are coming to this with existing TKGS or TKG clusters, do not panic and do not rush a migration; understand that the runtime is continuous and let the rename stop intimidating you. If you are evaluating VKS fresh, judge it for what it is, the Kubernetes of your private cloud, and not against a PaaS scorecard it was never built to win. The teams that are happiest with VKS are the ones who wanted governed, integrated, self-service Kubernetes on infrastructure they already trust, and who brought their own delivery platform on top. The teams that are disappointed wanted OpenShift and bought VKS by mistake. So before Part 2 gets into the architecture: which of those two teams are you, and does your answer match what your developers are actually asking for?
References
- Broadcom TechDocs: VKS Architecture (VCF 9.0)
- Broadcom TechDocs: vSphere Kubernetes Service Release Notes
- VCF Blog: Extend VCF with Enhanced vSphere Kubernetes Service Add-ons
About The Author
DrJha