Every few months a manager asks us a version of the same question: "We are moving to Kubernetes. Should we buy OpenShift, or use plain Kubernetes?" It sounds like a technical question, but most of the answer is about people, budget and risk.

This post explains what OpenShift is in simple terms, what it adds, what it costs, and the situations where we would and would not recommend it.

Kubernetes in one paragraph

Kubernetes is open-source software that runs containerised applications across a group of servers. You tell it "run five copies of this app, expose it on this address, restart it if it crashes," and it keeps that true. It is powerful, but on its own it is a toolkit: you still need to choose and run networking, ingress, monitoring, logging, a container registry, build pipelines, security policies and an upgrade process.

Cloud providers sell managed Kubernetes (Amazon EKS, Google GKE, Azure AKS) where they run the control plane for you, but you still assemble most of the rest.

What OpenShift is

Red Hat OpenShift is a Kubernetes distribution that comes with those extra pieces chosen, integrated, tested together and supported by Red Hat. It runs on your own servers, on virtual machines, or as a managed service on public clouds (for example Red Hat OpenShift Service on AWS and Azure Red Hat OpenShift). A free community version called OKD exists, without Red Hat support.

What OpenShift adds on top of Kubernetes

Area

Plain Kubernetes

OpenShift

Node operating system

Your choice

Red Hat Enterprise Linux CoreOS, managed by the cluster

Upgrades

You plan and run them per component

Cluster-wide upgrade channels, tested as a whole

Web console

Optional add-ons

Full console for developers and admins

Security defaults

Fairly open by default

Restrictive: containers run with random user IDs, not root

Exposing apps

Ingress controller of your choice

Routes plus a built-in router (Ingress also supported)

Builds

External CI

Built-in builds, including source-to-image

Registry

External

Integrated image registry

Pipelines and GitOps

Assemble yourself

Supported Tekton-based Pipelines and Argo CD-based GitOps

Operators

Install from community sources

OperatorHub with certified operators

Virtual machines

Add-ons

OpenShift Virtualization (based on KubeVirt)

Support

Community or cloud provider

Red Hat, for the whole stack

The main idea: with plain Kubernetes, your team is the integrator. With OpenShift, Red Hat is.

The security defaults change daily work

OpenShift's default rules (called Security Context Constraints) stop containers from running as root and assign each one a random user ID. That is good security practice, but it surprises teams moving from Docker or plain Kubernetes: many public container images assume they run as root or as a fixed user, and they fail with "permission denied" errors on OpenShift until the image is adjusted.

Plan time to fix your images. It is work you should probably do anyway, but it is real work.

What it costs

Money: OpenShift is sold as a subscription, typically priced by CPU cores or worker nodes, on top of your hardware or cloud bill. Managed versions on public clouds charge a service fee in addition to the compute instances. A production cluster also needs at least three control plane machines (single-node and compact options exist for edge and small sites). For small teams the total cost is often much higher than a managed EKS, GKE or AKS cluster.

Habits: OpenShift has its own command-line tool (oc, which also accepts kubectl commands), its own concepts (Projects, Routes, BuildConfigs) and its own way of doing upgrades. Your engineers learn OpenShift, which is Kubernetes plus extras, and some tutorials written for plain Kubernetes need small changes.

Lock-in: your application manifests stay mostly portable, but if you lean on OpenShift-only features (Routes, BuildConfigs, specific operators), moving away later means rewriting those parts.

When OpenShift is worth it

  • On-premises or hybrid: running Kubernetes yourself on your own hardware is hard. OpenShift's integrated install, upgrade and support make it much more realistic for a company data centre.

  • Regulated industries: banks, telecoms, government and healthcare often need vendor support, certified components, security hardening and audit-friendly defaults.

  • Many teams on one platform: the web console, projects, quotas and built-in pipelines help a platform team serve dozens of development teams consistently.

  • An existing Red Hat shop: if you already run RHEL and have Red Hat contracts and skills, OpenShift fits naturally.

  • Running virtual machines and containers together on one platform during a gradual move away from traditional virtualisation.

When plain or managed Kubernetes is enough

  • Small teams already on one public cloud: EKS, GKE or AKS plus a few well-known add-ons is cheaper and well documented.

  • Cost-sensitive startups: subscription fees are hard to justify before product-market fit.

  • Teams with strong platform engineers who prefer to choose each component themselves.

  • Serverless or simple container needs: services such as Cloud Run, AWS Fargate or Azure Container Apps may remove the need for any Kubernetes at all.

A middle path: try before committing

You do not need to bet the company on day one. Practical ways to evaluate:

  • Local test: Red Hat offers OpenShift Local, a small single-machine cluster for developer laptops. It is enough to see how your applications behave under OpenShift's security rules and to try the console, builds and Routes.

  • Developer Sandbox: Red Hat runs a free, time-limited shared OpenShift environment for experimenting without installing anything.

  • Managed trial on your cloud: the managed OpenShift services on AWS and Azure let you create a cluster with your existing cloud account and remove it after the test, paying only for the hours used.

  • Pilot one application: move a real but non-critical service, including its CI pipeline, monitoring and alerting. Measure how long the migration took and how many image changes were needed.

Do the same pilot on a managed EKS, GKE or AKS cluster with the add-ons you would actually need. Comparing two real pilots, with real effort and real bills, beats comparing feature lists.

Questions to ask before deciding

  1. Where will the clusters run: one cloud, several clouds, or our own data centre?

  2. Who will upgrade and patch the cluster every few months, and who do we call at 3 a.m.?

  3. Do auditors or customers require vendor support or certifications?

  4. How many teams and applications will share the platform?

  5. What is the three-year cost, including subscriptions, people and training?

  6. How many of our container images run as root today?

Key takeaways

  • OpenShift is Kubernetes plus an integrated, supported set of tools and stricter security defaults.

  • It shines on-premises, in regulated environments and for large multi-team platforms.

  • Managed Kubernetes on a single cloud is usually cheaper and simpler for small teams.

  • Budget time to fix container images for OpenShift's non-root, random-UID default.

References