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.9+ がインストールされていること。 -
cluster-admin
パーミッションを持つアカウントを使用して、oc
で OpenShift Container Platform 4.9 クラスターにログインしていること。 - クラスターがイメージをプルできるようにするには、イメージをプッシュするリポジトリーを 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-sample
Pod のサービスアカウントに追加します。$ 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-system
Operator を調整する CR を確認します。
$ oc logs deployment.apps/nginx-operator-controller-manager \ -c manager \ -n nginx-operator-system
CR を削除する
次のコマンドを実行して CR を削除します。
$ oc delete -f config/samples/cache_v1_memcached.yaml -n memcached-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) 仕様で指定されたものと同じであることを確認します。 -
ステータスライターを使用して、
Nginx
CR ステータスをnginx
Pod の名前で更新します。
このプロセスは、Operator Framework の 2 つの重要な設定要素を使用して実行されます。
- Operator SDK
-
operator-sdk
CLI ツールおよびcontroller-runtime
ライブラリー API - Operator Lifecycle Manager (OLM)
- クラスター上の Operator のインストール、アップグレード、ロールベースのアクセス制御 (RBAC)
このチュートリアルでは、Helm ベースの Operator の Operator SDK の使用を開始する よりも詳細に説明します。
5.6.2.1. 前提条件
- Operator SDK CLI がインストールされていること。
-
OpenShift CLI (
oc
) v4.9+ がインストールされていること。 -
cluster-admin
パーミッションを持つアカウントを使用して、oc
で OpenShift Container Platform 4.9 クラスターにログインしていること。 - クラスターがイメージをプルできるようにするには、イメージをプッシュするリポジトリーを 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 が
Nginx
CR で指定される必要な設定 (レプリカ数、イメージ、サービスタイプなど) に一致することを確認します。
デフォルトで、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 を開発できるようになりました。クラスター管理者は、Operator Lifecycle Manager (OLM) によって処理される環境変数のプロキシーサポートを設定します。Operator は以下の標準プロキシー変数の環境を検査し、値をオペランドに渡して、プロキシーされたクラスターをサポートする必要があります。
-
HTTP_PROXY
-
HTTPS_PROXY
-
NO_PROXY
このチュートリアルでは、HTTP_PROXY
を環境変数の例として使用します。
前提条件
- クラスター全体の egress プロキシーが有効にされているクラスター。
手順
watches.yaml
ファイルを編集し、overrideValues
フィールドを追加して、環境変数に基づいてオーバーライドを含めます。... - group: demo.example.com version: v1alpha1 kind: Nginx chart: helm-charts/nginx overrideValues: proxy.http: $HTTP_PROXY ...
helmcharts/nginx/values.yaml
ファイルにproxy.http
値を追加します。... proxy: http: "" https: "" no_proxy: ""
チャートテンプレートで変数の使用がサポートされているようにするには、
helm-charts/nginx/templates/deployment.yaml
ファイルのチャートテンプレートを編集して以下を追加します。containers: - name: {{ .Chart.Name }} securityContext: - toYaml {{ .Values.securityContext | nindent 12 }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}" imagePullPolicy: {{ .Values.image.pullPolicy }} env: - name: http_proxy value: "{{ .Values.proxy.http }}"
以下を
config/manager/manager.yaml
ファイルに追加して、Operator デプロイメントに環境変数を設定します。containers: - args: - --leader-elect - --leader-election-id=ansible-proxy-demo image: controller:latest name: manager env: - name: "HTTP_PROXY" value: "http_proxy_test"
5.6.2.5. Operator の実行
Operator SDK CLI を使用して Operator をビルドし、実行する方法は 3 つあります。
- クラスター外で Go プログラムとしてローカルに実行します。
- クラスター上のデプロイメントとして実行します。
- Operator をバンドルし、Operator Lifecycle Manager (OLM) を使用してクラスター上にデプロイします。
5.6.2.5.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.5.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.5.3. Operator のバンドルおよび Operator Lifecycle Manager を使用したデプロイ
5.6.2.5.3.1. Operator のバンドル
Operator Bundle Format は、Operator SDK および Operator Lifecycle Manager (OLM) のデフォルトパッケージ方法です。Operator SDK を使用して OLM に対して Operator を準備し、バンドルイメージをとして Operator プロジェクトをビルドしてプッシュできます。
前提条件
- 開発ワークステーションに Operator SDK CLI がインストールされていること。
-
OpenShift CLI (
oc
) v4.9+ がインストールされていること。 - 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.5.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.9 など、
apiextensions.k8s.io/v1
CRD を使用する場合は 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.6. カスタムリソースの作成
Operator のインストール後に、Operator によってクラスターに提供されるカスタムリソース (CR) を作成して、これをテストできます。
前提条件
-
クラスターにインストールされている
Nginx
CR を提供する Nginx Operator の例
手順
Operator がインストールされている namespace へ変更します。たとえば、
make deploy
コマンドを使用して Operator をデプロイした場合は、以下のようになります。$ oc project nginx-operator-system
config/samples/demo_v1_nginx.yaml
でNginx
CR マニフェストのサンプルを編集し、以下の仕様が含まれるようにします。apiVersion: demo.example.com/v1 kind: Nginx metadata: name: nginx-sample ... spec: ... replicaCount: 3
Nginx サービスアカウントには、OpenShift Container Platform で実行する特権アクセスが必要です。以下の SCC(Security Context Constraints) を
nginx-sample
Pod のサービスアカウントに追加します。$ oc adm policy add-scc-to-user \ anyuid system:serviceaccount:nginx-operator-system:nginx-sample
CR を作成します。
$ oc apply -f config/samples/demo_v1_nginx.yaml
Nginx
Operator が、正しいサイズで 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
ファイルを更新して、Nginx
CR のspec.size
フィールドを3
から5
に変更します。$ oc patch nginx nginx-sample \ -p '{"spec":{"replicaCount": 5}}' \ --type=merge
Operator がデプロイメントサイズを変更することを確認します。
$ 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.7. 関連情報
- Operator SDK によって作成されるディレクトリー構造の詳細は、Helm ベースの Operator のプロジェクトレイアウト を参照してください。
- クラスター全体の egress プロキシーが設定されている場合 に、クラスター管理者は Operator Lifecycle Manager(OLM) で実行される特定の Operator の プロキシー設定を上書きしたり、 カスタム CA 証明書を挿入したり できます。
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 に準拠するため、実稼働環境の変更を簡単に防止することができます。