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:
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.
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.
|Custom Resource Definition (CRD)||The CRD is a file in the operator and defines an extension to the Kubernetes API.|
|Cluster Service Version (CSV)||A CSV represents a version of an operator in the cluster.|
|Install Plan (IP)||An Install Plan is a list of resources to be created when installing or updating a CSV.|
|Operator Framework Component||Description|
|Operator||Software makes it easier to manage the lifecycle of applications within a cluster.|
|OperatorHub||A curated collection of operators available to install on a cluster.|
|Operator Registry||An application that provides operator metadata, custom resource definitions (CRDs), and cluster service versions (CSVs) to the OLM.|
|Operator LifeCycle Manager (OLM)||Manages the operator lifecycle, i.e., the installation, updates, and RBAC access for the operator.|
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.
An Elasticsearch resource is an example of a custom resource. You can define a custom Elasticsearch resource like this:
Now, let’s look at the larger OpenShift Operator Framework to understand the full extent of the operator lifecycle relative to the cluster.
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 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 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 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.
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.”
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.
Subscribe to our LinkedIn Newsletter to receive more educational contentSubscribe now