In this article, we will examine and point out some of the differences between two popular container orchestration management systems, Red Hat OpenShift and native Kubernetes.
Both OpenShift and Kubernetes are open-source platforms helping with container orchestration and application development. With OpenShift being a product and Kubernetes being a project.
Kubernetes is an open-source container orchestration system, first developed by Google and is now part of the Cloud-Native Computing Foundation. It enables the automation of highly available containerized solutions through auto-scaling, load balancing, storage automation, and self-healing capabilities.
You can learn more about Kubernetes with our detailed Kubernetes tutorial.
OpenShift is a cloud-based Kubernetes container platform that’s considered both containerization software and a platform-as-a-service (PaaS). Red Hat owns the OpenShift product, which is partially built on Docker.
OpenShift can be considered the distribution of a container platform that works with Kubernetes as the ‘kernel’. It offers consistent security, built-in monitoring, centralized policy management, and compatibility with Kubernetes container workloads. It’s fast, enables self-service provisioning, and integrates with a variety of 3rd party tools. OpenShift runs on top of Red Hat Enterprise Linux.
OpenShift contains all of the native Kubernetes and Docker features and platforms, as well as adding value through its own management functionality and DevOps tooling features. OpenShift can be described as a complete open-source container application platform.
OpenShift OKD (Origin Key Distribution) is the community distribution of Kubernetes that powers Red Hat OpenShift. Also referred to as Origin, it supports multiple programming languages, including Go, Node.js, Ruby, Python, PHP, Perl, and Java.
OKD is a sibling Kubernetes distribution to Red Hat OpenShift. Enterprise-level support is offered with OpenShift only, not OKD.
As well as the OpenShift container platform, the engine version of OpenShift is available. The platform version offers more features, such as advanced management around logging, traceback, and chargeback, Advanced networking capabilities like OpenShift Service Mesh and Multi-tenant software-defined networking, and a better developer experience with automated builds, integrated console, and built-in CI/CD pipelines.
Essentially Openshift container engine is a cheaper, cut-down version with a subset of the platform version’s features. For full details, check the documentation.
Kubernetes is arguably more flexible than OpenShift, as it is an open-source framework that can be installed on any Linux distribution. OpenShift requires the proprietary Red Hat Enterprise Linux Atomic Host (RHELAH), Fedora, or CentOS.
Managed PaaS versions of OpenShift can be deployed directly in the big three public cloud platforms, Microsoft Azure, Amazon AWS, or Google Cloud, similar to their native Kubernetes PaaS offerings like AKS (Azure Kubernetes Service) or Amazon EKS (Elastic Kubernetes Service).
Kubernetes uses an object-based deployment system, while OpenShift uses DeploymentConfig (DC). Kubernetes Objects are persistent entities in the Kubernetes system that represent the state of your cluster. A DeploymentConfig in OpenShift is more or less equivalent to a Kubernetes Deployment however, a deployment uses ReplicaSet and DeploymentConfig uses ReplicationController.
OpenShift bakes in strong security best practices and policies on the platform, layering in controls to secure data, networking, build pipelines, container registry, API endpoints, and gateways. It provides security features for multi-tenant networking and fine-grained network control. All traffic to the control plane is encrypted. Application traffic is encrypted with OpenShift Service Mesh.
By default, OpenShift prevents containers from running as root. In addition, it enables granular deployment policies that allow operations, security, and compliance teams to enforce quotas, isolation, and access protections. It also provides embedded Role-based access controls (RBAC).
OpenShift provides strong encryption controls to protect sensitive data, including platform secrets and application configuration data. OpenShift optionally uses FIPS 140–2 Level 1 compliant encryption modules to meet security standards for U.S. federal departments.
Because OpenShift has much more strict security policies than native Kubernetes out of the box, this can be harder to administer as the policies need to be learned, and a higher level of privilege is needed to administer them. This might prove restrictive initially, but ultimately provides a much more holistic and better level of security to your platform.
Learn more about Kubernetes Security Best Practices.
Kubernetes has a large open-source support network, whereas OpenShift is more limited, although OKD is also an open-source project which is mainly led by Red Hat developers.
Red Hat offers OpenShift enterprise-level support policies, which are defined by a base entitlement as well as additional Add-On Entitlements. The licensing of Red Hat Openshift is subscription-based and must be renewed periodically. Costs will grow as the cluster grows in size.
OpenShift has a native networking solution called Open vSwitch, which comes with three native plug-ins. OpenShift Service Mesh, and Multi-tenant software-defined networking can be used. Kubernetes, on the other hand, does not have a networking solution without 3rd party plugins.
To allow external access to the system, Kubernetes uses Ingress objects which are more mature and have more features than the OpenShift equivalent ‘router’ objects.
Kubernetes offers Helm templates (Helm is a Kubernetes package manager) that are flexible, easy to use, and readily available. There are a few simple steps to getting Helm working in Kubernetes.
OpenShift templates come baked into the platform but are not as flexible or openly available. However, Helm can be used in OpenShift if required. OpenShift templates cannot be used in native Kubernetes.
One big disadvantage OpenShift templates have is that release versioning is not available, whereas Helm allows release versioning and rollback.
OpenShift template structures are also more basic than Helm templates. Helm allows the use of basic coding structures such as iteration and conditional logic, whereas Openshift templates do not.
Openshift uses an integrated container registry called ImageStreams to make image management easy, something which is not natively handled in Kubernetes.
Kubernetes does not have an integrated image registry. A 3rd party one must be used, such as Azure Container Registry (ACR) or Amazon Elastic Container Registry (ECR).
OpenShift comes with a fully supported Jenkins image for streamlined CI/CD (Continuous Integration and Continuous Delivery), whereas Kubernetes does not have an integrated solution.
Currently in ‘technology preview’ is OpenShift Pipelines, which is a cloud-native, continuous CI/CD solution based on Kubernetes resources. It uses Tekton building blocks to automate deployments across multiple platforms by abstracting away the underlying implementation details.
See 7 Best Practices and Tools for Kubernetes CI/CD Pipelines.
Openshift provides an enhanced user interface over Kubernetes, although Kubernetes has a lot of 3rd party options that can be used to enhance the UI.
Openshift provides monitoring through Prometheus and utilizes Grafana to display dashboards, which would need to be added to Kubernetes (Learn how to set up Prometheus Monitoring On a Kubernetes Cluster).
Openshift has integrated tools that allow access to the cluster resources. External tools are needed for use with Kubernetes.
The Kubernetes dashboard must be installed, and users have to create bearer tokens to make authentication and authorization easier, something which is handled by the OpenShift login page and out-of-the-box dashboard.
Spacelift helps you manage the complexities and compliance challenges of using Kubernetes. It brings with it a GitOps flow, so your Kubernetes Deployments are synced with your Kubernetes Stacks, and pull requests show you a preview of what they’re planning to change. It also has an extensive selection of policies, which lets you automate compliance checks and build complex multi-stack workflows.
You can also use Spacelift to mix and match Terraform, Pulumi, CloudFormation, and Kubernetes Stacks and have them talk to one another. For example, you can set up Terraform Stacks to provision the required infrastructure (like an ECS/EKS cluster with all its dependencies) and then deploy the following via a Kubernetes Stack.
OpenShift is a product, and Kubernetes is a project. Since OpenShift is built on top of Kubernetes, it adds extra features and functionality that may prove useful when choosing between solutions. Enterprise-level support will certainly be valuable for most large organizations. However, the added cost of running OpenShift may prove the deciding factor for many.
The information in this article should form a decent starting point for you you delve deeper into particular areas of interest or concern. The choice will depend on a number of factors, including the need for agility, cost, security, requirements, and integration with existing systems (such as CI/CD or container registries).
The most Flexible CI/CD Automation Tool
Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities for infrastructure management.
