In enterprise companies you often find OpenShift instead of vanilla Kubernetes — and a developer used to kubectl and Ingress lands in a world of oc, Routes, and puzzling "pod can't start as root" failures. Let's break down what OpenShift adds on top of Kubernetes and which of it actually affects you.

What it is

OpenShift is a Kubernetes distribution by Red Hat. Under the hood it's the same Kubernetes (the same pods, deployments, services, the same API), but packaged into a finished product with support, integrated builds, out-of-the-box security, and a web console. Analogy: Kubernetes is the kernel, OpenShift is the distribution around it, like Ubuntu around Linux.

That's why Kubernetes knowledge carries over directly: Deployment, Service, and ConfigMap manifests work as-is. The differences are in the add-ons.

What it adds on top of Kubernetes

  • Routes instead of Ingress. External access in OpenShift has historically been done through the Route object (with a built-in HAProxy router) rather than through Ingress. Recent versions understand Ingress too, but in existing projects you'll almost always come across Route.
  • Built-in registry and builds (S2I). OpenShift can build an image from source via Source-to-Image: you give it a repository and get an image in its internal registry, without a hand-written Dockerfile. This is handled by the BuildConfig and ImageStream objects.
  • Security Context Constraints (SCC). The main source of surprises. By default OpenShift forbids containers from running as root and assigns a random UID. An image that ran as root on plain Kubernetes fails here — you need to make it "rootless": don't hardcode the UID, and only allow writes to the directories that actually need them.
  • oc and a web console. The oc CLI is a superset of kubectl (everything the same, plus OpenShift specifics: oc new-app, oc login). Plus a rich graphical console for deployment and diagnostics.
  • Projects instead of namespaces. A "project" in OpenShift is a namespace with additional access policies layered on top.

What it means for a developer

If you deploy a Spring Boot service on OpenShift:

  • The image must be rootless. Prepare the container so it runs under an arbitrary unprivileged UID (don't write to /, put files in directories with group-write access). This is also good practice for plain Kubernetes.
  • External access goes through a Route. Instead of Ingress, you create a Route for your Service (or use oc expose).
  • Probes, resources, configuration — just like in Kubernetes. readinessProbe, livenessProbe, CPU/memory limits, ConfigMap/Secret — all the same; there's nothing to relearn here.

Practical takeaway: learn Kubernetes — it carries over to OpenShift 90% of the way. Pick up the OpenShift specifics (Routes, SCC, S2I) as needed for the particular cluster.

In short

  • OpenShift is a Kubernetes distribution by Red Hat: the same kernel, add-ons on top, and commercial support.
  • External access goes through a Route (built-in router), not just Ingress.
  • It can build an image from source (S2I, BuildConfig, ImageStream) and store it in a built-in registry.
  • Security Context Constraints forbid root and hand out a random UID — the image must be rootless, a common cause of failures during a migration.
  • oc is a superset of kubectl; Kubernetes manifests work as-is, with nothing to relearn.
  • Kubernetes: fundamentals — the pods, deployments, and services OpenShift is built on.
  • Deploying to Kubernetes — manifests, Helm, and rolling updates.
  • Spring Boot on Kubernetes — probes and service configuration in the cluster.