Adding OLM to Kubernetes

On a cluster running Kubernetes version 1.20 or later, deploy OLM by creating the resources described in two manifests: first, the Custom Resource Definitions (CRDs) representing the OLM API, and, second, the custom controller pods where the OLM, catalog, and and package services run.

kubectl create -f \
https://raw.githubusercontent.com/operator-framework/operator-lifecycle-manager/master/deploy/upstream/quickstart/crds.yaml
kubectl create -f \
https://raw.githubusercontent.com/operator-framework/operator-lifecycle-manager/master/deploy/upstream/quickstart/olm.yaml

OLM creates several CRDs for its custom resources. The six key CRDs to know about in order to list and subscribe to Operators from a CatalogSource are:

Key OLM CRDs

CatalogSource

A collection of Operator metadata (ClusterServiceVersions, CRDs, and PackageManifests). OLM uses CatalogSources to build the list of available operators that can be installed from OperatorHub in the OpenShift web console. In OpenShift 4, the web console has added support for managing the out-of-the-box CatalogSources as well as adding your own custom CatalogSources. You can create a custom CatalogSource using the OLM Operator Registry.

Subscription

Relates an operator to a CatalogSource. Subscriptions describe which channel of an operator package to subscribe to and whether to perform updates automatically or manually. If set to automatic, the Subscription ensures OLM will manage and upgrade the operator to ensure the latest version is always running in the cluster.

ClusterServiceVersion (CSV)

The metadata that accompanies your Operator container image. It can be used to populate user interfaces with info like your logo/description/version and it is also a source of technical information needed to run the Operator. It includes RBAC rules and which Custom Resources it manages or depends on. OLM will parse this and do all of the hard work to wire up the correct Roles and Role Bindings, ensuring that the Operator is started (or updated) within the desired namespace and check for various other requirements, all without the end users having to do anything. You can easily build your own CSV with [this handy website](https://operatorhub.io/packages) and read about the [full CSV architecture in more detail](https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/architecture.md#what-is-a-clusterserviceversion).

PackageManifest

An entry in the CatalogSource that associates a package identity with sets of CSVs. Within a package, channels point to a particular CSV. Because CSVs explicitly reference the CSV that they replace, a PackageManifest provides OLM with all of the information that is required to update a CSV to the latest version in a channel (stepping through each intermediate version).

InstallPlan

Calculated list of resources to be created in order to automatically install or upgrade a CSV.

OperatorGroup

Configures all Operators deployed in the same namespace as the OperatorGroup object to watch for their Custom Resource (CR) in a list of namespaces or cluster-wide.

Check these CRDs by running the following command:

kubectl get crd | grep -E 'catalogsource|subscription|clusterserviceversion|packagemanifest|installplan|operatorgroup'

OLM is powered by controllers in the olm namespace, running in three Deployments: catalog-operator, olm-operator, and packageserver:

kubectl -n olm get deployments

Community Operators from OperatorHub.io

Observe the CatalogSources that ship with OLM:

kubectl get catalogsources -n olm

These Operators are maintained in the operator-framework/community-operators GitHub repository and can be listed in your browser at https://operatorhub.io/.

To view the Operators available in the **Community Operators** CatalogSource, get a list of the packagemanifests present on the cluster labeled as being from the operatorhubio-catalog:

kubectl get packagemanifests -l catalog=operatorhubio-catalog