#Operator

#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:

1. Provided and maintained by , including full lifecycle management, security updates, technical support, and SLA commitments.

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

3. Community Provided by the open-source community, updated periodically to ensure installability, but functional completeness is not guaranteed; no SLA or support is provided.

4. Marketplace Provided and maintained by third-party vendors certified by . provides platform integration support, while the vendor is responsible for core maintenance.

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

1. Log in to the web console and switch to the Administrator view.

2. Navigate to Marketplace > OperatorHub.

3. If the status is Absent:

   • Download the Operator package from the Customer 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.

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

platform

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:

community-operators

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

The upgrade process starts by uploading the new Operator version.

After the upload is completed, wait approximately 10–15 minutes for the platform to synchronize the new version information.

Once synchronization is complete, upgrades follow the strategy configured in the Subscription:

• If the Operator Approval Strategy is set to Automatic, the Operator is upgraded automatically.

• If the strategy is set to Manual, the upgrade request must be approved manually. You can choose one of the following upgrade methods:

  • Batch Upgrade: Execute the upgrade on the Platform Management > Cluster Management > Cluster > Features page.
  • Individual Upgrade: Manually approve upgrade requests in OperatorHub.

Note: Only Operators provided by support batch upgrades.