The main difference between OpenShift and vanilla
Kubernetes is its extension of the platform with build-related artifacts as first-class Kubernetes resources upon which standard Kubernetes operations can apply. OpenShift's
oc client offers a superset of the standard
kubectl (Kubernetes standard client) capabilities., including direct interaction with build resources via sub-commands like
new-build or
start-build. It also provided out of the box an OpenShift-native pod builds technology called Source-to-Image (S2I), though this is slowly being phased out in favor of
Tekton, a cloud-native CI/CD framework for Kubernetes. Other differences include: • An out-of-the-box integrated container image registry. • Unique resources like ImageStreams (a sequence of pointers to images which can be associated with deployments) and Templates (a packaging mechanism for application components). • The
new-app command, which initiates an application deployment, automatically applies the
app label (with the value of the label taken from the
--name argument) to all created resources, simplifying management. • Support for multiple infrastructure platforms, including AWS, Azure, IBM Cloud, vSphere, and bare metal. • OpenShift’s implementation of Deployment, called DeploymentConfig is logic-based in comparison to Kubernetes' controller-based Deployment objects. OpenShift v4 tightly controls the operating systems for "control plane" components. They must run on Red Hat CoreOS, enabling automated, reliable upgrades and patches. The compute (worker) nodes can run any Linux OS or even Windows. OpenShift introduced the concept of
routes -- points of traffic ingress into the cluster. This later influenced the Kubernetes ingress concept. OpenShift also bundles various software components from the Kubernetes ecosystem for enhanced functionality. For observability, it includes
Prometheus, Fluentd, Vector, Loki, and Istio (branded as Red Hat Service Mesh, based on the Maistra open source project). == Products ==