Get best of the week

What's New in Red Hat OpenShift 4.2 and 4.3?


The fourth version of OpenShift was released relatively recently. The current version 4.3 is available from the end of January and all changes in it are either something completely new, which was not in the third version, or a major update of what appeared in version 4.1. Everything that we will tell you now, you need to know, understand and consider those who work with OpenShift and plan to upgrade to the new version.

With the release of OpenShift 4.2, Red Hat has simplified Kubernetes. New tools and plugins for creating containers, CI / CD pipelines and serverless deployments have appeared. Innovations give developers the opportunity to focus on writing code, rather than litigation with Kubernetes.

Actually, what's new in versions of OpenShift 4.2 and 4.3?

Move towards hybrid clouds


When planning a new IT infrastructure or developing an existing IT landscape, companies are increasingly considering the cloud approach in providing IT resources, for which they implement private cloud solutions, or use the power of public cloud providers. Thus, modern IT infrastructures are increasingly being built on a “hybrid” cloud model, when both on-premises resources and public cloud resources with a common management system are used. Red Hat OpenShift 4.2 is specially designed to simplify the transition to a hybrid cloud model and makes it easy to connect the resources of providers such as AWS, Azure and the Google Cloud Platform to the cluster along with private clouds on VMware and OpenStack.

New installation approach


In version 4, the approach to installing OpenShift has changed. Red Hat provides a special utility for deploying an OpenShift cluster - openshift-install. The utility is the only binary file written in Go. Openshit-installer prepares a yaml file with the configuration required for deployment.

In the case of installation using cloud resources, you will need to specify the minimum information about the future cluster: DNS zone, number of worker nodes, specific settings for the cloud provider, account information for access to the cloud provider. After preparing the configuration file, the cluster can be deployed with one command.

If installing on your own computing resources, for example, when using a private cloud (vSphere and OpenStack are supported) or when installing on bare metal servers, you will need to manually configure the infrastructure - prepare the minimum number of virtual machines or physical servers needed to create a Control Plane cluster, configure network services. After this configuration, the OpenShift cluster can be similarly created with one openshift-installer utility command.

Infrastructure Updates


Integration with CoreOS


A key update is integration with Red Hat CoreOS. Now Red Hat OpenShift master nodes can only work on the new OS. This is a free operating system from Red Hat that is designed specifically for containerized solutions. Red Hat CoreOS is a lightweight Linux optimized for running containers.

If in 3.11 the operating system and OpenShift existed separately, then in 4.2 it is inextricably linked with OpenShift. Now this is a single appliance - immutable infrastructure.


For clusters that use RHCOS for all nodes, updating the OpenShift Container Platform is a simple and well-automated process.

Previously, in order to upgrade OpenShift, it was first necessary to upgrade the underlying operating system on which the product was running (at that time it was Red Hat Enterprise Linux). Only after that it was possible to update OpenShift gradually, node by node. There was no talk about any automation of the process.

Now, since the OpenShift Container Platform fully controls the systems and services on each node, including the OS, this task is solved by pressing a button from the web interface. After that, a special operator is launched inside the OpenShift cluster, which controls the entire update process.

New CSI


The second is the new CSI, the storage interface controller, which allows you to connect various external storage systems to the OpenShift cluster. A large number of storage driver providers for OpenShift are supported based on the storage drivers written by the storage vendors themselves. A complete list of supported CSI drivers can be found in this document: https://kubernetes-csi.imtqy.com/docs/drivers.html . In this list you can find all the main models of disk arrays of leading manufacturers (Dell / EMC, IBM, NetApp, Hitachi, HPE, PureStorage), SDS solutions (Ceph) and cloud storage (AWS, Azure, Google). OpenShift 4.2 supports working with CSI drivers of the CSI version 1.1 specification.

RedHat OpenShift Service Mesh


Based on the Istio, Kiali and Jaeger projects - Red Hat OpenShift Service Mesh, in addition to the usual tasks of routing requests between services, it allows you to trace and visualize them. This helps developers simplify the interaction, monitoring, and management of applications deployed within Red Hat OpenShift.


Visualization of an application with a microservice architecture using Kiali

To simplify the installation, service and life cycle management of Service Mesh, Red Hat OpenShift provides administrators with a special operator - Service Mesh Operator. This is the Kubernetes operator, which allows you to deploy the reconfigured Istio, Kiali, and Jaeger packages on the cluster, minimizing the administrative burden of managing applications.

CRI-O instead of Docker


The default container runtime Docker has been replaced with CRI-O. CRI-O could already be used in version 3.11, but in 4.2 it became the main one. Not good and not bad, but worth keeping in mind when using the product.

Operators and deploy applications


Operators - a new entity for RedHat OpenShift, which appeared in the fourth version. This is a method for packaging, deploying, and managing the Kubernetes application. It can be imagined as a plugin for applications deployed in containers managed using the Kubernetes API and kubectl tools.

Kubernetes operators help automate any tasks related to administering and managing the life cycle of an application that you deploy in your cluster. For example, an operator can automate updates, backing up and scaling an application, change configuration, etc. A complete list of operators can be found at https://operatorhub.io/ .

OperatorHub is available directly from the web interface of the management console. It is an application catalog for OpenShift maintained by Red Hat. Those. all operators approved by Red Hat will be covered by vendor support.


OperatorHub Portal in OpenShift Management Console

Universal base image


This is a standardized set of RHEL OS images that you can use to create your applications in containers. There are minimal, standard and complete sets. They take up very little space, support all the necessary installed packages and programming languages.

CI / CD Tools


RedHat OpenShif 4.2 has the ability to choose between Jenkins and OpenShift Pipelines based on Tekton Pipelines.

OpenShift Pipelines is based on Tekton, which is better supported by the Pipeline as Code and GitOps approaches. In OpenShift pipelines, each step is executed in its own container, so resources are used only during the execution of the step. This gives developers complete control over the module delivery pipelines, plug-ins and access control without a central CI / CD server for management.

OpenShift Pipelines is currently in the Preview stage for developers and is available as an operator on the OpenShift 4 cluster. Of course, OpenShift users can still use Jenkins in RedHat OpenShift 4.

Management Updates for Developers


In 4.2, OpenShift completely updated the web interface for both developers and administrators.

In previous versions of OpenShift, everyone worked in three consoles: a service catalog, an administrator console, and a work console. Now the cluster is divided into only two parts - administrator console and developer console.

The developer console has received significant user interface improvements. Now it is more convenient to display topologies of applications and their assemblies. This makes it easier for developers to create, deploy, and visualize containerized applications and cluster resources. Allows you to focus on what is important to them.


Developer Portal in the OpenShift Management Console

Odo


Odo is a developer-oriented command-line utility that simplifies application development in OpenShift. Using git push style interaction, this CLI helps developers new to Kubernetes build applications in OpenShift.

Integration with development environments


Developers can now create, debug, and deploy their applications in OpenShift without leaving their favorite code development environment, such as Microsoft Visual Studio, JetBrains (including IntelliJ), Eclipse Desktop, etc.

Red Hat OpenShift Deployment extension for Microsoft Azure DevOps


The Red Hat OpenShift Deployment extension for Microsoft Azure DevOps has appeared. Now users of this DevOps toolkit can deploy their applications to Azure Red Hat OpenShift or any other OpenShift cluster directly from Microsoft Azure DevOps.

Transition from the third version to the fourth


Since we are talking about a new release, not an update, it is not so easy to take and put the fourth version on top of the third. Updating from third to fourth version will not be supported .

But there is good news: Red Hat provides tools for moving projects from 3.7 to 4.2. You can transfer application workloads with the Cluster Application Migration (CAM) tool. CAM allows you to control migration and minimize application downtime.

Openshift 4.3


The main innovations described in this article appeared in version 4.2. In the recently released 4.3, the changes are not so significant, but there is still something new. The list of changes is quite extensive, we give the most significant in our opinion:

Update Kubernetes version to 1.16.


The version was upgraded immediately to two steps, in OpenShift 4.2 it was 1.14.

Data Encryption in etcd


Starting with version 4.3, it became possible to encrypt data in the etcd database. After encryption is enabled, it will be possible to encrypt the following OpenShift API and Kubernetes API resources: Secrets, ConfigMaps, Routes, access tokens and OAuth authorization.

Helm


Added support for Helm 3rd version - a popular package manager for Kubernetes. So far, support has the status of TECHNOLOGY PREVIEW. In future versions of OpenShift, Helm support will be expanded to full. The helm cli utility comes with OpenShift and can be downloaded from the Cluster Management Web console.

Project Dashboard Update


In the new version of Project Dashboard provides additional information on the project page: project status, utilization of resources and quotas for the project.

Display vulnerabilities for quay in the web console


Added the function of displaying known vulnerabilities for images in Quay repositories to the management console. Vulnerability mapping for local and external repositories is supported.

Simplified offline operatorhub creation


For the case of deploying an OpenShift cluster on an isolated network, from which Internet access is limited or absent, the creation of a “mirror” for the OperatorHub registry is simplified. Now this can be done with just three teams.

Author: Yuri Semenyukov

More articles:


All Articles