This is a cache of https://docs.openshift.com/container-platform/4.3/operators/olm-understanding-operatorhub.html. It is a snapshot of the page at 2024-11-26T02:18:04.308+0000.
Understanding the OperatorHub | Operators | OpenShift Container Platform 4.3
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history
×

Understanding the OperatorHub

This guide outlines the architecture of the OperatorHub.

Overview of the OperatorHub

The OperatorHub is available via the OpenShift Container Platform web console and is the interface that cluster administrators use to discover and install Operators. With one click, an Operator can be pulled from their off-cluster source, installed and subscribed on the cluster, and made ready for engineering teams to self-service manage the product across deployment environments using the Operator Lifecycle Manager (OLM).

Cluster administrators can choose from OperatorSources grouped into the following categories:

Category Description

Red Hat Operators

Red Hat products packaged and shipped by Red Hat. Supported by Red Hat.

Certified Operators

Products from leading independent software vendors (ISVs). Red Hat partners with ISVs to package and ship. Supported by the ISV.

Community Operators

Optionally-visible software maintained by relevant representatives in the operator-framework/community-operators GitHub repository. No official support.

Custom Operators

Operators you add to the cluster yourself. If you have not added any Custom Operators, the Custom category does not appear in the web console on your OperatorHub.

OperatorHub content automatically refreshes every 60 minutes.

Operators on the OperatorHub are packaged to run on OLM. This includes a YAML file called a ClusterServiceVersion (CSV) containing all of the CRDs, RBAC rules, Deployments, and container images required to install and securely run the Operator. It also contains user-visible information like a description of its features and supported Kubernetes versions.

The Operator SDK can be used to assist developers packaging their Operators for use on OLM and the OperatorHub. If you have a commercial application that you want to make accessible to your customers, get it included using the certification workflow provided by Red Hat’s ISV partner portal at connect.redhat.com.

Additional resources

OperatorHub architecture

The OperatorHub UI component is driven by the Marketplace Operator by default on OpenShift Container Platform in the openshift-marketplace namespace.

The Marketplace Operator manages OperatorHub and OperatorSource Custom Resource Definitions (CRDs).

Although some OperatorSource information is exposed through the OperatorHub user interface, it is only used directly by those who are creating their own Operators.

While OperatorHub no longer uses CatalogSourceConfig resources, they are still supported in OpenShift Container Platform.

OperatorHub CRD

You can use the OperatorHub CRD to change the state of the default OperatorSources provided with OperatorHub on the cluster between enabled and disabled. This capability is useful when configuring OpenShift Container Platform in restricted network environments.

Example OperatorHub Custom Resource
apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
spec:
  disableAllDefaultSources: true (1)
  sources: [ (2)
    {
      name: "community-operators",
      disabled: false
    }
  ]
1 disableAllDefaultSources is an override that controls availability of all default OperatorSources that are configured by default during an OpenShift Container Platform installation.
2 Disable default OperatorSources individually by changing the disabled parameter value per source.

OperatorSource CRD

For each Operator, the OperatorSource CRD is used to define the external data store used to store Operator bundles.

Example OperatorSource Custom Resource
apiVersion: operators.coreos.com/v1
kind: OperatorSource
metadata:
  name: community-operators
  namespace: marketplace
spec:
  type: appregistry (1)
  endpoint: https://quay.io/cnr (2)
  registryNamespace: community-operators (3)
  displayName: "Community Operators" (4)
  publisher: "Red Hat" (5)
1 To identify the data store as an application registry, type is set to appregistry.
2 Currently, Quay is the external data store used by the OperatorHub, so the endpoint is set to https://quay.io/cnr for the Quay.io appregistry.
3 For a Community Operator, registryNamespace is set to community-operator.
4 Optionally, set displayName to a name that appears for the Operator in the OperatorHub UI.
5 Optionally, set publisher to the person or organization publishing the Operator that appears in the OperatorHub UI.