Kubernetes began as a Google project. It’s now a standard product for container orchestration as part of container-as-a-service (CaaS). The Kubernetes platform is flexible and largely adaptable to your needs. By contrast, OpenShift offers additional tooling to simplify the setup and operation of a CaaS platform. These additional tools can also help you automate build processes.
Below I’ll take a look at some key differences.
Differences between OpenShift and Kubernetes
OpenShift is primarily a Kubernetes distribution, marketed by Red Hat. To explain the difference between them, the Linux kernel is a useful analogy: Linux distributions turn the Linux kernel into a usable operating system and make it easy to install as a complete setup. In a similar way, OpenShift turns Kubernetes into an out-of-the-box integrated container platform.
OpenShift customers benefit from vendor support from Red Hat. If you don’t care about manufacturer support, you can use a community edition known as OKD (formerly OpenShift Origin). This edition includes most of the components in OpenShift Enterprise.
Differences in platform support between Kubernetes and OpenShift
There is a significant difference in the supported platforms. Kubernetes can be run on virtually all systems, including macOS and Windows. OpenShift on the other hand is limited to Red Hat Enterprise Linux, Fedora, and CentOS.
Secure by default
When it comes to security options, the configuration in OpenShift is stricter than in Kubernetes. For example, you can’t run containers with root privileges in OpenShift by default. The permission model in OpenShift is always RBAC. Kubernetes by contrast has supported RBAC only since Version 1.8 (September 2017).
Network model in the Kubernetes cluster
The Kubernetes cluster uses a software-defined network (SDN) for networking. You can select whichever implementation you prefer. The Kubernetes website alone currently lists about 20 different network implementations. They all share the following features:
- All the pods in a Kubernetes cluster can communicate with all other pods without network address translation (NAT).
- All the services on one host (for example, system daemons) can communicate with all the pods on the same host.
Individual implementations differ with regard to the supported backend technology. For example, there is an implementation specifically for NSX-T (VMware’s network virtualization and security platform) and one for Google Cloud Engine. There are also simple implementations such as Flannel, which provide a simple, flat network. Other implementations offer different levels of security and routing functionality. This means users can select the optimal solution for their use case.
Network plug-ins with OpenShift
OpenShift offers users three network plug-ins to choose from: 1) ovs-subnet provides a flat network in which each pod can communicate with any other pod. 2) ovs-multitenant isolates pods at the project level. This means that pods from one project cannot communicate directly with pods from another project. 3) ovs-networkpolicy gives you the most precise control when you are configuring your network connections. You can define point-to-point connections for each pod during development.[KS1]
Build & deployment automation
OpenShift offers extensive features for continuous build and deployment. With build and image streams, you can set up fully automated source-to-image (S2I) processes. Kubernetes by contrast does not offer these options out of the box.
Summary – Kubernetes vs. OpenShift
OpenShift simplifies the deployment of a container platform. It narrows down your choices intelligently, especially for common application scenarios. On the other hand, if you want to explore the broadest range of containerization options, Kubernetes is the best choice. If you value manufacturer support for your on-premise container platform, OpenShift Enterprise is the smart option. If you can manage with excellent community support, you’ll be able to build a mature, stable platform with Kubernetes or OKD.