Mastering Operator Lifecycle Manager: Architecture, Installation, and Upgrade Strategies

Operator Lifecycle Manager (OLM) is a key part of the Operator Framework that automates the installation, upgrade, and lifecycle management of Kubernetes Operators. It itself runs as an Operator, offering declarative automation that aligns with Kubernetes design principles.

Component Model

OLM defines several custom resources to manage operators:

Lifecycle management : handles upgrades and lifecycle of both the operator and its managed resources.

Service discovery : discovers which operators are present in the cluster, what resources they manage, and which operators are installable.

Packaging : provides a standard way to bundle operators and their dependencies for distribution, installation, and upgrade.

Interaction : offers a CLI‑style interface for users to interact with the operators and other cloud services.

Design goals include namespace‑scoped deployment, custom‑resource (CR) definitions, dependency parsing, idempotent deployment, and garbage‑collection using native Kubernetes mechanisms.

Architecture Overview

OLM consists of two operators: the OLM Operator and the Catalog Operator . They manage the following CRDs:

The OLM Operator creates Deployments, ServiceAccounts, and RBAC resources for the target operator, while the Catalog Operator creates the required CRDs and ClusterServiceVersions (CSVs).

Installation

OLM can be installed automatically using the release script or manually by applying the CRD and OLM manifests. Example for version 0.13.0:

curl -L https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.13.0/install.sh -o install.sh
chmod +x install.sh
./install.sh 0.13.0

Manual installation:

kubectl apply -f https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.13.0/crds.yaml
kubectl apply -f https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.13.0/olm.yaml

For local development, clone the OLM repository and run: make run-local Then verify the components with:

kubectl -n local get deployments

Configuration

OLM can be customized via a values file. Key parameters include RBAC API version, namespace placement, watched namespaces, and replica counts. Example snippet:

rbacApiVersion: rbac.authorization.k8s.io
namespace: olm
watchedNamespaces: olm
catalog_namespace: olm
operator_namespace: operators
olm:
  replicaCount: 1
  image:
    ref: quay.io/operator-framework/olm:local
    pullPolicy: IfNotPresent
  service:
    internalPort: 8080
catalog:
  replicaCount: 1
  image:
    ref: quay.io/operator-framework/olm:local
    pullPolicy: IfNotPresent
  service:
    internalPort: 8080

Dependency Resolution and Upgrade Management

OLM resolves dependencies similarly to package managers like apt or yum. It ensures that operators are not installed if required APIs are missing and prevents upgrades that would break existing dependencies.

CRD upgrades follow these rules:

All services used by the current CRD version must be present in the new version.

Existing CustomResource instances must validate against the new CRD schema.

To add a new CRD version, update the versions field and reference the new version in the CSV’s owned section. Example:

versions:
  - name: v1alpha1
    served: true
    storage: false
  - name: v1beta1
    served: true
    storage: true

When deprecating a CRD version, set served: false and later remove the version after it is no longer used.

OLM builds an upgrade DAG from CSVs. If intermediate versions exist, OLM installs them sequentially. The skips field can be used to bypass unsafe intermediate versions:

apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  name: etcdoperator.v0.9.2
spec:
  replaces: etcdoperator.v0.9.0
  skips:
  - etcdoperator.v0.9.1

Operator Registry Integration

The operator‑registry component provides a gRPC service that stores operator bundles (CSV + CRDs) in a SQLite database. A typical bundle directory contains a CSV and its associated CRDs.

Example bundle layout:

# bundle example
0.6.1
├── etcdcluster.crd.yaml
└── etcdoperator.clusterserviceversion.yaml

After building the registry image, create a CatalogSource that points to the registry:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: example-manifests
  namespace: default
spec:
  sourceType: grpc
  image: example-registry:latest

Watch available packages:

$ watch kubectl get packagemanifests
NAME        AGE
prometheus  13m
etcd        27m

Create a Subscription to install or upgrade an operator from the catalog:

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: etcd-subscription
  namespace: default
spec:
  channel: alpha
  name: etcd
  source: example-manifests
  sourceNamespace: default

Conclusion

The article provides a comprehensive overview of OLM’s architecture, component model, installation procedures, configuration options, and its sophisticated dependency‑resolution and upgrade mechanisms, equipping readers to effectively manage operators in cloud‑native environments.