OpenShift vs Standard CNCF Kubernetes on OpenStack: Architecture & TCO
By Alberto Estévez • Updated August 14, 2026 • 3 min read
A technical and financial comparison for infrastructure directors and platform leads: comparing full-stack Kubernetes distributions against standard CNCF Kubernetes running on OpenStack.
1. Architectural Paradigm: Opinionated Distribution vs Standard API
Red Hat OpenShift (and its open-source upstream project OKD) packages Kubernetes with a specialized ecosystem: Red Hat Enterprise Linux CoreOS (RHCOS), OpenShift-specific SecurityContextConstraints (SCCs), specialized Routes, and custom build pipelines (S2I). While this creates an integrated stack, it requires specific manifest conventions.
In contrast, running standard CNCF-conformant Kubernetes on OpenStack preserves standard upstream APIs: standard Ingress controllers (Traefik, NGINX), standard Pod Security Standards (PSS), and standard OCI container runtimes.
2. The Economics: Per-Core Licensing vs Per Managed Resource
The financial model of enterprise Kubernetes distributions is traditionally structured around per-core or per-vCPU subscription pairs. As hardware nodes scale to high core counts (64 to 128 cores per socket), the licensing cost scales with core count even if cluster utilization remains modest.
Upstream KubernetesIngress, Pod Security Standards, OCI runtime; standard CNCF binaries
decoupled: rolling updates, no OS reimaging
Standard enterprise Linuxhost image of your choice
Nova VMsnative, standard flavors, beside the clusters
VMs stay plain OpenStack instances
Per managed cluster or resource, core-agnostic
OpenStackthe same infrastructure underneath both
3. Day-2 Operations & OS Immutability
OpenShift clusters couple the node operating system (RHCOS) with the Kubernetes control plane. In contrast, running standard Kubernetes on OpenStack decouples the underlying Linux host image from cluster lifecycle automation, allowing rolling version updates without mandatory OS reimaging.
Standard CNCF Kubernetes ensures that third-party Helm charts and open-source operators deploy without modifying security contexts or translating standard Kubernetes Ingress resources into OpenShift-specific Route definitions. Platform teams can use standard ArgoCD or Flux GitOps pipelines seamlessly.
5. Architectural Transition Strategy
Transitioning from OpenShift to standard Kubernetes involves migrating OpenShift Routes to standard Ingress manifests, moving persistent volume claims to OpenStack Cinder CSI, and deploying standard Helm releases.
For a full overview of how edgeContinuum delivers managed upstream Kubernetes on private infrastructure, explore our OpenShift alternative platform. For the component level of standard Kubernetes on OpenStack, the cloud controller manager, Cinder CSI, the CNI and the provisioning routes, see the Kubernetes on OpenStack architecture guide.
Evaluate your Kubernetes platform architecture with us
Analyze your cluster footprint, core licensing overhead, and migration path to standard CNCF Kubernetes on OpenStack.
Is OpenShift worth the cost compared with standard Kubernetes?
It depends entirely on whether you would build what it bundles. OpenShift ships an integrated developer experience, an opinionated security posture, an operator catalog and a support relationship, and for organizations that would otherwise assemble those from parts, the per-core cost can be defensible. It stops being defensible when you are paying per core for workloads that do not need the bundle, when the estate grows denser and the bill grows with it, or when the opinionated pieces are ones you have already solved another way.
What do we lose by moving from OpenShift to standard CNCF Kubernetes?
Mostly convenience and defaults, not capability. You lose Routes, DeploymentConfigs, ImageStreams, the integrated build system and OpenShift's SCC model, and each has a standard equivalent: Ingress or Gateway API, Deployments, an external registry, an external CI system, and Pod Security Admission. You also lose the single support contract covering the whole stack. What you gain is a smaller surface with no proprietary APIs, so manifests stay portable and the licence stops scaling with your core count.
Is OKD a viable OpenShift replacement?
Technically yes, since OKD is the community distribution OpenShift is built from and behaves very similarly. The question is operational rather than technical: OKD comes without the support relationship, has a different release cadence, and leaves you owning upgrades and incident response for a fairly complex platform. Teams that choose OKD successfully tend to have real Kubernetes depth already. Teams choosing it purely to avoid the licence usually discover they replaced a cost line with a staffing line.
How does per-core pricing compare with per managed resource?
They scale on different axes, which is what makes the comparison awkward and important. Per-core pricing grows with hardware density, so consolidating workloads onto larger hosts increases the bill even though it improves utilisation. Per managed resource counts the things the platform manages, a cluster, a database, a virtual machine, so denser hardware reduces cost per workload. The crossover point arrives sooner than most teams expect, and it arrives faster still if you run large nodes for memory-heavy workloads.
Can we run OpenShift workloads on standard Kubernetes without rewriting them?
Standard container workloads move essentially unchanged, since they are just pods. The work is in the OpenShift-specific objects around them: Routes become Ingress or Gateway API resources, DeploymentConfigs become Deployments, ImageStreams become plain image references, and BuildConfigs move to your CI system. Anything relying on SCCs needs mapping to Pod Security Admission. For most applications this is a mechanical conversion plus testing rather than a rewrite, and it is usually done namespace by namespace.
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Preferences
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
