The fourth version of OpenShift was released relatively recently. The current version 4.3 has been available since the end of January and all the 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 are going to tell you now needs to be known, understood and taken into account by those who work with OpenShift and plan to switch to a new version.
With the release of OpenShift 4.2, Red Hat has made it easier to work with Kubernetes. There are new tools and plugins for creating containers, CI/CD pipelines and serverless deployments. Innovations give developers the opportunity to focus on writing code, and not on litigation with Kubernetes.
Actually, what's new in OpenShift 4.2 and 4.3?
Moving towards hybrid clouds
When planning a new IT infrastructure or when developing an existing IT landscape, companies are increasingly considering a 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 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 specifically designed to simplify the transition to a hybrid cloud model and allows you to easily connect resources from providers such as AWS, Azure and Google Cloud Platform to the cluster along with using private clouds on VMware and OpenStack.
A new approach to installation
In the 4th version, 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. The 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 accessing the cloud provider. After preparing the configuration file, the cluster can be deployed with a single command.
In case of installation 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 necessary to create a Control Plane cluster, configure network services. After this configuration, the OpenShift cluster can be similarly created with a single command of the openshift-installer utility.
Infrastructure Updates
Integration with CoreOS
The key update is the integration with Red Hat CoreOS. Red Hat OpenShift master nodes can now work only on the new OS. This is a free operating system from Red Hat, which 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 it is a single appliance - immutable infrastructure.
For clusters that use RHCOS for all nodes, updating the OpenShift Container Platform is a simple and highly automated process.
Previously, in order to update OpenShift, one had to first update the base operating system on which the product was running (Red Hat Enterprise Linux at the time). Only after that it was possible to update OpenShift gradually, node by node. There was no talk of 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, a storage interface controller that 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 storage-drivers that are written by the storage vendors themselves. A complete list of supported CSI drivers can be found in this document: . In this list you can find all the main models of disk arrays from 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 specification version 1.1.
RedHat OpenShift Service Mesh
Based on the projects of Istio, Kiali and Jaeger - Red Hat OpenShift Service Mesh, in addition to the usual tasks of routing requests between services, allows them to be traced and visualized. This helps developers to easily interact with, monitor, and manage an application deployed inside Red Hat OpenShift.
Visualization of an application that has a microservice architecture using Kiali
To make it as easy as possible to install, maintain, and manage the Service Mesh lifecycle, Red Hat OpenShift provides administrators with a special operator, the Service Mesh Operator. This is a Kubernetes operator that allows you to deploy reconfigured packages of Istio, Kiali and Jaeger on the cluster, removing the administrative burden of application management as much as possible.
CRI-O instead of Docker
The default Docker container runtime has been replaced with CRI-O. It was possible to use CRI-O already 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 application deployment
Operators are a new entity for RedHat OpenShift, which appeared in the fourth version. It is a method for packaging, deploying and managing a Kubernetes application. Think of it as a Kubernetes API and kubectl tool-driven plugin for applications deployed in containers.
Kubernetes operators help automate any task related to the administration and lifecycle management of an application that you deploy on your cluster. For example, an operator can automate updates, backups, and application scaling, configuration changes, and so on. The full list of operators can be found at .
OperatorHub is accessible directly from the web interface of the management console. It is a catalog of applications for OpenShift maintained by Red Hat. Those. all operators approved by Red Hat will be covered by vendor support.
Portal OperatorHub in the OpenShift management console
Universal base image
This is a standardized set of RHEL OS images that you can use to build your containerized applications. 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 introduces 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 runs in its own container, so resources are only used while the step is executing. This gives developers complete control over module delivery pipelines, plugins, and access control without a central CI/CD server to manage.
OpenShift Pipelines is currently in developer preview and available as an operator on an OpenShift 4 cluster. Of course, OpenShift users can still use Jenkins on RedHat OpenShift 4.
Developer Management Updates
In 4.2 OpenShift, the web interface has been completely updated for both developers and administrators.
In previous versions of OpenShift, everyone worked in three consoles: the service catalog, the administrator console, and the 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 more conveniently displays the topologies of applications and their assemblies. This makes it easier for developers to create, deploy, and visualize containerized applications and clustered resources. Allows them to focus on what is important to them.
Developer Portal in OpenShift Management Console
Odo
Odo is a developer-oriented command-line utility that simplifies the development of applications 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 build, debug and deploy their applications in OpenShift without leaving their favorite code development environment such as Microsoft Visual Studio, JetBrains (including IntelliJ), Eclipse Desktop, and more.
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 set of DevOps tools 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. Upgrading from version XNUMX to version XNUMX will not be supported.
But there is good news: Red Hat provides tools to migrate projects from 3.7 to 4.2. You can migrate application workloads using the Cluster Application Migration (CAM) tool. CAM allows you to control migration and minimize application downtime.
open shift 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 is still something new. The list of changes is quite extensive, here are the most significant in our opinion:
Update Kubernetes version to 1.16.
The version was upgraded by two steps at once, 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, encryption of the following OpenShift API and Kubernetes API resources will be possible: Secrets, ConfigMaps, Routes, access tokens and OAuth authorization.
Helmet
Added support for Helm version 3, a popular package manager for Kubernetes. While support has the status TECHNOLOGY PREVIEW. Helm support will be expanded to full support in future versions of OpenShift. The helm cli utility is supplied 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 quay vulnerabilities in the web console
Added a function to display known vulnerabilities for images in Quay repositories in the management console. Vulnerability display for local and external repositories is supported.
Simplified creation of offline operatorhub
For the case of deploying an OpenShift cluster in an isolated network with limited or no access to the Internet, the creation of a βmirrorβ for the OperatorHub registry has been simplified. Now it can be done with just three commands.
Authors:
Viktor Puchkov, Yuri Semenyukov
Source: habr.com