Operators, the software catalog (OperatorHub) and OLM on OpenShift

An Operator is a controller that runs in the cluster and manages an application the way an experienced administrator would: it installs it, configures it, upgrades it and reacts when something breaks. You describe what you want in a custom resource, such as “a PostgreSQL cluster with three replicas”, and the Operator keeps reality matching that description.

Two kinds of Operators in OpenShift

• Cluster Operators make up the platform itself: the API server, the router, the image registry, monitoring, networking and more. They are installed by default and managed by the Cluster Version Operator (CVO), which also drives cluster updates. You inspect them with oc get clusteroperators.
• Add-on Operators are optional software you install, such as databases, GitOps or logging. They are managed by Operator Lifecycle Manager (OLM). OLM does not manage cluster Operators.

oc get clusteroperators
oc get clusteroperator ingress -o yaml

A healthy cluster Operator shows AVAILABLE=True, PROGRESSING=False and DEGRADED=False. A degraded one is usually the first clue when something cluster-wide is wrong.

The software catalog, formerly OperatorHub

In the web console, administrators browse and install add-on Operators from a catalog page. Older versions call it OperatorHub; newer documentation calls it the software catalog. The underlying cluster resource is still an OperatorHub object named cluster, managed by the Marketplace Operator in the openshift-marketplace namespace. It controls which default catalog sources are enabled, which matters in disconnected clusters.

OLM building blocks

• CatalogSource: a catalog of Operators the cluster can install from. OpenShift ships Red Hat, certified and community catalogs; admins can add their own.
• PackageManifest: a read-only view of one Operator in a catalog, listing its channels and supported install modes.
• OperatorGroup: decides which namespaces an Operator watches. Only one per namespace. The openshift-operators namespace already has a global one for Operators that watch all namespaces.
• Subscription: “install this Operator from this catalog and keep it updated from this channel”.
• InstallPlan: the concrete list of resources OLM will create for an install or upgrade. With manual approval, nothing happens until an administrator approves it.
• ClusterServiceVersion (CSV): the installed Operator version, with its deployment, permissions and the custom resource types it provides.

Installing an Operator from the CLI

oc get packagemanifests -n openshift-marketplace
oc describe packagemanifest OPERATOR_NAME -n openshift-marketplace

Note the catalog, the default channel and the supported install modes. For an Operator that watches all namespaces, create the Subscription in openshift-operators:

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: example-operator
  namespace: openshift-operators
spec:
  channel: stable
  name: example-operator
  source: community-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual

oc apply -f subscription.yaml
oc get installplan -n openshift-operators
oc patch installplan INSTALL_PLAN_NAME -n openshift-operators --type merge -p '{"spec":{"approved":true}}'
oc get csv -n openshift-operators

When the CSV phase reaches Succeeded, the Operator is running and its custom resource types are available. For an Operator that only watches its own namespace, first create an OperatorGroup in that namespace whose targetNamespaces lists the namespace, then create the Subscription there.

Automatic or manual updates

With installPlanApproval: Automatic, OLM upgrades the Operator as soon as a new version appears in the channel. The documentation recommends Manual so an administrator can check permission changes and release notes first; pin a starting version with startingCSV if needed.

When an install is stuck

• oc describe subscription NAME -n NAMESPACE shows conditions such as a missing catalog or an unresolvable dependency.
• An InstallPlan waiting with approved: false needs manual approval.
• A CSV stuck in Installing or Failed: check its events and the Operator’s deployment and pods in the same namespace.
• A second OperatorGroup in the same namespace stops installs there.

Official documentation

• Understanding the software catalog
• Adding Operators to a cluster
• Control plane architecture: cluster and add-on Operators