11.7. Operator SDK CLI リファレンス

以下では、Operator SDK CLI コマンドおよびそれらの構文について説明します。

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

11.7.1. build

operator-sdk build コマンドはコードをコンパイルし、実行可能プロジェクトをビルドします。build が完了すると、イメージは docker でローカルにビルドされます。これは次にリモートレジストリーにプッシュされる必要があります。

表11.11 build 引数

引数説明

<image>

ビルトされるコンテナーイメージ (例: quay.io/example/operator:v0.0.1)。

表11.12 build フラグ

フラグ説明

--enable-tests (ブール)

テストバイナリーをイメージに追加することにより、クラスター内でのテストを有効にします。

--namespaced-manifest (文字列)

テスト用の namespace を使用したリソースマニフェストのパス。デフォルト: deploy/operator.yaml

--test-location (文字列)

テストの場所。デフォルト: ./test/e2e

-h, --help

使用方法についてのヘルプの出力。

--enable-tests が設定される場合、build コマンドはテストバイナリーもビルドし、これをコンテナーイメージに追加して、ユーザーがテストをクラスター上で Pod として実行できるように deploy/test-pod.yaml ファイルを生成します。

出力例

$ 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

11.7.2. completion

operator-sdk completion コマンドは、CLI コマンドをより迅速に、より容易に実行できるようにシェル補完を生成します。

表11.13 completion サブコマンド

サブコマンド説明

bash

bash 補完を生成します。

zsh

zsh 補完を生成します。

表11.14 completion フラグ

フラグ説明

-h, --help

使用方法についてのヘルプの出力。

出力例

$ operator-sdk completion bash

# bash completion for operator-sdk                         -*- shell-script -*-
...
# ex: ts=4 sw=4 et filetype=sh

11.7.3. print-deps

operator-sdk print-deps コマンドは、Operator が必要とする最新の Golang パッケージおよびバージョンを出力します。これはデフォルトで単票形式 (columnar format) の出力を行います。

表11.15 print-deps フラグ

フラグ説明

--as-file

Gopkg.toml 形式でパッケージおよびバージョンを出力します。

出力例

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

11.7.4. generate

operator-sdk generate コマンドは特定のジェネレーターを起動して、必要に応じてコードを生成します。

表11.16 generate サブコマンド

サブコマンド説明

k8s

すべての CRD API の Kubernetes code-generatorspkg/apis/ の下に実行します。現時点で、k8sdeepcopy-gen のみを実行し、すべてのカスタムリソース (CR) タイプに必要な DeepCopy() 関数を生成します。

注記

このコマンドは、カスタムリソースの API (spec および status) が更新されるたびに実行される必要があります。

出力例

$ 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

11.7.5. olm-catalog

operator-sdk olm-catalog は、すべての Operator Lifecycle Manager (OLM) Catalog 関連コマンドの親コマンドです。

11.7.5.1. gen-csv

gen-csv サブコマンドは、Cluster Service Version (CSV) マニフェスト、およびオプションでカスタムリソースリソース定義 (CRD) ファイルを deploy/olm-catalog/<operator_name>/<csv_version> に書き込みます。

表11.17 olm-catalog gen-csv フラグ

フラグ説明

--csv-version (文字列)

CSV マニフェストのセマンティックバージョン。必須。

--from-version (文字列)

新規バージョンのベースとして使用する CSV マニフェストのセマンティックバージョン。

--csv-config (文字列)

CSV 設定ファイルへのパス。デフォルト: deploy/olm-catalog/csv-config.yaml

--update-crds

最新の CRD マニフェストを使用して deploy/<operator_name>/<csv_version> で CRD マニフェストを更新します。

出力例

$ 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

11.7.6. new

operator-sdk new コマンドは新規の Operator アプリケーションを作成し、入力された <project_name> に基づいてデフォルトのプロジェクトディレクトリーのレイアウトの生成 (または スキャフォールディング) を実行します。

表11.18 new 引数

引数説明

<project_name>

新規プロジェクトの名前。

表11.19 new フラグ

フラグ説明

--api-version

$GROUP_NAME/$VERSION 形式の CRD APIVersion (例: app.example.com/v1alpha1)。ansible または helm タイプで使用されます。

--dep-manager [dep|modules]

新規プロジェクトが使用する依存関係マネージャー。 go タイプで使用されます。(デフォルト: modules)

--generate-playbook

Ansible Playbook のスケルトンを生成します。ansible タイプで使用されます。

--header-file <string>

生成される Go ファイルのヘッダーを含むファイルへのパスです。hack/boilerplate.go.txt にコピーされます。

--helm-chart <string>

既存の Helm チャートで Helm Operator を初期化します。 <url><repo>/<name> 、またはローカルパス。

--helm-chart-repo <string>

要求される Helm チャートのチャートリポジトリー URL。

--helm-chart-version <string>

Helm チャートの特定バージョン。(デフォルト: latest version)

--help, -h

使用方法およびヘルプの出力。

--kind <string>

CRD Kind (例: AppService)。ansible または helm タイプで使用されます。

--skip-git-init

ディレクトリーを Git リポジトリーとして実行しません。

--type

初期化する Operator のタイプ: goansible または helm。(デフォルト: go)

Go プロジェクトの使用例

$ mkdir $GOPATH/src/github.com/example.com/
$ cd $GOPATH/src/github.com/example.com/
$ operator-sdk new app-operator

Ansible プロジェクトの使用例

$ operator-sdk new app-operator \
    --type=ansible \
    --api-version=app.example.com/v1alpha1 \
    --kind=AppService

11.7.7. add

operator-sdk add コマンドは、コントローラーまたはリソースをプロジェクトに追加します。コマンドは、Operator プロジェクトのルートディレクトリーから実行される必要があります。

表11.20 add サブコマンド

サブコマンド説明

api

新規カスタムリソース (CR) の新規 API 定義を pkg/apis の下に追加し、カスタムリソース定義 (CRD) およびカスタムリソース (CR) ファイルを deploy/crds/ の下に生成します。API が pkg/apis/<group>/<version> にすでにある場合には、コマンドは上書きせず、エラーを返します。

controller

新規コントローラーを pkg/controller/<kind>/ の下に追加します。コントローラーは operator-sdk add api --kind=<kind> --api-version=<group/version> コマンドで pkg/apis/<group>/<version> の下にすでに定義されている必要のある CR タイプを使用することを予想します。その Kind のコントローラーパッケージが pkg/controller/<kind> にすでに存在する場合、コマンドは上書きせず、エラーが返されます。

crd

CRD および CR ファイルを追加します。<project-name>/deploy パスがすでに存在している必要があります。--api-version および --kind フラグが、新規 Operator アプリケーションを生成するために必要です。

  • 生成される CRD ファイル名: <project-name>/deploy/crds/<group>_<version>_<kind>_crd.yaml
  • 生成される CR ファイル名: <project-name>/deploy/crds/<group>_<version>_<kind>_cr.yaml

表11.21 add api フラグ

フラグ説明

--api-version (文字列)

$GROUP_NAME/$VERSION 形式の CRD APIVersion (例: app.example.com/v1alpha1)。

--image (文字列)

CRD Kind (例: AppService)。

add api 出力サンプル

$ 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 出力サンプル

$ 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 出力サンプル

$ 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

11.7.8. test

operator-sdk test コマンドは Operator をローカルでテストできます。

11.7.8.1. local

local サブコマンドは、Operator SDK のテストフレームワークを使用してビルドされた Go テストをローカルで実行します。

表11.22 test local 引数

引数説明

<test_location> (文字列)

e2e テストファイルの場所 (例: ./test/e2e/)。

表11.23 test local フラグ

フラグ説明

--kubeconfig (文字列)

クラスターの kubeconfig の場所。デフォルト: ~/.kube/config

--global-manifest (文字列)

グローバルリソースのマニフェストへのパス。デフォルト: deploy/crd.yaml

--namespaced-manifest (文字列)

テスト別の namespace を使用したリソースのマニフェストへのパス。デフォルト: deploy/service_account.yamldeploy/rbac.yaml、および deploy/operator.yaml の組み合わせ。

--namespace (文字列)

空ではない場合、テストを実行する単一の namespace (例: operator-test)。デフォルト: ""

--go-test-flags (string)

go test に渡す追加の引数 (例: -f "-v -parallel=2")。

--up-local

クラスターのイメージとしてではなく、go run を使用した Operator のローカルの実行を有効にします。

--no-setup

テストリソースの作成を無効にします。

--image (文字列)

namespace を使用したマニフェストで指定されたイメージとは異なる Operator イメージを使用します。

-h, --help

使用方法についてのヘルプの出力。

出力例

$ operator-sdk test local ./test/e2e/

# Output:
ok  	github.com/operator-framework/operator-sdk-samples/memcached-operator/test/e2e	20.410s

11.7.9. up

operator-sdk up コマンドには、様々な方法で Operator を実行できるサブコマンドが含まれます。

11.7.9.1. local

local サブコマンドは、kubeconfig ファイルを使用して Kubernetes クラスターにアクセスできる機能を使って Operator バイナリーをビルドし、Operator をローカルマシンで起動します。

表11.24 up local 引数

引数説明

--kubeconfig (文字列)

Kubernetes 設定ファイルへのファイルパス。デフォルト: $HOME/.kube/config

--namespace (文字列)

Operator が変更の有無を監視する namespace。デフォルト: default

--operator-flags

ローカル Operator が必要とする可能性のあるフラグ。例: --flag1 value1 --flag2=value2

-h, --help

使用方法についてのヘルプの出力。

出力例

$ operator-sdk up local \
  --kubeconfig "mycluster.kubecfg" \
  --namespace "default" \
  --operator-flags "--flag1 value1 --flag2=value2"

以下の例では、デフォルトの kubeconfig、デフォルトの namespace 環境変数を使用し、Operator のフラグで渡します。Operator フラグを使用するには、Operator がこのオプションの処理方法を認識している必要があります。たとえば、resync-interval フラグを認識する Operator の場合は、以下を実行します。

$ operator-sdk up local --operator-flags "--resync-interval 10"

デフォルト以外の namespace を使用することを予定している場合は、 --namespace フラグを使用して、Operator が作成されるカスタムリソース (CR) を監視する場所を変更します。

$ operator-sdk up local --namespace "testing"

これが機能させるには、Operator が WATCH_NAMESPACE 環境変数を処理する必要があります。これは、Operator に ユーティリティー機能k8sutil.GetWatchNamespace を使用して実行できます。