Skip to main content
You may already know the direct deployment path for an operator: build the controller image, push it to a registry, and apply the manifests that install the operator. The Operator Lifecycle Manager (OLM) provides an alternative, catalog-driven distribution model. OLM packages an operator into a bundle that a cluster can discover, install, and upgrade from a catalog — similar to how a package manager distributes software.
This image illustrates two methods for deploying an operator: a "Direct path" involving build, push, and apply steps, and an "OLM" method involving discovery and installation.
Think of raw manifests as handing someone a box of parts plus assembly instructions. OLM acts more like a package manager for operators: the operator package (bundle) still contains CRDs, RBAC, Deployments, and other runtime resources, but it also includes metadata that describes versions, channels, permissions, and upgrade behavior.
The image illustrates a package manager for operators, showing a flow where raw manifests containing CRD, RBAC, and Deployment data are enhanced with metadata before being processed by OLM.
Important: OLM is about distribution and lifecycle management — not a change to your operator’s runtime or reconciliation logic. The controller image you build still runs the operator; OLM defines how that operator is presented, installed, and upgraded on a cluster.
OLM provides discovery, install-time metadata, upgrade channels, and a managed approval workflow — it does not change how your reconcile loop works.
Vocabulary (simple sequence)
  • Bundle
    A bundle is the package for one version of the operator. It contains the files OLM needs: CRDs, metadata, and a ClusterServiceVersion (CSV). A bundle represents a single packaged version of your operator.
The image is an illustration labeled "Bundle: One Packaged Version," showing a green box with "BUNDLE" written on it, accompanied by a list that includes "CRDs," "Metadata," and "CSV."
  • Controller image
    The controller image is the container image with your operator code. The bundle references this image and includes the metadata that tells OLM how to deploy it.
  • ClusterServiceVersion (CSV)
    The CSV is the versioned manifest inside the bundle. It describes the APIs the operator owns, the install strategy (for example, the deployment spec), required RBAC permissions, and UI-facing metadata such as description and version.
The image describes "CSV: The Versioned Label" with a focus on ClusterServiceVersion elements like Owned APIs, Install strategy, and Permissions, alongside an illustration of an open box labeled "BUNDLE."
If the bundle is a box, the CSV is the version label that tells OLM and users what’s inside.
  • Catalog and CatalogSource
    A CatalogSource tells OLM where to look for operator packages (for example, a public registry, vendor catalog, or private catalog). Clusters can use multiple catalogs; catalogs are how OLM discovers available operators and their versions.
  • Subscription
    A Subscription is a user or platform request to install a package and follow a given channel over time. It names the package, the channel (for example, stable or beta), the catalog source, and the approval behavior (Automatic or Manual). OLM watches Subscription objects and decides which version should be installed now and which upgrades to consider later.
The image outlines an "Install Request" process involving a subscription, detailing package, channel, source, and approval settings, with OLM (Operator Lifecycle Manager) monitoring it. Context tabs are shown above, highlighting stages like Bundle, CSV, and Subscription.
  • InstallPlan
    An InstallPlan is the concrete list of steps OLM generates from a Subscription. It enumerates the resources OLM intends to install or upgrade (bundles, CSVs, CRDs, and other manifests). Based on the Subscription approval mode, OLM may apply the InstallPlan automatically or wait for human approval. This gating lets platform teams control when upgrades are applied.
If a Subscription uses manual approval, OLM will pause at the InstallPlan stage until an operator or platform engineer approves the plan. This prevents unintended upgrades in production clusters.
  • OperatorGroup
    An OperatorGroup defines the scope of the operator — which namespaces it should target. Operators can be namespace-scoped (watch a single namespace) or cluster-scoped (watch the entire cluster). OperatorGroup tells OLM the intended installation scope.
Quick comparison: When to use OLM
  • Choose raw manifests, Kustomize, or Helm when:
    • You want a simple, transparent install for a small internal operator.
    • You prefer straightforward YAML that you apply directly.
  • Choose OLM when you need:
    • Catalog-driven discovery and distribution.
    • Channel-based upgrades and version metadata.
    • Dependency resolution and a managed approval workflow.
    • A consistent operator marketplace experience (common on platforms like OpenShift).
The image is a comparison of when OLM fits versus when it doesn't, listing benefits like catalog-driven install and channel-based upgrades. It suggests raw manifests for small internal scenarios.
Summary table of OLM components Further reading and references Takeaway: Not every operator needs OLM. Think of distribution as levels: raw manifests are direct and transparent; OLM adds package metadata, catalogs, channels, InstallPlans, and a gated workflow. When you hear “bundle”, CSV, CatalogSource, Subscription, InstallPlan, and OperatorGroup, treat them as the parts of a package manager story for Kubernetes operators.

Watch Video