拡張機能
Operator Lifecycle Manager (OLM) v1 を使用した、OpenShift Container Platform 拡張機能の操作方法。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 を通じて拡張機能の管理を簡素化します。
新しい
ClusterExtensionAPI は、ユーザー向け API を単一のオブジェクトに統合することで、registry+v1バンドル形式を介した Operator などのインストール済み拡張機能の管理を効率化します。この API は、新しい Operator Controller コンポーネントによってclusterextension.olm.operatorframework.ioとして提供されます。管理者と SRE は、この API を使用してプロセスを自動化し、GitOps の原則に基づき望ましい状態を定義できます。注記OLM v1 の以前のテクノロジープレビューフェーズでは、新しい
OperatorAPI が導入されました。この API は、OpenShift Container Platform 4.16 でClusterExtensionに名前が変更され、以下の改善が加えられました。- クラスターの機能を拡張する簡素化された機能をより正確に反映します。
- より柔軟なパッケージ形式をより良く表現します。
-
接頭辞
Clusterは、ClusterExtensionオブジェクトがクラスタースコープであることを明確に示します。これは、Operator が namespace スコープまたはクラスタースコープのいずれかになる可能性がある既存の OLM からの変更です。
-
新しい catalogd コンポーネントによって提供される
CatalogAPI は、OLM v1 の基盤として機能し、クラスター上のクライアント用にカタログを展開して、ユーザーが Kubernetes 拡張機能や Operator などのインストール可能なコンテンツを検出できるようにします。これにより、詳細、チャネル、更新エッジなど、利用可能なすべての Operator バンドルバージョンの可視性が向上します。
重要現在、Operator Lifecycle Manager (OLM) v1 は、Red Hat が提供する Operator カタログなどのプライベートレジストリーを認証できません。これは既知の問題です。その結果、Red Hat Operators カタログがインストールされていることを前提とする OLM v1 の手順は機能しません。(OCPBUGS-36364)
詳細は、Operator Controller と Catalogd を参照してください。
- 拡張更新の制御の改善
- カタログの内容に対する洞察が向上したため、管理者はインストールと更新のターゲットバージョンを指定できます。これにより、管理者は拡張機能の更新の対象バージョンをより細かく制御できるようになります。詳細は、クラスター拡張機能の更新 を参照してください。
- 柔軟な拡張機能パッケージ形式
管理者は、既存の 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 オブジェクトの例
2.2.1.1. ターゲットバージョンを指定するカスタムリソース (CR) の例 リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) v1 では、クラスター管理者はカスタムリソース (CR) で Operator または拡張機能のターゲットバージョンを宣言的に設定できます。
次のフィールドのいずれかを指定して、ターゲットバージョンを定義できます。
- チャネル
- バージョン番号
- バージョン範囲
CR でチャネルを指定すると、OLM v1 は、指定されたチャネル内で解決できる最新バージョンの Operator または拡張機能をインストールします。指定されたチャネルに更新が公開されると、OLM v1 はそのチャネルから解決できる最新リリースに自動的に更新します。
チャネルを指定した CR の例
- 1
- 指定されたチャネルから解決できる最新リリースをインストールします。チャネルへの更新は自動的にインストールされます。
CR で Operator または拡張機能のターゲットバージョンを指定すると、OLM v1 は指定されたバージョンをインストールします。CR でターゲットバージョンが指定されている場合、カタログに更新が公開されても OLM v1 はターゲットバージョンを変更しません。
クラスターにインストールされている Operator のバージョンを更新する必要がある場合は、Operator の CR を手動で編集する必要があります。Operator のターゲットバージョンを指定すると、Operator のバージョンが指定されたリリースに固定されます。
ターゲットバージョンを指定した CR の例
- 1
- ターゲットのバージョンを指定します。インストールされている Operator または拡張機能のバージョンを更新する必要がある場合は、CR のこのフィールドを目的のターゲットバージョンに手動で更新する必要があります。
Operator または拡張機能の許容可能なバージョン範囲を定義する場合は、比較文字列を使用してバージョン範囲を指定できます。バージョン範囲を指定すると、OLM v1 は、Operator Controller で解決できる最新バージョンの Operator または拡張機能をインストールします。
バージョン範囲を指定した CR の例
- 1
- 必要なバージョン範囲が、バージョン
1.11.1より大きいことを指定します。詳細は、「バージョン範囲のサポート」を参照してください。
CR を作成または更新した後、次のコマンドを実行して設定ファイルを適用します。
コマンド構文
oc apply -f <extension_name>.yaml
$ oc apply -f <extension_name>.yaml
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 つのクラスター拡張機能が
Deployment、CustomResourceDefinition、Serviceオブジェクトなどの特定のオブジェクトを管理する場合、別のクラスター拡張機能は同じオブジェクトの所有権を主張できません。そのような試みは、すべて 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
CustomResourceDefinition 'logfilemetricexporters.logging.kubernetes.io' already exists in namespace 'kubernetes-logging' and cannot be managed by operator-controller
このエラーメッセージは、オブジェクトがすでに別のクラスター拡張機能によって管理されており、再割り当てまたは共有できないことを示します。
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 ツール (例:
jqCLI) を使用して、手動でカタログメタデータを簡単に操作できます。この編集機能により、以下の機能とユーザー定義の拡張が有効になります。
- 既存のバンドルの新規チャネルへのプロモート
- パッケージのデフォルトチャネルの変更
- アップグレードエッジを追加、更新、および削除するためのカスタムアルゴリズム
- コンポーザービリティー
ファイルベースのカタログは、任意のディレクトリー階層に保管され、カタログの作成が可能になります。たとえば、2 つのファイルベースのカタログディレクトリー (
catalogAおよびcatalogB) を見てみましょう。カタログメンテナーは、新規のディレクトリーcatalogCを作成してcatalogAとcatalogBをそのディレクトリーにコピーし、新しく結合カタログを作成できます。このコンポーザービリティーにより、カタログの分散化が可能になります。この形式により、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 ファイル
カタログメンテナーは、必要なレイアウトを柔軟に選択できますが、各パッケージのファイルベースのカタログ Blob は別々のサブディレクトリーに保管することを推奨します。個々のファイルは JSON または YAML のいずれかをしようしてください。カタログ内のすべてのファイルが同じ形式を使用する必要はありません。
推奨される基本構造
この推奨の構造には、ディレクトリー階層内の各サブディレクトリーは自己完結型のカタログであるという特性があるので、カタログの作成、検出、およびナビゲーションなどのファイルシステムの操作が簡素化されます。このカタログは、親カタログのルートディレクトリーにコピーして親カタログに追加することもできます。
4.1.3. スキーマ リンクのコピーリンクがクリップボードにコピーされました!
ファイルベースのカタログは、任意のスキーマで拡張できる CUE 言語仕様 に基づく形式を使用します。以下の _Meta CUE スキーマは、すべてのファイルベースのカタログ Blob が順守する必要のある形式を定義します。
_Meta スキーマ
この仕様にリストされている CUE スキーマは網羅されていると見なされます。opm validate コマンドには、CUE で簡潔に記述するのが困難または不可能な追加の検証が含まれます。
Operator Lifecycle Manager(OLM) カタログは、現時点で OLM の既存のパッケージおよびバンドルの概念に対応する 3 つのスキーマ (olm.package、olm.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 スキーマ
4.1.3.2. olm.channel スキーマ リンクのコピーリンクがクリップボードにコピーされました!
olm.channel スキーマは、パッケージ内のチャネル、チャネルのメンバーであるバンドルエントリー、およびそれらのバンドルのアップグレードエッジを定義します。
バンドルエントリーが複数の olm.channel Blob 内のエッジを表す場合、バンドルエントリーはチャネルごとに 1 つだけ指定できます。
エントリーの replaces 値が、このカタログにも別のカタログにも存在しない別のバンドル名を参照していても、有効とされます。ただし、他のすべてのチャネルの普遍条件に該当する必要があります (チャネルに複数のヘッドがない場合など)。
例4.2 olm.channel スキーマ
skipRange フィールドを使用すると、スキップされた Operator バージョンが更新グラフからプルーニングされ、ユーザーが Subscription オブジェクトの spec.startingCSV プロパティーを使用してそのバージョンをインストールできなくなります。
skipRange フィールドと replaces フィールドの両方を使用すると、以前にインストールしたバージョンをユーザーが将来インストールできるように維持しながら、Operator を段階的に更新できます。replaces フィールドが当該 Operator バージョンの直前のバージョンを参照していることを確認してください。
4.1.3.3. olm.bundle スキーマ リンクのコピーリンクがクリップボードにコピーされました!
例4.3 olm.bundle スキーマ
4.1.3.4. olm.deprecations スキーマ リンクのコピーリンクがクリップボードにコピーされました!
オプションの olm.deprecations スキーマは、カタログ内のパッケージ、バンドル、チャネルの非推奨情報を定義します。Operator の作成者は、このスキーマを使用して、サポートステータスや推奨アップグレードパスなど、Operator に関する関連メッセージを、カタログから Operator を実行しているユーザーに提供できます。
このスキーマが定義されている場合、OpenShift Container Platform の Web コンソールで、OperatorHub のインストール前ページとインストール後ページの両方に、カスタムの非推奨メッセージを含め、Operator の影響を受ける要素に対する警告バッジが表示されます。
olm.deprecations スキーマエントリーには、非推奨の範囲を示す次の reference タイプが 1 つ以上含まれています。Operator がインストールされると、指定されたメッセージが、関連する Subscription オブジェクトのステータス状況として表示されます。
| 型 | Scope | ステータス状況 |
|---|---|---|
|
| パッケージ全体を表します。 |
|
|
| 1 つのチャンネルを表します。 |
|
|
| 1 つのバンドルバージョンを表します。 |
|
次の例で詳しく説明するように、各 reference タイプには独自の要件があります。
例4.4 各 reference タイプを使用した olm.deprecations スキーマの例
- 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
my-catalog
└── my-operator
├── index.yaml
└── deprecations.yaml
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 プロパティー
4.1.4.2. olm.gvk プロパティー リンクのコピーリンクがクリップボードにコピーされました!
olm.gvk プロパティーは、このバンドルで提供される Kubernetes API の group/version/kind(GVK) を定義します。このプロパティーは、OLM が使用して、必須の API と同じ GVK をリストする他のバンドルの依存関係として、このプロパティーでバンドルを解決します。GVK は Kubernetes GVK の検証に準拠する必要があります。
例4.6 olm.gvk プロパティー
4.1.4.3. olm.package.required リンクのコピーリンクがクリップボードにコピーされました!
olm.package.required プロパティーは、このバンドルが必要な別のパッケージのパッケージ名とバージョン範囲を定義します。バンドルにリストされている必要なパッケージプロパティーごとに、OLM は、リストされているパッケージのクラスターに必要なバージョン範囲で Operator がインストールされていることを確認します。versionRange フィールドは有効なセマンティクスバージョン (semver) の範囲である必要があります。
例4.7 olm.package.required プロパティー
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 プロパティー
4.1.5. カタログの例 リンクのコピーリンクがクリップボードにコピーされました!
ファイルベースのカタログを使用すると、カタログメンテナーは Operator のキュレーションおよび互換性に集中できます。Operator の作成者は Operator 用に Operator 固有のカタログをすでに生成しているので、カタログメンテナーは、各 Operator カタログをカタログのルートディレクトリーのサブディレクトリーにレンダリングしてビルドできます。
ファイルベースのカタログをビルドする方法は多数あります。以下の手順は、単純なアプローチの概要を示しています。
カタログの設定ファイルを 1 つ維持し、カタログ内に Operator ごとにイメージの参照を含めます。
カタログ設定ファイルのサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 設定ファイルを解析し、その参照から新規カタログを作成するスクリプトを実行します。
スクリプトの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.6. ガイドライン リンクのコピーリンクがクリップボードにコピーされました!
ファイルベースのカタログを維持する場合には、以下のガイドラインを考慮してください。
4.1.6.1. イミュータブルなバンドル リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager(OLM) に関する一般的なアドバイスとして、バンドルイメージとそのメタデータをイミュータブルとして処理する必要がある点があります。
破損したバンドルがカタログにプッシュされている場合には、少なくとも 1 人のユーザーがそのバンドルにアップグレードしたと想定する必要があります。この仮定に基づいて、破損したバンドルがインストールされたユーザーがアップグレードを受信できるように、破損したバンドルから、アップグレードエッジが含まれる別のバンドルをリリースする必要があります。OLM は、カタログでバンドルの内容が更新された場合に、インストールされたバンドルは再インストールされません。
ただし、カタログメタデータの変更が推奨される場合があります。
-
チャネルプロモーション: バンドルをすでにリリースし、後で別のチャネルに追加することにした場合は、バンドルのエントリーを別の
olm.channelBlob に追加できます。 -
新規アップグレードエッジ:
1.2.zバンドルバージョンを新たにリリースしたが (例:1.2.4)、1.3.0がすでにリリースされている場合は、1.2.4をスキップするように1.3.0のカタログメタデータを更新できます。
4.1.6.2. ソース制御 リンクのコピーリンクがクリップボードにコピーされました!
カタログメタデータはソースコントロールに保存され、信頼できる情報源として処理される必要があります。以下の手順で、カタログイメージを更新する必要があります。
- ソース制御されたカタログディレクトリーを新規コミットを使用して更新します。
-
カタログイメージをビルドし、プッシュします。ユーザーがカタログが利用可能になり次第更新を受信できるように、一貫性のあるタグ付け (
:latestor:<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 によって提供されます。
| カタログ | インデックスイメージ | 説明 |
|---|---|---|
|
|
| Red Hat によってパッケージ化され、出荷される Red Hat 製品。Red Hat によってサポートされます。 |
|
|
| 大手独立系ソフトウェアベンダー (ISV) の製品。Red Hat は ISV とのパートナーシップにより、パッケージ化および出荷を行います。ISV によってサポートされます。 |
|
|
| Red Hat Marketplace から購入できる認定ソフトウェア。 |
|
|
| 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
registry.redhat.io/redhat/redhat-operator-index:v4.8
更新後は次のようになります。
registry.redhat.io/redhat/redhat-operator-index:v4.9
registry.redhat.io/redhat/redhat-operator-index:v4.9
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-catalogdnamespace にスコープ指定されたプルシークレットが必要です。詳細は、「セキュアなレジストリーでホストされるカタログのプルシークレットを作成する」を参照してください。
Red Hat Operator カタログの例
- 1
- 新しいイメージダイジェストを確認するためにリモートレジストリーをポーリングする間隔を指定します。デフォルト値は、
24hです。有効な単位は、秒 (s)、分 (m)、および時間 (h) です。ポーリングを無効にするには、0sなどのゼロ値を設定します。
認定 Operator カタログの例
コミュニティー Operator カタログの例
次のコマンドは、クラスターにカタログを追加します。
コマンド構文
oc apply -f <catalog_name>.yaml
$ oc apply -f <catalog_name>.yaml
- 1
redhat-operators.yamlなどのカタログ CR を指定します。
4.3.3. プライベートレジストリーでホストされているカタログのプルシークレットを作成する リンクのコピーリンクがクリップボードにコピーされました!
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$ oc create secret generic <pull_secret_name> \ --from-file=.dockercfg=<file_path>/.dockercfg \ --type=kubernetes.io/dockercfg \ --namespace=openshift-catalogdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例4.9 コマンドの例
oc create secret generic redhat-cred \ --from-file=.dockercfg=/home/<username>/.dockercfg \ --type=kubernetes.io/dockercfg \ --namespace=openshift-catalogd$ oc create secret generic redhat-cred \ --from-file=.dockercfg=/home/<username>/.dockercfg \ --type=kubernetes.io/dockercfg \ --namespace=openshift-catalogdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 保護されたレジストリーのログイン認証情報を含む
$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$ oc create secret generic <pull_secret_name> \ --from-file=.dockerconfigjson=<file_path>/.docker/config.json \ --type=kubernetes.io/dockerconfigjson \ --namespace=openshift-catalogdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例4.10 コマンドの例
oc create secret generic redhat-cred \ --from-file=.dockerconfigjson=/home/<username>/.docker/config.json \ --type=kubernetes.io/dockerconfigjson \ --namespace=openshift-catalogd$ oc create secret generic redhat-cred \ --from-file=.dockerconfigjson=/home/<username>/.docker/config.json \ --type=kubernetes.io/dockerconfigjson \ --namespace=openshift-catalogdCopy to Clipboard Copied! Toggle word wrap Toggle overflow セキュアなレジストリーのログイン認証情報を含む Docker 設定ファイルがない場合は、次のコマンドを実行してプルシークレットを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例4.11 コマンドの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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-catalogdnamespace にスコープ指定されたプルシークレットが必要です。catalogd は、OpenShift Container Platform クラスターからグローバルプルシークレットを読み取ることができません。Catalogd は、それがデプロイされている namespace でのみシークレットへの参照を読み取ることができます。
手順
次の例のようなカタログカスタムリソース (CR) を作成します。
redhat-operators.yamlの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、カタログをクラスターに追加します。
oc apply -f redhat-operators.yaml
$ oc apply -f redhat-operators.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
catalog.catalogd.operatorframework.io/redhat-operators created
catalog.catalogd.operatorframework.io/redhat-operators createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、カタログのステータスを確認します。
次のコマンドを実行して、カタログが利用可能かどうかを確認します。
oc get clustercatalog
$ oc get clustercatalogCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE redhat-operators 20s
NAME AGE redhat-operators 20sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、カタログのステータスを確認します。
oc describe clustercatalog
$ oc describe clustercatalogCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.5. カタログの削除 リンクのコピーリンクがクリップボードにコピーされました!
カタログを削除するには、そのカスタムリソース (CR) を削除します。
前提条件
- カタログがインストールされています。
手順
次のコマンドを実行してカタログを削除します。
oc delete clustercatalog <catalog_name>
$ oc delete clustercatalog <catalog_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
catalog.catalogd.operatorframework.io "my-catalog" deleted
catalog.catalogd.operatorframework.io "my-catalog" deletedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、カタログが削除されたことを確認します。
oc get clustercatalog
$ oc get clustercatalogCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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) を使用するカタログイメージを作成できます。
前提条件
-
opmCLI がインストールされている。 -
podmanバージョン 1.9.3 以降がある。 - バンドルイメージがビルドされ、Docker v2-2 をサポートするレジストリーにプッシュされている。
手順
カタログを初期化します。
次のコマンドを実行して、カタログ用のディレクトリーを作成します。
mkdir <catalog_dir>
$ mkdir <catalog_dir>Copy to Clipboard Copied! Toggle word wrap Toggle overflow opm generate dockerfileコマンドを実行して、カタログイメージを構築できる Dockerfile を生成します。opm generate dockerfile <catalog_dir> \ -i registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4.17 -i registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4.17$ opm generate dockerfile <catalog_dir> \ -i registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4.171 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
-iフラグを使用して公式の Red Hat ベースイメージを指定します。それ以外の場合、Dockerfile はデフォルトのアップストリームイメージを使用します。
Dockerfile は、直前の手順で作成したカタログディレクトリーと同じ親ディレクトリーに存在する必要があります。
ディレクトリー構造の例
. ├── <catalog_dir> └── <catalog_dir>.Dockerfile
.1 ├── <catalog_dir>2 └── <catalog_dir>.Dockerfile3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow opm initコマンドを実行して、カタログに Operator のパッケージ定義を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、指定されたカタログ設定ファイルに
olm.package宣言型設定 blob を生成します。
opm renderコマンドを実行して、バンドルをカタログに追加します。opm render <registry>/<namespace>/<bundle_image_name>:<tag> \ --output=yaml \ >> <catalog_dir>/index.yaml$ opm render <registry>/<namespace>/<bundle_image_name>:<tag> \1 --output=yaml \ >> <catalog_dir>/index.yaml2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記チャネルには、1 つ以上のバンドルが含まれる必要があります。
バンドルのチャネルエントリーを追加します。たとえば、次の例を仕様に合わせて変更し、
<catalog_dir>/index.yamlファイルに追加します。チャネルエントリーの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<operator_name>の後、かつ、バージョンのvの前に、ピリオド (.) を追加するようにしてください。それ以外の場合、エントリーがopm validateコマンドに合格できません。
ファイルベースのカタログを検証します。
カタログディレクトリーに対して
opm validateコマンドを実行します。opm validate <catalog_dir>
$ opm validate <catalog_dir>Copy to Clipboard Copied! Toggle word wrap Toggle overflow エラーコードが
0であることを確認します。echo $?
$ echo $?Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
0
0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
podman buildコマンドを実行して、カタログイメージをビルドします。podman build . \ -f <catalog_dir>.Dockerfile \ -t <registry>/<namespace>/<catalog_image_name>:<tag>$ podman build . \ -f <catalog_dir>.Dockerfile \ -t <registry>/<namespace>/<catalog_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow カタログイメージをレジストリーにプッシュします。
必要に応じて、
podman loginコマンドを実行してターゲットレジストリーで認証します。podman login <registry>
$ podman login <registry>Copy to Clipboard Copied! Toggle word wrap Toggle overflow podman pushコマンドを実行して、カタログイメージをプッシュします。podman push <registry>/<namespace>/<catalog_image_name>:<tag>
$ podman push <registry>/<namespace>/<catalog_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.2. ファイルベースのカタログイメージの更新またはフィルタリング リンクのコピーリンクがクリップボードにコピーされました!
opm CLI を使用して、ファイルベースのカタログ形式を使用するカタログイメージを更新またはフィルタリングできます。既存のカタログイメージのコンテンツを抽出すると、必要に応じてカタログを変更できます。たとえば、以下を実行できます。
- パッケージの追加
- パッケージの削除
- 既存のパッケージエントリーの更新
- パッケージ、チャネル、バンドルごとの非推奨メッセージの記載
その後、イメージをカタログの更新バージョンとして再構築できます。
または、ミラーレジストリーにカタログイメージがすでにある場合は、oc-mirror CLI プラグインを使用して、ターゲットレジストリーにミラーリングする際に、そのカタログイメージの更新されたソースバージョンから削除されたイメージを自動的にプルーニングできます。
oc-mirror プラグインとこのユースケースの詳細は、「ミラーレジストリーのコンテンツを最新の状態に維持」セクション、および「oc-mirror プラグインを使用した非接続インストールのイメージのミラーリング」の「イメージのプルーニング」サブセクションを参照してください。
前提条件
ワークステーションに以下が含まれている。
-
opmCLI。 -
podmanversion 1.9.3+。 - ファイルベースのカタログイメージ。
このカタログに関連するワークステーションで最近初期化されたカタログディレクトリー構造。
初期化されたカタログディレクトリーがない場合は、ディレクトリーを作成し、Dockerfile を生成します。詳細は、「ファイルベースのカタログイメージの作成」手順の「カタログの初期化」手順を参照してください。
-
手順
カタログイメージのコンテンツを YAML 形式でカタログディレクトリーの
index.yamlファイルに展開します。opm render <registry>/<namespace>/<catalog_image_name>:<tag> \ -o yaml > <catalog_dir>/index.yaml -o yaml > <catalog_dir>/index.yaml$ opm render <registry>/<namespace>/<catalog_image_name>:<tag> \ -o yaml > <catalog_dir>/index.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記または、
-o jsonフラグを使用して JSON 形式で出力することもできます。作成された
index.yamlファイルの内容を仕様に合わせて変更します。重要バンドルがカタログに公開されたら、いずれかのユーザーがバンドルをインストールしていると想定します。カタログ内で以前に公開されたすべてのバンドルに、現在または新しいチャネルヘッドへの更新パスが設定されていることを確認し、そのバージョンがインストールされているユーザーが立ち往生するのを防ぎます。
- Operator を追加するには、「ファイルベースのカタログイメージの作成」手順のパッケージ、バンドル、およびチャネルエントリーを作成する手順に従います。
Operator を削除するには、パッケージに関連する
olm.package、olm.channel、およびolm.bundleBlob のセットを削除します。次の例は、カタログからexample-operatorパッケージを削除するために削除する必要があるセットを示しています。例4.12 削除されたエントリーの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Operator の非推奨メッセージを追加または更新するには、パッケージの
index.yamlファイルと同じディレクトリーにdeprecations.yamlファイルがあることを確認してください。deprecations.yamlファイル形式の詳細は、「olm.deprecations スキーマ」を参照してください。
- 変更を保存します。
カタログを検証します。
opm validate <catalog_dir>
$ opm validate <catalog_dir>Copy to Clipboard Copied! Toggle word wrap Toggle overflow カタログを再構築します。
podman build . \ -f <catalog_dir>.Dockerfile \ -t <registry>/<namespace>/<catalog_image_name>:<tag>$ podman build . \ -f <catalog_dir>.Dockerfile \ -t <registry>/<namespace>/<catalog_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新されたカタログイメージをレジストリーにプッシュします。
podman push <registry>/<namespace>/<catalog_image_name>:<tag>
$ podman push <registry>/<namespace>/<catalog_image_name>:<tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
- Web コンソールで、Administration → Cluster Settings → Configuration ページで OperatorHub 設定リソースに移動します。
カタログソースを追加するか、既存のカタログソースを更新して、更新されたカタログイメージのプル仕様を使用します。
詳細は、このセクションの「関連情報」にある「クラスターへのカタログソースの追加」を参照してください。
- カタログソースが READY 状態になったら、Operators → OperatorHub ページに移動し、加えた変更が 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 と拡張機能を見つけることができます。カタログをクエリーする前に、カタログサーバーサービスをポート転送する必要があります。
前提条件
- クラスターにカタログを追加している。
-
jqCLI ツールがインストールされている。
手順
次のコマンドを実行して、
openshift-catalogdnamespace のカタログサーバーサービスのポート転送を行います。oc -n openshift-catalogd port-forward svc/catalogd-catalogserver 8080:443
$ oc -n openshift-catalogd port-forward svc/catalogd-catalogserver 8080:443Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいターミナルウィンドウまたはタブで、次のコマンドを実行してカタログの JSON ファイルをローカルにダウンロードします。
curl -L -k https://localhost:8080/catalogs/<catalog_name>/all.json \ -C - -o /<path>/<catalog_name>.json -C - -o /<path>/<catalog_name>.json
$ curl -L -k https://localhost:8080/catalogs/<catalog_name>/all.json \ -C - -o /<path>/<catalog_name>.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.1 コマンドの例
curl -L -k https://localhost:8080/catalogs/redhat-operators/all.json \ -C - -o /home/username/catalogs/rhoc.json -C - -o /home/username/catalogs/rhoc.json
$ curl -L -k https://localhost:8080/catalogs/redhat-operators/all.json \ -C - -o /home/username/catalogs/rhoc.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドのいずれかを実行して、カタログ内のオペレータと拡張機能のリストを返します。
重要現在、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
$ jq -s '.[] | select(.schema == "olm.package") | .name' \ /<path>/<filename>.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.2 コマンドの例
jq -s '.[] | select(.schema == "olm.package") | .name' \ /home/username/catalogs/rhoc.json
$ jq -s '.[] | select(.schema == "olm.package") | .name' \ /home/username/catalogs/rhoc.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.3 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
AllNamespacesインストールモードをサポートし、Webhook を使用しないパッケージのリストを、ローカルカタログファイルから取得します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.4 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
拡張機能は、既存の OLM で導入された
次のコマンドを実行して、Operator または拡張機能のメタデータの内容を検査します。
jq -s '.[] | select( .schema == "olm.package") | \ select( .name == "<package_name>")' /<path>/<catalog_name>.json
$ jq -s '.[] | select( .schema == "olm.package") | \ select( .name == "<package_name>")' /<path>/<catalog_name>.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.5 コマンドの例
jq -s '.[] | select( .schema == "olm.package") | \ select( .name == "openshift-pipelines-operator-rh")' \ /home/username/rhoc.json
$ jq -s '.[] | select( .schema == "olm.package") | \ select( .name == "openshift-pipelines-operator-rh")' \ /home/username/rhoc.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.6 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.1.2.1. 一般的なカタログクエリー リンクのコピーリンクがクリップボードにコピーされました!
jq CLI ツールを使用して、カタログをクエリーできます。
| クエリー | Request |
|---|---|
| カタログで利用可能なパッケージ |
jq -s '.[] | select( .schema == "olm.package") | \ .name' <catalog_name>.json
|
|
|
|
| パッケージのメタデータ |
jq -s '.[] | select( .schema == "olm.package") | \ select( .name == "<package_name>")' <catalog_name>.json
|
| パッケージ内のカタログブロブ |
jq -s '.[] | select( .package == "<package_name>")' \ <catalog_name>.json
|
| クエリー | Request |
|---|---|
| パッケージのチャネル |
jq -s '.[] | select( .schema == "olm.channel" ) | \ select( .package == "<package_name>") | .name' \ <catalog_name>.json
|
| チャネル内のバージョン |
jq -s '.[] | select( .package == "<package_name>" ) | \ select( .schema == "olm.channel" ) | \ select( .name == "<channel_name>" ) | \ .entries | .[] | .name' <catalog_name>.json
|
|
jq -s '.[] | select( .schema == "olm.channel" ) | \ select ( .name == "<channel>") | \ select( .package == "<package_name>")' \ <catalog_name>.json
|
| クエリー | Request |
|---|---|
| パッケージ内のバンドル |
jq -s '.[] | select( .schema == "olm.bundle" ) | \ select( .package == "<package_name>") | .name' \ <catalog_name>.json
|
|
jq -s '.[] | select( .schema == "olm.bundle" ) | \ select ( .name == "<bundle_name>") | \ select( .package == "<package_name>")' \ <catalog_name>.json
|
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 クラスターにアクセスできる。
手順
次の例のように、サービスアカウントを作成します。
apiVersion: v1 kind: ServiceAccount metadata: name: <extension>-installer namespace: <namespace>
apiVersion: v1 kind: ServiceAccount metadata: name: <extension>-installer namespace: <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.7
extension-service-account.yamlファイルの例apiVersion: v1 kind: ServiceAccount metadata: name: pipelines-installer namespace: pipelines
apiVersion: v1 kind: ServiceAccount metadata: name: pipelines-installer namespace: pipelinesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行してサービスアカウントを適用します。
oc apply -f extension-service-account.yaml
$ oc apply -f extension-service-account.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のように、クラスターロールを作成し、RBAC を割り当てます。
警告次のクラスターロールは、最小権限の原則に従っていません。このクラスターロールはテスト目的に限定して使用できます。実稼働クラスターでは使用しないでください。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.8
pipelines-cluster-role.yamlファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、クラスターにクラスターロールを追加します。
oc apply -f pipelines-role.yaml
$ oc apply -f pipelines-role.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のように、クラスターロールバインディングを作成して、クラスターロールによって付与された権限をサービスアカウントにバインドします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.9
pipelines-cluster-role-binding.yamlファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、クラスターロールバインディングを適用します。
oc apply -f pipelines-cluster-role-binding.yaml
$ oc apply -f pipelines-cluster-role-binding.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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)
前提条件
- クラスターにカタログを追加している。
- カタログファイルのローカルコピーをダウンロードしている。
-
jqCLI ツールがインストールされている。 - サービスアカウントを作成し、インストールする拡張機能をインストール、更新、管理するために十分なロールベースのアクセス制御 (RBAC) を割り当てました。詳細は GCP サービスアカウントの作成 を参照してください。
手順
次の手順を実行して、カタログファイルのローカルコピーからパッケージのチャネルとバージョン情報を検査します。
次のコマンドを実行して、選択したパッケージからチャネルのリストを取得します。
jq -s '.[] | select( .schema == "olm.channel" ) | \ select( .package == "<package_name>") | \ .name' /<path>/<catalog_name>.json
$ jq -s '.[] | select( .schema == "olm.channel" ) | \ select( .package == "<package_name>") | \ .name' /<path>/<catalog_name>.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.10 コマンドの例
jq -s '.[] | select( .schema == "olm.channel" ) | \ select( .package == "openshift-pipelines-operator-rh") | \ .name' /home/username/rhoc.json
$ jq -s '.[] | select( .schema == "olm.channel" ) | \ select( .package == "openshift-pipelines-operator-rh") | \ .name' /home/username/rhoc.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.11 出力例
"latest" "pipelines-1.11" "pipelines-1.12" "pipelines-1.13" "pipelines-1.14"
"latest" "pipelines-1.11" "pipelines-1.12" "pipelines-1.13" "pipelines-1.14"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、チャネルで公開されているバージョンのリストを取得します。
jq -s '.[] | select( .package == "<package_name>" ) | \ select( .schema == "olm.channel" ) | \ select( .name == "<channel_name>" ) | .entries | \ .[] | .name' /<path>/<catalog_name>.json
$ jq -s '.[] | select( .package == "<package_name>" ) | \ select( .schema == "olm.channel" ) | \ select( .name == "<channel_name>" ) | .entries | \ .[] | .name' /<path>/<catalog_name>.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.12 コマンドの例
jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) | \ select( .schema == "olm.channel" ) | select( .name == "latest" ) | \ .entries | .[] | .name' /home/username/rhoc.json
$ jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) | \ select( .schema == "olm.channel" ) | select( .name == "latest" ) | \ .entries | .[] | .name' /home/username/rhoc.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.13 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
拡張機能を新しい namespace にインストールする場合は、次のコマンドを実行します。
oc adm new-project <new_namespace>
$ oc adm new-project <new_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例のような CR を作成します。
pipelines-operator.yamlCR の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<namespace>-
pipelinesやmy-extensionなど、バンドルをインストールする namespace を指定します。拡張機能は継続してクラスタースコープであり、異なる namespace にインストールされているリソースが含まれる可能性があります。 <service_account>- 拡張機能をインストール、更新、管理するために作成したサービスアカウントの名前を指定します。
<channel>-
オプション: インストールまたは更新するパッケージのチャネル (
pipelines-1.11、latestなど) を指定します。 <version>オプション: インストールまたは更新するパッケージのバージョンまたはバージョン範囲 (
1.11.1、1.12.x、>=1.12.1など) を指定します。詳細は、「ターゲットバージョンを指定するカスタムリソース (CR) の例」および「バージョン範囲のサポート」を参照してください。重要一意の名前を持たない Operator または拡張機能をインストールしようとすると、インストールが失敗するか、予期しない結果になる可能性があります。その原因は以下のとおりです。
- クラスターに複数のカタログがインストールされている場合、Operator Lifecycle Manager (OLM) v1 には、Operator または拡張機能のインストール時にカタログを指定するメカニズムがありません。
- OLM v1 では、クラスターにインストールできるすべての Operator および拡張機能のバンドルとパッケージに、一意の名前が使用されている必要があります。
次のコマンドを実行して、CR をクラスターに適用します。
oc apply -f pipeline-operator.yaml
$ oc apply -f pipeline-operator.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
clusterextension.olm.operatorframework.io/pipelines-operator created
clusterextension.olm.operatorframework.io/pipelines-operator createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、Operator または拡張機能の CR を YAML 形式で表示します。
oc get clusterextension pipelines-operator -o yaml
$ oc get clusterextension pipelines-operator -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.14 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
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 または拡張機能がインストールされている。
-
jqCLI ツールがインストールされている。
手順
次の手順を実行して、カタログファイルのローカルコピーからパッケージのチャネルとバージョン情報を検査します。
次のコマンドを実行して、選択したパッケージからチャネルのリストを取得します。
jq -s '.[] | select( .schema == "olm.channel" ) | \ select( .package == "<package_name>") | \ .name' /<path>/<catalog_name>.json
$ jq -s '.[] | select( .schema == "olm.channel" ) | \ select( .package == "<package_name>") | \ .name' /<path>/<catalog_name>.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.15 コマンドの例
jq -s '.[] | select( .schema == "olm.channel" ) | \ select( .package == "openshift-pipelines-operator-rh") | \ .name' /home/username/rhoc.json
$ jq -s '.[] | select( .schema == "olm.channel" ) | \ select( .package == "openshift-pipelines-operator-rh") | \ .name' /home/username/rhoc.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.16 出力例
"latest" "pipelines-1.11" "pipelines-1.12" "pipelines-1.13" "pipelines-1.14"
"latest" "pipelines-1.11" "pipelines-1.12" "pipelines-1.13" "pipelines-1.14"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、チャネルで公開されているバージョンのリストを取得します。
jq -s '.[] | select( .package == "<package_name>" ) | \ select( .schema == "olm.channel" ) | \ select( .name == "<channel_name>" ) | .entries | \ .[] | .name' /<path>/<catalog_name>.json
$ jq -s '.[] | select( .package == "<package_name>" ) | \ select( .schema == "olm.channel" ) | \ select( .name == "<channel_name>" ) | .entries | \ .[] | .name' /<path>/<catalog_name>.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.17 コマンドの例
jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) | \ select( .schema == "olm.channel" ) | select( .name == "latest" ) | \ .entries | .[] | .name' /home/username/rhoc.json
$ jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) | \ select( .schema == "olm.channel" ) | select( .name == "latest" ) | \ .entries | .[] | .name' /home/username/rhoc.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.18 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、Operator または拡張機能の CR で指定されているバージョンまたはチャネルを確認します。
oc get clusterextension <operator_name> -o yaml
$ oc get clusterextension <operator_name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow コマンドの例
oc get clusterextension pipelines-operator -o yaml
$ oc get clusterextension pipelines-operator -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.19 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のいずれかの方法を使用して CR を編集します。
Operator または拡張機能を特定のバージョン (
1.12.1など) に固定する場合は、次の例のように CR を編集します。pipelines-operator.yamlCR の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- バージョンを
1.11.1から1.12.1に更新します。
許容可能な更新バージョンの範囲を定義する場合は、次の例のように CR を編集します。
バージョン範囲を指定した CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 必要なバージョン範囲が、バージョン
1.11.1より大きく、1.13より小さいことを指定します。詳細は、「バージョン範囲のサポート」および「バージョン比較文字列」を参照してください。
チャネルから解決できる最新バージョンに更新する場合は、次の例のように CR を編集します。
チャネルを指定した CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 指定されたチャネルから解決できる最新リリースをインストールします。チャネルへの更新は自動的にインストールされます。
チャネルとバージョンまたはバージョン範囲を指定する場合は、次の例のように CR を編集します。
チャネルとバージョン範囲を指定した CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細は、「ターゲットバージョンを指定するカスタムリソース (CR) の例」を参照してください。
次のコマンドを実行して、クラスターに更新を適用します。
oc apply -f pipelines-operator.yaml
$ oc apply -f pipelines-operator.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
clusterextension.olm.operatorframework.io/pipelines-operator configured
clusterextension.olm.operatorframework.io/pipelines-operator configuredCopy to Clipboard Copied! Toggle word wrap Toggle overflow ヒント次のコマンドを実行すると、CLI から CR にパッチを適用して変更を適用できます。
oc patch clusterextension/pipelines-operator -p \ '{"spec":{"version":"<1.13"}}' \ --type=merge$ oc patch clusterextension/pipelines-operator -p \ '{"spec":{"version":"<1.13"}}' \ --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
clusterextension.olm.operatorframework.io/pipelines-operator patched
clusterextension.olm.operatorframework.io/pipelines-operator patchedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、チャネルとバージョンの更新が適用されていることを確認します。
oc get clusterextension pipelines-operator -o yaml
$ oc get clusterextension pipelines-operator -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.20 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
トラブルシューティング
非推奨または存在しないターゲットバージョンまたはチャネルを指定する場合は、次のコマンドを実行して拡張機能のステータスを確認できます。
oc get clusterextension <operator_name> -o yaml
$ oc get clusterextension <operator_name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例5.21 存在しないバージョンの出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.1.6. Operator の削除 リンクのコピーリンクがクリップボードにコピーされました!
ClusterExtension カスタムリソース (CR) を削除することで、Operator とそのカスタムリソース定義 (CRD) を削除できます。
前提条件
- カタログがインストールされています。
- Operator がインストールされています。
手順
次のコマンドを実行して、Operator とその CRD を削除します。
oc delete clusterextension <operator_name>
$ oc delete clusterextension <operator_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
clusterextension.olm.operatorframework.io "<operator_name>" deleted
clusterextension.olm.operatorframework.io "<operator_name>" deletedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、Operator とそのリソースが削除されたことを確認します。
次のコマンドを実行して、Operator が削除されたことを確認します。
oc get clusterextensions
$ oc get clusterextensionsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
No resources found
No resources foundCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Operator のシステム namespace が削除されたことを確認します。
oc get ns <operator_name>-system
$ oc get ns <operator_name>-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Error from server (NotFound): namespaces "<operator_name>-system" not found
Error from server (NotFound): namespaces "<operator_name>-system" not foundCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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 セマンティクスをサポートします。このサポートは、replaces、skips、skipRange ディレクティブなど、既存の 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
# ... - name: example.v3.0.0 skips: ["example.v2.0.0"] - name: example.v2.0.0 skipRange: >=1.0.0 <2.0.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 1.0.0がインストールされている場合、OLM v1 の動作は次のように異なります。-
v2.0.0はスキップされ、replacesチェーン上にないため、既存の OLM はv2.0.0へのアップグレードエッジを検出しません。 -
OLM v1 には
replacesチェーンの概念がないため、OLM v1 はアップグレードエッジを検出します。OLM v1 は、現在インストールされているバージョンに対応するreplace、skip、または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 または二重縦棒 (||) を含めることで、別の比較文字列を追加できます。
| 比較演算子 | 定義 |
|---|---|
|
| 等しい |
|
| 等しくない |
|
| より大きい |
|
| より小さい |
|
| より大か等しい |
|
| より小か等しい |
次の例のような範囲比較を使用して、Operator または拡張機能の CR でバージョン範囲を指定できます。
バージョン範囲の比較例
すべてのタイプの比較文字列でワイルドカード文字を使用できます。OLM v1 では、x、X、およびアスタリスク (*) をワイルドカード文字として使用できます。ワイルドカード文字と比較演算子の等号 (=) を使用する場合は、パッチまたはマイナーバージョンレベルでの比較を定義します。
| ワイルドカード比較 | 一致する文字列 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
比較演算子のチルダ (~) を使用して、パッチリリースを比較できます。パッチリリースの比較では、次のメジャーバージョンまでのマイナーバージョンを指定します。
| パッチリリースの比較 | 一致する文字列 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
比較演算子のキャレット (^) を使用して、メジャーリリースを比較できます。最初の stable リリースが公開される前にメジャーリリース比較を使用する場合、マイナーバージョンにより API の安定レベルが定義されます。セマンティックバージョン (semver) 仕様では、最初の安定リリースは 1.0.0 バージョンとして公開されます。
| メジャーリリースの比較 | 一致する文字列 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.2.3. ターゲットバージョンを指定するカスタムリソース (CR) の例 リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) v1 では、クラスター管理者はカスタムリソース (CR) で Operator または拡張機能のターゲットバージョンを宣言的に設定できます。
次のフィールドのいずれかを指定して、ターゲットバージョンを定義できます。
- チャネル
- バージョン番号
- バージョン範囲
CR でチャネルを指定すると、OLM v1 は、指定されたチャネル内で解決できる最新バージョンの Operator または拡張機能をインストールします。指定されたチャネルに更新が公開されると、OLM v1 はそのチャネルから解決できる最新リリースに自動的に更新します。
チャネルを指定した CR の例
- 1
- 指定されたチャネルから解決できる最新リリースをインストールします。チャネルへの更新は自動的にインストールされます。
CR で Operator または拡張機能のターゲットバージョンを指定すると、OLM v1 は指定されたバージョンをインストールします。CR でターゲットバージョンが指定されている場合、カタログに更新が公開されても OLM v1 はターゲットバージョンを変更しません。
クラスターにインストールされている Operator のバージョンを更新する必要がある場合は、Operator の CR を手動で編集する必要があります。Operator のターゲットバージョンを指定すると、Operator のバージョンが指定されたリリースに固定されます。
ターゲットバージョンを指定した CR の例
- 1
- ターゲットのバージョンを指定します。インストールされている Operator または拡張機能のバージョンを更新する必要がある場合は、CR のこのフィールドを目的のターゲットバージョンに手動で更新する必要があります。
Operator または拡張機能の許容可能なバージョン範囲を定義する場合は、比較文字列を使用してバージョン範囲を指定できます。バージョン範囲を指定すると、OLM v1 は、Operator Controller で解決できる最新バージョンの Operator または拡張機能をインストールします。
バージョン範囲を指定した CR の例
- 1
- 必要なバージョン範囲が、バージョン
1.11.1より大きいことを指定します。詳細は、「バージョン範囲のサポート」を参照してください。
CR を作成または更新した後、次のコマンドを実行して設定ファイルを適用します。
コマンド構文
oc apply -f <extension_name>.yaml
$ oc apply -f <extension_name>.yaml
5.2.4. 更新またはロールバックの強制 リンクのコピーリンクがクリップボードにコピーされました!
OLM v1 は、次のメジャーバージョンへの自動更新や以前のバージョンへのロールバックをサポートしていません。メジャーバージョンの更新またはロールバックを実行する場合は、手動で更新を確認して強制する必要があります。
手動更新またはロールバックを強制した場合の影響を確認する必要があります。更新またはロールバックの強制を検証しないと、データ損失などの致命的な結果が生じる可能性があります。
前提条件
- カタログがインストールされています。
- Operator または拡張機能がインストールされている。
- サービスアカウントを作成し、インストールする拡張機能をインストール、更新、管理するために十分なロールベースのアクセス制御 (RBAC) を割り当てました。詳細は GCP サービスアカウントの作成 を参照してください。
手順
次の例に示すように、Operator または拡張機能のカスタムリソース (CR) を編集します。
CR の例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Operator または拡張機能 CR に変更を適用します。
oc apply -f <extension_name>.yaml
$ oc apply -f <extension_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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 バージョンで既存のフィールドタイプを変更する
- 以前はデフォルト値がなかったフィールドに新しいデフォルト値を追加する
- フィールドのデフォルト値を変更する
- フィールドの既存のデフォルト値を削除する
- これまで列挙制限がなかった既存フィールドに新しい列挙制限を追加する
- 既存フィールドから既存の列挙値を削除する
- 既存バージョンで既存フィールドの最小値を増やす
- 既存バージョンで既存フィールドの最大値を減らす
- 以前は制約がなかったフィールドに、最小または最大のフィールド制約を追加する
最小値と最大値の変更に関するルールは、minimum、minLength、minProperties、minItems、maximum、maxLength、maxProperties、および 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 によって引き続き防止されます。
前提条件
- クラスター拡張機能がインストールされている。
手順
CRD の
ClusterExtensionオブジェクトを編集します。oc edit clusterextension <clusterextension_name>
$ oc edit clusterextension <clusterextension_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow preflight.crdUpgradeSafety.disabledフィールドをtrueに設定します。例5.22
ClusterExtensionオブジェクトの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
trueに設定します。
5.3.4. 安全でない CRD 変更の例 リンクのコピーリンクがクリップボードにコピーされました!
次の例は、CRD アップグレードの安全性事前チェックで検出される、サンプルカスタムリソース定義 (CRD) のセクションに対する特定の変更を示しています。
次の例では、いかが変更前の CRD オブジェクトの状態であると想定します。
例5.23 CRD オブジェクトの例
5.3.4.1. スコープの変更 リンクのコピーリンクがクリップボードにコピーされました!
次のカスタムリソース定義 (CRD) の例では、scope フィールドが Namespaced から Cluster に変更されています。
例5.24 CRD におけるスコープ変更の例
例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"
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"
5.3.4.2. 保存されたバージョンの削除 リンクのコピーリンクがクリップボードにコピーされました!
次のカスタムリソース定義 (CRD) の例では、既存の保存バージョン v1alpha1 が削除されています。
例5.26 CRD で保存されたバージョンを削除した例
例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
validating upgrade for CRD "test.example.com" failed: CustomResourceDefinition test.example.com failed upgrade safety validation. "NoStoredVersionRemoved" validation failed: stored version "v1alpha1" removed
5.3.4.3. 既存フィールドの削除 リンクのコピーリンクがクリップボードにコピーされました!
次のカスタムリソース定義 (CRD) の例では、pollInterval プロパティーフィールドが v1alpha1 スキーマから削除されています。
例5.28 CRD の既存フィールドの削除例
例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
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
5.3.4.4. 必須フィールドの追加 リンクのコピーリンクがクリップボードにコピーされました!
次のカスタムリソース定義 (CRD) の例では、pollInterval プロパティーが必須フィールドに変更されています。
例5.30 CRD に必須フィールドを追加する例
例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]
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]
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.