Este contenido no está disponible en el idioma seleccionado.

Chapter 7. Operator SDK

7.1. Installing the Operator SDK CLI

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.

Important

The Red Hat-supported version of the Operator SDK CLI tool, including the related scaffolding and testing tools for Operator projects, is deprecated and is planned to be removed in a future release of OpenShift Dedicated. Red Hat will provide bug fixes and support for this feature during the current release lifecycle, but this feature will no longer receive enhancements and will be removed from future OpenShift Dedicated releases.

The Red Hat-supported version of the Operator SDK is not recommended for creating new Operator projects. Operator authors with existing Operator projects can use the version of the Operator SDK CLI tool released with OpenShift Dedicated 4 to maintain their projects and create Operator releases targeting newer versions of OpenShift Dedicated.

The following related base images for Operator projects are not deprecated. The runtime functionality and configuration APIs for these base images are still supported for bug fixes and for addressing CVEs.

The base image for Ansible-based Operator projects
The base image for Helm-based Operator projects

For information about the unsupported, community-maintained, version of the Operator SDK, see Operator SDK (Operator Framework).

Operator authors with cluster administrator access to a Kubernetes-based cluster, such as OpenShift Dedicated, can use the Operator SDK CLI to develop their own Operators based on Go, Ansible, Java, 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.

7.1.1. Installing the Operator SDK CLI on Linux

You can install the OpenShift SDK CLI tool on Linux.

Prerequisites

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

Procedure

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

Unpack the archive:

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

Make the file executable:
```
$ chmod +x operator-sdk
```
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.36.1-ocp", ...
```

7.1.2. Installing the Operator SDK CLI on macOS

You can install the OpenShift SDK CLI tool on macOS.

Prerequisites

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

Procedure

For the amd64 architecture, navigate to the OpenShift mirror site for the amd64 architecture.
From the latest 4 directory, download the latest version of the tarball for macOS.
Unpack the Operator SDK archive for amd64 architecture by running the following command:
```
$ tar xvf operator-sdk-v1.36.1-ocp-darwin-x86_64.tar.gz
```
Make the file executable by running the following command:
```
$ chmod +x operator-sdk
```
Move the extracted operator-sdk binary to a directory that is on your PATH by running the following command:
Tip
Check your PATH by running the following command:
```
$ echo $PATH
```
```
$ sudo mv ./operator-sdk /usr/local/bin/operator-sdk
```

Verification

After you install the Operator SDK CLI, verify that it is available by running the following command::
```
$ operator-sdk version
```
Example output
```
operator-sdk version: "v1.36.1-ocp", ...
```

7.2. Operator SDK CLI reference

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

Important

The base image for Ansible-based Operator projects
The base image for Helm-based Operator projects

For information about the unsupported, community-maintained, version of the Operator SDK, see Operator SDK (Operator Framework).

Operator SDK CLI syntax

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

7.2.1. bundle

The operator-sdk bundle command manages Operator bundle metadata.

7.2.1.1. validate

The bundle validate subcommand validates an Operator bundle.

Table 7.1. bundle validate flags
Flag	Description
`-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

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

Table 7.2. cleanup flags
Flag	Description
`-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

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

Table 7.3. completion subcommands
Subcommand	Description
`bash`	Generate bash completions.
`zsh`	Generate zsh completions.

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

7.2.4. create

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

7.2.4.1. 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 7.5. create api flags
Flag	Description
`-h`, `--help`	Help output for the `run bundle` subcommand.

7.2.5. generate

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

7.2.5.1. bundle

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.

Table 7.6. 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.
`--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

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

7.2.5.2.1. 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 7.7. 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.
`--output-dir` (string)	Directory where to write Kustomize files.
`--package` (string)	Package name.
`-q`, `--quiet`	Run in quiet mode.

7.2.6. init

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

Table 7.8. init flags
Flag	Description
`--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

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

7.2.7.1. bundle

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

Table 7.9. run bundle flags
Flag	Description
`--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.
`--security-context-config <security_context>`	Specifies the security context to use for the catalog pod. Allowed values include `restricted` and `legacy`. The default value is `legacy`. ^[1]
`-h`, `--help`	Help output for the `run bundle` subcommand.

The restricted security context is not compatible with the default namespace. To configure your Operator’s pod security admission in your production environment, see "Complying with pod security admission". For more information about pod security admission, see "Understanding and managing pod security admission".

7.2.7.2. bundle-upgrade

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

Table 7.10. run bundle-upgrade flags
Flag	Description
`--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.
`--security-context-config <security_context>`	Specifies the security context to use for the catalog pod. Allowed values include `restricted` and `legacy`. The default value is `legacy`. ^[1]
`-h`, `--help`	Help output for the `run bundle` subcommand.

The restricted security context is not compatible with the default namespace. To configure your Operator’s pod security admission in your production environment, see "Complying with pod security admission". For more information about pod security admission, see "Understanding and managing pod security admission".

7.2.8. scorecard

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.

Table 7.11. scorecard flags
Flag	Description
`-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`.
`--pod-security <security_context>`	Option to run scorecard with the specified security context. Allowed values include `restricted` and `legacy`. The default value is `legacy`. ^[1]
`-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`.

The restricted security context is not compatible with the default namespace. To configure your Operator’s pod security admission in your production environment, see "Complying with pod security admission". For more information about pod security admission, see "Understanding and managing pod security admission".