OpenShift vs Kubernetes: what the extra layer buys you

“OpenShift is just Kubernetes with extra steps” is the line you hear from teams who have used one and read about the other. It is close enough to be useful and wrong in the places that cost you a week.

Everything below is Kubernetes underneath. The question is not whether OpenShift is a fork — it isn’t — but which problems Red Hat decided to solve for you, and whether you wanted them solved that way.

Your workloads

• Deployments
• Services
• ConfigMaps
• BuildConfigs

OpenShift adds

• SCC admission
• Router / Routes
• OLM
• Internal registry
• Projects
• Monitoring stack

Everything in this band is what a subscription pays for. Each one is buildable upstream; few teams build all of them.

Kubernetes

• API server
• Scheduler
• Controllers
• etcd
• kubelet

Host

• RHCOS
• CRI-O

The API you write against is the Kubernetes one. The differences that cost you time all live in the band above it.

Pods do not run as root, and this is the one that bites

Upstream Kubernetes will happily run a container as UID 0 unless something stops it. OpenShift stops it by default.

Security Context Constraints are an admission-time policy that decides which UIDs, capabilities, volume types and host access a pod may request. The default restricted-v2 SCC assigns each project a UID range and runs your container as an arbitrary UID from it. Not root, and not the UID baked into your image either.

This is why a Helm chart that works on GKE fails on OpenShift with CreateContainerConfigError or a permission-denied on first write. The image assumed it owned /var/lib/something as a known user, and it doesn’t. We wrote up the diagnosis and the fix separately, because it is the single most common OpenShift support question we get.

The trade is real: this default prevents a whole class of container escapes, and it breaks perhaps a third of public Helm charts on first install.

Routes came first, Ingress came later

OpenShift shipped Routes years before Ingress stabilised upstream, and kept them. A Route is a first-class object backed by an HAProxy-based router, with TLS termination modes Ingress has no direct equivalent for.

Ingress objects still work — OpenShift converts them into Routes behind the scenes — so portable manifests are fine. You lose access to the termination modes and to per-route timeout and balancing annotations unless you use Routes directly. The three TLS modes and when each applies is its own post.

Operators are the install mechanism, not an add-on

On upstream Kubernetes you install things with Helm, or with an operator you chose to adopt. On OpenShift, Operator Lifecycle Manager is how the platform installs itself and how you install most vendor software.

That changes day-two work. Instead of helm upgrade, you are reasoning about subscriptions, channels, install plans and approval strategies. A subscription with installPlanApproval: Manual will sit and wait for a human, which looks exactly like a broken operator until you know to run oc get installplan.

The upside is real: upgrades become declarative and the operator carries the upgrade logic for its own CRDs. The cost is a vocabulary your team has to learn, and a new failure mode where the thing that is stuck is the installer rather than the workload.

Builds and the registry are inside the cluster

OpenShift ships an integrated image registry and BuildConfigs, including Source-to-Image, which turns a Git repository into a runnable image without a Dockerfile.

For teams without an established CI pipeline, this is a genuine shortcut. For teams that already build images in GitLab or GitHub Actions, it is machinery you will not use, and ImageStreams become an extra indirection between your registry and your Deployment. Know which of those you are before you lean on it.

Monitoring is preinstalled and partly locked

A cluster-monitoring Prometheus stack comes up with the cluster and scrapes the control plane. You do not install it, and you cannot freely reconfigure it: the platform stack is managed, and user workload monitoring is a separate opt-in stack you enable via a ConfigMap.

Teams used to running their own kube-prometheus-stack find this restrictive for about a week, then stop caring. Teams that need custom scrape configs across the whole cluster find it restrictive permanently.

Projects are namespaces with opinions

An OpenShift Project is a namespace plus default RBAC, default quota and limit ranges, and a self-service creation path for developers. oc new-project gives someone a working, bounded place to deploy in one command.

You can build the same thing upstream with a namespace template and a controller. Most teams intend to and never do.

When upstream Kubernetes is the right answer

We run both for clients, and we recommend upstream when:

• You are on a managed control plane and happy there. EKS, GKE and AKS remove exactly the operational work OpenShift’s installer automates. Paying for both is paying twice.
• Your team is small and already fluent. OpenShift’s guardrails are worth most where many teams share a cluster and no single person can review every manifest.
• You need a specific CNI, CSI or scheduler that Red Hat does not support. Supportability is a large part of what you are buying; running an unsupported component erodes it.
• Cost is the binding constraint and you have the people. Subscriptions are not trivial, and a competent platform team can build a good chunk of this on upstream.

We recommend OpenShift when a regulated environment needs defensible defaults, when developer self-service matters more than platform flexibility, or when the organisation needs a vendor to call at 3am.

The part nobody puts in the comparison table

The differences above are learnable in a fortnight. What actually determines whether an OpenShift programme goes well is whether someone owns the cluster — patching, upgrades, capacity, the operator catalogue — and that is the same question upstream. The platform choice changes the shape of that job, not whether it exists.

If you are weighing the two for a specific workload, our expertise page covers how we usually run the assessment.