OpenShift vs Kubernetes: what OpenShift adds, what it costs and how to choose

How are OpenShift and Kubernetes related?

Kubernetes was accepted into the CNCF in March 2016 and graduated in March 2018. Its documentation says Kubernetes is not a traditional, all-inclusive PaaS: it provides deployment, scaling and load balancing, then stops on purpose. It builds no application, dictates no logging or monitoring and provides no machine management.

OpenShift Container Platform (OCP) builds on that core. Red Hat's CLI documentation calls it a certified Kubernetes distribution, and the CNCF conformance repository holds a Kubernetes 1.35 entry for OCP 4.22. The CNCF says conformance gives interoperability from one Kubernetes installation to the next, so kubectl and standard manifests work on OpenShift.

OpenShift trails upstream. OCP 4.22 was released on 9 June 2026 and uses Kubernetes 1.35 with the CRI-O runtime, while the upstream project's latest minor release is 1.37.

The community build is OKD, which its project calls the community distribution of Kubernetes that powers OpenShift. Since 4.16 its nodes and base image come from CentOS Stream rather than Fedora CoreOS, and OKD 5.0, published on 17 September 2026, runs on CentOS Stream CoreOS 10 with Kubernetes 1.36. Red Hat's subscription guide lists four self-managed editions and four managed services, and OKD is in neither list. Use OKD to learn and test; buy OpenShift when you need a support contract.

What does OpenShift add on top of Kubernetes?

The table names the real components in OCP 4.22, in the order a platform team would otherwise have to decide them.

Two caveats sit behind the table. The first is edition: OpenShift Kubernetes Engine (OKE), the entry self-managed edition, is the same binary as OCP with a subset of features, and it leaves out Serverless, Service Mesh, Pipelines, Source-to-Image, Platform Logging and the developer console. The second is age: layered content, including the Operators you add to a cluster, maintains an independent life cycle from OpenShift itself. Only monitoring among the observability components follows the platform's release cycle.

Several cells hide details that decide real projects. On Kubernetes, Operators are optional extras; on OpenShift the platform itself is a set of cluster Operators, and optional add-ons are managed by Operator Lifecycle Manager. OLM v1 is generally available in 4.22 but its procedures are CLI-based and the console's software catalog does not display it yet. The registry is another detail: on bare metal, Nutanix and vSphere the Image Registry Operator installs as Removed, because those platforms have no shareable object storage, and you must switch it to Managed and configure storage. Builds is based on the Shipwright project, with Source-to-Image and Buildah strategies.

The delivery tools are open-source projects with Red Hat packaging. Red Hat describes Tekton pipelines as portable across Kubernetes distributions, and OpenShift GitOps is Argo CD packaged as an Operator. For Knative, see how serverless computing works. OpenShift Virtualization runs virtual machines beside containers in the same cluster, which is why it appears in VMware alternatives.

How do nodes and updates work?

Every OpenShift 4 node runs RHCOS, the only supported operating system for all node types in 4.22, and CRI-O is the only container engine. RHCOS is deliberately locked down: /usr is read-only, and /etc, /boot and /var are meant to be changed only by the Machine Config Operator (MCO). You declare node changes as MachineConfig objects. To apply one, the MCO drains each affected node, applies the change and reboots it, except for a short list such as SSH key changes and pull secret updates.

An update uses the same machinery. The Cluster Version Operator (CVO) asks the OpenShift Update Service which versions are valid from the current one, pulls the target release image, updates the control plane's Operators in stages and then lets the MCO update the operating system of every node. A new release enters the candidate channel, moves to fast and later to stable, and the delay before the first updates to a new minor reach stable is generally 45 to 90 days.

oc adm upgrade                      # current version and available updates
oc get clusterversion               # state of the running update
oc get machineconfigpool            # node rollout per pool
oc patch machineconfigpool/worker --type merge -p '{"spec":{"paused":true}}'   # hold node reboots

Pausing the worker pool before a machine config change defers the reboots to your change window; set paused back to false and the nodes roll into the new configuration.

What you give up for this is choice and speed:

• Node choice. One operating system, one container engine, and no hand-edited nodes: Red Hat does not support altering /usr, and the other writable paths are meant to be changed only by the Machine Config Operator.
• Policy objects. Red Hat says not to modify the default SCCs; you create your own instead.
• Gateway API versions. The Ingress Operator manages the Gateway API CRDs, and a cluster that already carries other versions must match the supported one before it can update.
• Release pace. 4.22 runs Kubernetes 1.35 while upstream is on 1.37, and a node reboot is part of most platform changes.

Routes, Ingress or Gateway API?

The Kubernetes Ingress API is generally available but frozen: it is no longer being developed, and the project recommends Gateway API, which is an add-on rather than part of core Kubernetes. OpenShift handles all three objects.

A Route is an OpenShift-specific object. Red Hat describes it as doing what Ingress does, with more advanced TLS termination options and traffic splitting, and specific to OpenShift. If you create an Ingress, the Ingress Operator manages a Route for it. Gateway API traffic management has been generally available since 4.19. You enable it by creating a GatewayClass with the one controller name OpenShift accepts, and the Ingress Operator then installs a lightweight Istio control plane based on Red Hat OpenShift Service Mesh in openshift-ingress:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: openshift-default
spec:
  controllerName: openshift.io/gateway-controller/v1

On bare metal and vSphere the same page says you must supply a load balancer controller such as MetalLB and map DNS yourself. A sound default for new applications is a standard Ingress or Gateway API object, because it also runs on other platforms; reach for a Route when you want OpenShift's features and accept that the manifest will not travel. Neither object is an API management layer. Authentication, quotas and versioning are covered in enterprise API development.

What does plain Kubernetes leave to you?

Plain Kubernetes is a set of building blocks, and each of the following is a decision you make and an upgrade you own:

• Pod network. kubeadm creates a cluster in which you must deploy a CNI add-on before DNS starts. OpenShift ships OVN-Kubernetes as its default pod network.
• Ingress controller. Ingress NGINX, one of the most popular community controllers, was retired in March 2026: no further releases, bug fixes or security updates. SIG Network recommends moving to Gateway API or another controller.
• Pod security. Pod Security Admission is built in, but its defaults are all privileged, so nothing is enforced until you configure the controller or label namespaces.
• Network isolation. A NetworkPolicy only works if your network plugin enforces it, and with no policy every pod can talk to every other.
• Image trust. The ImagePolicyWebhook admission controller hands the decision to a backend you run, and it is not among the plugins enabled by default.
• Logging, monitoring, node patching and upgrades. Kubernetes dictates no logging or monitoring and provides no machine maintenance, and upstream supports each minor for only about 14 months.

Distributions and managed services make some of the choices for you. K3s bundles containerd, Flannel, CoreDNS and Traefik. RKE2 sets defaults aimed at passing the CIS Kubernetes Benchmark and supports FIPS 140-2. On the clouds, the gap has narrowed. In standard mode EKS manages the control plane, and EKS Auto Mode extends that to nodes, with EKS Capabilities adding managed Argo CD. AKS Automatic handles node management, scaling, security, monitoring and upgrades, with AKS Standard as the do-it-yourself option. For a cloud-native team the fair comparison is OpenShift against EKS Auto Mode or AKS Automatic plus whatever you add, not against bare kubeadm.

How do the security defaults compare?

OpenShift's defence is mostly a stricter default for who a pod runs as and what it may do. Upstream Kubernetes gives you the same building blocks and leaves them off.

Neither platform replaces the rest of the supply chain. Scan every image in CI, pin versions and review dependencies as described in secure coding best practices.

Why does a workload that runs on Kubernetes fail on OpenShift?

A classic migration failure is not an API difference; it is an image that assumes root. By default OpenShift runs containers with an arbitrarily assigned user ID, which Red Hat says limits what a process that escapes a container can do to the node. The admission plugin reads the project's openshift.io/sa.scc.uid-range annotation and uses the minimum of that range as the default UID, a number that differs in every project. The container user is always in the root group.

Red Hat's knowledge base shows the shape of the first error. The values below are illustrative:

pods "web-7d9c4f6b8-" is forbidden: unable to validate against any security
context constraint: [..., provider restricted-v2: .containers[0].runAsUser:
Invalid value: 1000: must be in the ranges: [1000650000, 1000659999], ...]

The fix belongs in the image and the manifest. Red Hat's guidance is that files and directories written by the process must be owned by the root group and be group read-write, executables need group execute, and processes must not listen on ports below 1024. In the Dockerfile:

# ...your FROM and build steps above
RUN mkdir -p /opt/app/data \
 && chgrp -R 0 /opt/app \
 && chmod -R g=u /opt/app
USER 1001
EXPOSE 8080

The manifest then leaves the user ID to the platform and still passes the upstream restricted level, so it runs on both:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: web
          image: registry.example.com/team/web:1.4.2
          ports:
            - containerPort: 8080
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]
          volumeMounts:
            - name: tmp
              mountPath: /tmp
      volumes:
        - name: tmp
          emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

To see what the platform did, read the project's range and the SCC that admitted a pod:

oc get namespace web -o jsonpath='{.metadata.annotations.openshift\.io/sa\.scc\.uid-range}{"\n"}'
oc get pod web-7d9c4f6b8-x2k4p -o jsonpath='{.metadata.annotations.openshift\.io/scc}{"\n"}'

How long is each version supported, and what does year two look like?

Upstream Kubernetes releases about three times a year and supports each minor for about 14 months: 12 months of standard support and two in maintenance mode. As of October 2026 the maintained minors are 1.35 to 1.37, and 1.34 is in maintenance mode until 27 October 2026. Red Hat aims for a new OpenShift minor every four months and supports each one for longer.

A worked example from Red Hat's life cycle data: OCP 4.20, released on 21 October 2025, uses Kubernetes 1.33. Upstream stopped patching 1.33 on 28 June 2026. Red Hat keeps 4.20 in maintenance support until 21 April 2027 and, with Extended Update Support Terms 1 and 2, until 21 October 2028. Throughout maintenance support it releases fixes for Critical, Important and Moderate CVEs with a CVSS score of 7.0 or higher. That is the real trade: you give up the newest Kubernetes and gain a longer window per version.

Year two is about cadence, not installation. Four habits keep an OpenShift estate healthy:

1. Pick a channel and a date. Decide whether you follow the stable channel through every minor release or use the EUS channels for Control Plane Only updates between even-numbered releases, and put the dates in the calendar.
2. Track the add-ons separately. Each layered product has its own life cycle, so check it before every platform update.
3. Treat node changes as rollouts. Most machine config changes reboot nodes; schedule them like deployments.
4. Watch what Red Hat deprecates. For example, DeploymentConfig has been deprecated since 4.14; use Deployment.

Plain Kubernetes has its own cadence, and changes such as the Ingress NGINX retirement above arrive as project announcements. Looking ahead, Red Hat's roadmap notice, updated in December 2025, says it intends to release OpenShift 5 between the end of 2026 and the beginning of 2027, with support for both RHEL CoreOS 9 and 10. Treat that as an intention, not a commitment, and plan the 4.22 upgrade path around Red Hat's published life cycle.

What do managed OpenShift and the subscription cost?

Red Hat sells OpenShift self-managed and as four managed cloud services. Red Hat's pricing page lists who runs and bills what (as of October 2026):

AWS describes ROSA as jointly supported and operated by AWS and Red Hat, with Red Hat site reliability engineers handling cluster installation, maintenance and upgrades. Its cost has two parts: an hourly service fee per 4 vCPU of worker nodes (plus an hourly cluster fee for hosted control planes) and AWS infrastructure fees. Azure Red Hat OpenShift is jointly engineered, operated and supported by Red Hat and Microsoft, runs in your Azure subscription and appears on your Azure bill, and comes in a standard architecture and a hosted control plane one. So "ROSA vs EKS" is "OpenShift operated by SREs" against "Kubernetes with a managed control plane", and EKS's own automatic mode narrows the operational gap.

Self-managed OpenShift is sold in four editions, each including the one below it (per the same pricing page):

The subscription guide sets the unit. A core-pair is 2 physical cores or 4 vCPU; on a hyperscaler, 4 vCPU is always one core-pair, and hyperthreading does not change the physical count. Only compute nodes are counted. Control plane nodes are included, and so are infrastructure nodes that run no user applications, though they still cost hardware. You also choose Standard (8x5) or Premium (24x7) support, and the alternative to core-pairs is a bare-metal node subscription, which is the only option for Virtualization Engine. As an illustration, six worker VMs of 8 vCPU each are 48 vCPU, which is 12 core-pairs; three control plane VMs add none.

Red Hat does not publish list prices for the self-managed editions; its pricing page says only that pricing varies with sizing and subscription choices. Get a quote before you compare. Kubernetes has no licence fee, so its cost sits in engineering time, the tools you integrate and any support contracts for them, plus the cloud provider's own per-cluster and per-node fees. A fair comparison counts all of it over three years.

How do you decide, and can you run both?

Running both is realistic if you keep manifests portable. Deployments, StatefulSets, Services, NetworkPolicies, PersistentVolumeClaims and Ingress or Gateway API objects are standard Kubernetes. These are OpenShift-only and should live in one overlay: Route, BuildConfig, ImageStream and DeploymentConfig objects, and SCC grants. Write pods for the restricted level, as in the manifest above, and your workloads pass on both.

How do you move between OpenShift versions and Kubernetes flavours?

Within OpenShift 4, a minor update is an in-place operation run by the CVO. From OpenShift 3 it is not: Red Hat's documentation says an OpenShift 3 cluster cannot be upgraded to 4, so you start a new OpenShift 4 cluster and move the workloads. The cluster's DNS domain changes, so decide early whether clients keep the old host names through a reverse proxy or a route for the old name. A bank's move from OpenShift 3 to 4 was a migration to a new platform, not an update, and cut production over in one short change window.

Between Kubernetes flavours, check these in order:

1. Storage classes and CSI drivers, which differ by platform.
2. Ingress class, annotations and certificates; convert controller-specific annotations to Gateway API or Routes.
3. Pod security: admission labels on one side, SCCs on the other.
4. Image registry, pull secrets and signing policy.
5. Operators and CRDs, including their versions and life cycles.
6. Monitoring, alert rules and log forwarding.
7. DNS names, load balancers and network policies.

Plan the cutover and the way back as described in cloud migration strategy.

A platform decision you can make this month

1. List workloads that run as root, hard-code a UID, write outside volumes or listen below port 1024, and run each with an arbitrary UID in group 0.
2. Write down every item in the "what plain Kubernetes leaves to you" list that you would have to own, with a named owner for each.
3. Price both options over three years: subscription core-pairs or cloud fees, infrastructure, engineering time and support contracts.
4. Check the life-cycle fit: who upgrades, how often, and who tests each add-on.
5. Pilot one real workload on each platform with the restricted-level manifest, and measure the effort.
6. Decide, keep OpenShift-only objects in one overlay, and record a review date.

If you want an outside view, our cloud readiness assessment ends with a recommendation between OpenShift and managed Kubernetes and the trade-offs behind it.