OLM: Kubernetes' App Store for Operators

WHY IT EXISTS: Installing a Kubernetes Operator by hand means applying resources in the right order, then repeating that for every update. Tracking this across clusters and knowing which Operator owns which API becomes unmanageable at scale. OLM was built to automate this lifecycle so Operators can be installed, discovered, upgraded, and removed declaratively.

THE MENTAL MODEL: Think of OLM as the app store and package manager for your cluster. Instead of manually applying manifests, you point to a catalog. OLM resolves what needs to be installed, what it depends on, and how to update it safely without breaking other workloads.

HOW IT WORKS: OLM extends Kubernetes and provides a declarative way to install, manage, and upgrade Operators. It uses a packaging format that lets Operators express dependencies on the platform and on other Operators. Administrators make Operators available through catalogs, and cluster users can then select and install them. OLM provides over-the-air updates to keep applications current automatically. It also enforces cluster stability by preventing conflicting Operators that own the same APIs from being installed. Additionally, OLM enables Operators to behave like managed service providers through the declarative UI controls and APIs they expose.

WHEN TO USE IT: Use OLM when you run multiple Operators in production, especially third-party or in-house ones that receive frequent updates. It is valuable when you want self-service discoverability, allowing cluster users to browse and install from a catalog without deep knowledge of the underlying resources. Any environment where dependency tracking and automated upgrades matter is a strong candidate.

WHEN NOT TO USE IT: Do not use OLM if you only run a single static Operator that never changes, because the added complexity of catalogs and packaging is unnecessary overhead. It is also a poor fit if you need to hand-edit Operator resources outside of the declarative model, since OLM expects a versioned, declarative workflow.

ONE CANONICAL EXAMPLE: A platform team wants to offer a managed database service inside Kubernetes. They package their database Operator using OLM, publish it to a catalog, and enable automatic updates. Developers discover the service through the cluster catalog and install it declaratively. The platform team pushes patch updates overnight without touching each cluster. If a conflicting backup Operator tries to claim the same database API, OLM blocks the installation to preserve cluster stability.