Kubernetes Without the VMware Tax.
Thirty minutes. One platform demo. Three taxes retired in a single deploy. VergeOS runs the hypervisor, the Kubernetes control plane, and the storage layer from one integrated platform. Rancher stays.
Where you are today.
How does your team run Kubernetes in production today?
Zoom poll launches now. The next forty minutes lean into whichever cohort lands biggest.
Three taxes. One platform decision.
VMware shops running Kubernetes pay three vendors at once. The hypervisor tax keeps the cluster nodes running. The distribution tax adds Tanzu or OpenShift or Rancher Prime on top. The overlay storage tax patches the gap when vSphere storage policies do not extend cleanly into the cluster. The math compounds every renewal cycle, and the integration work between the three layers compounds with it.
vSphere keeps the lights on.
Every Kubernetes node runs on a hypervisor. The vSphere bill arrives every year regardless of how the cluster is being used. Broadcom pricing has tripled per-core in two cycles.
Tanzu, OpenShift, or Rancher Prime.
The commercial distribution adds another vendor on top. Each one packages upstream Kubernetes with proprietary glue. The price tag rides on top of the hypervisor cost, not in place of it.
Persistent volumes don’t Just Work.
vSphere storage policies stop at the cluster boundary unless Tanzu is wedged in. Many shops bolt on Longhorn, Portworx, or OpenEBS to fill the gap, and a third vendor enters the room.
The hypervisor swap solves one tax. The other two stay on the invoice. The platform decision is the one that retires all three.
Rancher stays.
The teams running Rancher today keep running Rancher. The platform underneath changes. The cluster object, the namespace policy, the team that operates the platform — none of it moves. VergeOS plugs in as a Rancher node driver, so cluster provisioning works through the same UI the team already uses every day.
The hardest part of a platform migration is what the operations team has to relearn. Rancher continuity removes that part of the cost.
Three Helm charts. One Cluster Repository.
VergeOS publishes three Helm charts from a single Cluster Repository on the verge-io GitHub. One repository registration in Rancher pulls the charts and pins them to verified upstream versions. There is no fork. There is no proprietary distribution. The cluster is vanilla upstream Kubernetes with VergeOS providing storage, network, and lifecycle services through the standard interfaces every other distribution uses.
Provisions persistent volumes from VergeOS storage. No overlay storage system required.
Networking, load balancers, and node lifecycle events through the standard Kubernetes interface.
Add and remove cluster nodes automatically based on pod scheduling pressure. Standard CA project.
The verge-io repository registered as a Rancher ClusterRepo. One registration brings the node driver into Rancher and pins all three charts to verified upstream versions. No catalog drift to manage.
Pick your starting position.
Every customer enters this decision from a different place. The integration meets each scenario at the natural starting point. No customer has to rebuild what is already working.
VMware + Rancher
The easy path. Rancher is already running cluster lifecycle. VergeOS replaces vSphere underneath. The cluster object is unchanged. The migration is a node-by-node rolling replacement.
VMware + Tanzu
The TAP reframe. Tanzu Application Platform is end-of-life. Tanzu Kubernetes Grid clusters migrate onto Rancher with VergeOS replacing the vSphere layer. One platform contract replaces three.
Bare metal
The new build. No hypervisor yet, no Rancher yet. VergeOS installs directly on hardware. Rancher comes with it. First Kubernetes cluster lights up the same afternoon.
Your decision window.
Where are you on a Tanzu or VMware Kubernetes decision?
Zoom poll launches now. The Tanzu wind-down dates we just covered set the clock for everyone in the first two answers.
From assembled to integrated.
The classic architecture stitches three independent systems together with brittle glue code. The integrated architecture runs all three from a single code base with a single API. The operations math runs differently on the second one.
Three systems, one workload
- Three vendor contracts and three renewal cycles
- Three patch schedules and three maintenance windows
- Three support tickets when one workload breaks
- Three teams to staff, or one team that owns three runbooks
One system, one workload
- One platform contract and one renewal
- One patch schedule applied to the full stack
- One support call when something breaks
- One operations team owns one platform
Validated at NGAMING / Nesine.
Production Kubernetes at scale on a regulated sports-betting platform. Twelve months in production. The first reference deployment is already running real transaction load through the integrated platform.
The portability story is the part that survived the architectural review. The cluster object is the same upstream Kubernetes shape every other team in the industry already uses.
What David will show.
One focused workflow, end to end. David provisions a fresh Kubernetes cluster from inside the Rancher UI, on top of VergeOS, exercising the VergeOS UI extension and the Rancher node driver. No second console. No slides over the top. The whole motion runs through the management plane teams already know.
Rancher with the VergeOS UI extension installed
The standard Rancher cluster manager. The VergeOS UI extension surfaces the platform inside Rancher as a registered cluster target. Nothing custom to learn.
Create a new cluster against VergeOS
Pick the VergeOS node driver, set the node template, click Create. The Rancher node driver calls the VergeOS API directly. No forked Kubernetes, no proprietary CRDs, no bolt-on operators.
Watch the cluster come up ready
Nodes provision through the driver. The three upstream Helm charts wire in from the Cluster Repository on the way up. The cluster lands in Rancher ready for workloads. Under three minutes from click to running.
The platform claim hinges on two things working without ceremony — Rancher really being the management plane, and the integration really shipping as standard upstream Kubernetes. The cluster-create flow puts both on the screen in one motion.
Architect Office Hours with David.
Five 45-minute sessions with David — the engineer who built the Kubernetes integration — in the two weeks after May 20. Qualified prospects only. Nobody else can put you in a room with the person who wrote the code.
Private-message Aaron Richman in the Zoom chat right now, or email [email protected] after the call. First five qualified prospects in.
Test the platform claim.
Five questions any VMware shop should ask before signing the next renewal. The answers tell you whether the platform stays integrated or quietly splits back into three control planes a year after the deal closes.
Does the Kubernetes integration ship as upstream Helm charts?
Or as a forked distribution with proprietary CRDs that have to track every upstream release on the vendor’s timeline?
Does Rancher manage cluster lifecycle the same way it does today?
Or does the platform require a new console, a new RBAC model, and a new operator training cycle?
Do snapshots apply to VMs and namespaces with the same policy?
Or does the platform run two snapshot subsystems and ask the operations team to keep their policies in sync by hand?
Does the storage layer use vendor CSI drivers or platform-native volumes?
The CSI overlay is the giveaway that storage is still a separate system pretending to be integrated.
Is the contract one platform contract or three stacked vendor agreements?
Procurement reveals the architecture. Three vendors on the invoice means three vendors on the support call.
What helps next.
What would be most useful from VergeIO after this session?
Zoom poll launches now. Answers route directly into the right-fit follow-up sequence before we move into live Q&A.
The recording goes to every registrant on May 21. The path to a hands-on evaluation runs through three short conversations. Each one is reversible. Each one tells you something the next one needs.
Read the white paper
Twelve sections, the full architectural argument. Three-tax model, three-chart integration, the operations math. Fourteen-minute read.
Book a 30-minute briefing
David walks your environment. Where Rancher sits today. What the Helm install looks like in your topology. No commitment.
Run a 90-day proof of concept
Full platform. Your hardware or ours. No charge. The data at the end of ninety days settles the architectural argument.
Pick a time below. Thirty minutes with Aaron Richman to map this onto your stack — your hypervisor, your Kubernetes distribution, your timeline. The right call for everyone who is not in line for an Architect Office Hours slot.
Three resources. One integrated story.
The white paper carries the architectural argument in full. The datasheet is the one-page anchor. The VMblog byline is the third-party voice for accounts that have already been pushed too hard on the lift-and-shift narrative.
Collapsing the Kubernetes Stack
Twelve sections. Three-Tax Model, Assembled vs Integrated, three-chart integration, three scenarios, stateful K8s resilience. Fourteen-minute read.
Kubernetes Without the VMware Tax
The flagship landing page. Hero stats, before/after architecture, four-step deployment, production validation, evaluation framework, FAQ.
When Storage, Virtualization, and Kubernetes Share One API
George Crump byline. Frames the three-API status quo as twenty years of accumulated integration tax. The migration motion becomes optional, not mandatory.