$ operator-sdk <command> [<subcommand>] [<argument>] [<flags>]
The Operator SDK command-line interface (cli) is a development kit designed to make writing Operators easier.
$ operator-sdk <command> [<subcommand>] [<argument>] [<flags>]
Operator authors with cluster administrator access to a Kubernetes-based cluster (such as OKD) can use the Operator SDK cli to develop their own Operators based on Go, Ansible, or Helm. Kubebuilder is embedded into the Operator SDK as the scaffolding solution for Go-based Operators, which means existing Kubebuilder projects can be used as is with the Operator SDK and continue to work.
See Developing Operators for full documentation on the Operator SDK.
The operator-sdk bundle
command manages Operator bundle metadata.
The bundle validate
subcommand validates an Operator bundle.
Flag | Description |
---|---|
|
Help output for the |
|
Tool to pull and unpack bundle images. Only used when validating a bundle image. Available options are |
|
List all optional validators available. When set, no validators are run. |
|
Label selector to select optional validators to run. When run with the |
The operator-sdk cleanup
command destroys and removes resources that were created for an Operator that was deployed with the run
command.
Flag | Description |
---|---|
|
Help output for the |
|
Path to the |
|
If present, namespace in which to run the cli request. |
|
Time to wait for the command to complete before failing. The default value is |
The operator-sdk completion
command generates shell completions to make issuing cli commands quicker and easier.
Subcommand | Description |
---|---|
|
Generate bash completions. |
|
Generate zsh completions. |
Flag | Description |
---|---|
|
Usage help output. |
For example:
$ operator-sdk completion bash
# bash completion for operator-sdk -*- shell-script -*-
...
# ex: ts=4 sw=4 et filetype=sh
The operator-sdk generate
command invokes a specific generator to generate code or manifests.
The generate bundle
subcommand generates a set of bundle manifests, metadata, and a bundle.Dockerfile
file for your Operator project.
Typically, you run the |
Flag | Description |
---|---|
|
Comma-separated list of channels to which the bundle belongs. The default value is |
|
Root directory for |
|
The default channel for the bundle. |
|
Root directory for Operator manifests, such as deployments and RBAC. This directory is different from the directory passed to the |
|
Help for |
|
Directory from which to read an existing bundle. This directory is the parent of your bundle |
|
Directory containing Kustomize bases and a |
|
Generate bundle manifests. |
|
Generate bundle metadata and Dockerfile. |
|
Directory to write the bundle to. |
|
Overwrite the bundle metadata and Dockerfile if they exist. The default value is |
|
Package name for the bundle. |
|
Run in quiet mode. |
|
Write bundle manifest to standard out. |
|
Semantic version of the Operator in the generated bundle. Set only when creating a new bundle or upgrading the Operator. |
See Bundling an Operator and deploying with Operator Lifecycle Manager for a full procedure that includes using the make bundle
command to call the generate bundle
subcommand.
The generate kustomize
subcommand contains subcommands that generate Kustomize data for the Operator.
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.
Flag | Description |
---|---|
|
Root directory for API type definitions. |
|
Help for |
|
Directory containing existing Kustomize files. |
|
When set to |
|
Directory where to write Kustomize files. |
|
Package name. |
|
Run in quiet mode. |
The operator-sdk init
command initializes an Operator project and generates, or scaffolds, a default project directory layout for the given plugin.
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
Flag | Description |
---|---|
|
Help output for the |
|
Name and optionally version of the plugin to initialize the project with. Available plugins are |
|
Project version. Available values are |
The operator-sdk run
command provides options that can launch the Operator in various environments.
The run bundle
subcommand deploys an Operator in the bundle format with Operator Lifecycle Manager (OLM).
Flag | Description |
---|---|
|
Index image in which to inject a bundle. The default image is |
|
Install mode supported by the cluster service version (CSV) of the Operator, for example |
|
Install timeout. The default value is |
|
Path to the |
|
If present, namespace in which to run the cli request. |
|
Help output for the |
See Operator group membership for details on possible install modes.
The run bundle-upgrade
subcommand upgrades an Operator that was previously installed in the bundle format with Operator Lifecycle Manager (OLM).
Flag | Description |
---|---|
|
Upgrade timeout. The default value is |
|
Path to the |
|
If present, namespace in which to run the cli request. |
|
Help output for the |
The operator-sdk scorecard
command 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.
Flag | Description |
---|---|
|
Path to scorecard configuration file. The default path is |
|
Help output for the |
|
Path to |
|
List which tests are available to run. |
|
Namespace in which to run the test images. |
|
Output format for results. Available values are |
|
Label selector to determine which tests are run. |
|
Service account to use for tests. The default value is |
|
Disable resource cleanup after tests are run. |
|
Seconds to wait for tests to complete, for example |
See Validating Operators using the scorecard tool for details about running the scorecard tool.