OpenShift vs Kubernetes vs OKD: what OpenShift adds

Kubernetes is the engine that schedules containers across a group of machines. On its own it is a toolkit: you still have to choose an operating system for the nodes, an ingress solution, a registry, a way to build images, monitoring, authentication and an upgrade process. OpenShift Container Platform (often just OpenShift) is Red Hat’s product that ships all of those pieces pre-integrated, and OKD is the community distribution of Kubernetes that powers OpenShift.

If you know Kubernetes, almost everything still applies: pods, deployments, services, ConfigMaps and Secrets work the same, and the oc command line tool accepts the same commands as kubectl. OpenShift adds extra resource types and stricter defaults on top.

OpenShift Container Platform and OKD

• OpenShift Container Platform is the commercial, Red Hat supported product, with its own release channels and documentation at docs.redhat.com.
• OKD is open source and community supported. It is built from the same code base and its documentation at docs.okd.io mirrors the OpenShift docs, with community operating system images and its own update channel.
• Commands, resource types and concepts are the same in both. Most tutorials written for one work on the other.

What OpenShift adds to Kubernetes

• Projects: a project is a Kubernetes namespace with additional annotations. Users create them with oc new-project, and access is controlled per project with roles such as admin, edit and view.
• Routes: a Route publishes a service on a host name through the built-in router (Ingress Controller), with edge, passthrough or re-encrypt TLS. Plain Kubernetes Ingress objects also work.
• Builds: a BuildConfig turns source code or a Dockerfile into an image inside the cluster. Source-to-Image (S2I) injects your code into a builder image, so you do not need to write a Dockerfile.
• Image streams: an image stream is a named pointer to images. Builds and deployments can watch an image stream tag and rebuild or redeploy automatically when it changes.
• Operators everywhere: the platform itself is run by cluster Operators managed by the Cluster Version Operator, and optional add-on Operators are installed through Operator Lifecycle Manager (OLM) from the software catalog, formerly called OperatorHub.
• Security Context Constraints (SCCs): by default pods run with a random, non-root user ID from a range assigned to the project, with all capabilities dropped. Images that insist on running as root fail until they are fixed.
• An integrated stack: a web console, OAuth login with identity providers, an internal image registry, monitoring and over-the-air cluster updates are part of the install.

The same task in kubectl and oc

# Works the same with kubectl and oc
oc get pods
oc apply -f deployment.yaml
oc logs deploy/web

# OpenShift-only commands
oc new-project shop-dev
oc new-app https://github.com/sclorg/httpd-ex.git
oc expose service/httpd-ex
oc start-build httpd-ex --follow

What this means in practice

Workloads written for plain Kubernetes usually run unchanged, with one common exception: container images that assume they run as root, or as one fixed user ID, often crash with permission denied because of the random user ID. Fix the image so it works with any UID rather than loosening security; the article on Security Context Constraints explains how.

OpenShift also manages the nodes themselves. Node operating system settings are changed through MachineConfig objects and cluster updates are driven by the Cluster Version Operator, so you do not normally log in to nodes and change them by hand.

Official documentation

• OKD architecture overview
• Control plane and Operators in OKD
• OKD project home page