Most OpenShift shortlists compare Kubernetes distributions and miss what teams actually bought: a router, a registry, a console, builds, operators and one number to call. This guide sets out the routes teams take, what each one keeps, and the questions that decide between them.
Two reasons come up. The first is the meter: OpenShift Kubernetes Engine, Container Platform and Platform Plus are subscribed per 2 cores or 4 vCPUs across every compute node of every cluster, or per bare-metal socket pair of up to 64 cores, and compact three-node clusters get no special pricing (Red Hat subscription guide). Denser hardware and more clusters reprice the platform. The second is the opinion: Routes, SecurityContextConstraints, the built-in OAuth server, ImageStreams and Source-to-Image builds make OpenShift productive, and also make manifests and habits specific to it.
So the useful first question is which parts of the bundle your teams actually use. If it is only Kubernetes, any route below will do. If it is the whole platform, the shortlist has to be judged on that.
SUSE Rancher Prime manages clusters across infrastructure you already have, with Harvester for virtual machines; its subscriptions are sold per 2 cores or 4 vCPUs, or per socket pair, much like OpenShift’s. Canonical Kubernetes is supported through Ubuntu Pro, priced per machine. Kubermatic (KKP) and Mirantis k0rdent both have open source editions with commercial ones on top, and Spectro Cloud Palette and Sidero Omni meter by core-hours and by node. vSphere Kubernetes Service is included in VMware Cloud Foundation, which only makes sense if you are staying on VCF. These change the distribution and the meter; most stop at Kubernetes, so databases, VMs and tenancy stay yours to source.
OKD is the community distribution OpenShift is built from, now on its 5.0 line over CentOS Stream CoreOS, with community support only. Upstream Kubernetes with Cluster API is the leaner baseline: you choose the ingress, registry, CI and console yourself. Both remove the licence. Neither removes the work: upgrades, certificates, etcd, operator lifecycle and the on-call behind them move to your platform team. The Kubernetes on OpenStack architecture guide lists what a self-built stack contains.
This is the route that keeps what teams liked about OpenShift and drops what they did not: the per-core meter, the platform-specific APIs and the work of running it. OpenStack runs the virtual machines and gives clusters their compute, block storage and load balancers; edgeContinuum adds the platform on top, connected through OpenStack’s standard APIs:
What you keep from OpenShift: one console, a service catalog and a vendor who owns upgrades and day-two operations. What you drop: per-core licensing, since the subscription counts managed resources (a cluster, a database, a VM), and platform-specific APIs, so manifests and Helm charts stay portable. Image builds and the registry stay in the CI and registry you already run.
It fits best when several teams or clients share the platform, VMs run beside the clusters, and the infrastructure has to stay on-premises, sovereign or air-gapped. See how each OpenShift piece maps, or start a free trial on your own OpenStack.
EKS and GKE charge $0.10 per cluster per hour plus the compute underneath, and AKS has a free control plane tier. If the bundle is what you want, OpenShift itself runs as a managed service: ROSA, operated with AWS, and ARO, operated with Microsoft. Both remove the hardware question. They are usually the wrong answer when data residency, latency to physical sites or steady-state cost dominate, which is often why the clusters were on-premises in the first place.
Move to plain Kubernetes and four things become your problem.
None of these is a reason to stay. They are the difference between a comparison that holds up in month six and one that does not.
How much of the bundle do you use? Count Routes, S2I, Pipelines, Service Mesh, Serverless and the developer console. If it is three or more, price their replacements before the licence saving. edgeContinuum covers the console, catalog, databases and VMs; builds and the registry stay in your CI.
Where do VMs live? If OpenShift Virtualization carries a real VM estate, decide whether VMs stay on Kubernetes (Harvester, KubeVirt) or move to a virtualization platform beside the clusters. With edgeContinuum they run on OpenStack, beside the clusters, from the same console.
Who runs the platform? OKD and upstream move the work to your team. Commercial distributions keep the software with a vendor but leave operations with you. With edgeContinuum, upgrades, node pool scaling and failed-node remediation are done by the platform.
What does the meter count? Double the cores in a cluster and check what happens to the bill under each option. That one test separates per-core models from per-resource ones: with edgeContinuum the bill does not move, because it counts clusters, databases and VMs.
Several teams, VMs beside the clusters, little appetite to run the platform yourself and a meter that should not follow cores: that is the profile edgeContinuum is built for.
Managed, CNCF-conformant clusters with VMs and PostgreSQL beside them, priced per managed resource instead of per core. Bring your cluster inventory and renewal date, and our engineers will map it onto the platform.
