Chapter 2. Installing the OpenShift Serverless Operator
You can install the OpenShift Serverless Operator to run Knative Serving, Knative Eventing, and the Knative broker for Apache Kafka on a OpenShift Container Platform cluster. The OpenShift Serverless Operator manages Knative custom resource definitions (CRDs) for the cluster. Configure these resources without modifying individual ConfigMaps for each component.
2.1. OpenShift Serverless Operator resource requirements Copy linkLink copied to clipboard!
The following sample setup might help you to estimate the minimum resource requirements for your OpenShift Serverless Operator installation. Your specific requirements might be significantly different, and might grow as your use of OpenShift Serverless increases.
The test suite used in the sample setup has the following parameters:
An OpenShift Container Platform cluster with:
- 10 workers (8 vCPU, 16GiB memory)
- 3 workers dedicated to Kafka
- 2 workers dedicated to Prometheus
- 5 workers remaining for both Serverless and test deployments
- 89 test scenarios running in parallel, mainly focused on using the control plane. Testing scenarios typically have a Knative Service sending events through an in-memory channel, a Kafka channel, an in-memory broker, or a Kafka broker to either a Deployment or a Knative Service.
- 48 re-creation scenarios, where the testing scenario is repeatedly being deleted and re-created.
- 41 stable scenarios, where events are sent throughout the test run slowly but continuously.
The test setup has, in total:
- 170 Knative Services
- 20 In-Memory Channels
- 24 Kafka Channels
- 52 Subscriptions
- 42 Brokers
- 68 Triggers
The following table details the minimal resource requirements for a Highly-Available (HA) setup discovered by the test suite:
| Component | RAM resources | CPU resources |
|---|---|---|
| OpenShift Serverless Operator | 1GB | 0.2 core |
| Knative Serving | 5GB | 2.5 cores |
| Knative Eventing | 2GB | 0.5 core |
| Knative broker for Apache Kafka | 6GB | 1 core |
| Sum | 14GB | 4.2 cores |
The following table details the minimal resource requirements for a non-HA setup discovered by the test suite:
| Component | RAM resources | CPU resources |
|---|---|---|
| OpenShift Serverless Operator | 1GB | 0.2 core |
| Knative Serving | 2.5GB | 1.2 cores |
| Knative Eventing | 1GB | 0.2 core |
| Knative broker for Apache Kafka | 6GB | 1 core |
| Sum | 10.5GB | 2.6 cores |
2.2. Installing the OpenShift Serverless Operator from the web console Copy linkLink copied to clipboard!
You can install the OpenShift Serverless Operator from the OperatorHub by using the OpenShift Container Platform web console. After installation, run Knative components on the cluster.
Prerequisites
- You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated.
- For OpenShift Container Platform, your cluster has the Marketplace capability enabled or the Red Hat Operator catalog source configured manually.
- You have logged in to the web console.
Procedure
-
In the web console, navigate to the Operators
OperatorHub page. - Scroll, or type the keyword Serverless into the Filter by keyword box to find the OpenShift Serverless Operator.
- Review the information about the Operator and click Install.
On the Install Operator page:
-
The Installation Mode is All namespaces on the cluster (default). This mode installs the Operator in the default
openshift-serverlessnamespace to watch and made available to all namespaces in the cluster. -
The Installed Namespace is
openshift-serverless. Select an Update Channel.
- The stable channel enables installation of the latest stable release of the OpenShift Serverless Operator. The stable channel is the default.
- To install another version, specify the corresponding stable-x.y channel, for example stable-1.29.
- Select the stable channel as the Update Channel. The stable channel will enable installation of the latest stable release of the OpenShift Serverless Operator.
- Select Automatic or Manual approval strategy.
-
The Installation Mode is All namespaces on the cluster (default). This mode installs the Operator in the default
- Click Install to make the Operator available to the selected namespaces on this OpenShift Container Platform cluster.
From the Catalog
Operator Management page, you can monitor the OpenShift Serverless Operator subscription’s installation and upgrade progress. - If you selected a Manual approval strategy, the subscription’s upgrade status will remain Upgrading until you review and approve its install plan. After approving on the Install Plan page, the subscription upgrade status moves to Up to date.
- If you selected an Automatic approval strategy, the upgrade status should resolve to Up to date without intervention.
Verification
After the Subscription’s upgrade status is Up to date, select Catalog
If it does not:
-
Switch to the Catalog
Operator Management page and inspect the Operator Subscriptions and Install Plans tabs for any failure or errors under Status. -
Check the logs in any pods in the
openshift-serverlessproject on the WorkloadsPods page that are reporting issues to troubleshoot further.
2.3. Installing the OpenShift Serverless Operator from the CLI Copy linkLink copied to clipboard!
You can install the OpenShift Serverless Operator from the OperatorHub by using the CLI. After installation, run Knative components on the cluster.
Prerequisites
- You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated.
- For OpenShift Container Platform, your cluster has the Marketplace capability enabled or the Red Hat Operator catalog source configured manually.
- You have logged in to the cluster.
Procedure
Create a YAML file containing
Namespace,OperatorGroup, andSubscriptionobjects to subscribe a namespace to the OpenShift Serverless Operator. For example, create the fileserverless-subscription.yamlsimilar to the following example:--- apiVersion: v1 kind: Namespace metadata: name: openshift-serverless --- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: serverless-operators namespace: openshift-serverless spec: {} --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: serverless-operator namespace: openshift-serverless spec: channel: stable name: serverless-operator source: redhat-operators sourceNamespace: openshift-marketplacespec.channel`-
The channel name of the Operator. The
stablechannel enables installation of the most recent stable version of the OpenShift Serverless Operator. To install another version, specify the correspondingstable-x.ychannel, for examplestable-1.29. spec.name`-
The name of the Operator to subscribe to. For the OpenShift Serverless Operator, this is always
serverless-operator. spec.source`-
The name of the
CatalogSourcethat provides the Operator. Useredhat-operatorsfor the default OperatorHub catalog sources. spec.sourceNamespace`-
The namespace of the
CatalogSource. Useopenshift-marketplacefor the default OperatorHub catalog sources.
Create the
Subscriptionobject:$ oc apply -f serverless-subscription.yaml
Verification
Check that the cluster service version (CSV) has reached the Succeeded phase:
Example command
$ oc get csv
Example output
NAME DISPLAY VERSION REPLACES PHASE
serverless-operator.v1.25.0 Red Hat OpenShift Serverless 1.25.0 serverless-operator.v1.24.0 Succeeded
2.4. OpenShift Serverless Operator global configuration Copy linkLink copied to clipboard!
The OpenShift Serverless Operator manages the global configuration of a Knative installation. It propagates values from the KnativeServing and KnativeEventing custom resources to system ConfigMaps. If you manually update a ConfigMap, the Operator overwrites those changes. You can change the Knative custom resources to set values for these ConfigMaps.
Knative uses many ConfigMaps with the config- prefix. Create all Knative ConfigMaps in the same namespace as the custom resource they apply to. For example, if you create the KnativeServing custom resource in the knative-serving namespace, create all Knative Serving ConfigMaps in the same namespace.
In Knative custom resources, the spec.config field has one <name> entry for each ConfigMap, named config-<name>. Set the value of each entry to define the data field for the corresponding ConfigMap.