Adding Operators to a cluster

    • Ensure that you have downloaded the pull secret from the Red Hat OpenShift Cluster Manager site as shown in Obtaining the installation program in the installation documentation for your platform.

      If you have the pull secret, add the catalog to the OperatorHub custom resource (CR) as shown in Configuring OKD to use Red Hat Operators.

    About Operator installation with OperatorHub

    OperatorHub is a user interface for discovering Operators; it works in conjunction with Operator Lifecycle Manager (OLM), which installs and manages Operators on a cluster.

    As a cluster administrator, you can install an Operator from OperatorHub using the OKD web console or CLI. Subscribing an Operator to one or more namespaces makes the Operator available to developers on your cluster.

    During installation, you must determine the following initial settings for the Operator:

    Installation Mode

    Choose All namespaces on the cluster (default) to have the Operator installed on all namespaces or choose individual namespaces, if available, to only install the Operator on selected namespaces. This example chooses All namespaces…​ to make the Operator available to all users and projects.

    Update Channel

    If an Operator is available through multiple channels, you can choose which channel you want to subscribe to. For example, to deploy from the stable channel, if available, select it from the list.

    Approval Strategy

    You can choose automatic or manual updates.

    If you choose automatic updates for an installed Operator, when a new version of that Operator is available in the selected channel, Operator Lifecycle Manager (OLM) automatically upgrades the running instance of your Operator without human intervention.

    If you select manual updates, when a newer version of an Operator is available, OLM creates an update request. As a cluster administrator, you must then manually approve that update request to have the Operator updated to the new version.

    You can install and subscribe to an Operator from OperatorHub using the OKD web console.

    Prerequisites

    • Access to an OKD cluster using an account with cluster-admin permissions.

    Procedure

    1. Navigate in the web console to the Operators → OperatorHub page.

    2. Scroll or type a keyword into the Filter by keyword box to find the Operator you want. For example, type advanced to find the Advanced Cluster Management for Kubernetes Operator.

      You can also filter options by Infrastructure Features. For example, select Disconnected if you want to see Operators that work in disconnected environments, also known as restricted network environments.

    3. Select the Operator to display additional information.

    4. Read the information about the Operator and click Install.

    5. On the Install Operator page:

      1. Select one of the following:

        • All namespaces on the cluster (default) installs the Operator in the default openshift-operators namespace to watch and be made available to all namespaces in the cluster. This option is not always available.

        • A specific namespace on the cluster allows you to choose a specific, single namespace in which to install the Operator. The Operator will only watch and be made available for use in this single namespace.

      3. Select Automatic or Manual approval strategy, as described earlier.

    6. Click Install to make the Operator available to the selected namespaces on this OKD cluster.

      1. If you selected a Manual approval strategy, the upgrade status of the subscription remains Upgrading until you review and approve the install plan.

        After approving on the Install Plan page, the subscription upgrade status moves to Up to date.

      2. If you selected an Automatic approval strategy, the upgrade status should resolve to Up to date without intervention.

    7. After the upgrade status of the subscription is Up to date, select Operators → Installed Operators to verify that the cluster service version (CSV) of the installed Operator eventually shows up. The Status should ultimately resolve to InstallSucceeded in the relevant namespace.

      If it does not:

      1. Check the logs in any pods in the openshift-operators project (or other relevant namespace if A specific namespace…​ installation mode was selected) on the Workloads → Pods page that are reporting issues to troubleshoot further.

    Installing from OperatorHub using the CLI

    Instead of using the OKD web console, you can install an Operator from OperatorHub using the CLI. Use the oc command to create or update a Subscription object.

    Prerequisites

    • Access to an OKD cluster using an account with cluster-admin permissions.

    • Install the oc command to your local system.

    Procedure

    1. View the list of Operators available to the cluster from OperatorHub:

      Example output

      1. 3scale-operator                    Red Hat Operators     91m
      2. advanced-cluster-management        Red Hat Operators     91m
      3. amq7-cert-manager                  Red Hat Operators     91m
      4. ...
      5. couchbase-enterprise-certified     Certified Operators   91m
      6. crunchy-postgres-operator          Certified Operators   91m
      7. mongodb-enterprise                 Certified Operators   91m
      8. ...
      9. etcd                               Community Operators   91m
      10. jaeger                             Community Operators   91m
      11. kubefed                            Community Operators   91m
      12. ...

      Note the catalog for your desired Operator.

    2. Inspect your desired Operator to verify its supported install modes and available channels:

      1. $ oc describe packagemanifests <operator_name> -n openshift-marketplace

    3. An Operator group, defined by an OperatorGroup object, selects target namespaces in which to generate required RBAC access for all Operators in the same namespace as the Operator group.

      The namespace to which you subscribe the Operator must have an Operator group that matches the install mode of the Operator, either the AllNamespaces or SingleNamespace mode. If the Operator you intend to install uses the , then the openshift-operators namespace already has an appropriate Operator group in place.

      However, if the Operator uses the SingleNamespace mode and you do not already have an appropriate Operator group in place, you must create one.

      1. Create an OperatorGroup object YAML file, for example operatorgroup.yaml:

        Example OperatorGroup object

      2. Create the OperatorGroup object:

        1. $ oc apply -f operatorgroup.yaml

    4. Create a Subscription object YAML file to subscribe a namespace to an Operator, for example sub.yaml:

      Example Subscription object

      1. apiVersion: operators.coreos.com/v1alpha1
      2. kind: Subscription
      3. metadata:
      4.   name: <subscription_name>
      5.   namespace: openshift-operators (1)
      6. spec:
      7.   channel: <channel_name> (2)
      8.   name: <operator_name> (3)
      9.   sourceNamespace: openshift-marketplace (5)

    5. At this point, OLM is now aware of the selected Operator. A cluster service version (CSV) for the Operator should appear in the target namespace, and APIs provided by the Operator should be available for creation.

    Additional resources

    You can install a specific version of an Operator by setting the cluster service version (CSV) in a Subscription object.

    Prerequisites

    • Access to an OKD cluster using an account with cluster-admin permissions

    • OpenShift CLI (oc) installed

    Procedure

    1. Create a Subscription object YAML file that subscribes a namespace to an Operator with a specific version by setting the startingCSV field. Set the installPlanApproval field to Manual to prevent the Operator from automatically upgrading if a later version exists in the catalog.

      For example, the following sub.yaml file can be used to install the Red Hat Quay Operator specifically to version 3.4.0:

      Subscription with a specific starting Operator version

      1. apiVersion: operators.coreos.com/v1alpha1
      2. kind: Subscription
      3. metadata:
      4.   name: quay-operator
      5.   namespace: quay
      6. spec:
      7.   channel: quay-v3.4
      8.   installPlanApproval: Manual (1)
      9.   name: quay-operator
      10.   source: redhat-operators
      11.   sourceNamespace: openshift-marketplace
      12.   startingCSV: quay-operator.v3.4.0 (2)

    2. Create the Subscription object:

      1. $ oc apply -f sub.yaml

    3. Manually approve the pending install plan to complete the Operator installation.

    Additional resources

    Pod placement of Operator workloads

    By default, Operator Lifecycle Manager (OLM) places pods on arbitrary worker nodes when installing an Operator or deploying Operand workloads. As an administrator, you can use projects with a combination of node selectors, taints, and tolerations to control the placement of Operators and Operands to specific nodes.

    Controlling pod placement of Operator and Operand workloads has the following prerequisites:

    1. Determine a node or set of nodes to target for the pods per your requirements. If available, note an existing label, such as node-role.kubernetes.io/app, that identifies the node or nodes. Otherwise, add a label, such as myoperator, by using a machine set or editing the node directly. You will use this label in a later step as the node selector on your project.

    2. If you want to ensure that only pods with a certain label are allowed to run on the nodes, while steering unrelated workloads to other nodes, add a taint to the node or nodes by using a machine set or editing the node directly. Use an effect that ensures that new pods that do not match the taint cannot be scheduled on the nodes. For example, a myoperator:NoSchedule taint ensures that new pods that do not match the taint are not scheduled onto that node, but existing pods on the node are allowed to remain.

    3. Create a project that is configured with a default node selector and, if you added a taint, a matching toleration.

    At this point, the project you created can be used to steer pods towards the specified nodes in the following scenarios:

    For Operator pods

    Administrators can create a Subscription object in the project. As a result, the Operator pods are placed on the specified nodes.

    For Operand pods

    Using an installed Operator, users can create an application in the project, which places the custom resource (CR) owned by the Operator in the project. As a result, the Operand pods are placed on the specified nodes, unless the Operator is deploying cluster-wide objects or resources in other namespaces, in which case this customized pod placement does not apply.

    Additional resources