Kubernetes Operator Lifecycle Management

Kubernetes Operator Lifecycle Management refers specifically to the Operator Lifecycle Manager (OLM) system itself: the set of custom resources and controllers, CatalogSource, Subscription, InstallPlan, ClusterServiceVersion, and OperatorGroup, that together automate discovery, dependency resolution, installation, and upgrade sequencing for Operators running on a cluster, as opposed to the general day-to-day practice of managing any single Operator's deployment.

The Catalog and Package Model

CatalogSource as the Package Index

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: operatorhubio-catalog
  namespace: olm
spec:
  sourceType: grpc
  image: quay.io/operatorhubio/catalog:latest

A CatalogSource points OLM at a gRPC-served index of available Operator packages, each package containing one or more channels, and each channel containing an ordered sequence of ClusterServiceVersion releases representing that package's version history.

Channels as Named Upgrade Tracks

packageName: postgres-operator
channels:
  - name: stable
    currentCSV: postgres-operator.v1.4.0
  - name: fast
    currentCSV: postgres-operator.v1.4.1

Each channel independently tracks its own "current" version, letting a package author publish a conservative stable track alongside a more frequently updated fast track, with subscribers choosing which track's upgrade cadence they want to follow.

Dependency Resolution

Resolving CRD and API Dependencies

apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
spec:
  customresourcedefinitions:
    required:
      - name: backuppolicies.backup.example.com
        version: v1
        kind: BackupPolicy

When a ClusterServiceVersion declares a required CRD it does not itself own, OLM's resolver searches available catalogs for another package that provides that CRD, and automatically includes it in the same InstallPlan, ensuring an Operator with cross-package dependencies is not installed into a state where a required API is missing.

The InstallPlan Approval Gate

Generated Install Plans

apiVersion: operators.coreos.com/v1alpha1
kind: InstallPlan
metadata:
  name: install-abc123
  namespace: databases-system
spec:
  approval: Manual
  approved: false
  clusterServiceVersionNames:
    - postgres-operator.v1.4.0

Every resolved installation or upgrade produces an InstallPlan object enumerating the exact set of manifests (CRDs, RBAC, Deployment) that will be applied; with manual approval configured, the plan sits in an unapproved state until an administrator explicitly sets spec.approved: true, giving a concrete, reviewable artifact of exactly what a pending upgrade will change.

kubectl patch installplan install-abc123 -n databases-system --type merge -p '{"spec":{"approved":true}}'

OperatorGroup and Scope Targeting

Determining Watched Namespaces

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: databases-operatorgroup
  namespace: databases-system
spec:
  targetNamespaces:
    - production
    - staging

An OperatorGroup present in the namespace where an Operator is installed determines which namespaces that Operator's generated RBAC actually grants it access to, translating the abstract install modes (AllNamespaces, SingleNamespace, MultiNamespace) declared in a ClusterServiceVersion into concrete RoleBinding and ClusterRoleBinding objects scoped to the targetNamespaces list.

One OperatorGroup Per Namespace Constraint

OLM enforces that at most one OperatorGroup can exist per namespace; installing a second Operator into a namespace already governed by an OperatorGroup with incompatible targetNamespaces causes that Operator's ClusterServiceVersion to fail reconciliation, a common source of installation failures in clusters hosting multiple independently installed Operators.

Upgrade Graph and Replacement Chains

The replaces Field

apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  name: postgres-operator.v1.4.0
spec:
  replaces: postgres-operator.v1.3.2

Each ClusterServiceVersion declares which prior version it replaces, forming a directed upgrade graph; OLM will only upgrade along this declared chain, refusing to skip versions unless a skips field explicitly permits bypassing an intermediate release, which prevents an Operator from being upgraded through an untested or unsupported version jump.

spec:
  skips:
    - postgres-operator.v1.4.0

Relationship to Operator Management and CRD Management

Operator Lifecycle Management is the specific automation system that implements the installation and upgrade practices described under Operator management, and its dependency resolution and approval gating directly govern how the version transitions covered under CRD version management are rolled out safely: an InstallPlan's enumerated changes are precisely where a CRD schema upgrade, RBAC change, and controller version bump are bundled together and either approved as a coherent unit or held back for review.