Soon, all Red Hat OpenShift documentation will only be available on docs.redhat.com, the official location of all Red Hat product documentation. Get familiar with the updated experience today!
  1. Documentation
    2. history
×

Operator SDK CLI reference

This guide documents the Operator SDK CLI commands and their syntax:

$ operator-sdk <command> [<subcommand>] [<argument>] [<flags>]

alpha

The operator-sdk alpha command is used to run an alpha subcommand.

scorecard

The alpha scorecard subcommand runs the scorecard tool to validate an Operator bundle and provide suggestions for improvements. The command takes one argument, either a bundle image or directory containing manifests and metadata. If the argument holds an image tag, the image must be present remotely.

Table 1. scorecard flags
Flag Description

-c, --config (string)

Path to scorecard configuration file.

-h, --help

Help output for the scorecard command.

--kubeconfig (string)

Path to kubeconfig file.

-L, --list

List which tests are available to run.

-n, --namespace (string)

Namespace in which to run the test images. Default: default.

-o, --output (string)

Output format for results. Available values are text, and json. Default: text.

-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.

-w, --wait-time <duration>

Seconds to wait for tests to complete, for example 35s. Default: 30s.

build

The operator-sdk build command compiles the code and builds the executables. After build completes, the image is built using a local container engine. It must then be pushed to a remote registry.

Table 2. build arguments
Argument Description

<image>

The container image to be built, for example quay.io/example/operator:v0.0.1.
Table 3. build flags
Flag Description

--go-build-args (string)

Extra Go build arguments.

--image-build-args (string)

Extra image build arguments as one string.

--image-builder (string)

Tool to build OCI images. Available options are: docker, podman, or buildah. Default: docker.

-h, --help

Usage help output.

bundle

The operator-sdk bundle command manages Operator bundle metadata.

validate

The bundle validate subcommand validates an Operator bundle.

Table 4. bundle validate flags
Flag Description

-h, --help

Help output for the bundle validate subcommand.

-b, --image-builder (string)

Tool to pull and unpack bundle images. Only used when validating a bundle image. Available options are docker, podman, or none. Default: docker.

cleanup

The operator-sdk cleanup command destroys and removes resources that were created for an Operator that was deployed with the run command.

packagemanifests

cleanup packagemanifests subcommand destroys an Operator that was deployed with OLM by using the run packagemanifests command.

Table 5. packagemanifests arguments
Arguments Description

--include (string)

The file path to Kubernetes resource manifests, such as role and subscription objects. These supplement or override the defaults generated by run or cleanup.

--install-mode (string)

The OperatorGroup is created with the specified InstallMode. Format: InstallModeType[=ns1,ns2[, …​]]`

--kubeconfig (string)

The file path to a Kubernetes configuration file. Default: The location specified by $KUBECONFIG, or to default file rules if not set.

--olm-namespace (string)

The namespace where the OLM is installed. Default: olm.

--operator-namespace (string)

The namespace where the Operator resources are created. The namespace must already exist in the cluster, or be defined in a manifest that is passed to --include.

--operator-version

The version of the Operator to be deployed.

--timeout <duration>

The time to wait for the command to complete before it fails. Default: 2m0s.

-h, --help

Usage help output.

completion

The operator-sdk completion command generates shell completions to make issuing CLI commands quicker and easier.

Table 6. completion subcommands
Subcommand Description

bash

Generate bash completions.

zsh

Generate zsh completions.
Table 7. completion flags
Flag Description

-h, --help

Usage help output.

For example:

$ operator-sdk completion bash
Example output
# bash completion for operator-sdk                         -*- shell-script -*-
...
# ex: ts=4 sw=4 et filetype=sh

create

The operator-sdk create command is used to create, or scaffold, a Kubernetes API.

api

The create api subcommand scaffolds a Kubernetes API. The subcommand must be run in a project that was initialized with the init command.

Table 8. create api flags
Flag Description

-h, --help

Help output for the run bundle subcommand.

webhook

The create webhook subcommand scaffolds a webhook for an API resource. The subcommand must be run in a project that was initialized with the init command.

Table 9. create webhook flags
Flag Description

-h, --help

Help output for the run bundle subcommand.

generate

The operator-sdk generate command invokes a specific generator to generate code as needed.

bundle

The generate bundle subcommand generates a set of bundle manifests, metadata, and a bundle.Dockerfile file for your Operator project.

Typically, you run the generate kustomize manifests subcommand first to generate the input Kustomize bases that are used by the generate bundle subcommand. However, you can use the make bundle command in an initialized project to automate running these commands in sequence.
Table 10. generate bundle flags
Flag Description

--channels (string)

Comma-separated list of channels to which the bundle belongs. The default value is alpha.

--crds-dir (string)

Root directory for CustomResoureDefinition manifests.

--default-channel (string)

The default channel for the bundle.

--deploy-dir (string)

Root directory for Operator manifests, such as deployments and RBAC. This directory is different from the directory passed to the --input-dir flag.

-h, --help

Help for generate bundle

--input-dir (string)

Directory from which to read an existing bundle. This directory is the parent of your bundle manifests directory and is different from the --deploy-dir directory.

--kustomize-dir (string)

Directory containing Kustomize bases and a kustomization.yaml file for bundle manifests. The default path is config/manifests.

--manifests

Generate bundle manifests.

--metadata

Generate bundle metadata and Dockerfile.

--operator-name (string)

Name of the Operator of the bundle.

--output-dir (string)

Directory to write the bundle to.

--overwrite

Overwrite the bundle metadata and Dockerfile if they exist. The default value is true.

-q, --quiet

Run in quiet mode.

--stdout

Write bundle manifest to standard out.

--version (string)

Semantic version of the Operator in the generated bundle. Set only when creating a new bundle or upgrading the Operator.

kustomize

The generate kustomize subcommand contains subcommands that generate Kustomize data for the Operator.

manifests

The generate kustomize manifests subcommand generates or regenerates Kustomize bases and a kustomization.yaml file in the config/manifests directory, which are used to build bundle manifests by other Operator SDK commands. This command interactively asks for UI metadata, an important component of manifest bases, by default unless a base already exists or you set the --interactive=false flag.

Table 11. generate kustomize manifests flags
Flag Description

--apis-dir (string)

Root directory for API type definitions.

-h, --help

Help for generate kustomize manifests.

--input-dir (string)

Directory containing existing Kustomize files.

--interactive

When set to false, if no Kustomize base exists, an interactive command prompt is presented to accept custom metadata.

--operator-name (string)

Name of the Operator.

--output-dir (string)

Directory where to write Kustomize files.

-q, --quiet

Run in quiet mode.

packagemanifests

Running generate packagemanifests subcommand is the first step to publishing your Operator to a catalog, deploying it with OLM or both. This command generates a set of manifests in a versioned directory and a package manifest file for your Operator. You must run generate kustomize manifests first to regenerate Kustomize bases consumed by this command.

Table 12. generate packagemanifests flags
Flag Description

--channel (string)

The channel name for the generated package.

--crds-dir (string)

The root directory for custom resource definition (CRD) manifests.

--default-channel

Use the channel passed to --channel as the default channel of package manifest file.

--deploy-dir (string)

The root directory for Operator manifests such as deployments and RBAC, for example, deploy. This directory is different from that passed to --input-dir.

--from-version (string)

The semantic version of the Operator, from which it is being upgraded.

-h, --help

Help for generate kustomize manifests.

--input-dir (string)

The directory to read existing package manifests from. This directory is the parent of individual versioned package directories, and different from --deploy-dir.

--kustomize-dir (string)

The directory containing Kustomize bases and a kustomization.yaml for operator-framework manifests. Default: config/manifests.

--operator-name (string)

The name of the packaged Operator.

--output-dir (string)

The directory in which to write package manifests.

-q, --quiet

Run in quiet mode.

--stdout

Write package to stdout.

--update-crds

Update custom resource definition (CRD) manifests in this package. Default: true.

-v, --version (string)

The semantic version of the packaged Operator.

init

The operator-sdk init command initializes an Operator project and generates, or scaffolds, a default project directory layout for the given plug-in.

This command writes the following files:

  • Boilerplate license file

  • PROJECT file with the domain and repository

  • Makefile to build the project

  • go.mod file with project dependencies

  • kustomization.yaml file for customizing manifests

  • Patch file for customizing images for manager manifests

  • Patch file for enabling Prometheus metrics

  • main.go file to run

Table 13. init flags
Flag Description

--help, -h

Help output for the init command.

--plugins (string)

Name and optionally version of the plug-in to initialize the project with. Available plug-ins are ansible.sdk.operatorframework.io/v1, go.kubebuilder.io/v2, go.kubebuilder.io/v3, and helm.sdk.operatorframework.io/v1.

--project-version

Project version. Available values are 2 and 3-alpha, which is the default.

new

The operator-sdk new command creates a new Operator application and generates (or scaffolds) a default project directory layout based on the input <project_name>.

Table 14. new arguments
Argument Description

<project_name>

Name of the new project.
Table 15. new flags
Flag Description

--api-version

Kubernetes API version in the format <group_name>/<version>, for example app.example.com/v1alpha1.

--crd-version

CRD version to generate. Default: v1.

--generate-playbook

Generate an Ansible playbook skeleton. Used with ansible type.

--helm-chart <string>

Initialize Helm Operator with existing Helm chart: <url>, <repo>/<name>, or local path.

--helm-chart-repo <string>

Chart repository URL for the requested Helm chart.

--helm-chart-version <string>

Specific version of the Helm chart. Used only with the helm type. Default: latest version.

--help, -h

Usage and help output.

--kind <string>

CRD kind, for example AppService.

--skip-generation

Skip generation of deepcopy and OpenAPI code and OpenAPI CRD specs.

--type

Type of Operator to initialize: ansible or helm.

Starting with Operator SDK v0.12.0, the --dep-manager flag and support for dep-based projects have been removed. Go projects are now scaffolded to use Go modules.
Example usage for Go project
$ mkdir $GOPATH/src/github.com/example.com/
$ cd $GOPATH/src/github.com/example.com/
$ operator-sdk new app-operator
Example usage for Ansible project
$ operator-sdk new app-operator \
    --type=ansible \
    --api-version=app.example.com/v1alpha1 \
    --kind=AppService

olm

The operator-sdk olm command manages the Operator Lifecycle Manager (OLM) installation in your cluster.

install

olm install subcommand installs OLM in your cluster.

Table 16. install arguments
Argument Description

--olm-namespace string

The namespace where OLM is installed. Default: olm.

--timeout <duration>

The time to wait for the command to complete before it fails. Default: 2m0s.

--version string

The version of OLM resources to be installed. Default: latest.

-h, --help

Usage help output.

status

olm status subcommand gets the status of the Operator Lifecycle Manager (OLM) installation in your cluster.

Table 17. status arguments
Argument Description

--olm-namespace string

The namespace from where OLM is installed. Default: olm.

--timeout <duration>

The time to wait for the command to complete before it fails. Default: 2m0s.

--version string

The version of the OLM that is installed on your cluster. If unset, operator-sdk attempts to auto-discover the version.

-h, --help

Usage help output.

uninstall

olm uninstall subcommand uninstalls OLM from your cluster.

Table 18. uninstall arguments
Argument Description

--olm-namespace (string)

The namespace from where OLM is to be uninstalled. Default: olm.

--timeout <duration>

The time to wait for the command to complete before it fails. Default: 2m0s.

--version (string)

The version of OLM resources to be uninstalled.

-h, --help

Usage help output.

run

The operator-sdk run command provides options that can launch the Operator in various environments.

packagemanifests

run packagemanifests subcommand deploys an Operator’s package manifests with Operator Lifecycle Manager (OLM). The command argument must be set to a valid package manifest root directory, for example, <project_root>/packagemanifests.

Table 19. packagemanifests arguments
Arguments Description

--include (string)

The file path to Kubernetes resource manifests, such as role and subscription objects. These supplement or override the defaults generated by run or cleanup.

--install-mode (string)

The OperatorGroup is created with the specified InstallMode. Format: InstallModeType[=ns1,ns2[, …​]].

--kubeconfig (string)

The file path to a Kubernetes configuration file. Default: The location specified by $KUBECONFIG, or to default file rules if the environment variable not set.

--olm-namespace (string)

The namespace where OLM is installed. Default: olm.

--operator-namespace (string)

The namespace where the Operator resources are created. The namespace must already exist in the cluster, or be defined in a manifest that is passed to --include.

--operator-version (string)

The version of the Operator to deploy.

--timeout <duration>

The time to wait for the command to complete before it fails. Default: 2m0s.

-h, --help

Usage help output.