The decision to use OpenShift instead of vanilla Kubernetes was made by procurement, not engineering.
I want to be clear about that because it shapes everything that follows. We weren't sitting in an architecture meeting weighing trade-offs. We were told that a vendor had won a firm-wide enterprise contract, our clusters were in scope, and we were moving to OpenShift. The timeline was nine months.
That was two years ago. Here is what I actually learned.
Let me explain the difference first
Kubernetes is an open-source system for running containers. A container, in simple terms, is a packaged-up version of an application along with everything it needs to run - code, configuration, dependencies. Kubernetes manages those containers: it decides where to run them, keeps them running, restarts them when they crash, and scales them up or down based on demand.
OpenShift is Red Hat's version of Kubernetes. It takes the core Kubernetes system and adds a layer of tooling on top: a web console for managing things visually, built-in security defaults, an integrated image registry (a place to store your container images), and support contracts you can actually call. It is Kubernetes with opinions.
The opinions are where it gets interesting.
The first thing that hit us: security defaults
Kubernetes, out of the box, is fairly permissive about what your containers can do on the system they run on. You can run containers as the root user (the administrator user, with full system access). You can mount certain system directories. You can run processes that require elevated permissions.
OpenShift is not permissive about any of this by default. It uses a system called Security Context Constraints - SCCs - to control exactly what each container is allowed to do. The default setting, called "restricted," is strict. Containers cannot run as root. They get assigned a random user ID. They cannot write to arbitrary filesystem paths.
This is the right default from a security standpoint. Running containers as root is genuinely dangerous - if someone exploits a vulnerability in your application, they get root access on the underlying host, which is a serious problem.
The issue is that a lot of software is written assuming it can run as root, especially older software and software designed for simpler environments. We had several workloads that worked fine on vanilla Kubernetes and failed immediately on OpenShift because they hit these restrictions.
The error messages were not always helpful. "Permission denied" is a message that could mean fifty different things.
# How I actually debugged SCC issues
oc get pod failing-pod-name -o yaml | grep scc
oc describe pod failing-pod-name | grep -A 10 "Events"
oc adm policy who-can use scc anyuid -n my-namespaceWe spent about two weeks doing nothing except figuring out which workloads needed SCC adjustments and how to make those adjustments without just giving everything elevated permissions (which would defeat the point). It was grinding, tedious work, and it wasn't in the project plan.
The web console is genuinely good
OpenShift has a web console - a graphical interface for managing everything in the cluster. You can see your running applications, their logs, their resource usage, the network traffic between them. There's a "topology view" that draws a map of your services and how they connect.
I want to be honest about this: the console is much better than anything I'd seen built on top of vanilla Kubernetes. Better than Rancher, better than Lens, better than the internal dashboards we had cobbled together.
And it was used primarily by platform engineers who were perfectly comfortable in the command line anyway.
The people who would have benefited most from the visual interface - application developers who don't live in terminals - weren't trained on it. We deployed a beautiful tool and then pointed people at kubectl out of habit. This was entirely our fault, not OpenShift's.
Routes vs Ingress: the friction that never fully goes away
In vanilla Kubernetes, the standard way to expose an application to external traffic is through a resource called an Ingress. Most Helm charts (packages of Kubernetes configuration that you can install) are written to use Ingress.
OpenShift has its own resource called a Route for doing the same thing. It predates Kubernetes Ingress and works differently. OpenShift supports Ingress too, through a compatibility layer, but the native OpenShift experience is Routes, and the documentation, the console, and the support organization all assume you're using Routes.
We had a library of Helm charts written against Ingress. We had three options: use the compatibility layer and accept some rough edges, rewrite the charts to use Routes, or run a separate Ingress controller alongside OpenShift's router and maintain two networking layers.
We tried all three on different workloads. None of them was clean. We landed on a mix, which means two years later I still have to think about which networking model a given workload is using before I touch it. That cognitive overhead is real.
Two years in: the honest verdict
The cluster runs well. The security model is better than what we had before and I genuinely believe that. The platform team has learned OpenShift thoroughly and the operational burden has settled to something manageable.
I would not choose to migrate from one to the other mid-stream again without a significant budget and timeline specifically for the transition. The technical work is real. The retraining is real. The weeks your senior engineers spend learning the new platform's opinions instead of building things are real and they are invisible in a project plan until they're happening.
If your firm is starting fresh, OpenShift is a reasonable choice if you want guardrails and enterprise support, and vanilla Kubernetes is a reasonable choice if you want flexibility and control and have the team expertise to manage it. Neither is wrong.
What I would not do is let the decision be made by procurement and handed to the engineering team as a fait accompli with a nine-month deadline. The platform you pick is the one you'll be living with for five years. Engineering should be in the room when it's chosen.
