Operator SDK – Operator SDK Integration with Operator Lifecycle Manager

Docs: OLM Integration Bundle Quickstart

Mon, 01 Jan 0001 00:00:00 +0000

The Operator Lifecycle Manager (OLM) is a set of cluster resources that manage the lifecycle of an Operator. The Operator SDK supports both creating manifests for OLM deployment, and testing your Operator on an OLM-enabled Kubernetes cluster.

This document is intended to quickly walk through the steps to generate an OLM bundle. For further explanation, or if you’re using package manifests, see the Bundle Tutorial.

Important: this guide assumes your project was scaffolded with operator-sdk init --project-version=3. These features are unavailable to projects of version 2 or less; this information can be found by inspecting your PROJECT file’s version value.

Prerequisites

Have a working operator that you have uploaded to a container registry. This guide assumes the simple Golang Memcached operator from the building operators section at version 0.0.1.
Make sure your user is authorized with cluster-admin permissions.
Have OLM installed on your cluster. The command operator-sdk olm install will attempt to install a basic OLM deployment on your cluster.

Steps

Export environment variables

$ export USERNAME=<container-registry-username>
$ export VERSION=0.0.1
$ export IMG=docker.io/$USERNAME/memcached-operator:v$VERSION // location where your operator image is hosted
$ export BUNDLE_IMG=docker.io/$USERNAME/memcached-operator-bundle:v$VERSION // location where your bundle will be hosted

Create a bundle from the root directory of your project

$ make bundle

This will prompt you to enter basic information about your operator.

Build and push the bundle image

$ make bundle-build bundle-push

Validate the bundle

$ operator-sdk bundle validate $BUNDLE_IMG

Install the bundle with OLM

$ operator-sdk run bundle $BUNDLE_IMG

Next Steps

Read the full tutorial for a more in-depth look at creating and using a bundle.

Docs: OLM Integration Bundle Tutorial

Mon, 01 Jan 0001 00:00:00 +0000

This document succinctly walks through getting an Operator OLM-ready with bundles, and glosses over explanations of certain steps for brevity. The following documents contain more detail on these steps:

All operator-framework manifest commands supported by the SDK: CLI overview.
Generating operator-framework manifests: generation overview.

If you are working with package manifests, see the package manifests tutorial once you have completed the Setup section below.

Setup

Let’s first walk through creating an Operator for memcached, a distributed key-value store.

Follow one of the user guides to develop the memcached-operator in either Go, Ansible, or Helm, depending on which Operator type you are interested in. This guide assumes memcached-operator is on version 0.0.1, which is set in the Makefile variable VERSION.

Enabling OLM

Ensure OLM is enabled on your cluster before following this guide. operator-sdk olm has several subcommands that can install, uninstall, and check the status of particular OLM versions in a cluster.

Note: Certain cluster types may already have OLM enabled, but under a non-default ("olm") namespace, which can be configured by setting --olm-namespace=[non-default-olm-namespace] for operator-sdk olm status|uninstall subcommands.

You can check if OLM is already installed by running the following command, which will detect the installed OLM version automatically (0.15.1 in this example):

$ operator-sdk olm status
INFO[0000] Fetching CRDs for version "0.15.1"
INFO[0002] Fetching resources for version "0.15.1"
INFO[0002] Successfully got OLM status for version "0.15.1"

NAME                                            NAMESPACE    KIND                        STATUS
olm                                                          Namespace                   Installed
operatorgroups.operators.coreos.com                          CustomResourceDefinition    Installed
catalogsources.operators.coreos.com                          CustomResourceDefinition    Installed
subscriptions.operators.coreos.com                           CustomResourceDefinition    Installed
...

All resources listed should have status Installed.

Note: The operator-sdk olm status command is geared to detect the status of OLM that was installed by installation methods like operator-sdk olm install or by applying OLM manifests directly on the cluster. This command retrieves the resources that were compiled into SDK at the time of installation from the OLM manifests. However, if OLM was installed in a cluster in a custom fashion (such as in OpenShift clusters), it is possible that some resources will show a Not Found status when the operator-sdk olm status command is issued.

To check the true status of such resources in OCP clusters, run:

oc get <resource-name> -n <resource-namespace>

If OLM is not already installed, go ahead and install the latest version:

$ operator-sdk olm install
INFO[0000] Fetching CRDs for version "latest"
INFO[0001] Fetching resources for version "latest"
INFO[0007] Creating CRDs and resources
INFO[0007]   Creating CustomResourceDefinition "clusterserviceversions.operators.coreos.com"
INFO[0007]   Creating CustomResourceDefinition "installplans.operators.coreos.com"
INFO[0007]   Creating CustomResourceDefinition "subscriptions.operators.coreos.com"
...
NAME                                            NAMESPACE    KIND                        STATUS
clusterserviceversions.operators.coreos.com                  CustomResourceDefinition    Installed
installplans.operators.coreos.com                            CustomResourceDefinition    Installed
subscriptions.operators.coreos.com                           CustomResourceDefinition    Installed
catalogsources.operators.coreos.com                          CustomResourceDefinition    Installed
...

Note: By default, olm status and olm uninstall auto-detect the OLM version installed in your cluster. This can fail if the installation is broken in some way, so the version of OLM can be overridden using the --version flag provided with these commands.

Creating a bundle

If working with package manifests, see the package manifests tutorial.

We will now create bundle manifests by running make bundle in the root of the memcached-operator project.

$ make bundle
/home/user/go/bin/controller-gen rbac:roleName=manager-role crd webhook paths="./..." output:crd:artifacts:config=config/crd/bases
operator-sdk generate kustomize manifests -q
kustomize build config/manifests | operator-sdk generate bundle -q --overwrite --version 0.0.1
INFO[0000] Building annotations.yaml
INFO[0000] Writing annotations.yaml in /home/user/go/src/github.com/test-org/memcached-operator/bundle/metadata
INFO[0000] Building Dockerfile
INFO[0000] Writing bundle.Dockerfile in /home/user/go/src/github.com/test-org/memcached-operator
operator-sdk bundle validate ./bundle
INFO[0000] Found annotations file                        bundle-dir=bundle container-tool=docker
INFO[0000] Could not find optional dependencies file     bundle-dir=bundle container-tool=docker
INFO[0000] All validation tests have completed successfully

The above command will have created the following bundle artifacts: a manifests directory (bundle/manifests) containing a CSV and all CRDs from config/crds, metadata directory (bundle/metadata), and bundle.Dockerfile have been created in the Operator project. These files have been statically validated by operator-sdk bundle validate to ensure the on-disk bundle representation is correct.

Deploying an Operator with OLM

At this point in development we’ve generated all files necessary to build the memcached-operator bundle. Now we’re ready to test and deploy the Operator with OLM.

Note: If testing a bundle whose image will be hosted in a registry that is private and/or has a custom CA, these configuration steps must be complete.

Testing bundles

Before proceeding, make sure you’ve Installed OLM onto your cluster.

First, we need to build our bundle. To build a memcached-operator bundle, run:

$ make bundle-build bundle-push BUNDLE_IMG=<some-registry>/memcached-operator-bundle:v0.0.1

Now that the bundle image is present in a registry, operator-sdk run bundle can create a pod to serve that bundle to OLM via a Subscription, along with other OLM objects, ephemerally.

$ operator-sdk run bundle <some-registry>/memcached-operator-bundle:v0.0.1
INFO[0008] Successfully created registry pod: <some-registry>-memcached-operator-bundle-0-0-1
INFO[0008] Created CatalogSource: memcached-operator-catalog
INFO[0008] OperatorGroup "operator-sdk-og" created
INFO[0008] Created Subscription: memcached-operator-v0-0-1-sub
INFO[0019] Approved InstallPlan install-krv7q for the Subscription: memcached-operator-v0-0-1-sub
INFO[0019] Waiting for ClusterServiceVersion "default/memcached-operator.v0.0.1" to reach 'Succeeded' phase
INFO[0019]   Waiting for ClusterServiceVersion "default/memcached-operator.v0.0.1" to appear
INFO[0031]   Found ClusterServiceVersion "default/memcached-operator.v0.0.1" phase: Pending
INFO[0032]   Found ClusterServiceVersion "default/memcached-operator.v0.0.1" phase: Installing
INFO[0040]   Found ClusterServiceVersion "default/memcached-operator.v0.0.1" phase: Succeeded
INFO[0040] OLM has successfully installed "memcached-operator.v0.0.1"

Note: If the bundle that is being installed has dependencies, the --index-image flag allows adding a bundle to a catalog that contains that bundle’s dependencies.

Note: Version v1.22.0 and later of the operator-sdk use the new file-based catalog (FBC) bundle format by default. Earlier releases use the deprecated SQLite bundle format. If you use an earlier version of the Operator SDK, you must update to a newer version or specify the index image by adding the --index-image=quay.io/operator-framework/opm:v1.23.0 flag. For more information about this known issue, see the FAQ.

Upgrading a bundle to a newer version

We can use the operator-sdk run bundle-upgrade command with a newer version of bundle image to upgrade an existing operator bundle deployed on cluster. The command automates the manual orchestration typically required to upgrade an operator from one version to another. It extracts the package name from bundle, finds the existing subscription, updates the catalog source, deletes the existing registry pod and creates a new registry pod with the version of bundle image provided in the command.

Let’s upgrade the previously deployed memcached-operator bundle from version 0.0.1 to 0.0.2.

$ operator-sdk run bundle-upgrade <some-registry>/memcached-operator-bundle:v0.0.2
INFO[0002] Found existing subscription with name memcached-operator-bundle-0-0-1-sub and namespace default
INFO[0002] Found existing catalog source with name memcached-operator-catalog and namespace default
INFO[0007] Successfully created registry pod: <some-registry>-memcached-operator-bundle-0-0-2
INFO[0007] Updated catalog source memcached-operator-catalog with address and annotations
INFO[0008] Deleted previous registry pod with name "<some-registry>-memcached-operator-bundle-0-0-1"
INFO[0050] Approved InstallPlan install-c8fkh for the Subscription: memcached-operator-bundle-0-0-1-sub
INFO[0050] Waiting for ClusterServiceVersion "default/memcached-operator.v0.0.2" to reach 'Succeeded' phase
INFO[0050]   Waiting for ClusterServiceVersion "default/memcached-operator.v0.0.2" to appear
INFO[0052]   Found ClusterServiceVersion "default/memcached-operator.v0.0.2" phase: Pending
INFO[0057]   Found ClusterServiceVersion "default/memcached-operator.v0.0.2" phase: InstallReady
INFO[0058]   Found ClusterServiceVersion "default/memcached-operator.v0.0.2" phase: Installing
INFO[0095]   Found ClusterServiceVersion "default/memcached-operator.v0.0.2" phase: Succeeded
INFO[0095] Successfully upgraded to "memcached-operator.v0.0.2"

Note: If a bundle was installed using operator-sdk run bundle with a SQLite index image, the replaces field must be present and populated in the upgraded CSV’s spec.

Upgrading a bundle that was installed traditionally using OLM

An operator bundle can be upgraded even if it was originally deployed using OLM without using the run bundle command.

Let’s see how to deploy an operator bundle traditionally using OLM and then upgrade the operator bundle to a newer version.

First, create a CatalogSource by building the CatalogSource from a catalog.

$ oc create -f catalogsource.yaml

# catalogsource.yaml
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: etcdoperator
  namespace: default
spec:
  displayName: Etcd Operators
  image: <some-registry>/etcd-catalog:latest
  sourceType: grpc

Next, install the operator bundle by creating a subscription.

$ oc create -f subscription.yaml

# subscription.yaml
apiVersion: v1
items:
- apiVersion: operators.coreos.com/v1alpha1
  kind: Subscription
  metadata:
    name: etcd
    namespace: default
  spec:
    channel: "stable"
    installPlanApproval: Manual
    name: etcd
    source: etcdoperator
    sourceNamespace: default
    startingCSV: etcdoperator.v0.0.1

Once the Operator bundle is deployed, you can use the run bundle-upgrade command by specifying the new bundle image that you want to upgrade to.

$ operator-sdk run bundle-upgrade <some-registry>/etcd-bundle:v0.0.2
INFO[0000] Found existing subscription with name etcd and namespace default
INFO[0000] Found existing catalog source with name etcdoperator and namespace default
INFO[0005] Successfully created registry pod: <some-registry>-etcd-bundle-0-0-2
INFO[0005] Updated catalog source etcdoperator with address and annotations
INFO[0005] Deleted previous registry pod with name "<some-registry>-etcd-bundle-0-0-1"
INFO[0005] Approved InstallPlan install-6vrzh for the Subscription: etcd
INFO[0005] Waiting for ClusterServiceVersion "default/etcdoperator.v0.0.2" to reach 'Succeeded' phase
INFO[0005]   Waiting for ClusterServiceVersion "default/etcdoperator.v0.0.2" to appear
INFO[0007]   Found ClusterServiceVersion "default/etcdoperator.v0.0.2" phase: Pending
INFO[0008]   Found ClusterServiceVersion "default/etcdoperator.v0.0.2" phase: Installing
INFO[0018]   Found ClusterServiceVersion "default/etcdoperator.v0.0.2" phase: Succeeded
INFO[0018] Successfully upgraded to "etcdoperator.v0.0.2"

Deploying bundles in production

OLM and Operator Registry consumes Operator bundles via a catalog of Operators, implemented as an index image, which are composed of one or more bundles. To build and push a memcached-operator bundle image for version v0.0.1, run:

$ make bundle-build bundle-push BUNDLE_IMG=<some-registry>/memcached-operator-bundle:v0.0.1

Now you can build and push the catalog by running catalog-* Makfile targets, which use the Operator package manager tool opm to build the catalog:

$ make catalog-build catalog-push CATALOG_IMG=<some-registry>/memcached-operator-catalog:v0.0.1

Assuming IMAGE_TAG_BASE = <some-registry>/memcached-operator has the desired tag base, you can inline the above two commands to:

$ make bundle-build bundle-push catalog-build catalog-push

Which will build and push both <some-registry>/memcached-operator-bundle:v0.0.1 and <some-registry>/memcached-operator-catalog:v0.0.1.

Docs: OLM Integration Package Manifests Quickstart

Mon, 01 Jan 0001 00:00:00 +0000

Note As operator framework has moved to using bundle format by default, the package manifest commands have been deprecated and will be removed soon. It is suggested that you follow the bundle quickstart to package your operator.

This guide assumes you have followed the introduction and Setup section of the bundle quickstart, and have added the packagemanifests target to your Makefile as described here.

Creating package manifests

We will now create a package manifests format by running make packagemanifests in the root of the memcached-operator project:

$ make packagemanifests
/home/user/go/bin/controller-gen rbac:roleName=manager-role crd webhook paths="./..." output:crd:artifacts:config=config/crd/bases
operator-sdk generate kustomize manifests -q
kustomize build config/manifests | operator-sdk generate packagemanifests -q --version 0.0.1

A versioned manifests directory packagemanifests/0.0.1 containing a CSV and all CRDs in config/crds and a package manifest YAML file packagemanifests/<project-name>.package.yaml have been created in the Operator project.

Deploying an Operator with OLM

At this point in development we’ve generated all files necessary to build a memcached-operator registry. Now we’re ready to test the Operator with OLM.

Testing package manifests

operator-sdk run packagemanifests will create an Operator registry from manifests and metadata in the memcached-operator project, and inform OLM that memcached-operator v0.0.1 is ready to be deployed. This process effectively replicates production deployment in a constrained manner to make sure OLM can deploy our Operator successfully before attempting real production deployment.

run packagemanifests performs some optionally configurable setup under the hood, but for most use cases the following invocation is all we need:

$ operator-sdk run packagemanifests --version 0.0.1
INFO[0000] Running operator from directory packagemanifests
INFO[0000] Creating memcached-operator registry         
INFO[0000]   Creating ConfigMap "olm/memcached-operator-registry-manifests-package"
INFO[0000]   Creating ConfigMap "olm/memcached-operator-registry-manifests-0-0-1"
INFO[0000]   Creating Deployment "olm/memcached-operator-registry-server"
INFO[0000]   Creating Service "olm/memcached-operator-registry-server"
INFO[0000] Waiting for Deployment "olm/memcached-operator-registry-server" rollout to complete
INFO[0000]   Waiting for Deployment "olm/memcached-operator-registry-server" to rollout: 0 of 1 updated replicas are available
INFO[0066]   Deployment "olm/memcached-operator-registry-server" successfully rolled out
INFO[0066] Creating resources                           
INFO[0066]   Creating CatalogSource "default/memcached-operator-ocs"
INFO[0066]   Creating Subscription "default/memcached-operator-v0-0-1-sub"
INFO[0066]   Creating OperatorGroup "default/operator-sdk-og"
INFO[0066] Waiting for ClusterServiceVersion "default/memcached-operator.v0.0.1" to reach 'Succeeded' phase
INFO[0066]   Waiting for ClusterServiceVersion "default/memcached-operator.v0.0.1" to appear
INFO[0073]   Found ClusterServiceVersion "default/memcached-operator.v0.0.1" phase: Pending
INFO[0077]   Found ClusterServiceVersion "default/memcached-operator.v0.0.1" phase: InstallReady
INFO[0078]   Found ClusterServiceVersion "default/memcached-operator.v0.0.1" phase: Installing
INFO[0036]   Found ClusterServiceVersion "default/memcached-operator.v0.0.1" phase: Succeeded
INFO[0037] Successfully installed "memcached-operator.v0.0.1" on OLM version "0.15.1"

NAME                            NAMESPACE    KIND                        STATUS
memcacheds.cache.example.com    default      CustomResourceDefinition    Installed
memcached-operator.v0.0.1       default      ClusterServiceVersion       Installed

As long as both the ClusterServiceVersion and all CustomResourceDefinition's return an Installed status, the memcached-operator has been deployed successfully.

Now that we’re done testing the memcached-operator, we should probably clean up the Operator’s resources. operator-sdk cleanup will do this for you:

$ operator-sdk cleanup memcached-operator
INFO[0000] subscription "memcached-operator-v0-0-1-sub" deleted
INFO[0000] customresourcedefinition "memcacheds.cache.example.com" deleted
INFO[0000] clusterserviceversion "memcached-operator.v0.0.1" deleted
INFO[0000] clusterrole "memcached-operator-metrics-reader" deleted
INFO[0000] serviceaccount "default" deleted
INFO[0000] role "memcached-operator.v0.0.1-jhjk7" deleted
INFO[0000] rolebinding "memcached-operator.v0.0.1-jhjk7-default-mxv6m" deleted
INFO[0000] catalogsource "memcached-operator-ocs" deleted
INFO[0000] operatorgroup "operator-sdk-og" deleted
INFO[0001] operator "memcached-operator" uninstalled

Migrating packagemanifests to bundles

In order to migrate packagemanifests to bundles, operator-sdk pkgman-to-bundle command can be used.

As an example, consider the packagemanifests directory to have the following structure:

packagemanifests
└── etcd
    ├── 0.0.1
    │   ├── etcdcluster.crd.yaml
    │   └── etcdoperator.clusterserviceversion.yaml
    ├── 0.0.2
    │   ├── etcdbackup.crd.yaml
    │   ├── etcdcluster.crd.yaml
    │   ├── etcdoperator.v0.0.2.clusterserviceversion.yaml
    │   └── etcdrestore.crd.yaml
    └── etcd.package.yaml

Here, we have manifests for two versions of the etcd operator. The following command will generate bundles for each of these versions.

$ operator-sdk pkgman-to-bundle packagemanifests --output-dir etcd-bundle/
INFO[0000] Packagemanifests will be migrated to bundles in bundle directory
INFO[0000] Creating etcd-bundle/bundle-0.0.1/bundle.Dockerfile
INFO[0000] Creating etcd-bundle/bundle-0.0.1/metadata/annotations.yaml
...

This will create output bundles in the directory etcd-bundle. The output directory will look like:

etcd-bundle/
├── bundle-0.0.1
│   ├── bundle
│   │   ├── manifests
│   │   │   ├── etcdcluster.crd.yaml
│   │   │   ├── etcdoperator.clusterserviceversion.yaml
│   │   ├── metadata
│   │   │   └── annotations.yaml
│   │   └── tests
│   │       └── scorecard
│   │           └── config.yaml
│   └── bundle.Dockerfile
└── bundle-0.0.2
    ├── bundle
    │   ├── manifests
    │   │   ├── etcdbackup.crd.yaml
    │   │   ├── etcdcluster.crd.yaml
    │   │   ├── etcdoperator.v0.0.2.clusterserviceversion.yaml
    │   │   ├── etcdrestore.crd.yaml
    │   └── metadata
    │       └── annotations.yaml
    └── bundle.Dockerfile

To build images for the bundles, the base container image name can be provided using --image-tag-base flag. This name should be provided without the tag (: and characters following), as the command will tag each bundle image with its packagemanifests directory name, i.e. <image-tag-base>:<dir-name>. For example, the following command for the above packagemnifests directory would build the bundles quay.io/example/etcd-bundle:0.0.1 and quay.io/example/etcd-bundle:0.0.2.

operator-sdk pkgman-to-bundle packagemanifests --image-tag-base quay.io/example/etcd-bundle

A custom command can also be specified to build images, using the --build-cmd flag. The default command is docker build. For example:

$ operator-sdk pkgman-to-bundle packagemanifests --output-dir etcd-bundle/ --image-tag-base quay.io/example/etcd --build-cmd "podman build -f bundle.Dockerfile . -t"

However, if using a custom command, it needs to be made sure that the command is in the PATH or a fully qualified path name is provided as input to the flag.

Once the command has finished building your bundle images and they have been added to a catalog image, delete all bundle directories except for the latest one. This directory will contain manifests for your operator’s head bundle, and should be versioned with version control system like git. Move this directory and its bundle.Dockerfile to your project’s root:

$ cp -r ./etcd-bundle/bundle-0.0.2/* .
$ rm -rf ./etcd-bundle

Try building then running your bundle on a live cluster to make sure it works as expected:

$ make bundle bundle-build bundle-push
$ operator-sdk run bundle quay.io/example/etcd-bundle:0.0.2

Docs: OLM and Bundle CLI Overview

Mon, 01 Jan 0001 00:00:00 +0000

This document gives an overview of using operator-sdk to work with Operator manifests related to OLM, namely bundles and package manifests. See the manifests generation doc for an in-depth discussion of these commands.

OLM installation

The following operator-sdk subcommands manage an OLM installation:

olm install: install a particular version of OLM.
olm status: check the status of a particular version of OLM running in a cluster. This command can infer the version of an error-free OLM installation.
olm uninstall: uninstall a particular version of OLM running in a cluster. This command can infer the version of an error-free OLM installation.

Manifests and metadata

The following make recipes and operator-sdk subcommands create or interact with Operator package manifests and bundles:

generate kustomize manifests: creates kustomize bases and a kustomization.yaml in config/manifests.

Bundles

make bundle: runs the following commands:
- generate kustomize manifests: see above.
- generate bundle: creates a new or updates an existing bundle in the <project-root>/bundle directory. This command generates both manifests and metadata.
- bundle validate: validates an Operator bundle image or unpacked manifests and metadata.
make bundle-build: builds a bundle image using the bundle.Dockerfile generated by make bundle.
run bundle: runs the given Operator’s bundle image with an existing OLM installation.
run bundle-upgrade: upgrades the Operator bundle to a specified newer version.

Private bundle and catalog image registries

By default, projects are configured to push to and pull from a docker.io registry with namespace being the value passed to operator-sdk init --domain=<value>. Modify this value to push/pull bundle and catalog images with a different registry host or namespace.

All bundle and catalog image-related commands invoke opm (except for bundle image builds, for which docker is used directly). opm leverages the host’s image build/pull tools indirectly to perform various image tasks, so if your image registry is private or has a custom CA you must ensure the in-use build tool is able to push to/pull from the registry:

docker: config.json, certificate configuration
podman: auth.json, certificate configuration
none (containerd): uses docker’s config.json, certificate configuration

The run bundle or run bundle-upgrade commands use the none image tool, described above, in-cluster. These commands accept the names of secrets available in the deployment namespace that contain configuration file data. Ideally a cluster admin will provision a namespace and service account for bundle testing, such that they include and reference these secrets:

Create an image pull secret for your config.json and add it to your service account.

Create a generic secret with a cert.pem key containing root certificate(s) for your registry.

Once the above secrets have been created, run the either command with --pull-secret-name=<image pull secret> and --ca-secret-name=<certificate secret>:

operator-sdk run bundle private-custom-ca-reg.com/memcached-operator-bundle:v0.0.2 \
    --index-image private-custom-ca-reg.com/memcached-operator-catalog:v0.0.1 \
    --pull-secret-name foo-pull-sec \
    --ca-secret-name foo-cert-sec

You may have to set --namespace=<provisioned namespace> if the namespace encoded in your kubeconfig’s current context was not provisioned with these secrets.

Package Manifests

The operator-framework is removing support for the packagemanifests format in the near future, and migration efforts are currently underway. Therefore generate packagemanifests and run packagemanifests commands have been deprecated. For more details on bundle format refer here. To migrate from packagemanifests to the bundle format, use the operator-sdk pkgman-to-bundle command.

Docs: Generating Manifests and Metadata

Mon, 01 Jan 0001 00:00:00 +0000

This document describes how to manage packaging and shipping your Operator in the following stages:

Generate your first release - encapsulate the metadata needed to install your Operator with the Operator Lifecycle Manager and configure the permissions it needs from the generated SDK files.
Update your Operator - apply any updates to Operator manifests made during development.
Upgrade your Operator - carry over any customizations you have made and ensure a rolling update to the next version of your Operator.

Overview

Several operator-sdk subcommands manage operator-framework manifests and metadata, in particular ClusterServiceVersion's (CSVs), for an Operator: generate bundle and generate kustomize manifests. See this CLI overview for details on each command.

Note: The packagemanifests format is deprecated and support will be removed in operator-sdk v2.0.0.

Kustomize files

operator-sdk generate kustomize manifests generates a CSV kustomize base config/manifests/bases/<project-name>.clusterserviceversion.yaml and a config/manifests/kustomization.yaml by default. These files are required as kustomize build input in downstream commands.

By default, the command starts an interactive prompt if a CSV base in config/manifests/bases is not present to collect UI metadata. You can disable the interactive prompt by passing --interactive=false.

$ operator-sdk generate kustomize manifests
INFO[0000] Generating CSV manifest version 0.1.0

Display name for the operator (required):
> memcached

Comma-separated list of keywords for your operator (required):
> app, operator
...

Once this base is written, you may modify any of the fields labeled user in the fields section below. These values will persist when generating a bundle, so make necessary metadata changes here and not the generated bundle.

For Go Operators only: the command parses CSV markers from Go API type definitions, located in ./api for single group projects and ./apis for multigroup projects, to populate certain CSV fields. You can set an alternative path to the API types root directory with --apis-dir. These markers are not available to Ansible or Helm project types.

The command attempts to process the local types defined in your API. If you import a package that uses the same name as a local type, running the command causes an infinite loop. For example:

type PodStatus struct {
  SomeField string
  // imported type with the same name will infinitely trigger
  // the parser to process the local PodStatus type
  Status v1.PodStatus 
}

To prevent an infinite loop, edit the local type definition to use a different name. For example:

type PodStatusWrapper struct {
  SomeField string
  Status v1.PodStatus 
}

ClusterServiceVersion manifests

CSV’s are manifests that define all aspects of an Operator, from what CustomResourceDefinitions (CRDs) it uses to metadata describing the Operator’s maintainers. They are typically versioned by semver, much like Operator projects themselves; this version is present in both their metadata.name and spec.version fields. The CSV generator called by generate <bundle|packagemanifests> requires certain input manifests to construct a CSV manifest; all inputs are read when either command is invoked, along with a CSV’s base, to idempotently regenerate a CSV.

The following resource kinds are typically included in a CSV, which are addressed by config/manifests/kustomization.yaml:

Role: define Operator permissions within a namespace.
ClusterRole: define cluster-wide Operator permissions.
Deployment: define how the Operator’s operand is run in pods.
ValidatingWebhookConfiguration, MutatingWebhookConfiguration: configures webhooks for your manager to handle.
CustomResourceDefinition: definitions of custom objects your Operator reconciles.
Custom resource examples: examples of objects adhering to the spec of a particular CRD.

You can optionally specify an input ClusterServiceVersion manifest to the set of manifests passed to these generate subcommands instead of having them read from the base path. This is advantageous for those who would like to take full advantage of kustomize for their base. All fields unlabeled or labeled with marker below will be overwritten by these command, so make sure you do not kustomize build those fields!

Webhooks

A CSV allows you to define both admission and conversion webhooks at spec.webhookdefinitions. The generate <bundle|packagemanifests> commands, described below, will automatically add webhooks to your CSV if the following holds true:

A webhook configuration must be associated with a Service by name and namespace, whether in a CRD or in a *WebhookConfiguration file,
The associated Service must expose one spec.ports[*].targetPort that matches both containerPort and protocol of one element in the Operator Deployment's spec.template.spec.containers[*].ports.

By default, the manager’s Deployment is configured to mount a volume containing TLS cert data created by [cert-manager][cert-manager] into the manager’s container. OLM does not yet support cert-manager, so a JSON patch was added to remove this volume and mount such that OLM can itself create and manage certs for your Operator.

Note (for Go Operators only): If targeting OLM < v0.17.0, the manager’s default webhook server is not configured with the correct cert/key paths; the correct path is /apiserver.local.config/certificates/apiserver.{cert,key}. To cover this case, make the following changes to your main.go:

import (
  ...
  ctrl "sigs.k8s.io/controller-runtime"
  "sigs.k8s.io/controller-runtime/pkg/webhook"
)

func main() {
  ...

  // Configure a webhook.Server with the correct path and file names.
  // If webhookServer is nil, which will be the case of OLM >= 0.17 is available,
  // the manager will create a server for you using Host, Port,
  // and the default CertDir, KeyName, and CertName.
  var webhookServer *webhook.Server
  const legacyOLMCertDir = "/apiserver.local.config/certificates"
  if info, err := os.Stat(legacyOLMCertDir); err == nil && info.IsDir() {
    webhookServer = &webhook.Server{
      Host:     <some host>, // Set this only if normally set in ctrl.Options below.
      Port:     <some port>, // Set this only if normally set in ctrl.Options below.
      CertDir:  legacyOLMCertDir,
      CertName: "apiserver.crt",
      KeyName:  "apiserver.key",
    }
  }

  mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
    Host:          <some host>,
    Port:          <some port>,
    WebhookServer: webhookServer, // Host/Port will not be used if webhookServer is nil.
  })
 
  // Now you can register webhooks.
  ...
}

Note: The Service itself will still be placed into the manifests/ directory, in case other Operator resources require routing. Feel free to remove it otherwise.

Generate your first release

You’ve recently run operator-sdk init and created your APIs with operator-sdk create api. Now you’d like to package your Operator for deployment by OLM. Your Operator is at version v0.0.1; the Makefile variable VERSION should be set to 0.0.1. You’ve also built your operator image, example.com/memcached-operator:v0.0.1; if this image tag does not match yours, swap in the correct one in the docs below.

Bundle format

A bundle consists of manifests (CSV, CRDs, and other supported kinds) and metadata that define an Operator at a particular version, and an optional scorecard configuration file. You may have also heard of a bundle image. From the bundle docs:

An Operator Bundle is built as a scratch (non-runnable) container image that contains operator manifests and specific metadata in designated directories inside the image. Then, it can be pushed and pulled from an OCI-compliant container registry. Ultimately, an operator bundle will be used by Operator Registry and OLM to install an operator in OLM-enabled clusters.

At this stage in your Operator’s development, we only need to worry about generating bundle files; bundle images become important once you’re ready to publish your Operator.

SDK projects are scaffolded with a Makefile containing the bundle recipe by default, which wraps generate kustomize manifests, generate bundle, and other related commands.

By default make bundle will generate a CSV, copy CRDs and other supported kinds, generate metadata, and add your scorecard configuration in the bundle format:

$ make bundle
$ tree ./bundle
./bundle
├── manifests
│   ├── cache.example.com_memcacheds.yaml
│   ├── memcached-operator.clusterserviceversion.yaml
│   ├── memcached-operator-controller-manager-metrics-monitor_monitoring.coreos.com_v1_servicemonitor.yaml
│   ├── memcached-operator-controller-manager-metrics-service_v1_service.yaml
│   ├── memcached-operator-metrics-reader_rbac.authorization.k8s.io_v1beta1_clusterrole.yaml
│   └── memcached-operator-webhook-service_v1_service.yaml
├── metadata
│   └── annotations.yaml
└── tests
    └── scorecard
        └── config.yaml

Important: bundle generation is supposed to be idempotent, so any changes to CSV fields able to be persisted (marked (user) or (marker) below) must be made to the base set of manifests, typically found in config/.

Bundle metadata in bundle/metadata/annotations.yaml contains information about a particular Operator version available in a registry. OLM uses this information to install specific Operator versions and resolve dependencies. That file and bundle.Dockerfile contain the same annotations, the latter as LABELs, which do not need to be modified in most cases; if you do decide to modify them, both sets of annotations must be the same to ensure consistent Operator deployment.

Channels

Metadata for each bundle contains channel information as well:

Channels allow package authors to write different upgrade paths for different users (e.g. beta vs. stable).

Channels become important when publishing, but we should still be aware of them beforehand as they’re required values in our metadata. make bundle writes the channel alpha by default.

Validation

The bundle recipe includes a call to operator-sdk bundle validate, which runs a set of required object validators on your bundle that ensure both its format and content meet the bundle specification. These will always be run and cannot be disabled.

You may also have added CSV fields containing useful UI metadata for cluster console display, and want to ensure that metadata matches some hosted catalog’s submission requirements. The bundle validate command supports optional validators that can validate these bundle metadata. These validators are disabled by default, and can be selectively enabled with --select-optional <label-selector>. You can list all available optional validators by setting the --list-optional flag:

$ operator-sdk bundle validate --list-optional
NAME           LABELS                                                DESCRIPTION
operatorhub    name=operatorhub                                      OperatorHub.io metadata validation. 
               suite=operatorframework    
community      name=community                                        (stage: alpha) Community Operator bundle validation      
...

For example, you want to turn on the operatorhub validator shown above so you can publish the 0.0.1 operator you recently created on OperatorHub.io. To do so, you can modify your Makefile’s bundle recipe to validate any further changes you make to bundle UI metadata related to OperatorHub requirements:

bundle: ...
  ...
  operator-sdk bundle validate ./bundle --select-optional name=operatorhub

Also, see that you can test the bundle against the suite of test to ensure it against all criteria:

operator-sdk bundle validate ./bundle --select-optional suite=operatorframework

Note: The OperatorHub.io validator in the operatorframework optional suite allows you to validate that your manifests can work with a Kubernetes cluster of a particular version using the k8s-version optional key value:

operator-sdk bundle validate ./bundle --select-optional suite=operatorframework --optional-values=k8s-version=1.22

Documentation on optional validators:

operatorhub

Note: (stage: alpha) The Community validator allows you to validate your bundle.Dockerfile configuration against its specific criteria using the image-path optional key value:

operator-sdk bundle validate ./bundle --select-optional name=community --optional-values=image-path=bundle.Dockerfile

Package manifests format

A [package manifests][package-manifests] format consists of on-disk manifests (CSV, CRDs and other supported kinds) and metadata that define an Operator at all versions of that Operator. Each version is contained in its own directory, with a parent package manifest YAML file containing channel-to-version mappings, much like a bundle’s metadata.

If your Operator is already formatted as a package manifests and you do not wish to migrate to the bundle format yet, you should add the following to your Makefile to make development easier:

For Go-based Operator projects

# Options for "packagemanifests".
ifneq ($(origin FROM_VERSION), undefined)
PKG_FROM_VERSION := --from-version=$(FROM_VERSION)
endif
ifneq ($(origin CHANNEL), undefined)
PKG_CHANNELS := --channel=$(CHANNEL)
endif
ifeq ($(IS_CHANNEL_DEFAULT), 1)
PKG_IS_DEFAULT_CHANNEL := --default-channel
endif
PKG_MAN_OPTS ?= $(PKG_FROM_VERSION) $(PKG_CHANNELS) $(PKG_IS_DEFAULT_CHANNEL)

# Generate package manifests.
packagemanifests: kustomize manifests
  operator-sdk generate kustomize manifests -q
  cd config/manager && $(KUSTOMIZE) edit set image controller=$(IMG)
  $(KUSTOMIZE) build config/manifests | operator-sdk generate packagemanifests -q --version $(VERSION) $(PKG_MAN_OPTS)

For Helm/Ansible-based Operator projects

# Options for "packagemanifests".
ifneq ($(origin FROM_VERSION), undefined)
PKG_FROM_VERSION := --from-version=$(FROM_VERSION)
endif
ifneq ($(origin CHANNEL), undefined)
PKG_CHANNELS := --channel=$(CHANNEL)
endif
ifeq ($(IS_CHANNEL_DEFAULT), 1)
PKG_IS_DEFAULT_CHANNEL := --default-channel
endif
PKG_MAN_OPTS ?= $(PKG_FROM_VERSION) $(PKG_CHANNELS) $(PKG_IS_DEFAULT_CHANNEL)

# Generate package manifests.
packagemanifests: kustomize
  operator-sdk generate kustomize manifests -q
  cd config/manager && $(KUSTOMIZE) edit set image controller=$(IMG)
  $(KUSTOMIZE) build config/manifests | operator-sdk generate packagemanifests -q --version $(VERSION) $(PKG_MAN_OPTS)

By default make packagemanifests will generate a CSV, a package manifest file, and copy CRDs in the package manifests format:

$ make packagemanifests IMG=example.com/memcached-operator:v0.0.1
$ tree ./packagemanifests
./packagemanifests
├── 0.0.1
│   ├── cache.my.domain_memcacheds.yaml
│   └── memcached-operator.clusterserviceversion.yaml
└── memcached-operator.package.yaml

Update your Operator

Let’s say you added a new API App with group app and version v1alpha1 to your Operator project, and added a port to your manager Deployment in config/manager/manager.yaml.

If using a bundle format, the current version of your CSV can be updated by running:

$ make bundle IMG=example.com/memcached-operator:v0.0.1

If using a package manifests format, run:

$ make packagemanifests IMG=example.com/memcached-operator:v0.0.1

Running the command for either format will append your new CRD to spec.customresourcedefinitions.owned, replace the old data at spec.install.spec.deployments with your updated Deployment, and update your existing CSV manifest. The SDK will not overwrite user-defined fields like spec.maintainers.

Upgrade your Operator

Let’s say you’re upgrading your Operator to version v0.0.2, you’ve already updated the VERSION variable in your Makefile to 0.0.2, and built a new operator image example.com/memcached-operator:v0.0.2. You also want to add a new channel beta, and use it as the default channel.

First, update spec.replaces in your base CSV manifest to the current CSV name. In this case, the change would look like:

spec:
  ...
  replaces: memcached-operator.v0.0.1

Next, upgrade your bundle. If using a bundle format, a new version of your CSV can be created by running:

$ make bundle CHANNELS=beta DEFAULT_CHANNEL=beta IMG=example.com/memcached-operator:v0.0.2

If using a package manifests format, run:

$ make packagemanifests FROM_VERSION=0.0.1 CHANNEL=beta IS_CHANNEL_DEFAULT=1 IMG=example.com/memcached-operator:v0.0.2

Running the command for either format will persist user-defined fields, and updates spec.version and metadata.name.

For packagemanifests only The command will also populate spec.replaces with the old CSV version’s name.

CSV fields

Below are two lists of fields: the first is a list of all fields the SDK and OLM expect in a CSV, and the second are optional.

For Go Operators only: Several fields require user input (labeled user) or a CSV marker (labeled marker). This list may change as the SDK becomes better at generating CSV’s. These markers are not available to Ansible or Helm project types.

Required:

metadata.name _(user*)_: a *unique* name for this CSV of the format <project-name>.vX.Y.Z, ex. app-operator.v0.0.1.
spec.displayName (user) : a name to display for the Operator in Operator Hub.
spec.version _(user*)_: semantic version of the Operator, ex. 0.0.1.
spec.installModes (user): what mode of installation namespacing OLM should use. Currently all but MultiNamespace are supported by SDK Operators.
spec.customresourcedefinitions: any CRDs the Operator uses. Certain fields in elements of owned will be filled by the SDK.
- owned: all CRDs the Operator deploys itself from it’s bundle.
  - name: CRD’s metadata.name.
  - kind: CRD’s spec.names.kind.
  - version: CRD’s spec.version.
  - description (marker) : description of the CRD.
  - displayName (marker) : display name of the CRD.
  - resources (marker) : any Kubernetes resources used by the CRD, ex. Pod's and ConfigMap's.
  - specDescriptors (marker) : UI hints for inputs and outputs of the Operator’s spec.
  - statusDescriptors (marker) : UI hints for inputs and outputs of the Operator’s status.
  - actionDescriptors (user) : UI hints for an Operator’s in-cluster actions.
- required (user) : all CRDs the Operator expects to be present in-cluster, if any. All required element fields must be populated manually.

Optional:

spec.description (user) : a thorough description of the Operator’s functionality.
spec.keywords (user) : a list of keywords describing the Operator.
spec.maintainers (user) : a list of human or organizational entities maintaining the Operator, with a name and email.
spec.provider (user) : the Operator provider, with a name; usually an organization.
spec.labels (user) : a list of key:value pairs to be used by Operator internals.
metadata.annotations.alm-examples: CR examples, in JSON string literal format, for your CRD’s. Ideally one per CRD.
metadata.annotations.capabilities: level of Operator capability. See the Operator maturity model for a list of valid values.
spec.replaces (user): the name of the CSV being replaced by this CSV.
spec.links (user) : a list of URL’s to websites, documentation, etc. pertaining to the Operator or application being managed, each with a name and url.
spec.selector (user) : selectors by which the Operator can pair resources in a cluster.
spec.icon (user) : a base64-encoded icon unique to the Operator, set in a base64data field with a mediatype.
spec.maturity (user): the Operator’s maturity, ex. alpha.
spec.minKubeVersion (user): the minimal Kubernetes version supported by the Operator, ex. 1.16.0.
spec.webhookdefinitions: any webhooks the Operator uses.
spec.relatedImages (user): a list of image tags containing SHA digests mapped to in-CSV names that your Operator might require to perform their functions.
- To get the correct tag for an image available in some remote registry, run docker inspect --format='{{range $i, $d := .RepoDigests}}{{$d}}{{"\n"}}{{end}}' and choose the tag for the desired registry.
spec.skips (user): the names of one or more CSVs that should be skipped in a catalog’s upgrade graph.

* metadata.name and spec.version will only be automatically updated from the base CSV when you set --version when running generate <bundle|packagemanifests>.

Docs: Testing Operator Deployment with OLM

Mon, 01 Jan 0001 00:00:00 +0000

This document discusses the behavior of operator-sdk <run|cleanup> subcommands related to OLM deployment, and assumes you are familiar with OLM, related terminology, and have read the SDK-OLM integration design proposal.

Caveats

run bundle, run bundle-upgrade, run packagemanifests, and cleanup are intended to be used for testing purposes only, since these commands create a transient image registry that should not be used in production. Typically a registry is deployed separately and a set of catalog manifests are created in the cluster to inform OLM of that registry and which Operator versions it can deploy and where to deploy the Operator.
run bundle and run packagemanifests can only deploy one Operator and one version of that Operator at a time, and run bundle-upgrade can only upgrade one Operator and one version of that Operator at a time, hence their intended purpose being testing only.
If testing a bundle or catalog whose image will be hosted in a registry that is private and/or has a custom CA, these configuration steps must be complete.

`operator-sdk run bundle` command overview

operator-sdk run bundle assumes OLM is already installed and running on your cluster. It also assumes that your Operator has a valid bundle. See the [creating a bundle][creating-bundle] guide for more information. See the CLI overview for commands to work with an OLM installation and generate a bundle.

operator-sdk run bundle <bundle-image> [--index-image=] [--kubeconfig=] [--namespace=] [--timeout=] [--install-mode=(AllNamespace|OwnNamespace|SingleNamespace=)]

Let’s look at the configuration shared between run bundle, run packagemanifests, run bundle-upgrade and cleanup:

kubeconfig: the local path to a kubeconfig. This uses well-defined default loading rules to load the config if empty.
namespace: the cluster namespace in which Operator resources are created. This namespace must already exist in the cluster. This is an optional field which will default to the kubeconfig context if not provided.
timeout: a time string dictating the maximum time that run can run. The command will return an error if the timeout is exceeded.

Let’s look at the anatomy of the run bundle configuration model:

bundle-image: specifies the Operator bundle image, this is a required parameter. The bundle image must be pullable.
index-image: specifies an index image in which to inject the given bundle. This is an optional field which will default to quay.io/operator-framework/opm:latest
install-mode: specifies which supported installMode should be used to create an OperatorGroup by configuring its spec.targetNamespaces field. The InstallModeType string passed must be marked as “supported” in the CSV being installed.
- This option understands the following strings (assuming your CSV does as well):
  - AllNamespaces: the Operator will watch all namespaces (cluster-scoped Operators). This is the default.
  - OwnNamespace: the Operator will watch its own namespace (from namespace or the kubeconfig default).
  - SingleNamespace="my-ns": the Operator will watch a namespace, not necessarily its own.
- This is an optional parameter, but if the CSV does not support AllNamespaces then this parameter becomes required to instruct run bundle with the appropriate InstallModeType.

`operator-sdk run packagemanifests` command overview

operator-sdk run packagemanifests assumes OLM is already installed and running on your cluster, and that your Operator has a valid package manifests format. See the CLI overview for commands to work with an OLM installation and generate a package manifests format.

operator-sdk run packagemanifests <packagemanifests-root-dir> [--version=] [--kubeconfig=] [--namespace=] [--timeout=] [--install-mode=(AllNamespace|OwnNamespace|SingleNamespace=)]

Let’s look at the configuration shared between run bundle, run packagemanifests and cleanup:

kubeconfig: the local path to a kubeconfig. This uses well-defined default loading rules to load the config if empty.
namespace: the cluster namespace in which Operator resources are created. This namespace must already exist in the cluster. This is an optional field which will default to the kubeconfig context if not provided.
timeout: a time string dictating the maximum time that run can run. The command will return an error if the timeout is exceeded.

Let’s look at the anatomy of the run packagemanifests configuration model:

packagemanifests-root-dir: a directory containing the Operator’s package manifests, this is a required parameter.
install-mode: specifies which supported installMode should be used to create an OperatorGroup by configuring its spec.targetNamespaces field. The InstallModeType string passed must be marked as “supported” in the CSV being installed.
- This option understands the following strings (assuming your CSV does as well):
  - AllNamespaces: the Operator will watch all namespaces (cluster-scoped Operators). This is the default.
  - OwnNamespace: the Operator will watch its own namespace (from namespace or the kubeconfig default).
  - SingleNamespace="my-ns": the Operator will watch a namespace, not necessarily its own.
- This is an optional parameter, but if the CSV does not support AllNamespaces then this parameter becomes required to instruct run packagemanifests with the appropriate InstallModeType.
version: the version of the Operator to deploy. It must be a semantic version, ex. 0.0.1. This version must match the version of the CSV manifest found in manifests-dir, e.g. packagemanifests/0.0.1 in an Operator SDK project.

`operator-sdk run bundle-upgrade` command overview

operator-sdk run bundle-upgrade assumes OLM is already installed and running on your cluster and that the Operator has a valid bundle. It also assumes that the previous version of the Operator was either deployed on the cluster using run bundle command or traditionally via OLM. Another assumption of this command is that the newer operator bundle should not exist in the index image, if the previous version of the operator bundle was installed traditionally using OLM. This will cause the registry pod to fail as the bundle is already added to the index that provides package and csv. See the CLI overview for commands to work with an OLM installation and generate a bundle.

operator-sdk run bundle-upgrade <bundle-image> [--kubeconfig=] [--namespace=] [--timeout=]

Let’s look at the anatomy of the run bundle-upgrade configuration model:

bundle-image: specifies the Operator bundle image, this is a required parameter. The bundle image must be pullable.

`operator-sdk cleanup` command overview

operator-sdk cleanup assumes an Operator was deployed using run bundle or run packagemanifests.

operator-sdk cleanup <operatorPackageName> [--delete-all=] [--delete-crds=] [--delete-operator-groups=] [--kubeconfig=] [--namespace=] [--timeout=]

Let’s look at the configuration shared between run bundle, run packagemanifests and cleanup:

kubeconfig: the local path to a kubeconfig. This uses well-defined default loading rules to load the config if empty.
namespace: the cluster namespace in which Operator resources are created. This namespace must already exist in the cluster. This is an optional field which will default to the kubeconfig context if not provided.
timeout: a time string dictating the maximum time that run can run. The command will return an error if the timeout is exceeded.

Let’s look at the anatomy of the cleanup configuration model:

operatorPackageName: the Operator’s package name which you want to remove from the cluster, e.g. memcached-operator. This is a required parameter.
delete-all: a boolean indicating to enable all the delete flags that are present. This is an optional field which will default to true if not provided. If set to true, it will enable all the delete flags to be true. If set to false, it will enable specific delete flags.
delete-crds: a boolean indicating to delete all owned CRDs and CRs. This is an optional field which will default to false if not provided. If set to true, owned CRDs and CRs will be deleted.
delete-operator-groups: a boolean indicating to delete all operator groups. This is an optional field which will default to false if not provided. If set to true, operator groups will be deleted.

Operator SDK – Operator SDK Integration with Operator Lifecycle Manager

Docs: OLM Integration Bundle Quickstart

Prerequisites

Steps

Next Steps

Docs: OLM Integration Bundle Tutorial

Setup

Enabling OLM

Creating a bundle

Deploying an Operator with OLM

Testing bundles

Upgrading a bundle to a newer version

Upgrading a bundle that was installed traditionally using OLM

Deploying bundles in production

Further reading

Docs: OLM Integration Package Manifests Quickstart

Creating package manifests

Deploying an Operator with OLM

Testing package manifests

Migrating packagemanifests to bundles

Docs: OLM and Bundle CLI Overview

OLM installation

Manifests and metadata

Bundles

Private bundle and catalog image registries

Package Manifests

Docs: Generating Manifests and Metadata

Overview

Kustomize files

ClusterServiceVersion manifests

Webhooks

Generate your first release

Bundle format

Channels

Validation

Package manifests format

Update your Operator

Upgrade your Operator

CSV fields

Docs: Testing Operator Deployment with OLM

Caveats

operator-sdk run bundle command overview

operator-sdk run packagemanifests command overview

operator-sdk run bundle-upgrade command overview

operator-sdk cleanup command overview

`operator-sdk run bundle` command overview

`operator-sdk run packagemanifests` command overview

`operator-sdk run bundle-upgrade` command overview

`operator-sdk cleanup` command overview