$ ./openshift-install create manifests --dir <installation_directory> (1)
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. |
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.
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:
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:
|
Access to an OKD cluster using an account with cluster-admin
permissions.
The TechPreviewNoUpgrade
feature set enabled on the cluster.
Enabling the |
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.
As a cluster administrator, you can install platform Operators by providing FeatureGate
and PlatformOperator
manifests during cluster creation.
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:
feature-gate.yaml
fileapiVersion: 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 service-mesh-po.yaml
file for the Red Hat OpenShift Service Mesh Operator:
service-mesh-po.yaml
fileapiVersion: platform.openshift.io/v1alpha1
kind: PlatformOperator
metadata:
name: service-mesh-po
spec:
package:
name: servicemeshoperator
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. |
Check the status of the service-mesh-po
platform Operator by running the following command:
$ oc get platformoperator service-mesh-po -o yaml
...
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 . |
Verify that the platform-operators-aggregated
cluster Operator is reporting an Available=True
status:
$ oc get clusteroperator platform-operators-aggregated -o yaml
...
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
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.
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 service-mesh-po.yaml
file for the Red Hat OpenShift Service Mesh Operator:
sevice-mesh-po.yaml
fileapiVersion: platform.openshift.io/v1alpha1
kind: PlatformOperator
metadata:
name: service-mesh-po
spec:
package:
name: servicemeshoperator
Create the PlatformOperator
object by running the following command:
$ oc apply -f service-mesh-po.yaml
If your cluster does not have the
|
Check the status of the service-mesh-po
platform Operator by running the following command:
$ oc get platformoperator service-mesh-po -o yaml
...
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 . |
Verify that the platform-operators-aggregated
cluster Operator is reporting an Available=True
status:
$ oc get clusteroperator platform-operators-aggregated -o yaml
...
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
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. |
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
platformoperator.platform.openshift.io "quay-operator" deleted
Verify the namespace for the platform Operator is eventually deleted, for example, for the Quay Operator:
$ oc get ns quay-operator-system
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
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE
platform-operators-aggregated 4.15.0-0 True False False 70s