Kubernetes is a popular open-source containerization system that allows for fast development, deployment, and scaling. It has become the default option for container orchestration in the past few years, and in one survey, over 50% of participants said they used Kubernetes for container management.
However, there are several disadvantages associated with using Kubernetes. There are significant security and network communications and monitoring configuration updates needed by default. Additionally, hiring the expertise for developing and maintaining Kubernetes is difficult. At a recent KubeCon, a survey of 152 attending organizations found that lack of expertise (52%) and operational complexity (50%) are the biggest roadblocks to integrating Kubernetes.
While these are valid concerns, there are options that can simplify Kubernetes and require fewer developer resources to manage. In this article, you will learn about OpenShift, a managed service for Kubernetes, how it works with, and its key differences from Kubernetes. Along the way, you’ll learn some use cases for OpenShift, and see a basic setup so you can try out both platforms.
OpenShift deep dive and comparisons
OpenShift was founded in 2019 as an open-source initiative by the Red Hat organization, now a subsidiary of IBM. OpenShift is a hosted containerization platform built around Kubernetes. It provides a managed service for the whole Kubernetes ecosystem, including automated installation, monitoring, upgrades, continuous integration and deployment (CI/CD), and centralized policy management. Alongside the managed service, OpenShift support is available for setup and issue resolution.
Like other Kubernetes distributions, there are multiple options to host OpenShift: you can pay a license fee to RedHat to host OpenShift on your own servers or host it on one of the platform’s cloud partners, including Azure, IBM, and AWS. Since OpenShift is managed with dedicated support personnel, the pricing depends on usage but is based on the number of clusters and worker nodes you run.
Why use OpenShift over standard Kubernetes?
It is difficult to secure, maintain, and monitor Kubernetes without dedicated systems engineering resources and often third-party software. These resources cost money and time to install, manage, and monitor. Like Kubernetes, OpenShift is open-source (in fact – OpenShift has Kubernetes as a core layer), will not lock you into a particular vendor, and has integrations with a variety of tools.
However, there are many differences between the hosted OpenShift and the self-hosted Kubernetes platforms that make it attractive.
Differences between OpenShift and Kubernetes
The biggest difference is that Kubernetes provides you with more flexibility, while OpenShift is opinionated, limiting choice to ensure security and concierge offerings. This illustration shows you the functions that OpenShift provides as managed services, explained in further detail below.
- OpenShift, unlike Kubernetes, limits operating system choices to RedHat’s Linux Atomic Host (RHELAH), Fedora, or CentOS. This is a tradeoff which OpenShift prefers: by limiting OS choices, you don’t manage or worry about its sources, images, and security vulnerabilities.
- OpenShift has stricter security policies than Kubernetes by default, such as limits on user privileges to run containers. For instance, every cluster in OpenShift is set up with OpenShift security context constraints, a set of roles that restrict access to resources.
- OpenShift has 24/7 Red Hat Premium Support, a team consisting of Red Hat site reliability engineers, while Kubernetes has an active community of developers on forums. This means you might have to wait longer to find answers to your Kubernetes questions without OpenShift.
- OpenShift has secure networking out of the box, through Open Shift Service Mesh, while in Kubernetes, network configurations have to be defined. For example, instances in OpenShift communicate over SSL, and secure information transmits through SSH with keys rather than passwords.
- OpenShift provides monitoring by default based on Prometheus and Grafana through the Cluster Monitoring Operator which alerts you about issues on the stack through the web platform and CLI. If you’re using Kubernetes alone, you need to select third-party software, such as, for monitoring.
- OpenShift offers CI/CD tools through Tekton. Tekton allows you to configure pipelines, triggers, has a native dashboard and built-in best practices for Kubernetes. Self-managed Kubernetes needs third-party software for CI/CD; this could be handled through Tekton or CodePipeline.
Overall, OpenShift is an opinionated service with many out-of-the-box features. It allows teams with limited Kubernetes experience, expertise, and time to have access to state-of-the-art security, integration, networking, and DevOps tools managed by RedHat and their cloud partners. On the other hand, Kubernetes is a better fit for teams that want more customization or already have in-house teams equipped to manage their Kubernetes environments.
While you can host OpenShift yourself, there are a number of different platforms that offer OpenShift as a managed service such as Microsoft Azure, IBM Cloud, Google, and AWS.
A representative pricing exercise for running OpenShift on AWS follows:
For AWS, there is an hourly cluster fee of
$0.03/hour. Worker node pricing runs from:
1 year Reserved Instance:
$1,000/year for 4 vCPUs (approx.
$0.114/hour for 4 vCPUs)
3 year Reserved Instance:
$2,000/3 years for 4 vCPUs (approx.
$0.076/hour for 4 vCPUs)
As a comparison, EKS, the AWS hosted Kubernetes (non-OpenShift) service runs for:
You pay 70% ($0.17/$0.10) more for on-demand instances using the managed OpenShift Kubernetes platform. EKS does not advertise costs for reserved instances, but they would most likely be around the same range (~50% cheaper than hosting OpenShift). While this difference is significant, it excludes the time and cost associated with third-party tools and developer time you might incur.
Now that you have an understanding of the costs and differences between Kubernetes and OpenShift, let’s take a look at the setup process.
Exploring OpenShift and Kubernetes
You can get started on Openshift through online interactive tutorials, which provide you with a 60-minute burner cluster and guided lessons. It’s easy to start off, and the tutorial goes through essentials such as the command line, development, collaboration, deployments, and connections.
Once done, you take a deep dive through their free 60-day trial with a fully managed Red Hat OpenShift Dedicated trial cluster, with self-service sign-up and cluster provisioning through either AWS or GCS. This allows you to check out the web console and integrations with existing native cloud applications to see if OpenShift can work for your services.
Since Kubernetes is free, you can install it locally or run it on a service like EKS. While EKS is not supported in AWS’s free tier, running a cluster or two for a few hours is a very cheap way to test your Kubernetes deployment.
When you need a secure, scalable container orchestration environment, both Kubernetes and OpenShift can do the job. Your decision should be made based on budget, time, in-house expertise, and personal preference.
For example, if you’re already using Kubernetes and you’ve got a preferred set of third-party tools for CI/CD, monitoring and logging, and everything else in your stack, then you may not find the switch worth it. On the other hand, if you’re new to Kubernetes, have a small team without much experience in it, and prefer the “done-for-you” option, OpenShift might be a good option.