3.7. カスタムカタログの管理

以下では、OpenShift Container Platform で Operator Lifecycle Manager (OLM) の Package Manifest Format または Bundle Format のいずれかを使用してパッケージ化されたカスタムカタログを使用する方法について説明します。

3.7.1. Package Manifest Format を使用したカスタムカタログ

3.7.1.1. Operator カタログイメージについて

Operator Lifecycle Manager (OLM) は常に Operator カタログの最新バージョンから Operator をインストールします。OpenShift Container Platform 4.5 では、Red Hat が提供する Operator は、quay.io から Quay App Registry カタログ経由で配布されます。

表3.2 Red Hat が提供する App Registry カタログ

カタログ説明

redhat-operators

Red Hat によってパッケージ化され、出荷される Red Hat 製品のパブリックカタログ。Red Hat によってサポートされます。

certified-operators

大手独立系ソフトウェアベンダー (ISV) の製品のパブリックカタログ。Red Hat は ISV とのパートナーシップにより、パッケージ化および出荷を行います。ISV によってサポートされます。

community-operators

operator-framework/community-operators GitHub リポジトリーで関連するエンティティーによってメンテナーンスされる、オプションで表示可能になるソフトウェアのパブリックカタログ。正式なサポートはありません。

カタログが更新されると、Operator の最新バージョンが変更され、それ以前のバージョンが削除または変更される可能性があります。この動作により、再現可能なインストールを維持することが徐々に難しくなる可能性があります。さらに OLM がネットワークが制限された環境の OpenShift Container Platform クラスターで実行される場合、quay.io からカタログに直接アクセスすることはできません。

oc adm catalog build コマンドを使用して、クラスター管理者は Operator カタログイメージを作成できます。以下は Operator カタログイメージの説明です。

  • App Registry タイプカタログのコンテンツの特定の時点のエクスポート。
  • App Registry カタログをコンテナーイメージタイプカタログに変換した結果。
  • イミュータブルなアーティファクト。

Operator カタログイメージを作成する方法は、前述の問題を引き起こさずにこのコンテンツを使用できる簡単な方法です。

3.7.1.2. Operator カタログイメージのビルド

クラスター管理者は、Operator Lifecycle Manager (OLM) によって使用される Package Manifest Format に基づいてカスタム Operator カタログイメージをビルドできます。カタログイメージは、Docker v2-2 をサポートするコンテナーイメージレジストリーにプッシュできます。ネットワークが制限された環境のクラスターの場合、このレジストリーには、ネットワークが制限されたクラスターのインストール時に作成されたミラーレジストリーなど、クラスターにネットワークアクセスのあるレジストリーを使用できます。

重要

OpenShift Container Platform クラスターの内部レジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。

以下の例では、お使いのネットワークとインターネットの両方にアクセスできるミラーレジストリーを使用することを前提としています。

注記

Windows および macOS のバージョンは oc adm catalog build コマンドを提供しないため、この手順では oc クライアントの Linux バージョンのみを使用できます。

前提条件

  • ネットワークアクセスが無制限のワークステーション
  • oc バージョン 4.3.5+ Linux クライアント
  • podman version 1.4.4+
  • Docker v2-2 をサポートするミラーレジストリーへのアクセス
  • プライベートレジストリーを使用している場合、後続の手順で使用するために REG_CREDS 環境変数をレジストリー認証情報のファイルパスに設定します。たとえば podman CLI の場合は、以下のようになります。

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json
  • quay.io アカウントがアクセスできるプライベート namespace を使用している場合、Quay 認証トークンを設定する必要があります。quay.io 認証情報を使用してログイン API に対して要求を行うことにより、--auth-token フラグで使用できる AUTH_TOKEN 環境変数を設定します。

    $ AUTH_TOKEN=$(curl -sH "Content-Type: application/json" \
        -XPOST https://quay.io/cnr/api/v1/users/login -d '
        {
            "user": {
                "username": "'"<quay_username>"'",
                "password": "'"<quay_password>"'"
            }
        }' | jq -r '.token')

手順

  1. ネットワークアクセスが無制限のワークステーションで、ターゲットミラーレジストリーを使用して認証を行います。

    $ podman login <registry_host_name>

    また、ビルド時にベースイメージをプルできるように、registry.redhat.io で認証します。

    $ podman login registry.redhat.io
  2. Quay.io から redhat-operators カタログをベースにカタログイメージをビルドし、そのイメージにタグを付け、ミラーレジストリーにプッシュします。

    $ oc adm catalog build \
        --appregistry-org redhat-operators \1
        --from=registry.redhat.io/openshift4/ose-operator-registry:v4.5 \2
        --filter-by-os="linux/amd64" \3
        --to=<registry_host_name>:<port>/olm/redhat-operators:v1 \4
        [-a ${REG_CREDS}] \5
        [--insecure] \6
        [--auth-token "${AUTH_TOKEN}"] 7
    1
    App Registry インスタンスからのプルに使用する組織 (namespace)。
    2
    ターゲット OpenShift Container Platform クラスターのメジャーバージョンおよびマイナーバージョンに一致するタグを使用して、--fromose-operator-registry ベースイメージに設定します。
    3
    --filter-by-os を、ターゲットの OpenShift Container Platform クラスターと一致する必要のある、ベースイメージに使用するオペレーティングシステムおよびアーキテクチャーに設定します。使用できる値は、linux/amd64linux/ppc64le、および linux/s390x です。
    4
    カタログイメージに名前を付け、v1 などのタグを追加します。
    5
    オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。
    6
    オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。
    7
    オプション: 公開されていない他のアプリケーションレジストリーカタログが使用されている場合、Quay 認証トークンを指定します。

    出力例

    INFO[0013] loading Bundles                               dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605
    ...
    Pushed sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3 to example_registry:5000/olm/redhat-operators:v1

    無効なマニフェストが Red Hat のカタログに誤って導入されることあります。これが実際に生じる場合には、以下のようなエラーが表示される可能性があります。

    エラーのある出力の例

    ...
    INFO[0014] directory                                     dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605 file=4.2 load=package
    W1114 19:42:37.876180   34665 builder.go:141] error building database: error loading package into db: fuse-camel-k-operator.v7.5.0 specifies replacement that couldn't be found
    Uploading ... 244.9kB/s

    通常、これらのエラーは致命的なエラーではなく、該当する Operator パッケージにインストールする予定の Operator やその依存関係が含まれない場合、それらを無視することができます。

3.7.1.3. Operator カタログイメージのミラーリング

クラスター管理者はそれぞれのカタログの内容をレジストリーにミラーリングし、CatalogSource を使用してコンテンツを OpenShift Container Platform クラスターに読み込むことができます。この例では、以前にビルドされ、サポートされているレジストリーにプッシュされたカスタム redhat-operators カタログイメージを使用します。

前提条件

  • ネットワークアクセスが無制限のワークステーション
  • サポートされているレジストリーにプッシュされるカスタム Operator カタログイメージ
  • oc version 4.3.5+
  • podman version 1.4.4+
  • Docker v2-2 をサポートするミラーレジストリーへのアクセス
  • プライベートレジストリーを使用している場合、後続の手順で使用するために REG_CREDS 環境変数をレジストリー認証情報のファイルパスに設定します。たとえば podman CLI の場合は、以下のようになります。

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json

手順

  1. oc adm catalog mirror コマンドは、カスタム Operator カタログイメージのコンテンツを抽出し、ミラーリングに必要なマニフェストを生成します。以下のいずれかを選択できます。

    • コマンドのデフォルト動作で、マニフェストの生成後にすべてのイメージコンテンツをミラーレジストリーに自動的にミラーリングできるようにします。または、
    • --manifests-only フラグを追加して、ミラーリングに必要なマニフェストのみを生成しますが、これにより、イメージコンテンツがレジストリーに自動的にミラーリングされる訳ではありません。これは、ミラーリングする内容を確認するのに役立ちます。また、コンテンツのサブセットのみが必要な場合に、マッピングの一覧に変更を加えることができます。次に、そのファイルを oc image mirror コマンドで使用し、後のステップでイメージの変更済みの一覧をミラーリングできます。

    ネットワークアクセスが無制限のワークステーションで、以下のコマンドを実行します。

    $ oc adm catalog mirror \
        <registry_host_name>:<port>/olm/redhat-operators:v1 \1
        <registry_host_name>:<port> \
        [-a ${REG_CREDS}] \2
        [--insecure] \3
        --filter-by-os='.*' \4
        [--manifests-only] 5
    1
    Operator カタログイメージを指定します。
    2
    オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。
    3
    オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。
    4
    このフラグは、現時点で複数のアーキテクチャーのサポートに関して問題が存在するために必要になります。
    5
    オプション: ミラーリングに必要なマニフェストのみを生成し、実際にはイメージコンテンツをレジストリーにミラーリングしません。
    警告

    --filter-by-os フラグが設定されていない状態か、または .* 以外の値に設定されている場合、コマンドが複数の異なるアーキテクチャーをフィルターし、マニフェスト一覧のダイジェスト (multi-arch image イメージとしても知られる) が変更されます。ダイジェストが間違っていると、それらのイメージおよび Operator の非接続クラスターでのデプロイメントに失敗します。詳細は、BZ#1890951 を参照してください。

    出力例

    using database path mapping: /:/tmp/190214037
    wrote database to /tmp/190214037
    using database at: /tmp/190214037/bundles.db 1
    ...

    1
    コマンドで生成される一時的なデータベース。

    コマンドの実行後に、<image_name>-manifests/ ディレクトリーが現在のディレクトリーに作成され、以下のファイルが生成されます。

    • これにより、imageContentSourcePolicy.yaml ファイルは ImageContentSourcePolicy オブジェクトを定義します。このオブジェクトは、ノードを Operator マニフェストおよびミラーリングされたレジストリーに保存されるイメージ参照間で変換できるように設定します。
    • mapping.txt ファイルには、すべてのソースイメージが含まれ、これはそれらのイメージをターゲットレジストリー内のどこにマップするかを示します。このファイルは oc image mirror コマンドと互換性があり、ミラーリング設定をさらにカスタマイズするために使用できます。
  2. 直前の手順で --manifests-only フラグを使用して、コンテンツのサブセットのみをミラーリングする場合は、以下を実行します。

    1. mapping.txt ファイルのイメージの一覧を仕様に変更します。ミラーリングするイメージのサブセットの名前とバージョンが不明な場合は、以下の手順で確認します。

      1. oc adm catalog mirror コマンドで生成された一時的なデータベースに対して sqlite3 ツールを実行し、一般的な検索クエリーに一致するイメージの一覧を取得します。出力は、後に mapping.txt ファイルを編集する方法を通知するのに役立ちます。

        たとえば、clusterlogging.4.3 の文字列のようなイメージの一覧を取得するには、以下を実行します。

        $ echo "select * from related_image \
            where operatorbundle_name like 'clusterlogging.4.3%';" \
            | sqlite3 -line /tmp/190214037/bundles.db 1
        1
        oc adm catalog mirror コマンドの直前の出力を参照し、データベースファイルのパスを見つけます。

        出力例

        image = registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61
        operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
        
        image = registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506
        operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
        ...

      2. 直前の手順で取得した結果を使用して mapping.txt ファイルを編集し、ミラーリングする必要のあるイメージのサブセットのみを追加します。

        たとえば、前述の出力例の image 値を使用して、mapping.txt ファイルに以下の一致する行が存在することを確認できます。

        mapping.txt の一致するイメージマッピング。

        registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61=<registry_host_name>:<port>/openshift4-ose-logging-kibana5:a767c8f0
        registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506=<registry_host_name>:<port>/openshift4-ose-oauth-proxy:3754ea2b

        この例では、これらのイメージのみをミラーリングする場合に、mapping.txt ファイルの他のすべてのエントリーを削除し、上記の 2 行のみを残します。

    2. ネットワークアクセスが無制限のワークステーション上で、変更した mapping.txt ファイルを使用し、 oc image mirror コマンドを使用してイメージをレジストリーにミラーリングします。

      $ oc image mirror \
          [-a ${REG_CREDS}] \
          --filter-by-os='.*' \
          -f ./redhat-operators-manifests/mapping.txt
      警告

      --filter-by-os フラグが設定されていない状態か、または .* 以外の値に設定されている場合、コマンドが複数の異なるアーキテクチャーをフィルターし、マニフェスト一覧のダイジェスト (multi-arch image イメージとしても知られる) が変更されます。ダイジェストが間違っていると、それらのイメージおよび Operator の非接続クラスターでのデプロイメントに失敗します。

  3. ImageContentSourcePolicy オブジェクトを適用します。

    $ oc apply -f ./redhat-operators-manifests/imageContentSourcePolicy.yaml
  4. カタログイメージを参照する CatalogSource オブジェクトを作成します。

    1. 仕様を以下のように変更し、これを catalogsource.yaml ファイルとして保存します。

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace
      spec:
        sourceType: grpc
        image: <registry_host_name>:<port>/olm/redhat-operators:v1 1
        displayName: My Operator Catalog
        publisher: grpc
      1
      Operator カタログイメージを指定します。
    2. このファイルを使用して CatalogSource オブジェクトを作成します。

      $ oc create -f catalogsource.yaml
  5. 以下のリソースが正常に作成されていることを確認します。

    1. Pod を確認します。

      $ oc get pods -n openshift-marketplace

      出力例

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

    2. カタログソースを確認します。

      $ oc get catalogsource -n openshift-marketplace

      出力例

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

    3. パッケージマニフェストを確認します。

      $ oc get packagemanifest -n openshift-marketplace

      出力例

      NAME    CATALOG              AGE
      etcd    My Operator Catalog  34s

ネットワークが制限された環境の OpenShift Container Platform クラスター Web コンソールで、OperatorHub ページから Operator をインストールできます。

3.7.1.4. Operator カタログイメージの更新

クラスター管理者がカスタム Operator カタログイメージを使用するように OperatorHub を設定した後、管理者は Red Hat の App Registry カタログに追加された更新をキャプチャーして、OpenShift Container Platform クラスターを最新の Operator と共に最新の状態に保つことができます。これは、新規 Operator カタログイメージをビルドし、プッシュしてから、既存の CatalogSource オブジェクトの spec.image パラメーターを新規イメージダイジェストに置き換えることによって実行されます。

この例では、カスタムの redhat-operators カタログイメージが OperatorHub と使用するように設定されていることを前提としています。

注記

Windows および macOS のバージョンは oc adm catalog build コマンドを提供しないため、この手順では oc クライアントの Linux バージョンのみを使用できます。

前提条件

  • ネットワークアクセスが無制限のワークステーション
  • oc バージョン 4.3.5+ Linux クライアント
  • podman version 1.4.4+
  • Docker v2-2 をサポートするミラーレジストリーへのアクセス
  • カスタムカタログイメージを使用するように設定されている OperatorHub
  • プライベートレジストリーを使用している場合、後続の手順で使用するために REG_CREDS 環境変数をレジストリー認証情報のファイルパスに設定します。たとえば podman CLI の場合は、以下のようになります。

    $ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json
  • quay.io アカウントがアクセスできるプライベート namespace を使用している場合、Quay 認証トークンを設定する必要があります。quay.io 認証情報を使用してログイン API に対して要求を行うことにより、--auth-token フラグで使用できる AUTH_TOKEN 環境変数を設定します。

    $ AUTH_TOKEN=$(curl -sH "Content-Type: application/json" \
        -XPOST https://quay.io/cnr/api/v1/users/login -d '
        {
            "user": {
                "username": "'"<quay_username>"'",
                "password": "'"<quay_password>"'"
            }
        }' | jq -r '.token')

手順

  1. ネットワークアクセスが無制限のワークステーションで、ターゲットミラーレジストリーを使用して認証を行います。

    $ podman login <registry_host_name>

    また、ビルド時にベースイメージをプルできるように、registry.redhat.io で認証します。

    $ podman login registry.redhat.io
  2. Quay.io から redhat-operators カタログをベースに新規カタログイメージをビルドし、そのイメージにタグを付け、ミラーレジストリーにプッシュします。

    $ oc adm catalog build \
        --appregistry-org redhat-operators \1
        --from=registry.redhat.io/openshift4/ose-operator-registry:v4.5 \2
        --filter-by-os="linux/amd64" \3
        --to=<registry_host_name>:<port>/olm/redhat-operators:v2 \4
        [-a ${REG_CREDS}] \5
        [--insecure] \6
        [--auth-token "${AUTH_TOKEN}"] 7
    1
    App Registry インスタンスからのプルに使用する組織 (namespace)。
    2
    ターゲット OpenShift Container Platform クラスターのメジャーバージョンおよびマイナーバージョンに一致するタグを使用して、--fromose-operator-registry ベースイメージに設定します。
    3
    --filter-by-os を、ターゲットの OpenShift Container Platform クラスターと一致する必要のある、ベースイメージに使用するオペレーティングシステムおよびアーキテクチャーに設定します。使用できる値は、linux/amd64linux/ppc64le、および linux/s390x です。
    4
    カタログイメージに名前を付け、タグを追加します (更新済みのカタログの場合は v2 などのタグ)。
    5
    オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。
    6
    オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。
    7
    オプション: 公開されていない他のアプリケーションレジストリーカタログが使用されている場合、Quay 認証トークンを指定します。

    出力例

    INFO[0013] loading Bundles                               dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605
    ...
    Pushed sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3 to example_registry:5000/olm/redhat-operators:v2

  3. カタログのコンテンツをターゲットレジストリーに対してミラーリングします。以下の oc adm catalog mirror コマンドは、カスタム Operator カタログイメージのコンテンツを抽出し、ミラーリングに必要なマニフェストを生成し、イメージをレジストリーにミラーリングします。

    $ oc adm catalog mirror \
        <registry_host_name>:<port>/olm/redhat-operators:v2 \1
        <registry_host_name>:<port> \
        [-a ${REG_CREDS}] \2
        [--insecure] \3
        --filter-by-os='.*' 4
    1
    新規の Operator カタログイメージを指定します。
    2
    オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。
    3
    オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。
    4
    このフラグは、現時点で複数のアーキテクチャーのサポートに関して問題が存在するために必要になります。--filter-by-os フラグが設定されていない状態か、または .* 以外の値に設定されている場合、コマンドが複数の異なるアーキテクチャーをフィルターし、マニフェスト一覧のダイジェスト (multi-arch image イメージとしても知られる) が変更されます。ダイジェストが間違っていると、それらのイメージおよび Operator の非接続クラスターでのデプロイメントに失敗します。詳細は、BZ#1890951 を参照してください。
  4. 新たに生成されたマニフェストを適用します。

    $ oc apply -f ./redhat-operators-manifests
    重要

    imageContentSourcePolicy.yaml マニフェストを適用する必要がない場合があります。ファイルの diff を完了して、変更が必要かどうかを判断します。

  5. カタログイメージを参照する CatalogSource オブジェクトを更新します。

    1. この CatalogSource オブジェクトの元の catalogsource.yaml ファイルがある場合:

      1. catalogsource.yaml ファイルを編集し、spec.image フィールドで新規カタログイメージを参照できるようにします。

        apiVersion: operators.coreos.com/v1alpha1
        kind: CatalogSource
        metadata:
          name: my-operator-catalog
          namespace: openshift-marketplace
        spec:
          sourceType: grpc
          image: <registry_host_name>:<port>/olm/redhat-operators:v2 1
          displayName: My Operator Catalog
          publisher: grpc
        1
        新規の Operator カタログイメージを指定します。
      2. 更新されたファイルを使用して CatalogSource オブジェクトを置き換えます。

        $ oc replace -f catalogsource.yaml
    2. または、以下のコマンドを使用してカタログソースを編集し、spec.image パラメーターで新規カタログイメージを参照します。

      $ oc edit catalogsource <catalog_source_name> -n openshift-marketplace

更新された Operator は、OpenShift Container Platform クラスターの OperatorHub ページから利用できるようになりました。

3.7.1.5. Operator カタログイメージのテスト

Operator カタログイメージのコンテンツは、これをコンテナーとして実行し、gRPC API をクエリーして検証できます。イメージをさらにテストするには、CatalogSource オブジェクトでイメージを参照して OLM サブスクリプションを解決できます。この例では、以前にビルドされ、サポートされているレジストリーにプッシュされたカスタム redhat-operators カタログイメージを使用します。

前提条件

  • サポートされているレジストリーにプッシュされるカスタム Operator カタログイメージ
  • podman version 1.4.4+
  • oc version 4.3.5+
  • Docker v2-2 をサポートするミラーレジストリーへのアクセス
  • grpcurl

手順

  1. Operator カタログイメージをプルします。

    $ podman pull <registry_host_name>:<port>/olm/redhat-operators:v1
  2. イメージを実行します。

    $ podman run -p 50051:50051 \
        -it <registry_host_name>:<port>/olm/redhat-operators:v1
  3. grpcurl を使用して利用可能なパッケージの実行中のイメージをクエリーします。

    $ grpcurl -plaintext localhost:50051 api.Registry/ListPackages

    出力例

    {
      "name": "3scale-operator"
    }
    {
      "name": "amq-broker"
    }
    {
      "name": "amq-online"
    }

  4. チャネルの最新の Operator バンドルを取得します。

    $  grpcurl -plaintext -d '{"pkgName":"kiali-ossm","channelName":"stable"}' localhost:50051 api.Registry/GetBundleForChannel

    出力例

    {
      "csvName": "kiali-operator.v1.0.7",
      "packageName": "kiali-ossm",
      "channelName": "stable",
    ...

  5. イメージのダイジェストを取得します。

    $ podman inspect \
        --format='{{index .RepoDigests 0}}' \
        <registry_host_name>:<port>/olm/redhat-operators:v1

    出力例

    example_registry:5000/olm/redhat-operators@sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3

  6. Operator グループが Operator とその依存関係をサポートする namespace my-ns にあることを前提とし、イメージダイジェストを使用して CatalogSource オブジェクトを作成します。以下に例を示します。

    apiVersion: operators.coreos.com/v1alpha1
    kind: CatalogSource
    metadata:
      name: custom-redhat-operators
      namespace: my-ns
    spec:
      sourceType: grpc
      image: example_registry:5000/olm/redhat-operators@sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3
      displayName: Red Hat Operators
  7. カタログイメージから、利用可能な最新の servicemeshoperator およびその依存関係を解決するサブスクリプションを作成します。

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: servicemeshoperator
      namespace: my-ns
    spec:
      source: custom-redhat-operators
      sourceNamespace: my-ns
      name: servicemeshoperator
      channel: "1.0"