Operator SDK – Command Line Interface

Docs: operator-sdk

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

operator-sdk

Synopsis

CLI tool for building Kubernetes extensions and tools.

operator-sdk [flags]

Examples

The first step is to initialize your project:
    operator-sdk init [--plugins=<PLUGIN KEYS> [--project-version=<PROJECT VERSION>]]

<PLUGIN KEYS> is a comma-separated list of plugin keys from the following table
and <PROJECT VERSION> a supported project version for these plugins.

                             Plugin keys | Supported project versions
-----------------------------------------+----------------------------
     ansible.sdk.operatorframework.io/v1 |                          3
 deploy-image.go.kubebuilder.io/v1-alpha |                          3
                    go.kubebuilder.io/v4 |                          3
         grafana.kubebuilder.io/v1-alpha |                          3
        helm.sdk.operatorframework.io/v1 |                          3

For more specific help for the init command of a certain plugins and project version
configuration please run:
    operator-sdk init --help --plugins=<PLUGIN KEYS> [--project-version=<PROJECT VERSION>]

Default plugin keys: "go.kubebuilder.io/v4"
Default project version: "3"

Options

  -h, --help                     help for operator-sdk
      --plugins strings          plugin keys to be used for this subcommand execution
      --project-version string   project version (default "3")
      --verbose                  Enable verbose logging

Docs: operator-sdk alpha

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

operator-sdk alpha

Alpha-stage subcommands

Synopsis

Alpha subcommands are for unstable features.

Alpha subcommands are exploratory and may be removed without warning.
No backwards compatibility is provided for any alpha subcommands.

Options

  -h, --help   help for alpha

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk alpha config-3alpha-to-3

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

operator-sdk alpha config-3alpha-to-3

Convert your PROJECT config file from version 3-alpha to 3

Synopsis

Your PROJECT file contains config data specified by some version. This version is not a kubernetes-style version. In general, alpha and beta config versions are unstable and support for them is dropped once a stable version is released. The 3-alpha version has recently become stable (3), and therefore is no longer supported by operator-sdk v1.5+. This command is intended to migrate 3-alpha PROJECT files to 3 with as few manual modifications required as possible.

operator-sdk alpha config-3alpha-to-3 [flags]

Options

  -h, --help   help for config-3alpha-to-3

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk alpha generate

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

operator-sdk alpha generate

Re-scaffold an existing Kuberbuilder project

Synopsis

It’s an experimental feature that has the purpose of re-scaffolding the whole project from the scratch using the current version of KubeBuilder binary available.

make sure the PROJECT file is in the ‘input-dir’ argument, the default is the current directory.

$ kubebuilder alpha generate –input-dir=”./test” –output-dir=”./my-output” Then we will re-scaffold the project by Kubebuilder in the directory specified by ‘output-dir’.

operator-sdk alpha generate [flags]

Options

  -h, --help                help for generate
      --input-dir string    Specifies the full path to a Kubebuilder project file. If not provided, the current working directory is used.
      --output-dir string   Specifies the full path where the scaffolded files will be output. Defaults to a directory within the current working directory.

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk bundle

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

operator-sdk bundle

Manage operator bundle metadata

Synopsis

Manage bundle builds, bundle metadata generation, and bundle validation. An operator bundle is a portable operator packaging format understood by Kubernetes native software, like the Operator Lifecycle Manager.

More information about operator bundles and metadata: https://github.com/operator-framework/operator-registry/blob/master/docs/design/operator-bundle.md

More information about the integration with OLM via SDK: https://sdk.operatorframework.io/docs/olm-integration

Options

  -h, --help   help for bundle

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk bundle validate

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

operator-sdk bundle validate

Validate an operator bundle

Synopsis

The ‘operator-sdk bundle validate’ command can validate both content and format of an operator bundle image or an operator bundle directory on-disk containing operator metadata and manifests. This command will exit with an exit code of 1 if any validation errors arise, and 0 if only warnings arise or all validators pass.

A valid bundle is defined by the bundle spec (linked below), therefore the default validator ensures a bundle conforms to that spec. If you want to ensure that your bundle is valid for an optional superset of requirements such as to those required to publish your operator on operatorhub.io, then you will need to run one or more supported optional validators. Set ‘–list-optional’ to list which optional validators are supported, and how they are grouped by label.

More information about operator bundles and metadata: https://github.com/operator-framework/operator-registry/blob/master/docs/design/operator-bundle.md

NOTE: if validating an image, the image must exist in a remote registry, not just locally.

operator-sdk bundle validate [flags]

Examples

This example assumes you either have a *pullable* bundle image,
or something similar to the following operator bundle layout present locally:

  $ tree ./bundle
  ./bundle
  ├── manifests
  │   ├── cache.my.domain_memcacheds.yaml
  │   └── memcached-operator.clusterserviceversion.yaml
  └── metadata
      └── annotations.yaml

To validate a local bundle:

  $ operator-sdk bundle validate ./bundle

To build and validate a *pullable* bundle image:

  $ operator-sdk bundle validate <some-registry>/<operator-bundle-name>:<tag>

To list and run optional validators, which are specified by a label selector:

  $ operator-sdk bundle validate --list-optional
  NAME           LABELS                     DESCRIPTION
  operatorhub    name=operatorhub           OperatorHub.io metadata validation.
                 suite=operatorframework

To validate a bundle against the entire suite of validators for Operator Framework, in addition to required bundle validators:

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

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

To validate a bundle against the validator for operatorhub.io specifically, in addition to required bundle validators:

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

This validator allows check the bundle against an specific Kubernetes cluster version using the k8s-version optional key value:

  $ operator-sdk bundle validate ./bundle --select-optional name=operatorhub --optional-values=k8s-version=1.22

[Deprecated] To validate a bundle against the (alpha) validator for Community Operators specifically, in addition to required bundle validators:

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

To validate a bundle against the validator for Good Practices specifically, in addition to required bundle validators:

  $ operator-sdk bundle validate ./bundle --select-optional name=good-practices

To validate a bundle against the (alpha) validator for Deprecated APIs specifically, in addition to required bundle validators:

  $ operator-sdk bundle validate ./bundle --select-optional name=alpha-deprecated-apis --optional-values=k8s-version=1.22

To validate a bundle against an external validator, in addition to required bundle validators:

  $ operator-sdk bundle validate ./bundle --alpha-select-external /path/to/external-validator[:/path/to/optional-second-validator]

To validate a bundle against the (alpha) validator for Multiple Architectures bundle validation, in addition to required bundle validators:

IMPORTANT: To use this option it is required to have access to pull the images defined on the CSV.

  $ operator-sdk bundle validate ./bundle --select-optional name=multiarch 

NOTE: The --optional-values can be used to inform the container-tools that should be used i.e. "--optional-values=container-tools=docker".
The valid values for the container-tools optional value are [docker, podman, none]. If no value is supplied then the command will default to using docker to inspect the images.
More info: https://github.com/operator-framework/api/blob/master/pkg/validation/internal/multiarch.go

Options

      --alpha-select-external string                         Selector to select external validators to run. It should be set to a Unix path list ("/path/to/e1.sh:/path/to/e2")
  -h, --help                                                 help for validate
  -b, --image-builder string                                 Tool to pull and unpack bundle images. Only used when validating a bundle image. One of: [docker, podman, none] (default "docker")
      --list-optional                                        List all optional validators available. When set, no validators will be run
      --optional-values --optional-values=k8s-version=1.22   Inform a []string map of key=values which can be used by the validator. e.g. to check the operator bundle against an Kubernetes version that it is intended to be distributed use --optional-values=k8s-version=1.22 (default [])
  -o, --output string                                        Result format for results. One of: [text, json-alpha1]. Note: output format types containing "alphaX" are subject to change and not covered by guarantees of stable APIs. (default "text")
      --select-optional string                               Label selector to select optional validators to run. Run this command with '--list-optional' to list available optional validators

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk cleanup

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

operator-sdk cleanup

Clean up an Operator deployed with the ‘run’ subcommand

Synopsis

This command has subcommands that will destroy an Operator deployed with OLM.

operator-sdk cleanup <operatorPackageName> [flags]

Options

      --delete-all               If set to true, all other delete options will be enabled (default true)
      --delete-crds              If set to true, owned CRDs and CRs will be deleted
      --delete-operator-groups   If set to true, operator groups will be deleted
  -h, --help                     help for cleanup
      --kubeconfig string        Path to the kubeconfig file to use for CLI requests.
  -n, --namespace string         If present, namespace scope for this CLI request
      --timeout duration         Duration to wait for the command to complete before failing (default 2m0s)

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk completion

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

operator-sdk completion

Load completions for the specified shell

Synopsis

Output shell completion code for the specified shell. The shell code must be evaluated to provide interactive completion of operator-sdk commands. Detailed instructions on how to do this for each shell are provided in their own commands.

Options

  -h, --help   help for completion

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk completion bash

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

operator-sdk completion bash

Load bash completions

operator-sdk completion bash [flags]

Examples

# To load completion for this session, execute:
$ source <(operator-sdk completion bash)

# To load completions for each session, execute once:
Linux:
  $ operator-sdk completion bash > /etc/bash_completion.d/operator-sdk
MacOS:
  $ operator-sdk completion bash > /usr/local/etc/bash_completion.d/operator-sdk

Options

  -h, --help   help for bash

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk completion fish

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

operator-sdk completion fish

Load fish completions

operator-sdk completion fish [flags]

Examples

# To load completion for this session, execute:
$ operator-sdk completion fish | source

# To load completions for each session, execute once:
$ operator-sdk completion fish > ~/.config/fish/completions/operator-sdk.fish

Options

  -h, --help   help for fish

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk completion powershell

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

operator-sdk completion powershell

Load powershell completions

operator-sdk completion powershell [flags]

Options

  -h, --help   help for powershell

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk completion zsh

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

operator-sdk completion zsh

Load zsh completions

operator-sdk completion zsh [flags]

Examples

# If shell completion is not already enabled in your environment you will need
# to enable it. You can execute the following once:
$ echo "autoload -U compinit; compinit" >> ~/.zshrc

# To load completions for each session, execute once:
$ operator-sdk completion zsh > "${fpath[1]}/_operator-sdk"

# You will need to start a new shell for this setup to take effect.

Options

  -h, --help   help for zsh

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk create

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

operator-sdk create

Scaffold a Kubernetes API or webhook

Synopsis

Scaffold a Kubernetes API or webhook.

Options

  -h, --help   help for create

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk create api

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

operator-sdk create api

Scaffold a Kubernetes API

Synopsis

Scaffold a Kubernetes API by writing a Resource definition and/or a Controller.

If information about whether the resource and controller should be scaffolded was not explicitly provided, it will prompt the user if they should be.

After the scaffold is written, the dependencies will be updated and make generate will be run.

operator-sdk create api [flags]

Examples

  # Create a frigates API with Group: ship, Version: v1beta1 and Kind: Frigate
  operator-sdk create api --group ship --version v1beta1 --kind Frigate

  # Edit the API Scheme

  nano api/v1beta1/frigate_types.go

  # Edit the Controller
  nano internal/controller/frigate/frigate_controller.go

  # Edit the Controller Test
  nano internal/controller/frigate/frigate_controller_test.go

  # Generate the manifests
  make manifests

  # Install CRDs into the Kubernetes cluster using kubectl apply
  make install

  # Regenerate code and run against the Kubernetes cluster configured by ~/.kube/config
  make run

Options

      --controller                   if set, generate the controller without prompting the user (default true)
      --external-api-domain string   Specify the domain name for the external API. This domain is used to generate accurate RBAC markers and permissions for the external resources (e.g., cert-manager.io).
      --external-api-path string     Specify the Go package import path for the external API. This is used to scaffold controllers for resources defined outside this project (e.g., github.com/cert-manager/cert-manager/pkg/apis/certmanager/v1).
      --force                        attempt to create resource even if it already exists
      --group string                 resource Group
  -h, --help                         help for api
      --kind string                  resource Kind
      --make make generate           if true, run make generate after generating files (default true)
      --namespaced                   resource is namespaced (default true)
      --plural string                resource irregular plural form
      --resource                     if set, generate the resource without prompting the user (default true)
      --version string               resource Version

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk create webhook

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

operator-sdk create webhook

Scaffold a webhook for an API resource

Synopsis

Scaffold a webhook for an API resource. You can choose to scaffold defaulting, validating and/or conversion webhooks.

operator-sdk create webhook [flags]

Examples

  # Create defaulting and validating webhooks for Group: ship, Version: v1beta1
  # and Kind: Frigate
  operator-sdk create webhook --group ship --version v1beta1 --kind Frigate --defaulting --programmatic-validation

  # Create conversion webhook for Group: ship, Version: v1beta1
  # and Kind: Frigate
  operator-sdk create webhook --group ship --version v1beta1 --kind Frigate --conversion --spoke v1

Options

      --conversion                   if set, scaffold the conversion webhook
      --defaulting                   if set, scaffold the defaulting webhook
      --external-api-domain string   Specify the domain name for the external API. This domain is used to generate accurate RBAC markers and permissions for the external resources (e.g., cert-manager.io).
      --external-api-path string     Specify the Go package import path for the external API. This is used to scaffold controllers for resources defined outside this project (e.g., github.com/cert-manager/cert-manager/pkg/apis/certmanager/v1).
      --force                        attempt to create resource even if it already exists
      --group string                 resource Group
  -h, --help                         help for webhook
      --kind string                  resource Kind
      --legacy                       [DEPRECATED] Attempts to create resource under the API directory (legacy path). This option will be removed in future versions.
      --make make generate           if true, run make generate after generating files (default true)
      --plural string                resource irregular plural form
      --programmatic-validation      if set, scaffold the validating webhook
      --spoke strings                Comma-separated list of spoke versions to be added to the conversion webhook (e.g., --spoke v1,v2)
      --version string               resource Version

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk edit

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

operator-sdk edit

Update the project configuration

Synopsis

This command will edit the project configuration. Features supported:

Toggle between single or multi group projects.

operator-sdk edit [flags]

Examples

  # Enable the multigroup layout
  operator-sdk edit --multigroup

  # Disable the multigroup layout
  operator-sdk edit --multigroup=false

Options

  -h, --help         help for edit
      --multigroup   enable or disable multigroup layout

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk generate

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

operator-sdk generate

Invokes a specific generator

Synopsis

The ‘operator-sdk generate’ command invokes a specific generator to generate code or manifests.

Options

  -h, --help   help for generate

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk generate bundle

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

operator-sdk generate bundle

Generates bundle data for the operator

Synopsis

Running ‘generate bundle’ is the first step to publishing your operator to a catalog and deploying it with OLM. This command both generates and packages files into an on-disk representation of an operator called a bundle. A bundle consists of a ClusterServiceVersion (CSV), CustomResourceDefinitions (CRDs), manifests not part of the CSV but required by the operator, some metadata (annotations.yaml), and a bundle.Dockerfile to build a bundle image.

A CSV manifest is generated by collecting data from the set of manifests passed to this command (see below), such as CRDs, RBAC, etc., and applying that data to a “base” CSV manifest. This base CSV can contain metadata, added by hand or by the ‘generate kustomize manifests’ command, and can be passed in like any other manifest (see below) or by file at the exact path ‘<kustomize-dir>/bases/<package-name>.clusterserviceversion.yaml’. Be aware that ‘generate bundle’ idempotently regenerates a bundle, so all non-metadata values in a base will be overwritten. If no base was passed in, input manifest data will be applied to an empty CSV.

There are two ways to pass the to-be-bundled set of manifests to this command: stdin via a Unix pipe, or in a directory using ‘–input-dir’. See command help for more information on these modes. Passing a directory is useful for running ‘generate bundle’ outside of a project or within a project that does not use kustomize and/or contains cluster-ready manifests on disk.

Set ‘–version’ to supply a semantic version for your bundle if you are creating one for the first time or upgrading an existing one.

If ‘–output-dir’ is set and you wish to build bundle images from that directory, either manually update your bundle.Dockerfile or set ‘–overwrite’.

More information on bundles: https://github.com/operator-framework/operator-registry/#manifest-format

operator-sdk generate bundle [flags]

Examples


  # If running within a project or in a project that uses kustomize to generate manifests,
	# make sure a kustomize directory exists that looks like the following 'config/manifests' directory:
  $ tree config/manifests
  config/manifests
  ├── bases
  │   └── memcached-operator.clusterserviceversion.yaml
  └── kustomization.yaml

  # Generate a 0.0.1 bundle by passing manifests to stdin:
  $ kustomize build config/manifests | operator-sdk generate bundle --version 0.0.1
  Generating bundle version 0.0.1
  ...

  # If running outside of a project or in a project that does not use kustomize to generate manifests,
	# make sure cluster-ready manifests are available on disk:
  $ tree deploy/
  deploy/
  ├── crds
  │   └── cache.my.domain_memcacheds.yaml
  ├── deployment.yaml
  ├── role.yaml
  ├── role_binding.yaml
  ├── service_account.yaml
  └── webhooks.yaml

  # Generate a 0.0.1 bundle by passing manifests by dir:
  $ operator-sdk generate bundle --input-dir deploy --version 0.0.1
  Generating bundle version 0.0.1
  ...

  # After running in either of the above modes, you should see this directory structure:
  $ tree bundle/
  bundle/
  ├── manifests
  │   ├── cache.my.domain_memcacheds.yaml
  │   └── memcached-operator.clusterserviceversion.yaml
  └── metadata
      └── annotations.yaml

Options

      --channels string                  A comma-separated list of channels the bundle belongs to (default "alpha")
      --crds-dir string                  Directory to read cluster-ready CustomResoureDefinition manifests from. This option can only be used if --deploy-dir is set
      --default-channel string           The default channel for the bundle
      --deploy-dir string                Directory to read cluster-ready operator manifests from. If --crds-dir is not set, CRDs are ready from this directory. This option is mutually exclusive with --input-dir and piping to stdin
      --extra-service-accounts strings   Names of service accounts, outside of the operator's Deployment account, that have bindings to {Cluster}Roles that should be added to the CSV
  -h, --help                             help for bundle
      --input-dir string                 Directory to read cluster-ready operator manifests from. This option is mutually exclusive with --deploy-dir/--crds-dir and piping to stdin. This option should not be passed an existing bundle directory, as this bundle will not contain the correct set of manifests required to generate a CSV. Use --kustomize-dir to pass a base CSV
      --kustomize-dir string             Directory containing kustomize bases in a "bases" dir and a kustomization.yaml for operator-framework manifests (default "config/manifests")
      --manifests                        Generate bundle manifests
      --metadata                         Generate bundle metadata and Dockerfile
      --output-dir string                Directory to write the bundle to
      --overwrite                        Overwrite the bundle's metadata and Dockerfile if they exist (default true)
      --overwrite-annotations            Only overwrite annotations.yaml without modifying bundle.Dockerfile
      --package string                   Bundle's package name
  -q, --quiet                            Run in quiet mode
      --stdout                           Write bundle manifest to stdout
      --use-image-digests                Use SHA Digest for images
  -v, --version string                   Semantic version of the operator in the generated bundle. Only set if creating a new bundle or upgrading your operator

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk generate kustomize

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

operator-sdk generate kustomize

Contains subcommands that generate operator-framework kustomize data for the operator

Options

  -h, --help   help for kustomize

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk generate kustomize manifests

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

operator-sdk generate kustomize manifests

Generates kustomize bases and a kustomization.yaml for operator-framework manifests

Synopsis

Running ‘generate kustomize manifests’ will (re)generate kustomize bases and a kustomization.yaml in ‘config/manifests’, which are used to build operator-framework manifests by other operator-sdk commands. This command will interactively ask for UI metadata, an important component of manifest bases, by default unless a base already exists or you set ‘–interactive=false’.

operator-sdk generate kustomize manifests [flags]

Examples


  $ operator-sdk generate kustomize manifests

  Display name for the operator (required):
  > memcached-operator
  ...

  $ tree config/manifests
  config/manifests
  ├── bases
  │   └── memcached-operator.clusterserviceversion.yaml
  └── kustomization.yaml

  # After generating kustomize bases and a kustomization.yaml, you can generate a bundle or package manifests.

  # To generate a bundle:
  $ kustomize build config/manifests | operator-sdk generate bundle --version 0.0.1

  # To generate package manifests:
  $ kustomize build config/manifests | operator-sdk generate packagemanifests --version 0.0.1

Options

      --apis-dir string     Root directory for API type defintions
  -h, --help                help for manifests
      --input-dir string    Directory containing existing kustomize files
      --interactive         When set to false, if no kustomize base exists, an interactive command prompt will be presented to accept non-inferrable metadata
      --output-dir string   Directory to write kustomize files
      --package string      Package name
  -q, --quiet               Run in quiet mode

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk init

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

operator-sdk init

Initialize a new project

Synopsis

Initialize a new project including the following files:

a “go.mod” with project dependencies
a “PROJECT” file that stores project configuration
a “Makefile” with several useful make targets for the project
several YAML files for project deployment under the “config” directory
a “cmd/main.go” file that creates the manager that will run the project controllers

operator-sdk init [flags]

Examples

  # Initialize a new project with your domain and name in copyright
  operator-sdk init --plugins go/v4 --domain example.org --owner "Your name"

  # Initialize a new project defining a specific project version
  operator-sdk init --plugins go/v4 --project-version 3

Options

      --domain string            domain for groups (default "my.domain")
      --fetch-deps               ensure dependencies are downloaded (default true)
  -h, --help                     help for init
      --license string           license to use to boilerplate, may be one of 'apache2', 'none' (default "apache2")
      --owner string             owner to add to the copyright
      --project-name string      name of this project
      --project-version string   project version (default "3")
      --repo string              name to use for go module (e.g., github.com/user/repo), defaults to the go package of the current working directory.
      --skip-go-version-check    if specified, skip checking the Go version

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk olm

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

operator-sdk olm

Manage the Operator Lifecycle Manager installation in your cluster

Options

  -h, --help   help for olm

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk olm install

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

operator-sdk olm install

Install Operator Lifecycle Manager in your cluster

operator-sdk olm install [flags]

Options

  -h, --help               help for install
      --timeout duration   time to wait for the command to complete before failing (default 2m0s)
      --version string     version of OLM resources to install (default "0.28.0")

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk olm status

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

operator-sdk olm status

Get the status of the Operator Lifecycle Manager installation in your cluster

operator-sdk olm status [flags]

Options

  -h, --help                   help for status
      --olm-namespace string   namespace where OLM is installed (default "olm")
      --timeout duration       time to wait for the command to complete before failing (default 2m0s)
      --version string         version of OLM installed on cluster; if unsetoperator-sdk attempts to auto-discover the version

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk olm uninstall

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

operator-sdk olm uninstall

Uninstall Operator Lifecycle Manager from your cluster

operator-sdk olm uninstall [flags]

Options

  -h, --help                   help for uninstall
      --olm-namespace string   namespace from where OLM is to be uninstalled. (default "olm")
      --timeout duration       time to wait for the command to complete before failing (default 2m0s)
      --version string         version of OLM resources to uninstall.

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk pkgman-to-bundle

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

operator-sdk pkgman-to-bundle

Migrates packagemanifests to bundles

Synopsis

‘pkgman-to-bundle’ command helps in migrating OLM packagemanifests to bundles which is the preferred OLM packaging format. This command takes an input packagemanifest directory and generates bundles for each of the versions of manifests present in the input directory. Additionally, it also provides the flexibility to build bundle images for each of the generated bundles.

The generated bundles are always written on disk. Location for the generated bundles can be specified using ‘–output-dir’. If not specified, the default location would be ‘bundle/’ directory.

The base container image name for the bundles can be provided using ‘–image-tag-base’ flag. This should be provided without the tag, since the tag for the images would be the bundle version, (ie) image names will be in the format <base_image>:<bundle_version>.

Specify the build command for building container images using ‘–build-cmd’ flag. The default build command is ‘docker build’. The command will need to be in the ‘PATH’ or fully qualified path name should be provided.

operator-sdk pkgman-to-bundle <packagemanifestdir> [flags]

Examples



# Provide the packagemanifests directory as input to the command. Consider the packagemanifests directory to have the following
# structure:

$ tree packagemanifests/
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

# Run the following command to generate bundles in the default 'bundle/' directory with the base-container image name
# to be 'quay.io/example/etcd'
$ operator-sdk pkgman-to-bundle packagemanifests --image-tag-base quay.io/example/etcd
INFO[0000] Packagemanifests will be migrated to bundles in bundle directory
INFO[0000] Creating bundle/bundle-0.0.1/bundle.Dockerfile
INFO[0000] Creating bundle/bundle-0.0.1/metadata/annotations.yaml
...

# After running the above command, the bundles will be generated in 'bundles/' directory.
$ tree bundles/
bundles/
├── 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

A custom command to build bundle images can also be specified using the '--build-cmd' flag. For example,

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

Images for the both the bundles will be built with the following names: quay.io/example/etcd:0.0.1 and quay.io/example/etcd:0.0.2.

Options

      --build-cmd string        Build command to be run for building images. By default 'docker build' is run.
  -h, --help                    help for pkgman-to-bundle
      --image-tag-base string   Base container image name for bundle image tags, ex. my.reg/foo/bar-operator-bundle will become my.reg/foo/bar-operator-bundle:${package-dir-name} for each child directory name in the packagemanifests directory
      --output-dir string       Directory to write bundle to. (default "bundles")

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk run

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

operator-sdk run

Run an Operator in a variety of environments

Synopsis

This command has subcommands that will deploy your Operator with OLM.

Options

  -h, --help   help for run

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk run bundle

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

operator-sdk run bundle

Deploy an Operator in the bundle format with OLM

Synopsis

The single argument to this command is a bundle image, with the full registry path specified. If using a docker.io image, you must specify docker.io(/<namespace>)?/<bundle-image-name>:<tag>. If the bundle image provided is a SQLite index, it must be pullable by the cluster as SQLite images are pulled from the cluster. If the bundle image provided is a File-Based Catalog (FBC) index, it will be pulled on the local machine.

The main purpose of this command is to streamline running the bundle without having to provide an index image with the bundle already included.

The --index-image flag specifies an index image in which to inject the given bundle. It can be specified to resolve dependencies for a bundle. This is an optional flag which will default to quay.io/operator-framework/opm:latest. The index image provided should NOT already have the bundle. A limitation of the index image flag is that it does not check the upgrade graph as the annotations for channels are ignored but it is still a useful flag to have to validate the dependencies. For example: It does not fail fast when the bundle version provided is <= ChannelHead.

operator-sdk run bundle <bundle-image> [flags]

Options

      --ca-secret-name string                     Name of a generic secret containing a PEM root certificate file required to pull bundle images. This secret *must* be in the namespace that this command is configured to run in, and the file *must* be encoded under the key "cert.pem"
      --decompression-image string                image used in an init container in the registry pod to decompress the compressed catalog contents. cat and gzip binaries are expected to exist in the PATH (default "registry.access.redhat.com/ubi9/ubi:9.7")
  -h, --help                                      help for bundle
      --image-pull-policy string                  image pull policy for the registry pod (default "Always")
      --index-image string                        index image in which to inject bundle (default "quay.io/operator-framework/opm:latest")
      --install-mode InstallModeValue             install mode
      --kubeconfig string                         Path to the kubeconfig file to use for CLI requests.
  -n, --namespace string                          If present, namespace scope for this CLI request
      --pull-secret-name string                   Name of image pull secret ("type: kubernetes.io/dockerconfigjson") required to pull bundle images. This secret *must* be both in the namespace and an imagePullSecret of the service account that this command is configured to run in
      --security-context-config SecurityContext   specifies the security context to use for the catalog pod. allowed: 'restricted', 'legacy'. (default legacy)
      --service-account string                    Service account name to bind registry objects to. If unset, the default service account is used. This value does not override the operator's service account
      --skip-tls                                  skip authentication of image registry TLS certificate when pulling a bundle image in-cluster
      --skip-tls-verify                           skip TLS certificate verification for container image registries while pulling bundles
      --timeout duration                          Duration to wait for the command to complete before failing (default 2m0s)
      --use-http                                  use plain HTTP for container image registries while pulling bundles

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk run bundle-upgrade

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

operator-sdk run bundle-upgrade

Upgrade an Operator previously installed in the bundle format with OLM

Synopsis

operator-sdk run bundle-upgrade <bundle-image> [flags]

Options

      --ca-secret-name string                     Name of a generic secret containing a PEM root certificate file required to pull bundle images. This secret *must* be in the namespace that this command is configured to run in, and the file *must* be encoded under the key "cert.pem"
  -h, --help                                      help for bundle-upgrade
      --image-pull-policy string                  image pull policy for the registry pod (default "Always")
      --kubeconfig string                         Path to the kubeconfig file to use for CLI requests.
  -n, --namespace string                          If present, namespace scope for this CLI request
      --pull-secret-name string                   Name of image pull secret ("type: kubernetes.io/dockerconfigjson") required to pull bundle images. This secret *must* be both in the namespace and an imagePullSecret of the service account that this command is configured to run in
      --security-context-config SecurityContext   specifies the security context to use for the catalog pod. allowed: 'restricted', 'legacy'. (default legacy)
      --service-account string                    Service account name to bind registry objects to. If unset, the default service account is used. This value does not override the operator's service account
      --skip-tls                                  skip authentication of image registry TLS certificate when pulling a bundle image in-cluster
      --skip-tls-verify                           skip TLS certificate verification for container image registries while pulling bundles
      --timeout duration                          Duration to wait for the command to complete before failing (default 2m0s)
      --use-http                                  use plain HTTP for container image registries while pulling bundles

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk scorecard

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

operator-sdk scorecard

Runs scorecard

Synopsis

Has flags to configure dsl, bundle, and selector. This command takes one argument, either a bundle image or directory containing manifests and metadata. If the argument holds an image tag, it must be present remotely.

operator-sdk scorecard [flags]

Options

  -c, --config string            path to scorecard config file
  -h, --help                     help for scorecard
      --kubeconfig string        kubeconfig path
  -L, --list                     Option to enable listing which tests are run
  -n, --namespace string         namespace to run the test images in
  -o, --output string            Output format for results. Valid values: text, json, xunit (default "text")
      --pod-security string      option to run scorecard with legacy pod security context (default "legacy")
  -l, --selector string          label selector to determine which tests are run
  -s, --service-account string   Service account to use for tests (default "default")
  -x, --skip-cleanup             Disable resource cleanup after tests are run
  -b, --storage-image string     Storage image to be used by the Scorecard pod (default "quay.io/operator-framework/scorecard-storage@sha256:a3bfda71281393c7794cabdd39c563fb050d3020fd0b642ea164646bdd39a0e2")
  -t, --test-output string       Test output directory. (default "test-output")
  -u, --untar-image string       Untar image to be used by the Scorecard pod (default "quay.io/operator-framework/scorecard-untar@sha256:2e728c5e67a7f4dec0df157a322dd5671212e8ae60f69137463bd4fdfbff8747")
  -w, --wait-time duration       seconds to wait for tests to complete. Example: 35s (default 30s)

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Docs: operator-sdk version

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

operator-sdk version

Print the operator-sdk version

Synopsis

Print the operator-sdk version

operator-sdk version [flags]

Examples

operator-sdk version

Options

  -h, --help   help for version

Options inherited from parent commands

      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

Operator SDK – Command Line Interface

Docs: operator-sdk

operator-sdk

Synopsis

Examples

Options

SEE ALSO

Docs: operator-sdk alpha

operator-sdk alpha

Synopsis

Options

Options inherited from parent commands

SEE ALSO

Docs: operator-sdk alpha config-3alpha-to-3

operator-sdk alpha config-3alpha-to-3

Synopsis

Options

Options inherited from parent commands

SEE ALSO

Docs: operator-sdk alpha generate

operator-sdk alpha generate

Synopsis

make sure the PROJECT file is in the ‘input-dir’ argument, the default is the current directory.

Options

Options inherited from parent commands

SEE ALSO

Docs: operator-sdk bundle

operator-sdk bundle

Synopsis

Options

Options inherited from parent commands

SEE ALSO

Docs: operator-sdk bundle validate

operator-sdk bundle validate

Synopsis

Examples

Options

Options inherited from parent commands

SEE ALSO

Docs: operator-sdk cleanup

operator-sdk cleanup

Synopsis

Options

Options inherited from parent commands

SEE ALSO

Docs: operator-sdk completion

operator-sdk completion

Synopsis

Options

Options inherited from parent commands

SEE ALSO

Docs: operator-sdk completion bash

operator-sdk completion bash

Examples

Options

Options inherited from parent commands

SEE ALSO

Docs: operator-sdk completion fish

operator-sdk completion fish

Examples

Options

Options inherited from parent commands

SEE ALSO

Docs: operator-sdk completion powershell

operator-sdk completion powershell

Options

Options inherited from parent commands

SEE ALSO

Docs: operator-sdk completion zsh

operator-sdk completion zsh

Examples

Options

Options inherited from parent commands

SEE ALSO

Docs: operator-sdk create

operator-sdk create

Synopsis

Options

Options inherited from parent commands

SEE ALSO