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.
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
