The biggest win for us has been bringing container and VM operations together under one roof. Our infra team didn’t have to learn an entirely new toolchain—spinning up a Tanzu Kubernetes Cluster (control plane, worker nodes, the works) happens right inside vSphere Client, using the same namespace-based workflow we already rely on for everything else. We created a dedicated namespace ("primp-industries") and had a cluster up and running in minutes, not days.

What really sold the team, though, was the single-pane visibility. Node health, control plane status, CPU/memory allocation, storage policies—it’s all available in one dashboard instead of being split between a Kubernetes-specific tool and a separate vCenter view. With content library integration for our TKG cluster images and the built-in CLI tooling, day-to-day operations feel much less fragmented than they did in our old setup. Review collected by and hosted on G2.com.

Onboarding was pretty rough for anyone on the team without a Kubernetes background. Getting the supervisor cluster, the namespace structure, and storage policies configured correctly took real ramp-up time. A few of the configuration panels—especially the ones for setting per-namespace resource limits—feel less intuitive than they should. Also, when a node goes unhealthy, we often end up leaving the vSphere UI entirely to dig through logs elsewhere, which undercuts the “everything in one place” promise a bit. Post-Broadcom licensing costs are another area we’re watching closely as we think about scaling this up. Review collected by and hosted on G2.com.