DOCSEARCHbyAlgolia
Submit Docs

Operator Lifecycle Manager (OLM)

website·Indexed 38 days ago

https://olm.operatorframework.io/docs

Documentation for the Operator Lifecycle Manager (OLM), covering the installation, management, and distribution of Kubernetes operators. Includes guides on creating operator bundles, managing CatalogSources, configuring ClusterServiceVersion (CSV) and Subscription CRDs, and implementing file-based catalogs using opm.

Tokens
34.1K
Snippets
146
Records
235
Agent score
72%

What's inside OLM

  1. Overview of OLM documentation technology stack

    The OLM documentation website is built using the following tools:

    • Hugo: An open-source static site generator used for formatting, content organization, and website generation. Pages are written in Markdown or HTML.
    • Docsy: The theme used for styling and site structure.
    • Netlify: Used to manage the deployment of the site and provide automated PR previews.

  2. Overview of OperatorGroup in OLM

    An OperatorGroup is an OLM resource used to configure multitenancy for installed operators. It defines a set of target namespaces where the OLM will generate the required RBAC access for member operators. The target namespaces are stored in the olm.targetNamespaces annotation on the member operator's ClusterServiceVersion (CSV) and are projected into deployments via the Kubernetes Downward API.

  3. Overview of Operator Lifecycle Manager (OLM)

    Operator Lifecycle Manager (OLM) is a component of the Operator Framework designed to manage Kubernetes-native applications (Operators) in an automated and scalable manner. OLM extends Kubernetes to provide a declarative method for installing, managing, and upgrading Operators and their dependencies within a cluster.

  4. Overview of Operator Lifecycle Manager (OLM)

    The Operator Lifecycle Manager (OLM) is an extension of Kubernetes that provides a declarative framework to install, manage, and upgrade Operators on a cluster. It ensures cluster stability by preventing the installation of conflicting Operators that own the same APIs and allows Operators to function as managed service providers via their exposed APIs.

  5. Overview of Operator Bundles

    An Operator Bundle is a non-runnable (scratch) container image that stores Kubernetes manifests and metadata associated with a specific version of an operator. It typically consists of a directory containing a manifests/ folder (with the ClusterServiceVersion and CRDs), a metadata/ folder (containing annotations.yaml), and a Dockerfile used to build the image. The bundle is pushed to an OCI-compliant container registry for use in a catalog.
    example-bundle/
├── manifests/
│   ├── cluster.crd.yaml
│   └── operator.clusterserviceversion.yaml
├── metadata/
│   └── annotations.yaml
└── Dockerfile

  6. Overview of Catalog Templates for File-Based Catalogs

    Catalog Templates provide a simplified, declarative way to define File-Based Catalogs (FBC) for operator update graphs. A template consists of an input API schema and an executable (such as opm) that processes the schema to produce a valid FBC. This reduces the complexity of managing large numbers of releases and dependencies. Currently, two types of templates are supported: the Basic Template and the Semver Template. Note that catalog templates are currently in ALPHA and may undergo breaking changes.

  7. Overview of OLM File-based Catalogs

    File-based catalogs are a plaintext (JSON or YAML) evolution of the OLM sqlite database format. They are designed to be fully backwards compatible while enabling direct editing via standard tooling (like jq), composability through directory nesting, and extensibility via custom schemas. Catalog maintainers can compose decentralized catalogs by combining operator-specific directories into a single root catalog.

  8. Understand OLM Architecture and Component Roles

    The Operator Lifecycle Manager (OLM) is composed of two primary operators that manage the lifecycle of operators in a cluster: the OLM Operator and the Catalog Operator.

    • OLM Operator: Responsible for deploying applications defined by ClusterServiceVersion (CSV) resources once their requirements are met. It manages the actual deployment of the operator's pods and associated RBAC.
    • Catalog Operator: Responsible for resolving dependencies, installing CSVs and their required resources, and monitoring CatalogSources for package updates. It handles the 'planning' phase of installation via InstallPlans.

  9. Choose an Operator SDK development path

    Operators can be developed using the SDK with three different supported frameworks. Depending on the desired implementation, developers should follow the corresponding quickstart guide: Ansible, Helm, or Go.

  10. Name OLM channels by Operand version

    In scenarios where users care more about the version of the managed software (the Operand) than the Operator version (e.g., a database operator), include the operand version in the channel name. This allows users to track the latest operator capable of managing a specific software version.
    # For Postgres v12
candidate-pg-v12
fast-pg-v12
stable-pg-v12

# For Postgres v13
candidate-pg-v13
fast-pg-v13
stable-pg-v13

  11. Filter PackageManifests by OS or architecture

    You can filter available operators by their supported OS or architecture using kubectl with the corresponding label selector. Note that only labels on the HEAD of the default channel are considered for filtering in the PackageManifest API; labels in non-default channels will not be available for filtering.
    # Filter for Windows-supported operators
kubectl get packagemanifests -l operatorframework.io/os.windows=supported

  12. Understand the ClusterServiceVersion (CSV) resource

    A ClusterServiceVersion (CSV) is the main entrypoint for packaging an operator for OLM. It represents a specific version of a running operator on a cluster. It serves two primary purposes: it acts as a package (similar to an rpm or deb) containing metadata required for installation, and it acts as a template for the operator's Deployment and required permissions.