Operator
TOC
Overview
Based on the OLM (Operator Lifecycle Manager) framework, OperatorHub provides a unified interface for managing the installation, upgrade, and lifecycle of Operators.
Administrators can use OperatorHub to install and manage Operators, enabling full lifecycle automation for Kubernetes applications, including creation, updates, and deletion.
OLM mainly consists of the following components and CRDs:
- OLM (olm-operator): Manages the complete lifecycle of Operators, including installation, upgrades, and version conflict detection.
- Catalog Operator: Manages Operator catalogs and generates corresponding InstallPlans.
- CatalogSource: A namespace-scoped CRD that manages the Operator catalog source and provides Operator metadata (e.g., version info, managed CRDs). The platform provides 3 default CatalogSources: system, platform, and custom. Operators in system are not displayed in OperatorHub.
- ClusterServiceVersion (CSV): A namespace-scoped CRD that describes a specific version of an Operator, including the resources, CRDs, and permissions it requires.
- Subscription: A namespace-scoped CRD that describes the subscribed Operator, its source, acquisition channel, and upgrade strategy.
- InstallPlan: A namespace-scoped CRD that describes the actual installation operations to be performed (e.g., creating Deployments, CRDs, RBAC). An Operator will only be installed or upgraded once the InstallPlan is approved.
Operator Sources
To clarify the lifecycle strategy of different Operators in OperatorHub, the platform provides 5 source types:
-
Provided and maintained by , including full lifecycle management, security updates, technical support, and SLA commitments.
-
Curated
Selected from the open-source community, consistent with community versions, without code modifications or recompilation. provides guidance and security updates but does not guarantee SLA or lifecycle management.
-
Community
Provided by the open-source community, updated periodically to ensure installability, but functional completeness is not guaranteed; no SLA or support is provided.
-
Marketplace
Provided and maintained by third-party vendors certified by . provides platform integration support, while the vendor is responsible for core maintenance.
-
Custom
Developed and uploaded by the user to meet custom use-case requirements.
Pre-installation Preparation
Before installing an Operator, you need to understand the following key parameters:
Installation Mode
OLM provides three installation modes:
- Single Namespace
- Multi Namespace
- Cluster
Cluster mode (AllNamespaces) is recommended. The platform will eventually be upgraded to OLM v1, which only supports the AllNamespaces install mode. Therefore, SingleNamespace and MultiNamespace should be strongly avoided.
Update Channel
If an Operator provides multiple update channels, you can choose which channel to subscribe to, e.g., stable.
Approval Strategy
Options: Automatic or Manual.
- Automatic: OLM will automatically upgrade the Operator when a new version is released in the selected channel.
- Manual: When a new version is available, OLM creates an upgrade request that must be manually approved by the cluster administrator before the upgrade occurs.
Note: Operators from only support Manual mode; otherwise, installation will fail.
Installation Location
It is recommended to create a separate namespace for each Operator.
If multiple Operators share the same namespace, their Subscriptions may be resolved into a single InstallPlan:
- If an InstallPlan in that namespace requires Manual approval and remains pending, it can block automatic upgrades for other Subscriptions included in the same InstallPlan.
Installing via Web Console
-
Log in to the web console and switch to the Administrator view.
-
Navigate to Marketplace > OperatorHub.
-
If the status is Absent:
- Download the Operator package from the Custom Portal or contact support.
- Upload the package to the target cluster using
violet
(see CLI).
- On the Marketplace > Upload Packages page, switch to the Operator tab and confirm the upload.
-
If the status is Ready, click Install and follow the Operator's user guide.
Installing via YAML
The following examples demonstrate installation methods for Operators from (Manual only) and non- sources (Manual or Automatic).
Manual
The harbor-ce-operator
is from and supports Manual approval only.
In Manual mode, even if a new version is released, the Operator will not upgrade automatically. You must Approve manually before OLM executes the upgrade.
1. Check available versions
(
echo -e "CHANNEL\tNAME\tVERSION"
kubectl get packagemanifest harbor-ce-operator -o json | jq -r '
.status.channels[] |
.name as $channel |
.entries[] |
[$channel, .name, .version] | @tsv
'
) | column -t -s $'\t'
Example output:
CHANNEL NAME VERSION
harbor-2 harbor-ce-operator.v2.12.11 2.12.11
harbor-2 harbor-ce-operator.v2.12.10 2.12.10
stable harbor-ce-operator.v2.12.11 2.12.11
stable harbor-ce-operator.v2.12.10 2.12.10
Fields:
- CHANNEL: Operator channel name
- NAME: CSV resource name
- VERSION: Operator version
2. Confirm catalogSource
kubectl get packagemanifests harbor-ce-operator -ojsonpath='{.status.catalogSource}'
Example output:
This indicates the harbor-ce-operator
comes from the platform
catalogSource.
3. Create a namespace
kubectl create namespace harbor-ce-operator
4. Create a Subscription
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
annotations:
cpaas.io/target-namespaces: ""
name: harbor-ce-operator-subs
namespace: harbor-ce-operator
spec:
channel: stable
installPlanApproval: Manual
name: harbor-ce-operator
source: platform
sourceNamespace: cpaas-system
startingCSV: harbor-ce-operator.v2.12.11
Field explanations:
- annotation
cpaas.io/target-namespaces
: It is recommended to set this to empty; empty indicates cluster-wide installation.
- .metadata.name: Subscription name (DNS-compliant, max 253 characters).
- .metadata.namespace: Namespace where the Operator will be installed.
- .spec.channel: Subscribed Operator channel.
- .spec.installPlanApproval: Approval strategy (
Manual
or Automatic
). Here, Manual
requires manual approval for install/upgrade.
- .spec.source: Operator catalogSource.
- .spec.sourceNamespace: Must be set to cpaas-system because all catalogSources provided by the platform are located in this namespace.
- .spec.startingCSV: Specifies the version to install for Manual approval; defaults to the latest in the channel if empty. Not required for Automatic.
5. Check Subscription status
kubectl -n harbor-ce-operator get subscriptions harbor-ce-operator-subs -o yaml
Key output:
- .status.state:
UpgradePending
indicates the Operator is awaiting installation or upgrade.
- Condition InstallPlanPending = True: Waiting for manual approval.
- .status.currentCSV: Latest subscribed CSV.
- .status.installPlanRef: Associated InstallPlan; must be approved before installation proceeds.
6. Approve InstallPlan
kubectl -n harbor-ce-operator get installplan \
"$(kubectl -n harbor-ce-operator get subscriptions harbor-ce-operator-subs -o jsonpath='{.status.installPlanRef.name}')"
Example output:
NAME CSV APPROVAL APPROVED
install-27t29 harbor-ce-operator.v2.12.11 Manual false
Approve manually:
PLAN="$(kubectl -n harbor-ce-operator get subscription harbor-ce-operator-subs -o jsonpath='{.status.installPlanRef.name}')"
kubectl -n harbor-ce-operator patch installplan "$PLAN" --type=json -p='[{"op": "replace", "path": "/spec/approved", "value": true}]'
Wait for CSV creation; Phase changes to Succeeded
:
kubectl -n harbor-ce-operator get csv
Example output:
NAME DISPLAY VERSION REPLACES PHASE
harbor-ce-operator.v2.12.11 Alauda Build of Harbor 2.12.11 harbor-ce-operator.v2.12.10 Succeeded
Fields:
- NAME: Installed CSV name
- DISPLAY: Operator display name
- VERSION: Operator version
- REPLACES: CSV replaced during upgrade
- PHASE: Installation status (
Succeeded
indicates success)
Automatic
The clickhouse-operator
comes from a non- source, and its Approval Strategy can be set to Automatic.
In Automatic mode, the Operator upgrades automatically when a new version is released, without manual approval.
1. Check available versions
(
echo -e "CHANNEL\tNAME\tVERSION"
kubectl get packagemanifest clickhouse-operator -o json | jq -r '
.status.channels[] |
.name as $channel |
.entries[] |
[$channel, .name, .version] | @tsv
'
) | column -t -s $'\t'
Example output:
CHANNEL NAME VERSION
stable clickhouse-operator.v0.18.2 0.18.2
2. Confirm catalogSource
kubectl get packagemanifests clickhouse-operator -ojsonpath='{.status.catalogSource}'
Example output:
This indicates the clickhouse-operator
comes from the community-operators
catalogSource.
3. Create a namespace
kubectl create namespace clickhouse-operator
4. Create a Subscription
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
annotations:
cpaas.io/target-namespaces: ""
name: clickhouse-operator-subs
namespace: clickhouse-operator
spec:
channel: stable
installPlanApproval: Automatic
name: clickhouse-operator
source: community-operators
sourceNamespace: openshift-marketplace
Field explanations are the same as in Manual.
5. Check Subscription status
kubectl -n clickhouse-operator get subscriptions clickhouse-operator -oyaml
6. Verify CSV
kubectl -n clickhouse-operator get csv
Example output:
NAME DISPLAY VERSION PHASE
clickhouse-operator.v0.18.2 ClickHouse Operator 0.18.2 Succeeded
Installation is successful.
Upgrade Process
-
Upload the new Operator version.
-
Upgrades follow the strategy configured in the Subscription:
Note: Only Operators from support batch upgrades.