OpenShift Operators: Tutorial & Instructions

An OpenShift operator is a core component in a RedHat OpenShift
cluster that extends its capabilities and makes it easier to manage applications. 

An operator encompasses administrative actions into an automated loop. It has logic to ensure the
application is always installed with the same resources and in the same order and can apply automated
updates.

This article will cover three major areas:

• OpenShift Operator components 
• The OpenShift Operator Framework
• How to install an OpenShift Operator from the OpenShift Console

OpenShift Operators executive summary

The operator is a part of a larger system called Operator Lifecycle Management. Each part plays its role
in the extension of the OpenShift cluster APIs.

In this article, we go over the individual components of the operator, such as the CRDs, CSVs, and
install plans which define how to extend the API.

Then we talk about how the operator is part of a larger management cycle where we download the operator
from an operator hub and store the information in a local registry.

To wrap it up, we will go over navigating the web console to search and install an operator from the
OpenShift Marketplace.

Before diving in, let us define some common terms used in this article. 

Summary of Terms

The tables below briefly summarize the cluster resources and components associated with operators and the
OpenShift Operator Framework we will further elaborate on in this article.

OpenShift Operator components

All operators should integrate seamlessly into your OpenShift cluster. They are built to meet a standard
for integration and act as an extension of the OpenShift cluster API.

An operator comes with all the files required to create the expected cluster resources and define
role-based access controls (RBAC).

Let’s start by looking at an operator’s packaging format. Understanding an operator’s makeup will help
lay the foundation for understanding how the operator fits into the total ecosystem.

The Operator Framework introduced a bundle format for packaging operators. The bundle format replaces an
older package manifest format that became unsupported in version 4.8.

There is a bundle for each version of an operator, and it is packaged as a bundle image (a
non-runnable container image). A bundle contains information about the operator, all UI resources needed
to integrate it with the existing web console, and any custom resource definitions (CRDs). 

The files packaged in an operator also include information about any annotations and dependencies the
operator needs to integrate successfully.

A Cluster Service Version (CSV) represents a single version of an operator. You could think about it the
same way you think about an RPM or a deb package. It is a similar idea. 

A custom resource definition (CRD) extends the cluster’s API. In OpenShift/Kubernetes, APIs define
resource objects such as pods, replica sets, routes, etc.

As an example, a common resource is a pod. In the YAML excerpt below, notice the line “kind: Pod.” which
defines the resource. 

kind: Pod
                    apiVersion: v1
                    metadata:

An Elasticsearch resource is an example of a custom resource. You can define a custom Elasticsearch
resource like this:

apiVersion: elasticsearch.k8s.elastic.co/v1
                        kind: Elasticsearch

The OpenShift Operator Framework

Now, let’s look at the larger OpenShift Operator Framework to understand the full extent of the operator
lifecycle relative to the cluster. 

The role of an OpenShift Operator

Above, we described the makeup of an operator. Here we outline the role of the operator.

The operator is one of the core components of an OpenShift cluster. Kubernetes has a concept of a
controller. Put plainly, a controller is a control loop that monitors the state of the cluster and takes
actions to ensure the current state matches the desired state within the cluster.

For example, if a cluster’s desired state is to have ten pods running, but only eight are running, the
controller ensure the cluster deploys two more pods. The pods will be deployed precisely as they are
defined, with the correct image, in the proper order, and with the proper annotations and other
metadata.

Building off that idea, an OpenShift operator is an application-specific, custom controller. 

OpenShift groups operators into either cluster operators or all other operators. The cluster operators
are those that keep the OpenShift cluster running. All of the other operators are more application
specific. In this article, we’re referring to application-specific operators when installing an operator
from the OpenShift Marketplace.

The OperatorHub

The OperatorHub is the place to search for and install operators. It is built into the OpenShift web
console and is the gateway to various curated operators from Red Hat, the Kubernetes community, and
other vetted vendors.

Regarding the cluster, the operator hub is run by the openshift-marketplace operator. We note this to
highlight how OpenShift uses operators to manage other operators.

When an operator is installed, it creates a subscription and install plan for the operator.

A subscription associates a software channel with the operator. An install plan lists all of the
resources that need to be created for the operator. 

One last thing to note is the OperatorHub is a curated and vetted set of operators, but the support
varies by vendor. Check the specific operator’s documentation for details.

The Operator Registry

The OperatorHub is the gateway to installing operators on your cluster. The registry is where they are
stored locally on the cluster.

Each OpenShift cluster has an operator registry built in. It stores the CRDs and operator metadata
locally on the cluster so it is ready for deployment.

The operator lifecycle manager (OLM) consults the registry for the resources it needs to run the
application. 

The Operator Lifecycle Manager (OLM)

The operator lifecycle manager comprises the OLM operator and the catalog operator.

The OLM operator manages the installed operator’s lifecycle, including installing and updating the
operator’s software. 

The catalog operator ensures the cluster state outlined in the cluster service version (CSV) is deployed.
It also monitors the registry for updates and can automatically apply them.

How to install an OpenShift Operator from the OpenShift Console

In this section, we will explain how to install an operator from the OperatorHub in the OpenShift web
console. Installing an operator via the web console is the easiest way to add software and extend the
power of your OpenShift cluster. 

For our example, we will install the ElasticSearch operator RedHat provides. 

Please note this operator is meant to be integrated with other Red Hat operators and services. In our
case, installing this operator is simply for demo purposes. Our demo only covers installing the
operator. Each operator will have application-specific configurations that are outside of the scope
of this article. 

Step 1 – Select Operators on the left-hand menu from the web console and click on
Operator Hub. Search for ElasticSearch and select the OpenShift ElasticSearch Operator

Step 2 – There will be a preview screen where you can see some of the details for the
operator. This page will often provide details of the operator software. Once you have read the
information, click “Install.”

Step 3 – On the next screen is the option to choose the channel (subscription),
installation mode (automatic or manual), and the installed namespace. Unless you have other specific
requirements, the default openshift-operators-redhat is a suitable namespace. 

Once the installation is complete, click on View Operator to see the installation results. Uninstalling
an operator is as simple as selecting “Actions” and “Uninstall Operator.”

Conclusion

OpenShift Operators play a vital role in OpenShift clusters. Their power lies in being able to integrate
and extend the capabilities of the cluster as well as automatically manage software installation and
updates.

This article explained that an OpenShift Operator is a set of files bundled into a non-runnable image.
The bundle includes the operator metadata, CSVs, CRDs, images, and annotations.

We learned that the operator is part of a more extensive framework comprising the operator hub, the
operator registry, and the operator lifecycle manager. Each component is essential in automating this
process as much as possible.

The big takeaway is that an operator can automate the actions of a systems administrator and ensure that
the software deploys the same way every time. The operator can ensure the application is updated the
same way every time. It reduces the chance that a step is skipped, a backup isn’t taken, and general
human error.

Operators make it easier to manage an OpenShift cluster. If you need to add features to the cluster, look
at the OperatorHub for supported operators first.