How to install an Operator from OperatorHub.io

How do I install an Operator from OperatorHub.io?

In order to install an Operator from OperatorHub.io, first be sure that you have a Kubernetes cluster (v1.7 or newer) running with privileges to create new namespaces, ClusterRoles, ClusterRoleBindings and CustomResourceDefinitions. The Operator Lifecycle Manager (OLM), a component of the Operator Framework, must also be present in your cluster. OLM makes Operators available for users to install based on the concept of catalogswhich are repositories of Operators packaged for use with OLM. If you like to learn more about how OLM delivers Operators, click here.

From there, simply click Install on any Operators detail page. To use the Operator without this component, manual installation is usually documented on the website or in the source code repository of the Operator maintainers.

How do I get Operator Lifecycle Manager?

A quick way to install OLM on a Kubernetes cluster with default settings and appropriate permission is by running this command:

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

This will deploy OLM, which consists of two Operators (catalog-operator and olm-operator) running in Pods in the olm namespace. OLM is now ready to run.

If you receive permission errors running the above command referring to a failed attempt to grant extra privileges to the system:controller:operator-lifecycle-manager service account, please kubectl delete -f the above command and add more privileges to your current user:

kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user [USER_NAME]

Then retry to install OLM.

What happens when I execute the 'Install' command presented in the pop-up?

Once OLM is in your cluster you can execute the provided quick install command. Behind the provided URL, OperatorHub.io generates YAML manifests required to deploy an Operator.

The quick install command generates YAML that makes assumptions about the default catalogs that ship with upstream OLM. If you make modifications or have an existing OLM deployment that deviates please adjust the generated YAML manifests.

These create the following resources:

1. A CatalogSource object that represents a catalog of all the Operators found on OperatorHub.io, so OLM knows where to download the Operator
2. A Subscription object that represents your intent to deploy an Operator via OLM, triggering the actual installation

Optionally, if the Operator is only able to work in a particular namespace, also the following gets created:

3. An OperatorGroup object that configures the Operator to only watch for the CustomResourceDefinitions in the namespace it’s deployed in
4. A separate namespace, named after the Operator, in which the Operator following the scheme my-<operator-name>, in which the Operator and all the resources above

This difference will be called out in the Installation dialog.

When executed it typically takes between 20-30 seconds to deploy an Operator. You can watch it’sClusterServiceVersion spin up in either the namespace called operators or the namespace created by the install command (if applicable).

See below for an example of the output from deploying the EtcdOperator:

$ kubectl get csv -n my-etcd -w
NAME                  AGE
etcdoperator.v0.9.2   <invalid>
etcdoperator.v0.9.2   <invalid>
etcdoperator.v0.9.2   <invalid>
etcdoperator.v0.9.2   <invalid>
etcdoperator.v0.9.2   0s
etcdoperator.v0.9.2   5s

After a while the Operator will be stood up in the form of a Pod:

$ kubectl get pod -n operators
NAME                            READY   STATUS    RESTARTS   AGE
etcd-operator-9d7b7b6f8-7ghbg   3/3     Running   0          58s
operatorhubio-catalog-pf9hk     1/1     Running   0          87s

Next to the Pod for the EtcdOperator you see the Pod the serving the catalog from OperatorHub.io to OLM.

You can now start using the Operator by leveraging it’s CustomResource. The Operator detail page contains examples of these in the CustomResourceDefinitions section

Important: Most Operators are available in all namespaces in your cluster. Some however do not support this. That means, that any of its CustomResources need to be placed in a specific namespace that the Operator is watching. For Operators from OperatorHub.io this namespace is called my-<operator-name>. Also the Operators Pod will be deployed there.

This behavior is controlled by the OperatorGroup , you can read more about it here. In short, the list in spec.targetNamespace of the OperatorGroup and controls namespaces in which you want this Operator to be usable.