Red Hat Summit Red Hat SummitApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Este contenido no está disponible en el idioma seleccionado.

Chapter 7. Operator SDK

7.1. Installing the Operator SDK CLI
Copiar enlace

The Operator SDK provides a command-line interface (CLI) tool that Operator developers can use to build, test, and deploy an Operator. You can install the Operator SDK CLI on your workstation so that you are prepared to start authoring your own Operators.

See Developing Operators for full documentation on the Operator SDK.

Note

OpenShift Container Platform 4.8 and later supports Operator SDK v1.8.0.

7.1.1. Installing the Operator SDK CLI
Copiar enlace

You can install the OpenShift SDK CLI tool on Linux.

Prerequisites

  • Go v1.16+ 
  • docker
    v17.03+, 
    podman
    v1.9.3+, or 
    buildah
    v1.7+

Procedure

  1. Navigate to the OpenShift mirror site.
  2. From the 
    4.8.4
    directory, download the latest version of the tarball for Linux.

  3. Unpack the archive: 

    $ tar xvf operator-sdk-v1.8.0-ocp-linux-x86_64.tar.gz

  4. Make the file executable: 

    $ chmod +x operator-sdk

  5. Move the extracted 

    operator-sdk
    binary to a directory that is on your 
    PATH
    .

    Tip

    To check your 

    PATH
    : 

    $ echo $PATH
     
    $ sudo mv ./operator-sdk /usr/local/bin/operator-sdk

Verification

  • After you install the Operator SDK CLI, verify that it is available: 

    $ operator-sdk version

    Example output

    operator-sdk version: "v1.8.0-ocp", ...

7.2. Operator SDK CLI reference
Copiar enlace

The Operator SDK command-line interface (CLI) is a development kit designed to make writing Operators easier.

Operator SDK CLI syntax

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

Operator authors with cluster administrator access to a Kubernetes-based cluster (such as OpenShift Container Platform) 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.

7.2.1. bundle
Copiar enlace

The 

operator-sdk bundle
command manages Operator bundle metadata.

7.2.1.1. validate
Copiar enlace

The 

bundle validate
subcommand validates an Operator bundle.

Expand
Table 7.1. bundle validate flags
FlagDescription

-h
, 
--help

Help output for the 

bundle validate
subcommand. 

--index-builder
(string)

Tool to pull and unpack bundle images. Only used when validating a bundle image. Available options are 

docker
, which is the default, 
podman
, or 
none
. 

--list-optional

List all optional validators available. When set, no validators are run. 

--select-optional
(string)

Label selector to select optional validators to run. When run with the 

--list-optional
flag, lists available optional validators.

7.2.2. cleanup
Copiar enlace

The 

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

Expand
Table 7.2. cleanup flags
FlagDescription

-h
, 
--help

Help output for the 

run bundle
subcommand. 

--kubeconfig
(string)

Path to the 

kubeconfig
file to use for CLI requests. 

n
, 
--namespace
(string)

If present, namespace in which to run the CLI request. 

--timeout <duration>

Time to wait for the command to complete before failing. The default value is 

2m0s
.

7.2.3. completion
Copiar enlace

The 

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

Expand
Table 7.3. completion subcommands
SubcommandDescription

bash

Generate bash completions. 

zsh

Generate zsh completions.

Expand
Table 7.4. completion flags
FlagDescription

-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

7.2.4. create
Copiar enlace

The 

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

7.2.4.1. api
Copiar enlace

The 

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

Expand
Table 7.5. create api flags
FlagDescription

-h
, 
--help

Help output for the 

run bundle
subcommand.

7.2.5. generate
Copiar enlace

The 

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

7.2.5.1. bundle
Copiar enlace

The 

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

Note

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.

Expand
Table 7.6. generate bundle flags
FlagDescription

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

--output-dir
(string)

Directory to write the bundle to. 

--overwrite

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

true
. 

--package
(string)

Package name for the bundle. 

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

7.2.5.2. kustomize
Copiar enlace

The 

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

7.2.5.2.1. manifests
Copiar enlace

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.

Expand
Table 7.7. generate kustomize manifests flags
FlagDescription

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

--output-dir
(string)

Directory where to write Kustomize files. 

--package
(string)

Package name. 

-q
, 
--quiet

Run in quiet mode.

7.2.6. init
Copiar enlace

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
Expand
Table 7.8. init flags
FlagDescription

--help, -h

Help output for the 

init
command. 

--plugins
(string)

Name and optionally version of the plugin to initialize the project with. Available plugins 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.

7.2.7. run
Copiar enlace

The 

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

7.2.7.1. bundle
Copiar enlace

The 

run bundle
subcommand deploys an Operator in the bundle format with Operator Lifecycle Manager (OLM).

Expand
Table 7.9. run bundle flags
FlagDescription

--index-image
(string)

Index image in which to inject a bundle. The default image is 

quay.io/operator-framework/upstream-opm-builder:latest
. 

--install-mode <install_mode_value>

Install mode supported by the cluster service version (CSV) of the Operator, for example 

AllNamespaces
or 
SingleNamespace
. 

--timeout <duration>

Install timeout. The default value is 

2m0s
. 

--kubeconfig
(string)

Path to the 

kubeconfig
file to use for CLI requests. 

n
, 
--namespace
(string)

If present, namespace in which to run the CLI request. 

-h
, 
--help

Help output for the 

run bundle
subcommand.

7.2.7.2. bundle-upgrade
Copiar enlace

The 

run bundle-upgrade
subcommand upgrades an Operator that was previously installed in the bundle format with Operator Lifecycle Manager (OLM).

Expand
Table 7.10. run bundle-upgrade flags
FlagDescription

--timeout <duration>

Upgrade timeout. The default value is 

2m0s
. 

--kubeconfig
(string)

Path to the 

kubeconfig
file to use for CLI requests. 

n
, 
--namespace
(string)

If present, namespace in which to run the CLI request. 

-h
, 
--help

Help output for the 

run bundle
subcommand.

7.2.8. scorecard
Copiar enlace

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.

Expand
Table 7.11. scorecard flags
FlagDescription

-c
, 
--config
(string)

Path to scorecard configuration file. The default path is 

bundle/tests/scorecard/config.yaml
. 

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

-o
, 
--output
(string)

Output format for results. Available values are 

text
, which is the default, and 
json
. 

-l
, 
--selector
(string)

Label selector to determine which tests are run. 

-s
, 
--service-account
(string)

Service account to use for tests. The default value is 

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
. The default value is 
30s
.

Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2026 Red HatVolver arriba