5.5. Helm ベースの Operator
5.5.1. Helm ベースの Operator の Operator SDK の使用を開始する
Operator プロジェクトを生成するための Operator SDK には、Go コードを作成せずに Kubernetes リソースを統一されたアプリケーションとしてデプロイするために、既存の Helm チャートを使用するオプションがあります。
Operator SDK によって提供されるツールおよびライブラリーを使用して Helm ベースの Operator をセットアップし、実行するための基本を示すには、Operator 開発者は Helm ベースの Nginx Operator のサンプルをビルドし、これをクラスターへデプロイすることができます。
5.5.1.1. 前提条件
- Operator SDK CLI がインストールされていること。
-
OpenShift CLI (
oc
) v4.12 以降がインストールされている -
cluster-admin
パーミッションを持つアカウントを使用して、oc
で OpenShift Container Platform 4.12 クラスターにログインしている - クラスターがイメージをプルできるようにするには、イメージをプッシュするリポジトリーを public として設定するか、イメージプルシークレットを設定する必要があります。
5.5.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/demo_v1_nginx.yaml -n nginx-operator-system
クリーンアップします。
以下のコマンドを実行して、この手順の一部として作成されたリソースをクリーンアップします。
$ make undeploy
5.5.1.3. 次のステップ
- Helm ベースの Operator のビルドに関する詳細な手順は、Helm ベースの Operator の Operator SDK チュートリアル を参照してください。
5.5.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.5.2.1. 前提条件
- Operator SDK CLI がインストールされていること。
-
OpenShift CLI (
oc
) v4.12 以降がインストールされている -
cluster-admin
パーミッションを持つアカウントを使用して、oc
で OpenShift Container Platform 4.12 クラスターにログインしている - クラスターがイメージをプルできるようにするには、イメージをプッシュするリポジトリーを public として設定するか、イメージプルシークレットを設定する必要があります。
5.5.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.5.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.5.2.2.2. PROJECT ファイル
operator-sdk init
コマンドで生成されるファイルの 1 つに、Kubebuilder の PROJECT
ファイルがあります。プロジェクトルートから実行される後続の operator-sdk
コマンドおよび help
出力は、このファイルを読み取り、プロジェクトタイプが Helm であることを認識しています。以下に例を示します。
domain: example.com layout: - helm.sdk.operatorframework.io/v1 plugins: manifests.sdk.operatorframework.io/v2: {} scorecard.sdk.operatorframework.io/v2: {} sdk.x-openshift.io/v1: {} projectName: nginx-operator resources: - api: crdVersion: v1 namespaced: true domain: example.com group: demo kind: Nginx version: v1 version: "3"
5.5.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.5.2.3.1. Helm チャートのサンプル
Helm Operator プロジェクトの作成時に、Operator SDK は、単純な Nginx リリース用のテンプレートセットが含まれる Helm チャートのサンプルを作成します。
この例では、Helm チャート開発者がリリースに関する役立つ情報を伝えるために使用する NOTES.txt
テンプレートと共に、デプロイメント、サービス、および Ingress リソース用にテンプレートを利用できます。
Helm チャートの使用に慣れていない場合は、Helm 開発者用のドキュメント を参照してください。
5.5.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.5.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 ...
helm-charts/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.5.2.5. Operator の実行
Operator SDK CLI を使用して Operator をビルドし、実行する方法は 3 つあります。
- クラスター外で Go プログラムとしてローカルに実行します。
- クラスター上のデプロイメントとして実行します。
- Operator をバンドルし、Operator Lifecycle Manager (OLM) を使用してクラスター上にデプロイします。
5.5.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.5.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.5.2.5.3. Operator のバンドルおよび Operator Lifecycle Manager を使用したデプロイ
5.5.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.12 以降がインストールされている - 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.5.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.12 など、
apiextensions.k8s.io/v1
CRD を使用する場合は v1.16.0 以降の) Kubernetes ベースのクラスターに OLM がインストールされていること。 -
cluster-admin
パーミッションのあるアカウントを使用してoc
でクラスターへログインしていること。
手順
以下のコマンドを入力してクラスターで Operator を実行します。
$ operator-sdk run bundle \1 -n <namespace> \2 <registry>/<user>/<bundle_image_name>:<tag> 3
- 1
run bundle
コマンドは、有効なファイルベースのカタログを作成し、OLM を使用して Operator バンドルをクラスターにインストールします。- 2
- オプション: デフォルトで、このコマンドは
~/.kube/config
ファイルの現在アクティブなプロジェクトに Operator をインストールします。-n
フラグを追加して、インストールに異なる namespace スコープを設定できます。 - 3
- イメージを指定しない場合、コマンドは
quay.io/operator-framework/opm:latest
をデフォルトのインデックスイメージとして使用します。イメージを指定した場合は、コマンドはバンドルイメージ自体をインデックスイメージとして使用します。
重要OpenShift Container Platform 4.11 の時点で、Operator カタログに関して、
run bundle
コマンドはデフォルトでファイルベースのカタログ形式をサポートします。Operator カタログに関して、非推奨の SQLite データベース形式は引き続きサポートされますが、今後のリリースで削除される予定です。Operator の作成者はワークフローをファイルベースのカタログ形式に移行することが推奨されます。このコマンドにより、以下のアクションが行われます。
- バンドルイメージをインジェクトしてインデックスイメージを作成します。インデックスイメージは不透明で一時的なものですが、バンドルを実稼働環境でカタログに追加する方法を正確に反映します。
- 新規インデックスイメージを参照するカタログソースを作成します。これにより、OperatorHub が Operator を検出できるようになります。
-
OperatorGroup
、Subscription
、InstallPlan
、および RBAC を含むその他の必要なリソースすべてを作成して、Operator をクラスターにデプロイします。
5.5.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
次のコマンドを実行して CR を削除します。
$ oc delete -f config/samples/demo_v1_nginx.yaml
このチュートリアルの一環として作成したリソースをクリーンアップします。
Operator のテストに
make deploy
コマンドを使用した場合は、以下のコマンドを実行します。$ make undeploy
Operator のテストに
operator-sdk run bundle
コマンドを使用した場合は、以下のコマンドを実行します。$ operator-sdk cleanup <project_name>
5.5.2.7. 関連情報
- Operator SDK によって作成されるディレクトリー構造の詳細は、Helm ベースの Operator のプロジェクトレイアウト を参照してください。
- クラスター全体の egress プロキシーが設定されている場合、クラスター管理者は Operator Lifecycle Manager (OLM) で実行されている特定の Operator に対して プロキシー設定のオーバーライドやカスタム CA 証明書の注入 を実行できます。
5.5.3. Helm ベースの Operator のプロジェクトレイアウト
operator-sdk
CLI は、各 Operator プロジェクトに多数のパッケージおよびファイルを生成、または スキャフォールディング することができます。
5.5.3.1. Helm ベースのプロジェクトレイアウト
operator-sdk init --plugins helm
コマンドを使用して生成される Helm ベースの Operator プロジェクトには、以下のディレクトリーおよびファイルが含まれます。
ファイル/フォルダー | 目的 |
---|---|
| Kubernetes クラスターへの Operator のデプロイに使用する Kustomize マニフェスト。 |
|
|
|
|
| group/version/kind (GVK) および Helm チャートの場所。 |
| プロジェクトの管理に使用するターゲット。 |
| Operator のメタデータ情報が含まれる YAML ファイル。 |
5.5.4. 新しい Operator SDK バージョンの Helm ベースのプロジェクトの更新
OpenShift Container Platform 4.12 は Operator SDK 1.25.4 をサポートします。ワークステーションに 1.28.0 CLI がすでにインストールされている場合は、最新バージョンをインストール して CLI を 1.31.0 に更新できます。
ただし、既存の Operator プロジェクトが Operator SDK 1.25.4 との互換性を維持するには、1.22.2 以降に導入された関連する重大な変更に対し、更新手順を実行する必要があります。アップグレードの手順は、以前は 1.22.2 で作成または維持されている Operator プロジェクトのいずれかで手動で実行する必要があります。
5.5.4.1. Operator SDK 1.25.4 の Helm ベースの Operator プロジェクトの更新
次の手順では、1.25.4 との互換性を確保するため、既存の Helm ベースの Operator プロジェクトを更新します。
前提条件
- Operator SDK 1.25.4 がインストールされている
- Operator SDK 1.22.2 で作成または保守されている Operator プロジェクト
手順
config/default/manager_auth_proxy_patch.yaml
ファイルに以下の変更を加えます。apiVersion: apps/v1 kind: Deployment metadata: name: controller-manager namespace: system spec: template: spec: containers: - name: kube-rbac-proxy image: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.12 1 args: - "--secure-listen-address=0.0.0.0:8443" - "--upstream=http://127.0.0.1:8080/" - "--logtostderr=true" - "--v=0" ...
- 1
- タグバージョンを
v4.11
からv4.12
に更新します。
Makefile
に以下の変更を加えます。マルチアーキテクチャービルドサポートを有効にするには、
docker-buildx
ターゲットをプロジェクトのMakefile
に追加します。Makefile
の例# PLATFORMS defines the target platforms for the manager image be build to provide support to multiple # architectures. (i.e. make docker-buildx IMG=myregistry/mypoperator:0.0.1). To use this option you need to: # - able to use docker buildx . More info: https://docs.docker.com/build/buildx/ # - have enable BuildKit, More info: https://docs.docker.com/develop/develop-images/build_enhancements/ # - be able to push the image for your registry (i.e. if you do not inform a valid value via IMG=<myregistry/image:<tag>> than the export will fail) # To properly provided solutions that supports more than one platform you should use this option. PLATFORMS ?= linux/arm64,linux/amd64,linux/s390x,linux/ppc64le .PHONY: docker-buildx docker-buildx: test ## Build and push docker image for the manager for cross-platform support # copy existing Dockerfile and insert --platform=${BUILDPLATFORM} into Dockerfile.cross, and preserve the original Dockerfile sed -e '1 s/\(^FROM\)/FROM --platform=\$$\{BUILDPLATFORM\}/; t' -e ' 1,// s//FROM --platform=\$$\{BUILDPLATFORM\}/' Dockerfile > Dockerfile.cross - docker buildx create --name project-v3-builder docker buildx use project-v3-builder - docker buildx build --push --platform=$(PLATFORMS) --tag ${IMG} -f Dockerfile.cross - docker buildx rm project-v3-builder rm Dockerfile.cross
Operator プロジェクトで 64 ビットのアーキテクチャーのサポートを有効にするには、
Makefile
に以下の変更を加えます。古い
Makefile
OS := $(shell uname -s | tr '[:upper:]' '[:lower:]') ARCH := $(shell uname -m | sed 's/x86_64/amd64/')
新しい
Makefile
OS := $(shell uname -s | tr '[:upper:]' '[:lower:]') ARCH := $(shell uname -m | sed 's/x86_64/amd64/' | sed 's/aarch64/arm64/')
次の例に示すように、Kustomize のバージョンを
v4.5.5
に更新します。古い
Makefile
.PHONY: kustomize KUSTOMIZE = $(shell pwd)/bin/kustomize kustomize: ## Download kustomize locally if necessary. ifeq (,$(wildcard $(KUSTOMIZE))) ifeq (,$(shell which kustomize 2>/dev/null)) @{ \ set -e ;\ mkdir -p $(dir $(KUSTOMIZE)) ;\ curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v3.8.7/kustomize_v3.8.7_$(OS)_$(ARCH).tar.gz | \ tar xzf - -C bin/ ;\ } else
新しい
Makefile
.PHONY: kustomize KUSTOMIZE = $(shell pwd)/bin/kustomize kustomize: ## Download kustomize locally if necessary. ifeq (,$(wildcard $(KUSTOMIZE))) ifeq (,$(shell which kustomize 2>/dev/null)) @{ \ set -e ;\ mkdir -p $(dir $(KUSTOMIZE)) ;\ curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v4.5.5/kustomize_v4.5.5_$(OS)_$(ARCH).tar.gz | \ 1 tar xzf - -C bin/ ;\ } else
- 1
- バージョン
v3.8.7
をv4.5.5
に更新します。
重要Kustomize バージョン
4.0.0
では、go-getter
プラグインが削除され、以前のバージョンとの下位互換性がない重大な変更が導入されました。古いバージョンの Kustomize に依存する Operator プロジェクトは、新しいリリースでは機能しない可能性があります。Makefile
に変更を適用し、Operator を再構築するには、次のコマンドを入力します。$ make
次の例のとおり、Operator の Dockerfile 内のイメージタグを更新します。
Dockerfile の例
FROM registry.redhat.io/openshift4/ose-helm-operator:v4.12 1
- 1
- バージョンタグを
v4.12
に更新します。
次の例に示すように、
config/default/kustomizations.yaml
ファイルを更新します。kustomizations.yaml
ファイルの例# Adds namespace to all resources. namespace: memcached-operator-system # Value of this field is prepended to the # names of all resources, e.g. a deployment named # "wordpress" becomes "alices-wordpress". # Note that it should also match with the prefix (text before '-') of the namespace # field above. namePrefix: memcached-operator- # Labels to add to all resources and selectors. #labels: 1 #- includeSelectors: true 2 # pairs: # someName: someValue resources: 3 - ../crd - ../rbac - ../manager
5.5.4.2. 関連情報
5.5.5. Operator SDK での Helm サポート
5.5.5.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 に準拠するため、実稼働環境の変更を簡単に防止することができます。
5.5.6. Hybrid Helm Operator 向けの Operator SDK チュートリアル
Operator SDK における標準の Helm ベースの Operator サポートは、Operator の Operator 成熟度モデル で Auto Pilot 機能 (レベル V) に達した Go ベースおよび Ansible ベースの Operator サポートよりも機能が限定されています。
Hybrid Helm Operator は、Go API を使用して既存の Helm ベースのサポート機能を強化します。Helm と Go のこのハイブリッドアプローチでは、Operator SDK により、Operator の作成者は次のプロセスを使用できます。
- Helm と同じプロジェクトで Go API のデフォルト構造またはscaffoldを生成します。
-
Hybrid Helm Operator が提供するライブラリーを使用して、プロジェクトの
main.go
ファイルで Helm reconciler を設定します。
Hybrid Helm Operator は、テクノロジープレビュー機能のみとしてご利用いただけます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
このチュートリアルでは、Hybrid Helm Operator を使用して、次のプロセスを説明していきます。
-
Memcached
デプロイメントがない場合には、Helm チャートを使用して作成する -
デプロイメントのサイズが、
Memcached
カスタムリソース (CR) 仕様で指定されたものと同じであることを確認する -
Go API を使用して
MemcachedBackup
デプロイメントを作成する
5.5.6.1. 前提条件
- Operator SDK CLI がインストールされていること。
-
OpenShift CLI (
oc
) v4.12 以降がインストールされている -
cluster-admin
パーミッションを持つアカウントを使用して、oc
で OpenShift Container Platform 4.12 クラスターにログインしている - クラスターがイメージをプルできるようにするには、イメージをプッシュするリポジトリーを public として設定するか、イメージプルシークレットを設定する必要があります。
5.5.6.2. プロジェクトの作成
Operator SDK CLI を使用して memcached-operator
というプロジェクトを作成します。
手順
プロジェクトのディレクトリーを作成します。
$ mkdir -p $HOME/github.com/example/memcached-operator
ディレクトリーに切り替えます。
$ cd $HOME/github.com/example/memcached-operator
operator-sdk init
コマンドを実行してプロジェクトを初期化します。$ operator-sdk init \ --plugins=hybrid.helm.sdk.operatorframework.io \ --project-version="3" \ --domain my.domain \ --repo=github.com/example/memcached-operator
init
コマンドは、チャートのデフォルトのマニフェストでデプロイされるリソースをもとに、config/rbac/role.yaml
ファイルに RBAC ルールを生成します。config/rbac/role.yaml
ファイルで生成されたルールが、Operator のパーミッション要件を満たしていることを確認します。
関連情報
- この手順では、Helm API と Go API の両方と互換性のあるプロジェクト構造を作成します。プロジェクトディレクトリー構造の詳細は、プロジェクトレイアウトを参照してください。
5.5.6.3. Helm API の作成
Operator SDKCLI を使用して Helm API を作成します。
手順
以下のコマンドを実行して、グループ
cache
、バージョンv1
、および種類Memcached
を指定して Helm API を作成します。$ operator-sdk create api \ --plugins helm.sdk.operatorframework.io/v1 \ --group cache \ --version v1 \ --kind Memcached
この手順では、API バージョン v1
を使用して Memcached
リソースを監視し、定型的な Helm チャートをスキャフォールドするように Operator プロジェクトも設定します。Operator SDK によってスキャフォールドされた定型 Helm チャートからプロジェクトを作成する代わりに、ローカルファイルシステムまたはリモートチャートリポジトリーからの既存のチャートを使用することもできます。
既存または新規のチャートをもとに Helm API を作成する方法と例については、次のコマンドを実行してください。
$ operator-sdk create api --plugins helm.sdk.operatorframework.io/v1 --help
関連情報
5.5.6.3.1. Helm API の Operator ロジック
デフォルトでは、スキャフォールディングされた Operator プロジェクトは、watches.yaml
ファイルに示されているようにMemcached
リソースイベントを監視し、指定されたチャートを使用して Helm リリースを実行します。
例5.2 watches.yaml
ファイルの例
# Use the 'create api' subcommand to add watches to this file. - group: cache.my.domain version: v1 kind: Memcached chart: helm-charts/memcached #+kubebuilder:scaffold:watch
関連情報
- チャートを介した Helm Operator ロジックのカスタマイズに関する詳細なドキュメントは、Operator ロジックを参照してください。
5.5.6.3.2. 指定のライブラリー API を使用したカスタム Helm reconciler 設定
既存の Helm ベースの Operator の欠点は、ユーザーから抽象化されているため、Helm reconciler を設定できないことです。Helm ベースの Operator が既存の Helm チャートを再利用するシームレスアップグレード機能 (レベル II 以降) に到達する場合には、Go タイプと Helm Operator タイプのハイブリッドが付加価値をもたらします。
helm-operator-plugins
ライブラリーで提供される API を使用すると、Operator の作成者は以下の設定が可能です。
- クラスターの状態に基づいて値のマッピングをカスタマイズする
- reconciler のイベントレコーダーを設定して、特定のイベントでコードを実行する
- reconciler のロガーをカスタマイズする
-
Install
、Upgrade
、Uninstall
アノテーションを設定して Helm のアクションを、reconciler が監視するカスタムリソースにあるアノテーションを元に設定されるようにする -
Pre
フックとPost
フックで実行するように reconciler を設定する
reconciler に対する上記の設定は、main.go
ファイルで実行できます。
main.go
ファイルの例
// Operator's main.go // With the help of helpers provided in the library, the reconciler can be // configured here before starting the controller with this reconciler. reconciler := reconciler.New( reconciler.WithChart(*chart), reconciler.WithGroupVersionKind(gvk), ) if err := reconciler.SetupWithManager(mgr); err != nil { panic(fmt.Sprintf("unable to create reconciler: %s", err)) }
5.5.6.4. Go API の作成
Operator SDKCLI を使用して Go API を作成します。
手順
以下のコマンドを実行して、グループ
cache
、バージョンv1
、および種類MemcachedBackup
を指定して Go API を作成します。$ operator-sdk create api \ --group=cache \ --version v1 \ --kind MemcachedBackup \ --resource \ --controller \ --plugins=go/v3
プロンプトが表示されたら
y
を入力し、リソースとコントローラーの両方を作成します。$ Create Resource [y/n] y Create Controller [y/n] y
この手順では、MemcachedBackup
リソース API を api/v1/memcachedbackup_types.go
に生成し、コントローラーを controllers/memcachedbackup_controller.go
に生成します。
5.5.6.4.1. API の定義
MemcachedBackup
カスタムリソース (CR) の API を定義します。
デプロイする Memcached バックアップインスタンス (CR) の数を設定するMemcachedBackupSpec.Size
フィールドと、CR の Pod 名を格納する MemcachedBackupStatus.Nodes
フィールドがある MemcachedBackup
タイプを定義して、この Go API を表します。
Node
フィールドは、Status
フィールドの例を示すために使用されます。
手順
api/v1/memcachedbackup_types.go
ファイルの Go タイプ定義を次のspec
とstatus
に変更して、MemcachedBackup
CR の API を定義します。例5.3
api/v1/memcachedbackup_types.go
ファイルの例// MemcachedBackupSpec defines the desired state of MemcachedBackup type MemcachedBackupSpec struct { // INSERT ADDITIONAL SPEC FIELDS - desired state of cluster // Important: Run "make" to regenerate code after modifying this file //+kubebuilder:validation:Minimum=0 // Size is the size of the memcached deployment Size int32 `json:"size"` } // MemcachedBackupStatus defines the observed state of MemcachedBackup type MemcachedBackupStatus struct { // INSERT ADDITIONAL STATUS FIELD - define observed state of cluster // Important: Run "make" to regenerate code after modifying this file // Nodes are the names of the memcached pods Nodes []string `json:"nodes"` }
リソースタイプ用に生成されたコードを更新します。
$ make generate
ヒント*_types.go
ファイルの変更後は、make generate
コマンドを実行し、該当するリソースタイプ用に生成されたコードを更新する必要があります。API を
spec
フィールドとstatus
フィールドおよび CRD 検証マーカーで定義した後に、CRD マニフェストを生成および更新します。$ make manifests
この Makefile ターゲットは controller-gen
ユーティリティーを呼び出し、config/crd/bases/cache.my.domain_memcachedbackups.yaml
ファイルに CRD マニフェストを生成します。
5.5.6.4.2. コントローラーの実装
このチュートリアルのコントローラーは、次のアクションを実行します。
-
Memcached
デプロイメントを作成します (ない場合)。 -
デプロイメントのサイズが、
Memcached
CR 仕様で指定されたものと同じであることを確認します。 -
Memcached
CR ステータスをmemcached
Pod の名前に置き換えます。
上記のアクションを実行するようにコントローラーを設定する方法は、標準の Go ベースの Operator の Operator SDK チュートリアルで、コントローラーの実装を参照してください。
5.5.6.4.3. main.go の違い
標準の Go ベースの Operator と Hybrid Helm Operator の場合には、main.go
ファイルは、Go API のManager
プログラムの初期化と実行のスキャフォールディングを処理します。ただし、Hybrid Helm Operator の場合には、main.go
ファイルは、watches.yaml
ファイルをロードして Helm reconciler を設定するためのロジックも公開します。
例5.4 main.go
ファイルの例
... for _, w := range ws { // Register controller with the factory reconcilePeriod := defaultReconcilePeriod if w.ReconcilePeriod != nil { reconcilePeriod = w.ReconcilePeriod.Duration } maxConcurrentReconciles := defaultMaxConcurrentReconciles if w.MaxConcurrentReconciles != nil { maxConcurrentReconciles = *w.MaxConcurrentReconciles } r, err := reconciler.New( reconciler.WithChart(*w.Chart), reconciler.WithGroupVersionKind(w.GroupVersionKind), reconciler.WithOverrideValues(w.OverrideValues), reconciler.SkipDependentWatches(w.WatchDependentResources != nil && !*w.WatchDependentResources), reconciler.WithMaxConcurrentReconciles(maxConcurrentReconciles), reconciler.WithReconcilePeriod(reconcilePeriod), reconciler.WithInstallAnnotations(annotation.DefaultInstallAnnotations...), reconciler.WithUpgradeAnnotations(annotation.DefaultUpgradeAnnotations...), reconciler.WithUninstallAnnotations(annotation.DefaultUninstallAnnotations...), ) ...
マネージャーは、Helm
と Go
reconciler の両方で初期化されます。
例5.5 Helm
および Go
reconciler の例
... // Setup manager with Go API if err = (&controllers.MemcachedBackupReconciler{ Client: mgr.GetClient(), Scheme: mgr.GetScheme(), }).SetupWithManager(mgr); err != nil { setupLog.Error(err, "unable to create controller", "controller", "MemcachedBackup") os.Exit(1) } ... // Setup manager with Helm API for _, w := range ws { ... if err := r.SetupWithManager(mgr); err != nil { setupLog.Error(err, "unable to create controller", "controller", "Helm") os.Exit(1) } setupLog.Info("configured watch", "gvk", w.GroupVersionKind, "chartPath", w.ChartPath, "maxConcurrentReconciles", maxConcurrentReconciles, "reconcilePeriod", reconcilePeriod) } // Start the manager if err := mgr.Start(ctrl.SetupSignalHandler()); err != nil { setupLog.Error(err, "problem running manager") os.Exit(1) }
5.5.6.4.4. パーミッションおよび RBAC マニフェスト
コントローラーは、マネージドリソースの操作に、特定のロールベースのアクセス制御 (RBAC) 権限を必要とします。Go API の場合には、標準の Go ベースの Operator の Operator SDK チュートリアルに示されているように、RBAC マーカーで指定されます。
Helm API の場合、権限はデフォルトでroles.yaml
にスキャフォールディングされます。ただし、現在、Go API がスキャフォールディングされている場合の既知の問題が原因で、Helm API の権限が上書きされます。このような問題があるので、roles.yaml
で定義された権限が要件に一致することを確認してください。
この既知の問題は、https://github.com/operator-framework/helm-operator-plugins/issues/142で追跡されています。
以下は、Memcached Operator のrole.yaml
の例です。
例5.6 Helm
および Go
reconciler の例
--- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: manager-role rules: - apiGroups: - "" resources: - namespaces verbs: - get - apiGroups: - apps resources: - deployments - daemonsets - replicasets - statefulsets verbs: - create - delete - get - list - patch - update - watch - apiGroups: - cache.my.domain resources: - memcachedbackups verbs: - create - delete - get - list - patch - update - watch - apiGroups: - cache.my.domain resources: - memcachedbackups/finalizers verbs: - create - delete - get - list - patch - update - watch - apiGroups: - "" resources: - pods - services - services/finalizers - endpoints - persistentvolumeclaims - events - configmaps - secrets - serviceaccounts verbs: - create - delete - get - list - patch - update - watch - apiGroups: - cache.my.domain resources: - memcachedbackups/status verbs: - get - patch - update - apiGroups: - policy resources: - events - poddisruptionbudgets verbs: - create - delete - get - list - patch - update - watch - apiGroups: - cache.my.domain resources: - memcacheds - memcacheds/status - memcacheds/finalizers verbs: - create - delete - get - list - patch - update - watch
5.5.6.5. クラスター外でローカルに実行する。
Operator プロジェクトをクラスター外の Go プログラムとして実行できます。これは、デプロイメントとテストを迅速化するという開発目的において便利です。
手順
以下のコマンドを実行して、
~/.kube/config
ファイルに設定されたクラスターにカスタムリソース定義 (CRD) をインストールし、Operator をローカルで実行します。$ make install run
5.5.6.6. クラスター上でのデプロイメントとしての実行
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.5.6.7. カスタムリソースの作成
Operator のインストール後に、Operator によってクラスターに提供されるカスタムリソース (CR) を作成して、これをテストできます。
手順
Operator がインストールされている namespace へ変更します。
$ oc project <project_name>-system
replicaCount
フィールドを3
に変更して、config/samples/cache_v1_memcached.yaml
ファイルにあるサンプルMemcached CR
マニフェストを更新します。例5.7
config/samples/cache_v1_memcached.yaml
ファイルの例apiVersion: cache.my.domain/v1 kind: Memcached metadata: name: memcached-sample spec: # Default values copied from <project_dir>/helm-charts/memcached/values.yaml affinity: {} autoscaling: enabled: false maxReplicas: 100 minReplicas: 1 targetCPUUtilizationPercentage: 80 fullnameOverride: "" image: pullPolicy: IfNotPresent repository: nginx tag: "" imagePullSecrets: [] ingress: annotations: {} className: "" enabled: false hosts: - host: chart-example.local paths: - path: / pathType: ImplementationSpecific tls: [] nameOverride: "" nodeSelector: {} podAnnotations: {} podSecurityContext: {} replicaCount: 3 resources: {} securityContext: {} service: port: 80 type: ClusterIP serviceAccount: annotations: {} create: true name: "" tolerations: []
Memcached
CR を作成します。$ oc apply -f config/samples/cache_v1_memcached.yaml
Memcached Operator が、正しいサイズで CR サンプルのデプロイメントを作成することを確認します。
$ oc get pods
出力例
NAME READY STATUS RESTARTS AGE memcached-sample-6fd7c98d8-7dqdr 1/1 Running 0 18m memcached-sample-6fd7c98d8-g5k7v 1/1 Running 0 18m memcached-sample-6fd7c98d8-m7vn7 1/1 Running 0 18m
size
を2
に更新して、config/samples/cache_v1_memcachedbackup.yaml
ファイルにあるサンプルMemcachedBackup
CR マニフェストを更新します。例5.8
config/samples/cache_v1_memcachedbackup.yaml
ファイルの例apiVersion: cache.my.domain/v1 kind: MemcachedBackup metadata: name: memcachedbackup-sample spec: size: 2
MemcachedBackup
CR を作成します。$ oc apply -f config/samples/cache_v1_memcachedbackup.yaml
memcachedbackup
Pod の数が CR で指定されているものと同じであることを確認してください。$ oc get pods
出力例
NAME READY STATUS RESTARTS AGE memcachedbackup-sample-8649699989-4bbzg 1/1 Running 0 22m memcachedbackup-sample-8649699989-mq6mx 1/1 Running 0 22m
-
上記の各 CR の
spec
を更新してから、再度適用できます。コントローラーは再度調整し、Pod のサイズがそれぞれの CR の仕様
で指定されているとおりであることを確認します。 このチュートリアルの一環として作成したリソースをクリーンアップします。
Memcached
リソースを削除します。$ oc delete -f config/samples/cache_v1_memcached.yaml
MemcachedBackup
リソースを削除します。$ oc delete -f config/samples/cache_v1_memcachedbackup.yaml
Operator のテストに
make deploy
コマンドを使用した場合は、以下のコマンドを実行します。$ make undeploy
5.5.6.8. プロジェクトのレイアウト
Hybrid Helm Operator スキャフォールディングは、Helm API と Go API の両方と互換性があるようにカスタマイズされています。
ファイル/フォルダー | 目的 |
---|---|
|
|
| プロジェクトでの操作に役立つヘルパーターゲットを使用してファイルをビルドします。 |
| Operator のメタデータ情報が含まれる YAML ファイル。プロジェクトの設定を表し、CLI およびプラグインの有用な情報の追跡に使用されます。 |
|
プロジェクトのローカル実行に使用される |
| クラスターで Operator プロジェクト起動するための全Kustomizeマニフェストなど、設定ファイルが含まれています。プラグインはこのファイルを使用して機能を提供する場合があります。たとえば、Operator SDK が Operator バンドルの作成に役立つように、CLI はこのディレクトリーにスキャフォールディングされている CRD と CR を検索します。
|
| Go API 定義が含まれています。 |
| Go API のコントローラーが含まれています。 |
| プロジェクトファイルのライセンスヘッダーのスキャフォールディングに使用されるファイルなどのユーティリティーファイルが含まれています。 |
|
Operator のメインプログラム。 |
|
Helm プラグインで |
| group/version/kind (GVK) および Helm チャートの場所が含まれます。Helm ウォッチの設定に使用されます。 |
5.5.7. 新しい Operator SDK バージョンのハイブリッドの Helm ベースのプロジェクトの更新
OpenShift Container Platform 4.12 は Operator SDK 1.25.4 をサポートします。ワークステーションに 1.28.0 CLI がすでにインストールされている場合は、最新バージョンをインストール して CLI を 1.31.0 に更新できます。
ただし、既存の Operator プロジェクトが Operator SDK 1.25.4 との互換性を維持するには、1.22.2 以降に導入された関連する重大な変更に対し、更新手順を実行する必要があります。アップグレードの手順は、以前は 1.22.2 で作成または維持されている Operator プロジェクトのいずれかで手動で実行する必要があります。
5.5.7.1. Operator SDK 1.25.4 のハイブリッドの Helm ベースの Operator プロジェクトの更新
次の手順では、1.25.4 との互換性を確保するため、既存のハイブリッドの Helm ベースの Operator プロジェクトを更新します。
前提条件
- Operator SDK 1.25.4 がインストールされている
- Operator SDK 1.22.2 で作成または保守されている Operator プロジェクト
手順
config/default/manager_auth_proxy_patch.yaml
ファイルに以下の変更を加えます。apiVersion: apps/v1 kind: Deployment metadata: name: controller-manager namespace: system spec: template: spec: containers: - name: kube-rbac-proxy image: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.12 1 args: - "--secure-listen-address=0.0.0.0:8443" - "--upstream=http://127.0.0.1:8080/" - "--logtostderr=true" - "--v=0" ...
- 1
- タグバージョンを
v4.11
からv4.12
に更新します。
Makefile
に以下の変更を加えます。マルチアーキテクチャービルドサポートを有効にするには、
docker-buildx
ターゲットをプロジェクトのMakefile
に追加します。Makefile
の例# PLATFORMS defines the target platforms for the manager image be build to provide support to multiple # architectures. (i.e. make docker-buildx IMG=myregistry/mypoperator:0.0.1). To use this option you need to: # - able to use docker buildx . More info: https://docs.docker.com/build/buildx/ # - have enable BuildKit, More info: https://docs.docker.com/develop/develop-images/build_enhancements/ # - be able to push the image for your registry (i.e. if you do not inform a valid value via IMG=<myregistry/image:<tag>> than the export will fail) # To properly provided solutions that supports more than one platform you should use this option. PLATFORMS ?= linux/arm64,linux/amd64,linux/s390x,linux/ppc64le .PHONY: docker-buildx docker-buildx: test ## Build and push docker image for the manager for cross-platform support # copy existing Dockerfile and insert --platform=${BUILDPLATFORM} into Dockerfile.cross, and preserve the original Dockerfile sed -e '1 s/\(^FROM\)/FROM --platform=\$$\{BUILDPLATFORM\}/; t' -e ' 1,// s//FROM --platform=\$$\{BUILDPLATFORM\}/' Dockerfile > Dockerfile.cross - docker buildx create --name project-v3-builder docker buildx use project-v3-builder - docker buildx build --push --platform=$(PLATFORMS) --tag ${IMG} -f Dockerfile.cross - docker buildx rm project-v3-builder rm Dockerfile.cross
Makefile
に変更を適用し、Operator を再構築するには、次のコマンドを入力します。$ make
Go とその依存関係を更新するには、
go.mod
ファイルに次の変更を加えます。go 1.19 1 require ( github.com/onsi/ginkgo/v2 v2.1.4 2 github.com/onsi/gomega v1.19.0 3 k8s.io/api v0.25.0 4 k8s.io/apimachinery v0.25.0 5 k8s.io/client-go v0.25.0 6 sigs.k8s.io/controller-runtime v0.13.0 7 )
更新されたバージョンをダウンロードし、依存関係をクリーンアップして、
go.mod
ファイルの変更を適用するには、次のコマンドを実行します。$ go mod tidy