Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 8. Operator SDK

8.1. Installing the Operator SDK CLI
Link kopieren

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.

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

See Developing Operators for full documentation on the Operator SDK.

Note

OpenShift Container Platform 4.12 supports Operator SDK 1.25.4.

8.1.1. Installing the Operator SDK CLI on Linux
Link kopieren

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

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

  3. Unpack the archive: 

    $ tar xvf operator-sdk-v1.25.4-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.25.4-ocp", ...

8.1.2. Installing the Operator SDK CLI on macOS
Link kopieren

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

  1. For the 
    amd64
    and 
    arm64
    architectures, navigate to the OpenShift mirror site for the amd64 architecture and OpenShift mirror site for the arm64 architecture respectively.
  2. From the latest 4.12 directory, download the latest version of the tarball for macOS.

  3. Unpack the Operator SDK archive for 

    amd64
    architecture by running the following command: 

    $ tar xvf operator-sdk-v1.25.4-ocp-darwin-x86_64.tar.gz

  4. Unpack the Operator SDK archive for 

    arm64
    architecture by running the following command: 

    $ tar xvf operator-sdk-v1.25.4-ocp-darwin-aarch64.tar.gz

  5. Make the file executable by running the following command: 

    $ chmod +x operator-sdk

  6. 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.25.4-ocp", ...

8.2. Operator SDK CLI reference
Link kopieren

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

See Developing Operators for full documentation on the Operator SDK.

8.2.1. bundle
Link kopieren

The 

operator-sdk bundle
command manages Operator bundle metadata.

8.2.1.1. validate
Link kopieren

The 

bundle validate
subcommand validates an Operator bundle.

Expand
Table 8.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.

8.2.2. cleanup
Link kopieren

The 

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

Expand
Table 8.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
.

8.2.3. completion
Link kopieren

The 

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

Expand
Table 8.3. completion subcommands
SubcommandDescription

bash

Generate bash completions. 

zsh

Generate zsh completions.

Expand
Table 8.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

8.2.4. create
Link kopieren

The 

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

8.2.4.1. api
Link kopieren

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 8.5. create api flags
FlagDescription

-h
, 
--help

Help output for the 

run bundle
subcommand.

8.2.5. generate
Link kopieren

The 

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

8.2.5.1. bundle
Link kopieren

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

8.2.5.2. kustomize
Link kopieren

The 

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

8.2.5.2.1. manifests
Link kopieren

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

8.2.6. init
Link kopieren

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

8.2.7. run
Link kopieren

The 

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

8.2.7.1. bundle
Link kopieren

The 

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

Expand
Table 8.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. 

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

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

8.2.7.2. bundle-upgrade
Link kopieren

The 

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

Expand
Table 8.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. 

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

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

8.2.8. scorecard
Link kopieren

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

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

  1. 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".
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red HatNach oben