红帽全球峰会This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.4.9. Operator SDK CLI reference
This guide documents the Operator SDK CLI commands and their syntax:
operator-sdk <command> [<subcommand>] [<argument>] [<flags>]
$ operator-sdk <command> [<subcommand>] [<argument>] [<flags>]4.9.1. 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.
| Argument | Description |
|---|---|
|
|
The container image to be built, for example |
| Flag | Description |
|---|---|
|
| Enable in-cluster testing by adding test binary to the image. |
|
|
Path of namespaced resources manifest for tests. Default: |
|
|
Location of tests. Default: |
|
| Usage help output. |
If --enable-tests is set, the build command also builds the testing binary, adds it to the container image, and generates a deploy/test-pod.yaml file that allows a user to run the tests as a pod on a cluster.
For example:
operator-sdk build quay.io/example/operator:v0.0.1
$ operator-sdk build quay.io/example/operator:v0.0.1Example output
4.9.2. completion
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
$ operator-sdk completion bashExample output
bash completion for operator-sdk -*- shell-script -*- ex: ts=4 sw=4 et filetype=sh
# bash completion for operator-sdk -*- shell-script -*-
...
# ex: ts=4 sw=4 et filetype=sh4.9.3. print-deps
The operator-sdk print-deps command prints the most recent Golang packages and versions required by Operators. It prints in columnar format by default.
| Flag | Description |
|---|---|
|
|
Print packages and versions in |
For example:
operator-sdk print-deps --as-file
$ operator-sdk print-deps --as-fileExample output
4.9.4. generate
The operator-sdk generate command invokes a specific generator to generate code as needed.
4.9.4.1. crds
The generate crds subcommand generates custom resource definitions (CRDs) or updates them if they exist, under deploy/crds/__crd.yaml. OpenAPI V3 validation YAML is generated as a validation object.
| Flag | Description |
|---|---|
|
|
CRD version to generate. Default: |
|
|
Help for |
For example:
operator-sdk generate crds
$ operator-sdk generate crdstree deploy/crds
$ tree deploy/crdsExample output
├── deploy/crds/app.example.com_v1alpha1_appservice_cr.yaml └── deploy/crds/app.example.com_appservices_crd.yaml
├── deploy/crds/app.example.com_v1alpha1_appservice_cr.yaml
└── deploy/crds/app.example.com_appservices_crd.yaml4.9.4.2. csv
The csv subcommand writes a cluster service version (CSV) manifest for use with Operator Lifecycle Manager (OLM). It also optionally writes CRD files to deploy/olm-catalog/<operator_name>/<csv_version>.
| Flag | Description |
|---|---|
|
| The channel the CSV should be registered under in the package manifest. |
|
|
The path to the CSV configuration file. Default: |
|
| The semantic version of the CSV manifest. Required. |
|
|
Use the channel passed to |
|
| The semantic version of CSV manifest to use as a base for a new version. |
|
| The Operator name to use while generating the CSV. |
|
|
Updates CRD manifests in |
For example:
operator-sdk generate csv \
--csv-version 0.1.0 \
--update-crds
$ operator-sdk generate csv \
--csv-version 0.1.0 \
--update-crdsExample output
4.9.4.3. k8s
The k8s subcommand runs the Kubernetes code-generators for all CRD APIs under pkg/apis/. Currently, k8s only runs deepcopy-gen to generate the required DeepCopy() functions for all custom resource (CR) types.
This command must be run every time the API (spec and status) for a custom resource type is updated.
For example:
tree pkg/apis/app/v1alpha1/
$ tree pkg/apis/app/v1alpha1/Example output
pkg/apis/app/v1alpha1/ ├── appservice_types.go ├── doc.go └── register.go
pkg/apis/app/v1alpha1/
├── appservice_types.go
├── doc.go
└── register.gooperator-sdk generate k8s
$ operator-sdk generate k8sExample output
Running code-generation for Custom Resource (CR) group versions: [app:v1alpha1] Generating deepcopy funcs
Running code-generation for Custom Resource (CR) group versions: [app:v1alpha1]
Generating deepcopy funcstree pkg/apis/app/v1alpha1/
$ tree pkg/apis/app/v1alpha1/Example output
pkg/apis/app/v1alpha1/ ├── appservice_types.go ├── doc.go ├── register.go └── zz_generated.deepcopy.go
pkg/apis/app/v1alpha1/
├── appservice_types.go
├── doc.go
├── register.go
└── zz_generated.deepcopy.go4.9.5. 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>.
| Argument | Description |
|---|---|
|
| Name of the new project. |
| Flag | Description |
|---|---|
|
|
CRD API version in the format |
|
|
Generate an Ansible playbook skeleton. Used with |
|
|
Path to file containing headers for generated Go files. Copied to |
|
|
Initialize Helm Operator with existing Helm chart: |
|
| Chart repository URL for the requested Helm chart. |
|
| Specific version of the Helm chart. Default: latest version. |
|
| Usage and help output. |
|
|
CRD kind, for example |
|
| Do not initialize the directory as a Git repository. |
|
|
Type of Operator to initialize: |
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/
$ mkdir $GOPATH/src/github.com/example.com/cd $GOPATH/src/github.com/example.com/
$ cd $GOPATH/src/github.com/example.com/operator-sdk new app-operator
$ operator-sdk new app-operatorExample usage for Ansible project
operator-sdk new app-operator \
--type=ansible \
--api-version=app.example.com/v1alpha1 \
--kind=AppService
$ operator-sdk new app-operator \
--type=ansible \
--api-version=app.example.com/v1alpha1 \
--kind=AppService4.9.6. add
The operator-sdk add command adds a controller or resource to the project. The command must be run from the Operator project root directory.
| Subcommand | Description |
|---|---|
|
|
Adds a new API definition for a new custom resource (CR) under |
|
|
Adds a new controller under |
|
|
Adds a CRD and the CR files. The
|
| Flag | Description |
|---|---|
|
|
CRD API version in the format |
|
|
CRD |
For example:
operator-sdk add api \
--api-version app.example.com/v1alpha1 \
--kind AppService
$ operator-sdk add api \
--api-version app.example.com/v1alpha1 \
--kind AppServiceExample output
tree pkg/apis
$ tree pkg/apisExample output
operator-sdk add controller \
--api-version app.example.com/v1alpha1 \
--kind AppService
$ operator-sdk add controller \
--api-version app.example.com/v1alpha1 \
--kind AppServiceExample output
Create pkg/controller/appservice/appservice_controller.go Create pkg/controller/add_appservice.go
Create pkg/controller/appservice/appservice_controller.go
Create pkg/controller/add_appservice.gotree pkg/controller
$ tree pkg/controllerExample output
pkg/controller/ ├── add_appservice.go ├── appservice │ └── appservice_controller.go └── controller.go
pkg/controller/
├── add_appservice.go
├── appservice
│ └── appservice_controller.go
└── controller.gooperator-sdk add crd \
--api-version app.example.com/v1alpha1 \
--kind AppService
$ operator-sdk add crd \
--api-version app.example.com/v1alpha1 \
--kind AppServiceExample output
Generating Custom Resource Definition (CRD) files Create deploy/crds/app_v1alpha1_appservice_crd.yaml Create deploy/crds/app_v1alpha1_appservice_cr.yaml
Generating Custom Resource Definition (CRD) files
Create deploy/crds/app_v1alpha1_appservice_crd.yaml
Create deploy/crds/app_v1alpha1_appservice_cr.yaml4.9.7. test
The operator-sdk test command can test the Operator locally.
4.9.7.1. local
The local subcommand runs Go tests built using the test framework of the Operator SDK locally.
| Arguments | Description |
|---|---|
|
|
Location of end-to-end (e2e) test files, for example |
| Flags | Description |
|---|---|
|
|
Location of |
|
|
Path to manifest for global resources. Default: |
|
|
Path to manifest for per-test, namespaced resources. Default: combines |
|
|
If non-empty, a single namespace to run tests in, for example |
|
|
Extra arguments to pass to |
|
|
Enable running the Operator locally with |
|
| Disable test resource creation. |
|
| Use a different Operator image from the one specified in the namespaced manifest. |
|
| Usage help output. |
For example:
operator-sdk test local ./test/e2e/
$ operator-sdk test local ./test/e2e/Example output
ok github.com/operator-framework/operator-sdk-samples/memcached-operator/test/e2e 20.410s
ok github.com/operator-framework/operator-sdk-samples/memcached-operator/test/e2e 20.410s4.9.8. run
The operator-sdk run command provides options that can launch the Operator in various environments.
| Arguments | Description |
|---|---|
|
|
The file path to a Kubernetes configuration file. Default: |
|
|
The Operator is run locally by building the Operator binary with the ability to access a Kubernetes cluster using a |
|
|
The namespace where the Operator watches for changes. Default: |
|
|
Flags that the local Operator might require. Example: |
|
| Usage help output. |
4.9.8.1. --local
The --local flag launches the Operator on the local machine by building the Operator binary with the ability to access a Kubernetes cluster using a kubeconfig file.
For example:
operator-sdk run --local \ --kubeconfig "mycluster.kubecfg" \ --namespace "default" \ --operator-flags "--flag1 value1 --flag2=value2"
$ operator-sdk run --local \
--kubeconfig "mycluster.kubecfg" \
--namespace "default" \
--operator-flags "--flag1 value1 --flag2=value2"
The following example uses the default kubeconfig, the default namespace environment variable, and passes in flags for the Operator. To use the Operator flags, your Operator must know how to handle the option. For example, for an Operator that understands the resync-interval flag:
operator-sdk run --local --operator-flags "--resync-interval 10"
$ operator-sdk run --local --operator-flags "--resync-interval 10"
If you are planning on using a different namespace than the default, use the --namespace flag to change where the Operator is watching for custom resources (CRs) to be created:
operator-sdk run --local --namespace "testing"
$ operator-sdk run --local --namespace "testing"
For this to work, your Operator must handle the WATCH_NAMESPACE environment variable. This can be accomplished using the utility function k8sutil.GetWatchNamespace in your Operator.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}