At CoreOS we considered Kubernetes to be the "kernel" of distributed systems. We recognized that a well designed job scheduler, operating across multiple machines, capable of reconciling the state of managed workloads would naturally foster collaboration much in the same way that the Linux kernel did for the scheduling workloads on a single host. Following this logic, we knew that products would differentiate themselves based on the concerns important to their users.
He goes on to expand this comparison to the Linux kernel:
While anyone could build Linux from Scratch by choosing each piece and assembling them in the bespoke manner each user chooses, most do not. The level of abstraction that most users choose means that they don’t derive a lot of value from managing (or even knowing about) the differences between Util-Linux version 2.31 and 2.33. To take this a step further, user care about a minimum level of functionality (e.g. they know which commands/APIs will be available as long as they surpass a minimum version number) and then a list of features provided.
This is much the same as OpenShift. We package Kubernetes and include additional tooling as features that we find important and our users demand. Much as CoreOS and CentOS contain different sets of tooling, catering to different users, so it is the same with Kubernetes distributions. At Red Hat we have focused on making available the tools that help make developers and operations teams successful. This is why, for example, we are including Istio as a technology preview in OpenShift now. We feel it is a tool many users may come to depend on, and thus should be included as table stakes in the base distribution.
Be sure to check the full post, or share it with your team to help them understand how Kubernetes and OpenShift relate to one another.
TL;DR: as of Kubernetes 1.20, support of the Docker container engine is deprecated, but users will still be able to use Docker container images and registries, as well as create containers that look ...