Red Hat often refers to OpenShift as “Enterprise Kubernetes” and tends to describe it as Platform as a Service (PaaS). Understanding the differences between OpenShift and Kubernetes can be a difficult task, since Kubernetes is an integral part of OpenShift.
In this article, This article describes the most essential differences between Kubernetes and OpenShift such as security, deployment options, networking and more.
Kubernetes is an open-source framework for automating the management, deployment and scaling of containerized applications. OpenShift is a containerization solution developed by Red Hat. Their main product is the OpenShift Container Platform, a hybrid cloud PaaS, which is managed and orchestrated by Kubernetes.
Here’s a review of key differences between Kubernetes and Openshift:
To summarize, if you need support for Kubernetes and all the features that a paid product provides, then OpenShift is the right choice for you. On the other hand, if you prefer an open-source project with all its benefits, go with plain Kubernetes.
To install OpenShift you need to use Red Hat Enterprise Linux (RHEL) or Red Hat Atomic on OpenShift 3. For compute nodes you have to use Red Hat CoreOS and RHEL on OpenShift 4. You cannot install OpenShift on other Linux distributions.
Each version of OpenShift has a different installation process. OpenShift 3 is installed manually or with OpenShift Ansible, which is an installation and configuration management tool. Installation with Ansible is obviously a better choice, but the process is slow and complex. The major advantage of installing with Ansible is the rolling update of the whole cluster that lets you easily upgrade Kubernetes clusters.
OpenShift 4, on the other hand, has an easier installation process, which supports AWS and vSphere. It is performed by dedicated software, and the whole configuration is kept in ConfigMaps inside a cluster.
In contrast, you can install Kubernetes almost on any linux distribution like Ubuntu or Debian. Kubernetes has many available installation tools like kops, kubeadm, and kube-spray. Some tools are better for cloud while others are more universal and complex.
Kubernetes is available on all popular cloud platforms, through the use of the following services:
In conclusion, Kubernetes is available on more platforms than OpenShift. However, the new OpenShift installer is more flexible and faster. We can expect that OpenShift will be a reasonable alternative for Kubernetes.
OpenShift has more strict security policies than default Kubernetes because of the target audience for OpenShift product. For instance, OpenShift will not run most of the container images available on Docker Hub because running a container as a root is not allowed on OpenShift. There is a simple method to disable that policy, but it still shows a different approach to security.
Role-Based Access Control (RBAC) is an essential component of OpenShift while Kubernetes is sometimes used without RBAC. That is fine for small setups, but for large companies, you need to establish a permission mechanism even if it is hard to comprehend. OpenShift, on the other hand, does not provide other options—you have to use RBAC when you deploy apps.
OpenShift lets you install external components like Internal Container Registry, Prometheus for monitoring, Jenkins and ElasticSearch, Fluentd, and Kibana (EFK) for logging. Authentication and authorization of those components is done with the OAuth mechanism. That makes permissions management easier and can provide additional features. For example in EFK, you can see only the logs you have access to. Kubernetes also provide this level of authentication, but it requires a lot of work.
OpenShift and Kubernertes manage deployments in different ways. Deployment objects in Kubernetes are implemented internally in controllers and they are responsible for updating pods in a rolling fashion.
On the contrary, DeploymentConfig objects in OpenShift are not implemented by controllers. The entire process is controlled by a complex logic based on dedicated pods. An important advantage of this feature is that you can use hooks to update your environments. For example you can change the database schema. The DeploymentConfig object has some drawbacks, for example, it does not support synchronous updates. While with Kubernetes you can scale updates properly.
Kubernetes does not have a native networking solution. The communication between external and internal cluster service is based on an Ingress router. Ingress is an interface implemented by multiple servers such as nginx, AWS ELB/ALB, traefik, GCE, Kong, and others, including HAproxy.
In contrast, OpenShift provides a native networking solution like Route objects, which are similar to Kubernetes Ingress. The routers in OpenShift are implemented using the open source HAproxy server.
Jenkins is often used with Kubernetes to perform Continuous Integration (CI), build container images, and deploy clusters on multiple environments with Continuous Deployment (CD) pipelines. Manual integration is required only for use with Kubernetes.
Since Jenkins is a built-in part of OpenShift it makes the CI/CD pipeline easier and provides the following advantages:
Custom Jenkins image—update Jenkins images when a source image is changed by using custom configurations and resources.
OpenShift and Kubernetes allow you to easily manage and deploy containerized applications. In addition, beginners can easily learn how to use OpenShift with the help of its unique web console.
Although OpenShift has Kubernetes built into it, installing Kubernetes often requires an external solution or managed Kubernetes clusters. Installing OpenShift is easier, but it is limited to Red Hat Linux distributions.
There are many solutions to choose from, and many can be tailored to your system requirements. Prioritize the scalability, flexibility and web interface needs of your project, and design the pipeline that works best for you.