$ operator-sdk <command> [<subcommand>] [<argument>] [<flags>]
This guide documents the Operator SDK cli commands and their syntax:
$ operator-sdk <command> [<subcommand>] [<argument>] [<flags>]
The operator-sdk build
command compiles the code and builds the executables.
After build
completes, the image is built locally in docker
. It must then be
pushed to a remote registry.
Argument | Description |
---|---|
|
The container image to be built, e.g., |
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.
$ operator-sdk build quay.io/example/operator:v0.0.1 building example-operator... building container quay.io/example/operator:v0.0.1... Sending build context to Docker daemon 163.9MB Step 1/4 : FROM alpine:3.6 ---> 77144d8c6bdc Step 2/4 : ADD tmp/_output/bin/example-operator /usr/local/bin/example-operator ---> 2ada0d6ca93c Step 3/4 : RUN adduser -D example-operator ---> Running in 34b4bb507c14 Removing intermediate container 34b4bb507c14 ---> c671ec1cff03 Step 4/4 : USER example-operator ---> Running in bd336926317c Removing intermediate container bd336926317c ---> d6b58a0fcb8c Successfully built d6b58a0fcb8c Successfully tagged quay.io/example/operator:v0.0.1
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. |
$ operator-sdk completion bash # bash completion for operator-sdk -*- shell-script -*- ... # ex: ts=4 sw=4 et filetype=sh
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 |
$ operator-sdk print-deps --as-file required = [ "k8s.io/code-generator/cmd/defaulter-gen", "k8s.io/code-generator/cmd/deepcopy-gen", "k8s.io/code-generator/cmd/conversion-gen", "k8s.io/code-generator/cmd/client-gen", "k8s.io/code-generator/cmd/lister-gen", "k8s.io/code-generator/cmd/informer-gen", "k8s.io/code-generator/cmd/openapi-gen", "k8s.io/gengo/args", ] [[override]] name = "k8s.io/code-generator" revision = "6702109cc68eb6fe6350b83e14407c8d7309fd1a" ...
The operator-sdk generate
command invokes a specific generator to generate
code as needed.
Subcommand | Description |
---|---|
|
Runs the Kubernetes
code-generators for all CRD
APIs under |
This command must be run every time the API ( |
$ tree pkg/apis/app/v1alpha1/ pkg/apis/app/v1alpha1/ ├── appservice_types.go ├── doc.go ├── register.go $ operator-sdk generate k8s Running code-generation for Custom Resource (CR) group versions: [app:v1alpha1] Generating deepcopy funcs $ tree pkg/apis/app/v1alpha1/ pkg/apis/app/v1alpha1/ ├── appservice_types.go ├── doc.go ├── register.go └── zz_generated.deepcopy.go
The operator-sdk olm-catalog
is the parent command for all Operator Lifecycle
Manager (OLM) Catalog-related commands.
The gen-csv
subcommand writes a Cluster Service Version (CSV) manifest and
optionally Custom Resource Definition (CRD) files to
deploy/olm-catalog/<operator_name>/<csv_version>
.
Flag | Description |
---|---|
|
Semantic version of the CSV manifest. Required. |
|
Semantic version of CSV manifest to use as a base for a new version. |
|
Path to CSV configuration file. Default: |
|
Updates CRD manifests in |
$ operator-sdk olm-catalog gen-csv --csv-version 0.1.0 --update-crds INFO[0000] Generating CSV manifest version 0.1.0 INFO[0000] Fill in the following required fields in file deploy/olm-catalog/operator-name/0.1.0/operator-name.v0.1.0.clusterserviceversion.yaml: spec.keywords spec.maintainers spec.provider spec.labels INFO[0000] Created deploy/olm-catalog/operator-name/0.1.0/operator-name.v0.1.0.clusterserviceversion.yaml
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 |
|
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 |
|
Do not initialize the directory as a Git repository. |
|
Type of Operator to initialize: |
Starting with Operator SDK v0.12.0, the |
$ mkdir $GOPATH/src/github.com/example.com/ $ cd $GOPATH/src/github.com/example.com/ $ operator-sdk new app-operator
$ operator-sdk new app-operator \ --type=ansible \ --api-version=app.example.com/v1alpha1 \ --kind=AppService
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 |
|
CRD |
add api
output$ operator-sdk add api --api-version app.example.com/v1alpha1 --kind AppService Create pkg/apis/app/v1alpha1/appservice_types.go Create pkg/apis/addtoscheme_app_v1alpha1.go Create pkg/apis/app/v1alpha1/register.go Create pkg/apis/app/v1alpha1/doc.go Create deploy/crds/app_v1alpha1_appservice_cr.yaml Create deploy/crds/app_v1alpha1_appservice_crd.yaml Running code-generation for Custom Resource (CR) group versions: [app:v1alpha1] Generating deepcopy funcs $ tree pkg/apis pkg/apis/ ├── addtoscheme_app_appservice.go ├── apis.go └── app └── v1alpha1 ├── doc.go ├── register.go ├── types.go
add controller
output$ operator-sdk add controller --api-version app.example.com/v1alpha1 --kind AppService Create pkg/controller/appservice/appservice_controller.go Create pkg/controller/add_appservice.go $ tree pkg/controller pkg/controller/ ├── add_appservice.go ├── appservice │ └── appservice_controller.go └── controller.go
add crd
output$ operator-sdk add crd --api-version app.example.com/v1alpha1 --kind AppService Generating Custom Resource Definition (CRD) files Create deploy/crds/app_v1alpha1_appservice_crd.yaml Create deploy/crds/app_v1alpha1_appservice_cr.yaml
The operator-sdk test
command can test the Operator locally.
The local
subcommand runs Go tests built using the Operator SDK’s test
framework locally.
Arguments | Description |
---|---|
|
Location of e2e test files (e.g., |
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 (e.g., |
|
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. |
$ operator-sdk test local ./test/e2e/ # Output: ok github.com/operator-framework/operator-sdk-samples/memcached-operator/test/e2e 20.410s
The operator-sdk up
command has subcommands that can launch the Operator in
various ways.
The local
subcommand launches the Operator on the local machine by building
the Operator binary with the ability to access a Kubernetes cluster using a
kubeconfig
file.
Arguments | Description |
---|---|
|
The file path to a Kubernetes configuration file. Defaults: |
|
The namespace where the Operator watches for changes. Default: |
|
Flags that the local Operator may need. Example: |
|
Usage help output. |
$ operator-sdk up 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 up 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 up 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.