GitOpsing Operator Subscriptions in OpenShift

One of the better features of OpenShift is its fantastic support for finding, installing and managing operators from Red Hat’s Certified Operator catalog. Installing operators can be done easily within the OpenShift Operator management console.

However, while this tooling is great for getting things quickly up and running, it’s not very repeatable and requires human clicking through buttons. There are much more automated and repeatable ways to install operators into your cluster using GitOps principles.

OpenShift uses the Operator Lifecycle Manager to help users manage their operators running in the cluster.

Operator Lifecycle Manager (OLM) helps users install, update, and manage the lifecycle of Kubernetes native applications (Operators) and their associated services running across their OpenShift Container Platform clusters. It is part of the Operator Framework, an open source toolkit designed to manage Operators in an effective, automated, and scalable way.
https://docs.openshift.com/container-platform/4.6/operators/understanding/olm/olm-understanding-olm.html#olm-overview_olm-understanding-olm

Long story short, we can get operators installed with some CRs associated with the OLM: Subscription and OperatorGroup.

Namespaces, Operator Groups and Subscriptions

Finding the Details for the Operators

The OpenShift documentation does a really good job describing how to locate and piece together the information needed to install operators via the OpenShift oc cli. To retrieve all the available operators using a specific marketplace, the following command can be used. I usually know what I am looking for, so the added grep allows me to narrow the search.

oc get packagemanifests -n openshift-marketplace | grep <searchterm>

Once I have the exact name of the operator I want to install, I’ll execute the describe command to get the install details of the operator.

oc describe packagemanifests -n openshift-marketplace <operator-name>

The output of the describe can be lengthy as it provides a ton of documentation, similar to man, for the operators along with the needed specs. You will need this output to properly fill in the Subscription object.

Operator Groups

Depending on where you want to install the operator, you may need an OperatorGroup.

An Operator group, defined by an OperatorGroup object, selects target namespaces in which to generate required RBAC access for all Operators in the same namespace as the Operator group.
The namespace to which you subscribe the Operator must have an Operator group that matches the install mode of the Operator, either the AllNamespaces or SingleNamespace mode. If the Operator you intend to install uses the AllNamespaces, then the openshift-operators namespace already has an appropriate Operator group in place.
However, if the Operator uses the SingleNamespace mode and you do not already have an appropriate Operator group in place, you must create one.
https://docs.openshift.com/container-platform/4.6/operators/admin/olm-adding-operators-to-cluster.html#olm-installing-operator-from-operatorhub-using-cli_olm-adding-operators-to-a-cluster

Installing SingleNamespace Operators

For installing operators into a single namespace, you’ll need three manifests. In this example, we will be installing the argocd operator and using kustomize. In the root of the folder, we have the kustomization file.

namespace: argocd

resources:
- argocd-namespace.yaml
- argocd-operator-group.yaml
- argocd-subscription.yaml
- argocd-cluster-role-binding.yaml

In the same folder, the namespace.

kind: Namespace
apiVersion: v1
metadata:
  name: argocd

Next, because we are installing an operator into a new namespace, we will need to setup an OperatorGroup.

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: argocd-operator
spec:
  targetNamespaces:
  - argocd

Then the actual Subscription object. This is where the values

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: argocd-operator
spec:
  channel: alpha
  installPlanApproval: Automatic
  name: argocd-operator
  source: community-operators
  sourceNamespace: openshift-marketplace

All of the values for the spec can be found in the oc describe output above. In addition to the above configuration, argocd needs some additional permissions due to it’s power.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: argocd-application-controller-cluster-admin
subjects:
  - kind: ServiceAccount
    name: argocd-application-controller
    namespace: argocd
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin

Once everything is filled in, apply the configuration and the operator will be installed and started.

oc apply -k .

Installing Cluster Wide Operators (AllNamespaces)

For those operators that will be installed in a cluster wide manner, across all namespaces, it’s the same process without the need for the Namespace or the OperatorGroup. These operators are for cluster centric functionality such as logging, service mesh capabilities and things like OpenShift Pipelines. Here’s some examples for installing the needed operators for OpenShift Service Mesh.

Elasticsearch

namespace: openshift-operators-redhat

resources:
- elasticsearch-operator-subscription.yaml

kind: Subscription
apiVersion: operators.coreos.com/v1alpha1
metadata:
  name: elasticsearch-operator-subscription
spec:
  channel: "4.6"
  name: elasticsearch-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

Jaeger

namespace: openshift-operators

resources:
- jaeger-operator-subscription.yaml

kind: Subscription
apiVersion: operators.coreos.com/v1alpha1
metadata:
  name: jaeger-operator-subscription
spec:
  channel: stable
  name: jaeger-product
  source: redhat-operators
  sourceNamespace: openshift-marketplace

Kiali

namespace: openshift-operators

resources:
- kiali-operator-subscription.yaml

kind: Subscription
apiVersion: operators.coreos.com/v1alpha1
metadata:
  name: kiali-operator-subscription
spec:
  channel: stable
  name: kiali-ossm
  source: redhat-operators
  sourceNamespace: openshift-marketplace

Operators FTW

Operators are a great way to install and manage not only the third party software but also your company’s custom applications. The Operator SDK allows the development in either Go, Ansible and Helm and gives your application developers a way to not only codify the way their applications are installed and upgraded, but also gives them full capabilities to codify more advanced capabilities such as scaling or failover. If you haven’t been using operators to deploy your custom applications, you should give them a shot.