Thinking of adopting VMware’s vSphere Kubernetes Service? Here is why many organisations regret it, and what they should consider instead.
Every technology decision carries consequences that only become visible once the work begins. This is especially true for teams considering VMware’s vSphere Kubernetes Service (formerly known as Tanzu). On paper it appears to align neatly with existing VMware estates. In practice the experience often feels far heavier than expected.
The platform aims to bring Kubernetes into the VMware ecosystem at enterprise scale. That focus is also the root of its friction. vSphere, NSX, vSAN and the Kubernetes Supervisor are tightly bound together, which means even simple deployments demand careful planning across networking, storage and security. Lean IT teams discover quickly that the platform assumes deep VMware expertise, and any gaps in that knowledge create delays and extra cost.
The Broadcom-era packaging changes have amplified these issues. vSphere Kubernetes Service is no longer a standalone option. It is now embedded inside the VMware Cloud Foundation (version 9) subscription and is tied to NSX as the networking layer and vSAN as the storage foundation for supported production clusters. Organisations that once used more flexible designs now find themselves pushed into a prescriptive architecture that increases both the footprint and the licensing bill.
Operationally, the load continues to grow. Running Kubernetes through the vSphere Supervisor adds abstractions, lifecycle components and dependencies that must all be maintained. NSX requires constant attention, vSAN adds its own tuning requirements and the cluster class model introduces a steep learning curve. The platform is capable, although it asks for more time, more training and more specialised engineering than many organisations possess.
This creates a sense of lock-in that only becomes clear once the platform is in place. Adopting vSphere Kubernetes Service means adopting the full VMware stack across compute, storage, networking and lifecycle operations. Replacing any part of that stack becomes difficult, and the long-term cost of the ecosystem rises sharply. Smaller organisations feel this most because they must carry the overhead without the scale that usually justifies it.
This is why many teams pause their plans and look for a modern path that delivers Kubernetes without the weight. Portainer, with its integrated support for Talos / Kubernetes, offers that path. Portainer provides an intuitive control plane that makes Kubernetes clear and manageable without diluting capability. Talos delivers an immutable, API-driven operating system designed for Kubernetes, which removes configuration drift, reduces maintenance effort and eliminates entire categories of operational risk.
Together, they give organisations a platform that is easy to deploy, predictable to operate and far lighter to run. They avoid prescriptive storage and networking choices. They reduce the number of tools an engineer must learn. They support clusters in the data centre, at the edge or in the cloud with the same consistent experience. Most importantly, they align with how real IT teams work, rather than expecting those teams to mimic hyperscale engineering practices.
The question is not whether vSphere Kubernetes Service is powerful. The question is whether the cost, the operational friction and the architectural lock-in fit the organisation you have today. For many teams the answer is no. They need something faster to adopt, easier to live with and more aligned with their constraints.
Portainer with Talos delivers that. It offers a clear, capable and future-ready Kubernetes foundation without the burden that has caused so many organisations to step back from the VMware path.