Managing platform Operators (Technology Preview)

Managing platform Operators (Technology Preview)

A platform Operator is an OLM-based Operator that can be installed during or after an OpenShift Container Platform cluster’s Day 0 operations and participates in the cluster’s lifecycle. As a cluster administrator, you can manage platform Operators by using the PlatformOperator API.

The platform Operator type is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

About platform Operators

Operator Lifecycle Manager (OLM) introduces a new type of Operator called platform Operators. A platform Operator is an OLM-based Operator that can be installed during or after an OKD cluster’s Day 0 operations and participates in the cluster’s lifecycle. As a cluster administrator, you can use platform Operators to further customize your OKD installation to meet your requirements and use cases.

Using the existing cluster capabilities feature in OKD, cluster administrators can already disable a subset of Cluster Version Operator-based (CVO) components considered non-essential to the initial payload prior to cluster installation. Platform Operators iterate on this model by providing additional customization options. Through the platform Operator mechanism, which relies on resources from the RukPak component, OLM-based Operators can now be installed at cluster installation time and can block cluster rollout if the Operator fails to install successfully.

In OKD 4.12, this Technology Preview release focuses on the basic platform Operator mechanism and builds a foundation for expanding the concept in upcoming releases. You can use the cluster-wide PlatformOperator API to configure Operators before or after cluster creation on clusters that have enabled the TechPreviewNoUpgrades feature set.

Additional resources

Technology Preview restrictions for platform Operators

During the Technology Preview release of the platform Operators feature in OKD 4.12, the following restrictions determine whether an Operator can be installed through the platform Operators mechanism:

Kubernetes manifests must be packaged using the Operator Lifecycle Manager (OLM) registry+v1 bundle format.
The Operator cannot declare package or group/version/kind (GVK) dependencies.
The Operator cannot specify cluster service version (CSV) install modes other than AllNamespaces
The Operator cannot specify any Webhook or APIService definitions.
All package bundles must be in the redhat-operators catalog source.

After considering these restrictions, the following Operators can be successfully installed:

Table 1. OLM-based Operators installable as platform Operators
3scale-operator	amq-broker-rhel8
amq-online	amq-streams
ansible-cloud-addons-operator	apicast-operator
container-security-operator	eap
file-integrity-operator	gatekeeper-operator-product
integration-operator	jws-operator
kiali-ossm	node-healthcheck-operator
odf-csi-addons-operator	odr-hub-operator
openshift-cert-manager-operator	openshift-custom-metrics-autoscaler-operator
openshift-gitops-operator	openshift-pipelines-operator-rh
quay-operator	red-hat-camel-k
rhpam-kogito-operator	service-registry-operator
servicemeshoperator	skupper-operator

The following features are not available during this Technology Preview release:

Automatically upgrading platform Operator packages after cluster rollout
Extending the platform Operator mechanism to support any optional, CVO-based components

Prerequisites

Access to an OKD cluster using an account with cluster-admin permissions.
The TechPreviewNoUpgrades feature set enabled on the cluster.

Enabling the TechPreviewNoUpgrade feature set cannot be undone and prevents minor version updates. These feature sets are not recommended on production clusters.
Only the redhat-operators catalog source enabled on the cluster. This is a restriction during the Technology Preview release.
The oc command installed on your workstation.

Additional resources

Installing platform Operators during cluster creation

As a cluster administrator, you can install platform Operators by providing FeatureGate and PlatformOperator manifests during cluster creation.

Procedure

Choose a platform Operator from the supported set of OLM-based Operators. For the list of this set and details on current limitations, see “Technology Preview restrictions for platform Operators”.
Select a cluster installation method and follow the instructions through creating an install-config.yaml file. For more details on preparing for a cluster installation, see “Selecting a cluster installation method and preparing it for users”.
After you have created the install-config.yaml file and completed any modifications to it, change to the directory that contains the installation program and create the manifests:
```
$ ./openshift-install create manifests --dir <installation_directory> (1)
```
1 For <installation_directory>, specify the name of the directory that contains the install-config.yaml file for your cluster.

Create a FeatureGate object YAML file in the <installation_directory>/manifests/ directory that enables the TechPreviewNoUpgrade feature set, for example a feature-gate.yaml file:

Example feature-gate.yaml file

apiVersion: config.openshift.io/v1
kind: FeatureGate
metadata:
  annotations:
    include.release.openshift.io/self-managed-high-availability: "true"
    include.release.openshift.io/single-node-developer: "true"
    release.openshift.io/create-only: "true"
  name: cluster
spec:
  featureSet: TechPreviewNoUpgrade (1)

1	Enable the `TechPreviewNoUpgrade` feature set.

Create a PlatformOperator object YAML file for your chosen platform Operator in the <installation_directory>/manifests/ directory, for example a cert-manager.yaml file for the cert-manager Operator for Red Hat OpenShift:

Example cert-manager.yaml file
```
apiVersion: platform.openshift.io/v1alpha1
kind: PlatformOperator
metadata:
  name: cert-manager
spec:
  package:
    name: openshift-cert-manager-operator
```
When you are ready to complete the cluster install, refer to your chosen installation method and continue through running the openshift-install create cluster command.

During cluster creation, your provided manifests are used to enable the TechPreviewNoUpgrade feature set and install your chosen platform Operator.

Failure of the platform Operator to successfully install will block the cluster installation process.

Verification

Check the status of the cert-manager platform Operator by running the following command:

$ oc get platformoperator cert-manager -o yaml

Example output

...
status:
  activeBundleDeployment:
    name: cert-manager
  conditions:
  - lastTransitionTime: "2022-10-24T17:24:40Z"
    message: Successfully applied the cert-manager BundleDeployment resource
    reason: InstallSuccessful
    status: "True" (1)
    type: Installed

1	Wait until the `Installed` status condition reports `True`.

Verify that the platform-operators-aggregated cluster Operator is reporting an Available=True status:

$ oc get clusteroperator platform-operators-aggregated -o yaml

Example output

...
status:
  conditions:
  - lastTransitionTime: "2022-10-24T17:43:26Z"
    message: All platform operators are in a successful state
    reason: AsExpected
    status: "False"
    type: Progressing
  - lastTransitionTime: "2022-10-24T17:43:26Z"
    status: "False"
    type: Degraded
  - lastTransitionTime: "2022-10-24T17:43:26Z"
    message: All platform operators are in a successful state
    reason: AsExpected
    status: "True"
    type: Available

Additional resources

Installing platform Operators after cluster creation

As a cluster administrator, you can install platform Operators after cluster creation on clusters that have enabled the TechPreviewNoUpgrades feature set by using the cluster-wide PlatformOperator API.

Procedure

Choose a platform Operator from the supported set of OLM-based Operators. For the list of this set and details on current limitations, see “Technology Preview restrictions for platform Operators”.
Create a PlatformOperator object YAML file for your chosen platform Operator, for example a cert-manager.yaml file for the cert-manager Operator for Red Hat OpenShift:

Example cert-manager.yaml file
```
apiVersion: platform.openshift.io/v1alpha1
kind: PlatformOperator
metadata:
  name: cert-manager
spec:
  package:
    name: openshift-cert-manager-operator
```

Create the PlatformOperator object by running the following command:

$ oc apply -f cert-manager.yaml

If your cluster does not have the TechPreviewNoUpgrades feature set enabled, the object creation fails with the following message:

error: resource mapping not found for name: “cert-manager” namespace: “” from “cert-manager.yaml”: no matches for kind “PlatformOperator” in version “platform.openshift.io/v1alpha1”
ensure CRDs are installed first

Verification

Check the status of the cert-manager platform Operator by running the following command:

$ oc get platformoperator cert-manager -o yaml

Example output

...
status:
  activeBundleDeployment:
    name: cert-manager
  conditions:
  - lastTransitionTime: "2022-10-24T17:24:40Z"
    message: Successfully applied the cert-manager BundleDeployment resource
    reason: InstallSuccessful
    status: "True" (1)
    type: Installed

1	Wait until the `Installed` status condition reports `True`.

Verify that the platform-operators-aggregated cluster Operator is reporting an Available=True status:

$ oc get clusteroperator platform-operators-aggregated -o yaml

Example output

...
status:
  conditions:
  - lastTransitionTime: "2022-10-24T17:43:26Z"
    message: All platform operators are in a successful state
    reason: AsExpected
    status: "False"
    type: Progressing
  - lastTransitionTime: "2022-10-24T17:43:26Z"
    status: "False"
    type: Degraded
  - lastTransitionTime: "2022-10-24T17:43:26Z"
    message: All platform operators are in a successful state
    reason: AsExpected
    status: "True"
    type: Available

Additional resources

Technology Preview restrictions for platform Operators

Deleting platform Operators

As a cluster administrator, you can delete existing platform Operators. Operator Lifecycle Manager (OLM) performs a cascading deletion. First, OLM removes the bundle deployment for the platform Operator, which then deletes any objects referenced in the registry+v1 type bundle.

The platform Operator manager and bundle deployment provisioner only manage objects that are referenced in the bundle, but not objects subsequently deployed by any bundle workloads themselves. For example, if a bundle workload creates a namespace and the Operator is not configured to clean it up before the Operator is removed, it is outside of the scope of OLM to remove the namespace during platform Operator deletion.

Procedure

Get a list of installed platform Operators and find the name for the Operator you want to delete:
```
$ oc get platformoperator
```
Delete the PlatformOperator resource for the chosen Operator, for example, for the Quay Operator:
```
$ oc delete platformoperator quay-operator
```
Example output
```
platformoperator.platform.openshift.io "quay-operator" deleted
```

Verification

Verify the namespace for the platform Operator is eventually deleted, for example, for the Quay Operator:
```
$ oc get ns quay-operator-system
```
Example output
```
Error from server (NotFound): namespaces "quay-operator-system" not found
```

Verify the platform-operators-aggregated cluster Operator continues to report an Available=True status:

$ oc get co platform-operators-aggregated

Example output

NAME                            VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
platform-operators-aggregated   4.13.0-0    True        False         False      70s