> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # A Brief Look At OLM > Overview of Operator Lifecycle Manager explaining operator packaging, catalogs, bundles, CSVs, subscriptions, install plans, and when to use OLM versus raw manifests. 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 | Resource Type | Purpose | Key fields / notes | | --------------: | --------------------------------------- | ---------------------------------------------------------------------- | | Bundle | One packaged version of an operator | Contains CRDs, `CSV`, metadata | | `CSV` | Versioned descriptor for the bundle | `spec.installStrategy`, owned APIs, permissions | | `CatalogSource` | Where OLM discovers packages | Points to a registry or index image | | `Subscription` | Request to install and follow a channel | `spec.name`, `spec.channel`, `spec.source`, `spec.installPlanApproval` | | `InstallPlan` | Concrete steps OLM will apply | Lists manifests and their order; may require approval | | `OperatorGroup` | Defines operator install scope | Namespace-scoped or cluster-scoped behavior | Further reading and references * Operator Lifecycle Manager (OLM) docs: [https://olm.operatorframework.io/docs/](https://olm.operatorframework.io/docs/) * OpenShift Operators and OperatorHub: [https://docs.openshift.com/](https://docs.openshift.com/) * When to use Helm, Kustomize, or raw manifests: compare in your platform-specific docs Takeaway: Not every operator needs OLM. Think of distribution as levels: raw manifests are direct and transparent; OLM adds package metadata, catalogs, channels, `InstallPlan`s, 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.