A look into Kubernetes Operator Lifecycle Manager (OLM)

Operators are vital part in Kubernetes ecosystem. It helps us install and manage software/service without the need for any manual intervention throughout the usage. 

One such use case could be installing a fully managed PostgreSQL cluster in a Kubenetes native way.

Such Operators could be installed in many different ways and installing it through the Operator Lifecycle Manager (OLM) is one such way.

OLM helps us to install an operator by requesting it through set of Kubernetes CRD that are known to it.

Lets go through OLM process and understand Kubernetes CRDs involved with that.

Prerequisites

OLM is installed in your cluster.

Create OperatorGroup

Typically OLM has a cluster wide access and it could provide any access which is requested by an operator, therefore, OperatorGroup is used by OLM to limit the scope of the operator to a single namespace or multiple namespaces.

Scuh OperatorGroup should be requested to target a set of namespaces using the OperatorGroup CRD provided by OLM. 

Any operators created in those targeted namespaces will become a part of that OperatorGroup and this enabled cluster admins to scope the operator permission to limited namespaces.

Following OperatorGroup is one such example where it targets a single namespace called my-namespace, it uses targetNamespace field to assign an operators, created in a namespace, within its group.

apiVersion: operators.coreos.com/v1alpha2
kind: OperatorGroup
metadata:
  name: my-group
  namespace: my-namespace
spec:
  targetNamespaces:
  - my-namespace

An OperatorGroup may target one or more namespaces through its targetNamespaces field.

Create Subscription

Subscription is the CRD contains enough information to let OLM know what kind of Operator we need in our namespace.

Subscription simply contains the information about the CatalogSource name, its namespace, operator name, and the operator version.

Following is one such sample Subscription requesting a CloudNativePG operator.

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cloudnative-pg
  namespace: my-namespace
spec:
  channel: v1.22.1
  name: cloudnative-pg
  source: community-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic

what is meant by above Subscription is, look for an operator named cloudnative-pg with release line v1.22.1 from the CatalogSource named community-operators which present in the namespace openshift-marketplace.

CatalogSource is more like a store which contains set of operators it knows on how to install them or more specifically its ClusterServiceVersion.

What is ClusterServiceVersion (CSV)

ClusterServiceVersion resource contains operator installation specification such as InstallModes, required permission, deployment template, CustomResourceDefinitions and etc.

One thing to note is that a operator will be assigned to a specific OperatorGroup only when OperatorGroup targetNamespaces type matches one of ClusterServiceVersion InstallModes.

E.g. Operator which supports OwnNamespace install mode can get assinged to an OperatorGroup that targets single namespace and its where the operator is installed.

InstallPlan

With the help of Subscription OLM will create an InstallPlan resource which contains the selected ClusterServiceVersion for the installation and its state of approval for the installation procedure.

If the Subscription's installPlanApproval is automatic then OLM will go ahead and install the operator components into the namespace using the selected ClusterServiceVersion resource. Otherwise an approval should be given explicitly to install the operator.

To sum all up, following is a simple illustrate on how resources are connected when an operator is deployed using OLM.