1.5. Understanding OperatorHub
1.5.1. About OperatorHub
OperatorHub is the web console interface in OpenShift Container Platform that cluster administrators use to discover and install Operators. With one click, an Operator can be pulled from its 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 Operator Lifecycle Manager (OLM).
Cluster administrators can choose from Operator sources 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 OperatorHub are packaged to run on OLM. This includes a YAML file called a cluster service version (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 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.
1.5.2. 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
object information is exposed through the OperatorHub UI, it is only used directly by those who are creating their own Operators.
1.5.2.1. OperatorHub
CRD
You can use the OperatorHub
CRD to change the state of the default OperatorSource
objects 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.5.2.2. 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 toappregistry
. - 2
- Currently, Quay is the external data store used by OperatorHub, so the endpoint is set to
https://quay.io/cnr
for the Quay.ioappregistry
. - 3
- For a Community Operator,
registryNamespace
is set tocommunity-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.