This is a cache of https://docs.okd.io/4.15/operators/admin/olm-managing-po.html. It is a snapshot of the page at 2024-11-26T20:45:30.308+0000.
Managing platform Operators - Administrator tasks | Operators | OKD 4.15
  1. Documentation
×

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.15, 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 TechPreviewNoUpgrade feature set.

Additional resources

Technology Preview restrictions for platform Operators

During the Technology Preview release of the platform Operators feature in OKD 4.15, 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-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 TechPreviewNoUpgrade 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

  1. 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".

  2. 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".

  3. 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.

  4. 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.

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

    Example service-mesh-po.yaml file
    apiVersion: platform.openshift.io/v1alpha1
kind: PlatformOperator
metadata:
  name: service-mesh-po
spec:
  package:
    name: servicemeshoperator

  6. 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

  1. Check the status of the service-mesh-po platform Operator by running the following command:

    $ oc get platformoperator service-mesh-po -o yaml
    Example output
    ...
status:
  activeBundleDeployment:
    name: service-mesh-po
  conditions:
  - lastTransitionTime: "2022-10-24T17:24:40Z"
    message: Successfully applied the service-mesh-po BundleDeployment resource
    reason: InstallSuccessful
    status: "True" (1)
    type: Installed
    1 Wait until the Installed status condition reports True.

  2. 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 TechPreviewNoUpgrade feature set by using the cluster-wide PlatformOperator API.

Procedure

  1. 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".

  2. Create a PlatformOperator object YAML file for your chosen platform Operator, for example a service-mesh-po.yaml file for the Red Hat OpenShift service Mesh Operator:

    Example sevice-mesh-po.yaml file
    apiVersion: platform.openshift.io/v1alpha1
kind: PlatformOperator
metadata:
  name: service-mesh-po
spec:
  package:
    name: servicemeshoperator

  3. Create the PlatformOperator object by running the following command:

    $ oc apply -f service-mesh-po.yaml

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

    error: resource mapping not found for name: "service-mesh-po" namespace: "" from "service-mesh-po.yaml": no matches for kind "PlatformOperator" in version "platform.openshift.io/v1alpha1"
ensure CRDs are installed first
Verification

  1. Check the status of the service-mesh-po platform Operator by running the following command:

    $ oc get platformoperator service-mesh-po -o yaml
    Example output
    ...
status:
  activeBundleDeployment:
    name: service-mesh-po
  conditions:
  - lastTransitionTime: "2022-10-24T17:24:40Z"
    message: Successfully applied the service-mesh-po BundleDeployment resource
    reason: InstallSuccessful
    status: "True" (1)
    type: Installed
    1 Wait until the Installed status condition reports True.

  2. 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

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

  1. Get a list of installed platform Operators and find the name for the Operator you want to delete:

    $ oc get platformoperator

  2. 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

  1. 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

  2. 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.15.0-0    True        False         False      70s