11.7. Operator SDK CLI リファレンス
以下では、Operator SDK CLI コマンドおよびそれらの構文について説明します。
$ operator-sdk <command> [<subcommand>] [<argument>] [<flags>]
11.7.1. build
operator-sdk build
コマンドはコードをコンパイルし、実行可能プロジェクトをビルドします。build
が完了すると、イメージは docker
でローカルにビルドされます。これは次にリモートレジストリーにプッシュされる必要があります。
引数 | 説明 |
---|---|
|
ビルトされるコンテナーイメージ (例: |
フラグ | 説明 |
---|---|
| テストバイナリーをイメージに追加することにより、クラスター内でのテストを有効にします。 |
|
テスト用の namespace を使用したリソースマニフェストのパス。デフォルト: |
|
テストの場所。デフォルト: |
| 使用方法についてのヘルプの出力。 |
--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 コマンドをより迅速に、より容易に実行できるようにシェル補完を生成します。
サブコマンド | 説明 |
---|---|
| bash 補完を生成します。 |
| zsh 補完を生成します。 |
フラグ | 説明 |
---|---|
| 使用方法についてのヘルプの出力。 |
出力例
$ 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) の出力を行います。
フラグ | 説明 |
---|---|
|
|
出力例
$ 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
コマンドは特定のジェネレーターを起動して、必要に応じてコードを生成します。
サブコマンド | 説明 |
---|---|
|
すべての CRD API の Kubernetes code-generators を |
このコマンドは、カスタムリソースの 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>
に書き込みます。
フラグ | 説明 |
---|---|
| CSV マニフェストのセマンティックバージョン。必須。 |
| 新規バージョンのベースとして使用する CSV マニフェストのセマンティックバージョン。 |
|
CSV 設定ファイルへのパス。デフォルト: |
|
最新の 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>
に基づいてデフォルトのプロジェクトディレクトリーのレイアウトの生成 (または スキャフォールディング) を実行します。
引数 | 説明 |
---|---|
| 新規プロジェクトの名前。 |
フラグ | 説明 |
---|---|
|
|
|
新規プロジェクトが使用する依存関係マネージャー。 |
|
Ansible Playbook のスケルトンを生成します。 |
|
生成される Go ファイルのヘッダーを含むファイルへのパスです。 |
|
既存の Helm チャートで Helm Operator を初期化します。 |
| 要求される Helm チャートのチャートリポジトリー URL。 |
| Helm チャートの特定バージョン。(デフォルト: latest version) |
| 使用方法およびヘルプの出力。 |
|
CRD |
| ディレクトリーを Git リポジトリーとして実行しません。 |
|
初期化する Operator のタイプ: |
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 プロジェクトのルートディレクトリーから実行される必要があります。
サブコマンド | 説明 |
---|---|
|
新規カスタムリソース (CR) の新規 API 定義を |
|
新規コントローラーを |
|
CRD および CR ファイルを追加します。
|
フラグ | 説明 |
---|---|
|
|
|
CRD |
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 テストをローカルで実行します。
引数 | 説明 |
---|---|
|
e2e テストファイルの場所 (例: |
フラグ | 説明 |
---|---|
|
クラスターの |
|
グローバルリソースのマニフェストへのパス。デフォルト: |
|
テスト別の namespace を使用したリソースのマニフェストへのパス。デフォルト: |
|
空ではない場合、テストを実行する単一の namespace (例: |
|
|
|
クラスターのイメージとしてではなく、 |
| テストリソースの作成を無効にします。 |
| namespace を使用したマニフェストで指定されたイメージとは異なる Operator イメージを使用します。 |
| 使用方法についてのヘルプの出力。 |
出力例
$ 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 をローカルマシンで起動します。
引数 | 説明 |
---|---|
|
Kubernetes 設定ファイルへのファイルパス。デフォルト: |
|
Operator が変更の有無を監視する namespace。デフォルト: |
|
ローカル Operator が必要とする可能性のあるフラグ。例: |
| 使用方法についてのヘルプの出力。 |
出力例
$ 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
を使用して実行できます。