"What is the difference between Kubernetes and OpenShift?" – this question arises with enviable constancy. But really, it's like asking what's the difference between a car and an engine. If we continue the analogy, then a car is a finished product, it can be used immediately, literally: I sat down and drove off. On the other hand, in order for the engine to take you somewhere, you first need to supplement it with a lot of other things in order to end up with the same car.
Therefore, Kubernetes is such an engine around which the car (platform) of the OpenShift brand is assembled, which takes you to the goal.
In this article, we want to recall and analyze the following key points in a little more detail:
- Kubernetes is the heart of the OpenShift platform. And it's 100% Kubernetes certified, completely open source and not proprietary. In short:
- The API for the OpenShift cluster is XNUMX% Kubernetes.
- If the container runs on any other Kubernetes system, then it will run on OpenShift without any changes. You don't need to make any changes to the apps.
- OpenShift not only complements Kubernetes with useful features and capabilities. Like a car, OpenShift is immediately ready to use, can be immediately put into production and, as we will show below, it greatly simplifies the life of a developer. That is why OpenShift is one in two. It is both a successful and well-known enterprise-class PaaS platform when viewed from a developer's perspective. And at the same time, this is a super-reliable Container-as-a-Service class solution from the point of view of industrial operation.
OpenShift is Kubernetes 100% certified by CNCF
OpenShift is based on . Therefore, after appropriate training, users marvel at the power of kubectl. And those who have migrated to OpenShift from Kubernetes Cluster often say how much they love that after redirecting kubeconfig to the OpenShift cluster, all existing scripts work flawlessly.
You must have heard of OpenShift's command line utility called OC. It is fully command compatible with kubectl, plus it offers several useful helpers that will come in handy for a variety of tasks. But first, a little more about OC and kubectl compatibility:
kubectl commands
OC Commands
kubectl get pods
oc get pods
kubectl get namespaces
oc get namespaces
kubectl create -f deployment.yaml
oc create -f deployment.yaml
Here is what the results of using kubectl on the OpenShift API look like:
• kubectl get pods - Returns pods as expected.
• kubectl get namespaces - Returns the namespaces as expected.
The kubectl create -f mydeployment.yaml command creates kubernetes resources just like it would on any other Kubernetes platform, as shown in the video below:
In other words, all Kubernetes APIs are fully available in OpenShift while maintaining 100% compatibility. That is why .
OpenShift adds useful features to Kubernetes
Kubernetes APIs are 100% available in OpenShift, but the standard Kubernetes utility kubectl clearly lacks functionality and convenience. Therefore, Red Hat has enhanced Kubernetes with useful features and command line tools such as OC (short for OpenShift client) and ODO (OpenShift DO, this utility is for developers).
1. OC utility - more powerful and convenient version of Kubectl
For example, unlike kubectl, it allows you to create new namespaces and easily switch contexts, and also offers a number of useful commands for developers, for example, to build containerized images and deploy applications directly from source code or binaries (Source-to-image, s2i).
Let's look at examples of how the built-in helpers and extended functionality of the OC utility help simplify everyday work.
The first example is namespace management. Each Kubernetes cluster always has multiple namespaces. They are usually used to create development and production environments, but can also be used to, for example, give each developer a personal sandbox. In practice, this results in the developer often having to switch between namespaces because kubectl is running in the context of the current namespace. Therefore, in the case of kubectl, people actively use helper scripts for this. But when using OC, it is enough to say “oc project namespace” to switch to the desired space.
Don't remember what the namespace you want is called? No problem, just type "oc get projects" to display the full list. Skeptically wondering how this would work if you only have access to a limited subset of the namespaces on the cluster? Well, because kubectl only does this correctly if RBAC allows you to see all the spaces on the cluster, and in large clusters, not everyone is given such permissions. So, we answer: for OC this is not a problem at all and it will easily give out a complete list in such a situation. These are the little things that form the corporate focus of Openshift and the good scalability of this platform in terms of users and applications.
2. ODO is an improved version of kubectl for developers
Another example of Red Hat OpenShift's improvements over Kubernetes is the ODO command line utility. It is designed for developers to quickly deploy local code to a remote OpenShift cluster. In addition, it can streamline internal processes to instantly synchronize all code changes with containers on a remote OpenShift cluster without having to rebuild, re-array, and redeploy images.
Let's take a look at how OC and ODO make working with containers and Kubernetes easier.
Let's just compare a couple of workflows when they are built on top of kubectl and when they use OC or ODO.
• Deploying code on OpenShift for those who do not speak YAML:
Kubernetes/kubectl
$> git clone
1- Create a Dockerfile that builds the image from code
-----
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
PRESENTATION 3000
CMD [ “npm”, “start” ] ————–
2- Build the image
$>podman build...
3- Log in to the registry
podman login...
4- Place the image in the registry
podman push
5- Create yaml files for application deployment (deployment.yaml, service.yaml, ingress.yaml) - this is the absolute minimum
6- Deploy the manifest files:
Kubectl apply -f .
OpenShift/oc
$> oc new-app – name_of_our_application
OpenShift/odo
$> git clone
$> odo create component nodejs myapp
$> odo push
• Context Switch: Change the workspace name or work cluster.
Kubernetes/kubectl
1- Create context in kubeconfig for project “myproject”
2- kubectl set-context...
OpenShift/oc
oc project "myproject"
QA: “There's an interesting feature here, still in alpha. Can we put it into production?”
Imagine that they put you in a racing car and say: “We have installed a new type of brakes here and, frankly, they are not all right with reliability yet ... But don’t worry, we will actively refine them right during the championship.” How do you like this perspective? We are not very good at Red Hat. 🙂
Therefore, we try to refrain from alpha releases until they are sufficiently mature and we have done extensive combat testing and feel that they are safe to use. Usually, everything goes through the Dev Preview stage first, then through and only then comes out in the form of a public release (GA), which is already stable enough to be suitable for production.
Why is that? Because, as with the development of any other software, not all initial ideas in Kubernetes reach the final release. Or they reach, and even retain the intended functionality, but their implementation is fundamentally different from the one that was in the alpha version. Because thousands upon thousands of Red Hat customers rely on OpenShift to support mission-critical workloads, we put a lot of emphasis on our platform's stability and long-term support.
Red Hat purposefully releases frequent releases of OpenShift and updates its version of Kubernetes. For example, the current GA release of OpenShift 4.3 includes Kubernetes 1.16, which is only one behind the upstream version of Kubernetes 1.17. In this way, we try to give the customer enterprise-class Kubernetes and provide additional quality control in the process of releasing new versions of OpenShift.
Software fixes: “There was a hole in the version of Kubernetes we have in production. And you can close it only by updating three versions up. Or are there options?
In the open source Kubernetes project, software patches are usually released as part of the next release, sometimes they cover one or two previous interim releases, which gives coverage as little as 6 months ago.
Red Hat prides itself on being the first to release critical fixes and providing much longer support. Take, for example, a privilege escalation vulnerability in Kubernetes (): it showed up in Kubernetes 1.11, and fixes for previous releases were released only up to version 1.10.11, leaving this hole in all previous Kubernetes releases, from 1.x to 1.9.
In turn, (there is Kubernetes 1.2), capturing nine releases of OpenShift and clearly demonstrating customer care (read more ).
How OpenShift and Red Hat are driving Kubernetes forward
Red Hat is second only to Google in terms of software contributions to the open source Kubernetes project, with 3 of the 5 most prolific developers being Red Hat employees. Another little-known fact: many critical features appeared in Kubernetes precisely at the initiative of Red Hat, in particular, such as:
- RBAC. Kubernetes did not have RBAC (ClusterRole, ClusterRoleBinding) functions until Red Hat engineers decided to implement them as part of the platform itself, and not as an additional feature of OpenShift. Is Red Hat afraid to improve Kubernetes? Of course not, because Red Hat strictly follows the principles of open source, and does not play Open Core games. Improvements and innovations that are implemented at the level of development communities, and not on a proprietary basis, become more viable and more widely adopted, which is in perfect harmony with our main goal of making open source software more useful for our customers.
- Security policies for pods (Pod Security Policies). Initially, this concept of secure execution of applications inside pods was implemented in OpenShift under the name SCC (Security Context Constraints). And as in the previous example, Red Hat decided to make these developments part of the Kubernetes open project so that everyone could use them.
This series of examples could go on, but we just wanted to show that Red Hat really wants to evolve Kubernetes and make it better for everyone.
Clearly, OpenShift is Kubernetes. And what are the differences? 🙂
We hope that by reading up to this point, you have understood that Kubernetes is the main component of OpenShift. The main one, but not the only one. In other words, just installing Kubernetes won't give you an enterprise-class platform. You will need to add authentication, networking, security, monitoring, log management, and more. In addition, you will have to make a difficult choice from a large number of tools available (to appreciate the diversity of the ecosystem, just look ) and somehow ensure consistency and coherence so that they work as one. In addition, you will regularly need to update and regression test when a new version of any of the components you use is released. That is, in addition to creating and maintaining the platform itself, you will also need to deal with all this software. It is unlikely that there will be much time left to solve business problems and achieve competitive advantages.
But in the case of OpenShift, Red Hat takes all these complexities upon itself and simply gives you a functionally complete platform, which includes not only Kubernetes itself, but also the whole set of necessary open source tools that turn Kubernetes into a real enterprise-class solution that you can immediately and completely calmly launch into production. And of course, if you have your own technology stacks, then you can embed OpenShift into existing solutions.
Take a look at the picture above: everything that is outside the Kubernetes rectangle is the areas where Red Hat adds functionality that is not in Kubernetes, what is called, by-design. And now we will consider the main of these areas.
1. Reliable OS as the basis: RHEL CoreOS or RHEL
Red Hat has been a leading provider of Linux distributions for mission-critical business applications for over 20 years. The accumulated and constantly updated experience in this area allows us to offer a truly reliable and trusted basis for the industrial operation of containers. RHEL CoreOS uses the same kernel as RHEL, but is optimized primarily for tasks such as running containers and working in Kubernetes clusters: its reduced size and immutability make it easy to set up clusters, autoscale, deploy patches, etc. All of these features make it the ideal foundation for delivering the same OpenShift user experience across a wide range of computing environments, from bare metal to private and public clouds.
2. Automation of IT operations
Automation of installation processes and second-day operations (that is, daily operation) is OpenShift's strong point, which greatly facilitates the administration, updating and maintenance of the container platform at the highest level. This is achieved by supporting Kubernetes operators at the core level of OpenShift 4.
OpenShift 4 is also a whole ecosystem of solutions based on Kubernetes operators, developed both by Red Hat itself and by third-party partners (see. Red Hat, or operator shop , created by Red Hat for third-party developers).
OpenShift 4 integrated catalog includes over 180 Kubernetes operators
3. Developer tools
Since 2011, OpenShift has been available as a PaaS (Platform-as-a-Service) platform that greatly simplifies the life of developers, helps them focus on creating code, and offers built-in support for programming languages such as Java, Node.js, PHP, Ruby, Python, Go, as well as continuous integration and delivery services CI / CD, databases, etc. OpenShift 4 offers , which includes more than 100 services based on Kubernetes operators developed by Red Hat and our partners.
Unlike Kubernetes, OpenShift 4 has a dedicated GUI () that helps developers effortlessly deploy applications from various sources (git, external registries, Dockerfile, etc.) into their namespaces and visualizes the relationships between application components.
In addition, OpenShift offers a set of Codeready development tools, which, in particular, includes , a fully containerized web-based IDE that runs directly on top of OpenShift and implements an IDE-as-a-service approach. On the other hand, for those who want to work strictly locally, there is Codeready Containers, a fully functional version of OpenShift 4 that can be deployed on a laptop.
Integrated "IDE as a Service" for efficient Kubernetes/OpenShift development
Right out of the box, OpenShift offers a complete CI/CD system, either based on containerized Jenkins and a plugin for working with pipelines, or a Kubernetes-oriented CI / CD system (still in Tech preview version). Both of these solutions integrate fully with the OpenShift console, allowing you to run pipeline triggers, view deployments, view logs, and more.
4. Application tools
OpenShift allows you to deploy both traditional stateful applications and cloud-based solutions based on new architectures, such as microservices or serverless. The OpenShift Service Mesh solution right out of the box is key microservice maintenance tools like Istio, Kiali and Jaeger. In turn, the OpenShift Serverless solution includes not only Knative, but also tools created as part of a joint initiative with Microsoft, such as Keda, to provide Azure functions on the OpenShift platform.
Integrated solution OpenShift ServiceMesh (Istio, Kiali, Jaeger) is useful when developing microservices
To bridge the gap between legacy applications and containers, OpenShift now allows virtual machines to be migrated to the OpenShift platform using Container Native Virtualization (currently in TechPreview), making hybrid applications a reality and facilitating their migration between different clouds, both private and public.
Windows 2019 Virtual machine running on OpenShift via Container Native Virtualization (in Tech preview so far)
5. Tools for clusters
Any enterprise-class platform should have monitoring and centralized logging services, security mechanisms, authentication and authorization, and network management tools. And OpenShift provides it all out of the box, and it's all 100% open source, including solutions like ElasticSearch, Prometheus, Grafana. All of these solutions come with dashboards, metrics, and alerts that are pre-built and configured with Red Hat's extensive experience in cluster monitoring, allowing you to effectively control and monitor your production environment from the first minute.
OpenShift also comes standard with things that are important for a corporate customer, such as authentication with a built-in oauth provider, integration with credential providers, including LDAP, ActiveDirectory, OpenID Connect, and much more.
Preconfigured Grafana Dashboard for OpenShift Cluster Monitoring
Over 150 preconfigured Prometheus metrics and alerts to monitor your OpenShift cluster
To be continued
The rich functionality of the solution and the extensive experience of Red Hat in the field of Kubernetes - it is for these reasons that OpenShift has gained a dominant position in the market, as shown in the figure below (more ).
“Currently, Red Hat leads the market with a 44% share.
The company is reaping the benefits of its participatory sales strategy, in which it first consults and trains enterprise developers, and then moves to monetization as the enterprise begins introducing containers into production.”
(A source: )
We hope you enjoyed this article. In the next posts in this series, we'll take a closer look at the benefits of OpenShift versus Kubernetes in each of the categories discussed here.
Source: habr.com