検索

5.5. Helm ベースの Operator

download PDF

5.5.1. Helm ベースの Operator の Operator SDK チュートリアル

Operator 開発者は、Operator SDK での Helm のサポートを利用して、Helm ベースの Nginx Operator のサンプルをビルドし、そのライフサイクルを管理することができます。このチュートリアルでは、以下のプロセスを説明します。

  • Nginx デプロイメントの作成
  • デプロイメントのサイズが、Nginx カスタムリソース (CR) 仕様で指定されたものと同じであることを確認します。
  • ステータスライターを使用して、Nginx CR ステータスを nginx Pod の名前で更新します。
重要

Operator プロジェクトの関連スキャフォールディングおよびテストツールなど、Red Hat がサポートするバージョンの Operator SDK CLI ツールは非推奨となり、Red Hat OpenShift Service on AWS の今後のリリースで削除される予定です。Red Hat は、現在のリリースライフサイクル中にこの機能のバグ修正とサポートを提供しますが、この機能は今後、機能拡張の提供はなく、Red Hat OpenShift Service on AWS リリースから削除されます。

新しい Operator プロジェクトを作成する場合、Red Hat がサポートするバージョンの Operator SDK は推奨されません。既存の Operator プロジェクトを使用する Operator 作成者は、Red Hat OpenShift Service on AWS 4 でリリースされるバージョンの Operator SDK CLI ツールを使用してプロジェクトを維持し、Red Hat OpenShift Service on AWS の新しいバージョンを対象とする Operator リリースを作成できます。

Operator プロジェクトの次の関連ベースイメージは 非推奨 ではありません。これらのベースイメージのランタイム機能と設定 API は、バグ修正と CVE への対応のために引き続きサポートされます。

  • Ansible ベースの Operator プロジェクトのベースイメージ
  • Helm ベースの Operator プロジェクトのベースイメージ

サポートされていない、コミュニティーによって管理されているバージョンの Operator SDK については、Operator SDK (Operator Framework) を参照してください。

このプロセスは、Operator Framework の 2 つの重要な設定要素を使用して実行されます。

Operator SDK
operator-sdk CLI ツールおよび controller-runtime ライブラリー API
Operator Lifecycle Manager (OLM)
クラスター上の Operator のインストール、アップグレード、ロールベースのアクセス制御 (RBAC)
注記

このチュートリアルでは、OpenShift Container Platform ドキュメントの Helm ベースの Operator の Operator SDK の使用を開始する よりも詳細に説明します。

5.5.1.1. 前提条件

  • Operator SDK CLI がインストールされている。
  • OpenShift CLI (oc) 4 以降がインストールされている。
  • dedicated-admin 権限を持つアカウントを使用して、oc で Red Hat OpenShift Service on AWS クラスターにログインしている。
  • クラスターがイメージをプルできるように、イメージをプッシュするリポジトリーを public として設定するか、イメージプルシークレットを設定している。

5.5.1.2. プロジェクトの作成

Operator SDK CLI を使用して nginx-operator というプロジェクトを作成します。

手順

  1. プロジェクトのディレクトリーを作成します。

    $ mkdir -p $HOME/projects/nginx-operator
  2. ディレクトリーに切り替えます。

    $ cd $HOME/projects/nginx-operator
  3. 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 および Kind Nginx でのリソースの監視に特化した nginx-operator プロジェクトを作成します。

  4. Helm ベースのプロジェクトの場合、init コマンドは、チャートのデフォルトマニフェストによってデプロイされるリソースに基づいて config/rbac/role.yaml ファイルに RBAC ルールを生成します。このファイルで生成されるルールが Operator のパーミッション要件を満たしていることを確認します。
5.5.1.2.1. 既存の Helm チャート

ボイラープレート Helm チャートでプロジェクトを作成する代わりに、以下のフラグを使用してローカルファイルシステムまたはリモートチャートリポジトリーから既存のチャートを使用することもできます。

  • --helm-chart
  • --helm-chart-repo
  • --helm-chart-version

--helm-chart フラグを指定すると、--group--version、および --kind フラグは任意となります。未設定のままにすると、以下のデフォルト値が使用されます。

フラグ

--domain

my.domain

--group

charts

--version

v1

--kind

指定されたチャートからの推定値。

--helm-chart フラグがローカルチャートアーカイブ (例: example-chart-1.2.0.tgz) またはディレクトリーを指定する場合、チャートは検証され、プロジェクトにデプロイメントされるかコピーされます。そうでない場合は、Operator SDK はリモートリポジトリーからチャートの取得を試みます。

--helm-chart-repo フラグでカスタムリポジトリーの URL が指定されない場合には、以下のチャート参照形式がサポートされます。

フォーマット説明

<repo_name>/<chart_name>

$HELM_HOME/repositories/repositories.yaml ファイルで指定されるように、<repo_name> という名前の Helm チャートリポジトリーから、<chart_name> という名前の Helm チャートを取得します。helm repo add コマンドを使用して、このファイルを設定します。

<url>

指定された URL で Helm チャートアーカイブを取得します。

カスタムリポジトリーの URL が --helm-chart-repo によって指定される場合、以下のチャート参照形式がサポートされます。

フォーマット説明

<chart_name>

--helm-chart-repo URL の値で指定された Helm チャートリポジトリーで、<chart_name> という名前の Helm チャートを取得します。

--helm-chart-version フラグが設定されていない場合は、Operator SDK は Helm チャートの利用可能な最新バージョンを取得します。フラグが設定されている場合は、指定したバージョンを取得します。--helm-chart フラグで指定したチャートが特定のバージョンを参照する場合 (例: ローカルパスまたは URL の場合)、オプションの --helm-chart-version フラグは使用されません。

詳細と例を確認するには、以下のコマンドを実行します。

$ operator-sdk init --plugins helm --help
5.5.1.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.1.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.1.3.1. Helm チャートのサンプル

Helm Operator プロジェクトの作成時に、Operator SDK は、単純な Nginx リリース用のテンプレートセットが含まれる Helm チャートのサンプルを作成します。

この例では、Helm チャート開発者がリリースに関する役立つ情報を伝えるために使用する NOTES.txt テンプレートと共に、デプロイメント、サービス、および Ingress リソース用にテンプレートを利用できます。

Helm チャートの使用に慣れていない場合は、Helm 開発者用のドキュメント を参照してください。

5.5.1.3.2. カスタムリソース仕様の変更

Helm は 値 (value) という概念を使用して、values.yaml ファイルに定義される Helm チャートのデフォルトをカスタマイズします。

カスタムリソース (CR) 仕様に必要な値を設定し、これらのデフォルトを上書きすることができます。例としてレプリカ数を使用することができます。

手順

  1. 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
  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.1.4. プロキシーサポートの有効化

Operator の作成者は、ネットワークプロキシーをサポートする Operator を開発できます。dedicated-admin ロールを持つ管理者は、Operator Lifecycle Manager (OLM) によって処理される環境変数のプロキシーサポートを設定します。Operator は以下の標準プロキシー変数の環境を検査し、値をオペランドに渡して、プロキシーされたクラスターをサポートする必要があります。

  • HTTP_PROXY
  • HTTPS_PROXY
  • NO_PROXY
注記

このチュートリアルでは、HTTP_PROXY を環境変数の例として使用します。

前提条件

  • クラスター全体の egress プロキシーが有効にされているクラスター。

手順

  1. watches.yaml ファイルを編集し、overrideValues フィールドを追加して、環境変数に基づいてオーバーライドを含めます。

    ...
    - group: demo.example.com
      version: v1alpha1
      kind: Nginx
      chart: helm-charts/nginx
      overrideValues:
        proxy.http: $HTTP_PROXY
    ...
  2. helm-charts/nginx/values.yaml ファイルに proxy.http 値を追加します。

    ...
    proxy:
      http: ""
      https: ""
      no_proxy: ""
  3. チャートテンプレートで変数の使用がサポートされているようにするには、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 }}"
  4. 以下を 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.1.5. Operator の実行

Operator をビルドして実行するには、Operator SDK CLI を使用して Operator をバンドルし、Operator Lifecycle Manager (OLM) を使用してクラスターにデプロイします。

注記

Operator を Red Hat OpenShift Service on AWS ではなく OpenShift Container Platform クラスターにデプロイする場合は、次の 2 つのデプロイ方法をさらに使用できます。

  • クラスター外で Go プログラムとしてローカルに実行します。
  • クラスター上のデプロイメントとして実行します。

関連情報

5.5.1.5.1. Operator のバンドルおよび Operator Lifecycle Manager を使用したデプロイ
5.5.1.5.1.1. Operator のバンドル

Operator Bundle Format は、Operator SDK および Operator Lifecycle Manager (OLM) のデフォルトパッケージ方法です。Operator SDK を使用して OLM に対して Operator を準備し、バンドルイメージとして Operator プロジェクトをビルドしてプッシュできます。

前提条件

  • 開発ワークステーションに Operator SDK CLI がインストールされている。
  • OpenShift CLI (oc) v4 以降がインストールされている。
  • Operator プロジェクトが Operator SDK を使用して初期化されている。

手順

  1. 以下の make コマンドを Operator プロジェクトディレクトリーで実行し、Operator イメージをビルドし、プッシュします。以下の手順の IMG 引数を変更して、アクセス可能なリポジトリーを参照します。Quay.io などのリポジトリーサイトにコンテナーを保存するためのアカウントを取得できます。

    1. イメージをビルドします。

      $ 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 を参照してください。

    2. イメージをリポジトリーにプッシュします。

      $ make docker-push IMG=<registry>/<user>/<operator_image_name>:<tag>
  2. 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 を使用して自動的に検証され、ディスク上のバンドル表現が正しいことを確認します。

  3. 以下のコマンドを実行し、バンドルイメージをビルドしてプッシュします。OLM は、1 つ以上のバンドルイメージを参照するインデックスイメージを使用して Operator バンドルを使用します。

    1. バンドルイメージをビルドします。イメージをプッシュしようとするレジストリー、ユーザー namespace、およびイメージタグの詳細で BUNDLE_IMG を設定します。

      $ make bundle-build BUNDLE_IMG=<registry>/<user>/<bundle_image_name>:<tag>
    2. バンドルイメージをプッシュします。

      $ docker push <registry>/<user>/<bundle_image_name>:<tag>
5.5.1.5.1.2. Operator Lifecycle Manager を使用した Operator のデプロイ

Operator Lifecycle Manager (OLM) は、Kubernetes クラスターで Operator (およびそれらの関連サービス) をインストールし、更新し、ライフサイクルを管理するのに役立ちます。OLM はデフォルトで Red Hat OpenShift Service on AWS にインストールされ、Kubernetes 拡張として実行されます。そのため、追加のツールなしで、すべての Operator ライフサイクル管理機能に Web コンソールと OpenShift CLI (oc) を使用できます。

Operator Bundle Format は、Operator SDK および OLM のデフォルトパッケージ方法です。Operator SDK を使用して OLM でバンドルイメージを迅速に実行し、適切に実行されるようにできます。

前提条件

  • 開発ワークステーションに Operator SDK CLI がインストールされている。
  • Operator バンドルイメージがビルドされ、レジストリーにプッシュされている。
  • OLM が Kubernetes ベースのクラスターにインストールされている (apiextensions.k8s.io/v1 CRD を使用する場合は v1.16.0 以降、たとえば Red Hat OpenShift Service on AWS 4)
  • dedicated-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 をデフォルトのインデックスイメージとして使用します。イメージを指定した場合は、コマンドはバンドルイメージ自体をインデックスイメージとして使用します。
    重要

    Red Hat OpenShift Service on AWS 4.11 以降、run bundle コマンドは Operator カタログのファイルベースのカタログ形式をデフォルトでサポートしています。Operator カタログに関して、非推奨の SQLite データベース形式は引き続きサポートされますが、今後のリリースで削除される予定です。Operator の作成者はワークフローをファイルベースのカタログ形式に移行することが推奨されます。

    このコマンドにより、以下のアクションが行われます。

    • バンドルイメージをインジェクトしてインデックスイメージを作成します。インデックスイメージは不透明で一時的なものですが、バンドルを実稼働環境でカタログに追加する方法を正確に反映します。
    • 新規インデックスイメージを参照するカタログソースを作成します。これにより、OperatorHub が Operator を検出できるようになります。
    • OperatorGroupSubscriptionInstallPlan、および RBAC を含むその他の必要なリソースすべてを作成して、Operator をクラスターにデプロイします。

5.5.1.6. カスタムリソースの作成

Operator のインストール後に、Operator によってクラスターに提供されるカスタムリソース (CR) を作成して、これをテストできます。

前提条件

  • クラスターにインストールされている Nginx CR を提供する Nginx Operator の例

手順

  1. Operator がインストールされている namespace へ変更します。たとえば、make deploy コマンドを使用して Operator をデプロイした場合は、以下のようになります。

    $ oc project nginx-operator-system
  2. config/samples/demo_v1_nginx.yamlNginx CR マニフェストのサンプルを編集し、以下の仕様が含まれるようにします。

    apiVersion: demo.example.com/v1
    kind: Nginx
    metadata:
      name: nginx-sample
    ...
    spec:
    ...
      replicaCount: 3
  3. Nginx サービスアカウントを Red Hat OpenShift Service on AWS で実行するには、特権アクセスが必要です。以下の SCC (Security Context Constraints) を nginx-sample Pod のサービスアカウントに追加します。

    $ oc adm policy add-scc-to-user \
        anyuid system:serviceaccount:nginx-operator-system:nginx-sample
  4. CR を作成します。

    $ oc apply -f config/samples/demo_v1_nginx.yaml
  5. 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

  6. ステータスが Nginx Pod 名で更新されていることを確認するために、Pod および CR ステータスを確認します。

    1. 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

    2. 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

  7. デプロイメントサイズを更新します。

    1. config/samples/demo_v1_nginx.yaml ファイルを更新して、Nginx CR の spec.size フィールドを 3 から 5 に変更します。

      $ oc patch nginx nginx-sample \
          -p '{"spec":{"replicaCount": 5}}' \
          --type=merge
    2. 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

  8. 次のコマンドを実行して CR を削除します。

    $ oc delete -f config/samples/demo_v1_nginx.yaml
  9. このチュートリアルの一環として作成したリソースをクリーンアップします。

    • Operator のテストに make deploy コマンドを使用した場合は、以下のコマンドを実行します。

      $ make undeploy
    • Operator のテストに operator-sdk run bundle コマンドを使用した場合は、以下のコマンドを実行します。

      $ operator-sdk cleanup <project_name>

5.5.1.7. 関連情報

5.5.2. Helm ベースの Operator のプロジェクトレイアウト

operator-sdk CLI は、各 Operator プロジェクトに多数のパッケージおよびファイルを生成、または スキャフォールディング することができます。

重要

Operator プロジェクトの関連スキャフォールディングおよびテストツールなど、Red Hat がサポートするバージョンの Operator SDK CLI ツールは非推奨となり、Red Hat OpenShift Service on AWS の今後のリリースで削除される予定です。Red Hat は、現在のリリースライフサイクル中にこの機能のバグ修正とサポートを提供しますが、この機能は今後、機能拡張の提供はなく、Red Hat OpenShift Service on AWS リリースから削除されます。

新しい Operator プロジェクトを作成する場合、Red Hat がサポートするバージョンの Operator SDK は推奨されません。既存の Operator プロジェクトを使用する Operator 作成者は、Red Hat OpenShift Service on AWS 4 でリリースされるバージョンの Operator SDK CLI ツールを使用してプロジェクトを維持し、Red Hat OpenShift Service on AWS の新しいバージョンを対象とする Operator リリースを作成できます。

Operator プロジェクトの次の関連ベースイメージは 非推奨 ではありません。これらのベースイメージのランタイム機能と設定 API は、バグ修正と CVE への対応のために引き続きサポートされます。

  • Ansible ベースの Operator プロジェクトのベースイメージ
  • Helm ベースの Operator プロジェクトのベースイメージ

サポートされていない、コミュニティーによって管理されているバージョンの Operator SDK については、Operator SDK (Operator Framework) を参照してください。

5.5.2.1. Helm ベースのプロジェクトレイアウト

operator-sdk init --plugins helm コマンドを使用して生成される Helm ベースの Operator プロジェクトには、以下のディレクトリーおよびファイルが含まれます。

ファイル/フォルダー目的

config/

Kubernetes クラスターへの Operator のデプロイに使用する Kustomize マニフェスト。

helm-charts/

operator-sdk create api コマンドで初期化された Helm チャート。

Dockerfile

make docker-build コマンドで Operator イメージをビルドする際に使用します。

watches.yaml

group/version/kind (GVK) および Helm チャートの場所。

Makefile

プロジェクトの管理に使用するターゲット。

PROJECT

Operator のメタデータ情報が含まれる YAML ファイル。

5.5.3. 新しい Operator SDK バージョンの Helm ベースのプロジェクトの更新

Red Hat OpenShift Service on AWS 4 は Operator SDK 1.31.0 をサポートしています。ワークステーションに 1.28.0 CLI がすでにインストールされている場合は、最新バージョンをインストール して CLI を 1.31.0 に更新できます。

重要

Operator プロジェクトの関連スキャフォールディングおよびテストツールなど、Red Hat がサポートするバージョンの Operator SDK CLI ツールは非推奨となり、Red Hat OpenShift Service on AWS の今後のリリースで削除される予定です。Red Hat は、現在のリリースライフサイクル中にこの機能のバグ修正とサポートを提供しますが、この機能は今後、機能拡張の提供はなく、Red Hat OpenShift Service on AWS リリースから削除されます。

新しい Operator プロジェクトを作成する場合、Red Hat がサポートするバージョンの Operator SDK は推奨されません。既存の Operator プロジェクトを使用する Operator 作成者は、Red Hat OpenShift Service on AWS 4 でリリースされるバージョンの Operator SDK CLI ツールを使用してプロジェクトを維持し、Red Hat OpenShift Service on AWS の新しいバージョンを対象とする Operator リリースを作成できます。

Operator プロジェクトの次の関連ベースイメージは 非推奨 ではありません。これらのベースイメージのランタイム機能と設定 API は、バグ修正と CVE への対応のために引き続きサポートされます。

  • Ansible ベースの Operator プロジェクトのベースイメージ
  • Helm ベースの Operator プロジェクトのベースイメージ

サポートされていない、コミュニティーによって管理されているバージョンの Operator SDK については、Operator SDK (Operator Framework) を参照してください。

ただし、既存の Operator プロジェクトが Operator SDK 1.31.0 との互換性を維持するには、1.28.0 以降に導入された関連する重大な変更に対し、更新手順を実行する必要があります。アップグレードの手順は、以前は 1.28.0 で作成または維持されている Operator プロジェクトのいずれかで手動で実行する必要があります。

5.5.3.1. Operator SDK 1.31.0 の Helm ベースの Operator プロジェクトの更新

次の手順では、1.31.0 との互換性を確保するため、既存の Helm ベースの Operator プロジェクトを更新します。

前提条件

  • Operator SDK 1.31.0 がインストールされている
  • Operator SDK 1.28.0 で作成または保守されている Operator プロジェクト

手順

  1. 次の例に示すように、Operator プロジェクトの Makefile を編集して Operator SDK バージョンを 1.31.0 に更新します。

    例 makefile

    # Set the Operator SDK version to use. By default, what is installed on the system is used.
    # This is useful for CI or a project to utilize a specific version of the operator-sdk toolkit.
    OPERATOR_SDK_VERSION ?= v1.36.1 1

    1
    バージョンを 1.28.0 から 1.31.0 に変更します。
  2. 次の例に示すように、Operator の Dockerfile を編集して ose-helm-rhel9-operator イメージタグを 4 に更新します。

    Dockerfile の例

    FROM registry.redhat.io/openshift4/ose-helm-rhel9-operator:v4

  3. kustomize/v2 プラグインは安定版になり、go/v4ansible/v1helm/v1、および hybrid/v1-alpha プラグインを使用する場合にプラグインチェーンで使用されるデフォルトのバージョンになりました。このデフォルトのスキャフォールディングの詳細については、Kubebuilder ドキュメントの Kustomize v2 を参照してください。
  4. Operator プロジェクトがマルチプラットフォームまたはマルチアーキテクチャー、ビルドを使用する場合、既存の docker-buildx ターゲットをプロジェクトの Makefile の以下の定義に置き換えます。

    例 makefile

    docker-buildx:
    ## Build and push the Docker image for the manager for multi-platform support
    	- docker buildx create --name project-v3-builder
    	docker buildx use project-v3-builder
    	- docker buildx build --push --platform=$(PLATFORMS) --tag ${IMG} -f Dockerfile .
    	- docker buildx rm project-v3-builder

  5. 1.29 を使用するには、Operator プロジェクトの Kubernetes バージョンをアップグレードする必要があります。プロジェクト構造、Makefile、および go.mod ファイルで以下の変更を加える必要があります。

    重要

    go/v3 プラグインは Kubebuilder で非推奨であるため、Operator SDK も今後のリリースで go/v4 に移行しています。

    1. go.mod ファイルを更新して、依存関係をアップグレードします。

      k8s.io/api v0.29.2
      k8s.io/apimachinery v0.29.2
      k8s.io/client-go v0.29.2
      sigs.k8s.io/controller-runtime v0.17.3
    2. 次のコマンドを実行して、アップグレードされた依存関係をダウンロードします。

      $ go mod tidy
  6. Makefile の Kustomize バージョンを更新するには、以下の変更を加えます。

    - curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v5.2.1/kustomize_v5.2.1_$(OS)_$(ARCH).tar.gz | \
    + curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v5.3.0/kustomize_v5.3.0_$(OS)_$(ARCH).tar.gz | \

5.5.3.2. 関連情報

5.5.4. Operator SDK での Helm サポート

重要

Operator プロジェクトの関連スキャフォールディングおよびテストツールなど、Red Hat がサポートするバージョンの Operator SDK CLI ツールは非推奨となり、Red Hat OpenShift Service on AWS の今後のリリースで削除される予定です。Red Hat は、現在のリリースライフサイクル中にこの機能のバグ修正とサポートを提供しますが、この機能は今後、機能拡張の提供はなく、Red Hat OpenShift Service on AWS リリースから削除されます。

新しい Operator プロジェクトを作成する場合、Red Hat がサポートするバージョンの Operator SDK は推奨されません。既存の Operator プロジェクトを使用する Operator 作成者は、Red Hat OpenShift Service on AWS 4 でリリースされるバージョンの Operator SDK CLI ツールを使用してプロジェクトを維持し、Red Hat OpenShift Service on AWS の新しいバージョンを対象とする Operator リリースを作成できます。

Operator プロジェクトの次の関連ベースイメージは 非推奨 ではありません。これらのベースイメージのランタイム機能と設定 API は、バグ修正と CVE への対応のために引き続きサポートされます。

  • Ansible ベースの Operator プロジェクトのベースイメージ
  • Helm ベースの Operator プロジェクトのベースイメージ

サポートされていない、コミュニティーによって管理されているバージョンの Operator SDK については、Operator SDK (Operator Framework) を参照してください。

5.5.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 に準拠するため、実稼働環境の変更を簡単に防止することができます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.