4.10. ネットワークが制限された環境での Operator Lifecycle Manager の使用
ネットワークが制限された環境 ( 非接続クラスター としても知られる) にインストールされている OpenShift Container Platform クラスターの場合、デフォルトで Operator Lifecycle Manager (OLM) はリモートレジストリーでホストされる Red Hat が提供する OperatorHub ソースにアクセスできません。それらのリモートソースには完全なインターネット接続が必要であるためです。
ただし、クラスター管理者は、完全なインターネットアクセスのあるワークステーションがある場合には、クラスターがネットワークが制限された環境で OLM を使用できるようにできます。ワークステーションは、リモートソースのローカルミラーを準備するために使用され、コンテンツをミラーレジストリーにプッシュしますが、これにはリモートの OperatorHub コンテンツをプルするのに完全なインターネットアクセスが必要になります。
ミラーレジストリーは bastion ホストに配置することができます。bastion ホストには、ワークステーションと非接続クラスターの両方への接続、または完全に切断されたクラスター、またはミラーリングされたコンテンツを非接続環境に物理的に移動するためにリムーバブルメディアが必要な エアギャップ ホストへの接続が必要です。
以下では、ネットワークが制限された環境で OLM を有効にするために必要な以下のプロセスについて説明します。
- OLM のデフォルトのリモート OperatorHub ソースを無効にします。
- 完全なインターネットアクセスのあるワークステーションを使用して、OperatorHub コンテンツのローカルミラーを作成し、これをミラーレジストリーにプッシュします。
- OLM を、デフォルトのリモートソースからではなくミラーレジストリーのローカルソースから Operator をインストールし、管理するように設定します。
ネットワークが制限された環境で OLM を有効にした後も、引き続き制限のないワークステーションを使用して、Operator の新しいバージョンが更新されるとローカルの OperatorHub ソースを更新された状態に維持することができます。
OLM はローカルソースから Operator を管理できますが、特定の Operator がネットワークが制限された環境で正常に実行されるかどうかは、Operator 自体が次の基準を満たすかどうかに依存します。
-
関連するイメージ、または Operator がそれらの機能を実行するために必要となる可能性のある他のコンテナーイメージを
ClusterServiceVersion(CSV) オブジェクトのrelatedImagesパラメーターで一覧表示します。 - 指定されたすべてのイメージを、タグではなくダイジェスト (SHA) で参照します。
Red Hat エコシステムカタログ でソフトウェアを検索して、以下の選択肢でフィルタリングすることにより、非接続モードでの実行をサポートする Red Hat Operator のリストを見つけることができます。
| 型 | コンテナー化されたアプリケーション |
| デプロイメント方法 | Operator |
| インフラストラクチャー機能 | オフラインインストール |
4.10.1. 前提条件
-
cluster-admin権限を持つユーザーとして OpenShift Container Platform クラスターにログインします。
IBM zSystems のネットワークが制限された環境で OLM を使用している場合は、レジストリーを配置するディレクトリーに 12 GB 以上を割り当てる必要があります。
4.10.2. デフォルトの OperatorHub カタログソースの無効化
Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。その後、OperatorHub をローカルカタログソースを使用するように設定できます。
手順
disableAllDefaultSources: trueをOperatorHubオブジェクトに追加して、デフォルトカタログのソースを無効にします。$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
または、Web コンソールを使用してカタログソースを管理できます。Administration → Cluster Settings → Configuration → OperatorHub ページから、Sources タブをクリックして、個別のソースを作成し、削除し、無効にし、有効にすることができます。
4.10.3. Operator カタログのミラーリング
非接続クラスターで使用する Operator カタログをミラーリングする方法は、Mirroring images for a disconnected installation を参照してください。
OpenShift Container Platform 4.11 の時点で、デフォルトの Red Hat が提供する Operator カタログは、ファイルベースのカタログ形式でリリースされます。OpenShift Container Platform 4.6 から 4.10 までのデフォルトの Red Hat が提供する Operator カタログは、非推奨の SQLite データベース形式でリリースされました。
opm サブコマンド、フラグ、および SQLite データベース形式に関連する機能も非推奨となり、今後のリリースで削除されます。機能は引き続きサポートされており、非推奨の SQLite データベース形式を使用するカタログに使用する必要があります。
opm index prune などの SQLite データベース形式を使用する opm サブコマンドおよびフラグの多くは、ファイルベースのカタログ形式では機能しません。ファイルベースのカタログの使用について、詳細は Operator Framework パッケージ形式、カスタムカタログの管理、および oc-mirror プラグインを使用した非接続インストールのイメージのミラーリング を参照してください。
4.10.4. クラスターへのカタログソースの追加
カタログソースを OpenShift Container Platform クラスターに追加すると、ユーザーの Operator の検出およびインストールが可能になります。クラスター管理者は、インデックスイメージを参照する CatalogSource オブジェクトを作成できます。OperatorHub はカタログソースを使用してユーザーインターフェイスを設定します。
前提条件
- レジストリーにビルドされ、プッシュされるインデックスイメージ。
手順
インデックスイメージを参照する
CatalogSourceオブジェクトを作成します。oc adm catalog mirrorコマンドを使用してカタログをターゲットレジストリーにミラーリングする場合、manifests ディレクトリーに生成されるcatalogSource.yamlファイルを開始点としてそのまま使用することができます。仕様を以下のように変更し、これを
catalogSource.yamlファイルとして保存します。apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: my-operator-catalog 1 namespace: openshift-marketplace 2 spec: sourceType: grpc grpcPodConfig: securityContextConfig: <security_mode> 3 image: <registry>/<namespace>/redhat-operator-index:v4.12 4 displayName: My Operator Catalog publisher: <publisher_name> 5 updateStrategy: registryPoll: 6 interval: 30m
- 1
- レジストリーにアップロードする前にローカルファイルにコンテンツをミラーリングする場合は、
metadata.nameフィールドからバックスラッシュ (/) 文字を削除し、オブジェクトの作成時に invalid resource name エラーを回避します。 - 2
- カタログソースを全 namespace のユーザーがグローバルに利用できるようにする場合は、
openshift-marketplacenamespace を指定します。それ以外の場合は、そのカタログの別の namespace を対象とし、その namespace のみが利用できるように指定できます。 - 3
legacyまたはrestrictedの値を指定します。フィールドが設定されていない場合、デフォルト値はlegacyです。今後の OpenShift Container Platform リリースでは、デフォルト値がrestrictedになる予定です。restricted権限でカタログを実行できない場合は、このフィールドを手動でlegacyに設定することを推奨します。- 4
- インデックスイメージを指定します。イメージ名の後にタグを指定した場合 (
:v4.11など)、カタログソース Pod はAlwaysのイメージプルポリシーを使用します。これは、Pod が常にコンテナーを開始する前にイメージをプルすることを意味します。@sha256:<id>などのダイジェストを指定した場合、イメージプルポリシーはIfNotPresentになります。これは、イメージがノード上にまだ存在しない場合にのみ、Pod がイメージをプルすることを意味します。 - 5
- カタログを公開する名前または組織名を指定します。
- 6
- カタログソースは新規バージョンの有無を自動的にチェックし、最新の状態を維持します。
このファイルを使用して
CatalogSourceオブジェクトを作成します。$ oc apply -f catalogSource.yaml
以下のリソースが正常に作成されていることを確認します。
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
カタログソースを確認します。
$ oc get catalogsource -n openshift-marketplace
出力例
NAME DISPLAY TYPE PUBLISHER AGE my-operator-catalog My Operator Catalog grpc 5s
パッケージマニフェストを確認します。
$ oc get packagemanifest -n openshift-marketplace
出力例
NAME CATALOG AGE jaeger-product My Operator Catalog 93s
OpenShift Container Platform Web コンソールで、OperatorHub ページから Operator をインストールできるようになりました。
4.10.5. SQLite ベースのインデックスイメージの更新
カスタムインデックスイメージを参照するカタログソースを使用するように OperatorHub を設定した後に、クラスター管理者はバンドルイメージをインデックスイメージに追加して、クラスターで利用可能な Operator を最新の状態に維持することができます。
opm index add コマンドを使用して既存インデックスイメージを更新できます。ネットワークが制限された環境の場合、更新されたコンテンツもクラスターにミラーリングする必要があります。
前提条件
-
opm -
podmanversion 1.9.3+ - レジストリーにビルドされ、プッシュされるインデックスイメージ。
- インデックスイメージを参照する既存のカタログソース。
手順
バンドルイメージを追加して、既存のインデックスを更新します。
$ opm index add \ --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \1 --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \2 --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \3 --pull-tool podman 4ここでは、以下のようになります。
<registry>-
quay.ioやmirror.example.comなどのレジストリーのホスト名を指定します。 <namespace>-
ocs-devやabcなど、レジストリーの namespace を指定します。 <new_bundle_image>-
ocs-operatorなど、レジストリーに追加する新しいバンドルイメージを指定します。 <digest>-
c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41などのバンドルイメージの SHA イメージ ID またはダイジェストを指定します。 <existing_index_image>-
abc-redhat-operator-indexなど、以前にプッシュされたイメージを指定します。 <existing_tag>-
4.12など、以前にプッシュされたイメージタグを指定します。 <updated_tag>-
4.12.1など、更新されたインデックスイメージに適用するイメージタグを指定します。
コマンドの例
$ opm index add \ --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \ --from-index mirror.example.com/abc/abc-redhat-operator-index:4.12 \ --tag mirror.example.com/abc/abc-redhat-operator-index:4.12.1 \ --pull-tool podman更新されたインデックスイメージをプッシュします。
$ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>
Operator カタログのミラーリングの手順にあるステップを再度実行し、更新されたコンテンツをミラーリングします。ただし、
ImageContentSourcePolicy(ICSP) オブジェクトの作成手順を参照する場合、oc createコマンドの代わりにoc replaceコマンドを使用します。以下に例を示します。$ oc replace -f ./manifests-redhat-operator-index-<random_number>/imageContentSourcePolicy.yaml
この変更は、オブジェクトがすでに存在し、更新する必要があるために必要になります。
注記通常、
oc applyコマンドを使用して、oc applyを使用して以前に作成された既存のオブジェクトを更新できます。ただし、ICSP オブジェクトのmetadata.annotationsフィールドのサイズに関する既知の問題により、現時点ではoc replaceコマンドをこの手順で使用する必要があります。Operator Lifecycle Manager (OLM) がカタログソースで参照されるインデックスイメージを一定間隔で自動的にポーリングした後に、新規パッケージが正常に追加されたことを確認します。
$ oc get packagemanifests -n openshift-marketplace
関連情報