The fourth version of OpenShift was released relatively recently. The current version 4.3 has been available since late January, and all changes in it are either something completely new that was not present in the third version or a major update of features that appeared in version 4.1. Everything we discuss here is essential for those working with OpenShift and planning to transition to the new version.
With the release of OpenShift 4.2, Red Hat simplified working with Kubernetes. New tools and plugins for creating containers, CI/CD pipelines, and serverless deployments have been introduced. These innovations allow developers to focus on writing code rather than dealing with Kubernetes.
So, what's new in OpenShift versions 4.2 and 4.3?
Movement towards hybrid clouds
When planning a new IT infrastructure or developing the existing IT landscape, companies increasingly consider a cloud approach to providing IT resources, implementing private cloud solutions, or utilizing the power of public cloud providers. As a result, modern IT infrastructures are often built on a "hybrid" cloud model, which combines both on-premises resources and public cloud resources with a common management system. Red Hat OpenShift 4.2 is specifically designed to simplify the transition to a hybrid cloud model and allows easy integration of resources from providers like AWS, Azure, and Google Cloud Platform alongside using private clouds on VMware and OpenStack.
A new approach to installation
In version 4, the approach to installing OpenShift has changed. Red Hat provides a special utility for deploying an OpenShift cluster – openshift-install. This tool is a single binary file written in Go. The OpenShift installer prepares a yaml file with the configuration needed for deployment.
When installing using cloud resources, you will need to specify minimal information about the future cluster: the DNS zone, the number of worker nodes, specific settings for the cloud provider, and account data for accessing the cloud provider. Once the configuration file is prepared, the cluster can be deployed with a single command.
In the case of installation on private computing resources, such as when using a private cloud (vSphere and OpenStack are supported) or when installing on bare metal servers, manual infrastructure setup will be required – prepare the minimum number of virtual machines or physical servers necessary to create the Control Plane cluster, and configure network services. After this setup, the OpenShift cluster can be created with a single command using the openshift-installer utility.
Infrastructure Updates
Integration with CoreOS
A key upgrade is the integration with Red Hat CoreOS. Now, the master nodes of Red Hat OpenShift can operate only on the new OS. This is a free operating system from Red Hat, specifically designed for container solutions. Red Hat CoreOS is a lightweight Linux optimized for running containers.
Whereas in version 3.11, the operating system and OpenShift existed separately, in version 4.2 they are inseparably linked to OpenShift. Now it 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, to update OpenShift, it was necessary to first update the underlying operating system on which the product was running (at that time, it was Red Hat Enterprise Linux). Only after that could OpenShift be updated gradually, node by node. Automation of the process was not considered.
Now, since the OpenShift Container Platform fully controls the systems and services on each node, including the OS, this task can be accomplished with the press of a button from the web interface. After this, a special operator within the OpenShift cluster is launched to manage the entire update process.
New CSI
The second is the new CSI — a storage interface controller that allows various external storage systems to be connected to the OpenShift cluster. A wide range of storage driver providers is supported for OpenShift based on storage drivers written by the manufacturers of the storage systems. A complete list of supported CSI drivers can be found in this document: This list includes all the main disk array models from leading manufacturers (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), SDS solutions (Ceph), and cloud storage providers (AWS, Azure, Google). OpenShift 4.2 supports working with CSI drivers of CSI specification version 1.1.
RedHat OpenShift Service Mesh
Based on the Istio, Kiali, and Jaeger projects, Red Hat OpenShift Service Mesh not only handles standard request routing between services but also enables tracing and visualization. This helps developers simplify interaction, monitoring, and management of applications deployed within Red Hat OpenShift.
Visualization of an application with a microservices architecture using Kiali
To streamline the installation, service, and lifecycle management processes of Service Mesh, Red Hat OpenShift provides administrators with a dedicated operator – the Service Mesh Operator. This Kubernetes operator allows for the deployment of reconfigured Istio, Kiali, and Jaeger packages on a cluster, significantly reducing the administrative overhead in application management.
CRI-O instead of Docker
The default container runtime Docker has been replaced by CRI-O. CRI-O was available starting from version 3.11, but in 4.2 it became the primary option. It's neither good nor bad, but worth keeping in mind when using the product.
Operators and application deployment
Operators are a new entity for RedHat OpenShift that appeared in version four. They represent a method for packaging, deploying, and managing Kubernetes applications. You can think of them as a plugin managed through the Kubernetes API and kubectl tools for applications deployed in containers.
Kubernetes operators help automate any tasks related to the administration and lifecycle management of applications you deploy in your cluster. For example, an operator can automate updates, backups, scaling the application, changing configurations, etc. A complete list of operators can be found on .
OperatorHub is accessible directly from the web interface of the management console. It serves as a catalog of applications for OpenShift, supported by Red Hat. This means that all operators approved by Red Hat will receive vendor support.
The OperatorHub portal in the OpenShift management console
Universal base image
This is a standardized set of RHEL OS images that can be used to create your applications in containers. There are minimal, standard, and complete sets. They take up very little space, support all necessary installed packages, and programming languages.
CI/CD Tools
In RedHat OpenShift 4.2, the option to choose between Jenkins and OpenShift Pipelines based on Tekton Pipelines has been introduced.
OpenShift Pipelines is based on Tekton, which better supports the Pipeline as Code and GitOps approaches. In OpenShift pipelines, each step runs in its own container, so resources are used only during the execution of that step. This gives developers complete control over module delivery pipelines, plugins, and access control without a central CI/CD server for management.
OpenShift Pipelines is currently in Preview for developers and available as an operator on the OpenShift 4 cluster. Naturally, OpenShift users can still use Jenkins in RedHat OpenShift 4.
Updates in Management for Developers
In 4.2, OpenShift has completely updated the web interface for both developers and administrators.
In previous versions of OpenShift, users worked in three consoles: service catalog, admin console, and work console. Now the cluster is only divided into two parts — the administrator console and the developer console.
The Developer console has received significant user interface improvements. It now displays application topologies and their builds more conveniently. This makes it easier for developers to create, deploy, and visualize container applications and cluster resources. It allows them to focus on what matters to them.
Developer Portal in the OpenShift Management Console
Odo
Odo is a developer-focused command-line utility that simplifies application development in OpenShift. Using a git push-style interaction, this CLI helps developers unfamiliar with Kubernetes create 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 been released. 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.
Transitioning from version three to four
Since this is a new release rather than an update, you cannot simply install the fourth version over the third. The upgrade from the third to the fourth version will not be supported..
But there is good news: Red Hat provides tools for migrating projects from 3.7 to 4.2. You can migrate application workloads using the Cluster Application Migration (CAM) tool. CAM allows you to control the 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 as significant, but there are still some new features. The list of changes is quite extensive; we will highlight the most important ones.
Updated Kubernetes version to 1.16.
The version has stepped up by two levels, as OpenShift 4.2 had 1.14.
Data encryption in etcd
Starting from version 4.3, there is an option to encrypt data in the etcd database. Once encryption is enabled, it will be possible to encrypt the following OpenShift API and Kubernetes API resources: Secrets, ConfigMaps, Routes, access and OAuth authorization tokens.
Helm
Support for Helm version 3 has been added — a popular package manager for Kubernetes. Currently, the support is in TECHNOLOGY PREVIEW status. In future versions of OpenShift, Helm support will be expanded to full. The helm cli utility is included with OpenShift and can be downloaded from the cluster management web console.
Project Dashboard update
In the new version, the Project Dashboard provides additional information on the project page: project status, resource utilization, and project quotas.
Displaying vulnerabilities for Quay in the web console
A feature has been added to the management console to display known vulnerabilities for images in Quay repositories. Vulnerability display is supported for both local and external repositories.
Creation of offline operator hub simplified.
In the case of deploying an OpenShift cluster in an isolated network with limited or no internet access, creating a "mirror" for the OperatorHub registry has been simplified. Now it can be done with just three commands.
Authors:
Victor Puchkov, Yuri Semenyukov
Source: habr.com
