Generating a cluster service version (CSV)

A cluster service version (CSV), defined by a ClusterServiceVersion object, is a YAML manifest created from Operator metadata that assists Operator Lifecycle Manager (OLM) in running the Operator in a cluster. It is the metadata that accompanies an Operator container image, used to populate user interfaces with information such as its logo, description, and version. It is also a source of technical information that is required to run the Operator, like the RBAC rules it requires and which custom resources (CRs) it manages or depends on.

The Operator SDK includes the generate csv subcommand to generate a CSV for the current Operator project customized using information contained in manually-defined YAML manifests and Operator source files.

A CSV-generating command removes the responsibility of Operator authors having in-depth OLM knowledge in order for their Operator to interact with OLM or publish metadata to the Catalog Registry. Further, because the CSV spec will likely change over time as new Kubernetes and OLM features are implemented, the Operator SDK is equipped to easily extend its update system to handle new CSV features going forward.

The CSV version is the same as the Operator version, and a new CSV is generated when upgrading Operator versions. Operator authors can use the --csv-version flag to have their Operator state encapsulated in a CSV with the supplied semantic version:

$ operator-sdk generate csv --csv-version <version>

This action is idempotent and only updates the CSV file when a new version is supplied, or a YAML manifest or source file is changed. Operator authors should not have to directly modify most fields in a CSV manifest. Those that require modification are defined in this guide. For example, the CSV version must be included in metadata.name.

How CSV generation works

The deploy/ directory of an Operator project is the standard location for all manifests required to deploy an Operator. The Operator SDK can use data from manifests in deploy/ to write a cluster service version (CSV).

The following command:

$ operator-sdk generate csv --csv-version <version>

writes a CSV YAML file to the deploy/olm-catalog/ directory by default.

Exactly three types of manifests are required to generate a CSV:

• operator.yaml

• *_{crd,cr}.yaml

• RBAC role files, for example role.yaml

Operator authors may have different versioning requirements for these files and can configure which specific files are included in the deploy/olm-catalog/csv-config.yaml file.

Workflow

Depending on whether an existing CSV is detected, and assuming all configuration defaults are used, the generate csv subcommand either:

• Creates a new CSV, with the same location and naming convention as exists currently, using available data in YAML manifests and source files.

  1. The update mechanism checks for an existing CSV in deploy/. When one is not found, it creates a ClusterServiceVersion object, referred to here as a cache, and populates fields easily derived from Operator metadata, such as Kubernetes API ObjectMeta.

  2. The update mechanism searches deploy/ for manifests that contain data a CSV uses, such as a Deployment resource, and sets the appropriate CSV fields in the cache with this data.

  3. After the search completes, every cache field populated is written back to a CSV YAML file.

or:

• Updates an existing CSV at the currently pre-defined location, using available data in YAML manifests and source files.

  1. The update mechanism checks for an existing CSV in deploy/. When one is found, the CSV YAML file contents are marshaled into a CSV cache.

  2. The update mechanism searches deploy/ for manifests that contain data a CSV uses, such as a Deployment resource, and sets the appropriate CSV fields in the cache with this data.

  3. After the search completes, every cache field populated is written back to a CSV YAML file.

CSV composition configuration

Operator authors can configure CSV composition by populating several fields in the deploy/olm-catalog/csv-config.yaml file:

Manually-defined CSV fields

Many CSV fields cannot be populated using generated, generic manifests that are not specific to Operator SDK. These fields are mostly human-written metadata about the Operator and various custom resource definitions (CRDs).

Operator authors must directly modify their cluster service version (CSV) YAML file, adding personalized data to the following required fields. The Operator SDK gives a warning during CSV generation when a lack of data in any of the required fields is detected.

The following tables detail which manually-defined CSV fields are required and which are optional.

Further details on what data each field above should hold are found in the CSV spec.

Additional resources

• Operator maturity model

Operator metadata annotations

Operator developers can manually define certain annotations in the metadata of a cluster service version (CSV) to enable features or highlight capabilities in user interfaces (UIs), such as OperatorHub.

The following table lists Operator metadata annotations that can be manually defined using metadata.annotations fields.

Example use cases

Operator supports disconnected and proxy-aware

operators.openshift.io/infrastructure-features: '["disconnected", "proxy-aware"]'

Operator requires an OpenShift Container Platform license

operators.openshift.io/valid-subscription: '["OpenShift Container Platform"]'

Operator requires a 3scale license

operators.openshift.io/valid-subscription: '["3Scale Commercial License", "Red Hat Managed Integration"]'

Operator supports disconnected and proxy-aware, and requires an OpenShift Container Platform license

operators.openshift.io/infrastructure-features: '["disconnected", "proxy-aware"]'
operators.openshift.io/valid-subscription: '["OpenShift Container Platform"]'

Additional resources

• CRD templates

• Initializing required custom resources

• Setting a suggested namespace

• Enabling your Operator for restricted network environments (disconnected mode)

• Hiding internal objects

• Support for FIPS crytography

Generating a CSV

Prerequisites

• An Operator project generated using the Operator SDK

Procedure

1. In your Operator project, configure your CSV composition by modifying the deploy/olm-catalog/csv-config.yaml file, if desired.

2. Generate the CSV:

   $ operator-sdk generate csv --csv-version <version>

3. In the new CSV generated in the deploy/olm-catalog/ directory, ensure all required, manually-defined fields are set appropriately.

Enabling your Operator for restricted network environments

As an Operator author, your Operator must meet additional requirements to run properly in a restricted network, or disconnected, environment.

Operator requirements for supporting disconnected mode

• In the cluster service version (CSV) of your Operator:

  • List any related images, or other container images that your Operator might require to perform their functions.

  • Reference all specified images by a digest (SHA) and not by a tag.

• All dependencies of your Operator must also support running in a disconnected mode.

• Your Operator must not require any off-cluster resources.

For the CSV requirements, you can make the following changes as the Operator author.

Prerequisites

• An Operator project with a CSV.

Procedure

1. Use SHA references to related images in two places in the CSV for your Operator:

   1. Update spec.relatedImages:

      ...
      spec:
        relatedImages: (1)
          - name: etcd-operator (2)
            image: quay.io/etcd-operator/operator@sha256:d134a9865524c29fcf75bbc4469013bc38d8a15cb5f41acfddb6b9e492f556e4 (3)
          - name: etcd-image
            image: quay.io/etcd-operator/etcd@sha256:13348c15263bd8838ec1d5fc4550ede9860fcbb0f843e48cbccec07810eebb68
      ...

      1	Create a relatedImages section and set the list of related images.
      2	Specify a unique identifier for the image.
      3	Specify each image by a digest (SHA), not by an image tag.

   2. Update the env section in the deployment when declaring environment variables that inject the image that the Operator should use:

      spec:
        install:
          spec:
            deployments:
            - name: etcd-operator-v3.1.1
              spec:
                replicas: 1
                selector:
                  matchLabels:
                    name: etcd-operator
                strategy:
                  type: Recreate
                template:
                  metadata:
                    labels:
                      name: etcd-operator
                  spec:
                    containers:
                    - args:
                      - /opt/etcd/bin/etcd_operator_run.sh
                      env:
                      - name: WATCH_NAMESPACE
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.annotations['olm.targetNamespaces']
                      - name: ETCD_OPERATOR_DEFAULT_ETCD_IMAGE (1)
                        value: quay.io/etcd-operator/etcd@sha256:13348c15263bd8838ec1d5fc4550ede9860fcbb0f843e48cbccec07810eebb68 (2)
                      - name: ETCD_LOG_LEVEL
                        value: INFO
                      image: quay.io/etcd-operator/operator@sha256:d134a9865524c29fcf75bbc4469013bc38d8a15cb5f41acfddb6b9e492f556e4 (3)
                      imagePullPolicy: IfNotPresent
                      livenessProbe:
                        httpGet:
                          path: /healthy
                          port: 8080
                        initialDelaySeconds: 10
                        periodSeconds: 30
                      name: etcd-operator
                      readinessProbe:
                        httpGet:
                          path: /ready
                          port: 8080
                        initialDelaySeconds: 10
                        periodSeconds: 30
                      resources: {}
                    serviceAccountName: etcd-operator
          strategy: deployment

      1	Inject the images referenced by the Operator by using environment variables.
      2	Specify each image by a digest (SHA), not by an image tag.
      3	Also reference the Operator container image by a digest (SHA), not by an image tag.

      When configuring probes, the timeoutSeconds value must be lower than the periodSeconds value. The timeoutSeconds default value is 1. The periodSeconds default value is 10.

2. Add the disconnected annotation, which indicates that the Operator works in a disconnected environment:

   metadata:
     annotations:
       operators.openshift.io/infrastructure-features: '["disconnected"]'

   Operators can be filtered in OperatorHub by this infrastructure feature.

Enabling your Operator for multiple architectures and operating systems

Operator Lifecycle Manager (OLM) assumes that all Operators run on Linux hosts. However, as an Operator author, you can specify whether your Operator supports managing workloads on other architectures, if worker nodes are available in the OKD cluster.

If your Operator supports variants other than AMD64 and Linux, you can add labels to the cluster service version (CSV) that provides the Operator to list the supported variants. Labels indicating supported architectures and operating systems are defined by the following:

labels:
    operatorframework.io/arch.<arch>: supported (1)
    operatorframework.io/os.<os>: supported (2)

If a CSV does not include an os label, it is treated as if it has the following Linux support label by default:

labels:
    operatorframework.io/os.linux: supported

If a CSV does not include an arch label, it is treated as if it has the following AMD64 support label by default:

labels:
    operatorframework.io/arch.amd64: supported

If an Operator supports multiple node architectures or operating systems, you can add multiple labels, as well.

Prerequisites

• An Operator project with a CSV.

• To support listing multiple architectures and operating systems, your Operator image referenced in the CSV must be a manifest list image.

• For the Operator to work properly in restricted network, or disconnected, environments, the image referenced must also be specified using a digest (SHA) and not by a tag.

Procedure

• Add a label in the metadata.labels of your CSV for each supported architecture and operating system that your Operator supports:

  labels:
    operatorframework.io/arch.s390x: supported
    operatorframework.io/os.zos: supported
    operatorframework.io/os.linux: supported (1)
    operatorframework.io/arch.amd64: supported (1)

  1	After you add a new architecture or operating system, you must also now include the default os.linux and arch.amd64 variants explicitly.

Additional resources

• See the Image Manifest V 2, Schema 2 specification for more information on manifest lists.

Architecture and operating system support for Operators

The following strings are supported in Operator Lifecycle Manager (OLM) on OKD when labeling or filtering Operators that support multiple architectures and operating systems:

Setting a suggested namespace

Some Operators must be deployed in a specific namespace, or with ancillary resources in specific namespaces, in order to work properly. If resolved from a subscription, Operator Lifecycle Manager (OLM) defaults the namespaced resources of an Operator to the namespace of its subscription.

As an Operator author, you can instead express a desired target namespace as part of your cluster service version (CSV) to maintain control over the final namespaces of the resources installed for their Operators. When adding the Operator to a cluster using OperatorHub, this enables the web console to autopopulate the suggested namespace for the cluster administrator during the installation process.

Procedure

• In your CSV, set the operatorframework.io/suggested-namespace annotation to your suggested namespace:

  metadata:
    annotations:
      operatorframework.io/suggested-namespace: <namespace> (1)

  1	Set your suggested namespace.

Defining webhooks

Webhooks allow Operator authors to intercept, modify, and accept or reject resources before they are saved to the object store and handled by the Operator controller. Operator Lifecycle Manager (OLM) can manage the lifecycle of these webhooks when they are shipped alongside your Operator.

The cluster service version (CSV) resource of an Operator can include a webhookdefinitions section to define the following types of webhooks:

• Admission webhooks (validating and mutating)

• Conversion webhooks

Procedure

• Add a webhookdefinitions section to the spec section of the CSV of your Operator and include any webhook definitions using a type of ValidatingAdmissionWebhook, MutatingAdmissionWebhook, or ConversionWebhook. The following example contains all three types of webhooks:

  CSV containing webhooks

    apiVersion: operators.coreos.com/v1alpha1
    kind: ClusterServiceVersion
    metadata:
      name: webhook-operator.v0.0.1
    spec:
      customresourcedefinitions:
        owned:
        - kind: WebhookTest
          name: webhooktests.webhook.operators.coreos.io (1)
          version: v1
      install:
        spec:
          deployments:
          - name: webhook-operator-webhook
            ...
            ...
            ...
        strategy: deployment
      installModes:
      - supported: false
        type: OwnNamespace
      - supported: false
        type: SingleNamespace
      - supported: false
        type: MultiNamespace
      - supported: true
        type: AllNamespaces
      webhookdefinitions:
      - type: ValidatingAdmissionWebhook (2)
        admissionReviewVersions:
        - v1beta1
        - v1
        containerPort: 443
        targetPort: 4343
        deploymentName: webhook-operator-webhook
        failurePolicy: Fail
        generateName: vwebhooktest.kb.io
        rules:
        - apiGroups:
          - webhook.operators.coreos.io
          apiVersions:
          - v1
          operations:
          - CREATE
          - UPDATE
          resources:
          - webhooktests
        sideEffects: None
        webhookPath: /validate-webhook-operators-coreos-io-v1-webhooktest
      - type: MutatingAdmissionWebhook (3)
        admissionReviewVersions:
        - v1beta1
        - v1
        containerPort: 443
        targetPort: 4343
        deploymentName: webhook-operator-webhook
        failurePolicy: Fail
        generateName: mwebhooktest.kb.io
        rules:
        - apiGroups:
          - webhook.operators.coreos.io
          apiVersions:
          - v1
          operations:
          - CREATE
          - UPDATE
          resources:
          - webhooktests
        sideEffects: None
        webhookPath: /mutate-webhook-operators-coreos-io-v1-webhooktest
      - type: ConversionWebhook (4)
        admissionReviewVersions:
        - v1beta1
        - v1
        containerPort: 443
        targetPort: 4343
        deploymentName: webhook-operator-webhook
        generateName: cwebhooktest.kb.io
        sideEffects: None
        webhookPath: /convert
        conversionCRDs:
        - webhooktests.webhook.operators.coreos.io (5)
  ...

  1	The CRDs targeted by the conversion webhook must exist here.
  2	A validating admission webhook.
  3	A mutating admission webhook.
  4	A conversion webhook.
  5	The spec.PreserveUnknownFields property of each CRD must be set to false or nil.

Additional resources

• Types of webhook admission plug-ins

• Kubernetes documentation:

  • Validating admission webhooks

  • Mutating admission webhooks

  • Conversion webhooks

Webhook considerations for OLM

When deploying an Operator with webhooks using Operator Lifecycle Manager (OLM), you must define the following:

• The type field must be set to either ValidatingAdmissionWebhook, MutatingAdmissionWebhook, or ConversionWebhook, or the CSV will be placed in a failed phase.

• The CSV must contain a deployment whose name is equivalent to the value supplied in the deploymentName field of the webhookdefinition.

When the webhook is created, OLM ensures that the webhook only acts upon namespaces that match the Operator group that the Operator is deployed in.

Certificate authority constraints

OLM is configured to provide each deployment with a single certificate authority (CA). The logic that generates and mounts the CA into the deployment was originally used by the API service lifecycle logic. As a result:

• The TLS certificate file is mounted to the deployment at /apiserver.local.config/certificates/apiserver.crt.

• The TLS key file is mounted to the deployment at /apiserver.local.config/certificates/apiserver.key.

Admission webhook rules constraints

To prevent an Operator from configuring the cluster into an unrecoverable state, OLM places the CSV in the failed phase if the rules defined in an admission webhook intercept any of the following requests:

• Requests that target all groups

• Requests that target the operators.coreos.com group

• Requests that target the ValidatingWebhookConfigurations or MutatingWebhookConfigurations resources

Conversion webhook constraints

OLM places the CSV in the failed phase if a conversion webhook definition does not adhere to the following constraints:

• CSVs featuring a conversion webhook can only support the AllNamespaces install mode.

• The CRD targeted by the conversion webhook must have its spec.preserveUnknownFields field set to false or nil.

• The conversion webhook defined in the CSV must target an owned CRD.

• There can only be one conversion webhook on the entire cluster for a given CRD.

Understanding your custom resource definitions (CRDs)

There are two types of custom resource definitions (CRDs) that your Operator can use: ones that are owned by it and ones that it depends on, which are required.

Owned CRDs

The custom resource definitions (CRDs) owned by your Operator are the most important part of your CSV. This establishes the link between your Operator and the required RBAC rules, dependency management, and other Kubernetes concepts.

It is common for your Operator to use multiple CRDs to link together concepts, such as top-level database configuration in one object and a representation of replica sets in another. Each one should be listed out in the CSV file.

The following example depicts a MongoDB Standalone CRD that requires some user input in the form of a secret and config map, and orchestrates services, stateful sets, pods and config maps:

Example owned CRD

      - displayName: MongoDB Standalone
        group: mongodb.com
        kind: MongoDbStandalone
        name: mongodbstandalones.mongodb.com
        resources:
          - kind: Service
            name: ''
            version: v1
          - kind: StatefulSet
            name: ''
            version: v1beta2
          - kind: Pod
            name: ''
            version: v1
          - kind: ConfigMap
            name: ''
            version: v1
        specDescriptors:
          - description: Credentials for Ops Manager or Cloud Manager.
            displayName: Credentials
            path: credentials
            x-descriptors:
              - 'urn:alm:descriptor:com.tectonic.ui:selector:core:v1:Secret'
          - description: Project this deployment belongs to.
            displayName: Project
            path: project
            x-descriptors:
              - 'urn:alm:descriptor:com.tectonic.ui:selector:core:v1:ConfigMap'
          - description: MongoDB version to be installed.
            displayName: Version
            path: version
            x-descriptors:
              - 'urn:alm:descriptor:com.tectonic.ui:label'
        statusDescriptors:
          - description: The status of each of the pods for the MongoDB cluster.
            displayName: Pod Status
            path: pods
            x-descriptors:
              - 'urn:alm:descriptor:com.tectonic.ui:podStatuses'
        version: v1
        description: >-
          MongoDB Deployment consisting of only one host. No replication of
          data.

Required CRDs

Relying on other required CRDs is completely optional and only exists to reduce the scope of individual Operators and provide a way to compose multiple Operators together to solve an end-to-end use case.

An example of this is an Operator that might set up an application and install an etcd cluster (from an etcd Operator) to use for distributed locking and a Postgres database (from a Postgres Operator) for data storage.

Operator Lifecycle Manager (OLM) checks against the available CRDs and Operators in the cluster to fulfill these requirements. If suitable versions are found, the Operators are started within the desired namespace and a service account created for each Operator to create, watch, and modify the Kubernetes resources required.

Example required CRD

    required:
    - name: etcdclusters.etcd.database.coreos.com
      version: v1beta2
      kind: EtcdCluster
      displayName: etcd Cluster
      description: Represents a cluster of etcd nodes.

CRD upgrades

OLM upgrades a custom resource definition (CRD) immediately if it is owned by a singular cluster service version (CSV). If a CRD is owned by multiple CSVs, then the CRD is upgraded when it has satisfied all of the following backward compatible conditions:

• All existing serving versions in the current CRD are present in the new CRD.

• All existing instances, or custom resources, that are associated with the serving versions of the CRD are valid when validated against the validation schema of the new CRD.

Adding a new CRD version

Procedure

To add a new version of a CRD to your Operator:

1. Add a new entry in the CRD resource under the versions section of your CSV.

   For example, if the current CRD has a version v1alpha1 and you want to add a new version v1beta1 and mark it as the new storage version, add a new entry for v1beta1:

   versions:
     - name: v1alpha1
       served: true
       storage: false
     - name: v1beta1 (1)
       served: true
       storage: true

   1	New entry.

2. Ensure the referencing version of the CRD in the owned section of your CSV is updated if the CSV intends to use the new version:

   customresourcedefinitions:
     owned:
     - name: cluster.example.com
       version: v1beta1 (1)
       kind: cluster
       displayName: Cluster

   1	Update the version.

3. Push the updated CRD and CSV to your bundle.

Deprecating or removing a CRD version

Operator Lifecycle Manager (OLM) does not allow a serving version of a custom resource definition (CRD) to be removed right away. Instead, a deprecated version of the CRD must be first disabled by setting the served field in the CRD to false. Then, the non-serving version can be removed on the subsequent CRD upgrade.

Procedure

To deprecate and remove a specific version of a CRD:

1. Mark the deprecated version as non-serving to indicate this version is no longer in use and may be removed in a subsequent upgrade. For example:

   versions:
     - name: v1alpha1
       served: false (1)
       storage: true

   1	Set to false.

2. Switch the storage version to a serving version if the version to be deprecated is currently the storage version. For example:

   versions:
     - name: v1alpha1
       served: false
       storage: false (1)
     - name: v1beta1
       served: true
       storage: true (1)

   1	Update the storage fields accordingly.

   In order to remove a specific version that is or was the storage version from a CRD, that version must be removed from the storedVersion in the status of the CRD. OLM will attempt to do this for you if it detects a stored version no longer exists in the new CRD.

3. Upgrade the CRD with the above changes.

4. In subsequent upgrade cycles, the non-serving version can be removed completely from the CRD. For example:

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

5. Ensure the referencing CRD version in the owned section of your CSV is updated accordingly if that version is removed from the CRD.

CRD templates

Users of your Operator must be made aware of which options are required versus optional. You can provide templates for each of your custom resource definitions (CRDs) with a minimum set of configuration as an annotation named alm-examples. Compatible UIs will pre-fill this template for users to further customize.

The annotation consists of a list of the kind, for example, the CRD name and the corresponding metadata and spec of the Kubernetes object.

The following full example provides templates for EtcdCluster, EtcdBackup and EtcdRestore:

metadata:
  annotations:
    alm-examples: >-
      [{"apiVersion":"etcd.database.coreos.com/v1beta2","kind":"EtcdCluster","metadata":{"name":"example","namespace":"default"},"spec":{"size":3,"version":"3.2.13"}},{"apiVersion":"etcd.database.coreos.com/v1beta2","kind":"EtcdRestore","metadata":{"name":"example-etcd-cluster"},"spec":{"etcdCluster":{"name":"example-etcd-cluster"},"backupStorageType":"S3","s3":{"path":"<full-s3-path>","awsSecret":"<aws-secret>"}}},{"apiVersion":"etcd.database.coreos.com/v1beta2","kind":"EtcdBackup","metadata":{"name":"example-etcd-cluster-backup"},"spec":{"etcdEndpoints":["<etcd-cluster-endpoints>"],"storageType":"S3","s3":{"path":"<full-s3-path>","awsSecret":"<aws-secret>"}}}]

Hiding internal objects

It is common practice for Operators to use custom resource definitions (CRDs) internally to accomplish a task. These objects are not meant for users to manipulate and can be confusing to users of the Operator. For example, a database Operator might have a Replication CRD that is created whenever a user creates a Database object with replication: true.

As an Operator author, you can hide any CRDs in the user interface that are not meant for user manipulation by adding the operators.operatorframework.io/internal-objects annotation to the cluster service version (CSV) of your Operator.

Procedure

1. Before marking one of your CRDs as internal, ensure that any debugging information or configuration that might be required to manage the application is reflected on the status or spec block of your CR, if applicable to your Operator.

2. Add the operators.operatorframework.io/internal-objects annotation to the CSV of your Operator to specify any internal objects to hide in the user interface:

   Internal object annotation

   apiVersion: operators.coreos.com/v1alpha1
   kind: ClusterServiceVersion
   metadata:
     name: my-operator-v1.2.3
     annotations:
       operators.operatorframework.io/internal-objects: '["my.internal.crd1.io","my.internal.crd2.io"]' (1)
   ...

   1	Set any internal CRDs as an array of strings.

Initializing required custom resources

An Operator might require the user to instantiate a custom resource before the Operator can be fully functional. However, it can be challenging for a user to determine what is required or how to define the resource.

As an Operator developer, you can specify a single required custom resource that must be created at the time that the Operator is installed by adding the operatorframework.io/initialization-resource annotation to the cluster service version (CSV). The annotation must include a template that contains a complete YAML definition that is required to initialize the resource during installation.

If this annotation is defined, after installing the Operator from the OKD web console, the user is prompted to create the resource using the template provided in the CSV.

Procedure

• Add the operatorframework.io/initialization-resource annotation to the CSV of your Operator to specify a required custom resource. For example, the following annotation requires the creation of a StorageCluster resource and provides a full YAML definition:

  Initialization resource annotation

  apiVersion: operators.coreos.com/v1alpha1
  kind: ClusterServiceVersion
  metadata:
    name: my-operator-v1.2.3
    annotations:
      operatorframework.io/initialization-resource: |-
          {
              "apiVersion": "ocs.openshift.io/v1",
              "kind": "StorageCluster",
              "metadata": {
                  "name": "example-storagecluster"
              },
              "spec": {
                  "manageNodes": false,
                  "monPVCTemplate": {
                      "spec": {
                          "accessModes": [
                              "ReadWriteOnce"
                          ],
                          "resources": {
                              "requests": {
                                  "storage": "10Gi"
                              }
                          },
                          "storageClassName": "gp2"
                      }
                  },
                  "storageDeviceSets": [
                      {
                          "count": 3,
                          "dataPVCTemplate": {
                              "spec": {
                                  "accessModes": [
                                      "ReadWriteOnce"
                                  ],
                                  "resources": {
                                      "requests": {
                                          "storage": "1Ti"
                                      }
                                  },
                                  "storageClassName": "gp2",
                                  "volumeMode": "Block"
                              }
                          },
                          "name": "example-deviceset",
                          "placement": {},
                          "portable": true,
                          "resources": {}
                      }
                  ]
              }
          }
  ...

Understanding your API services

As with CRDs, there are two types of API services that your Operator may use: owned and required.

Owned API services

When a CSV owns an API service, it is responsible for describing the deployment of the extension api-server that backs it and the group/version/kind (GVK) it provides.

An API service is uniquely identified by the group/version it provides and can be listed multiple times to denote the different kinds it is expected to provide.

API service resource creation

Operator Lifecycle Manager (OLM) is responsible for creating or replacing the service and API service resources for each unique owned API service:

• Service pod selectors are copied from the CSV deployment matching the DeploymentName field of the API service description.

• A new CA key/certificate pair is generated for each installation and the base64-encoded CA bundle is embedded in the respective API service resource.

API service serving certificates

OLM handles generating a serving key/certificate pair whenever an owned API service is being installed. The serving certificate has a common name (CN) containing the hostname of the generated Service resource and is signed by the private key of the CA bundle embedded in the corresponding API service resource.

The certificate is stored as a type kubernetes.io/tls secret in the deployment namespace, and a volume named apiservice-cert is automatically appended to the volumes section of the deployment in the CSV matching the DeploymentName field of the API service description.

If one does not already exist, a volume mount with a matching name is also appended to all containers of that deployment. This allows users to define a volume mount with the expected name to accommodate any custom path requirements. The path of the generated volume mount defaults to /apiserver.local.config/certificates and any existing volume mounts with the same path are replaced.

Required API services

OLM ensures all required CSVs have an API service that is available and all expected GVKs are discoverable before attempting installation. This allows a CSV to rely on specific kinds provided by API services it does not own.