5.6. Helm ベースの Operator
5.6.1. Helm ベースの Operator の Operator SDK の使用を開始する
Operator プロジェクトを生成するための Operator SDK には、Go コードを作成せずに Kubernetes リソースを統一されたアプリケーションとしてデプロイするために、既存の Helm チャートを使用するオプションがあります。
Operator SDK によって提供されるツールおよびライブラリーを使用して Helm ベースの Operator をセットアップし、実行するための基本を示すには、Operator 開発者は Helm ベースの Nginx Operator のサンプルをビルドし、これをクラスターへデプロイすることができます。
5.6.1.1. 前提条件
- Operator SDK CLI がインストールされていること。
-
OpenShift CLI (
oc) v4.8+ がインストールされていること。 -
cluster-adminパーミッションを持つアカウントを使用して、ocで OpenShift Container Platform 4.8 クラスターにログインしていること。 - クラスターがイメージをプルできるようにするには、イメージをプッシュするリポジトリーを public として設定するか、またはイメージプルシークレットを設定する必要があります。
5.6.1.2. Helm ベースの Operator の作成とデプロイ
Operator SDK を使用して Nginx の単純な Helm ベースの Operator をビルドし、デプロイできます。
手順
プロジェクトを作成します。
プロジェクトディレクトリーを作成します。
$ mkdir nginx-operator
プロジェクトディレクトリーに移動します。
$ cd nginx-operator
helmプラグインを指定してoperator-sdk initコマンドを実行し、プロジェクトを初期化します。$ operator-sdk init \ --plugins=helm
API を作成します。
単純な Nginx API を作成します。
$ operator-sdk create api \ --group demo \ --version v1 \ --kind Nginxこの API は、
helm createコマンドでビルトインの Helm チャートボイラープレートを使用します。Operator イメージをビルドし、プッシュします。
デフォルトの
Makefileターゲットを使用して Operator をビルドし、プッシュします。プッシュ先となるレジストリーを使用するイメージのプル仕様を使用してIMGを設定します。$ make docker-build docker-push IMG=<registry>/<user>/<image_name>:<tag>
Operator を実行します。
CRD をインストールします。
$ make install
プロジェクトをクラスターにデプロイします。
IMGをプッシュしたイメージに設定します。$ make deploy IMG=<registry>/<user>/<image_name>:<tag>
SCC(Security Context Constraints) を追加します。
Nginx サービスアカウントには、OpenShift Container Platform で実行する特権アクセスが必要です。以下の SCC を
nginx-samplePod のサービスアカウントに追加します。$ oc adm policy add-scc-to-user \ anyuid system:serviceaccount:nginx-operator-system:nginx-sampleサンプルカスタムリソース (CR) を作成します。
サンプル CR を作成します。
$ oc apply -f config/samples/demo_v1_nginx.yaml \ -n nginx-operator-systemOperator を調整する CR を確認します。
$ oc logs deployment.apps/nginx-operator-controller-manager \ -c manager \ -n nginx-operator-system
クリーンアップします。
以下のコマンドを実行して、この手順の一部として作成されたリソースをクリーンアップします。
$ make undeploy
5.6.1.3. 次のステップ
- Helm ベースの Operator のビルドに関する詳細な手順は、Helm ベースの Operator の Operator SDK チュートリアル を参照してください。
5.6.2. Helm ベースの Operator の Operator SDK チュートリアル
Operator 開発者は、Operator SDK での Helm のサポートを利用して、Helm ベースの Nginx Operator のサンプルをビルドし、そのライフサイクルを管理することができます。このチュートリアルでは、以下のプロセスについて説明します。
- Nginx デプロイメントの作成
-
デプロイメントのサイズが、
Nginxカスタムリソース (CR) 仕様で指定されたものと同じであることを確認します。 -
ステータスライターを使用して、
NginxCR ステータスをnginxPod の名前で更新します。
このプロセスは、Operator Framework の 2 つの重要な設定要素を使用して実行されます。
- Operator SDK
-
operator-sdkCLI ツールおよびcontroller-runtimeライブラリー API - Operator Lifecycle Manager (OLM)
- クラスター上の Operator のインストール、アップグレード、ロールベースのアクセス制御 (RBAC)
このチュートリアルでは、Helm ベースの Operator の Operator SDK の使用を開始する よりも詳細に説明します。
5.6.2.1. 前提条件
- Operator SDK CLI がインストールされていること。
-
OpenShift CLI (
oc) v4.8+ がインストールされていること。 -
cluster-adminパーミッションを持つアカウントを使用して、ocで OpenShift Container Platform 4.8 クラスターにログインしていること。 - クラスターがイメージをプルできるようにするには、イメージをプッシュするリポジトリーを public として設定するか、またはイメージプルシークレットを設定する必要があります。
5.6.2.2. プロジェクトの作成
Operator SDK CLI を使用して nginx-operator というプロジェクトを作成します。
手順
プロジェクトのディレクトリーを作成します。
$ mkdir -p $HOME/projects/nginx-operator
ディレクトリーに切り替えます。
$ cd $HOME/projects/nginx-operator
helmプラグインを指定してoperator-sdk initコマンドを実行し、プロジェクトを初期化します。$ operator-sdk init \ --plugins=helm \ --domain=example.com \ --group=demo \ --version=v1 \ --kind=Nginx注記デフォルトで、
helmプラグインは、ボイラープレート Helm チャートを使用してプロジェクトを初期化します。--helm-chartフラグなどの追加のフラグを使用すると、既存の Helm チャートを使用してプロジェクトを初期化できます。initコマンドは、API バージョンexample.com/v1および KindNginxでのリソースの監視に特化したnginx-operatorプロジェクトを作成します。-
Helm ベースのプロジェクトの場合、
initコマンドは、チャートのデフォルトマニフェストによってデプロイされるリソースに基づいてconfig/rbac/role.yamlファイルに RBAC ルールを生成します。このファイルで生成されるルールが Operator のパーミッション要件を満たしていることを確認します。
5.6.2.2.1. 既存の Helm チャート
ボイラープレート Helm チャートでプロジェクトを作成する代わりに、以下のフラグを使用してローカルファイルシステムまたはリモートチャートリポジトリーから既存のチャートを使用することもできます。
-
--helm-chart -
--helm-chart-repo -
--helm-chart-version
--helm-chart フラグを指定すると、--group、--version、および --kind フラグは任意となります。未設定のままにすると、以下のデフォルト値が使用されます。
| フラグ | 値 |
|---|---|
|
|
|
|
|
|
|
|
|
|
| 指定されたチャートからの推定値。 |
--helm-chart フラグがローカルチャートアーカイブ (例: example-chart-1.2.0.tgz) またはディレクトリーを指定する場合、チャートは検証され、プロジェクトに展開されるかコピーされます。そうでない場合は、Operator SDK はリモートリポジトリーからチャートの取得を試みます。
--helm-chart-repo フラグでカスタムリポジトリーの URL が指定されない場合には、以下のチャート参照形式がサポートされます。
| フォーマット | 説明 |
|---|---|
|
|
|
|
| 指定された URL で Helm チャートアーカイブを取得します。 |
カスタムリポジトリーの URL が --helm-chart-repo によって指定される場合、以下のチャート参照形式がサポートされます。
| フォーマット | 説明 |
|---|---|
|
|
|
--helm-chart-version フラグが設定されていない場合は、Operator SDK は Helm チャートの利用可能な最新バージョンを取得します。フラグが設定されている場合は、指定したバージョンを取得します。--helm-chart フラグで指定したチャートが特定のバージョンを参照する場合 (例: ローカルパスまたは URL の場合)、オプションの --helm-chart-version フラグは使用されません。
詳細と例を確認するには、以下のコマンドを実行します。
$ operator-sdk init --plugins helm --help
5.6.2.2.2. PROJECT ファイル
operator-sdk init コマンドで生成されるファイルの 1 つに、Kubebuilder の PROJECT ファイルがあります。プロジェクトルートから実行される後続の operator-sdk コマンドおよび help 出力は、このファイルを読み取り、プロジェクトタイプが Helm であることを認識しています。以下に例を示します。
domain: example.com layout: helm.sdk.operatorframework.io/v1 projectName: helm-operator resources: - group: demo kind: Nginx version: v1 version: 3
5.6.2.3. Operator ロジックについて
この例では、nginx-operator はそれぞれの Nginx カスタムリソース (CR) について以下の調整 (reconciliation) ロジックを実行します。
- Nginx デプロイメントを作成します (ない場合)。
- Nginx サービスを作成します (ない場合)。
- Nginx Ingress を作成します (有効にされているが存在しない場合)。
-
デプロイメント、サービス、およびオプションの Ingress が
NginxCR で指定される必要な設定 (レプリカ数、イメージ、サービスタイプなど) に一致することを確認します。
デフォルトで、nginx-operator プロジェクトは、watches.yaml ファイルに示されるように Nginx リソースイベントを監視し、指定されたチャートを使用して Helm リリースを実行します。
# Use the 'create api' subcommand to add watches to this file. - group: demo version: v1 kind: Nginx chart: helm-charts/nginx # +kubebuilder:scaffold:watch
5.6.2.3.1. Helm チャートのサンプル
Helm Operator プロジェクトの作成時に、Operator SDK は、単純な Nginx リリース用のテンプレートセットが含まれる Helm チャートのサンプルを作成します。
この例では、Helm チャート開発者がリリースについての役立つ情報を伝えるために使用する NOTES.txt テンプレートと共に、デプロイメント、サービス、および Ingress リソース用にテンプレートを利用できます。
Helm チャートの使用に慣れていない場合は、Helm 開発者用のドキュメント を参照してください。
5.6.2.3.2. カスタムリソース仕様の変更
Helm は 値 (value) という概念を使用して、values.yaml ファイルに定義される Helm チャートのデフォルトをカスタマイズします。
カスタムリソース (CR) 仕様に必要な値を設定し、これらのデフォルトを上書きすることができます。例としてレプリカ数を使用することができます。
手順
helm-charts/nginx/values.yamlファイルには、デフォルトでreplicaCountという名前の値が1に設定されています。デプロイメントに 2 つの Nginx インスタンスを設定するには、CR 仕様にreplicaCount: 2が含まれる必要があります。config/samples/demo_v1_nginx.yamlファイルを編集し、replicaCount: 2を設定します。apiVersion: demo.example.com/v1 kind: Nginx metadata: name: nginx-sample ... spec: ... replicaCount: 2
同様に、デフォルトのサービスポートは
80に設定されます。8080を使用するには、config/samples/demo_v1_nginx.yamlファイルを編集し、spec.port: 8080を設定します。これにより、サービスポートの上書きが追加されます。apiVersion: demo.example.com/v1 kind: Nginx metadata: name: nginx-sample spec: replicaCount: 2 service: port: 8080
Helm Operator は、helm install -f ./overrides.yaml コマンドのように、仕様全体を values ファイルの内容のように適用します。
5.6.2.4. Operator の実行
Operator SDK CLI を使用して Operator をビルドし、実行する方法は 3 つあります。
- クラスター外で Go プログラムとしてローカルに実行します。
- クラスター上のデプロイメントとして実行します。
- Operator をバンドルし、Operator Lifecycle Manager (OLM) を使用してクラスター上にデプロイします。
5.6.2.4.1. クラスター外でローカルに実行する。
Operator プロジェクトをクラスター外の Go プログラムとして実行できます。これは、デプロイメントとテストを迅速化するという開発目的において便利です。
手順
以下のコマンドを実行して、
~/.kube/configファイルに設定されたクラスターにカスタムリソース定義 (CRD) をインストールし、Operator をローカルで実行します。$ make install run
出力例
... {"level":"info","ts":1612652419.9289865,"logger":"controller-runtime.metrics","msg":"metrics server is starting to listen","addr":":8080"} {"level":"info","ts":1612652419.9296563,"logger":"helm.controller","msg":"Watching resource","apiVersion":"demo.example.com/v1","kind":"Nginx","namespace":"","reconcilePeriod":"1m0s"} {"level":"info","ts":1612652419.929983,"logger":"controller-runtime.manager","msg":"starting metrics server","path":"/metrics"} {"level":"info","ts":1612652419.930015,"logger":"controller-runtime.manager.controller.nginx-controller","msg":"Starting EventSource","source":"kind source: demo.example.com/v1, Kind=Nginx"} {"level":"info","ts":1612652420.2307851,"logger":"controller-runtime.manager.controller.nginx-controller","msg":"Starting Controller"} {"level":"info","ts":1612652420.2309358,"logger":"controller-runtime.manager.controller.nginx-controller","msg":"Starting workers","worker count":8}
5.6.2.4.2. クラスター上でのデプロイメントとしての実行
Operator プロジェクトは、クラスター上でのデプロイメントとして実行することができます。
手順
以下の
makeコマンドを実行して Operator イメージをビルドし、プッシュします。以下の手順のIMG引数を変更して、アクセス可能なリポジトリーを参照します。Quay.io などのリポジトリーサイトにコンテナーを保存するためのアカウントを取得できます。イメージをビルドします。
$ make docker-build IMG=<registry>/<user>/<image_name>:<tag>
注記Operator の SDK によって生成される Dockerfile は、
go buildについてGOARCH=amd64を明示的に参照します。これは、AMD64 アーキテクチャー以外の場合はGOARCH=$TARGETARCHに修正できます。Docker は、-platformで指定された値に環境変数を自動的に設定します。Buildah では、そのために-build-argを使用する必要があります。詳細は、Multiple Architectures を参照してください。イメージをリポジトリーにプッシュします。
$ make docker-push IMG=<registry>/<user>/<image_name>:<tag>
注記両方のコマンドのイメージの名前とタグ (例:
IMG=<registry>/<user>/<image_name>:<tag>) を Makefile に設定することもできます。IMG ?= controller:latestの値を変更して、デフォルトのイメージ名を設定します。
以下のコマンドを実行して Operator をデプロイします。
$ make deploy IMG=<registry>/<user>/<image_name>:<tag>
デフォルトで、このコマンドは
<project_name>-systemの形式で Operator プロジェクトの名前で namespace を作成し、デプロイメントに使用します。このコマンドは、config/rbacから RBAC マニフェストもインストールします。Operator が実行されていることを確認します。
$ oc get deployment -n <project_name>-system
出力例
NAME READY UP-TO-DATE AVAILABLE AGE <project_name>-controller-manager 1/1 1 1 8m
5.6.2.4.3. Operator のバンドルおよび Operator Lifecycle Manager を使用したデプロイ
5.6.2.4.3.1. Operator のバンドル
Operator Bundle Format は、Operator SDK および Operator Lifecycle Manager (OLM) のデフォルトパッケージ方法です。Operator SDK を使用して OLM に対して Operator を準備し、バンドルイメージをとして Operator プロジェクトをビルドしてプッシュできます。
前提条件
- 開発ワークステーションに Operator SDK CLI がインストールされていること。
-
OpenShift CLI (
oc) v4.8+ がインストールされていること。 - Operator プロジェクトが Operator SDK を使用して初期化されていること。
手順
以下の
makeコマンドを Operator プロジェクトディレクトリーで実行し、Operator イメージをビルドし、プッシュします。以下の手順のIMG引数を変更して、アクセス可能なリポジトリーを参照します。Quay.io などのリポジトリーサイトにコンテナーを保存するためのアカウントを取得できます。イメージをビルドします。
$ make docker-build IMG=<registry>/<user>/<operator_image_name>:<tag>
注記Operator の SDK によって生成される Dockerfile は、
go buildについてGOARCH=amd64を明示的に参照します。これは、AMD64 アーキテクチャー以外の場合はGOARCH=$TARGETARCHに修正できます。Docker は、-platformで指定された値に環境変数を自動的に設定します。Buildah では、そのために-build-argを使用する必要があります。詳細は、Multiple Architectures を参照してください。イメージをリポジトリーにプッシュします。
$ make docker-push IMG=<registry>/<user>/<operator_image_name>:<tag>
Operator SDK
generate bundleおよびbundle validateのサブコマンドを含む複数のコマンドを呼び出すmake bundleコマンドを実行し、Operator バンドルマニフェストを作成します。$ make bundle IMG=<registry>/<user>/<operator_image_name>:<tag>
Operator のバンドルマニフェストは、アプリケーションを表示し、作成し、管理する方法を説明します。
make bundleコマンドは、以下のファイルおよびディレクトリーを Operator プロジェクトに作成します。-
ClusterServiceVersionオブジェクトを含むbundle/manifestsという名前のバンドルマニフェストディレクトリー -
bundle/metadataという名前のバンドルメタデータディレクトリー -
config/crdディレクトリー内のすべてのカスタムリソース定義 (CRD) -
Dockerfile
bundle.Dockerfile
続いて、これらのファイルは
operator-sdk bundle validateを使用して自動的に検証され、ディスク上のバンドル表現が正しいことを確認します。-
以下のコマンドを実行し、バンドルイメージをビルドしてプッシュします。OLM は、1 つ以上のバンドルイメージを参照するインデックスイメージを使用して Operator バンドルを使用します。
バンドルイメージをビルドします。イメージをプッシュしようとするレジストリー、ユーザー namespace、およびイメージタグの詳細で
BUNDLE_IMGを設定します。$ make bundle-build BUNDLE_IMG=<registry>/<user>/<bundle_image_name>:<tag>
バンドルイメージをプッシュします。
$ docker push <registry>/<user>/<bundle_image_name>:<tag>
5.6.2.4.3.2. Operator Lifecycle Manager を使用した Operator のデプロイ
Operator Lifecycle Manager (OLM) は、Kubernetes クラスターで Operator (およびそれらの関連サービス) をインストールし、更新し、ライフサイクルを管理するのに役立ちます。OLM はデフォルトで OpenShift Container Platform にインストールされ、Kubernetes 拡張として実行されるため、追加のツールなしにすべての Operator のライフサイクル管理機能に Web コンソールおよび OpenShift CLI (oc) を使用できます。
Operator Bundle Format は、Operator SDK および OLM のデフォルトパッケージ方法です。Operator SDK を使用して OLM でバンドルイメージを迅速に実行し、適切に実行されるようにできます。
前提条件
- 開発ワークステーションに Operator SDK CLI がインストールされていること。
- ビルドされ、レジストリーにプッシュされる Operator バンドルイメージ。
-
(OpenShift Container Platform 4.8 など、
apiextensions.k8s.io/v1CRD を使用する場合は v1.16.0 以降の) Kubernetes ベースのクラスターに OLM がインストールされていること。 -
cluster-adminパーミッションのあるアカウントを使用してocでクラスターへログインしていること。
手順
以下のコマンドを入力してクラスターで Operator を実行します。
$ operator-sdk run bundle \ [-n <namespace>] \1 <registry>/<user>/<bundle_image_name>:<tag>- 1
- デフォルトで、このコマンドは
~/.kube/configファイルの現在アクティブなプロジェクトに Operator をインストールします。-nフラグを追加して、インストールに異なる namespace スコープを設定できます。
このコマンドにより、以下のアクションが行われます。
- バンドルイメージをインジェクトしてインデックスイメージを作成します。インデックスイメージは不透明で一時的なものですが、バンドルを実稼働環境でカタログに追加する方法を正確に反映します。
- 新規インデックスイメージを参照するカタログソースを作成します。これにより、OperatorHub が Operator を検出できるようになります。
-
OperatorGroup、Subscription、InstallPlan、および RBAC を含むその他の必要なオブジェクトすべてを作成して、Operator をクラスターにデプロイします。
5.6.2.5. カスタムリソースの作成
Operator のインストール後に、Operator によってクラスターに提供されるカスタムリソース (CR) を作成して、これをテストできます。
前提条件
-
クラスターにインストールされている
NginxCR を提供する Nginx Operator の例
手順
Operator がインストールされている namespace へ変更します。たとえば、
make deployコマンドを使用して Operator をデプロイした場合は、以下のようになります。$ oc project nginx-operator-system
config/samples/demo_v1_nginx.yamlでNginxCR マニフェストのサンプルを編集し、以下の仕様が含まれるようにします。apiVersion: demo.example.com/v1 kind: Nginx metadata: name: nginx-sample ... spec: ... replicaCount: 3
Nginx サービスアカウントには、OpenShift Container Platform で実行する特権アクセスが必要です。以下の SCC(Security Context Constraints) を
nginx-samplePod のサービスアカウントに追加します。$ oc adm policy add-scc-to-user \ anyuid system:serviceaccount:nginx-operator-system:nginx-sampleCR を作成します。
$ oc apply -f config/samples/demo_v1_nginx.yaml
NginxOperator が、正しいサイズで CR サンプルのデプロイメントを作成することを確認します。$ oc get deployments
出力例
NAME READY UP-TO-DATE AVAILABLE AGE nginx-operator-controller-manager 1/1 1 1 8m nginx-sample 3/3 3 3 1m
ステータスが Nginx Pod 名で更新されていることを確認するために、Pod および CR ステータスを確認します。
Pod を確認します。
$ oc get pods
出力例
NAME READY STATUS RESTARTS AGE nginx-sample-6fd7c98d8-7dqdr 1/1 Running 0 1m nginx-sample-6fd7c98d8-g5k7v 1/1 Running 0 1m nginx-sample-6fd7c98d8-m7vn7 1/1 Running 0 1m
CR ステータスを確認します。
$ oc get nginx/nginx-sample -o yaml
出力例
apiVersion: demo.example.com/v1 kind: Nginx metadata: ... name: nginx-sample ... spec: replicaCount: 3 status: nodes: - nginx-sample-6fd7c98d8-7dqdr - nginx-sample-6fd7c98d8-g5k7v - nginx-sample-6fd7c98d8-m7vn7
デプロイメントサイズを更新します。
config/samples/demo_v1_nginx.yamlファイルを更新して、NginxCR のspec.sizeフィールドを3から5に変更します。$ oc patch nginx nginx-sample \ -p '{"spec":{"replicaCount": 5}}' \ --type=mergeOperator がデプロイメントサイズを変更することを確認します。
$ oc get deployments
出力例
NAME READY UP-TO-DATE AVAILABLE AGE nginx-operator-controller-manager 1/1 1 1 10m nginx-sample 5/5 5 5 3m
このチュートリアルの一環として作成したリソースをクリーンアップします。
Operator のテストに
make deployコマンドを使用した場合は、以下のコマンドを実行します。$ make undeploy
Operator のテストに
operator-sdk run bundleコマンドを使用した場合は、以下のコマンドを実行します。$ operator-sdk cleanup <project_name>
5.6.2.6. 関連情報
- Operator SDK によって作成されるディレクトリー構造の詳細は、Helm ベースの Operator のプロジェクトレイアウト を参照してください。
5.6.3. Helm ベースの Operator のプロジェクトレイアウト
operator-sdk CLI は、各 Operator プロジェクトに多数のパッケージおよびファイルを生成、または スキャフォールディング することができます。
5.6.3.1. Helm ベースのプロジェクトレイアウト
operator-sdk init --plugins helm コマンドを使用して生成される Helm ベースの Operator プロジェクトには、以下のディレクトリーおよびファイルが含まれます。
| ファイル/フォルダー | 目的 |
|---|---|
|
| Kubernetes クラスターへの Operator のデプロイに使用する Kustomize マニフェスト。 |
|
|
|
|
|
|
|
| group/version/kind (GVK) および Helm チャートの場所。 |
|
| プロジェクトの管理に使用するターゲット。 |
|
| Operator のメタデータ情報が含まれる YAML ファイル。 |
5.6.4. Operator SDK での Helm サポート
5.6.4.1. Helm チャート
Operator プロジェクトを生成するための Operator SDK のオプションの 1 つとして、Go コードを作成せずに既存の Helm チャートを使用して Kubernetes リソースを統一されたアプリケーションとしてデプロイするオプションがあります。このような Helm ベースの Operator では、変更はチャートの一部として生成される Kubernetes オブジェクトに適用されるため、ロールアウト時にロジックをほとんど必要としないステートレスなアプリケーションを使用する際に適しています。いくらか制限があるような印象を与えるかもしれませんが、Kubernetes コミュニティーがビルドする Helm チャートが急速に増加していることからも分かるように、この Operator は数多くのユーザーケースに対応することができます。
Operator の主な機能として、アプリケーションインスタンスを表すカスタムオブジェクトから読み取り、必要な状態を実行されている内容に一致させることができます。Helm ベース Operator の場合、オブジェクトの spec フィールドは、通常 Helm の values.yaml ファイルに記述される設定オプションの一覧です。Helm CLI を使用してフラグ付きの値を設定する代わりに (例: helm install -f values.yaml)、これらをカスタムリソース (CR) 内で表現することができます。 これにより、ネイティブ Kubernetes オブジェクトとして、適用される RBAC および監査証跡の利点を活用できます。
Tomcat という単純な CR の例:
apiVersion: apache.org/v1alpha1 kind: Tomcat metadata: name: example-app spec: replicaCount: 2
この場合の replicaCount 値、2 は以下が使用されるチャートのテンプレートに伝播されます。
{{ .Values.replicaCount }}
Operator のビルドおよびデプロイ後に、CR の新規インスタンスを作成してアプリケーションの新規インスタンスをデプロイしたり、 oc コマンドを使用してすべての環境で実行される異なるインスタンスを一覧表示したりすることができます。
$ oc get Tomcats --all-namespaces
Helm CLI を使用したり、Tiller をインストールしたりする必要はありません。Helm ベースの Operator はコードを Helm プロジェクトからインポートします。Operator のインスタンスを実行状態にし、カスタムリソース定義 (CRD) で CR を登録することのみが必要になります。これは RBAC に準拠するため、実稼働環境の変更を簡単に防止することができます。