# OpenShift vs Kubernetes: what OpenShift adds, what it costs and how to choose > Kubernetes is the open-source orchestrator; OpenShift is Red Hat's supported distribution of it. What OpenShift adds, what it costs and how to choose. - URL: https://computese.com/openshift-vs-kubernetes/ - Author: Duong Quan Nguyen, CEO, Computese - Published: 2026-10-05 - Updated: 2026-10-09 - Topics: Cloud ## In short - Kubernetes is the CNCF-hosted orchestrator. OpenShift is Red Hat's conformant distribution of it, adding the node OS, updates, security defaults, registry, console, monitoring and developer tooling you would otherwise choose and wire together. - The price in flexibility: OpenShift 4.22 runs only on RHCOS with CRI-O, changes nodes through the Machine Config Operator, and starts containers with an assigned non-root UID, so images that expect root or port 80 fail until they are fixed. - OpenShift trails upstream (4.22 uses Kubernetes 1.35; upstream is at 1.37) but supports each minor for 18 months, or up to 48 with paid Extended Update Support on even-numbered releases. - Self-managed OpenShift is sold per core-pair (2 cores or 4 vCPU) of compute, with Standard or Premium support. ROSA, Azure Red Hat OpenShift, OpenShift Dedicated and IBM Cloud are the managed options. Kubernetes has no licence fee; running it has a cost. - Choose OpenShift for regulated, multi-team, on-premises or VM-plus-container estates that want one supported platform. Choose EKS, AKS or a lighter distribution when a cloud-native team already runs the tools. Standard manifests keep the choice reversible. Kubernetes is the open-source container orchestrator, a graduated project of the Cloud Native Computing Foundation (CNCF). OpenShift is Red Hat's distribution of it: the same conformant Kubernetes API, packaged with an operating system, update service, security defaults, registry, console and monitoring, and sold with support. The choice is between assembling a platform and buying one. This guide shows what OpenShift adds layer by layer, what it takes away, how the security defaults and support windows differ, what the managed versions and the subscription cost, and how to decide. Everything was checked against Red Hat, Kubernetes and cloud provider documentation in October 2026, when OpenShift Container Platform 4.22 and Kubernetes 1.37 were the current releases. If the real question is how to move a whole estate, start with [cloud migration strategy](https://computese.com/cloud-migration-strategy/); if the driver is leaving VMware, see [VMware alternatives](https://computese.com/vmware-alternatives/). ## How are OpenShift and Kubernetes related? Kubernetes was [accepted into the CNCF in March 2016 and graduated in March 2018](https://www.cncf.io/projects/kubernetes/). Its documentation says Kubernetes [is not a traditional, all-inclusive PaaS](https://kubernetes.io/docs/concepts/overview/): 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](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/cli_tools/openshift-cli-oc), and the CNCF conformance repository holds [a Kubernetes 1.35 entry for OCP 4.22](https://github.com/cncf/k8s-conformance/blob/master/v1.35/openshift/PRODUCT.yaml). The CNCF says [conformance gives interoperability](https://www.cncf.io/training/certification/software-conformance/) 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](https://access.redhat.com/product-life-cycles?product=Red%20Hat%20OpenShift%20Container%20Platform) and [uses Kubernetes 1.35 with the CRI-O runtime](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/release_notes/ocp-4-22-release-notes), while the upstream project's [latest minor release is 1.37](https://kubernetes.io/releases/). The community build is OKD, which its project calls [the community distribution of Kubernetes that powers OpenShift](https://github.com/okd-project/okd). Since 4.16 its nodes and base image come from [CentOS Stream rather than Fedora CoreOS](https://okd.io/docs/project/upgrade-notes/from-4-15/fcos-to-scos-migration/), and OKD 5.0, [published on 17 September 2026](https://github.com/okd-project/okd-web/blob/main/blog/2026/09-17-okd-5.0-release-notes.md), runs on CentOS Stream CoreOS 10 with Kubernetes 1.36. Red Hat's [subscription guide](https://www.redhat.com/en/resources/self-managed-openshift-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. | What a platform needs | Plain Kubernetes | OpenShift 4.22 | | ------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Node operating system | Not provided; no machine configuration or maintenance system | [Red Hat Enterprise Linux CoreOS](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/architecture/architecture-rhcos) (RHCOS) on every node, configured by the Machine Config Operator | | Cluster updates | Your tooling: kubeadm, a managed service or your own automation | The Cluster Version Operator and the OpenShift Update Service; one operation from the console or `oc adm upgrade` | | Add-on software | Manifests, Helm charts and operators you choose | Cluster Operators by default, plus Operator Lifecycle Manager and a software catalog (OLM v1 is generally available in 4.22, with CLI-only procedures) | | Image registry and builds | Kubernetes does not build your application; CI/CD is left to you | An integrated registry run by the Image Registry Operator, and Builds with Source-to-Image and Buildah | | Traffic into the cluster | Ingress (frozen) or Gateway API (an add-on), with a controller you pick | An Ingress Controller that uses HAProxy, Routes, and Gateway API since 4.19 | | Pod security | Pod Security Admission, which enforces nothing until configured | Security context constraints (SCCs), applied to every pod by default | | Tenancy | Namespaces | Projects, which map namespaces to authenticated users | | Monitoring | Not dictated | Prometheus, Alertmanager and Thanos Querier, deployed by default | | Delivery and services | Your choice of CI/CD, GitOps, mesh, serverless and VM tooling | Pipelines (Tekton), GitOps (Argo CD), Service Mesh, Serverless (Knative) and Virtualization, as add-on products with their own release cadences | | CLI and console | `kubectl` | `oc`, which does everything `kubectl` does and adds OpenShift objects, and a web console | 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](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/overview/oke-about) 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](https://access.redhat.com/support/policy/updates/openshift) from OpenShift itself. [Only monitoring](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/observability_overview/observability-overview) among the observability components follows the platform's release cycle. ![Two clusters side by side. On the left, five separate add-on boxes hang above the servers on individual cables, two plugs not yet inserted. On the right, the same five functions sit inside one block on the servers.](https://computese.com/images/blog/openshift-vs-kubernetes/two-clusters.8de0af90bb-1536.webp) *Both clusters offer the same functions; on the left each is a separate product to choose, install and keep compatible.* Several cells hide details that decide real projects. On Kubernetes, [Operators](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/operators/operators-overview) 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](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/extensions/extensions-overview) 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](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/registry/configuring-registry-operator), because those platforms have no shareable object storage, and you must switch it to Managed and configure storage. [Builds](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/builds_using_shipwright/overview-openshift-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](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/pipelines/about-pipelines), and [OpenShift GitOps](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/gitops/about-redhat-openshift-gitops) is Argo CD packaged as an Operator. For Knative, see [how serverless computing works](https://computese.com/the-future-of-serverless-computing-streamlining/). [OpenShift Virtualization](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/virtualization/about) runs virtual machines beside containers in the same cluster, which is why it appears in [VMware alternatives](https://computese.com/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](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/machine_configuration/machine-config-index) (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](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/updating_clusters/understanding-openshift-updates-1). ```bash 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. ![A registry cylinder sends a release image to a gear-shaped controller, which reaches three servers in a row. The left server has a tick, the middle one has a restart arrow, the right one waits.](https://computese.com/images/blog/openshift-vs-kubernetes/rolling-update.a1b8cba780-1536.webp) *The cluster pulls the release image and restarts its nodes in a rolling manner, instead of an administrator patching each machine.* 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](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/authentication_and_authorization/managing-pod-security-policies); 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](https://kubernetes.io/docs/concepts/services-networking/ingress/) is generally available but frozen: it is no longer being developed, and the project recommends [Gateway API](https://kubernetes.io/docs/concepts/services-networking/gateway/), 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](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/networking_overview/understanding-networking). If you create an Ingress, the Ingress Operator manages [a Route for it](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/ingress_and_load_balancing/routes). Gateway API traffic management has been [generally available since 4.19](https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/release_notes/ocp-4-19-release-notes). 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](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/ingress_and_load_balancing/configuring-gateway-api) based on Red Hat OpenShift Service Mesh in `openshift-ingress`: ```yaml 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](https://computese.com/the-future-of-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](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) before DNS starts. OpenShift ships [OVN-Kubernetes](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/networking_overview/understanding-networking) as its default pod network. - **Ingress controller.** Ingress NGINX, one of the most popular community controllers, was [retired in March 2026](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/): 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](https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/), so nothing is enforced until you configure the controller or label namespaces. - **Network isolation.** A [NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/) only works if your network plugin enforces it, and with no policy every pod can talk to every other. - **Image trust.** The [ImagePolicyWebhook](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) 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](https://kubernetes.io/releases/patch-releases/). Distributions and managed services make some of the choices for you. [K3s](https://docs.k3s.io/) bundles containerd, Flannel, CoreDNS and Traefik. [RKE2](https://docs.rke2.io/) 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](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html), and EKS Auto Mode extends that to nodes, with EKS Capabilities adding managed Argo CD. [AKS Automatic](https://learn.microsoft.com/en-us/azure/aks/what-is-aks) 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. | Control | Kubernetes 1.37 (upstream) | OpenShift 4.22 | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Policy model | [Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/): levels privileged, baseline and restricted, modes enforce, audit and warn | [SCCs](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/authentication_and_authorization/managing-pod-security-policies) decide per pod; [Pod Security Admission runs alongside](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/authentication_and_authorization/understanding-and-managing-pod-security-admission), enforcing privileged globally and using restricted for warnings and audits | | Out-of-the-box | All three modes default to privileged | Authenticated users get `restricted-v2`; the same reference calls `restricted-v3`, which adds Linux user namespaces, the most restrictive SCC of a new installation | | User ID | Set by the pod or image; the [restricted level](https://kubernetes.io/docs/concepts/security/pod-security-standards/) requires non-root | Assigned from the project's UID range; an explicit `runAsUser` outside it is rejected | | Capabilities | Restricted: drop `ALL`, add back only `NET_BIND_SERVICE` | `restricted-v2` drops all capabilities, lets a pod add `NET_BIND_SERVICE`, defaults seccomp to `RuntimeDefault` and forbids privilege escalation | | Granting exceptions | Namespace labels and admission configuration exemptions | Granting another SCC to a service account; project administrators cannot grant SCC use by default | | Network traffic | Allowed until a NetworkPolicy selects a pod | The [same default in user projects](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/network_security/network-policy), and a project template where you can add default policies | | Image signatures | No built-in check; ImagePolicyWebhook calls your backend | `ClusterImagePolicy` and `ImagePolicy` objects verify [sigstore signatures](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/nodes/nodes-sigstore-using), generally available since [4.20](https://docs.redhat.com/en/documentation/openshift_container_platform/4.20/html/release_notes/ocp-4-20-release-notes) | > [!WARNING] > SCCs and Pod Security Admission are two independent controllers on OpenShift, and a workload must satisfy both. On plain Kubernetes, Pod Security Admission is the only one, and its defaults are permissive, so a cluster that "has Pod Security Admission" may still enforce nothing. 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](https://computese.com/best-practices-for-secure-coding/). ## 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](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/images/creating-images), 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. | Symptom | Cause | Fix | | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Pod never created; the controller's events say `unable to validate against any security context constraint` and `runAsUser ... must be in the ranges` | The manifest or Helm values hard-code `runAsUser` (for example 1000) outside the project's range | Remove `runAsUser` and `fsGroup` from the pod spec and let the SCC assign them | | Container starts, then exits with a permission error on a path | The process runs as an arbitrary UID in group 0, and the directory is owned by root with no group write | In the image build, `chgrp -R 0` and `chmod -R g=u` the directories the process writes; write only to volumes | | Cannot bind port 80 or 443 | Red Hat's image guidance says processes must not listen on ports below 1024, because they do not run as a privileged user | Listen on 8080 and map the Service port 80 to `targetPort: 8080` | | Image declares `USER root` or a chart sets `runAsUser: 0` | The restricted SCC does not allow root | Rebuild with a numeric non-root `USER`; if a vendor image cannot change, review a dedicated service account for the `anyuid` SCC | | Source-to-Image build fails | An S2I image without a numeric `USER` fails by default | Declare a numeric `USER` in the builder image | [Red Hat's knowledge base](https://access.redhat.com/solutions/7069472) shows the shape of the first error. The values below are illustrative: ```text 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], ...] ``` ![Two pods approach a check-post. The pod carrying a large key waits in front of a lowered barrier arm. The pod carrying a small tag passes a raised arm and continues toward a server rack.](https://computese.com/images/blog/openshift-vs-kubernetes/admission-gate.ac1454ae83-1536.webp) *The check happens before the pod exists, so the fix is in the manifest and the image, not in the running container.* 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](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/images/creating-images). In the Dockerfile: ```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: ```yaml 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: ```bash 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"}' ``` > [!TIP] > Test before you migrate. Run the image with an arbitrary UID in group 0 and a read-only root filesystem: `podman run --rm --user 1000650000:0 --read-only --tmpfs /tmp -p 8080:8080 `. The UID is an example. If the image starts there, it has cleared the failure causes listed above. The `anyuid` SCC exists, but treat it as an exception approved per workload, not a namespace-wide fix. ## How long is each version supported, and what does year two look like? Upstream Kubernetes releases [about three times a year](https://kubernetes.io/releases/release/) and supports each minor for [about 14 months](https://kubernetes.io/releases/patch-releases/): 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](https://access.redhat.com/support/policy/updates/openshift) and supports each one for longer. | Platform | Standard window per minor | Longer option | | --------------------------------------------------------------------------------------- | -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Kubernetes (upstream) | About 14 months | None | | OpenShift Container Platform | 18 months from release: full support, then maintenance support | Extended Update Support on even-numbered minors: Term 1 adds 6 months (included with Premium, optional with Standard), Term 2 adds 12 and Term 3 adds 12, up to 48 months in total | | [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) | 14 months | 12 more months of extended support, at an additional cost per cluster hour | | [AKS](https://learn.microsoft.com/en-us/azure/aks/supported-kubernetes-versions) | The latest three generally available minors | Long-term support, which needs to be enabled: one year of community support plus one year of LTS | A worked example from Red Hat's [life cycle data](https://access.redhat.com/product-life-cycles?product=Red%20Hat%20OpenShift%20Container%20Platform): OCP 4.20, released on 21 October 2025, [uses Kubernetes 1.33](https://docs.redhat.com/en/documentation/openshift_container_platform/4.20/html/release_notes/ocp-4-20-release-notes). 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](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/building_applications/deployments); 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](https://access.redhat.com/articles/7134648), 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](https://www.redhat.com/en/technologies/cloud-computing/openshift/pricing) lists who runs and bills what (as of October 2026): | Service | Runs on | Managed by | Billed by | SLA | | --------------------------------------- | ---------------------------------------------------------- | --------------------- | ------------------------------------------------------ | ------ | | Red Hat OpenShift Service on AWS (ROSA) | AWS | Red Hat and AWS | AWS | 99.95% | | Azure Red Hat OpenShift | Azure | Red Hat and Microsoft | Azure | 99.95% | | Red Hat OpenShift Dedicated | Google Cloud (Red Hat's subscription guide also lists AWS) | Red Hat | Red Hat for OpenShift, Google Cloud for infrastructure | 99.95% | | Red Hat OpenShift on IBM Cloud | IBM Cloud | IBM | IBM | 99.99% | AWS describes [ROSA](https://docs.aws.amazon.com/rosa/latest/userguide/what-is-rosa.html) 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](https://learn.microsoft.com/en-us/azure/openshift/intro-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): | Edition | Includes, beyond the edition below | | ------------------------------- | ------------------------------------------------------------------------------------------------------ | | OpenShift Virtualization Engine | OpenShift Virtualization, VM hosting and a virtualization administrator console; virtual machines only | | OpenShift Kubernetes Engine | RHCOS and enterprise Kubernetes for container applications | | OpenShift Container Platform | Developer console, Serverless, Service Mesh, Pipelines and GitOps | | OpenShift Platform Plus | Advanced Cluster Management, Advanced Cluster Security, OpenShift Data Foundation Essentials and Quay | The [subscription guide](https://www.redhat.com/en/resources/self-managed-openshift-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? | If this describes you | Lean towards | Why | | ----------------------------------------------------------------------------------------------------- | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | Regulated estate, on-premises or in several sites, one vendor answerable for OS, platform and patches | OpenShift | One subscription covers RHCOS and the platform, with a published life cycle | | Many teams share clusters and you want non-root and tenancy guardrails by default | OpenShift | SCCs and projects apply without extra tooling | | You need VMs and containers on one platform, for example while leaving VMware | OpenShift | OpenShift Virtualization runs both in one cluster | | One cloud, a cloud-native team, ingress, CI and observability already in place | EKS or AKS | Managed control plane, cloud billing, newer Kubernetes minors sooner (AKS lists 1.37 as generally available in October 2026) | | You want upstream features as soon as they ship | Managed Kubernetes | OCP 4.22 runs Kubernetes 1.35 while upstream is on 1.37 | | Small team, one or two applications, edge or lab use | k3s or a managed service | A single binary; no subscription | | You want OpenShift without operating it | ROSA or Azure Red Hat OpenShift | Red Hat and the cloud provider operate the cluster | 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](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/cli_tools/openshift-cli-oc) 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](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/migrating_from_version_3_to_4/planning-migration-3-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](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/migrating_from_version_3_to_4/planning-considerations-3-4). 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](https://computese.com/work/banking-platform-migration/). 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](https://computese.com/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](https://computese.com/services/cloud-transformation/) ends with a recommendation between OpenShift and managed Kubernetes and the trade-offs behind it. ## Key terms - **Kubernetes distribution**: A packaged build of Kubernetes with an installer, chosen add-ons and usually vendor support. OpenShift, RKE2 and k3s are examples. - **OKD**: The community distribution of Kubernetes that powers OpenShift. OKD 5.0 (September 2026) runs on CentOS Stream CoreOS 10 and Kubernetes 1.36. It is not one of the editions in Red Hat's subscription guide. - **Security context constraint (SCC)**: An OpenShift API object that sets what a pod may do: user ID, capabilities, host access, volume types, SELinux and seccomp. Authenticated users get restricted-v2 by default. - **Pod Security Admission**: The built-in Kubernetes admission controller that applies the Pod Security Standards (privileged, baseline, restricted) to a namespace in enforce, audit or warn mode. Its built-in default for every mode is privileged. - **Red Hat Enterprise Linux CoreOS (RHCOS)**: The operating system OpenShift 4.22 supports on every node. It is managed from the cluster, with a read-only /usr and transactional updates delivered as container images. - **Machine Config Operator (MCO)**: The OpenShift Operator that configures and updates node operating systems from MachineConfig objects. To apply a change it drains each affected node and reboots it. - **Cluster Version Operator (CVO)**: The Operator that moves an OpenShift cluster to a target release image, checking the OpenShift Update Service for safe update paths and then rolling out each cluster Operator in stages. - **Route**: An OpenShift object that exposes a Service to traffic from outside the cluster. It does what Ingress does, adds TLS options and traffic splitting, and exists only on OpenShift. - **Extended Update Support (EUS)**: A paid add-on for even-numbered OpenShift minor releases. Term 1 adds six months after maintenance support; Terms 2 and 3 add twelve months each, for up to 48 months in total. - **Core-pair**: The billing unit for self-managed OpenShift: 2 physical cores or 4 vCPU on compute nodes. Control plane nodes are included, and so are infrastructure nodes that run no user applications. ## Common questions ### Is OpenShift just Kubernetes with a user interface? No. The console is one part. OpenShift also supplies the node operating system, a cluster-managed update path, Operators for the platform's own services, security context constraints, a registry, builds, monitoring and (depending on edition) pipelines, GitOps, a service mesh and virtualization. The Kubernetes API underneath is the same, and Red Hat's CLI documentation says kubectl works. ### What is the difference between OKD and OpenShift? OKD is the community distribution that OpenShift is built from. OpenShift Container Platform is the Red Hat product, sold by subscription with support and a published life cycle. Red Hat's subscription guide lists OpenShift editions and managed services, and OKD is not among them. ### Can I run my Kubernetes workloads and Helm charts on OpenShift unchanged? Usually the API objects apply unchanged, but the pods must pass OpenShift's default security context constraint. Images that run as root, hard-code a runAsUser outside the project's range, write outside volumes or listen on a port below 1024 fail until they are rebuilt. Test with an arbitrary UID in group 0 before you migrate. ### Is OpenShift better than EKS or AKS? It depends on what you want to buy. EKS and AKS manage the Kubernetes control plane for you, and their automatic modes extend that to nodes and some add-ons. OpenShift is a larger, opinionated platform that also runs on-premises and in several clouds, with one vendor supporting the operating system and platform. ROSA is OpenShift operated jointly by Red Hat and AWS. ### What is the difference between an OpenShift Route and a Kubernetes Ingress? A Route is an OpenShift object that offers more TLS options and traffic splitting but works only on OpenShift. An Ingress is the standard Kubernetes object; on OpenShift the Ingress Operator manages a Route for it. Gateway API has been generally available on OpenShift since 4.19. ### How long is each OpenShift version supported? Each minor version gets 18 months from release across full and maintenance support, under Red Hat's published policy as of October 2026. Even-numbered minors can add Extended Update Support, which brings the total to 36 months with Terms 1 and 2 and 48 months with Term 3. Red Hat aims for a new minor every four months. ### Can I upgrade OpenShift 3 to OpenShift 4? No. Red Hat's documentation says an existing OpenShift 3 cluster cannot be upgraded to 4. You install a new OpenShift 4 cluster and move the workloads, and you plan the DNS change because the new cluster has a different domain. ## Sources 1. [Kubernetes: project maturity](https://www.cncf.io/projects/kubernetes/), Cloud Native Computing Foundation 2. [Kubernetes overview: what Kubernetes is not](https://kubernetes.io/docs/concepts/overview/), Kubernetes documentation 3. [OpenShift CLI (oc), OpenShift Container Platform 4.22](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/cli_tools/openshift-cli-oc), Red Hat Documentation 4. [Certified Kubernetes conformance entry: OpenShift Container Platform on Kubernetes 1.35](https://github.com/cncf/k8s-conformance/blob/master/v1.35/openshift/PRODUCT.yaml), CNCF (k8s-conformance repository) 5. [Software conformance (Certified Kubernetes)](https://www.cncf.io/training/certification/software-conformance/), Cloud Native Computing Foundation 6. [OpenShift Container Platform 4.22 release notes](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/release_notes/ocp-4-22-release-notes), Red Hat Documentation 7. [Product Life Cycles: Red Hat OpenShift Container Platform](https://access.redhat.com/product-life-cycles?product=Red%20Hat%20OpenShift%20Container%20Platform), Red Hat Customer Portal 8. [Kubernetes releases](https://kubernetes.io/releases/), Kubernetes documentation 9. [Kubernetes release cycle](https://kubernetes.io/releases/release/), Kubernetes documentation 10. [OKD: The Community Distribution of Kubernetes that powers Red Hat's OpenShift](https://github.com/okd-project/okd), OKD project (GitHub) 11. [Node operating system changes to SCOS](https://okd.io/docs/project/upgrade-notes/from-4-15/fcos-to-scos-migration/), OKD project 12. [OKD 5.0 release notes](https://github.com/okd-project/okd-web/blob/main/blog/2026/09-17-okd-5.0-release-notes.md), OKD project (GitHub) 13. [Self-managed Red Hat OpenShift subscription guide](https://www.redhat.com/en/resources/self-managed-openshift-subscription-guide), Red Hat 14. [Red Hat OpenShift editions and pricing](https://www.redhat.com/en/technologies/cloud-computing/openshift/pricing), Red Hat 15. [About OpenShift Kubernetes Engine](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/overview/oke-about), Red Hat Documentation 16. [Red Hat OpenShift Container Platform life cycle policy](https://access.redhat.com/support/policy/updates/openshift), Red Hat Customer Portal 17. [Red Hat Enterprise Linux CoreOS (RHCOS)](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/architecture/architecture-rhcos), Red Hat Documentation 18. [Machine configuration overview](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/machine_configuration/machine-config-index), Red Hat Documentation 19. [Understanding OpenShift updates](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/updating_clusters/understanding-openshift-updates-1), Red Hat Documentation 20. [Operators overview](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/operators/operators-overview), Red Hat Documentation 21. [Extensions overview (OLM v1)](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/extensions/extensions-overview), Red Hat Documentation 22. [Configuring the Image Registry Operator](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/registry/configuring-registry-operator), Red Hat Documentation 23. [Overview of Builds (Shipwright)](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/builds_using_shipwright/overview-openshift-builds), Red Hat Documentation 24. [About Red Hat OpenShift GitOps](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/gitops/about-redhat-openshift-gitops), Red Hat Documentation 25. [About Red Hat OpenShift Pipelines](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/pipelines/about-pipelines), Red Hat Documentation 26. [About OpenShift Virtualization](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/virtualization/about), Red Hat Documentation 27. [About Observability](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/observability_overview/observability-overview), Red Hat Documentation 28. [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/), Kubernetes documentation 29. [Gateway API](https://kubernetes.io/docs/concepts/services-networking/gateway/), Kubernetes documentation 30. [Understanding networking](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/networking_overview/understanding-networking), Red Hat Documentation 31. [Routes](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/ingress_and_load_balancing/routes), Red Hat Documentation 32. [Configuring Gateway API](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/ingress_and_load_balancing/configuring-gateway-api), Red Hat Documentation 33. [OpenShift Container Platform 4.19 release notes](https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/release_notes/ocp-4-19-release-notes), Red Hat Documentation 34. [Ingress NGINX Retirement: What You Need to Know](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/), Kubernetes Blog 35. [Creating a cluster with kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), Kubernetes documentation 36. [Network policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/), Kubernetes documentation 37. [Admission controllers reference](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/), Kubernetes documentation 38. [K3s: Lightweight Kubernetes](https://docs.k3s.io/), K3s documentation 39. [RKE2 introduction](https://docs.rke2.io/), RKE2 documentation 40. [What is Amazon EKS?](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html), Amazon Web Services 41. [What is Azure Kubernetes Service (AKS)?](https://learn.microsoft.com/en-us/azure/aks/what-is-aks), Microsoft Learn 42. [Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/), Kubernetes documentation 43. [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/), Kubernetes documentation 44. [Enforce Pod Security Standards by configuring the built-in admission controller](https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/), Kubernetes documentation 45. [Managing security context constraints](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/authentication_and_authorization/managing-pod-security-policies), Red Hat Documentation 46. [Understanding and managing pod security admission](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/authentication_and_authorization/understanding-and-managing-pod-security-admission), Red Hat Documentation 47. [Network policy](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/network_security/network-policy), Red Hat Documentation 48. [Manage secure signatures with sigstore](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/nodes/nodes-sigstore-using), Red Hat Documentation 49. [OpenShift Container Platform 4.20 release notes](https://docs.redhat.com/en/documentation/openshift_container_platform/4.20/html/release_notes/ocp-4-20-release-notes), Red Hat Documentation 50. [Creating images: OpenShift-specific guidelines](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/images/creating-images), Red Hat Documentation 51. [Error when trying to deploy an application: provider restricted-v2 runAsUser must be in the ranges](https://access.redhat.com/solutions/7069472), Red Hat Customer Portal (knowledge base) 52. [Kubernetes patch releases and support period](https://kubernetes.io/releases/patch-releases/), Kubernetes documentation 53. [Amazon EKS Kubernetes versions](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html), Amazon Web Services 54. [Supported Kubernetes versions in AKS](https://learn.microsoft.com/en-us/azure/aks/supported-kubernetes-versions), Microsoft Learn 55. [Preview: Red Hat OpenShift 5 Intent to Release Roadmap Update](https://access.redhat.com/articles/7134648), Red Hat Customer Portal 56. [What is Red Hat OpenShift Service on AWS?](https://docs.aws.amazon.com/rosa/latest/userguide/what-is-rosa.html), Amazon Web Services 57. [Introduction to Azure Red Hat OpenShift](https://learn.microsoft.com/en-us/azure/openshift/intro-openshift), Microsoft Learn 58. [Differences between OpenShift Container Platform 3 and 4](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/migrating_from_version_3_to_4/planning-migration-3-4), Red Hat Documentation 59. [Network considerations for migrating from OpenShift 3 to 4](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/migrating_from_version_3_to_4/planning-considerations-3-4), Red Hat Documentation 60. [Deployments (DeploymentConfig objects)](https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/html/building_applications/deployments), Red Hat Documentation