Kubernetes Without the VMware Tax

VergeOS does not introduce a Kubernetes distribution. RKE2, K3s, upstream Kubernetes, and vendor distributions all run on VergeOS through Rancher or directly on VergeOS VMs. The CSI driver and Cloud Controller Manager work with any cluster that meets the upstream Kubernetes specification.

If a platform requires you to adopt a specific distribution, you are trading one form of lock-in for another.

The VergeOS CSI driver delegates storage operations directly to the VergeOS API. Persistent volumes are vSAN volumes — with inline deduplication, multi-tier placement across NVMe / SSD / HDD, and snapshots that integrate with VergeOS system snapshots. A Kubernetes persistent volume snapshot is a vSAN snapshot, which means stateful workloads share the same DR and replication infrastructure that protects production VMs.

Compare to overlay storage solutions like Longhorn or Portworx, which run their own replicated storage engines on top of the hypervisor — doubling work, breaking dedup, and splintering management.

Yes. Most enterprises run a mix of containerized applications and traditional VMs — databases that have not been containerized, packaged software supported only on VMs, legacy applications that predate the cloud-native era. VergeOS runs all of these workloads alongside Kubernetes clusters on shared infrastructure with shared storage and shared networking.

Kubernetes-only platforms force you to maintain separate infrastructure for these workloads. That is not a trade most enterprises want to make.

Industry research describes the dominant Kubernetes migration pattern as parallel operation with iterative workload movement. VergeOS plus Rancher fits this pattern natively. New clusters land on VergeOS. Old clusters stay on vSphere. Rancher manages both for the duration of the migration. Workloads move on your timeline, starting with stateless services and finishing with stateful workloads after the new platform validates under real load.

For Tanzu customers, the migration includes reconstruction of StorageClasses (replacing SPBM-projected policies), networking plane replacement (replacing NSX-T), and developer experience continuity (typically Backstage, Argo CD, Tekton, and Crossplane in place of TAP). VergeOS is the platform built to absorb the work.

Nothing. Application teams continue to use Rancher, kubectl, and standard Kubernetes APIs. The substrate underneath changes. The contract above does not. Pods schedule the same way. Services expose the same way. Persistent volumes mount the same way. The integration is native at the platform layer, not visible to the application layer.

This is the entire point of the Rancher continuity argument. VergeOS slots in as a new substrate alongside vSphere, and after cutover becomes the substrate. Application teams see no change in their day-to-day interaction with Kubernetes.

Native, not bolted on. VergeOS ships a CSI driver and a Cloud Controller Manager as Helm charts from the verge-io GitHub repository. The CCM provisions LoadBalancer services through VergeOS VNet NAT rules. The CSI driver delegates storage operations directly to the VergeOS API — provisioned volumes participate in the full vSAN feature set including inline dedup, multi-tier placement, and integrated snapshots.

No. Rancher remains the management plane. VergeOS replaces vSphere as the substrate underneath. The native Rancher node driver and UI extension provision clusters on VergeOS exactly the way Rancher provisions clusters on vSphere today — same flow, same forms, same operational model.

RKE2 and K3s through the Rancher node driver. Upstream Kubernetes and other distributions through the standard CSI and CCM contracts. The integration is distribution-agnostic at the storage and networking layer — if your cluster meets the upstream Kubernetes specification, the components work.

Unified storage policy across VMs and pods. Stateful Kubernetes workloads share the same vSAN that protects production VMs — same snapshot semantics, same DR model, same deduplication, same UI. Overlay storage layers run their own replicated storage engine on top of the hypervisor, which doubles work, breaks dedup, and splinters management.

Phased, with Rancher managing both substrates during cutover. New clusters land on VergeOS. Existing TKG clusters stay on vSphere. Stateless services move first. Stateful workloads move after validation. The honest position: migration is a project, not a port. SPBM-projected StorageClasses and NSX-T networking need reconstruction. VergeOS is the platform built to absorb that work.

Tanzu Application Platform v1.12 was designated long-term support in March 2026, so TAP technically remains supported. The investment thesis behind it has been undermined — Tanzu Platform SaaS reached End of Availability May 1, 2025, legacy Tanzu SKUs were retired in May 2024, and Broadcom has cut substantial workforce across the Tanzu organization. Most TAP shops migrate to a CNCF-native developer experience built on Backstage, Argo CD, Tekton, and Crossplane.

VergeOS itself runs on bare metal commodity hardware. Kubernetes clusters then run on VergeOS VMs — the enterprise pattern. This gives you live migration, integrated DR, snapshot-based recovery, and unified storage policy across containerized and traditional workloads. If you are running Kubernetes directly on bare metal today, this is the operational uplift path.