🥉 🖕🏾 📪 OpenShift as an enterprise version of Kubernetes 💣 🚊 💋

“What is the difference between Kubernetes and OpenShift?” - This question arises with enviable constancy. Although in reality it is like asking how a car differs from an engine. If we continue the analogy, then a car is a finished product, you can use it immediately, literally: you sat down and went. On the other hand, in order for the engine to take you somewhere, it must first be supplemented with a host of other things in order to eventually get the same car.

Therefore, Kubernetes is such an engine, around which an automobile (platform) of the OpenShift brand is assembled, which carries you to the goal.

In this article, we want to recall and analyze in more detail the following key points:

Kubernetes is at the heart of the OpenShift platform. And it is 100% Kubernetes certified, fully open source and without the slightest propriety. In short:
- API OpenShift – Kubernetes.
- Kubernetes, - OpenShift. .
OpenShift Kubernetes . , OpenShift , , , . OpenShift . , PaaS- , . Container-as-a-Service .

OpenShift – Kubernetes 100% CNCF

OpenShift is based on Kubernetes Certified . Therefore, after appropriate training, users admire the power of kubectl. And those who switched to OpenShift with Kubernetes Cluster often say how they really like that after redirecting kubeconfig to the OpenShift cluster, all available scripts work flawlessly.

You've probably heard about the OpenShift command line utility called OC. It is fully compatible with kubectl commands, plus it offers several useful helper'ov that are useful when performing a number of tasks. But first, a little more about OC and kubectl compatibility:

Kubectl teams	OC Teams
kubectl get pods	oc get pods
kubectl get namespaces	oc get namespaces
kubectl create -f deployment.yaml	oc create -f deployment.yaml

Here's what the results of using kubectl on the OpenShift API look like:

• kubectl get pods - it is expected to return pods.

• kubectl get namespaces - quite expectedly returns namespaces.

The kubectl create -f mydeployment.yaml command creates kubernetes resources just like on any other Kubernetes platform, as shown in the video below:

In other words, all Kubernetes' APIs are fully accessible in OpenShift with 100% compatibility. That is why OpenShift is recognized by the Cloud Native Computing Foundation (CNCF) as a certified Kubernetes platform .

OpenShift Supports Kubernetes with Useful Features

Kubernetes 'APIs are 100% available in OpenShift, but the regular Kubernetes' kubectl utility is clearly lacking in functionality and convenience. Therefore, Red Hat added Kubernetes with useful features and command-line tools, such as OC (short for OpenShift client) and ODO (OpenShift DO, this utility is intended for developers).

1. The OC utility - a 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, for building container images and deploying applications directly from source code or binary files (Source-to-image, s2i).

Let's look at examples of how built-in helper's and advanced functionality of the OC utility help simplify everyday work.

Example one is namespace management. Each Kubernetes cluster always has multiple namespaces. Usually they are used to create development and production environments, but can also be used to, for example, give each developer a personal “sandbox”. In practice, this leads to the fact that the developer often has to switch between namespaces, since kubectl works in the context of the current space. Therefore, in the case of kubectl, people actively use helper scripts for this. But when using OC to switch to the desired space, it is enough to say “oc project namespace_”.

Don’t remember what the namespace is called? No problem, just type “oc get projects” to display a complete list. Skeptically wondering how this will work if you only have access to a limited subset of namespaces on the cluster? Well, because kubectl does this correctly, only if RBAC allows you to see all the spaces on the cluster, and in large clusters, not everyone gives such authority. So, we answer: for OC this is not a problem at all and it will easily give a complete list in such a situation. It is from such trifles that Openshift's corporate focus and good scalability of this platform in terms of users and applications are made up

2. ODO - 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 intended for developers and allows you to quickly deploy local code on a remote OpenShift cluster. In addition, it can be used to optimize internal processes to instantly synchronize all code changes with containers on a remote OpenShift cluster without having to reassemble, place in the registry and redeploy images.

Let's see how OC and ODO make container and Kubernetes easier.

Just compare a couple of workflows when they are built on the basis of kubectl, and when OC or ODO are used.

• Deployment of code on OpenShift for those who do not speak the YAML language:

Kubernetes / kubectl	$> git clone github.com/sclorg/nodejs-ex.git 1- Dockerfile, ————– FROM node WORKDIR /usr/src/app COPY package*.json ./ COPY index.js ./ COPY ./app ./app RUN npm install EXPOSE 3000 CMD [ “npm”, “start” ] ————– 2- $> podman build … 3- podman login … 4- podman push 5- yaml- (deployment.yaml, service.yaml, ingress.yaml) – 6- manifest-: Kubectl apply -f .
OpenShift / oc	$> oc new-app github.com/sclorg/nodejs-ex.git – __
OpenShift / odo	$> git clone github.com/sclorg/nodejs-ex.git $> odo create component nodejs myapp $> odo push

• : .

Kubernetes / kubectl	1- kubeconfig “myproject” 2- kubectl set-context …
OpenShift / oc	oc project “myproject”

: « , -. ?»

Imagine that you are seated in a racing car and they say: "We put 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 in the course of the championship." How do you like this prospect? We at Red Hat are somehow not very. :)

Therefore, we try to refrain from alpha versions until they are ripe enough, and we do not conduct thorough combat testing and feel that they can be used safely. Usually, everything passes first through the Dev Preview stage, then through Tech Preview, and only then comes out in the form of a public release General Availability (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 their intended functionality, but their implementation is fundamentally different from the one in the alpha version. As thousands and thousands of Red Hat customers use OpenShift to support mission-critical tasks, we place particular emphasis on the stability of our platform and long-term support.

Red Hat deliberately releases frequent OpenShift releases and updates its version of Kubernetes. For example, at the time of writing this article, the GA release of OpenShift 4.3 includes Kubernetes 1.16, which is only one unit behind the upstream version of Kubernetes 1.17. Thus, we try to give the enterprise-class Kubernetes customer and provide additional quality control in the process of releasing new versions of OpenShift.

Software fixes: “There was a hole in that version of Kubernetes that we have in production. And you can close it only by updating three versions up. Or are there options? ”

As part of the Kubernetes open source project, software fixes are usually released as part of the next release, sometimes they cover one or two previous interim releases, which gives coverage only 6 months ago.

Red Hat is justifiably proud of releasing critical fixes earlier than others and providing support for a much longer period. Take, for example, Kubernetes privilege escalation vulnerability ( CVE-2018-1002105 ): it was discovered in Kubernetes 1.11, and patches for previous releases were released only to version 1.10.11, leaving this hole in all previous Kubernetes releases, from 1 .x to 1.9.

In turn, Red Hat patched OpenShift back to version 3.2(Kubernetes 1.2 is standing there), capturing nine OpenShift releases and demonstrating customer care (more info here ).

How OpenShift and Red Hat Move Kubernetes Forward

Red Hat ranks second in terms of software contributions to Kubernetes open source, second only to Google, with 3 of the 5 most prolific developers working for Red Hat. Another little-known fact: many critical functions appeared in Kubernetes precisely at the initiative of Red Hat, in particular, such as:

RBAC. Kubernetes RBAC (ClusterRole, ClusterRoleBinding) , Red Hat , OpenShift. Red Hat Kubernetes? , Red Hat , Open Core. , , , , – .
Security Policies for Pods (Pod Security Policies). Initially, this concept of safe application execution inside pods was implemented in OpenShift under the name SCC (Security Context Constraints). And as in the previous example, Red Hat decided to introduce these developments into the open-source Kubernetes project so that everyone could use them.

This series of examples can be continued, but we just wanted to show that Red Hat is really striving to develop Kubernetes and make it better for everyone.

Clearly, OpenShift is Kubernetes. And what are the differences? :)

We hope that after reading up to this point, you realized that Kubernetes is the main component of OpenShift. Basic, but not the only one. In other words, just by installing Kubernetes you won’t get an enterprise-class platform. You will need to add authentication, network, security, monitoring, log management and more. In addition, you will have to make a difficult choice from the large number of tools available (to assess the diversity of the ecosystem, just look at the CNCF diagram) and somehow ensure coherence and coherence so that they work as a whole. In addition, you will regularly have to perform updating and regression testing when a new version of any of the used components 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 much time will be left here to solve business problems and achieve competitive advantages.

But in the case of OpenShift, Red Hat takes all these difficulties 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 can immediately and completely calmly run in production. And of course, if you have any of your technology stacks, then you can embed OpenShift into your existing solutions.

OpenShift is a smart Kubernetes platform

Take a look at the picture above: everything that is outside the Kubernetes rectangle is the area where Red Hat adds functionality that Kubernetes doesn't have, which is called by-design. And now we will consider the main of these areas.

1. Reliable OS as a basis: RHEL CoreOS or RHEL

For more than 20 years, Red Hat has been a leading provider of Linux distributions for mission-critical business applications. The experience gained and constantly updated in this area allows us to offer a truly reliable and trusted basis for the industrial operation of containers. RHEL CoreOS uses the same core as RHEL, but is optimized primarily for tasks such as running containers and working in Kubernetes clusters: its reduced size and immutability simplifies cluster installation, autoscaling, deployment of fixes, etc. All these features make it an ideal basis for gaining the same user experience when working with OpenShift in a wide variety of computing environments, from bare metal to private and public cloud.

2. Automation of IT operations

Automation of installation processes and operations of the second day (that is, daily operation) is an OpenShift hobbyhorse that 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 by both Red Hat and third-party partners (see the Red Hat operator directory or the operator store operatorhub.io , created by Red Hat for third-party developers).

OpenShift 4 Integrated Directory Includes Over 180 Kubernetes Operators

3. Developer Tools

Since 2011, OpenShift has been available as a PaaS (Platform-as-a-Service) platform, which greatly simplifies the life of developers, helps them focus on code creation and offers built-in support for programming languages such as Java, Node.js, PHP, Ruby, Python, Go, as well as CI / CD continuous integration and delivery services, databases, etc. OpenShift 4 offers an extensive catalog that includes more than 100 services based on Kubernetes operators developed by Red Hat and our partners.

Unlike Kubernetes, OpenShift 4 has a special graphical interface ( Developer Console), which helps developers easily deploy applications in their namespaces from various sources (git, external registries, Dockerfile, etc.) and visually visualize the connections between application components.

Developer Console visualizes application components and simplifies working with Kubernetes.

In addition, OpenShift offers a set of Codeready development tools, which include Codeready Workspaces , a fully containerized web-based IDE that runs directly on top of OpenShift and implements the IDE-like approach service". On the other hand, for those who want to work strictly in local mode, 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 development on the Kubernetes / OpenShift platform.

Right out of the box, OpenShift offers a complete CI / CD system, either based on the containerized Jenkins and the DSL plug-in for pipelines, or the Kubernetes CI / CD-based Tekton system (for now in the Tech preview version). Both of these solutions are fully integrated with the OpenShift console, allowing you to run pipeline triggers, view deployments, logs, etc.

4. Tools for applications

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 to supporting microservice tools like Istio, Kiali and Jaeger. In turn, the OpenShift Serverless solution includes not only Knative, but also tools like Keda, created as part of a joint initiative with Microsoft, to provide Azure functions on the OpenShift platform.

An integrated OpenShift ServiceMesh solution (Istio, Kiali, Jaeger) is useful when developing microservices.

To narrow the gap between legacy applications and containers, OpenShift now allows you to migrate virtual machines to the OpenShift platform using Container Native Virtualization (while in the version in TechPreview), turning hybrid applications into reality and facilitating their transfer between different clouds, both private and public.

Windows 2019 Virtual virtual machine running on OpenShift through Container Native Virtualization (currently in Tech preview version)

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 all this out of the box, and all this is 100% open source, including solutions such as ElasticSearch, Prometheus, Grafana. All of these solutions come with dashboards, metrics and alerts that are already configured and configured based on Red Hat's extensive cluster monitoring experience, which allows you to effectively monitor and track your production environment from the very first minutes.

OpenShift also has such important things for the corporate customer as authentication with the integrated oauth provider, integration with credential providers, including LDAP, ActiveDirectory, OpenID Connect, and much more.

Pre-configured Grafana dashboard for monitoring an OpenShift cluster

Over 150 Prometheus Preconfigured Metrics and Alerts for Monitoring an OpenShift Cluster

To be continued

The rich functionality of the solution and the extensive experience of Red Hat in the field of Kubernetes - for these reasons, OpenShift has taken a dominant position in the market, as shown in the figure below (more details here ).

“At present, Red Hat leads the market with a 44% share.
The company is reaping the benefits of its sales strategy with active participation in customer affairs, in which it first advises and trains corporate developers, and then moves on to monetization as the company begins to introduce containers into production. ”

(Source: www.lightreading.com/nfv/containers/ihs-red-hat-container-strategy-is-paying-off/d/d-id/753863 )

We hope you enjoyed this article. In the next posts in this series, we will take a closer look at the advantages of OpenShift compared to Kubernetes in each of the categories discussed here.

OpenShift as an enterprise version of Kubernetes