OpenShift Container Platform (formerly known as OpenShift Enterprise[16]) is Red Hat’s on-premises private platform as a service product, built around a core of application containers powered by Docker, with orchestration and management provided by Kubernetes, on a foundation of Red Hat Enterprise Linux and Red Hat Enterprise Linux CoreOS (RHCOS).
The main difference between OpenShift and vanilla Kubernetes is the concept of build-related artifacts. In OpenShift, such artifacts are considered first class Kubernetes resources upon which standard Kubernetes operations can apply. OpenShift’s client program, known as “oc”, offers a superset of the standard capabilities bundled in the mainline “kubectl” client program of Kubernetes.[11] Using this client, one can directly interact with the build-related resources using sub-commands (such as “new-build” or “start-build”). In addition to this, an OpenShift-native pod build technology called Source-to-Image (S2I) is available out of the box, though this is slowly being phased out in favor of Tekton – which is a cloud native way of building and deploying to Kubernetes. For the OpenShift platform, this provides capabilities equivalent to what Jenkins can do.
Some other differences when OpenShift is compared to Kubernetes:
- The v4 product line uses the CRI-O runtime – which means that docker daemons are not present on the master or worker nodes. This improves the security posture of the cluster.
- The out-of-the-box install of OpenShift comes with an image repository.
- ImageStreams (a sequence of pointers to images which can be associated with deployments) and Templates (a packaging mechanism for application components) are unique to OpenShift and simplify application deployment and management.
- The “new-app” command which can be used to initiate an application deployment automatically applies the app label (with the value of the label taken from the –name argument) to all resources created as a result of the deployment. This can simplify the management of application resources.
- In terms of platforms, OpenShift used to be limited to Red Hat’s own offerings but now supports others like AWS, IBM Cloud and vSphere with OpenShift 4.[12]
- OpenShift’s implementation of Deployment, called DeploymentConfig is logic-based in comparison to Kubernetes’ controller-based Deployment objects.[13] As of v4.5, OpenShift is steering more towards Deployments by changing the default behavior of its CLI.
- An embedded OperatorHub. This is a web gui where users can browse and install a library of Kubernetes Operators that have been packaged for easy lifecycle management. These include Red Hat authored Operators, Red Hat Certified Operators and Community Operators[14]
Openshift also tightly controls the Operating Systems used. The Master components have to be running Red Hat CoreOS. This level of control enables the cluster to support upgrades and patches of the Master nodes with minimal effort. The Worker Nodes can be running other variants of Linux or even Windows.
OpenShift introduced the concept of routes – points of traffic ingress into the Kubernetes cluster. The Kubernetes ingress concept was modeled after this.[15]
OpenShift also provides value adds by bundling various software solutions – application runtimes as well as infrastructure components from the Kubernetes ecosystem. For example, for observability needs, Prometheus, Hawkular, and Istio (and their dependencies) are included out of the box. The Red Hat branding of Istio is called Red Hat Service Mesh, and is based on an opensource project called Maistra, that aligns base Istio to the needs of opensource OpenShift.
