Operator Lifecycle Manager

What the Operator Lifecycle Manager (OLM) Does

Operator Lifecycle Manager (OLM) is the subsystem in OpenShift that manages the entire lifecycle of Operators and their associated services. Concretely, OLM:

• Discovers and exposes available Operators via catalogs
• Installs Operators into clusters or specific namespaces
• Ensures required permissions and RBAC are created
• Manages upgrades (including channels and version constraints)
• Handles dependencies between Operators
• Coordinates removal and cleanup of Operators

Think of OLM as the package manager for Operators, with safety checks and upgrade orchestration built in.

Core OLM Concepts and Resources

OLM is implemented through a set of Kubernetes-style APIs (CustomResourceDefinitions). The most important resources you’ll encounter are:

CatalogSource

CatalogSource defines where OLM discovers available Operators.

Typical types:

• Red Hat-provided catalogs (e.g., redhat-operators, certified-operators)
• Community catalogs (e.g., community-operators)
• Custom / private catalogs (internal registries for in-house Operators)

Key characteristics:

• Backed by a container image or a gRPC source that contains Operator metadata
• Watched by OLM to know which Operators, versions, and channels exist
• Can be cluster-scoped (available everywhere) or namespace-scoped (restricted)

Example use cases:

• Pointing to a custom catalog for internal Operators
• Pinning to a specific catalog image version for upgrade stability

OperatorGroup

OperatorGroup defines the target namespaces that Operators in a given namespace will watch and manage.

Roles of an OperatorGroup:

• Declares the set of namespaces an Operator can manage:
• Single namespace
• A list of namespaces
• All namespaces in the cluster (cluster-wide)
• Controls Operator scope for multi-tenant or limited-scope deployments
• Ensures generated RBAC only applies where appropriate

Common patterns:

• Single-tenant per namespace: one OperatorGroup per project, each watching its own namespace
• Cluster-wide Operator: one OperatorGroup in a system namespace (e.g., openshift-operators) that targets all namespaces

Subscription

Subscription describes the desired Operator, its channel, and how it should be kept up to date.

A Subscription:

• Points to a specific Operator package
• Refers to a channel (e.g., stable, fast, preview)
• Chooses an update strategy (e.g., automatic or manual)
• Triggers OLM to create InstallPlans and install/upgrade Operators

Key aspects:

• Defines what Operator you want and how you want to track its versions
• Is usually created in the same namespace as the OperatorGroup
• Drives ongoing reconciliation of the Operator installation

InstallPlan

InstallPlan is the detailed plan OLM creates to execute an install or upgrade.

Characteristics:

• Generated automatically when a Subscription sees a new or updated version
• Lists all actions: CRDs to create, RBAC to apply, deployments to update
• Can be set to:
• Automatic approval: OLM immediately executes the plan
• Manual approval: an admin must approve before changes apply

Why InstallPlans matter:

• Provide a clear audit trail of what changed during an Operator install/upgrade
• Can be inspected for safety and compatibility before approval
• Integrate with change control processes in regulated environments

ClusterServiceVersion (CSV)

ClusterServiceVersion is the manifest that describes a specific released version of an Operator from the catalog’s perspective.

A CSV includes:

• Metadata: name, version, description, maturity
• Installation spec: Deployments, permissions (RBAC), required CRDs
• Supported API versions (the CRDs and APIs the Operator manages)
• Display information used in the web console

Lifecycle:

• Each Operator version corresponds to a CSV
• OLM uses CSVs to understand how to install and upgrade an Operator
• Old CSVs are replaced as upgrades occur, subject to compatibility rules

How OLM Installs Operators

At a high level, installing an Operator via OLM follows this sequence:

1. Catalog discovery
• OLM reads CatalogSources to know which Operators, versions, and channels exist.
2. Scope definition
• An OperatorGroup defines the namespaces the Operator will target.
3. Subscription creation
• A Subscription specifies:
• The Operator package name
• The channel (stable, fast, etc.)
• Source catalog
• Approval strategy for InstallPlans
4. InstallPlan generation
• OLM compares current state with desired state and creates an InstallPlan:
• CRDs to create/update
• RBAC definitions
• Deployments/Pods for the Operator
5. Approval and execution
• If automatic: OLM immediately executes the InstallPlan
• If manual: an admin inspects and approves before execution
6. CSV deployment
• OLM creates the ClusterServiceVersion for the selected Operator version
• The Operator is deployed and begins managing its CRDs in the target scope

Upgrades and Channels

OLM provides a structured way to manage Operator upgrades.

Channels

A channel is a named upgrade stream for an Operator, such as:

• stable
• fast
• candidate
• preview

Characteristics:

• Each channel describes an ordered graph of CSV versions
• Subscriptions track a specific channel to control how aggressively they update
• Different environments (dev/test/prod) can use different channels

Upgrade Strategies

With a Subscription, you control:

• Upgrade source: which CatalogSource to use
• Channel: which upgrade path to follow
• Approval mode:
• Automatic: OLM applies new versions as they appear in the channel
• Manual: OLM creates InstallPlans that require explicit approval

Upgrade flow:

1. New version appears in catalog in the same channel
2. Subscription notices a newer CSV matching its constraints
3. OLM creates a new InstallPlan
4. Based on approval mode:
• Automatic: InstallPlan is executed
• Manual: Waits for administrator approval
5. OLM updates CSV and Operator deployment

Dependency Management and Constraints

OLM understands relationships between Operators and their APIs:

• Required CRDs/APIs: An Operator can declare that it depends on APIs provided by another Operator.
• Provided APIs: Operators declare which CRDs and API groups they provide.

OLM uses this information to:

• Prevent installation of Operators when required APIs are missing
• Orchestrate upgrades in an order that maintains API compatibility
• Surface dependency issues in Subscription or InstallPlan status

Practical implications:

• Installing an advanced Operator may auto-trigger InstallPlans for its dependencies, or require that you install prerequisite Operators first.
• Removing a dependency Operator can cause dependent Operators to become unhealthy or blocked; OLM surfaces these issues.

Namespaces, Scope, and Multi-Tenancy

How OLM handles multi-tenancy and scope is primarily determined by OperatorGroup and Subscription placement.

Patterns:

• Cluster-wide Operators:
• Operator installed in a shared namespace (e.g., openshift-operators)
• OperatorGroup targets all namespaces
• Suitable for cluster services (monitoring, storage, logging, etc.)
• Namespace-scoped Operators:
• Operator installed in application namespace (e.g., a team project)
• OperatorGroup targets that single namespace
• Ideal for isolating Operators per team or application

Implications:

• OLM enforces that only one OperatorGroup per namespace is effective
• Overlapping target namespaces across OperatorGroups can cause installation failures or unexpected behavior
• Proper design of OperatorGroups is part of multi-tenant cluster governance

Using the Web Console vs CLI with OLM

While the underlying resources are the same, the experience differs:

Web Console Experience

The OpenShift web console integrates tightly with OLM:

• OperatorHub UI:
• Visual browsing of Operators from available CatalogSources
• One-click installation that creates Subscriptions and OperatorGroups
• Installed Operators view:
• Shows installed Operators, their versions, status, and scope
• Provides links to create and manage custom resources (CRs) for each Operator

This is often the simplest path for beginners.

CLI / YAML Workflows

For scripted and GitOps workflows:

• You define:
• CatalogSource (for custom catalogs)
• OperatorGroup (to set scope)
• Subscription (to select Operator, channel, and upgrade mode)

Benefits:

• Reproducible installations across clusters
• Easy integration into automation pipelines
• Explicit, version-controlled Operator lifecycle definitions

Common Operational Considerations

Version Pinning and Stability

You can manage risk by:

• Choosing a conservative channel (e.g., stable vs fast)
• Using manual approval for InstallPlans in production
• Pinning custom CatalogSources to specific image tags or digests

This allows you to:

• Test new Operator versions in non-production environments first
• Control when changes reach production
• Align Operator upgrades with change windows

Catalog Updates

CatalogSources themselves can be updated:

• Cluster-managed Red Hat catalogs are generally updated as part of cluster upgrades
• Custom catalogs can be:
• Updated on a schedule
• Pinned for extended periods
• When catalogs update, Subscriptions may see new versions and trigger InstallPlans

Monitoring:

• Track events and status on Subscriptions and InstallPlans
• Watch for compatibility notes in Operator documentation and release notes

Troubleshooting OLM-Managed Operators

Common places to look:

• Subscription status:
• Tells you if OLM can find a matching CSV
• Shows reasons for failures (e.g., missing dependencies, upgrade conflicts)
• InstallPlan status:
• Shows which steps succeeded or failed
• Provides error messages for RBAC issues, CRD conflicts, etc.
• CSV status:
• Indicates whether the Operator deployment is healthy
• Surfaces requirement issues (APIs missing, permissions not granted)

When issues arise, you typically follow this order:

1. Check Subscription conditions
2. Inspect latest InstallPlan
3. Review CSV status and associated Operator pods/deployments

Best Practices for Working with OLM

• Define clear scope using OperatorGroups
• Avoid overlapping or ambiguous target namespaces
• Prefer cluster-scoped Operators only when truly needed
• Align channels with environments
• Dev: fast or candidate
• Test/Stage: stable but ahead of production
• Prod: stable with manual InstallPlan approval
• Version control your OLM resources
• Store YAML definitions for Subscriptions, OperatorGroups, and custom CatalogSources in Git
• Use GitOps or automation tools to roll out to clusters
• Monitor lifecycle events
• Watch for Subscription and InstallPlan changes as part of cluster monitoring
• Integrate OLM events into operational dashboards and alerts where appropriate
• Coordinate with cluster upgrades
• Check Operator compatibility matrices
• Ensure critical Operators are at supported versions before cluster upgrades
• Use manual approval in sensitive periods to avoid surprise changes

By understanding and using OLM effectively, you gain a structured, repeatable, and governed way to introduce powerful platform capabilities into your OpenShift clusters without manually managing the underlying Kubernetes objects.