拡張機能


OpenShift Container Platform 4.17

Operator Lifecycle Manager (OLM) v1 を使用した、OpenShift Container Platform 拡張機能の操作方法。OLM v1 は、テクノロジープレビュー機能です。

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、OpenShift Container Platform の拡張機能と Operator のインストール、管理、および設定に関する情報を提供します。Operator Lifecycle Manager (OLM) v1 はテクノロジープレビュー機能です。

第1章 拡張機能の概要

重要

Operator Lifecycle Manager (OLM) v1 はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

拡張機能により、クラスター管理者は OpenShift Container Platform クラスター上のユーザーの機能を拡張できます。

Operator Lifecycle Manager (OLM) は、最初のリリースから OpenShift Container Platform 4 に含まれています。OpenShift Container Platform 4.17 には、一般提供 (GA) 機能として OLM の次世代イテレーションのコンポーネントが含まれており、このフェーズでは OLM v1 と呼ばれています。この更新されたフレームワークは、OLM の以前のバージョンの一部であった概念の多くを進化させ、新しい機能を追加します。

1.1. 主な特徴

管理者は次の主要項目の詳細を確認できます。

GitOps ワークフローをサポートする完全な宣言型モデル

OLM v1 は、次の 2 つの主要 API を通じて拡張機能の管理を簡素化します。

  • 新しい ClusterExtension API は、ユーザー向け API を単一のオブジェクトに統合することで、registry+v1 バンドル形式を介した Operator などのインストール済み拡張機能の管理を効率化します。この API は、新しい Operator Controller コンポーネントによって clusterextension.olm.operatorframework.io として提供されます。管理者と SRE は、この API を使用してプロセスを自動化し、GitOps の原則に基づき望ましい状態を定義できます。

    注記

    OLM v1 の以前のテクノロジープレビューフェーズでは、新しい Operator API が導入されました。この API は、OpenShift Container Platform 4.16 で ClusterExtension に名前が変更され、以下の改善が加えられました。

    • クラスターの機能を拡張する簡素化された機能をより正確に反映します。
    • より柔軟なパッケージ形式をより良く表現します。
    • 接頭辞 Cluster は、ClusterExtension オブジェクトがクラスタースコープであることを明確に示します。これは、Operator が namespace スコープまたはクラスタースコープのいずれかになる可能性がある既存の OLM からの変更です。
  • 新しい catalogd コンポーネントによって提供される Catalog API は、OLM v1 の基盤として機能し、クラスター上のクライアント用にカタログを展開して、ユーザーが Kubernetes 拡張機能や Operator などのインストール可能なコンテンツを検出できるようにします。これにより、詳細、チャネル、更新エッジなど、利用可能なすべての Operator バンドルバージョンの可視性が向上します。
重要

現在、Operator Lifecycle Manager (OLM) v1 は、Red Hat が提供する Operator カタログなどのプライベートレジストリーを認証できません。これは既知の問題です。その結果、Red Hat Operators カタログがインストールされていることを前提とする OLM v1 の手順は機能しません。(OCPBUGS-36364)

詳細は、Operator ControllerCatalogd を参照してください。

拡張更新の制御の改善
カタログの内容に対する洞察が向上したため、管理者はインストールと更新のターゲットバージョンを指定できます。これにより、管理者は拡張機能の更新の対象バージョンをより細かく制御できるようになります。詳細は、クラスター拡張機能の更新 を参照してください。
柔軟な拡張機能パッケージ形式

管理者は、既存の OLM エクスペリエンスと同様に、ファイルベースのカタログを使用して、OLM ベースの Operator などの拡張機能をインストールおよび管理できます。

さらに、バンドルサイズは etcd 値のサイズ制限によって制限されなくなりました。詳細は、拡張機能のインストール を参照してください。

安全なカタログ通信
OLM v1 は catalogd サーバー応答に HTTPS 暗号化を使用します。

1.2. 目的

Operator Lifecycle Manager (OLM) の使命は、Kubernetes クラスター上でクラスター拡張機能のライフサイクルを一元的かつ宣言的に管理することです。これは、基盤となるクラスターのライフサイクル全体を通じて、クラスターおよび PaaS (platform-as-a-service) 管理者によるクラスターへの機能拡張のインストール、実行、更新を簡単、安全、再現可能にすることを目的としています。

OpenShift Container Platform 4 で導入された OLM の初期バージョン (デフォルトで含まれています) は、クラスター機能拡張に対するこのような具体的なニーズを、独自の方法でサポートすることを重視していました。それが Operator です。Operator は 1 つ以上の Kubernetes コントローラーとして分類され、クラスターに追加機能を提供するための CustomResourceDefinition (CRD) オブジェクトとして、1 つ以上の API 機能拡張とともに出荷されます。

多くのリリースにおいて実稼働クラスターで実行された後、次世代の OLM では単なる Operator ではないクラスター機能拡張のライフサイクルを包含することを目指しています。

第2章 アーキテクチャー

2.1. OLM v1 コンポーネントの概要

重要

Operator Lifecycle Manager (OLM) v1 はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

Operator Lifecycle Manager (OLM) v1 は、次のコンポーネントプロジェクトで構成されています。

Operator Controller
Operator Controller は OLM v1 の中心的なコンポーネントで、API を使用して Kubernetes を拡張します。ユーザーはこれを使用して、Operator や拡張機能をインストールし、そのライフサイクルを管理できます。カタログから情報を使用します。
Catalogd
Catalogd は、クラスター上のクライアントが使用する、コンテナーイメージにパッケージ化されて出荷されるファイルベースのカタログ (FBC) コンテンツを展開する Kubernetes 拡張機能です。OLM v1 マイクロサービスアーキテクチャーのコンポーネントである catalogd は、Kubernetes 拡張機能の作成者がパッケージ化した拡張機能のメタデータをホストします。これは、ユーザーがインストール可能なコンテンツを発見するのに役立ちます。

2.2. Operator Controller

重要

Operator Lifecycle Manager (OLM) v1 はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

Operator Controller は、Operator Lifecycle Manager (OLM) v1 の中心的なコンポーネントであり、他の OLM v1 コンポーネント (catalogd) を使用します。Operator Controller は API で Kubernetes を拡張し、これを通してユーザーは Operator や機能拡張をインストールできます。

2.2.1. ClusterExtension API

Operator Controller は、インストールされた拡張機能のインスタンスを表す単一のリソースである新しい ClusterExtension API オブジェクトを提供します。これには、registry+v1 バンドル形式を介した Operator などが含まれます。この clusterextension.olm.operatorframework.io API は、ユーザー向け API を 1 つのオブジェクトに統合することで、インストールされた拡張機能の管理を効率化します。

重要

OLM v1 では、ClusterExtension オブジェクトはクラスタースコープです。これは、関連する Subscription および OperatorGroup オブジェクトの設定に応じて、Operator が namespace スコープまたはクラスタースコープのいずれかになる可能性がある既存の OLM とは異なります。

以前の動作の詳細は、マルチテナンシーと Operator のコロケーション を参照してください。

ClusterExtension オブジェクトの例

apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
  name: <operator_name>
spec:
  packageName: <package_name>
  installNamespace: <namespace_name>
  channel: <channel_name>
  version: <version_number>
Copy to Clipboard Toggle word wrap

2.2.1.1. ターゲットバージョンを指定するカスタムリソース (CR) の例

Operator Lifecycle Manager (OLM) v1 では、クラスター管理者はカスタムリソース (CR) で Operator または拡張機能のターゲットバージョンを宣言的に設定できます。

次のフィールドのいずれかを指定して、ターゲットバージョンを定義できます。

  • チャネル
  • バージョン番号
  • バージョン範囲

CR でチャネルを指定すると、OLM v1 は、指定されたチャネル内で解決できる最新バージョンの Operator または拡張機能をインストールします。指定されたチャネルに更新が公開されると、OLM v1 はそのチャネルから解決できる最新リリースに自動的に更新します。

チャネルを指定した CR の例

apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  installNamespace: <namespace_name>
  serviceAccount:
    name: <service_account>
  channel: latest 
1
Copy to Clipboard Toggle word wrap

1
指定されたチャネルから解決できる最新リリースをインストールします。チャネルへの更新は自動的にインストールされます。

CR で Operator または拡張機能のターゲットバージョンを指定すると、OLM v1 は指定されたバージョンをインストールします。CR でターゲットバージョンが指定されている場合、カタログに更新が公開されても OLM v1 はターゲットバージョンを変更しません。

クラスターにインストールされている Operator のバージョンを更新する必要がある場合は、Operator の CR を手動で編集する必要があります。Operator のターゲットバージョンを指定すると、Operator のバージョンが指定されたリリースに固定されます。

ターゲットバージョンを指定した CR の例

apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  installNamespace: <namespace_name>
  serviceAccount:
    name: <service_account>
  version: "1.11.1" 
1
Copy to Clipboard Toggle word wrap

1
ターゲットのバージョンを指定します。インストールされている Operator または拡張機能のバージョンを更新する必要がある場合は、CR のこのフィールドを目的のターゲットバージョンに手動で更新する必要があります。

Operator または拡張機能の許容可能なバージョン範囲を定義する場合は、比較文字列を使用してバージョン範囲を指定できます。バージョン範囲を指定すると、OLM v1 は、Operator Controller で解決できる最新バージョンの Operator または拡張機能をインストールします。

バージョン範囲を指定した CR の例

apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  installNamespace: <namespace_name>
  serviceAccount:
    name: <service_account>
  version: ">1.11.1" 
1
Copy to Clipboard Toggle word wrap

1
必要なバージョン範囲が、バージョン 1.11.1 より大きいことを指定します。詳細は、「バージョン範囲のサポート」を参照してください。

CR を作成または更新した後、次のコマンドを実行して設定ファイルを適用します。

コマンド構文

$ oc apply -f <extension_name>.yaml
Copy to Clipboard Toggle word wrap

2.2.2. クラスター拡張機能のオブジェクト所有権

Operator Lifecycle Manager (OLM) v1 では、Kubernetes オブジェクトを所有できるのは一度に 1 つの ClusterExtension オブジェクトのみです。これにより、OpenShift Container Platform クラスター内のオブジェクトの管理が一貫し、同じオブジェクトを制御しようとする複数のクラスター拡張機能間の競合が防止されます。

2.2.2.1. 単独所有

OLM v1 は、各オブジェクトは所有者としてクラスター拡張機能を 1 つだけ持つことができる、というコア所有の原則を強制します。これにより、複数のクラスター拡張機能による管理の重複や競合が防止され、各オブジェクトが 1 つのバンドルにのみ一意に関連付けられることが保証されます。

単独所有の影響

  • CustomResourceDefinition (CRD) オブジェクトを提供するバンドルは、一度だけインストールできます。

    バンドルは、ClusterExtension オブジェクトの一部である CRD を提供します。つまり、クラスターには 1 回限定でバンドルをインストールできます。各カスタムリソースは所有者として 1 つのクラスター拡張機能のみを持つことができるため、同じ CRD を提供する別のバンドルをインストールしようとすると失敗します。

  • クラスター拡張機能はオブジェクトを共有できません。

    OLM v1 の単独所有ポリシーは、クラスター拡張機能がオブジェクトの所有権を共有できないことを意味します。1 つのクラスター拡張機能が DeploymentCustomResourceDefinitionService オブジェクトなどの特定のオブジェクトを管理する場合、別のクラスター拡張機能は同じオブジェクトの所有権を主張できません。そのような試みは、すべて OLM v1 によってブロックされます。

2.2.2.2. エラーメッセージ

複数のクラスター拡張機能が同じオブジェクトを管理しようとして競合が発生した場合、Operator Controller は次のような所有権の競合を示すエラーメッセージを返します。

エラーメッセージの例

CustomResourceDefinition 'logfilemetricexporters.logging.kubernetes.io' already exists in namespace 'kubernetes-logging' and cannot be managed by operator-controller
Copy to Clipboard Toggle word wrap

このエラーメッセージは、オブジェクトがすでに別のクラスター拡張機能によって管理されており、再割り当てまたは共有できないことを示します。

2.2.2.3. 留意事項

クラスターまたは拡張機能の管理者は、次の留意事項を確認する必要があります。

バンドルの一意性
同じ CRD を提供する Operator バンドルが複数回インストールされていないことを確認します。これにより、所有権の競合によるインストール失敗の可能性を回避できます。
オブジェクトの共有回避
類似のリソースと対話するために異なるクラスター拡張機能が必要な場合は、それらが別々のオブジェクトを管理していることを確認します。単独所有の強制により、クラスター拡張機能は同じオブジェクトを共同で管理できません。

2.3. Catalogd

重要

Operator Lifecycle Manager (OLM) v1 はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

Operator Lifecycle Manager (OLM) v1 は、catalogd コンポーネントとそのリソースを使用して、Operator カタログと機能拡張カタログを管理します。

重要

現在、Operator Lifecycle Manager (OLM) v1 は、Red Hat が提供する Operator カタログなどのプライベートレジストリーを認証できません。これは既知の問題です。その結果、Red Hat Operators カタログがインストールされていることを前提とする OLM v1 の手順は機能しません。(OCPBUGS-36364)

2.3.1. OLM v1 のカタログについて

catalogd コンポーネントを使用して、Operator やコントローラーなどの Kubernetes 拡張機能のカタログをクエリーすることで、インストール可能なコンテンツを検出できます。catalogd は、クラスター上のクライアント用にカタログコンテンツを展開する Kubernetes 機能拡張であり、マイクロサービスの Operator Lifecycle Manager (OLM) v1 スイートの一部です。現在、catalogd は、コンテナーイメージとしてパッケージ化および配布されているカタログコンテンツを解凍します。

重要

一意の名前を持たない Operator または拡張機能をインストールしようとすると、インストールが失敗するか、予期しない結果になる可能性があります。その原因は以下のとおりです。

  • クラスターに複数のカタログがインストールされている場合、Operator Lifecycle Manager (OLM) v1 には、Operator または拡張機能のインストール時にカタログを指定するメカニズムがありません。
  • OLM v1 では、クラスターにインストールできるすべての Operator および拡張機能のバンドルとパッケージに、一意の名前が使用されている必要があります。

第3章 一般的な Operator Framework 用語

重要

Operator Lifecycle Manager (OLM) v1 はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

以下は、Operator Framework に関連する用語で、そこには Operator Lifecycle Manager (OLM) v1 も含まれています。

3.1. バンドル

Bundle Format では、バンドル は Operator CSV、マニフェスト、およびメタデータのコレクションです。さらに、それらはクラスターにインストールできる一意のバージョンの Operator を形成します。

3.2. バンドルイメージ

Bundle Format では、バンドルイメージ は Operator マニフェストからビルドされ、1 つのバンドルが含まれるコンテナーイメージです。バンドルイメージは、Quay.io または DockerHub などの Open Container Initiative (OCI) 仕様コンテナーレジストリーによって保存され、配布されます。

3.3. カタログソース

カタログソース は、OLM が Operator およびそれらの依存関係を検出し、インストールするためにクエリーできるメタデータのストアを表します。

3.4. チャネル

チャネル は Operator の更新ストリームを定義し、サブスクライバーの更新をロールアウトするために使用されます。ヘッドはそのチャネルの最新バージョンを参照します。たとえば stable チャネルには、Operator のすべての安定したバージョンが最も古いものから最新のものへと編成されます。

Operator には複数のチャネルを含めることができ、特定のチャネルへのサブスクリプションのバインドはそのチャネル内の更新のみを検索します。

3.5. チャネルヘッド

チャネルヘッド は、特定のチャネル内の最新の既知の更新を指します。

3.6. クラスターサービスバージョン

クラスターサービスバージョン (CSV) は、クラスターでの Operator の実行に使用される Operator メタデータから作成される YAML マニフェストです。これは、ユーザーインターフェイスにロゴ、説明、およびバージョンなどの情報を設定するために使用される Operator コンテナーイメージに伴うメタデータです。

CSV は、Operator が必要とする RBAC ルールやそれが管理したり、依存したりするカスタムリソース (CR) などの Operator の実行に必要な技術情報の情報源でもあります。

3.7. 依存関係

Operator はクラスターに存在する別の Operator への 依存関係 を持つ場合があります。たとえば、Vault Operator にはそのデータ永続層について etcd Operator への依存関係があります。

OLM は、インストールフェーズで指定されたすべてのバージョンの Operator および CRD がクラスターにインストールされていることを確認して依存関係を解決します。この依存関係は、必要な CRD API を満たすカタログの Operator を検索し、インストールすることで解決され、パッケージまたはバンドルには関連しません。

3.8. インデックスイメージ

Bundle Format で、インデックスイメージ は、すべてのバージョンの CSV および CRD を含む Operator バンドルに関する情報が含まれるデータベースのイメージ (データベーススナップショット) を指します。このインデックスは、クラスターで Operator の履歴をホストでき、opm CLI ツールを使用して Operator を追加または削除することで維持されます。

3.9. インストール計画

インストール計画 は、CSV を自動的にインストールするか、アップグレードするために作成されるリソースの計算された一覧です。

3.10. マルチテナントへの対応

OpenShift Container Platform の テナント は、通常は namespace またはプロジェクトによって表される、一連のデプロイされたワークロードに対する共通のアクセスと権限を共有するユーザーまたはユーザーのグループです。テナントを使用して、異なるグループまたはチーム間に一定レベルの分離を提供できます。

クラスターが複数のユーザーまたはグループによって共有されている場合、マルチテナント クラスターと見なされます。

3.11. Operator グループ

Operator グループ は、OperatorGroup オブジェクトと同じ namespace にデプロイされたすべての Operator を、namespace のリストまたはクラスター全体でそれらの CR を監視できるように設定します。

3.12. Package

Bundle Format で、パッケージ は Operator のリリースされたすべての履歴をそれぞれのバージョンで囲むディレクトリーです。Operator のリリースされたバージョンは、CRD と共に CSV マニフェストに記述されます。

3.13. レジストリー

レジストリー は、Operator のバンドルイメージを保存するデータベースで、それぞれにすべてのチャネルの最新バージョンおよび過去のバージョンすべてが含まれます。

3.14. サブスクリプション

サブスクリプション は、パッケージのチャネルを追跡して CSV を最新の状態に保ちます。

3.15. 更新グラフ

更新グラフ は、他のパッケージ化されたソフトウェアの更新グラフと同様に、CSV の複数のバージョンを 1 つにまとめます。Operator を順番にインストールすることも、特定のバージョンを省略することもできます。更新グラフは、新しいバージョンが追加されている状態でヘッドでのみ拡張することが予想されます。

第4章 カタログ

4.1. ファイルベースのカタログ

重要

Operator Lifecycle Manager (OLM) v1 はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

OpenShift Container Platform の Operator Lifecycle Manager (OLM) v1 は、クラスター上のクラスター拡張機能 (Operator を含む) を検出および取得するために使用する ファイルベースのカタログ をサポートします。

重要

現在、Operator Lifecycle Manager (OLM) v1 は、Red Hat が提供する Operator カタログなどのプライベートレジストリーを認証できません。これは既知の問題です。その結果、Red Hat Operators カタログがインストールされていることを前提とする OLM v1 の手順は機能しません。(OCPBUGS-36364)

4.1.1. 主な特徴

ファイルベースのカタログは、Operator Lifecycle Manager(OLM) のカタログ形式の最新の反復になります。この形式は、プレーンテキストベース (JSON または YAML) であり、以前の SQLite データベース形式の宣言的な設定の進化であり、完全な下位互換性があります。この形式の目標は、Operator のカタログ編集、設定可能性、および拡張性を有効にすることです。

編集

ファイルベースのカタログを使用すると、カタログの内容を操作するユーザーは、形式を直接変更し、変更が有効であることを確認できます。この形式はプレーンテキストの JSON または YAML であるため、カタログメンテナーは、一般的に知られている、サポート対象の JSON または YAML ツール (例: jq CLI) を使用して、手動でカタログメタデータを簡単に操作できます。

この編集機能により、以下の機能とユーザー定義の拡張が有効になります。

  • 既存のバンドルの新規チャネルへのプロモート
  • パッケージのデフォルトチャネルの変更
  • アップグレードエッジを追加、更新、および削除するためのカスタムアルゴリズム
コンポーザービリティー

ファイルベースのカタログは、任意のディレクトリー階層に保管され、カタログの作成が可能になります。たとえば、2 つのファイルベースのカタログディレクトリー (catalogA および catalogB ) を見てみましょう。カタログメンテナーは、新規のディレクトリー catalogC を作成して catalogAcatalogB をそのディレクトリーにコピーし、新しく結合カタログを作成できます。

このコンポーザービリティーにより、カタログの分散化が可能になります。この形式により、Operator の作成者は Operator 固有のカタログを維持でき、メンテナーは個別の Operator カタログで構成されるカタログを簡単にビルドできます。ファイルベースのカタログは、他の複数のカタログを組み合わせたり、1 つのカタログのサブセットを抽出したり、またはこれらの両方を組み合わせたりすることで作成できます。

注記

パッケージ内でパッケージおよびバンドルを重複できません。opm validate コマンドは、重複が見つかった場合はエラーを返します。

Operator の作成者は Operator、その依存関係およびそのアップグレードの互換性について最も理解しているので、Operator 固有のカタログを独自のカタログに維持し、そのコンテンツを直接制御できます。ファイルベースのカタログの場合に、Operator の作成者はカタログでパッケージをビルドして維持するタスクを所有します。ただし、複合カタログメンテナーは、カタログ内のパッケージのキュレートおよびユーザーにカタログを公開するタスクのみを所有します。

拡張性

ファイルベースのカタログ仕様は、カタログの低レベル表現です。これは低レベルの形式で直接保守できますが、カタログメンテナーは、このレベルの上に任意の拡張をビルドして、独自のカスタムツールを使用して任意数の変更を加えることができます。

たとえば、ツールは (mode=semver) などの高レベルの API を、アップグレードエッジ用に低レベルのファイルベースのカタログ形式に変換できます。または、カタログ保守担当者は、特定の条件を満たすバンドルに新規プロパティーを追加して、すべてのバンドルメタデータをカスタマイズする必要がある場合があります。

このような拡張性を使用すると、今後の OpenShift Container Platform リリース向けに、追加の正式なツールを下層の API 上で開発できますが、主な利点として、カタログメンテナーにもこの機能がある点が挙げられます。

4.1.2. ディレクトリー構造

ファイルベースのカタログは、ディレクトリーベースのファイルシステムから保存してロードできます。opm CLI は、root ディレクトリーを元に、サブディレクトリーに再帰してカタログを読み込みます。CLI は、検出されるすべてのファイルの読み込みを試行し、エラーが発生した場合には失敗します。

.gitignore ファイルとパターンと優先順位が同じ .indexignore ファイルを使用して、カタログ以外のファイルを無視できます。

例: .indexignore ファイル

# Ignore everything except non-object .json and .yaml files
**/*
!*.json
!*.yaml
**/objects/*.json
**/objects/*.yaml
Copy to Clipboard Toggle word wrap

カタログメンテナーは、必要なレイアウトを柔軟に選択できますが、各パッケージのファイルベースのカタログ Blob は別々のサブディレクトリーに保管することを推奨します。個々のファイルは JSON または YAML のいずれかをしようしてください。カタログ内のすべてのファイルが同じ形式を使用する必要はありません。

推奨される基本構造

catalog
├── packageA
│   └── index.yaml
├── packageB
│   ├── .indexignore
│   ├── index.yaml
│   └── objects
│       └── packageB.v0.1.0.clusterserviceversion.yaml
└── packageC
    └── index.json
    └── deprecations.yaml
Copy to Clipboard Toggle word wrap

この推奨の構造には、ディレクトリー階層内の各サブディレクトリーは自己完結型のカタログであるという特性があるので、カタログの作成、検出、およびナビゲーションなどのファイルシステムの操作が簡素化されます。このカタログは、親カタログのルートディレクトリーにコピーして親カタログに追加することもできます。

4.1.3. スキーマ

ファイルベースのカタログは、任意のスキーマで拡張できる CUE 言語仕様 に基づく形式を使用します。以下の _Meta CUE スキーマは、すべてのファイルベースのカタログ Blob が順守する必要のある形式を定義します。

_Meta スキーマ

_Meta: {
  // schema is required and must be a non-empty string
  schema: string & !=""

  // package is optional, but if it's defined, it must be a non-empty string
  package?: string & !=""

  // properties is optional, but if it's defined, it must be a list of 0 or more properties
  properties?: [... #Property]
}

#Property: {
  // type is required
  type: string & !=""

  // value is required, and it must not be null
  value: !=null
}
Copy to Clipboard Toggle word wrap

注記

この仕様にリストされている CUE スキーマは網羅されていると見なされます。opm validate コマンドには、CUE で簡潔に記述するのが困難または不可能な追加の検証が含まれます。

Operator Lifecycle Manager(OLM) カタログは、現時点で OLM の既存のパッケージおよびバンドルの概念に対応する 3 つのスキーマ (olm.packageolm.channel および olm.bundle) を使用します。

カタログの各 Operator パッケージには、olm.package Blob が 1 つ (少なくとも olm.channel Blob 1 つ、および 1 つ以上の olm.bundle Blob) が必要です。

注記

olm.* スキーマは OLM 定義スキーマ用に予約されています。カスタムスキーマには、所有しているドメインなど、一意の接頭辞を使用する必要があります。

4.1.3.1. olm.package スキーマ

olm.package スキーマは Operator のパッケージレベルのメタデータを定義します。これには、名前、説明、デフォルトのチャネル、およびアイコンが含まれます。

例4.1 olm.package スキーマ

#Package: {
  schema: "olm.package"

  // Package name
  name: string & !=""

  // A description of the package
  description?: string

  // The package's default channel
  defaultChannel: string & !=""

  // An optional icon
  icon?: {
    base64data: string
    mediatype:  string
  }
}
Copy to Clipboard Toggle word wrap
4.1.3.2. olm.channel スキーマ

olm.channel スキーマは、パッケージ内のチャネル、チャネルのメンバーであるバンドルエントリー、およびそれらのバンドルのアップグレードエッジを定義します。

バンドルエントリーが複数の olm.channel Blob 内のエッジを表す場合、バンドルエントリーはチャネルごとに 1 つだけ指定できます。

エントリーの replaces 値が、このカタログにも別のカタログにも存在しない別のバンドル名を参照していても、有効とされます。ただし、他のすべてのチャネルの普遍条件に該当する必要があります (チャネルに複数のヘッドがない場合など)。

例4.2 olm.channel スキーマ

#Channel: {
  schema: "olm.channel"
  package: string & !=""
  name: string & !=""
  entries: [...#ChannelEntry]
}

#ChannelEntry: {
  // name is required. It is the name of an `olm.bundle` that
  // is present in the channel.
  name: string & !=""

  // replaces is optional. It is the name of bundle that is replaced
  // by this entry. It does not have to be present in the entry list.
  replaces?: string & !=""

  // skips is optional. It is a list of bundle names that are skipped by
  // this entry. The skipped bundles do not have to be present in the
  // entry list.
  skips?: [...string & !=""]

  // skipRange is optional. It is the semver range of bundle versions
  // that are skipped by this entry.
  skipRange?: string & !=""
}
Copy to Clipboard Toggle word wrap
警告

skipRange フィールドを使用すると、スキップされた Operator バージョンが更新グラフからプルーニングされ、ユーザーが Subscription オブジェクトの spec.startingCSV プロパティーを使用してそのバージョンをインストールできなくなります。

skipRange フィールドと replaces フィールドの両方を使用すると、以前にインストールしたバージョンをユーザーが将来インストールできるように維持しながら、Operator を段階的に更新できます。replaces フィールドが当該 Operator バージョンの直前のバージョンを参照していることを確認してください。

4.1.3.3. olm.bundle スキーマ

例4.3 olm.bundle スキーマ

#Bundle: {
  schema: "olm.bundle"
  package: string & !=""
  name: string & !=""
  image: string & !=""
  properties: [...#Property]
  relatedImages?: [...#RelatedImage]
}

#Property: {
  // type is required
  type: string & !=""

  // value is required, and it must not be null
  value: !=null
}

#RelatedImage: {
  // image is the image reference
  image: string & !=""

  // name is an optional descriptive name for an image that
  // helps identify its purpose in the context of the bundle
  name?: string & !=""
}
Copy to Clipboard Toggle word wrap
4.1.3.4. olm.deprecations スキーマ

オプションの olm.deprecations スキーマは、カタログ内のパッケージ、バンドル、チャネルの非推奨情報を定義します。Operator の作成者は、このスキーマを使用して、サポートステータスや推奨アップグレードパスなど、Operator に関する関連メッセージを、カタログから Operator を実行しているユーザーに提供できます。

このスキーマが定義されている場合、OpenShift Container Platform の Web コンソールで、OperatorHub のインストール前ページとインストール後ページの両方に、カスタムの非推奨メッセージを含め、Operator の影響を受ける要素に対する警告バッジが表示されます。

olm.deprecations スキーマエントリーには、非推奨の範囲を示す次の reference タイプが 1 つ以上含まれています。Operator がインストールされると、指定されたメッセージが、関連する Subscription オブジェクトのステータス状況として表示されます。

Expand
表4.1 非推奨の reference タイプ
Scopeステータス状況

olm.package

パッケージ全体を表します。

PackageDeprecated

olm.channel

1 つのチャンネルを表します。

ChannelDeprecated

olm.bundle

1 つのバンドルバージョンを表します。

BundleDeprecated

次の例で詳しく説明するように、各 reference タイプには独自の要件があります。

例4.4 各 reference タイプを使用した olm.deprecations スキーマの例

schema: olm.deprecations
package: my-operator 
1

entries:
  - reference:
      schema: olm.package 
2

    message: | 
3

    The 'my-operator' package is end of life. Please use the
    'my-operator-new' package for support.
  - reference:
      schema: olm.channel
      name: alpha 
4

    message: |
    The 'alpha' channel is no longer supported. Please switch to the
    'stable' channel.
  - reference:
      schema: olm.bundle
      name: my-operator.v1.68.0 
5

    message: |
    my-operator.v1.68.0 is deprecated. Uninstall my-operator.v1.68.0 and
    install my-operator.v1.72.0 for support.
Copy to Clipboard Toggle word wrap
1
各非推奨スキーマには package 値が必要であり、そのパッケージ参照はカタログ全体で一意である必要があります。関連する name フィールドを含めることはできません。
2
olm.package スキーマに name フィールドを含めることはできません。このフィールドは、スキーマ内で前に定義した package フィールドによって決定されるためです。
3
すべての message フィールドは、reference タイプを問わず、長さが 0 以外である必要があり、不透明なテキスト Blob として表す必要があります。
4
olm.channel スキーマの name フィールドは必須です。
5
olm.bundle スキーマの name フィールドは必須です。
注記

非推奨機能では、パッケージ、チャネル、バンドルなど、重複する非推奨は考慮されません。

Operator の作成者は、olm.deprecations スキーマエントリーを deprecations.yaml ファイルとしてパッケージの index.yaml ファイルと同じディレクトリーに保存できます。

非推奨を含むカタログのディレクトリー構造の例

my-catalog
└── my-operator
    ├── index.yaml
    └── deprecations.yaml
Copy to Clipboard Toggle word wrap

4.1.4. プロパティー

プロパティーは、ファイルベースのカタログスキーマに追加できる任意のメタデータです。type フィールドは、value フィールドのセマンティックおよび構文上の意味を効果的に指定する文字列です。値には任意の JSON または YAML を使用できます。

OLM は、予約済みの olm.* 接頭辞をもう一度使用して、いくつかのプロパティータイプを定義します。

4.1.4.1. olm.package プロパティー

olm.package プロパティーは、パッケージ名とバージョンを定義します。これはバンドルの必須プロパティーであり、これらのプロパティーが 1 つ必要です。packageName フィールドはバンドルのファーストクラス package フィールドと同じでなければならず、version フィールドは有効なセマンティクスバージョンである必要があります。

例4.5 olm.package プロパティー

#PropertyPackage: {
  type: "olm.package"
  value: {
    packageName: string & !=""
    version: string & !=""
  }
}
Copy to Clipboard Toggle word wrap
4.1.4.2. olm.gvk プロパティー

olm.gvk プロパティーは、このバンドルで提供される Kubernetes API の group/version/kind(GVK) を定義します。このプロパティーは、OLM が使用して、必須の API と同じ GVK をリストする他のバンドルの依存関係として、このプロパティーでバンドルを解決します。GVK は Kubernetes GVK の検証に準拠する必要があります。

例4.6 olm.gvk プロパティー

#PropertyGVK: {
  type: "olm.gvk"
  value: {
    group: string & !=""
    version: string & !=""
    kind: string & !=""
  }
}
Copy to Clipboard Toggle word wrap
4.1.4.3. olm.package.required

olm.package.required プロパティーは、このバンドルが必要な別のパッケージのパッケージ名とバージョン範囲を定義します。バンドルにリストされている必要なパッケージプロパティーごとに、OLM は、リストされているパッケージのクラスターに必要なバージョン範囲で Operator がインストールされていることを確認します。versionRange フィールドは有効なセマンティクスバージョン (semver) の範囲である必要があります。

例4.7 olm.package.required プロパティー

#PropertyPackageRequired: {
  type: "olm.package.required"
  value: {
    packageName: string & !=""
    versionRange: string & !=""
  }
}
Copy to Clipboard Toggle word wrap
4.1.4.4. olm.gvk.required

olm.gvk.required プロパティーは、このバンドルが必要とする Kubernetes API の group/version/kind(GVK) を定義します。バンドルにリストされている必要な GVK プロパティーごとに、OLM は、提供する Operator がクラスターにインストールされていることを確認します。GVK は Kubernetes GVK の検証に準拠する必要があります。

例4.8 olm.gvk.required プロパティー

#PropertyGVKRequired: {
  type: "olm.gvk.required"
  value: {
    group: string & !=""
    version: string & !=""
    kind: string & !=""
  }
}
Copy to Clipboard Toggle word wrap

4.1.5. カタログの例

ファイルベースのカタログを使用すると、カタログメンテナーは Operator のキュレーションおよび互換性に集中できます。Operator の作成者は Operator 用に Operator 固有のカタログをすでに生成しているので、カタログメンテナーは、各 Operator カタログをカタログのルートディレクトリーのサブディレクトリーにレンダリングしてビルドできます。

ファイルベースのカタログをビルドする方法は多数あります。以下の手順は、単純なアプローチの概要を示しています。

  1. カタログの設定ファイルを 1 つ維持し、カタログ内に Operator ごとにイメージの参照を含めます。

    カタログ設定ファイルのサンプル

    name: community-operators
    repo: quay.io/community-operators/catalog
    tag: latest
    references:
    - name: etcd-operator
      image: quay.io/etcd-operator/index@sha256:5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03
    - name: prometheus-operator
      image: quay.io/prometheus-operator/index@sha256:e258d248fda94c63753607f7c4494ee0fcbe92f1a76bfdac795c9d84101eb317
    Copy to Clipboard Toggle word wrap

  2. 設定ファイルを解析し、その参照から新規カタログを作成するスクリプトを実行します。

    スクリプトの例

    name=$(yq eval '.name' catalog.yaml)
    mkdir "$name"
    yq eval '.name + "/" + .references[].name' catalog.yaml | xargs mkdir
    for l in $(yq e '.name as $catalog | .references[] | .image + "|" + $catalog + "/" + .name + "/index.yaml"' catalog.yaml); do
      image=$(echo $l | cut -d'|' -f1)
      file=$(echo $l | cut -d'|' -f2)
      opm render "$image" > "$file"
    done
    opm generate dockerfile "$name"
    indexImage=$(yq eval '.repo + ":" + .tag' catalog.yaml)
    docker build -t "$indexImage" -f "$name.Dockerfile" .
    docker push "$indexImage"
    Copy to Clipboard Toggle word wrap

4.1.6. ガイドライン

ファイルベースのカタログを維持する場合には、以下のガイドラインを考慮してください。

4.1.6.1. イミュータブルなバンドル

Operator Lifecycle Manager(OLM) に関する一般的なアドバイスとして、バンドルイメージとそのメタデータをイミュータブルとして処理する必要がある点があります。

破損したバンドルがカタログにプッシュされている場合には、少なくとも 1 人のユーザーがそのバンドルにアップグレードしたと想定する必要があります。この仮定に基づいて、破損したバンドルがインストールされたユーザーがアップグレードを受信できるように、破損したバンドルから、アップグレードエッジが含まれる別のバンドルをリリースする必要があります。OLM は、カタログでバンドルの内容が更新された場合に、インストールされたバンドルは再インストールされません。

ただし、カタログメタデータの変更が推奨される場合があります。

  • チャネルプロモーション: バンドルをすでにリリースし、後で別のチャネルに追加することにした場合は、バンドルのエントリーを別の olm.channel Blob に追加できます。
  • 新規アップグレードエッジ:1.2.z バンドルバージョンを新たにリリースしたが (例:1.2.4)、1.3.0 がすでにリリースされている場合は、1.2.4 をスキップするように 1.3.0 のカタログメタデータを更新できます。
4.1.6.2. ソース制御

カタログメタデータはソースコントロールに保存され、信頼できる情報源として処理される必要があります。以下の手順で、カタログイメージを更新する必要があります。

  1. ソース制御されたカタログディレクトリーを新規コミットを使用して更新します。
  2. カタログイメージをビルドし、プッシュします。ユーザーがカタログが利用可能になり次第更新を受信できるように、一貫性のあるタグ付け (:latest or :<target_cluster_version>) を使用します。

4.1.7. CLI の使用

opm CLI を使用してファイルベースのカタログを作成する手順の詳細は、カスタムカタログの管理 を参照してください。

ファイルベースのカタログの管理に関連する opm CLI コマンドの参考情報は、CLI ツール を参照してください。

4.1.8. 自動化

Operator の作成者およびカタログメンテナーは、CI/CD ワークフローを使用してカタログのメンテナンスを自動化することが推奨されます。カタログメンテナーは、GitOps 自動化をビルドして以下のタスクを実行し、これをさらに向上させることができます。

  • パッケージのイメージ参照の更新など、プル要求 (PR) の作成者が要求された変更を実行できることを確認します。
  • カタログの更新で opm validate コマンドが指定されていることを確認します。
  • 更新されたバンドルまたはカタログイメージの参照が存在し、カタログイメージがクラスターで正常に実行され、そのパッケージの Operator が正常にインストールされることを確認します。
  • 以前のチェックに合格した PR を自動的にマージします。
  • カタログイメージを自動的にもう一度ビルドして公開します。

4.2. Red Hat が提供するカタログ

重要

Operator Lifecycle Manager (OLM) v1 はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

Red Hat は、デフォルトで OpenShift Container Platform に含まれる複数の Operator カタログを提供します。

重要

現在、Operator Lifecycle Manager (OLM) v1 は、Red Hat が提供する Operator カタログなどのプライベートレジストリーを認証できません。これは既知の問題です。その結果、Red Hat Operators カタログがインストールされていることを前提とする OLM v1 の手順は機能しません。(OCPBUGS-36364)

4.2.1. Red Hat が提供する Operator カタログについて

Red Hat が提供するカタログソースは、デフォルトで openshift-marketplace namespace にインストールされます。これにより、すべての namespace でクラスター全体でカタログを利用できるようになります。

以下の Operator カタログは Red Hat によって提供されます。

Expand
カタログインデックスイメージ説明

redhat-operators

registry.redhat.io/redhat/redhat-operator-index:v4.17

Red Hat によってパッケージ化され、出荷される Red Hat 製品。Red Hat によってサポートされます。

certified-operators

registry.redhat.io/redhat/certified-operator-index:v4.17

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

redhat-marketplace

registry.redhat.io/redhat/redhat-marketplace-index:v4.17

Red Hat Marketplace から購入できる認定ソフトウェア。

community-operators

registry.redhat.io/redhat/community-operator-index:v4.17

redhat-openshift-ecosystem/community-operators-prod/operators GitHub リポジトリーで、関連する担当者によって保守されているソフトウェア。正式なサポートはありません。

クラスターのアップグレード時に、Red Hat が提供するデフォルトのカタログソースのインデックスイメージのタグは、Operator Lifecycle Manager (OLM) が最新版のカタログをプルするように、Cluster Version Operator (CVO) により自動更新されます。たとえば、OpenShift Container Platform 4.8 から 4.9 にアップグレードする場合には、redhat-operators カタログの CatalogSource オブジェクトの spec.image フィールドは、以下から更新されます。

registry.redhat.io/redhat/redhat-operator-index:v4.8
Copy to Clipboard Toggle word wrap

更新後は次のようになります。

registry.redhat.io/redhat/redhat-operator-index:v4.9
Copy to Clipboard Toggle word wrap

4.3. カタログの管理

重要

Operator Lifecycle Manager (OLM) v1 はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

クラスター管理者は、カタログ、つまり Operator と Kubernetes 拡張機能の厳選されたコレクションをクラスターに追加できます。Operator の作成者は、自社の製品をこれらのカタログに公開します。クラスターにカタログを追加すると、カタログに公開されている Operator と拡張機能のバージョン、パッチ、無線更新にアクセスできるようになります。

カスタムリソース (CR) を使用して、CLI からカタログと拡張機能を宣言的に管理できます。

ファイルベースのカタログは、Operator Lifecycle Manager(OLM) のカタログ形式の最新の反復になります。この形式は、プレーンテキストベース (JSON または YAML) であり、以前の SQLite データベース形式の宣言的な設定の進化であり、完全な下位互換性があります。

重要

Kubernetes は定期的に特定の API を非推奨とし、後続のリリースで削除します。その結果、Operator は API を削除した Kubernetes バージョンを使用する OpenShift Container Platform のバージョン以降、削除された API を使用できなくなります。

クラスターがカスタムカタログを使用している場合に、Operator の作成者がプロジェクトを更新してワークロードの問題や、互換性のないアップグレードを回避できるようにする方法は Operator の互換性の OpenShift Container Platform バージョンへの制御 を参照してください。

4.3.1. OLM v1 のカタログについて

catalogd コンポーネントを使用して、Operator やコントローラーなどの Kubernetes 拡張機能のカタログをクエリーすることで、インストール可能なコンテンツを検出できます。catalogd は、クラスター上のクライアント用にカタログコンテンツを展開する Kubernetes 機能拡張であり、マイクロサービスの Operator Lifecycle Manager (OLM) v1 スイートの一部です。現在、catalogd は、コンテナーイメージとしてパッケージ化および配布されているカタログコンテンツを解凍します。

重要

一意の名前を持たない Operator または拡張機能をインストールしようとすると、インストールが失敗するか、予期しない結果になる可能性があります。その原因は以下のとおりです。

  • クラスターに複数のカタログがインストールされている場合、Operator Lifecycle Manager (OLM) v1 には、Operator または拡張機能のインストール時にカタログを指定するメカニズムがありません。
  • OLM v1 では、クラスターにインストールできるすべての Operator および拡張機能のバンドルとパッケージに、一意の名前が使用されている必要があります。

4.3.2. OLM v1 で Red Hat が提供する Operator カタログ

Operator Lifecycle Manager (OLM) v1 には、Red Hat が提供する Operator カタログがデフォルトで含まれていません。Red Hat が提供するカタログをクラスターに追加する場合は、カタログのカスタムリソース (CR) を作成し、クラスターに適用します。次のカスタムリソース (CR) の例は、OLM v1 のカタログリソースを作成する方法を示しています。

重要
  • 現在、Operator Lifecycle Manager (OLM) v1 は、Red Hat が提供する Operator カタログなどのプライベートレジストリーを認証できません。これは既知の問題です。その結果、Red Hat Operators カタログがインストールされていることを前提とする OLM v1 の手順は機能しません。(OCPBUGS-36364)

  • registry.redhat.io からの Red Hat 提供 Operator カタログなど、プライベートレジストリーでホストされているカタログを使用する場合は、openshift-catalogd namespace にスコープ指定されたプルシークレットが必要です。

    詳細は、「セキュアなレジストリーでホストされるカタログのプルシークレットを作成する」を参照してください。

Red Hat Operator カタログの例

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: ClusterCatalog
metadata:
  name: redhat-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/redhat-operator-index:v4.17
      pullSecret: <pull_secret_name>
      pollInterval: <poll_interval_duration> 
1
Copy to Clipboard Toggle word wrap

1
新しいイメージダイジェストを確認するためにリモートレジストリーをポーリングする間隔を指定します。デフォルト値は、24h です。有効な単位は、秒 (s)、分 (m)、および時間 (h) です。ポーリングを無効にするには、0s などのゼロ値を設定します。

認定 Operator カタログの例

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: ClusterCatalog
metadata:
  name: certified-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/certified-operator-index:v4.17
      pullSecret: <pull_secret_name>
      pollInterval: 24h
Copy to Clipboard Toggle word wrap

コミュニティー Operator カタログの例

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: ClusterCatalog
metadata:
  name: community-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/community-operator-index:v4.17
      pullSecret: <pull_secret_name>
      pollInterval: 24h
Copy to Clipboard Toggle word wrap

次のコマンドは、クラスターにカタログを追加します。

コマンド構文

$ oc apply -f <catalog_name>.yaml 
1
Copy to Clipboard Toggle word wrap

1
redhat-operators.yaml などのカタログ CR を指定します。

registry.redhat.io からの Red Hat 提供 Operator カタログなど、プライベートレジストリーでホストされているカタログを使用する場合は、openshift-catalogd namespace にスコープ指定されたプルシークレットが必要です。

catalogd は、OpenShift Container Platform クラスターからグローバルプルシークレットを読み取ることができません。Catalogd は、それがデプロイされている namespace でのみシークレットへの参照を読み取ることができます。

重要

現在、Operator Lifecycle Manager (OLM) v1 は、Red Hat が提供する Operator カタログなどのプライベートレジストリーを認証できません。これは既知の問題です。その結果、Red Hat Operators カタログがインストールされていることを前提とする OLM v1 の手順は機能しません。(OCPBUGS-36364)

前提条件

  • セキュアなレジストリーのログイン認証情報
  • Docker または Podman がワークステーションにインストールされている。

手順

  • セキュアなレジストリーのログイン認証情報を含む .dockercfg ファイルがすでにある場合は、次のコマンドを実行してプルシークレットを作成します。

    $ oc create secret generic <pull_secret_name> \
        --from-file=.dockercfg=<file_path>/.dockercfg \
        --type=kubernetes.io/dockercfg \
        --namespace=openshift-catalogd
    Copy to Clipboard Toggle word wrap

    例4.9 コマンドの例

    $ oc create secret generic redhat-cred \
        --from-file=.dockercfg=/home/<username>/.dockercfg \
        --type=kubernetes.io/dockercfg \
        --namespace=openshift-catalogd
    Copy to Clipboard Toggle word wrap
  • 保護されたレジストリーのログイン認証情報を含む $HOME/.docker/config.json ファイルがすでにある場合は、次のコマンドを実行してプルシークレットを作成します。

    $ oc create secret generic <pull_secret_name> \
        --from-file=.dockerconfigjson=<file_path>/.docker/config.json \
        --type=kubernetes.io/dockerconfigjson \
        --namespace=openshift-catalogd
    Copy to Clipboard Toggle word wrap

    例4.10 コマンドの例

    $ oc create secret generic redhat-cred \
        --from-file=.dockerconfigjson=/home/<username>/.docker/config.json \
        --type=kubernetes.io/dockerconfigjson \
        --namespace=openshift-catalogd
    Copy to Clipboard Toggle word wrap
  • セキュアなレジストリーのログイン認証情報を含む Docker 設定ファイルがない場合は、次のコマンドを実行してプルシークレットを作成します。

    $ oc create secret docker-registry <pull_secret_name> \
        --docker-server=<registry_server> \
        --docker-username=<username> \
        --docker-password=<password> \
        --docker-email=<email> \
        --namespace=openshift-catalogd
    Copy to Clipboard Toggle word wrap

    例4.11 コマンドの例

    $ oc create secret docker-registry redhat-cred \
        --docker-server=registry.redhat.io \
        --docker-username=username \
        --docker-password=password \
        --docker-email=user@example.com \
        --namespace=openshift-catalogd
    Copy to Clipboard Toggle word wrap

4.3.4. クラスターへのカタログの追加

カタログをクラスターに追加するには、カタログカスタムリソース (CR) を作成し、それをクラスターに適用します。

重要

現在、Operator Lifecycle Manager (OLM) v1 は、Red Hat が提供する Operator カタログなどのプライベートレジストリーを認証できません。これは既知の問題です。その結果、Red Hat Operators カタログがインストールされていることを前提とする OLM v1 の手順は機能しません。(OCPBUGS-36364)

前提条件

  • registry.redhat.io からの Red Hat 提供 Operator カタログなど、プライベートレジストリーでホストされているカタログを使用する場合は、openshift-catalogd namespace にスコープ指定されたプルシークレットが必要です。

    catalogd は、OpenShift Container Platform クラスターからグローバルプルシークレットを読み取ることができません。Catalogd は、それがデプロイされている namespace でのみシークレットへの参照を読み取ることができます。

手順

  1. 次の例のようなカタログカスタムリソース (CR) を作成します。

    redhat-operators.yaml の例

    apiVersion: catalogd.operatorframework.io/v1alpha1
    kind: ClusterCatalog
    metadata:
      name: redhat-operators
    spec:
      source:
        type: image
        image:
          ref: registry.redhat.io/redhat/redhat-operator-index:v4.17 
    1
    
          pullSecret: <pull_secret_name> 
    2
    
          pollInterval: <poll_interval_duration> 
    3
    Copy to Clipboard Toggle word wrap

    1
    spec.source.image フィールドにカタログのイメージを指定します。
    2
    カタログが registry.redhat.io などのセキュアなレジストリーでホストされている場合は、スコープを openshift-catalog namespace に設定したプルシークレットを作成する必要があります。
    3
    新しいイメージダイジェストを確認するためにリモートレジストリーをポーリングする間隔を指定します。デフォルト値は、24h です。有効な単位は、秒 (s)、分 (m)、および時間 (h) です。ポーリングを無効にするには、0s などのゼロ値を設定します。
  2. 次のコマンドを実行して、カタログをクラスターに追加します。

    $ oc apply -f redhat-operators.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    catalog.catalogd.operatorframework.io/redhat-operators created
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを実行して、カタログのステータスを確認します。

    1. 次のコマンドを実行して、カタログが利用可能かどうかを確認します。

      $ oc get clustercatalog
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                  AGE
      redhat-operators      20s
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して、カタログのステータスを確認します。

      $ oc describe clustercatalog
      Copy to Clipboard Toggle word wrap

      出力例

      Name:         redhat-operators
      Namespace:
      Labels:       <none>
      Annotations:  <none>
      API Version:  catalogd.operatorframework.io/v1alpha1
      Kind:         ClusterCatalog
      Metadata:
        Creation Timestamp:  2024-06-10T17:34:53Z
        Finalizers:
          catalogd.operatorframework.io/delete-server-cache
        Generation:        1
        Resource Version:  46075
        UID:               83c0db3c-a553-41da-b279-9b3cddaa117d
      Spec:
        Source:
          Image:
            Pull Secret:  redhat-cred
            Ref:          registry.redhat.io/redhat/redhat-operator-index:v4.17
          Type:           image
      Status: 
      1
      
        Conditions:
          Last Transition Time:  2024-06-10T17:35:15Z
          Message:
          Reason:                UnpackSuccessful 
      2
      
          Status:                True
          Type:                  Unpacked
        Content URL:             https://catalogd-catalogserver.openshift-catalogd.svc/catalogs/redhat-operators/all.json
        Observed Generation:     1
        Phase:                   Unpacked 
      3
      
        Resolved Source:
          Image:
            Last Poll Attempt:  2024-06-10T17:35:10Z
            Ref:                registry.redhat.io/redhat/redhat-operator-index:v4.17
            Resolved Ref:       registry.redhat.io/redhat/redhat-operator-index@sha256:f2ccc079b5e490a50db532d1dc38fd659322594dcf3e653d650ead0e862029d9 
      4
      
          Type:                 image
      Events:                   <none>
      Copy to Clipboard Toggle word wrap

      1
      カタログのステータスを記述します。
      2
      カタログが現在の状態になっている理由を表示します。
      3
      インストールプロセスのフェーズを表示します。
      4
      カタログのイメージ参照を表示します。

4.3.5. カタログの削除

カタログを削除するには、そのカスタムリソース (CR) を削除します。

前提条件

  • カタログがインストールされています。

手順

  • 次のコマンドを実行してカタログを削除します。

    $ oc delete clustercatalog <catalog_name>
    Copy to Clipboard Toggle word wrap

    出力例

    catalog.catalogd.operatorframework.io "my-catalog" deleted
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを実行して、カタログが削除されたことを確認します。

    $ oc get clustercatalog
    Copy to Clipboard Toggle word wrap

4.4. カタログの作成

重要

Operator Lifecycle Manager (OLM) v1 はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

カタログ管理者は、OpenShift Container Platform 上の Operator Lifecycle Manager (OLM) v1 で使用するために、ファイルベースのカタログ形式で新しいカタログを作成できます。

重要

現在、Operator Lifecycle Manager (OLM) v1 は、Red Hat が提供する Operator カタログなどのプライベートレジストリーを認証できません。これは既知の問題です。その結果、Red Hat Operators カタログがインストールされていることを前提とする OLM v1 の手順は機能しません。(OCPBUGS-36364)

4.4.1. ファイルベースのカタログイメージの作成

opm CLI を使用して、非推奨の SQLite データベース形式を置き換えるプレーンテキストの ファイルベースのカタログ 形式 (JSON または YAML) を使用するカタログイメージを作成できます。

前提条件

  • opm CLI がインストールされている。
  • podman バージョン 1.9.3 以降がある。
  • バンドルイメージがビルドされ、Docker v2-2 をサポートするレジストリーにプッシュされている。

手順

  1. カタログを初期化します。

    1. 次のコマンドを実行して、カタログ用のディレクトリーを作成します。

      $ mkdir <catalog_dir>
      Copy to Clipboard Toggle word wrap
    2. opm generate dockerfile コマンドを実行して、カタログイメージを構築できる Dockerfile を生成します。

      $ opm generate dockerfile <catalog_dir> \
          -i registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4.17 
      1
      Copy to Clipboard Toggle word wrap
      1
      -i フラグを使用して公式の Red Hat ベースイメージを指定します。それ以外の場合、Dockerfile はデフォルトのアップストリームイメージを使用します。

      Dockerfile は、直前の手順で作成したカタログディレクトリーと同じ親ディレクトリーに存在する必要があります。

      ディレクトリー構造の例

      . 
      1
      
      ├── <catalog_dir> 
      2
      
      └── <catalog_dir>.Dockerfile 
      3
      Copy to Clipboard Toggle word wrap

      1
      親ディレクトリー
      2
      カタログディレクトリー
      3
      opm generate dockerfile コマンドによって生成された Dockerfile
    3. opm init コマンドを実行して、カタログに Operator のパッケージ定義を追加します。

      $ opm init <operator_name> \ 
      1
      
          --default-channel=preview \ 
      2
      
          --description=./README.md \ 
      3
      
          --icon=./operator-icon.svg \ 
      4
      
          --output yaml \ 
      5
      
          > <catalog_dir>/index.yaml 
      6
      Copy to Clipboard Toggle word wrap
      1
      Operator、またはパッケージ、名前。
      2
      指定されていない場合にサブスクリプションがデフォルトで使用するチャネル
      3
      Operator の README.md またはその他のドキュメントへのパス。
      4
      Operator のアイコンへのパス。
      5
      出力形式: JSON または YAML。
      6
      カタログ設定ファイルを作成するパス。

      このコマンドは、指定されたカタログ設定ファイルに olm.package 宣言型設定 blob を生成します。

  2. opm render コマンドを実行して、バンドルをカタログに追加します。

    $ opm render <registry>/<namespace>/<bundle_image_name>:<tag> \ 
    1
    
        --output=yaml \
        >> <catalog_dir>/index.yaml 
    2
    Copy to Clipboard Toggle word wrap
    1
    バンドルイメージのプル仕様。
    2
    カタログ設定ファイルへのパス。
    注記

    チャネルには、1 つ以上のバンドルが含まれる必要があります。

  3. バンドルのチャネルエントリーを追加します。たとえば、次の例を仕様に合わせて変更し、<catalog_dir>/index.yaml ファイルに追加します。

    チャネルエントリーの例

    ---
    schema: olm.channel
    package: <operator_name>
    name: preview
    entries:
      - name: <operator_name>.v0.1.0 
    1
    Copy to Clipboard Toggle word wrap

    1
    <operator_name> の後、かつ、バージョンの v の前に、ピリオド (.) を追加するようにしてください。それ以外の場合、エントリーが opm validate コマンドに合格できません。
  4. ファイルベースのカタログを検証します。

    1. カタログディレクトリーに対して opm validate コマンドを実行します。

      $ opm validate <catalog_dir>
      Copy to Clipboard Toggle word wrap
    2. エラーコードが 0 であることを確認します。

      $ echo $?
      Copy to Clipboard Toggle word wrap

      出力例

      0
      Copy to Clipboard Toggle word wrap

  5. podman build コマンドを実行して、カタログイメージをビルドします。

    $ podman build . \
        -f <catalog_dir>.Dockerfile \
        -t <registry>/<namespace>/<catalog_image_name>:<tag>
    Copy to Clipboard Toggle word wrap
  6. カタログイメージをレジストリーにプッシュします。

    1. 必要に応じて、podman login コマンドを実行してターゲットレジストリーで認証します。

      $ podman login <registry>
      Copy to Clipboard Toggle word wrap
    2. podman push コマンドを実行して、カタログイメージをプッシュします。

      $ podman push <registry>/<namespace>/<catalog_image_name>:<tag>
      Copy to Clipboard Toggle word wrap

4.4.2. ファイルベースのカタログイメージの更新またはフィルタリング

opm CLI を使用して、ファイルベースのカタログ形式を使用するカタログイメージを更新またはフィルタリングできます。既存のカタログイメージのコンテンツを抽出すると、必要に応じてカタログを変更できます。たとえば、以下を実行できます。

  • パッケージの追加
  • パッケージの削除
  • 既存のパッケージエントリーの更新
  • パッケージ、チャネル、バンドルごとの非推奨メッセージの記載

その後、イメージをカタログの更新バージョンとして再構築できます。

注記

または、ミラーレジストリーにカタログイメージがすでにある場合は、oc-mirror CLI プラグインを使用して、ターゲットレジストリーにミラーリングする際に、そのカタログイメージの更新されたソースバージョンから削除されたイメージを自動的にプルーニングできます。

oc-mirror プラグインとこのユースケースの詳細は、「ミラーレジストリーのコンテンツを最新の状態に維持」セクション、および「oc-mirror プラグインを使用した非接続インストールのイメージのミラーリング」の「イメージのプルーニング」サブセクションを参照してください。

前提条件

  • ワークステーションに以下が含まれている。

    • opm CLI。
    • podman version 1.9.3+。
    • ファイルベースのカタログイメージ。
    • このカタログに関連するワークステーションで最近初期化されたカタログディレクトリー構造。

      初期化されたカタログディレクトリーがない場合は、ディレクトリーを作成し、Dockerfile を生成します。詳細は、「ファイルベースのカタログイメージの作成」手順の「カタログの初期化」手順を参照してください。

手順

  1. カタログイメージのコンテンツを YAML 形式でカタログディレクトリーの index.yaml ファイルに展開します。

    $ opm render <registry>/<namespace>/<catalog_image_name>:<tag> \
        -o yaml > <catalog_dir>/index.yaml
    Copy to Clipboard Toggle word wrap
    注記

    または、-o json フラグを使用して JSON 形式で出力することもできます。

  2. 作成された index.yaml ファイルの内容を仕様に合わせて変更します。

    重要

    バンドルがカタログに公開されたら、いずれかのユーザーがバンドルをインストールしていると想定します。カタログ内で以前に公開されたすべてのバンドルに、現在または新しいチャネルヘッドへの更新パスが設定されていることを確認し、そのバージョンがインストールされているユーザーが立ち往生するのを防ぎます。

    • Operator を追加するには、「ファイルベースのカタログイメージの作成」手順のパッケージ、バンドル、およびチャネルエントリーを作成する手順に従います。
    • Operator を削除するには、パッケージに関連する olm.packageolm.channel、および olm.bundle Blob のセットを削除します。次の例は、カタログから example-operator パッケージを削除するために削除する必要があるセットを示しています。

      例4.12 削除されたエントリーの例

      ---
      defaultChannel: release-2.7
      icon:
        base64data: <base64_string>
        mediatype: image/svg+xml
      name: example-operator
      schema: olm.package
      ---
      entries:
      - name: example-operator.v2.7.0
        skipRange: '>=2.6.0 <2.7.0'
      - name: example-operator.v2.7.1
        replaces: example-operator.v2.7.0
        skipRange: '>=2.6.0 <2.7.1'
      - name: example-operator.v2.7.2
        replaces: example-operator.v2.7.1
        skipRange: '>=2.6.0 <2.7.2'
      - name: example-operator.v2.7.3
        replaces: example-operator.v2.7.2
        skipRange: '>=2.6.0 <2.7.3'
      - name: example-operator.v2.7.4
        replaces: example-operator.v2.7.3
        skipRange: '>=2.6.0 <2.7.4'
      name: release-2.7
      package: example-operator
      schema: olm.channel
      ---
      image: example.com/example-inc/example-operator-bundle@sha256:<digest>
      name: example-operator.v2.7.0
      package: example-operator
      properties:
      - type: olm.gvk
        value:
          group: example-group.example.io
          kind: MyObject
          version: v1alpha1
      - type: olm.gvk
        value:
          group: example-group.example.io
          kind: MyOtherObject
          version: v1beta1
      - type: olm.package
        value:
          packageName: example-operator
          version: 2.7.0
      - type: olm.bundle.object
        value:
          data: <base64_string>
      - type: olm.bundle.object
        value:
          data: <base64_string>
      relatedImages:
      - image: example.com/example-inc/example-related-image@sha256:<digest>
        name: example-related-image
      schema: olm.bundle
      ---
      Copy to Clipboard Toggle word wrap
    • Operator の非推奨メッセージを追加または更新するには、パッケージの index.yaml ファイルと同じディレクトリーに deprecations.yaml ファイルがあることを確認してください。deprecations.yaml ファイル形式の詳細は、「olm.deprecations スキーマ」を参照してください。
  3. 変更を保存します。
  4. カタログを検証します。

    $ opm validate <catalog_dir>
    Copy to Clipboard Toggle word wrap
  5. カタログを再構築します。

    $ podman build . \
        -f <catalog_dir>.Dockerfile \
        -t <registry>/<namespace>/<catalog_image_name>:<tag>
    Copy to Clipboard Toggle word wrap
  6. 更新されたカタログイメージをレジストリーにプッシュします。

    $ podman push <registry>/<namespace>/<catalog_image_name>:<tag>
    Copy to Clipboard Toggle word wrap

検証

  1. Web コンソールで、AdministrationCluster SettingsConfiguration ページで OperatorHub 設定リソースに移動します。
  2. カタログソースを追加するか、既存のカタログソースを更新して、更新されたカタログイメージのプル仕様を使用します。

    詳細は、このセクションの「関連情報」にある「クラスターへのカタログソースの追加」を参照してください。

  3. カタログソースが READY 状態になったら、OperatorsOperatorHub ページに移動し、加えた変更が Operator のリストに反映されていることを確認します。

第5章 クラスター拡張機能

5.1. クラスター拡張機能の管理

重要

Operator Lifecycle Manager (OLM) v1 はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

カタログがクラスターに追加されると、カタログに公開されている拡張機能と Operator のバージョン、パッチ、OTA (over-the-air) 更新にアクセスできるようになります。

カスタムリソース (CR) を使用して、CLI から拡張機能を宣言的に管理できます。

重要

現在、Operator Lifecycle Manager (OLM) v1 は、Red Hat が提供する Operator カタログなどのプライベートレジストリーを認証できません。これは既知の問題です。その結果、Red Hat Operators カタログがインストールされていることを前提とする OLM v1 の手順は機能しません。(OCPBUGS-36364)

5.1.1. サポートされる拡張機能

現在、Operator Lifecycle Manager (OLM) v1 は、次のすべての条件を満たすクラスター拡張機能のインストールをサポートしています。

  • 拡張機能は、既存の OLM で導入された registry+v1 バンドル形式を使用する必要があります。
  • 拡張機能は、AllNamespaces インストールモードによるインストールをサポートする必要があります。
  • 拡張機能は Webhook を使用してはなりません。
  • 拡張機能は、次に示すいずれかのファイルベースのカタログプロパティーを使用して依存関係を宣言してはなりません。

    • olm.gvk.required
    • olm.package.required
    • olm.constraint

OLM v1 は、インストールする拡張機能がこれらの制約を満たしているかどうかを確認します。インストールする拡張機能がこれらの制約を満たしていない場合、クラスター拡張機能の条件にエラーメッセージが出力されます。

重要

Operator Lifecycle Manager (OLM) v1 は、既存の OLM で導入された OperatorConditions API をサポートしていません。

拡張機能が OperatorConditions API のみに依存して更新を管理している場合、拡張機能が正しくインストールされない可能性があります。この API に依存する拡張機能のほとんどは起動時に失敗しますが、一部は調整中に失敗する可能性があります。

回避策として、拡張機能を特定のバージョンに固定できます。拡張機能を更新する場合は、拡張機能のドキュメントを参照して、いつ拡張機能を新しいバージョンに固定すれば安全か確認してください。

5.1.2. カタログからインストールする Operator を見つける

クラスターにカタログを追加した後、カタログにクエリーを実行して、インストールする Operator と拡張機能を見つけることができます。カタログをクエリーする前に、カタログサーバーサービスをポート転送する必要があります。

前提条件

  • クラスターにカタログを追加している。
  • jq CLI ツールがインストールされている。

手順

  1. 次のコマンドを実行して、openshift-catalogd namespace のカタログサーバーサービスのポート転送を行います。

    $ oc -n openshift-catalogd port-forward svc/catalogd-catalogserver 8080:443
    Copy to Clipboard Toggle word wrap
  2. 新しいターミナルウィンドウまたはタブで、次のコマンドを実行してカタログの JSON ファイルをローカルにダウンロードします。

    $ curl -L -k https://localhost:8080/catalogs/<catalog_name>/all.json \
      -C - -o /<path>/<catalog_name>.json
    Copy to Clipboard Toggle word wrap

    例5.1 コマンドの例

    $ curl -L -k https://localhost:8080/catalogs/redhat-operators/all.json \
      -C - -o /home/username/catalogs/rhoc.json
    Copy to Clipboard Toggle word wrap
  3. 次のコマンドのいずれかを実行して、カタログ内のオペレータと拡張機能のリストを返します。

    重要

    現在、Operator Lifecycle Manager (OLM) v1 は、次のすべての条件を満たすクラスター拡張機能のインストールをサポートしています。

    • 拡張機能は、既存の OLM で導入された registry+v1 バンドル形式を使用する必要があります。
    • 拡張機能は、AllNamespaces インストールモードによるインストールをサポートする必要があります。
    • 拡張機能は Webhook を使用してはなりません。
    • 拡張機能は、次に示すいずれかのファイルベースのカタログプロパティーを使用して依存関係を宣言してはなりません。

      • olm.gvk.required
      • olm.package.required
      • olm.constraint

    OLM v1 は、インストールする拡張機能がこれらの制約を満たしているかどうかを確認します。インストールする拡張機能がこれらの制約を満たしていない場合、クラスター拡張機能の条件にエラーメッセージが出力されます。

    • 次のコマンドを実行して、ローカルカタログファイルからすべての Operator と拡張機能のリストを取得します。

      $ jq -s '.[] | select(.schema == "olm.package") | .name' \
        /<path>/<filename>.json
      Copy to Clipboard Toggle word wrap

      例5.2 コマンドの例

      $ jq -s '.[] | select(.schema == "olm.package") | .name' \
        /home/username/catalogs/rhoc.json
      Copy to Clipboard Toggle word wrap

      例5.3 出力例

      NAME                                                        AGE
      "3scale-operator"
      "advanced-cluster-management"
      "amq-broker-rhel8"
      "amq-online"
      "amq-streams"
      "amq7-interconnect-operator"
      "ansible-automation-platform-operator"
      "ansible-cloud-addons-operator"
      "apicast-operator"
      "aws-efs-csi-driver-operator"
      "aws-load-balancer-operator"
      "bamoe-businessautomation-operator"
      "bamoe-kogito-operator"
      "bare-metal-event-relay"
      "businessautomation-operator"
      ...
      Copy to Clipboard Toggle word wrap
    • 次のコマンドを実行して、AllNamespaces インストールモードをサポートし、Webhook を使用しないパッケージのリストを、ローカルカタログファイルから取得します。

      $ jq -c 'select(.schema == "olm.bundle") | \
        {"package":.package, "version":.properties[] | \
        select(.type == "olm.bundle.object").value.data | @base64d | fromjson | \
        select(.kind == "ClusterServiceVersion" and (.spec.installModes[] | \
        select(.type == "AllNamespaces" and .supported == true) != null) \
        and .spec.webhookdefinitions == null).spec.version}' \
        /<path>/<catalog_name>.json
      Copy to Clipboard Toggle word wrap

      例5.4 出力例

      {"package":"3scale-operator","version":"0.10.0-mas"}
      {"package":"3scale-operator","version":"0.10.5"}
      {"package":"3scale-operator","version":"0.11.0-mas"}
      {"package":"3scale-operator","version":"0.11.1-mas"}
      {"package":"3scale-operator","version":"0.11.2-mas"}
      {"package":"3scale-operator","version":"0.11.3-mas"}
      {"package":"3scale-operator","version":"0.11.5-mas"}
      {"package":"3scale-operator","version":"0.11.6-mas"}
      {"package":"3scale-operator","version":"0.11.7-mas"}
      {"package":"3scale-operator","version":"0.11.8-mas"}
      {"package":"amq-broker-rhel8","version":"7.10.0-opr-1"}
      {"package":"amq-broker-rhel8","version":"7.10.0-opr-2"}
      {"package":"amq-broker-rhel8","version":"7.10.0-opr-3"}
      {"package":"amq-broker-rhel8","version":"7.10.0-opr-4"}
      {"package":"amq-broker-rhel8","version":"7.10.1-opr-1"}
      {"package":"amq-broker-rhel8","version":"7.10.1-opr-2"}
      {"package":"amq-broker-rhel8","version":"7.10.2-opr-1"}
      {"package":"amq-broker-rhel8","version":"7.10.2-opr-2"}
      ...
      Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、Operator または拡張機能のメタデータの内容を検査します。

    $ jq -s '.[] | select( .schema == "olm.package") | \
      select( .name == "<package_name>")' /<path>/<catalog_name>.json
    Copy to Clipboard Toggle word wrap

    例5.5 コマンドの例

    $ jq -s '.[] | select( .schema == "olm.package") | \
      select( .name == "openshift-pipelines-operator-rh")' \
      /home/username/rhoc.json
    Copy to Clipboard Toggle word wrap

    例5.6 出力例

    {
      "defaultChannel": "stable",
      "icon": {
        "base64data": "PHN2ZyB4bWxu..."
        "mediatype": "image/png"
      },
      "name": "openshift-pipelines-operator-rh",
      "schema": "olm.package"
    }
    Copy to Clipboard Toggle word wrap
5.1.2.1. 一般的なカタログクエリー

jq CLI ツールを使用して、カタログをクエリーできます。

Expand
表5.1 一般的なパッケージクエリー
クエリーRequest

カタログで利用可能なパッケージ

$ jq -s '.[] | select( .schema == "olm.package") | \
  .name' <catalog_name>.json
Copy to Clipboard Toggle word wrap

AllNamespaces インストールモードをサポートし、Webhook を使用しないパッケージ

$ jq -c 'select(.schema == "olm.bundle") | \
  {"package":.package, "version":.properties[] | \
  select(.type == "olm.bundle.object").value.data | \
  @base64d | fromjson | \
  select(.kind == "ClusterServiceVersion" and (.spec.installModes[] | \
  select(.type == "AllNamespaces" and .supported == true) != null) \
  and .spec.webhookdefinitions == null).spec.version}' \
  <catalog_name>.json
Copy to Clipboard Toggle word wrap

パッケージのメタデータ

$ jq -s '.[] | select( .schema == "olm.package") | \
  select( .name == "<package_name>")' <catalog_name>.json
Copy to Clipboard Toggle word wrap

パッケージ内のカタログブロブ

$ jq -s '.[] | select( .package == "<package_name>")' \
  <catalog_name>.json
Copy to Clipboard Toggle word wrap
Expand
表5.2 一般的なチャネルクエリー
クエリーRequest

パッケージのチャネル

$ jq -s '.[] | select( .schema == "olm.channel" ) | \
  select( .package == "<package_name>") | .name' \
  <catalog_name>.json
Copy to Clipboard Toggle word wrap

チャネル内のバージョン

$ jq -s '.[] | select( .package == "<package_name>" ) | \
  select( .schema == "olm.channel" ) | \
  select( .name == "<channel_name>" ) | \
  .entries | .[] | .name' <catalog_name>.json
Copy to Clipboard Toggle word wrap
  • チャネルの最新バージョン
  • アップグレードパス
$ jq -s '.[] | select( .schema == "olm.channel" ) | \
  select ( .name == "<channel>") | \
  select( .package == "<package_name>")' \
  <catalog_name>.json
Copy to Clipboard Toggle word wrap
Expand
表5.3 一般的なバンドルクエリー
クエリーRequest

パッケージ内のバンドル

$ jq -s '.[] | select( .schema == "olm.bundle" ) | \
  select( .package == "<package_name>") | .name' \
  <catalog_name>.json
Copy to Clipboard Toggle word wrap
  • 依存関係をバンドルする
  • 利用可能な API
$ jq -s '.[] | select( .schema == "olm.bundle" ) | \
  select ( .name == "<bundle_name>") | \
  select( .package == "<package_name>")' \
  <catalog_name>.json
Copy to Clipboard Toggle word wrap

5.1.3. クラスター拡張機能の管理に使用するサービスアカウントの作成

既存の Operator Lifecycle Manager (OLM) とは異なり、OLM v1 にはクラスター拡張機能をインストール、更新、および管理する権限がありません。クラスター管理者は、サービスアカウントを作成し、クラスター拡張機能のインストール、更新、管理に必要なロールベースのアクセス制御 (RBAC) を割り当てる必要があります。

重要

OLM v1 には既知の問題があります。拡張機能のサービスアカウントに適切なロールベースのアクセス制御 (RBAC) を割り当てなければ、OLM v1 が停止し、調整が停止します。

現在、OLM v1 には、拡張機能管理者がサービスアカウントの適切な RBAC を見つけるために使用できるツールはありません。

OLM v1 はテクノロジープレビュー機能であり、実稼働クラスターでは使用できないため、この問題を回避するためには、ドキュメントに含まれているより許容度の高い RBAC を使用します。

この RBAC はテスト目的に限定して使用できます。実稼働クラスターでは使用しないでください。

前提条件

  • cluster-admin 権限を持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。

手順

  1. 次の例のように、サービスアカウントを作成します。

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: <extension>-installer
      namespace: <namespace>
    Copy to Clipboard Toggle word wrap

    例5.7 extension-service-account.yaml ファイルの例

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: pipelines-installer
      namespace: pipelines
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行してサービスアカウントを適用します。

    $ oc apply -f extension-service-account.yaml
    Copy to Clipboard Toggle word wrap
  3. 次の例のように、クラスターロールを作成し、RBAC を割り当てます。

    警告

    次のクラスターロールは、最小権限の原則に従っていません。このクラスターロールはテスト目的に限定して使用できます。実稼働クラスターでは使用しないでください。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: <extension>-installer-clusterrole
    rules:
    - apiGroups: ["*"]
      resources: ["*"]
      verbs: ["*"]
    Copy to Clipboard Toggle word wrap

    例5.8 pipelines-cluster-role.yaml ファイルの例

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: pipelines-installer-clusterrole
    rules:
    - apiGroups: ["*"]
      resources: ["*"]
      verbs: ["*"]
    Copy to Clipboard Toggle word wrap
  4. 次のコマンドを実行して、クラスターにクラスターロールを追加します。

    $ oc apply -f pipelines-role.yaml
    Copy to Clipboard Toggle word wrap
  5. 次の例のように、クラスターロールバインディングを作成して、クラスターロールによって付与された権限をサービスアカウントにバインドします。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
      name: <extension>-installer-binding
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: <extension>-installer-clusterrole
    subjects:
    - kind: ServiceAccount
      name: <extension>-installer
      namespace: <namespace>
    Copy to Clipboard Toggle word wrap

    例5.9 pipelines-cluster-role-binding.yaml ファイルの例

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
      name: pipelines-installer-binding
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: pipelines-installer-clusterrole
    subjects:
    - kind: ServiceAccount
      name: pipelines-installer
      namespace: pipelines
    Copy to Clipboard Toggle word wrap
  6. 次のコマンドを実行して、クラスターロールバインディングを適用します。

    $ oc apply -f pipelines-cluster-role-binding.yaml
    Copy to Clipboard Toggle word wrap

5.1.4. カタログからのクラスター拡張のインストール

カスタムリソース (CR) を作成し、それをクラスターに適用することで、カタログから拡張機能をインストールできます。Operator Lifecycle Manager (OLM) v1 は、クラスターにスコープ指定された、registry+v1 バンドル形式を介した既存の OLM Operator などの、クラスター拡張機能のインストールをサポートします。詳細は、サポートされている拡張機能 を参照してください。

重要

現在、Operator Lifecycle Manager (OLM) v1 は、Red Hat が提供する Operator カタログなどのプライベートレジストリーを認証できません。これは既知の問題です。その結果、Red Hat Operators カタログがインストールされていることを前提とする OLM v1 の手順は機能しません。(OCPBUGS-36364)

前提条件

  • クラスターにカタログを追加している。
  • カタログファイルのローカルコピーをダウンロードしている。
  • jq CLI ツールがインストールされている。
  • サービスアカウントを作成し、インストールする拡張機能をインストール、更新、管理するために十分なロールベースのアクセス制御 (RBAC) を割り当てました。詳細は GCP サービスアカウントの作成 を参照してください。

手順

  1. 次の手順を実行して、カタログファイルのローカルコピーからパッケージのチャネルとバージョン情報を検査します。

    1. 次のコマンドを実行して、選択したパッケージからチャネルのリストを取得します。

      $ jq -s '.[] | select( .schema == "olm.channel" ) | \
        select( .package == "<package_name>") | \
        .name' /<path>/<catalog_name>.json
      Copy to Clipboard Toggle word wrap

      例5.10 コマンドの例

      $ jq -s '.[] | select( .schema == "olm.channel" ) | \
        select( .package == "openshift-pipelines-operator-rh") | \
        .name' /home/username/rhoc.json
      Copy to Clipboard Toggle word wrap

      例5.11 出力例

      "latest"
      "pipelines-1.11"
      "pipelines-1.12"
      "pipelines-1.13"
      "pipelines-1.14"
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行して、チャネルで公開されているバージョンのリストを取得します。

      $ jq -s '.[] | select( .package == "<package_name>" ) | \
        select( .schema == "olm.channel" ) | \
        select( .name == "<channel_name>" ) | .entries | \
        .[] | .name' /<path>/<catalog_name>.json
      Copy to Clipboard Toggle word wrap

      例5.12 コマンドの例

      $ jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) | \
      select( .schema == "olm.channel" ) | select( .name == "latest" ) | \
      .entries | .[] | .name' /home/username/rhoc.json
      Copy to Clipboard Toggle word wrap

      例5.13 出力例

      "openshift-pipelines-operator-rh.v1.12.0"
      "openshift-pipelines-operator-rh.v1.12.1"
      "openshift-pipelines-operator-rh.v1.12.2"
      "openshift-pipelines-operator-rh.v1.13.0"
      "openshift-pipelines-operator-rh.v1.13.1"
      "openshift-pipelines-operator-rh.v1.11.1"
      "openshift-pipelines-operator-rh.v1.12.0"
      "openshift-pipelines-operator-rh.v1.12.1"
      "openshift-pipelines-operator-rh.v1.12.2"
      "openshift-pipelines-operator-rh.v1.13.0"
      "openshift-pipelines-operator-rh.v1.14.1"
      "openshift-pipelines-operator-rh.v1.14.2"
      "openshift-pipelines-operator-rh.v1.14.3"
      "openshift-pipelines-operator-rh.v1.14.4"
      Copy to Clipboard Toggle word wrap
  2. 拡張機能を新しい namespace にインストールする場合は、次のコマンドを実行します。

    $ oc adm new-project <new_namespace>
    Copy to Clipboard Toggle word wrap
  3. 次の例のような CR を作成します。

    pipelines-operator.yaml CR の例

    apiVersion: olm.operatorframework.io/v1alpha1
    kind: ClusterExtension
    metadata:
      name: pipelines-operator
    spec:
      packageName: openshift-pipelines-operator-rh
      installNamespace: <namespace>
      serviceAccount:
        name: <service_account>
      channel: <channel>
      version: "<version>"
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <namespace>
    pipelinesmy-extension など、バンドルをインストールする namespace を指定します。拡張機能は継続してクラスタースコープであり、異なる namespace にインストールされているリソースが含まれる可能性があります。
    <service_account>
    拡張機能をインストール、更新、管理するために作成したサービスアカウントの名前を指定します。
    <channel>
    オプション: インストールまたは更新するパッケージのチャネル (pipelines-1.11latest など) を指定します。
    <version>

    オプション: インストールまたは更新するパッケージのバージョンまたはバージョン範囲 (1.11.11.12.x>=1.12.1 など) を指定します。詳細は、「ターゲットバージョンを指定するカスタムリソース (CR) の例」および「バージョン範囲のサポート」を参照してください。

    重要

    一意の名前を持たない Operator または拡張機能をインストールしようとすると、インストールが失敗するか、予期しない結果になる可能性があります。その原因は以下のとおりです。

    • クラスターに複数のカタログがインストールされている場合、Operator Lifecycle Manager (OLM) v1 には、Operator または拡張機能のインストール時にカタログを指定するメカニズムがありません。
    • OLM v1 では、クラスターにインストールできるすべての Operator および拡張機能のバンドルとパッケージに、一意の名前が使用されている必要があります。
  4. 次のコマンドを実行して、CR をクラスターに適用します。

    $ oc apply -f pipeline-operator.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    clusterextension.olm.operatorframework.io/pipelines-operator created
    Copy to Clipboard Toggle word wrap

検証

  1. 次のコマンドを実行して、Operator または拡張機能の CR を YAML 形式で表示します。

    $ oc get clusterextension pipelines-operator -o yaml
    Copy to Clipboard Toggle word wrap

    例5.14 出力例

    apiVersion: v1
    items:
    - apiVersion: olm.operatorframework.io/v1alpha1
      kind: ClusterExtension
      metadata:
        annotations:
          kubectl.kubernetes.io/last-applied-configuration: |
            {"apiVersion":"olm.operatorframework.io/v1alpha1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","installNamespace":"pipelines","packageName":"openshift-pipelines-operator-rh","serviceAccount":{"name":"pipelines-installer"},"pollInterval":"30m"}}
        creationTimestamp: "2024-06-10T17:50:51Z"
        finalizers:
        - olm.operatorframework.io/cleanup-unpack-cache
        generation: 1
        name: pipelines-operator
        resourceVersion: "53324"
        uid: c54237be-cde4-46d4-9b31-d0ec6acc19bf
      spec:
        channel: latest
        installNamespace: pipelines
        packageName: openshift-pipelines-operator-rh
        serviceAccount:
          name: pipelines-installer
        upgradeConstraintPolicy: Enforce
      status:
        conditions:
        - lastTransitionTime: "2024-06-10T17:50:58Z"
          message: resolved to "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:dd3d18367da2be42539e5dde8e484dac3df33ba3ce1d5bcf896838954f3864ec"
          observedGeneration: 1
          reason: Success
          status: "True"
          type: Resolved
        - lastTransitionTime: "2024-06-10T17:51:11Z"
          message: installed from "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:dd3d18367da2be42539e5dde8e484dac3df33ba3ce1d5bcf896838954f3864ec"
          observedGeneration: 1
          reason: Success
          status: "True"
          type: Installed
        - lastTransitionTime: "2024-06-10T17:50:58Z"
          message: ""
          observedGeneration: 1
          reason: Deprecated
          status: "False"
          type: Deprecated
        - lastTransitionTime: "2024-06-10T17:50:58Z"
          message: ""
          observedGeneration: 1
          reason: Deprecated
          status: "False"
          type: PackageDeprecated
        - lastTransitionTime: "2024-06-10T17:50:58Z"
          message: ""
          observedGeneration: 1
          reason: Deprecated
          status: "False"
          type: ChannelDeprecated
        - lastTransitionTime: "2024-06-10T17:50:58Z"
          message: ""
          observedGeneration: 1
          reason: Deprecated
          status: "False"
          type: BundleDeprecated
        - lastTransitionTime: "2024-06-10T17:50:58Z"
          message: 'unpack successful:
          observedGeneration: 1
          reason: UnpackSuccess
          status: "True"
          type: Unpacked
        installedBundle:
          name: openshift-pipelines-operator-rh.v1.14.4
          version: 1.14.4
        resolvedBundle:
          name: openshift-pipelines-operator-rh.v1.14.4
          version: 1.14.4
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    spec.channel
    拡張の CR で定義されたチャネルを表示します。
    spec.version
    拡張の CR で定義されたバージョンまたはバージョン範囲を表示します。
    status.conditions
    拡張機能のステータスと健全性に関する情報を表示します。
    type: Deprecated

    次の 1 つ以上が非推奨かどうかを表示します。

    type: PackageDeprecated
    解決されたパッケージが非推奨かどうかを表示します。
    type: ChannelDeprecated
    解決されたチャネルが非推奨かどうかを表示します。
    type: BundleDeprecated
    解決されたバンドルが非推奨かどうかを表示します。

    status フィールドの False の値は reason: Deprecated 条件が非推奨ではないことを示します。ステータス フィールドの True の値は reason: Deprecated 条件が非推奨であることを示します。

    installedBundle.name
    インストールされているバンドルの名前を表示します。
    installedBundle.version
    インストールされているバンドルのバージョンを表示します。
    resolvedBundle.name
    解決されたバンドルの名前を表示します。
    resolvedBundle.version
    解決されたバンドルのバージョンを表示します。

5.1.5. クラスター拡張機能の更新

カスタムリソース (CR) を手動で編集し、変更を適用することで、クラスター拡張機能または Operator を更新できます。

前提条件

  • カタログがインストールされています。
  • カタログファイルのローカルコピーをダウンロードしている。
  • Operator または拡張機能がインストールされている。
  • jq CLI ツールがインストールされている。

手順

  1. 次の手順を実行して、カタログファイルのローカルコピーからパッケージのチャネルとバージョン情報を検査します。

    1. 次のコマンドを実行して、選択したパッケージからチャネルのリストを取得します。

      $ jq -s '.[] | select( .schema == "olm.channel" ) | \
        select( .package == "<package_name>") | \
        .name' /<path>/<catalog_name>.json
      Copy to Clipboard Toggle word wrap

      例5.15 コマンドの例

      $ jq -s '.[] | select( .schema == "olm.channel" ) | \
        select( .package == "openshift-pipelines-operator-rh") | \
        .name' /home/username/rhoc.json
      Copy to Clipboard Toggle word wrap

      例5.16 出力例

      "latest"
      "pipelines-1.11"
      "pipelines-1.12"
      "pipelines-1.13"
      "pipelines-1.14"
      Copy to Clipboard Toggle word wrap
    2. 次のコマンドを実行して、チャネルで公開されているバージョンのリストを取得します。

      $ jq -s '.[] | select( .package == "<package_name>" ) | \
        select( .schema == "olm.channel" ) | \
        select( .name == "<channel_name>" ) | .entries | \
        .[] | .name' /<path>/<catalog_name>.json
      Copy to Clipboard Toggle word wrap

      例5.17 コマンドの例

      $ jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) | \
      select( .schema == "olm.channel" ) | select( .name == "latest" ) | \
      .entries | .[] | .name' /home/username/rhoc.json
      Copy to Clipboard Toggle word wrap

      例5.18 出力例

      "openshift-pipelines-operator-rh.v1.11.1"
      "openshift-pipelines-operator-rh.v1.12.0"
      "openshift-pipelines-operator-rh.v1.12.1"
      "openshift-pipelines-operator-rh.v1.12.2"
      "openshift-pipelines-operator-rh.v1.13.0"
      "openshift-pipelines-operator-rh.v1.14.1"
      "openshift-pipelines-operator-rh.v1.14.2"
      "openshift-pipelines-operator-rh.v1.14.3"
      "openshift-pipelines-operator-rh.v1.14.4"
      Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して、Operator または拡張機能の CR で指定されているバージョンまたはチャネルを確認します。

    $ oc get clusterextension <operator_name> -o yaml
    Copy to Clipboard Toggle word wrap

    コマンドの例

    $ oc get clusterextension pipelines-operator -o yaml
    Copy to Clipboard Toggle word wrap

    例5.19 出力例

    apiVersion: olm.operatorframework.io/v1alpha1
    kind: ClusterExtension
    metadata:
      annotations:
        kubectl.kubernetes.io/last-applied-configuration: |
          {"apiVersion":"olm.operatorframework.io/v1alpha1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","installNamespace":"openshift-operators","packageName":"openshift-pipelines-operator-rh","pollInterval":"30m","version":"\u003c1.12"}}
      creationTimestamp: "2024-06-11T15:55:37Z"
      generation: 1
      name: pipelines-operator
      resourceVersion: "69776"
      uid: 6a11dff3-bfa3-42b8-9e5f-d8babbd6486f
    spec:
      channel: latest
      installNamespace: openshift-operators
      packageName: openshift-pipelines-operator-rh
      upgradeConstraintPolicy: Enforce
      version: <1.12
    status:
      conditions:
      - lastTransitionTime: "2024-06-11T15:56:09Z"
        message: installed from "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280"
        observedGeneration: 1
        reason: Success
        status: "True"
        type: Installed
      - lastTransitionTime: "2024-06-11T15:55:50Z"
        message: resolved to "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280"
        observedGeneration: 1
        reason: Success
        status: "True"
        type: Resolved
      - lastTransitionTime: "2024-06-11T15:55:50Z"
        message: ""
        observedGeneration: 1
        reason: Deprecated
        status: "False"
        type: Deprecated
      - lastTransitionTime: "2024-06-11T15:55:50Z"
        message: ""
        observedGeneration: 1
        reason: Deprecated
        status: "False"
        type: PackageDeprecated
      - lastTransitionTime: "2024-06-11T15:55:50Z"
        message: ""
        observedGeneration: 1
        reason: Deprecated
        status: "False"
        type: ChannelDeprecated
      - lastTransitionTime: "2024-06-11T15:55:50Z"
        message: ""
        observedGeneration: 1
        reason: Deprecated
        status: "False"
        type: BundleDeprecated
      installedBundle:
        name: openshift-pipelines-operator-rh.v1.11.1
        version: 1.11.1
      resolvedBundle:
        name: openshift-pipelines-operator-rh.v1.11.1
        version: 1.11.1
    Copy to Clipboard Toggle word wrap
  3. 次のいずれかの方法を使用して CR を編集します。

    • Operator または拡張機能を特定のバージョン (1.12.1 など) に固定する場合は、次の例のように CR を編集します。

      pipelines-operator.yaml CR の例

      apiVersion: olm.operatorframework.io/v1alpha1
      kind: ClusterExtension
      metadata:
        name: pipelines-operator
      spec:
        packageName: openshift-pipelines-operator-rh
        installNamespace: <namespace>
        version: "1.12.1" 
      1
      Copy to Clipboard Toggle word wrap

      1
      バージョンを 1.11.1 から 1.12.1 に更新します。
    • 許容可能な更新バージョンの範囲を定義する場合は、次の例のように CR を編集します。

      バージョン範囲を指定した CR の例

      apiVersion: olm.operatorframework.io/v1alpha1
      kind: ClusterExtension
      metadata:
        name: pipelines-operator
      spec:
        packageName: openshift-pipelines-operator-rh
        installNamespace: <namespace>
        version: ">1.11.1, <1.13" 
      1
      Copy to Clipboard Toggle word wrap

      1
      必要なバージョン範囲が、バージョン 1.11.1 より大きく、1.13 より小さいことを指定します。詳細は、「バージョン範囲のサポート」および「バージョン比較文字列」を参照してください。
    • チャネルから解決できる最新バージョンに更新する場合は、次の例のように CR を編集します。

      チャネルを指定した CR の例

      apiVersion: olm.operatorframework.io/v1alpha1
      kind: ClusterExtension
      metadata:
        name: pipelines-operator
      spec:
        packageName: openshift-pipelines-operator-rh
        installNamespace: <namespace>
        channel: pipelines-1.13 
      1
      Copy to Clipboard Toggle word wrap

      1
      指定されたチャネルから解決できる最新リリースをインストールします。チャネルへの更新は自動的にインストールされます。
    • チャネルとバージョンまたはバージョン範囲を指定する場合は、次の例のように CR を編集します。

      チャネルとバージョン範囲を指定した CR の例

      apiVersion: olm.operatorframework.io/v1alpha1
      kind: ClusterExtension
      metadata:
        name: pipelines-operator
      spec:
        packageName: openshift-pipelines-operator-rh
        installNamespace: <namespace>
        channel: latest
        version: "<1.13"
      Copy to Clipboard Toggle word wrap

      詳細は、「ターゲットバージョンを指定するカスタムリソース (CR) の例」を参照してください。

  4. 次のコマンドを実行して、クラスターに更新を適用します。

    $ oc apply -f pipelines-operator.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    clusterextension.olm.operatorframework.io/pipelines-operator configured
    Copy to Clipboard Toggle word wrap

    ヒント

    次のコマンドを実行すると、CLI から CR にパッチを適用して変更を適用できます。

    $ oc patch clusterextension/pipelines-operator -p \
      '{"spec":{"version":"<1.13"}}' \
      --type=merge
    Copy to Clipboard Toggle word wrap

    出力例

    clusterextension.olm.operatorframework.io/pipelines-operator patched
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを実行して、チャネルとバージョンの更新が適用されていることを確認します。

    $ oc get clusterextension pipelines-operator -o yaml
    Copy to Clipboard Toggle word wrap

    例5.20 出力例

    apiVersion: olm.operatorframework.io/v1alpha1
    kind: ClusterExtension
    metadata:
      annotations:
        kubectl.kubernetes.io/last-applied-configuration: |
          {"apiVersion":"olm.operatorframework.io/v1alpha1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","installNamespace":"openshift-operators","packageName":"openshift-pipelines-operator-rh","pollInterval":"30m","version":"\u003c1.13"}}
      creationTimestamp: "2024-06-11T18:23:26Z"
      generation: 2
      name: pipelines-operator
      resourceVersion: "66310"
      uid: ce0416ba-13ea-4069-a6c8-e5efcbc47537
    spec:
      channel: latest
      installNamespace: openshift-operators
      packageName: openshift-pipelines-operator-rh
      upgradeConstraintPolicy: Enforce
      version: <1.13
    status:
      conditions:
      - lastTransitionTime: "2024-06-11T18:23:33Z"
        message: resolved to "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:814742c8a7cc7e2662598e114c35c13993a7b423cfe92548124e43ea5d469f82"
        observedGeneration: 2
        reason: Success
        status: "True"
        type: Resolved
      - lastTransitionTime: "2024-06-11T18:23:52Z"
        message: installed from "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:814742c8a7cc7e2662598e114c35c13993a7b423cfe92548124e43ea5d469f82"
        observedGeneration: 2
        reason: Success
        status: "True"
        type: Installed
      - lastTransitionTime: "2024-06-11T18:23:33Z"
        message: ""
        observedGeneration: 2
        reason: Deprecated
        status: "False"
        type: Deprecated
      - lastTransitionTime: "2024-06-11T18:23:33Z"
        message: ""
        observedGeneration: 2
        reason: Deprecated
        status: "False"
        type: PackageDeprecated
      - lastTransitionTime: "2024-06-11T18:23:33Z"
        message: ""
        observedGeneration: 2
        reason: Deprecated
        status: "False"
        type: ChannelDeprecated
      - lastTransitionTime: "2024-06-11T18:23:33Z"
        message: ""
        observedGeneration: 2
        reason: Deprecated
        status: "False"
        type: BundleDeprecated
      installedBundle:
        name: openshift-pipelines-operator-rh.v1.12.2
        version: 1.12.2
      resolvedBundle:
        name: openshift-pipelines-operator-rh.v1.12.2
        version: 1.12.2
    Copy to Clipboard Toggle word wrap

トラブルシューティング

  • 非推奨または存在しないターゲットバージョンまたはチャネルを指定する場合は、次のコマンドを実行して拡張機能のステータスを確認できます。

    $ oc get clusterextension <operator_name> -o yaml
    Copy to Clipboard Toggle word wrap

    例5.21 存在しないバージョンの出力例

    apiVersion: olm.operatorframework.io/v1alpha1
    kind: ClusterExtension
    metadata:
      annotations:
        kubectl.kubernetes.io/last-applied-configuration: |
          {"apiVersion":"olm.operatorframework.io/v1alpha1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","installNamespace":"openshift-operators","packageName":"openshift-pipelines-operator-rh","pollInterval":"30m","version":"3.0"}}
      creationTimestamp: "2024-06-11T18:23:26Z"
      generation: 3
      name: pipelines-operator
      resourceVersion: "71852"
      uid: ce0416ba-13ea-4069-a6c8-e5efcbc47537
    spec:
      channel: latest
      installNamespace: openshift-operators
      packageName: openshift-pipelines-operator-rh
      upgradeConstraintPolicy: Enforce
      version: "3.0"
    status:
      conditions:
      - lastTransitionTime: "2024-06-11T18:29:02Z"
        message: 'error upgrading from currently installed version "1.12.2": no package
          "openshift-pipelines-operator-rh" matching version "3.0" found in channel "latest"'
        observedGeneration: 3
        reason: ResolutionFailed
        status: "False"
        type: Resolved
      - lastTransitionTime: "2024-06-11T18:29:02Z"
        message: installation has not been attempted as resolution failed
        observedGeneration: 3
        reason: InstallationStatusUnknown
        status: Unknown
        type: Installed
      - lastTransitionTime: "2024-06-11T18:29:02Z"
        message: deprecation checks have not been attempted as resolution failed
        observedGeneration: 3
        reason: Deprecated
        status: Unknown
        type: Deprecated
      - lastTransitionTime: "2024-06-11T18:29:02Z"
        message: deprecation checks have not been attempted as resolution failed
        observedGeneration: 3
        reason: Deprecated
        status: Unknown
        type: PackageDeprecated
      - lastTransitionTime: "2024-06-11T18:29:02Z"
        message: deprecation checks have not been attempted as resolution failed
        observedGeneration: 3
        reason: Deprecated
        status: Unknown
        type: ChannelDeprecated
      - lastTransitionTime: "2024-06-11T18:29:02Z"
        message: deprecation checks have not been attempted as resolution failed
        observedGeneration: 3
        reason: Deprecated
        status: Unknown
        type: BundleDeprecated
    Copy to Clipboard Toggle word wrap

5.1.6. Operator の削除

ClusterExtension カスタムリソース (CR) を削除することで、Operator とそのカスタムリソース定義 (CRD) を削除できます。

前提条件

  • カタログがインストールされています。
  • Operator がインストールされています。

手順

  • 次のコマンドを実行して、Operator とその CRD を削除します。

    $ oc delete clusterextension <operator_name>
    Copy to Clipboard Toggle word wrap

    出力例

    clusterextension.olm.operatorframework.io "<operator_name>" deleted
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを実行して、Operator とそのリソースが削除されたことを確認します。

    • 次のコマンドを実行して、Operator が削除されたことを確認します。

      $ oc get clusterextensions
      Copy to Clipboard Toggle word wrap

      出力例

      No resources found
      Copy to Clipboard Toggle word wrap

    • 次のコマンドを実行して、Operator のシステム namespace が削除されたことを確認します。

      $ oc get ns <operator_name>-system
      Copy to Clipboard Toggle word wrap

      出力例

      Error from server (NotFound): namespaces "<operator_name>-system" not found
      Copy to Clipboard Toggle word wrap

5.2. エッジのアップグレード

重要

Operator Lifecycle Manager (OLM) v1 はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

インストールされたクラスター拡張機能のアップグレードエッジ (アップグレードパスまたはアップグレード制約とも呼ばれる) を決定する場合、Operator Lifecycle Manager (OLM) v1 は、OpenShift Container Platform 4.16 以降で既存の OLM セマンティクスをサポートします。このサポートは、replacesskipsskipRange ディレクティブなど、既存の OLM の動作に従いますが、いくつかの違いがあります。

既存の OLM セマンティクスをサポートすることにより、OLM v1 はカタログからのアップグレードグラフを正確に尊重するようになりました。

重要

現在、Operator Lifecycle Manager (OLM) v1 は、Red Hat が提供する Operator カタログなどのプライベートレジストリーを認証できません。これは既知の問題です。その結果、Red Hat Operators カタログがインストールされていることを前提とする OLM v1 の手順は機能しません。(OCPBUGS-36364)

元の既存 OLM 実装との違い

  • 複数の後継候補がある場合の OLM v1 の動作は、次のように異なります。

    • 既存の OLM では、チャネルヘッドに最も近い後継が選択されます。
    • OLM v1 では、後継の中でセマンティックバージョン (semver) が最も大きいものが選択されます。
  • 次のファイルベースカタログ (FBC) チャネルエントリーのセットを検討してください。

    # ...
    - name: example.v3.0.0
      skips: ["example.v2.0.0"]
    - name: example.v2.0.0
      skipRange: >=1.0.0 <2.0.0
    Copy to Clipboard Toggle word wrap

    1.0.0 がインストールされている場合、OLM v1 の動作は次のように異なります。

    • v2.0.0 はスキップされ、replaces チェーン上にないため、既存の OLM は v2.0.0 へのアップグレードエッジを検出しません。
    • OLM v1 には replaces チェーンの概念がないため、OLM v1 はアップグレードエッジを検出します。OLM v1 は、現在インストールされているバージョンに対応する replaceskip、または skipRange の値を持つすべてのエントリーを検索します。

5.2.1. バージョン範囲のサポート

Operator Lifecycle Manager (OLM) v1 では、Operator または拡張機能のカスタムリソース (CR) で比較文字列を使用してバージョン範囲を指定できます。CR でバージョン範囲を指定すると、OLM v1 は、そのバージョン範囲内で解決できる Operator の最新バージョンをインストールまたは更新します。

解決されるバージョンのワークフロー

  • 解決されるバージョンは、Operator と環境の制約を満たす Operator の最新バージョンです。
  • 正常に解決された場合、指定された範囲内の Operator 更新は自動的にインストールされます。
  • 指定された範囲外にある場合、または正常に解決できない場合、その更新はインストールされません。

5.2.2. バージョン比較文字列

Operator または拡張機能のカスタムリソース (CR) の spec.version フィールドに比較文字列を追加することで、バージョン範囲を定義できます。比較文字列は、スペースまたはコンマで区切られた値と、二重引用符 (") で囲まれた 1 つ以上の比較演算子のリストです。文字列の間に比較演算子の OR または二重縦棒 (||) を含めることで、別の比較文字列を追加できます。

Expand
表5.4 基本的な比較
比較演算子定義

=

等しい

!=

等しくない

>

より大きい

<

より小さい

>=

より大か等しい

<=

より小か等しい

次の例のような範囲比較を使用して、Operator または拡張機能の CR でバージョン範囲を指定できます。

バージョン範囲の比較例

apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  installNamespace: <namespace_name>
  version: ">=1.11, <1.13"
Copy to Clipboard Toggle word wrap

すべてのタイプの比較文字列でワイルドカード文字を使用できます。OLM v1 では、xX、およびアスタリスク (*) をワイルドカード文字として使用できます。ワイルドカード文字と比較演算子の等号 (=) を使用する場合は、パッチまたはマイナーバージョンレベルでの比較を定義します。

Expand
表5.5 比較文字列内のワイルドカード文字の例
ワイルドカード比較一致する文字列

1.11.x

>=1.11.0, <1.12.0

>=1.12.X

>=1.12.0

<=2.x

<3

*

>=0.0.0

比較演算子のチルダ (~) を使用して、パッチリリースを比較できます。パッチリリースの比較では、次のメジャーバージョンまでのマイナーバージョンを指定します。

Expand
表5.6 パッチリリースの比較例
パッチリリースの比較一致する文字列

~1.11.0

>=1.11.0, <1.12.0

~1

>=1, <2

~1.12

>=1.12, <1.13

~1.12.x

>=1.12.0, <1.13.0

~1.x

>=1, <2

比較演算子のキャレット (^) を使用して、メジャーリリースを比較できます。最初の stable リリースが公開される前にメジャーリリース比較を使用する場合、マイナーバージョンにより API の安定レベルが定義されます。セマンティックバージョン (semver) 仕様では、最初の安定リリースは 1.0.0 バージョンとして公開されます。

Expand
表5.7 メジャーリリースの比較例
メジャーリリースの比較一致する文字列

^0

>=0.0.0, <1.0.0

^0.0

>=0.0.0, <0.1.0

^0.0.3

>=0.0.3, <0.0.4

^0.2

>=0.2.0, <0.3.0

^0.2.3

>=0.2.3, <0.3.0

^1.2.x

>= 1.2.0, < 2.0.0

^1.2.3

>= 1.2.3, < 2.0.0

^2.x

>= 2.0.0, < 3

^2.3

>= 2.3, < 3

5.2.3. ターゲットバージョンを指定するカスタムリソース (CR) の例

Operator Lifecycle Manager (OLM) v1 では、クラスター管理者はカスタムリソース (CR) で Operator または拡張機能のターゲットバージョンを宣言的に設定できます。

次のフィールドのいずれかを指定して、ターゲットバージョンを定義できます。

  • チャネル
  • バージョン番号
  • バージョン範囲

CR でチャネルを指定すると、OLM v1 は、指定されたチャネル内で解決できる最新バージョンの Operator または拡張機能をインストールします。指定されたチャネルに更新が公開されると、OLM v1 はそのチャネルから解決できる最新リリースに自動的に更新します。

チャネルを指定した CR の例

apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  installNamespace: <namespace_name>
  serviceAccount:
    name: <service_account>
  channel: latest 
1
Copy to Clipboard Toggle word wrap

1
指定されたチャネルから解決できる最新リリースをインストールします。チャネルへの更新は自動的にインストールされます。

CR で Operator または拡張機能のターゲットバージョンを指定すると、OLM v1 は指定されたバージョンをインストールします。CR でターゲットバージョンが指定されている場合、カタログに更新が公開されても OLM v1 はターゲットバージョンを変更しません。

クラスターにインストールされている Operator のバージョンを更新する必要がある場合は、Operator の CR を手動で編集する必要があります。Operator のターゲットバージョンを指定すると、Operator のバージョンが指定されたリリースに固定されます。

ターゲットバージョンを指定した CR の例

apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  installNamespace: <namespace_name>
  serviceAccount:
    name: <service_account>
  version: "1.11.1" 
1
Copy to Clipboard Toggle word wrap

1
ターゲットのバージョンを指定します。インストールされている Operator または拡張機能のバージョンを更新する必要がある場合は、CR のこのフィールドを目的のターゲットバージョンに手動で更新する必要があります。

Operator または拡張機能の許容可能なバージョン範囲を定義する場合は、比較文字列を使用してバージョン範囲を指定できます。バージョン範囲を指定すると、OLM v1 は、Operator Controller で解決できる最新バージョンの Operator または拡張機能をインストールします。

バージョン範囲を指定した CR の例

apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  installNamespace: <namespace_name>
  serviceAccount:
    name: <service_account>
  version: ">1.11.1" 
1
Copy to Clipboard Toggle word wrap

1
必要なバージョン範囲が、バージョン 1.11.1 より大きいことを指定します。詳細は、「バージョン範囲のサポート」を参照してください。

CR を作成または更新した後、次のコマンドを実行して設定ファイルを適用します。

コマンド構文

$ oc apply -f <extension_name>.yaml
Copy to Clipboard Toggle word wrap

5.2.4. 更新またはロールバックの強制

OLM v1 は、次のメジャーバージョンへの自動更新や以前のバージョンへのロールバックをサポートしていません。メジャーバージョンの更新またはロールバックを実行する場合は、手動で更新を確認して強制する必要があります。

警告

手動更新またはロールバックを強制した場合の影響を確認する必要があります。更新またはロールバックの強制を検証しないと、データ損失などの致命的な結果が生じる可能性があります。

前提条件

  • カタログがインストールされています。
  • Operator または拡張機能がインストールされている。
  • サービスアカウントを作成し、インストールする拡張機能をインストール、更新、管理するために十分なロールベースのアクセス制御 (RBAC) を割り当てました。詳細は GCP サービスアカウントの作成 を参照してください。

手順

  1. 次の例に示すように、Operator または拡張機能のカスタムリソース (CR) を編集します。

    CR の例:

    apiVersion: olm.operatorframework.io/v1alpha1
    kind: Operator
    metadata:
      name: <operator_name> 
    1
    
    spec:
      packageName: <package_name> 
    2
    
      installNamespace: <namespace_name>
      serviceAccount:
        name: <service_account>
      version: <version> 
    3
    
      upgradeConstraintPolicy: Ignore 
    4
    Copy to Clipboard Toggle word wrap

    1
    Operator または拡張機能の名前を指定します (pipelines-operator など)。
    2
    openshift-pipelines-operator-rh などのパッケージ名を指定します。
    3
    ブロックされた更新またはロールバックのバージョンを指定します。
    4
    オプション: アップグレード制約ポリシーを指定します。更新またはロールバックを強制するには、このフィールドを Ignore に設定します。指定しない場合、デフォルト設定は Enforce になります。
  2. 次のコマンドを実行して、Operator または拡張機能 CR に変更を適用します。

    $ oc apply -f <extension_name>.yaml
    Copy to Clipboard Toggle word wrap

5.3. カスタムリソース定義 (CRD) アップグレードの安全性

重要

Operator Lifecycle Manager (OLM) v1 はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

クラスター拡張機能によって提供されるカスタムリソース定義 (CRD) を更新すると、Operator Lifecycle Manager (OLM) v1 は CRD アップグレードの安全性事前チェックを実行し、その CRD の以前のバージョンとの下位互換性を確保します。CRD 更新は、クラスター上で変更が進行する前にその検証に合格する必要があります。

5.3.1. 禁止されている CRD アップグレード変更

既存のカスタムリソース定義 (CRD) に対する次の変更は、CRD アップグレードの安全性事前チェックによって検出され、アップグレードが妨げられます。

  • 既存の CRD バージョンに新しい必須フィールドを追加する
  • 既存の CRD バージョンから既存フィールドを削除する
  • 既存の CRD バージョンで既存のフィールドタイプを変更する
  • 以前はデフォルト値がなかったフィールドに新しいデフォルト値を追加する
  • フィールドのデフォルト値を変更する
  • フィールドの既存のデフォルト値を削除する
  • これまで列挙制限がなかった既存フィールドに新しい列挙制限を追加する
  • 既存フィールドから既存の列挙値を削除する
  • 既存バージョンで既存フィールドの最小値を増やす
  • 既存バージョンで既存フィールドの最大値を減らす
  • 以前は制約がなかったフィールドに、最小または最大のフィールド制約を追加する
注記

最小値と最大値の変更に関するルールは、minimumminLengthminPropertiesminItemsmaximummaxLengthmaxProperties、および maxItems の制約に適用されます。

既存の CRD に対する次の変更は、CRD アップグレードの安全性事前チェックによって報告され、アップグレードが防止されます。ただし、操作は技術的には Kubernetes API サーバーによって処理されます。

  • スコープを Cluster から Namespace へ、または Namespace から クラスター に変更する
  • 既存の保存された CRD バージョンを削除する

CRD アップグレード安全性事前チェックで禁止されているアップグレード変更のいずれかが検出されると、CRD アップグレードで検出された禁止されている変更ごとにエラーがログに記録されます。

ヒント

CRD への変更が禁止されている変更カテゴリーのいずれにも該当せず、許可されている変更として適切に検出もされない場合、CRD アップグレードの安全性事前チェックによってアップグレードが防止され、"未知の変更" としてエラーがログに記録されます。

5.3.2. 許可された CRD アップグレード変更

既存のカスタムリソース定義 (CRD) に対する次の変更は、下位互換性の観点で安全であり、CRD アップグレードの安全性事前チェックによってアップグレードが停止されることはありません。

  • フィールドで許可された列挙値のリストに新しい列挙値を追加する
  • 既存バージョンで既存の必須フィールドをオプションフィールドに変更する
  • 既存バージョンで既存フィールドの最小値を減らす
  • 既存バージョンで既存フィールドの最大値を増やす
  • 既存バージョンを変更せずに新規 CRD バージョンを追加する

5.3.3. CRD アップグレードの安全性事前チェックを無効にする

カスタムリソース定義 (CRD) アップグレード安全性事前チェックは、CRD を提供する ClusterExtension オブジェクトに、preflight.crdUpgradeSafety.disabled フィールドを true の値で追加することで無効にできます。

警告

CRD アップグレードの安全性事前チェックを無効にすると、保存されている CRD バージョンとの下位互換性が失われ、クラスターでその他の予期しない結果が発生する可能性があります。

個々のフィールド検証を無効にすることはできません。CRD アップグレードの安全性事前チェックを無効にすると、すべてのフィールド検証が無効になります。

注記

次のチェックは Kubernetes API サーバーによって処理されます。

  • スコープを Cluster から Namespace へ、または Namespace から クラスター に変更する
  • 既存の保存された CRD バージョンを削除する

Operator Lifecycle Manager (OLM) v1 を介して CRD アップグレードの安全性事前チェックを無効にした後も、これら 2 つの操作は Kubernetes によって引き続き防止されます。

前提条件

  • クラスター拡張機能がインストールされている。

手順

  1. CRD の ClusterExtension オブジェクトを編集します。

    $ oc edit clusterextension <clusterextension_name>
    Copy to Clipboard Toggle word wrap
  2. preflight.crdUpgradeSafety.disabled フィールドを true に設定します。

    例5.22 ClusterExtension オブジェクトの例

    apiVersion: olm.operatorframework.io/v1alpha1
    kind: ClusterExtension
    metadata:
        name: clusterextension-sample
    spec:
        installNamespace: default
        packageName: argocd-operator
        version: 0.6.0
        preflight:
            crdUpgradeSafety:
                disabled: true 
    1
    Copy to Clipboard Toggle word wrap
    1
    true に設定します。

5.3.4. 安全でない CRD 変更の例

次の例は、CRD アップグレードの安全性事前チェックで検出される、サンプルカスタムリソース定義 (CRD) のセクションに対する特定の変更を示しています。

次の例では、いかが変更前の CRD オブジェクトの状態であると想定します。

例5.23 CRD オブジェクトの例

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  annotations:
    controller-gen.kubebuilder.io/version: v0.13.0
  name: example.test.example.com
spec:
  group: test.example.com
  names:
    kind: Sample
    listKind: SampleList
    plural: samples
    singular: sample
  scope: Namespaced
  versions:
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        properties:
          apiVersion:
            type: string
          kind:
            type: string
          metadata:
            type: object
          spec:
            type: object
          status:
            type: object
          pollInterval:
            type: string
        type: object
    served: true
    storage: true
    subresources:
      status: {}
Copy to Clipboard Toggle word wrap
5.3.4.1. スコープの変更

次のカスタムリソース定義 (CRD) の例では、scope フィールドが Namespaced から Cluster に変更されています。

例5.24 CRD におけるスコープ変更の例

    spec:
      group: test.example.com
      names:
        kind: Sample
        listKind: SampleList
        plural: samples
        singular: sample
      scope: Cluster
      versions:
      - name: v1alpha1
Copy to Clipboard Toggle word wrap

例5.25 エラー出力の例

validating upgrade for CRD "test.example.com" failed: CustomResourceDefinition test.example.com failed upgrade safety validation. "NoScopeChange" validation failed: scope changed from "Namespaced" to "Cluster"
Copy to Clipboard Toggle word wrap
5.3.4.2. 保存されたバージョンの削除

次のカスタムリソース定義 (CRD) の例では、既存の保存バージョン v1alpha1 が削除されています。

例5.26 CRD で保存されたバージョンを削除した例

      versions:
      - name: v1alpha2
        schema:
          openAPIV3Schema:
            properties:
              apiVersion:
                type: string
              kind:
                type: string
              metadata:
                type: object
              spec:
                type: object
              status:
                type: object
              pollInterval:
                type: string
            type: object
Copy to Clipboard Toggle word wrap

例5.27 エラー出力の例

validating upgrade for CRD "test.example.com" failed: CustomResourceDefinition test.example.com failed upgrade safety validation. "NoStoredVersionRemoved" validation failed: stored version "v1alpha1" removed
Copy to Clipboard Toggle word wrap
5.3.4.3. 既存フィールドの削除

次のカスタムリソース定義 (CRD) の例では、pollInterval プロパティーフィールドが v1alpha1 スキーマから削除されています。

例5.28 CRD の既存フィールドの削除例

      versions:
      - name: v1alpha1
        schema:
          openAPIV3Schema:
            properties:
              apiVersion:
                type: string
              kind:
                type: string
              metadata:
                type: object
              spec:
                type: object
              status:
                type: object
            type: object
Copy to Clipboard Toggle word wrap

例5.29 エラー出力の例

validating upgrade for CRD "test.example.com" failed: CustomResourceDefinition test.example.com failed upgrade safety validation. "NoExistingFieldRemoved" validation failed: crd/test.example.com version/v1alpha1 field/^.spec.pollInterval may not be removed
Copy to Clipboard Toggle word wrap
5.3.4.4. 必須フィールドの追加

次のカスタムリソース定義 (CRD) の例では、pollInterval プロパティーが必須フィールドに変更されています。

例5.30 CRD に必須フィールドを追加する例

      versions:
      - name: v1alpha2
        schema:
          openAPIV3Schema:
            properties:
              apiVersion:
                type: string
              kind:
                type: string
              metadata:
                type: object
              spec:
                type: object
              status:
                type: object
              pollInterval:
                type: string
            type: object
            required:
            - pollInterval
Copy to Clipboard Toggle word wrap

例5.31 エラー出力の例

validating upgrade for CRD "test.example.com" failed: CustomResourceDefinition test.example.com failed upgrade safety validation. "ChangeValidator" validation failed: version "v1alpha1", field "^": new required fields added: [pollInterval]
Copy to Clipboard Toggle word wrap

Legal Notice

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat