TL;DR · Key Takeaways
- VKS is the right Kubernetes when you already run VCF and want clusters governed by the same teams, policies and infrastructure as everything else.
- It is not trying to be OpenShift. If you need a full, opinionated application platform with its own developer experience, that is a different product and a different bill.
- Versus hyperscaler managed Kubernetes, VKS wins on data residency, private-cloud integration and predictable on-prem economics; it loses on global reach and managed-service breadth.
- VKS earns its place clearest as an internal developer platform, for dev/test self-service, for data services on Kubernetes, and, most distinctively, as the substrate for GPU and AI workloads.
Sixteen parts in, you have seen what VKS is, how it is built, and how to run it. This final part steps back and answers the question that should drive any platform choice: when is VKS actually the right answer, and when is it not? I will be honest about the limits, compare it fairly to the obvious alternatives, and finish with where it genuinely earns its keep, because a recommendation without its boundaries is just marketing.
The middle ground, drawn plainly
VKS is at its best when Kubernetes needs to be a first-class citizen of a private cloud you already operate. The clusters draw compute from VM classes, storage from SPBM policies and networking from NSX, all things your existing teams understand and govern. One operational model covers VMs and Kubernetes; your storage policies, your segmentation and your monitoring in VCF Operations all extend to clusters without a parallel platform team. The honest way to place it is on a spectrum between two things you already know.
The honest limits
VKS is not an application platform. There is no built-in developer portal, no opinionated CI/CD, no integrated service mesh switched on by default; you assemble those yourself, as Part 13 made clear. It is tied to VCF, so it is only a sensible choice if you are committed to that platform, it is not a neutral, run-anywhere distribution. And being newer in its VCF 9 form, some capabilities are still maturing release to release, which is why this series anchored specifics to versioned documentation. None of these is disqualifying, but pretending they do not exist is how teams end up disappointed.
| Dimension | VKS | OpenShift | Hyperscaler managed K8s |
|---|---|---|---|
| Best fit | Kubernetes on the VCF you run | Full app platform, any infra | Cloud-native, global scale |
| Developer experience | Bring your own | Rich, built in | Cloud console + ecosystem |
| Data residency | On-prem, fully yours | Wherever you run it | In the provider’s cloud |
| Infra integration | Deep with vSphere/NSX/vSAN | Abstracted from infra | Deep with that cloud |
| Economics | Predictable, uses owned iron | Platform subscription | Consumption / egress costs |
The short version: choose OpenShift when you want a turnkey application platform and will pay for that experience across any infrastructure. Choose hyperscaler managed Kubernetes when the cloud is where your workloads and your scale want to be. Choose VKS when your data, your iron and your operational model are on a private cloud running VCF and you want Kubernetes to belong to that world rather than sit beside it.
Where VKS earns its place
Four use cases stand out where VKS is not just adequate but genuinely the strong choice:
- Internal developer platform. When the virtualization team wants to offer self-service Kubernetes to developers under existing governance, VKS delivers it without a second platform org.
- Dev/test self-service. Ephemeral clusters teams spin up and tear down within namespace quotas, with the infrastructure team keeping control of the guardrails.
- Data services on Kubernetes. Stateful workloads benefit from SPBM-backed storage and the dual Kubernetes/vCenter visibility from Part 8, so databases and queues are first-class, not awkward.
- GPU and AI workloads. The most distinctive case. As Part 14 showed, VKS is the substrate for VMware Private AI Foundation, and the path from a single GPU node pool to a governed AI platform is uniquely smooth.
Total cost of ownership, honestly
Economics is where the comparison gets real, and it cuts both ways. VKS runs on iron you already own and licenses you may already hold as part of VCF, so the marginal cost of standing up Kubernetes on an existing VCF estate is genuinely low compared with paying a separate platform subscription or a hyperscaler’s per-cluster and egress bill. That is the honest advantage. The honest cost is the human one: you bring your own developer platform, your own CI/CD, your own delivery tooling, and you operate it. With OpenShift a chunk of that is bought; with a hyperscaler a chunk is managed for you. So the cheaper infrastructure comes with more to run yourself, and whether that is a saving depends entirely on whether you have the platform team to absorb it.
The way to get the TCO comparison wrong is to count only the license line. Count the people, the tooling you will assemble, and the operational time, against the subscription and consumption costs of the alternatives. For an organisation already deep in VCF with a capable infrastructure team, VKS usually wins that fuller comparison. For an organisation that wants the platform handed to them and has no appetite to build one, the apparent saving evaporates into staffing, and one of the managed options is the better buy. Be honest about which organisation you are.
Migration paths onto VKS
If you are already running Kubernetes somewhere, adopting VKS is a migration, not a greenfield, and the path depends on where you are coming from. From existing TKG or TKGS clusters the move is mostly continuity, the same runtime lineage, so the work is updating to the Cluster API provisioning model and the VCF 9 networking modes rather than re-platforming. From upstream clusters or another distribution, the applications are portable because VKS is conformant, so the migration is redeploying the workloads, with their GitOps definitions, onto fresh VKS clusters and cutting traffic over, rather than lifting cluster internals. Stateful workloads are the careful part, as always: their data has to be moved or replicated, and that is where Velero restores or application-level replication earn their place.
The reason conformance matters here is that it keeps the migration at the application layer, where your manifests and Helm charts already live, rather than forcing a rewrite. That is a real advantage over moving between opinionated platforms. Plan the cutover workload by workload, keep the old and new running in parallel until each service is proven on VKS, and lean on GitOps so the redeploy is declarative rather than a hand-assembly job.
Where VKS is still immature, and a decision checklist
An honest verdict names the rough edges. In its VCF 9 form VKS is newer, and some capabilities are still settling release to release, which is precisely why this series has anchored specifics to versioned documentation and flagged the 9.0-to-9.1 breakpoints. The developer experience is deliberately bring-your-own, so if a polished, opinionated platform out of the box is the requirement, that gap is real and will not be closed by configuration. And the tie to VCF means VKS is only a sensible choice if you are committed to that platform; it is not a neutral, run-anywhere distribution you can carry between infrastructures. None of these is disqualifying, but a recommendation that hides them is the kind that produces disappointed teams.
So the decision comes down to a short checklist. Are you committed to VCF? Do you have a platform team able to bring and run the delivery tooling on top? Do your strongest use cases sit in the four where VKS is genuinely the better choice, internal developer platform, dev and test self-service, data services, and above all GPU and AI? And are you judging it as the Kubernetes of your private cloud rather than against a PaaS scorecard? If the answers are yes, VKS is a strong, defensible choice and the GPU continuity into Private AI is a real differentiator. If they are no, one of the alternatives will serve you better, and there is no shame in saying so.
What I’d Do
If your organisation is committed to VCF, I would adopt VKS for governed, self-service Kubernetes and bring my own delivery platform on top, exactly as Part 13 described, rather than shopping for a PaaS it was never meant to be. I would lead with the use cases where it is strongest, an internal developer platform, dev/test self-service, data services, and especially GPU and AI, because that GPU continuity into Private AI is the part competitors cannot easily match. And I would be honest with stakeholders about the limits up front, so nobody expects OpenShift’s developer experience out of the box. Judge VKS as the Kubernetes of your private cloud and it holds up well. That closes the series: seventeen parts from “what is VKS” to “when to use it.” Start back at Part 1, or jump to whichever part you need from the complete guide. So, last question of the series: is your team evaluating VKS for what it actually is, or holding it to a scorecard it was never built to win?
References
- VCF Blog: Architecting VKS on VCF, Field Questions Answered
- VCF Blog: Extend VCF with Enhanced vSphere Kubernetes Service Add-ons
- Broadcom TechDocs: VKS Architecture
About The Author
