Operator
OpenShift Container Platform での Operator の使用
概要
第1章 Operator の概要 リンクのコピーリンクがクリップボードにコピーされました!
Operator は OpenShift Container Platform の最も重要なコンポーネントです。これらは、コントロールプレーン上でサービスをパッケージ化、デプロイ、および管理するための推奨される方法です。Operator の使用は、ユーザーが実行するアプリケーションにも各種の利点があります。
Operator は、kubectl
や OpenShift CLI (oc
) などの Kubernetes API および CLI ツールと統合します。Operator はアプリケーションの監視、ヘルスチェックの実行、OTA (over-the-air) 更新の管理を実行し、アプリケーションが指定した状態にあることを確認するための手段となります。
Operator は、Kubernetes ネイティブアプリケーション向けに特別に設計されており、インストールや設定などの一般的な Day 1 オペレーションを実装および自動化します。Operator は、自動スケールアップや自動スケールダウン、バックアップの作成など、Day 2 オペレーションを自動化することもできます。これらのアクティビティーは、クラスター上で実行されているソフトウェアによってすべて制御されます。
どちらも同様の Operator の概念と目標に従いますが、OpenShift Container Platform の Operator は、目的に応じて 2 つの異なるシステムによって管理されます。
- クラスター Operator
- Cluster Version Operator (CVO) により管理され、クラスター機能を実行するためにデフォルトでインストールされます。
- オプションのアドオン Operator
- Operator Lifecycle Manager (OLM) により管理され、ユーザーがアプリケーションで実行するようにアクセスを可能にします。OLM ベースの Operator とも呼ばれます。
1.1. 開発者の場合 リンクのコピーリンクがクリップボードにコピーされました!
Operator 作成者は、OLM ベースの Operator に関して、次の開発タスクを実行できます。
1.2. 管理者の場合 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、OLM ベースの Operator に関して、次の管理タスクを実行できます。
Red Hat が提供するクラスター Operator の詳細は、クラスター Operator のリファレンス を参照してください。
1.3. 次のステップ リンクのコピーリンクがクリップボードにコピーされました!
第2章 Operator について リンクのコピーリンクがクリップボードにコピーされました!
2.1. Operator について リンクのコピーリンクがクリップボードにコピーされました!
概念的に言うと、Operator は人間の運用上のナレッジを使用し、これをコンシューマーと簡単に共有できるソフトウェアにエンコードします。
Operator は、ソフトウェアの他の部分を実行する運用上の複雑さを軽減するソフトウェアの特定の部分で設定されます。Operator はソフトウェアベンダーのエンジニアリングチームの拡張機能のように動作し、(OpenShift Container Platform などの) Kubernetes 環境を監視し、その最新状態に基づいてリアルタイムの意思決定を行います。高度な Operator はアップグレードをシームレスに実行し、障害に自動的に対応するように設計されており、時間の節約のためにソフトウェアのバックアッププロセスを省略するなどのショートカットを実行することはありません。
技術的に言うと、Operator は Kubernetes アプリケーションをパッケージ化し、デプロイし、管理する方法です。
Kubernetes アプリケーションは、Kubernetes にデプロイされ、Kubernetes API および kubectl
または oc
ツールを使用して管理されるアプリケーションです。Kubernetes を最大限に活用するには、Kubernetes 上で実行されるアプリケーションを提供し、管理するために拡張できるように一連の総合的な API が必要です。Operator は、Kubernetes 上でこのタイプのアプリケーションを管理するランタイムと見なすことができます。
2.1.1. Operator を使用する理由 リンクのコピーリンクがクリップボードにコピーされました!
Operator は以下を提供します。
- インストールおよびアップグレードの反復性。
- すべてのシステムコンポーネントの継続的なヘルスチェック。
- OpenShift コンポーネントおよび ISV コンテンツの OTA (Over-the-air) 更新。
- フィールドエンジニアの知識を凝縮し、1 人や 2 人だけでなくすべてのユーザーに広める場所。
- Kubernetes にデプロイする理由
- Kubernetes (延長線上で考えると OpenShift Container Platform も含まれる) には、シークレットの処理、負荷分散、サービスの検出、自動スケーリングなどの、オンプレミスおよびクラウドプロバイダーで機能する、複雑な分散システムをビルドするために必要なすべてのプリミティブが含まれます。
- アプリケーションを Kubernetes API および
kubectl
ツールで管理する理由 -
これらの API は機能的に充実しており、すべてのプラットフォームのクライアントを持ち、クラスターのアクセス制御/監査機能にプラグインします。Operator は Kubernetes の拡張メカニズム、カスタムリソース定義 (CRD、Custom Resource Definition ) を使用するため、
MongoDB
など のカスタムオブジェクトは、ビルトインされたネイティブ Kubernetes オブジェクトのように表示され、機能します。 - Operator とサービスブローカーとの比較
- サービスブローカーは、アプリケーションのプログラムによる検出およびデプロイメントを行うための 1 つの手段です。ただし、これは長期的に実行されるプロセスではないため、アップグレード、フェイルオーバー、またはスケーリングなどの Day 2 オペレーションを実行できません。カスタマイズおよびチューニング可能なパラメーターはインストール時に提供されるのに対し、Operator はクラスターの最新の状態を常に監視します。クラスター外のサービスを使用する場合は、Operator もこれらのクラスター外のサービスに使用できますが、これらをサービスブローカーで使用できます。
2.1.2. Operator Framework リンクのコピーリンクがクリップボードにコピーされました!
Operator Framework は、上記のカスタマーエクスペリエンスに関連して提供されるツールおよび機能のファミリーです。これは、コードを作成するためだけにあるのではなく、Operator のテスト、実行、および更新などの重要な機能を実行します。Operator Framework コンポーネントは、これらの課題に対応するためのオープンソースツールで構成されています。
- Operator Lifecycle Manager
- Operator Lifecycle Manager (OLM) は、クラスター内の Operator のインストール、アップグレード、ロールベースのアクセス制御 (RBAC) を制御します。OpenShift Container Platform 4.19 では、デフォルトでデプロイされます。
- Operator レジストリー
- Operator レジストリーは、クラスターで作成するためのクラスターサービスバージョン (Cluster Service Version、CSV) およびカスタムリソース定義 (CRD) を保存し、パッケージおよびチャネルに関する Operator メタデータを保存します。これは Kubernetes または OpenShift クラスターで実行され、この Operator カタログデータを OLM に指定します。
- OperatorHub
- OperatorHub は、クラスター管理者がクラスター上にインストールする Operator を検出し、選択するための Web コンソールです。OpenShift Container Platform ではデフォルトでデプロイされます。
これらのツールは組み立て可能なツールとして設計されているため、役に立つと思われるツールを使用できます。
2.1.3. Operator 成熟度モデル リンクのコピーリンクがクリップボードにコピーされました!
Operator 内にカプセル化されている管理ロジックの複雑さのレベルはさまざまです。また、このロジックは通常 Operator によって表されるサービスのタイプによって大きく変わります。
ただし、大半の Operator に含まれる特定の機能セットは、Operator のカプセル化された操作の成熟度の規模を一般化することができます。このため、以下の Operator 成熟度モデルは、Operator の一般的な Day 2 オペレーションに関する 5 つのフェーズの成熟度を定義しています。
図2.1 Operator 成熟度モデル
2.2. Operator Framework パッケージ形式 リンクのコピーリンクがクリップボードにコピーされました!
以下で、OpenShift Container Platform の Operator Lifecycle Manager (OLM) によってサポートされる Operator のパッケージ形式を説明します。
2.2.1. Bundle Format リンクのコピーリンクがクリップボードにコピーされました!
Operator の Bundle Format は、Operator Framework によって導入されるパッケージ形式です。スケーラビリティーを向上させ、アップストリームユーザーがより効果的に独自のカタログをホストできるようにするために、Bundle Format 仕様は Operator メタデータのディストリビューションを単純化します。
Operator バンドルは、Operator の単一バージョンを表します。ディスク上の バンドルマニフェスト は、Kubernetes マニフェストおよび Operator メタデータを保存する実行不可能なコンテナーイメージである バンドルイメージ としてコンテナー化され、提供されます。次に、バンドルイメージの保存および配布は、podman
、docker
、および Quay などのコンテナーレジストリーを使用して管理されます。
Operator メタデータには以下を含めることができます。
- Operator を識別する情報 (名前およびバージョンなど)。
- UI を駆動する追加情報 (アイコンや一部のカスタムリソース (CR) など)。
- 必須および提供される API。
- 関連するイメージ。
マニフェストを Operator レジストリーデータベースに読み込む際に、以下の要件が検証されます。
- バンドルには、アノテーションで定義された 1 つ以上のチャネルが含まれる必要がある。
- すべてのバンドルには、1 つのクラスターサービスバージョン (CSV) がある。
- CSV がクラスターリソース定義 (CRD) を所有する場合、その CRD はバンドルに存在する必要がある。
2.2.1.1. マニフェスト リンクのコピーリンクがクリップボードにコピーされました!
バンドルマニフェストは、Operator のデプロイメントおよび RBAC モデルを定義する Kubernetes マニフェストのセットを指します。
バンドルには、ディレクトリーごとに 1 つの CSV が含まれています。通常、その /manifests
ディレクトリーには、CSV が所有する API を定義する CRD が格納されています。
Bundle Format のレイアウトの例
2.2.1.1.1. その他のサポート対象のオブジェクト リンクのコピーリンクがクリップボードにコピーされました!
以下のオブジェクトタイプは、バンドルの /manifests
ディレクトリーにオプションとして追加することもできます。
サポート対象のオプションオブジェクトタイプ
-
ClusterRole
-
ClusterRoleBinding
-
ConfigMap
-
ConsoleCLIDownload
-
ConsoleLink
-
ConsoleQuickStart
-
ConsoleYamlSample
-
PodDisruptionBudget
-
PriorityClass
-
PrometheusRule
-
Role
-
RoleBinding
-
Secret
-
Service
-
ServiceAccount
-
ServiceMonitor
-
VerticalPodAutoscaler
これらのオプションオブジェクトがバンドルに含まれる場合、Operator Lifecycle Manager (OLM) はバンドルからこれらを作成し、CSV と共にそれらのライフサイクルを管理できます。
オプションオブジェクトのライフサイクル
- CSV が削除されると、OLM はオプションオブジェクトを削除します。
CSV がアップグレードされると、以下を実行します。
- オプションオブジェクトの名前が同じである場合、OLM はこれを更新します。
- オプションオブジェクトの名前がバージョン間で変更された場合、OLM はこれを削除し、再作成します。
2.2.1.2. アノテーション リンクのコピーリンクがクリップボードにコピーされました!
バンドルには、/metadata
ディレクトリーに annotations.yaml
ファイルも含まれています。このファイルは、バンドルをバンドルのインデックスに追加する方法に関する形式およびパッケージ情報の記述に役立つ高レベルの集計データを定義します。
annotations.yaml
の例
- 1
- Operator バンドルのメディアタイプまたは形式。
registry+v1
形式の場合、これに CSV および関連付けられた Kubernetes オブジェクトが含まれることを意味します。 - 2
- Operator マニフェストが含まれるディレクトリーへのイメージのパス。このラベルは今後使用するために予約され、現時点ではデフォの
manifests/
に設定されています。manifests.v1
の値は、バンドルに Operator マニフェストが含まれることを示します。 - 3
- バンドルに関するメタデータファイルが含まれるディレクトリーへのイメージのパス。このラベルは今後使用するために予約され、現時点ではデフォの
metadata/
に設定されています。metadata.v1
の値は、このバンドルに Operator メタデータがあることを意味します。 - 4
- バンドルのパッケージ名。
- 5
- Operator レジストリーに追加される際にバンドルがサブスクライブするチャネルのリスト。
- 6
- レジストリーからインストールされる場合に Operator がサブスクライブされるデフォルトチャネル。
一致しない場合、annotations.yaml
ファイルは、これらのアノテーションに依存するクラスター上の Operator レジストリーのみがこのファイルにアクセスできるために権威を持つファイルになります。
2.2.1.3. Dependencies リンクのコピーリンクがクリップボードにコピーされました!
Operator の依存関係は、バンドルの metadata/
フォルダー内の dependencies.yaml
ファイルに一覧表示されます。このファイルはオプションであり、現時点では明示的な Operator バージョンの依存関係を指定するためにのみ使用されます。
依存関係の一覧には、依存関係の内容を指定するために各項目の type
フィールドが含まれます。次のタイプの Operator 依存関係がサポートされています。
olm.package
-
このタイプは、特定の Operator バージョンの依存関係であることを意味します。依存関係情報には、パッケージ名とパッケージのバージョンを semver 形式で含める必要があります。たとえば、
0.5.2
などの特定バージョンや>0.5.1
などのバージョンの範囲を指定することができます。 olm.gvk
- このタイプの場合、作成者は CSV の既存の CRD および API ベースの使用方法と同様に group/version/kind (GVK) 情報で依存関係を指定できます。これは、Operator の作成者がすべての依存関係、API または明示的なバージョンを同じ場所に配置できるようにするパスです。
olm.constraint
- このタイプは、任意の Operator プロパティーに対するジェネリック制約を宣言します。
以下の例では、依存関係は Prometheus Operator および etcd CRD に指定されます。
dependencies.yaml
ファイルの例
2.2.1.4. opm CLI について リンクのコピーリンクがクリップボードにコピーされました!
opm
CLI ツールは、Operator Bundle Format で使用するために Operator Framework によって提供されます。このツールを使用して、ソフトウェアリポジトリーに相当する Operator バンドルのリストから Operator のカタログを作成し、維持することができます。結果として、コンテナーイメージをコンテナーレジストリーに保存し、その後にクラスターにインストールできます。
カタログには、コンテナーイメージの実行時に提供される組み込まれた API を使用してクエリーできる、Operator マニフェストコンテンツへのポインターのデータベースが含まれます。OpenShift Container Platform では、Operator Lifecycle Manager (OLM) は、CatalogSource
オブジェクトが定義したカタログソース内のイメージ参照できます。これにより、クラスター上にインストールされた Operator への頻度の高い更新を可能にするためにイメージを一定の間隔でポーリングできます。
-
opm
CLI のインストール手順は、CLI ツール を参照してください。
2.2.2. 主な特徴 リンクのコピーリンクがクリップボードにコピーされました!
ファイルベースのカタログ は、Operator Lifecycle Manager (OLM) の最新バージョンのカタログ形式です。この形式は、プレーンテキストベース (JSON または YAML) であり、以前の SQLite データベース形式の宣言的な設定の進化であり、完全な下位互換性があります。この形式の目標は、Operator のカタログ編集、設定可能性、および拡張性を有効にすることです。
- 編集
ファイルベースのカタログを使用すると、カタログの内容を操作するユーザーは、形式を直接変更し、変更が有効であることを確認できます。この形式はプレーンテキストの JSON または YAML であるため、カタログメンテナーは、一般的に知られている、サポート対象の JSON または YAML ツール (例:
jq
CLI) を使用して、手動でカタログメタデータを簡単に操作できます。この編集機能により、以下の機能とユーザー定義の拡張が有効になります。
- 既存のバンドルの新規チャネルへのプロモート
- パッケージのデフォルトチャネルの変更
- アップグレードパスを追加、更新、および削除するためのカスタムアルゴリズム
- コンポーザービリティー
ファイルベースのカタログは、任意のディレクトリー階層に保管され、カタログの作成が可能になります。たとえば、2 つのファイルベースのカタログディレクトリー (
catalogA
およびcatalogB
) を見てみましょう。カタログメンテナーは、新規のディレクトリーcatalogC
を作成してcatalogA
とcatalogB
をそのディレクトリーにコピーし、新しく結合カタログを作成できます。このコンポーザービリティーにより、カタログの分散化が可能になります。この形式により、Operator の作成者は Operator 固有のカタログを維持でき、メンテナーは個別の Operator カタログで構成されるカタログを簡単にビルドできます。ファイルベースのカタログは、他の複数のカタログを組み合わせたり、1 つのカタログのサブセットを抽出したり、またはこれらの両方を組み合わせたりすることで作成できます。
注記パッケージ内でパッケージおよびバンドルを重複できません。
opm validate
コマンドは、重複が見つかった場合はエラーを返します。Operator の作成者は Operator、その依存関係およびそのアップグレードの互換性を最も理解しているので、Operator 固有のカタログを独自のカタログに維持し、そのコンテンツを直接制御できます。ファイルベースのカタログの場合に、Operator の作成者はカタログでパッケージをビルドして維持するタスクを所有します。ただし、複合カタログメンテナーは、カタログ内のパッケージのキュレートおよびユーザーにカタログを公開するタスクのみを所有します。
- 拡張性
ファイルベースのカタログ仕様は、カタログの低レベル表現です。これは低レベルの形式で直接保守できますが、カタログメンテナーは、このレベルの上に任意の拡張をビルドして、独自のカスタムツールを使用して任意数の変更を加えることができます。
たとえば、
(mode=semver)
などの高レベルの API を、アップグレードパス用に低レベルのファイルベースのカタログ形式にツールで変換できます。または、カタログメンテナーは、特定の条件を満たすバンドルに新規プロパティーを追加して、すべてのバンドルメタデータをカスタマイズする必要がある場合があります。このような拡張性を使用すると、今後の OpenShift Container Platform リリース向けに、追加の正式なツールを下層の API 上で開発できますが、主な利点として、カタログメンテナーにもこの機能がある点が挙げられます。
OpenShift Container Platform 4.11 の時点で、デフォルトの Red Hat が提供する Operator カタログは、ファイルベースのカタログ形式でリリースされます。OpenShift Container Platform 4.6 から 4.10 までのデフォルトの Red Hat が提供する Operator カタログは、非推奨の SQLite データベース形式でリリースされました。
opm
サブコマンド、フラグ、および SQLite データベース形式に関連する機能も非推奨となり、今後のリリースで削除されます。機能は引き続きサポートされており、非推奨の SQLite データベース形式を使用するカタログに使用する必要があります。
opm index prune
などの SQLite データベース形式を使用する opm
サブコマンドおよびフラグの多くは、ファイルベースのカタログ形式では機能しません。ファイルベースのカタログを使用する方法の詳細は、カスタムカタログの管理 と oc-mirror プラグインを使用した非接続インストールのイメージのミラーリング を参照してください。
2.2.2.1. ディレクトリー構造 リンクのコピーリンクがクリップボードにコピーされました!
ファイルベースのカタログは、ディレクトリーベースのファイルシステムから保存してロードできます。opm
CLI は、root ディレクトリーを元に、サブディレクトリーに再帰してカタログを読み込みます。CLI は、検出されるすべてのファイルの読み込みを試行し、エラーが発生した場合には失敗します。
.gitignore
ファイルとパターンと優先順位が同じ .indexignore
ファイルを使用して、カタログ以外のファイルを無視できます。
例: .indexignore
ファイル
カタログメンテナーは、必要なレイアウトを柔軟に選択できますが、各パッケージのファイルベースのカタログ Blob は別々のサブディレクトリーに保管することを推奨します。個々のファイルは JSON または YAML のいずれかをしようしてください。カタログ内のすべてのファイルが同じ形式を使用する必要はありません。
推奨される基本構造
この推奨の構造には、ディレクトリー階層内の各サブディレクトリーは自己完結型のカタログであるという特性があるため、カタログの作成、検出、およびナビゲーションなどのファイルシステムの操作が簡素化されます。このカタログは、親カタログのルートディレクトリーにコピーして親カタログに追加することもできます。
2.2.2.2. スキーマ リンクのコピーリンクがクリップボードにコピーされました!
ファイルベースのカタログは、任意のスキーマで拡張できる 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 定義スキーマ用に予約されています。カスタムスキーマには、所有しているドメインなど、一意の接頭辞を使用する必要があります。
2.2.2.2.1. olm.package スキーマ リンクのコピーリンクがクリップボードにコピーされました!
olm.package
スキーマは Operator のパッケージレベルのメタデータを定義します。これには、名前、説明、デフォルトのチャネル、およびアイコンが含まれます。
例2.1 olm.package
スキーマ
2.2.2.2.2. olm.channel スキーマ リンクのコピーリンクがクリップボードにコピーされました!
olm.channel
スキーマは、パッケージ内のチャネル、チャネルのメンバーであるバンドルエントリー、およびそのバンドルのアップグレードパスを定義します。
バンドルエントリーが複数の olm.channel
Blob 内のエッジを表す場合、バンドルエントリーはチャネルごとに 1 つだけ指定できます。
エントリーの replaces
値が、このカタログにも別のカタログにも存在しない別のバンドル名を参照していても、有効とされます。ただし、他のすべてのチャネルの普遍条件に該当する必要があります (チャネルに複数のヘッドがない場合など)。
例2.2 olm.channel
スキーマ
skipRange
フィールドを使用すると、スキップされた Operator バージョンが更新グラフからプルーニングされ、ユーザーが Subscription
オブジェクトの spec.startingCSV
プロパティーを使用してそのバージョンをインストールできなくなります。
skipRange
フィールドと replaces
フィールドの両方を使用すると、以前にインストールしたバージョンをユーザーが将来インストールできるように維持しながら、Operator を段階的に更新できます。replaces
フィールドが当該 Operator バージョンの直前のバージョンを参照していることを確認してください。
2.2.2.2.3. olm.bundle スキーマ リンクのコピーリンクがクリップボードにコピーされました!
例2.3 olm.bundle
スキーマ
2.2.2.2.4. olm.deprecations スキーマ リンクのコピーリンクがクリップボードにコピーされました!
オプションの olm.deprecations
スキーマは、カタログ内のパッケージ、バンドル、チャネルの非推奨情報を定義します。Operator の作成者は、このスキーマを使用して、サポートステータスや推奨アップグレードパスなど、Operator に関する関連メッセージを、カタログから Operator を実行しているユーザーに提供できます。
このスキーマが定義されている場合、OpenShift Container Platform の Web コンソールで、OperatorHub のインストール前ページとインストール後ページの両方に、カスタムの非推奨メッセージを含め、Operator の影響を受ける要素に対する警告バッジが表示されます。
olm.deprecations
スキーマエントリーには、非推奨の範囲を示す次の reference
タイプが 1 つ以上含まれています。Operator がインストールされると、指定されたメッセージが、関連する Subscription
オブジェクトのステータス状況として表示されます。
型 | スコープ | ステータス状況 |
---|---|---|
| パッケージ全体を表します。 |
|
| 1 つのチャンネルを表します。 |
|
| 1 つのバンドルバージョンを表します。 |
|
次の例で詳しく説明するように、各 reference
タイプには独自の要件があります。
例2.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
2.2.2.3. プロパティー リンクのコピーリンクがクリップボードにコピーされました!
プロパティーは、ファイルベースのカタログスキーマに追加できる任意のメタデータです。type
フィールドは、value
フィールドのセマンティックおよび構文上の意味を効果的に指定する文字列です。値には任意の JSON または YAML を使用できます。
OLM は、予約済みの olm.*
接頭辞をもう一度使用して、いくつかのプロパティータイプを定義します。
2.2.2.3.1. olm.package プロパティー リンクのコピーリンクがクリップボードにコピーされました!
olm.package
プロパティーは、パッケージ名とバージョンを定義します。これはバンドルの必須プロパティーであり、これらのプロパティーが 1 つ必要です。packageName
フィールドはバンドルのファーストクラス package
フィールドと同じでなければならず、version
フィールドは有効なセマンティクスバージョンである必要があります。
例2.5 olm.package
プロパティー
2.2.2.3.2. olm.gvk プロパティー リンクのコピーリンクがクリップボードにコピーされました!
olm.gvk
プロパティーは、このバンドルで提供される Kubernetes API の group/version/kind(GVK) を定義します。このプロパティーは、OLM が使用して、必須の API と同じ GVK をリストする他のバンドルの依存関係として、このプロパティーでバンドルを解決します。GVK は Kubernetes GVK の検証に準拠する必要があります。
例2.6 olm.gvk
プロパティー
2.2.2.3.3. olm.package.required リンクのコピーリンクがクリップボードにコピーされました!
olm.package.required
プロパティーは、このバンドルが必要な別のパッケージのパッケージ名とバージョン範囲を定義します。バンドルにリストされている必要なパッケージプロパティーごとに、OLM は、リストされているパッケージのクラスターに必要なバージョン範囲で Operator がインストールされていることを確認します。versionRange
フィールドは有効なセマンティクスバージョン (semver) の範囲である必要があります。
例2.7 olm.package.required
プロパティー
2.2.2.3.4. olm.gvk.required リンクのコピーリンクがクリップボードにコピーされました!
olm.gvk.required
プロパティーは、このバンドルが必要とする Kubernetes API の group/version/kind(GVK) を定義します。バンドルにリストされている必要な GVK プロパティーごとに、OLM は、提供する Operator がクラスターにインストールされていることを確認します。GVK は Kubernetes GVK の検証に準拠する必要があります。
例2.8 olm.gvk.required
プロパティー
2.2.2.4. カタログの例 リンクのコピーリンクがクリップボードにコピーされました!
ファイルベースのカタログを使用すると、カタログメンテナーは 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
2.2.2.5. ガイドライン リンクのコピーリンクがクリップボードにコピーされました!
ファイルベースのカタログを維持する場合には、以下のガイドラインを考慮してください。
2.2.2.5.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
のカタログメタデータを更新できます。
2.2.2.5.2. ソース制御 リンクのコピーリンクがクリップボードにコピーされました!
カタログメタデータはソースコントロールに保存され、信頼できる情報源として処理される必要があります。以下の手順で、カタログイメージを更新する必要があります。
- ソース制御されたカタログディレクトリーを新規コミットを使用して更新します。
-
カタログイメージをビルドし、プッシュします。ユーザーがカタログが利用可能になり次第更新を受信できるように、一貫性のあるタグ付け (
:latest
or:<target_cluster_version>
) を使用します。
2.2.2.6. CLI の使用 リンクのコピーリンクがクリップボードにコピーされました!
opm
CLI を使用してファイルベースのカタログを作成する方法は、カスタムカタログの管理 を参照してください。
ファイルベースのカタログの管理に関連する opm
CLI コマンドの参考情報は、CLI ツール を参照してください。
2.2.2.7. 自動化 リンクのコピーリンクがクリップボードにコピーされました!
Operator の作成者およびカタログメンテナーは、CI/CD ワークフローを使用してカタログのメンテナンスを自動化することが推奨されます。カタログメンテナーは、GitOps 自動化をビルドして以下のタスクを実行し、これをさらに向上させることができます。
- パッケージのイメージ参照の更新など、プル要求 (PR) の作成者が要求された変更を実行できることを確認します。
-
カタログの更新で
opm validate
コマンドが指定されていることを確認します。 - 更新されたバンドルまたはカタログイメージの参照が存在し、カタログイメージがクラスターで正常に実行され、そのパッケージの Operator が正常にインストールされることを確認します。
- 以前のチェックに合格した PR を自動的にマージします。
- カタログイメージを自動的にもう一度ビルドして公開します。
2.3. 一般的な Operator Framework 用語 リンクのコピーリンクがクリップボードにコピーされました!
このトピックでは、Operator Lifecycle Manager (OLM) を含む Operator Framework に関連する一般的な用語の用語集を提供します。
2.3.1. バンドル リンクのコピーリンクがクリップボードにコピーされました!
Bundle Format では、バンドル は Operator CSV、マニフェスト、およびメタデータのコレクションです。さらに、それらはクラスターにインストールできる一意のバージョンの Operator を形成します。
2.3.2. バンドルイメージ リンクのコピーリンクがクリップボードにコピーされました!
Bundle Format では、バンドルイメージ は Operator マニフェストからビルドされ、1 つのバンドルが含まれるコンテナーイメージです。バンドルイメージは、Quay.io または DockerHub などの Open Container Initiative (OCI) 仕様コンテナーレジストリーによって保存され、配布されます。
2.3.3. カタログソース リンクのコピーリンクがクリップボードにコピーされました!
カタログソース は、OLM が Operator およびそれらの依存関係を検出し、インストールするためにクエリーできるメタデータのストアを表します。
2.3.4. チャネル リンクのコピーリンクがクリップボードにコピーされました!
チャネル は Operator の更新ストリームを定義し、サブスクライバーの更新をロールアウトするために使用されます。ヘッドはそのチャネルの最新バージョンを参照します。たとえば stable
チャネルには、Operator のすべての安定したバージョンが最も古いものから最新のものへと編成されます。
Operator には複数のチャネルを含めることができ、特定のチャネルへのサブスクリプションのバインドはそのチャネル内の更新のみを検索します。
2.3.5. チャネルヘッド リンクのコピーリンクがクリップボードにコピーされました!
チャネルヘッド は、特定のチャネル内の最新の既知の更新を指します。
2.3.6. クラスターサービスバージョン リンクのコピーリンクがクリップボードにコピーされました!
クラスターサービスバージョン (CSV) は、クラスターでの Operator の実行に使用される Operator メタデータから作成される YAML マニフェストです。これは、ユーザーインターフェイスにロゴ、説明、およびバージョンなどの情報を設定するために使用される Operator コンテナーイメージに伴うメタデータです。
CSV は、Operator が必要とする RBAC ルールやそれが管理したり、依存したりするカスタムリソース (CR) などの Operator の実行に必要な技術情報の情報源でもあります。
2.3.7. 依存関係 リンクのコピーリンクがクリップボードにコピーされました!
Operator はクラスターに存在する別の Operator への 依存関係 を持つ場合があります。たとえば、Vault Operator にはそのデータ永続層に etcd Operator への依存関係があります。
OLM は、インストールフェーズで指定されたすべてのバージョンの Operator および CRD がクラスターにインストールされていることを確認して依存関係を解決します。この依存関係は、必要な CRD API を満たすカタログの Operator を検索し、インストールすることで解決され、パッケージまたはバンドルには関連しません。
2.3.8. 拡張機能 リンクのコピーリンクがクリップボードにコピーされました!
拡張機能により、クラスター管理者は OpenShift Container Platform クラスター上のユーザーの機能を拡張できます。拡張機能は Operator Lifecycle Manager (OLM) v1 によって管理されます。
ClusterExtension
API は、ユーザー向け API を単一のオブジェクトに統合することで、registry+v1
バンドル形式を使用した Operator を含むインストール済み拡張機能の管理を効率化します。管理者と SRE は、この API を使用してプロセスを自動化し、GitOps の原則に基づき望ましい状態を定義できます。
2.3.9. インデックスイメージ リンクのコピーリンクがクリップボードにコピーされました!
Bundle Format で、インデックスイメージ は、すべてのバージョンの CSV および CRD を含む Operator バンドルに関する情報が含まれるデータベースのイメージ (データベーススナップショット) を指します。このインデックスは、クラスターで Operator の履歴をホストでき、opm
CLI ツールを使用して Operator を追加または削除することで維持されます。
2.3.10. インストール計画 リンクのコピーリンクがクリップボードにコピーされました!
インストール計画 は、CSV を自動的にインストールするか、アップグレードするために作成されるリソースの計算された一覧です。
2.3.11. マルチテナントへの対応 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform の テナント は、通常は namespace またはプロジェクトによって表される、一連のデプロイされたワークロードに対する共通のアクセスと権限を共有するユーザーまたはユーザーのグループです。テナントを使用して、異なるグループまたはチーム間に一定レベルの分離を提供できます。
クラスターが複数のユーザーまたはグループによって共有されている場合、マルチテナント クラスターと見なされます。
2.3.12. Operator リンクのコピーリンクがクリップボードにコピーされました!
Operator は、Kubernetes アプリケーションをパッケージ化し、デプロイし、管理する方法です。Kubernetes アプリケーションは、Kubernetes にデプロイされ、Kubernetes API および kubectl
または oc
ツールを使用して管理されるアプリケーションです。
Operator Lifecycle Manager (OLM) v1 では、ClusterExtension
API により、registry+v1
バンドル形式を使用した Operator を含むインストール済み拡張機能の管理が効率化されます。
2.3.13. Operator グループ リンクのコピーリンクがクリップボードにコピーされました!
Operator グループ は、OperatorGroup
オブジェクトと同じ namespace にデプロイされたすべての Operator を、namespace のリストまたはクラスター全体でそれらの CR を監視できるように設定します。
2.3.14. Package リンクのコピーリンクがクリップボードにコピーされました!
Bundle Format で、パッケージ は Operator のリリースされたすべての履歴をそれぞれのバージョンで囲むディレクトリーです。Operator のリリースされたバージョンは、CRD と共に CSV マニフェストに記述されます。
2.3.15. レジストリー リンクのコピーリンクがクリップボードにコピーされました!
レジストリー は、Operator のバンドルイメージを保存するデータベースで、それぞれにすべてのチャネルの最新バージョンおよび過去のバージョンすべてが含まれます。
2.3.16. サブスクリプション リンクのコピーリンクがクリップボードにコピーされました!
サブスクリプション は、パッケージのチャネルを追跡して CSV を最新の状態に保ちます。
2.3.17. 更新グラフ リンクのコピーリンクがクリップボードにコピーされました!
更新グラフ は、他のパッケージ化されたソフトウェアの更新グラフと同様に、CSV の複数のバージョンを 1 つにまとめます。Operator を順番にインストールすることも、特定のバージョンを省略することもできます。更新グラフは、新しいバージョンが追加されている状態でヘッドでのみ拡張することが予想されます。
更新エッジ または 更新パス とも呼ばれます。
2.4. Operator Lifecycle Manager (OLM) リンクのコピーリンクがクリップボードにコピーされました!
2.4.1. Operator Lifecycle Manager の概念およびリソース リンクのコピーリンクがクリップボードにコピーされました!
以下で、OpenShift Container Platform での Operator Lifecycle Manager (OLM) に関連する概念を説明します。
2.4.1.1. Operator Lifecycle Manager (OLM) Classic とは リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) Classic は、ユーザーが OpenShift Container Platform クラスター全体で実行される Kubernetes ネイティブアプリケーション (Operator) と関連サービスをインストール、更新、およびそれらのライフサイクルを管理するのに役立ちます。これは、Operator を効果的かつ自動化された拡張可能な方法で管理するために設計されたオープンソースツールキットの Operator Framework の一部です。
図2.2 OLM (Classic) ワークフロー
OLM は OpenShift Container Platform 4.19 でデフォルトで実行されます。これは、クラスター管理者がクラスターで実行される Operator のインストール、アップグレード、およびアクセス権の付与を行うのに役立ちます。OpenShift Container Platform Web コンソールでは、クラスター管理者が Operator をインストールし、特定のプロジェクトアクセスを付与して、クラスターで利用可能な Operator のカタログを使用するための管理画面を利用できます。
開発者の場合は、セルフサービスを使用することで、専門的な知識がなくてもデータベースのインスタンスのプロビジョニングや設定、またモニタリング、ビッグデータサービスなどを実行できます。Operator にそれらに関するナレッジが織り込まれているためです。
2.4.1.2. OLM リソース リンクのコピーリンクがクリップボードにコピーされました!
以下のカスタムリソース定義 (CRD) は Operator Lifecycle Manager (OLM) によって定義され、管理されます。
リソース | 短縮名 | 説明 |
---|---|---|
|
| アプリケーションメタデータ:例: 名前、バージョン、アイコン、必須リソース。 |
|
| CSV、CRD、およびアプリケーションを定義するパッケージのリポジトリー。 |
|
| パッケージのチャネルを追跡して CSV を最新の状態に保ちます。 |
|
| CSV を自動的にインストールするか、アップグレードするために作成されるリソースの計算された一覧。 |
|
|
|
| - |
OLM とそれが管理する Operator との間で通信チャネルを作成します。Operator は |
2.4.1.2.1. クラスターサービスバージョン リンクのコピーリンクがクリップボードにコピーされました!
クラスターサービスバージョン (CSV) は、OpenShift Container Platform クラスターで実行されている Operator の特定のバージョンを表します。これは、クラスターでの Operator Lifecycle Manager (OLM) の Operator の実行に使用される Operator メタデータから作成される YAML マニフェストです。
OLM は Operator に関するこのメタデータを要求し、これがクラスターで安全に実行できるようにし、Operator の新規バージョンが公開される際に更新を適用する方法に関する情報を提供します。これは従来のオペレーティングシステムのソフトウェアのパッケージに似ています。OLM のパッケージ手順を、rpm
、deb
、または apk
バンドルを作成するステージとして捉えることができます。
CSV には、ユーザーインターフェイスに名前、バージョン、説明、ラベル、リポジトリーリンクおよびロゴなどの情報を設定するために使用される Operator コンテナーイメージに伴うメタデータが含まれます。
CSV は、Operator が管理したり、依存したりするカスタムリソース (CR)、RBAC ルール、クラスター要件、およびインストールストラテジーなどの Operator の実行に必要な技術情報の情報源でもあります。この情報は OLM に対して必要なリソースの作成方法と、Operator をデプロイメントとしてセットアップする方法を指示します。
2.4.1.2.2. カタログソース リンクのコピーリンクがクリップボードにコピーされました!
カタログソース は、通常コンテナーレジストリーに保存されている インデックスイメージ を参照してメタデータのストアを表します。Operator Lifecycle Manager(OLM) はカタログソースをクエリーし、Operator およびそれらの依存関係を検出してインストールします。OpenShift Container Platform Web コンソールの OperatorHub は、カタログソースで提供される Operator も表示します。
クラスター管理者は、Web コンソールの Administration → Cluster Settings → Configuration → OperatorHub ページを使用して、クラスターで有効なログソースにより提供される Operator の詳細一覧を表示できます。
CatalogSource
オブジェクトの spec
は、Pod の構築方法、または Operator レジストリー gRPC API を提供するサービスとの通信方法を示します。
例2.9 CatalogSource
オブジェクトの例
- 1
CatalogSource
オブジェクトの名前。この値は、要求された namespace で作成される、関連の Pod 名の一部としても使用されます。- 2
- カタログを作成する namespace。カタログを全 namespace のクラスター全体で利用可能にするには、この値を
openshift-marketplace
に設定します。Red Hat が提供するデフォルトのカタログソースもopenshift-marketplace
namespace を使用します。それ以外の場合は、値を特定の namespace に設定し、Operator をその namespace でのみ利用可能にします。 - 3
- 任意: クラスターのアップグレードにより、Operator のインストールがサポートされていない状態になったり、更新パスが継続されなかったりする可能性を回避するために、クラスターのアップグレードの一環として、Operator カタログのインデックスイメージのバージョンを自動的に変更するように有効化することができます。
olm.catalogImageTemplate
アノテーションをインデックスイメージ名に設定し、イメージタグのテンプレートを作成する際に、1 つ以上の Kubernetes クラスターバージョン変数を使用します。アノテーションは、実行時にspec.image
フィールドを上書きします。詳細は、「カスタムカタログソースのイメージテンプレート」のセクションを参照してください。 - 4
- Web コンソールおよび CLI でのカタログの表示名。
- 5
- カタログのインデックスイメージ。オプションで、
olm.catalogImageTemplate
アノテーションを使用して実行時のプル仕様を設定する場合には、省略できます。 - 6
- カタログソースの重み。OLM は重みを使用して依存関係の解決時に優先順位付けします。重みが大きい場合は、カタログが重みの小さいカタログよりも優先されることを示します。
- 7
- ソースタイプには以下が含まれます。
-
image
参照のあるgrpc
: OLM はイメージをポーリングし、Pod を実行します。これにより、準拠 API が提供されることが予想されます。 -
address
フィールドのあるgrpc
: OLM は所定アドレスでの gRPC API へのアクセスを試行します。これはほとんどの場合使用することができません。 -
configmap
: OLM は設定マップデータを解析し、gRPC API を提供できる Pod を実行します。
-
- 8
legacy
またはrestricted
の値を指定します。フィールドが設定されていない場合、デフォルト値はlegacy
です。今後の OpenShift Container Platform リリースでは、デフォルト値がrestricted
になる予定です。restricted
権限でカタログを実行できない場合は、このフィールドを手動でlegacy
に設定することを推奨します。- 9
- オプション:
grpc
タイプのカタログソースの場合は、spec.image
でコンテンツを提供する Pod のデフォルトのノードセレクターをオーバーライドします (定義されている場合)。 - 10
- オプション:
grpc
タイプのカタログソースの場合は、spec.image
でコンテンツを提供する Pod のデフォルトの優先度クラス名をオーバーライドします (定義されている場合)。Kubernetes は、デフォルトで優先度クラスsystem-cluster-critical
およびsystem-node-critical
を提供します。フィールドを空 (""
) に設定すると、Pod にデフォルトの優先度が割り当てられます。他の優先度クラスは、手動で定義できます。 - 11
- オプション:
grpc
タイプのカタログソースの場合は、spec.image
でコンテンツを提供する Pod のデフォルトの Toleration をオーバーライドします (定義されている場合)。 - 12
- 最新の状態を維持するために、特定の間隔で新しいバージョンの有無を自動的にチェックします。
- 13
- カタログ接続が最後に監視された状態。以下に例を示します。
-
READY
: 接続が正常に確立されました。 -
CONNECTING
: 接続が確立中です。 -
TRANSIENT_FAILURE
: タイムアウトなど、接続の確立時一時的な問題が発生しました。状態は最終的にCONNECTING
に戻り、再試行されます。
詳細は、gRPC ドキュメントの 接続の状態 を参照してください。
-
- 14
- カタログイメージを保存するコンテナーレジストリーがポーリングされ、イメージが最新の状態であることを確認します。
- 15
- カタログの Operator レジストリーサービスのステータス情報。
サブスクリプションの CatalogSource
オブジェクトの name
を参照すると、要求された Operator を検索する場所を、OLM に指示します。
例2.10 カタログソースを参照する Subscription
オブジェクトの例
2.4.1.2.2.1. カスタムカタログソースのイメージテンプレート リンクのコピーリンクがクリップボードにコピーされました!
基礎となるクラスターとの Operator との互換性は、さまざまな方法でカタログソースにより表現できます。1 つの方法は、OpenShift Container Platform 4.19 など、特定のプラットフォームリリース用に特別に作成したインデックスイメージのイメージタグを指定することです。この方法は、デフォルトの Red Hat 提供のカタログソースに使用されています。
クラスターのアップグレード時に、Red Hat が提供するデフォルトのカタログソースのインデックスイメージのタグは、Operator Lifecycle Manager (OLM) が最新版のカタログをプルするように、Cluster Version Operator (CVO) により自動更新されます。たとえば、OpenShift Container Platform 4.18 から 4.19 へのアップグレード時に、redhat-operators
カタログの CatalogSource
オブジェクトの spec.image
フィールドは以下のようになります。
registry.redhat.io/redhat/redhat-operator-index:v4.19
registry.redhat.io/redhat/redhat-operator-index:v4.19
更新後は次のようになります。
registry.redhat.io/redhat/redhat-operator-index:v4.19
registry.redhat.io/redhat/redhat-operator-index:v4.19
ただし、CVO ではカスタムカタログのイメージタグは自動更新されません。クラスターのアップグレード後、ユーザーが互換性があり、サポート対象の Operator のインストールを確実に行えるようにするには、カスタムカタログも更新して、更新されたインデックスイメージを参照する必要があります。
OpenShift Container Platform 4.9 以降、クラスター管理者はカスタムカタログの CatalogSource
オブジェクトの olm.catalogImageTemplate
アノテーションを、テンプレートなどのイメージ参照に追加できます。以下の Kubernetes バージョン変数は、テンプレートで使用できるようにサポートされています。
-
kube_major_version
-
kube_minor_version
-
kube_patch_version
OpenShift Container Platform クラスターのバージョンはテンプレートに現在使用できないため、Kubernetes クラスターのバージョンを指定する必要があります。
更新された Kubernetes バージョンを指定するタグでインデックスイメージを作成してプッシュしている場合に、このアノテーションを設定すると、カスタムカタログのインデックスイメージのバージョンがクラスターのアップグレード後に自動的に変更されます。アノテーションの値は、CatalogSource
オブジェクトの spec.image
フィールドでイメージ参照を設定したり、更新したりするために使用されます。こうすることで、サポートなしの状態や、継続する更新パスなしの状態で Operator がインストールされないようにします。
格納されているレジストリーがどれであっても、クラスターのアップグレード時に、クラスターが、更新されたタグを含むインデックスイメージにアクセスできるようにする必要があります。
例2.11 イメージテンプレートを含むカタログソースの例
spec.image
フィールドおよび olm.catalogImageTemplate
アノテーションの両方が設定されている場合には、spec.image
フィールドはアノテーションから解決された値で上書きされます。アノテーションが使用可能なプル仕様に対して解決されない場合は、カタログソースは spec.image
値にフォールバックします。
spec.image
フィールドが設定されていない場合に、アノテーションが使用可能なプル仕様に対して解決されない場合は、OLM はカタログソースの調整を停止し、人間が判読できるエラー条件に設定します。
Kubernetes 1.33 を使用する OpenShift Container Platform 4.19 クラスターでは、前述の例の olm.catalogImageTemplate
アノテーションは以下のイメージ参照に解決されます。
quay.io/example-org/example-catalog:v1.32
quay.io/example-org/example-catalog:v1.32
OpenShift Container Platform の今後のリリースでは、より新しい OpenShift Container Platform バージョンが使用する、より新しい Kubernetes バージョンを対象とした、カスタムカタログの更新済みインデックスイメージを作成できます。アップグレード前に olm.catalogImageTemplate
アノテーションを設定してから、クラスターを新しい OpenShift Container Platform バージョンにアップグレードすると、カタログのインデックスイメージも自動的に更新されます。
2.4.1.2.2.2. カタログの正常性要件 リンクのコピーリンクがクリップボードにコピーされました!
クラスター上の Operator カタログは、インストール解決の観点から相互に置き換え可能です。Subscription
オブジェクトは特定のカタログを参照する場合がありますが、依存関係はクラスターのすべてのカタログを使用して解決されます。
たとえば、カタログ A が正常でない場合、カタログ A を参照するサブスクリプションはカタログ B の依存関係を解決する可能性があります。通常、B のカタログ優先度は A よりも低いため、クラスター管理者はこれおを想定していない可能性があります。
その結果、OLM では、特定のグローバル namespace (デフォルトの openshift-marketplace
namespace やカスタムグローバル namespace など) を持つすべてのカタログが正常であることが必要になります。カタログが正常でない場合、その共有グローバル namespace 内のすべての Operator のインストールまたは更新操作は、CatalogSourcesUnhealthy
状態で失敗します。正常でない状態でこれらの操作が許可されている場合、OLM はクラスター管理者が想定しない解決やインストールを決定する可能性があります。
クラスター管理者が、カタログが正常でないことを確認し、無効とみなして Operator インストールを再開する必要がある場合は、「カスタムカタログの削除」または「デフォルトの OperatorHub カタログソースの無効化」セクションで、正常でないカタログの削除を確認してください。
2.4.1.2.3. サブスクリプション リンクのコピーリンクがクリップボードにコピーされました!
サブスクリプション は、Subscription
オブジェクトによって定義され、Operator をインストールする意図を表します。これは、Operator をカタログソースに関連付けるカスタムリソースです。
サブスクリプションは、サブスクライブする Operator パッケージのチャネルや、更新を自動または手動で実行するかどうかを記述します。サブスクリプションが自動に設定された場合、Operator Lifecycle Manager (OLM) が Operator を管理し、アップグレードして、最新バージョンがクラスター内で常に実行されるようにします。
Subscription
オブジェクトの例
この Subscription
オブジェクトは、Operator の名前と namespace、および Operator データのあるカタログを定義します。alpha
、beta
、または stable
などのチャネルは、カタログソースからインストールする必要のある Operator ストリームを判別するのに役立ちます。
サブスクリプションのチャネルの名前は Operator 間で異なる可能性がありますが、命名スキームは指定された Operator 内の一般的な規則に従う必要があります。たとえば、チャネル名は Operator によって提供されるアプリケーションのマイナーリリース更新ストリーム (1.2
、1.3
) またはリリース頻度 (stable
、fast
) に基づく可能性があります。
OpenShift Container Platform Web コンソールから簡単に表示されるだけでなく、関連するサブスクリプションのステータスを確認して、Operator の新規バージョンが利用可能になるタイミングを特定できます。currentCSV
フィールドに関連付けられる値は OLM に認識される最新のバージョンであり、installedCSV
はクラスターにインストールされるバージョンです。
2.4.1.2.4. インストール計画 リンクのコピーリンクがクリップボードにコピーされました!
InstallPlan
オブジェクトによって定義される インストール計画 は、Operator Lifecycle Manager(OLM) が特定バージョンの Operator をインストールまたはアップグレードするために作成するリソースのセットを記述します。バージョンはクラスターサービスバージョン (CSV) で定義されます。
Operator、クラスター管理者、または Operator インストールパーミッションが付与されているユーザーをインストールするには、まず Subscription
オブジェクトを作成する必要があります。サブスクリプションでは、カタログソースから利用可能なバージョンの Operator のストリームにサブスクライブする意図を表します。次に、サブスクリプションは InstallPlan
オブジェクトを作成し、Operator のリソースのインストールを容易にします。
その後、インストール計画は、以下の承認ストラテジーのいずれかをもとに承認される必要があります。
-
サブスクリプションの
spec.installPlanApproval
フィールドがAutomatic
に設定されている場合には、インストール計画は自動的に承認されます。 -
サブスクリプションの
spec.installPlanApproval
フィールドがManual
に設定されている場合には、インストール計画はクラスター管理者または適切なパーミッションが割り当てられたユーザーによって手動で承認する必要があります。
インストール計画が承認されると、OLM は指定されたリソースを作成し、サブスクリプションで指定された namespace に Operator をインストールします。
例2.12 InstallPlan
オブジェクトの例
2.4.1.2.5. Operator グループ リンクのコピーリンクがクリップボードにコピーされました!
Operator グループ は、OperatorGroup
リソースによって定義され、マルチテナント設定を OLM でインストールされた Operator に提供します。Operator グループは、そのメンバー Operator に必要な RBAC アクセスを生成するために使用するターゲット namespace を選択します。
ターゲット namespace のセットは、クラスターサービスバージョン (CSV) の olm.targetNamespaces
アノテーションに保存されるコンマ区切りの文字列によって指定されます。このアノテーションは、メンバー Operator の CSV インスタンスに適用され、それらのデプロインメントに展開されます。
関連情報
2.4.1.2.6. Operator 条件 リンクのコピーリンクがクリップボードにコピーされました!
Operator のライフサイクル管理のロールの一部として、Operator Lifecycle Manager (OLM) は、Operator を定義する Kubernetes リソースの状態から Operator の状態を推測します。このアプローチでは、Operator が特定の状態にあることをある程度保証しますが、推測できない情報を Operator が OLM と通信して提供する必要がある場合も多々あります。続いて、OLM がこの情報を使用して、Operator のライフサイクルをより適切に管理することができます。
OLM は、Operator が OLM に条件を通信できる OperatorCondition
というカスタムリソース定義 (CRD) を提供します。OperatorCondition
リソースの Spec.Conditions
配列にある場合に、OLM による Operator の管理に影響するサポートされる条件のセットがあります。
デフォルトでは、Spec.Conditions
配列は、ユーザーによって追加されるか、カスタム Operator ロジックの結果として追加されるまで、OperatorCondition
オブジェクトに存在しません。
2.4.2. Operator Lifecycle Manager アーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
以下では、OpenShift Container Platform における Operator Lifecycle Manager (OLM) のコンポーネントのアーキテクチャーを説明します。
2.4.2.1. コンポーネントのロール リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) は、OLM Operator および Catalog Operator の 2 つの Operator で構成されています。
OLM Operator と Catalog Operator は、それぞれ OLM フレームワークの基礎となるカスタムリソース定義 (CRD) を管理します。
リソース | 短縮名 | 所有者 | 説明 |
---|---|---|---|
|
| OLM | アプリケーションのメタデータ: 名前、バージョン、アイコン、必須リソース、インストールなど。 |
|
| Catalog | CSV を自動的にインストールするか、アップグレードするために作成されるリソースの計算された一覧。 |
|
| Catalog | CSV、CRD、およびアプリケーションを定義するパッケージのリポジトリー。 |
|
| Catalog | パッケージのチャネルを追跡して CSV を最新の状態に保つために使用されます。 |
|
| OLM |
|
これらの Operator のそれぞれは以下のリソースの作成も行います。
リソース | 所有者 |
---|---|
| OLM |
| |
| |
| |
| Catalog |
|
2.4.2.2. OLM Operator リンクのコピーリンクがクリップボードにコピーされました!
OLM Operator は、CSV で指定された必須リソースがクラスター内にあることが確認された後に CSV リソースで定義されるアプリケーションをデプロイします。
OLM Operator は必須リソースの作成には関与せず、ユーザーが CLI またはカタログ Operator を使用してこれらのリソースを手動で作成することを選択できます。このタスクの分離により、アプリケーションに OLM フレームワークをどの程度活用するかに関連してユーザーによる追加機能の購入を可能にします。
OLM Operator は以下のワークフローを使用します。
- namespace でクラスターサービスバージョン (CSV) の有無を確認し、要件を満たしていることを確認します。
要件が満たされている場合、CSV のインストールストラテジーを実行します。
注記CSV は、インストールストラテジーの実行を可能にするために Operator グループのアクティブなメンバーである必要があります。
2.4.2.3. Catalog Operator リンクのコピーリンクがクリップボードにコピーされました!
Catalog Operator はクラスターサービスバージョン (CSV) およびそれらが指定する必須リソースを解決し、インストールします。また、カタログソースでチャネル内のパッケージへの更新の有無を確認し、必要な場合はそれらを利用可能な最新バージョンに自動的にアップグレードします。
チャネル内のパッケージを追跡するために、必要なパッケージ、チャネル、および更新のプルに使用する CatalogSource
オブジェクトを設定して Subscription
オブジェクトを作成できます。更新が見つかると、ユーザーに代わって適切な InstallPlan
オブジェクトの namespace への書き込みが行われます。
Catalog Operator は以下のワークフローを使用します。
- クラスターの各カタログソースに接続します。
ユーザーによって作成された未解決のインストール計画の有無を確認し、これがあった場合は以下を実行します。
- 要求される名前に一致する CSV を検索し、これを解決済みリソースとして追加します。
- マネージドまたは必須の CRD のそれぞれについて、これを解決済みリソースとして追加します。
- 必須 CRD のそれぞれについて、これを管理する CSV を検索します。
- 解決済みのインストール計画の有無を確認し、それに関する検出されたすべてのリソースを作成します (ユーザーによって、または自動的に承認される場合)。
- カタログソースおよびサブスクリプションの有無を確認し、それらに基づいてインストール計画を作成します。
2.4.2.4. カタログレジストリー リンクのコピーリンクがクリップボードにコピーされました!
カタログレジストリーは、クラスター内での作成用に CSV および CRD を保存し、パッケージおよびチャネルに関するメタデータを保存します。
パッケージマニフェスト は、パッケージアイデンティティーを CSV のセットに関連付けるカタログレジストリー内のエントリーです。パッケージ内で、チャネルは特定の CSV を参照します。CSV は置き換え対象の CSV を明示的に参照するため、パッケージマニフェストは Catalog Operator に対し、CSV をチャネル内の最新バージョンに更新するために必要なすべての情報を提供します (各中間バージョンをステップスルー)。
2.4.3. Operator Lifecycle Manager ワークフロー リンクのコピーリンクがクリップボードにコピーされました!
以下では、OpenShift Container Platform における Operator Lifecycle Manager (OLM) のワークロードを説明します。
2.4.3.1. OLM での Operator のインストールおよびアップグレードのワークフロー リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) エコシステムでは、以下のリソースを使用して Operator インストールおよびアップグレードを解決します。
-
ClusterServiceVersion
(CSV) -
CatalogSource
-
Subscription
CSV で定義される Operator メタデータは、カタログソースというコレクションに保存できます。OLM はカタログソースを使用します。これは Operator Registry API を使用して利用可能な Operator やインストールされた Operator のアップグレードをクエリーします。
図2.3 カタログソースの概要
カタログソース内で、Operator は パッケージ と チャネル という更新のストリームに編成されます。これは、Web ブラウザーのような継続的なリリースサイクルの OpenShift Container Platform や他のソフトウェアで使用される更新パターンです。
図2.4 カタログソースのパッケージおよびチャネル
ユーザーは サブスクリプション の特定のカタログソースの特定のパッケージおよびチャネルを指定できます (例: etcd
パッケージおよびその alpha
チャネル)。サブスクリプションが namespace にインストールされていないパッケージに対して作成されると、そのパッケージの最新 Operator がインストールされます。
OLM では、バージョンの比較が意図的に避けられます。そのため、所定の catalog → channel → package パスから利用可能な "latest" または "newest" Operator が必ずしも最も高いバージョン番号である必要はありません。これは Git リポジトリーの場合と同様に、チャネルの Head リファレンスとして見なされます。
各 CSV には、これが置き換える Operator を示唆する replaces
パラメーターがあります。これにより、OLM でクエリー可能な CSV のグラフが作成され、更新がチャネル間で共有されます。チャネルは、更新グラフのエントリーポイントと見なすことができます。
図2.5 利用可能なチャネル更新に関する OLM グラフ
パッケージのチャネルの例
カタログソース、パッケージ、チャネルおよび CSV がある状態で、OLM が更新のクエリーを実行できるようにするには、カタログが入力された CSV の置き換え (replaces
) を実行する単一 CSV を明確にかつ確定的に返すことができる必要があります。
2.4.3.1.1. アップグレードパスの例 リンクのコピーリンクがクリップボードにコピーされました!
アップグレードシナリオのサンプルについて、CSV バージョン 0.1.1
に対応するインストールされた Operator を見てみましょう。OLM はカタログソースをクエリーし、新規 CSV バージョン 0.1.3
について、サブスクライブされたチャネルのアップグレードを検出します。これは、古いバージョンでインストールされていない CSV バージョン 0.1.2
を置き換えます。その後、さらに古いインストールされた CSV バージョン 0.1.1
を置き換えます。
OLM は、チャネルヘッドから CSV で指定された replaces
フィールドで以前のバージョンに戻り、アップグレードパス 0.1.3
→ 0.1.2
→ 0.1.1
を判別します。矢印の方向は前者が後者を置き換えることを示します。OLM は、チャネルヘッドに到達するまで Operator を 1 バージョンずつアップグレードします。
このシナリオでは、OLM は Operator バージョン 0.1.2
をインストールし、既存の Operator バージョン 0.1.1
を置き換えます。その後、Operator バージョン 0.1.3
をインストールし、直前にインストールされた Operator バージョン 0.1.2
を置き換えます。この時点で、インストールされた Operator のバージョン 0.1.3
はチャネルヘッドに一致し、アップグレードは完了します。
2.4.3.1.2. アップグレードの省略 リンクのコピーリンクがクリップボードにコピーされました!
OLM のアップグレードの基本パスは以下の通りです。
- カタログソースは Operator への 1 つ以上の更新によって更新されます。
- OLM は、カタログソースに含まれる最新バージョンに到達するまで、Operator のすべてのバージョンを横断します。
ただし、この操作の実行は安全でない場合があります。公開されているバージョンの Operator がクラスターにインストールされていない場合、そのバージョンによって深刻な脆弱性が導入される可能性があるなどの理由で、その Operator をクラスターにインストールできないことがあります。
この場合、OLM は以下の 2 つのクラスターの状態を考慮に入れて、それらの両方に対応する更新グラフを提供する必要があります。
- "問題のある" 中間 Operator がクラスターによって確認され、かつインストールされている。
- "問題のある" 中間 Operator がクラスターにまだインストールされていない。
OLM は、新規カタログを送り、省略された リリースを追加することで、クラスターの状態や問題のある更新が発見されたかどうかにかかわらず、単一の固有の更新を常に取得することができます。
省略されたリリースの CSV 例
古い CatalogSource および 新規 CatalogSource に関する以下の例を見てみましょう。
図2.6 更新のスキップ
このグラフは、以下を示しています。
- 古い CatalogSource の Operator には、新規 CatalogSource の単一の置き換えがある。
- 新規 CatalogSource の Operator には、新規 CatalogSource の単一の置き換えがある。
- 問題のある更新がインストールされていない場合、これがインストールされることはない。
2.4.3.1.3. 複数の Operators の置き換え リンクのコピーリンクがクリップボードにコピーされました!
前述の方法で 新規 CatalogSource を作成するには、ある Operator を置き換えつつ (replace
)、複数バージョンをスキップ (skip
) できる CSV を公開する必要があります。これは、skipRange
アノテーションを使用して実行できます。
olm.skipRange: <semver_range>
olm.skipRange: <semver_range>
ここで <semver_range>
には、semver ライブラリー でサポートされるバージョン範囲の形式が使用されます。
カタログで更新を検索する場合、チャネルのヘッドに skipRange
アノテーションがあり、現在インストールされている Operator にその範囲内のバージョンフィールドがある場合、OLM はチャネル内の最新エントリーに対して更新されます。
以下は動作が実行される順序になります。
-
サブスクリプションの
sourceName
で指定されるソースのチャネルヘッド (省略する他の条件が満たされている場合)。 -
sourceName
で指定されるソースの現行バージョンを置き換える次の Operator。 - サブスクリプションに表示される別のソースのチャネルヘッド (省略する他の条件が満たされている場合)。
- サブスクリプションに表示されるソースの現行バージョンを置き換える次の Operator。
skipRange
を含む CSV の例
2.4.3.1.4. z-stream サポート リンクのコピーリンクがクリップボードにコピーされました!
z-stream またはパッチリリースは、同じマイナーバージョンの以前のすべての z-stream リリースを置き換える必要があります。OLM は、メジャー、マイナーまたはパッチバージョンを考慮せず、カタログ内で正確なグラフのみを作成する必要があります。
つまり、OLM では 古い CatalogSource のようにグラフを使用し、以前と同様に 新規 CatalogSource にあるようなグラフを生成する必要があります。
図2.7 複数 Operator の置き換え
このグラフは、以下を示しています。
- 古い CatalogSource の Operator には、新規 CatalogSource の単一の置き換えがある。
- 新規 CatalogSource の Operator には、新規 CatalogSource の単一の置き換えがある。
- 古い CatalogSource の z-stream リリースは、新規 CatalogSource の最新 z-stream リリースに更新される。
- 使用不可のリリースは "仮想" グラフノードと見なされる。それらのコンテンツは存在する必要がなく、レジストリーはグラフが示すように応答することのみが必要になります。
2.4.4. Operator Lifecycle Manager の依存関係の解決 リンクのコピーリンクがクリップボードにコピーされました!
以下で、OpenShift Container Platform の Operator Lifecycle Manager (OLM) での依存関係の解決およびカスタムリソース定義 (CRD) アップグレードライフサイクルを説明します。
2.4.4.1. 依存関係の解決 リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) は、実行中の Operator の依存関係の解決とアップグレードのライフサイクルを管理します。多くの場合、OLM が直面する問題は、yum
や rpm
などの他のシステムまたは言語パッケージマネージャーと同様です。
ただし、OLM にはあるものの、通常同様のシステムにはない 1 つの制約があります。Operator は常に実行されており、OLM は相互に機能しない Operator のセットの共存を防ごうとします。
その結果、以下のシナリオで OLM を使用しないでください。
- 提供できない API を必要とする Operator のセットのインストール
- Operator と依存関係のあるものに障害を発生させる仕方での Operator の更新
これは、次の 2 種類のデータで可能になります。
プロパティー | Operator に関する型付きのメタデータ。これは、依存関係のリゾルバーで Operator の公開インターフェイスを構成します。例としては、Operator が提供する API の group/version/kind (GVK) や Operator のセマンティックバージョン (semver) などがあります。 |
制約または依存関係 | ターゲットクラスターにすでにインストールされているかどうかに関係なく、他の Operator が満たす必要のある Operator の要件。これらは、使用可能なすべての Operator に対するクエリーまたはフィルターとして機能し、依存関係の解決およびインストール中に選択を制限します。クラスターで特定の API が利用できる状態にする必要がある場合や、特定のバージョンに特定の Operator をインストールする必要がある場合など、例として挙げられます。 |
OLM は、これらのプロパティーと制約をブール式のシステムに変換して SAT ソルバーに渡します。これは、ブールの充足可能性を確立するプログラムであり、インストールする Operator を決定する作業を行います。
2.4.4.2. Operator のプロパティー リンクのコピーリンクがクリップボードにコピーされました!
カタログ内の Operator にはすべて、次のプロパティーが含まれます。
olm.package
- パッケージの名前と Operator のバージョンを含めます。
olm.gvk
- クラスターサービスバージョン (CSV) から提供された API ごとに 1 つのプロパティー
追加のプロパティーは、Operator バンドルの metadata/
ディレクトリーに properties.yaml
ファイルを追加して、Operator 作成者が直接宣言することもできます。
任意のプロパティーの例
properties: - type: olm.kubeversion value: version: "1.16.0"
properties:
- type: olm.kubeversion
value:
version: "1.16.0"
2.4.4.2.1. 任意のプロパティー リンクのコピーリンクがクリップボードにコピーされました!
Operator の作成者は、Operator バンドルの metadata/
ディレクトリーにある properties.yaml
ファイルで任意のプロパティーを宣言できます。これらのプロパティーは、実行時に Operator Lifecycle Manager (OLM) リゾルバーへの入力として使用されるマップデータ構造に変換されます。
これらのプロパティーはリゾルバーには不透明です。リゾルバーはプロパティーを理解しませんが、これらのプロパティーに対する一般的な制約を評価して、プロパティーリストを指定することで制約を満たすことができるかどうかを判断します。
任意のプロパティーの例
この構造を使用して、ジェネリック制約の Common Expression Language (CEL) 式を作成できます。
2.4.4.3. Operator の依存関係 リンクのコピーリンクがクリップボードにコピーされました!
Operator の依存関係は、バンドルの metadata/
フォルダー内の dependencies.yaml
ファイルに一覧表示されます。このファイルはオプションであり、現時点では明示的な Operator バージョンの依存関係を指定するためにのみ使用されます。
依存関係の一覧には、依存関係の内容を指定するために各項目の type
フィールドが含まれます。次のタイプの Operator 依存関係がサポートされています。
olm.package
-
このタイプは、特定の Operator バージョンの依存関係であることを意味します。依存関係情報には、パッケージ名とパッケージのバージョンを semver 形式で含める必要があります。たとえば、
0.5.2
などの特定バージョンや>0.5.1
などのバージョンの範囲を指定することができます。 olm.gvk
- このタイプの場合、作成者は CSV の既存の CRD および API ベースの使用方法と同様に group/version/kind (GVK) 情報で依存関係を指定できます。これは、Operator の作成者がすべての依存関係、API または明示的なバージョンを同じ場所に配置できるようにするパスです。
olm.constraint
- このタイプは、任意の Operator プロパティーに対するジェネリック制約を宣言します。
以下の例では、依存関係は Prometheus Operator および etcd CRD に指定されます。
dependencies.yaml
ファイルの例
2.4.4.4. 一般的な制約 リンクのコピーリンクがクリップボードにコピーされました!
olm.constraint
プロパティーは、特定のタイプの依存関係制約を宣言し、非制約プロパティーと制約プロパティーを区別します。その value
フィールドは、制約メッセージの文字列表現を保持する failureMessage
フィールドを含むオブジェクトです。このメッセージは、実行時に制約が満たされない場合に、ユーザーへの参考のコメントとして表示されます。
次のキーは、使用可能な制約タイプを示します。
gvk
-
値と解釈が
olm.gvk
タイプと同じタイプ package
-
値と解釈が
olm.package
タイプと同じタイプ cel
- 任意のバンドルプロパティーとクラスター情報に対して Operator Lifecycle Manager (OLM) リゾルバーによって実行時に評価される Common Expression Language (CEL) 式
all
、any
、not
-
gvk
やネストされた複合制約など、1 つ以上の具体的な制約を含む、論理積、論理和、否定の制約。
2.4.4.4.1. Common Expression Language (CEL) の制約 リンクのコピーリンクがクリップボードにコピーされました!
cel
制約型は、式言語として Common Expression Language (CEL) をサポートしています。cel
構造には、Operator が制約を満たしているかどうかを判断するために、実行時に Operator プロパティーに対して評価される CEL 式文字列を含む rule
フィールドがあります。
cel
制約の例
type: olm.constraint value: failureMessage: 'require to have "certified"' cel: rule: 'properties.exists(p, p.type == "certified")'
type: olm.constraint
value:
failureMessage: 'require to have "certified"'
cel:
rule: 'properties.exists(p, p.type == "certified")'
CEL 構文は、AND
や OR
などの幅広い論理演算子をサポートします。その結果、単一の CEL 式は、これらの論理演算子で相互にリンクされる複数の条件に対して複数のルールを含めることができます。これらのルールは、バンドルまたは任意のソースからの複数の異なるプロパティーのデータセットに対して評価され、出力は、単一の制約内でこれらのルールのすべてを満たす単一のバンドルまたは Operator に対して解決されます。
複数のルールが指定された cel
制約の例
type: olm.constraint value: failureMessage: 'require to have "certified" and "stable" properties' cel: rule: 'properties.exists(p, p.type == "certified") && properties.exists(p, p.type == "stable")'
type: olm.constraint
value:
failureMessage: 'require to have "certified" and "stable" properties'
cel:
rule: 'properties.exists(p, p.type == "certified") && properties.exists(p, p.type == "stable")'
2.4.4.4.2. 複合制約 (all, any, not) リンクのコピーリンクがクリップボードにコピーされました!
複合制約タイプは、論理定義に従って評価されます。
以下は、2 つのパッケージと 1 つの GVK の接続制約 (all
) の例です。つまり、インストールされたバンドルがすべての制約を満たす必要があります。
all
制約の例
以下は、同じ GVK の 3 つのバージョンの選言的制約 (any
) の例です。つまり、インストールされたバンドルが少なくとも 1 つの制約を満たす必要があります。
any
制約の例
以下は、GVK の 1 つのバージョンの否定制約 (not
) の例です。つまり、この結果セットのバンドルでは、この GVK を提供できません。
not
の制約例
否定のセマンティクスは、not
制約のコンテキストで不明確であるように見える場合があります。つまり、この否定では、特定の GVK、あるバージョンのパッケージを含むソリューション、または結果セットからの子の複合制約を満たすソリューションを削除するように、リゾルバーに対して指示を出しています。
当然の結果として、最初に可能な依存関係のセットを選択せずに否定することは意味がないため、複合では not
制約は all
または any
制約内でのみ使用する必要があります。
2.4.4.4.3. ネストされた複合制約 リンクのコピーリンクがクリップボードにコピーされました!
ネストされた複合制約 (少なくとも 1 つの子複合制約と 0 個以上の単純な制約を含む制約) は、前述の各制約タイプの手順に従って、下から上に評価されます。
以下は、接続詞の論理和の例で、one、the other、または both が制約を満たすことができます。
ネストされた複合制約の例
olm.constraint
タイプの最大 raw サイズは 64KB に設定されており、リソース枯渇攻撃を制限しています。
2.4.4.5. 依存関係の設定 リンクのコピーリンクがクリップボードにコピーされました!
Operator の依存関係を同等に満たすオプションが多数ある場合があります。Operator Lifecycle Manager (OLM) の依存関係リゾルバーは、要求された Operator の要件に最も適したオプションを判別します。Operator の作成者またはユーザーとして、依存関係の解決が明確になるようにこれらの選択方法を理解することは重要です。
2.4.4.5.1. カタログの優先順位 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターでは、OLM がカタログソースを読み取り、どの Operator がインストール可能であるかを確認します。
CatalogSource
オブジェクトの例
- 1
legacy
またはrestricted
の値を指定します。フィールドが設定されていない場合、デフォルト値はlegacy
です。今後の OpenShift Container Platform リリースでは、デフォルト値がrestricted
になる予定です。restricted
権限でカタログを実行できない場合は、このフィールドを手動でlegacy
に設定することを推奨します。
CatalogSource
オブジェクトには priority
フィールドがあります。このフィールドは、依存関係のオプションを優先する方法を把握するためにリゾルバーによって使用されます。
カタログ設定を規定する 2 つのルールがあります。
- 優先順位の高いカタログにあるオプションは、優先順位の低いカタログのオプションよりも優先されます。
- 依存オブジェクトと同じカタログにあるオプションは他のカタログよりも優先されます。
2.4.4.5.2. チャネルの順序付け リンクのコピーリンクがクリップボードにコピーされました!
カタログ内の Operator パッケージは、OpenShift Container Platform クラスターでユーザーがサブスクライブできる更新チャネルのコレクションです。チャネルは、マイナーリリース (1.2
、1.3
) またはリリース頻度 (stable
、fast
) に関する特定の更新ストリームを提供するために使用できます。
同じパッケージの Operator によって依存関係が満たされる可能性がありますが、その場合、異なるチャネルの Operator のバージョンによって満たされる可能性があります。たとえば、Operator のバージョン 1.2
は stable
および fast
チャネルの両方に存在する可能性があります。
それぞれのパッケージにはデフォルトのチャネルがあり、これは常にデフォルト以外のチャネルよりも優先されます。デフォルトチャネルのオプションが依存関係を満たさない場合には、オプションは、チャネル名の辞書式順序 (lexicographic order) で残りのチャネルから検討されます。
2.4.4.5.3. チャネル内での順序 リンクのコピーリンクがクリップボードにコピーされました!
ほとんどの場合、単一のチャネル内に依存関係を満たすオプションが複数あります。たとえば、1 つのパッケージおよびチャネルの Operator は同じセットの API を提供します。
ユーザーがサブスクリプションを作成すると、それらはどのチャネルから更新を受け取るかを示唆します。これにより、すぐにその 1 つのチャネルだけに検索が絞られます。ただし、チャネル内では、多くの Operator が依存関係を満たす可能性があります。
チャネル内では、更新グラフでより上位にある新規 Operator が優先されます。チャネルのヘッドが依存関係を満たす場合、これがまず試行されます。
2.4.4.5.4. その他の制約 リンクのコピーリンクがクリップボードにコピーされました!
OLM には、パッケージの依存関係で指定される制約のほかに、必要なユーザーの状態を表し、常にメンテナンスする必要のある依存関係の解決を適用するための追加の制約が含まれます。
2.4.4.5.4.1. サブスクリプションの制約 リンクのコピーリンクがクリップボードにコピーされました!
サブスクリプションの制約は、サブスクリプションを満たすことのできる Operator のセットをフィルターします。サブスクリプションは、依存関係リゾルバーに関するユーザー指定の制約です。それらは、クラスター上にない場合は新規 Operator をインストールすることを宣言するか、既存 Operator の更新された状態を維持することを宣言します。
2.4.4.5.4.2. パッケージの制約 リンクのコピーリンクがクリップボードにコピーされました!
namespace 内では、2 つの Operator が同じパッケージから取得されることはありません。
2.4.4.6. CRD のアップグレード リンクのコピーリンクがクリップボードにコピーされました!
OLM は、単一のクラスターサービスバージョン (CSV) によって所有されている場合にはカスタムリソース定義 (CRD) をすぐにアップグレードします。CRD が複数の CSV によって所有されている場合、CRD は、以下の後方互換性の条件のすべてを満たす場合にアップグレードされます。
- 現行 CRD の既存の有効にされたバージョンすべてが新規 CRD に存在する。
- 検証が新規 CRD の検証スキーマに対して行われる場合、CRD の提供バージョンに関連付けられる既存インスタンスまたはカスタムリソースすべてが有効である。
2.4.4.7. 依存関係のベストプラクティス リンクのコピーリンクがクリップボードにコピーされました!
依存関係を指定する際には、ベストプラクティスを考慮する必要があります。
- Operator の API または特定のバージョン範囲によって異なります。
-
Operator は API をいつでも追加または削除できます。Operator が必要とする API に
olm.gvk
依存関係を常に指定できます。これの例外は、olm.package
制約を代わりに指定する場合です。 - 最小バージョンの設定
API の変更に関する Kubernetes ドキュメントでは、Kubernetes 形式の Operator で許可される変更を説明しています。これらのバージョン管理規則により、Operator は API バージョンに後方互換性がある限り、API バージョンに影響を与えずに API を更新することができます。
Operator の依存関係の場合、依存関係の API バージョンを把握するだけでは、依存する Operator が確実に意図された通りに機能することを確認できないことを意味します。
以下に例を示します。
-
TestOperator v1.0.0 は、v1alpha1 API バージョンの
MyObject
リソースを提供します。 -
TestOperator v1.0.1 は新しいフィールド
spec.newfield
をMyObject
に追加しますが、v1alpha1 のままになります。
Operator では、
spec.newfield
をMyObject
リソースに書き込む機能が必要になる場合があります。olm.gvk
制約のみでは、OLM で TestOperator v1.0.0 ではなく TestOperator v1.0.1 が必要であると判断することはできません。可能な場合には、API を提供する特定の Operator が事前に分かっている場合、最小値を設定するために追加の
olm.package
制約を指定します。-
TestOperator v1.0.0 は、v1alpha1 API バージョンの
- 最大バージョンを省略するか、幅広いバージョンを許可します。
Operator は API サービスや CRD などのクラスタースコープのリソースを提供するため、依存関係に小規模な範囲を指定する Operator は、その依存関係の他のコンシューマーの更新に不要な制約を加える可能性があります。
可能な場合は、最大バージョンを設定しないでください。または、他の Operator との競合を防ぐために、幅広いセマンティクスの範囲を設定します。例:
>1.0.0 <2.0.0
従来のパッケージマネージャーとは異なり、Operator の作成者は更新が OLM のチャネルで更新を安全に行われるように Operator を明示的にエンコードします。更新が既存のサブスクリプションで利用可能な場合、Operator の作成者がこれが以前のバージョンから更新できることを示唆していることが想定されます。依存関係の最大バージョンを設定すると、特定の上限で不必要な切り捨てが行われることにより、作成者の更新ストリームが上書きされます。
注記クラスター管理者は、Operator の作成者が設定した依存関係を上書きすることはできません。
ただし、回避する必要がある非互換性があることが分かっている場合は、最大バージョンを設定でき、およびこれを設定する必要があります。バージョン範囲の構文を使用すると、複数の特定のバージョンを省略できます (例:
> 1.0.0 !1.2.1
)。
2.4.4.8. 依存関係に関する注意事項 リンクのコピーリンクがクリップボードにコピーされました!
依存関係を指定する際には、考慮すべき注意事項があります。
- 複合制約がない (AND)
現時点で、制約の間に AND 関係を指定する方法はありません。つまり、ある Operator が、所定の API を提供し、バージョン
>1.1.0
を持つ別の Operator に依存するように指定することはできません。依存関係を指定すると、以下のようになります。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OLM は EtcdCluster を提供する Operator とバージョン
>3.1.0
を持つ Operator の 2 つの Operator で、上記の依存関係の例の条件を満たすことができる可能性があります。その場合や、または両方の制約を満たす Operator が選択されるかどうかは、選択できる可能性のあるオプションが参照される順序によって変わります。依存関係の設定および順序のオプションは十分に定義され、理にかなったものであると考えられますが、Operator は継続的に特定のメカニズムをベースとする必要があります。- namespace 間の互換性
- OLM は namespace スコープで依存関係の解決を実行します。ある namespace での Operator の更新が別の namespace の Operator の問題となる場合、更新のデッドロックが生じる可能性があります。
2.4.4.9. 依存関係解決のシナリオ例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例で、プロバイダー は CRD または API サービスを "所有" する Operator です。
2.4.4.9.1. 例: 依存 API を非推奨にする リンクのコピーリンクがクリップボードにコピーされました!
A および B は API (CRD):
- A のプロバイダーは B によって異なる。
- B のプロバイダーにはサブスクリプションがある。
- B のプロバイダーは C を提供するように更新するが、B を非推奨にする。
この結果は以下のようになります。
- B にはプロバイダーがなくなる。
- A は機能しなくなる。
これは OLM がアップグレードストラテジーで回避するケースです。
2.4.4.9.2. 例: バージョンのデッドロック リンクのコピーリンクがクリップボードにコピーされました!
A および B は API である:
- A のプロバイダーは B を必要とする。
- B のプロバイダーは A を必要とする。
- A のプロバイダーは (A2 を提供し、B2 を必要とするように) 更新し、A を非推奨にする。
- B のプロバイダーは (B2 を提供し、A2 を必要とするように) 更新し、B を非推奨にする。
OLM が B を同時に更新せずに A を更新しようとする場合や、その逆の場合、OLM は、新しい互換性のあるセットが見つかったとしても Operator の新規バージョンに進むことができません。
これは OLM がアップグレードストラテジーで回避するもう 1 つのケースです。
2.4.5. Operator グループ リンクのコピーリンクがクリップボードにコピーされました!
以下では、OpenShift Container Platform で Operator Lifecycle Manager (OLM) を使用した Operator グループの使用を説明します。
2.4.5.1. Operator グループについて リンクのコピーリンクがクリップボードにコピーされました!
Operator グループ は、OperatorGroup
リソースによって定義され、マルチテナント設定を OLM でインストールされた Operator に提供します。Operator グループは、そのメンバー Operator に必要な RBAC アクセスを生成するために使用するターゲット namespace を選択します。
ターゲット namespace のセットは、クラスターサービスバージョン (CSV) の olm.targetNamespaces
アノテーションに保存されるコンマ区切りの文字列によって指定されます。このアノテーションは、メンバー Operator の CSV インスタンスに適用され、それらのデプロインメントに展開されます。
2.4.5.2. Operator グループメンバーシップ リンクのコピーリンクがクリップボードにコピーされました!
Operator は、以下の条件が true の場合に Operator グループの メンバー とみなされます。
- Operator の CSV が Operator グループと同じ namespace にある。
- Operator の CSV のインストールモードは Operator グループがターゲットに設定する namespace のセットをサポートする。
CSV のインストールモードは InstallModeType
フィールドおよびブール値の Supported
フィールドで構成されます。CSV の仕様には、4 つの固有の InstallModeTypes
のインストールモードのセットを含めることができます。
InstallModeType | 説明 |
---|---|
| Operator は、独自の namespace を選択する Operator グループのメンバーにすることができます。 |
| Operator は 1 つの namespace を選択する Operator グループのメンバーにすることができます。 |
| Operator は複数の namespace を選択する Operator グループのメンバーにすることができます。 |
|
Operator はすべての namespace を選択する Operator グループのメンバーにすることができます (設定されるターゲット namespace は空の文字列 |
CSV の仕様が InstallModeType
のエントリーを省略する場合、そのタイプは暗黙的にこれをサポートする既存エントリーによってサポートが示唆されない限り、サポートされないものとみなされます。
2.4.5.3. ターゲット namespace の選択 リンクのコピーリンクがクリップボードにコピーされました!
spec.targetNamespaces
パラメーターを使用して Operator グループのターゲット namespace に名前を明示的に指定することができます。
または、spec.selector
パラメーターでラベルセレクターを使用して namespace を指定することもできます。
spec.targetNamespaces
で複数の namespace をリスト表示したり、spec.selector
でラベルセレクターを使用したりすることは推奨されません。Operator グループの複数のターゲット namespace のサポートは今後のリリースで取り除かれる可能性があります。
spec.targetNamespaces
と spec.selector
の両方が定義されている場合、spec.selector
は無視されます。または、spec.selector
と spec.targetNamespaces
の両方を省略し、global Operator グループを指定できます。これにより、すべての namespace が選択されます。
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: my-group namespace: my-namespace
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: my-group
namespace: my-namespace
選択された namespace の解決済みのセットは Operator グループの status.namespaces
パラメーターに表示されます。グローバル Operator グループの status.namespace
には空の文字列 (""
) が含まれます。これは、消費する Operator に対し、すべての namespace を監視するように示唆します。
2.4.5.4. Operator グループの CSV アノテーション リンクのコピーリンクがクリップボードにコピーされました!
Operator グループのメンバー CSV には以下のアノテーションがあります。
アノテーション | 説明 |
---|---|
| Operator グループの名前が含まれます。 |
| Operator グループの namespace が含まれます。 |
| Operator グループのターゲット namespace 選択をリスト表示するコンマ区切りの文字列が含まれます。 |
olm.targetNamespaces
以外のすべてのアノテーションがコピーされた CSV と共に含まれます。olm.targetNamespaces
アノテーションをコピーされた CSV で省略すると、テナント間のターゲット namespace の重複が回避されます。
2.4.5.5. 提供される API アノテーション リンクのコピーリンクがクリップボードにコピーされました!
group/version/kind(GVK) は Kubernetes API の一意の識別子です。Operator グループによって提供される GVK に関する情報が olm.providedAPIs
アノテーションに表示されます。アノテーションの値は、コンマで区切られた <kind>.<version>.<group>
で構成される文字列です。Operator グループのすべてのアクティブメンバーの CSV によって提供される CRD および API サービスの GVK が含まれます。
PackageManifest
リースを提供する単一のアクティブメンバー CSV を含む OperatorGroup
オブジェクトの以下の例を確認してください。
2.4.5.6. ロールベースのアクセス制御 リンクのコピーリンクがクリップボードにコピーされました!
Operator グループの作成時に、3 つのクラスタールールが生成されます。クラスターロールが生成されると、各クラスターロールが一意になるように、ハッシュ値が自動的に末尾に付加されます。各 Operator グループには、次の表に示すように、ラベルに一致するように設定されたクラスターロールセレクターを持つ 1 つの集約ルールが含まれています。
クラスターロール | 一致するラベル |
---|---|
|
|
|
|
|
|
Operator グループのクラスターロールを使用してリソースにロールベースのアクセス制御 (RBAC) を割り当てるには、次のコマンドを実行して、クラスターロールの完全な名前とハッシュ値を取得します。
oc get clusterroles | grep <operatorgroup_name>
$ oc get clusterroles | grep <operatorgroup_name>
ハッシュ値は Operator グループの作成時に生成されるため、クラスターロールの完全な名前を検索するには、先に Operator グループを作成する必要があります。
以下の RBAC リソースは、CSV が AllNamespaces
インストールモードのあるすべての namespace を監視しており、理由が InterOperatorGroupOwnerConflict
の失敗状態にない限り、CSV が Operator グループのアクティブメンバーになる際に生成されます。
- CRD からの各 API リソースのクラスターロール
- API サービスからの各 API リソースのクラスターロール
- 追加のロールおよびロールバインディング
クラスターロール | 設定 |
---|---|
|
集計ラベル:
|
|
集計ラベル:
|
|
集計ラベル:
|
|
Verbs on
集計ラベル:
|
クラスターロール | 設定 |
---|---|
|
集計ラベル:
|
|
集計ラベル:
|
|
集計ラベル:
|
追加のロールおよびロールバインディング
-
CSV が
*
が含まれる 1 つのターゲット namespace を定義する場合、クラスターロールと対応するクラスターロールバインディングが CSV のpermissions
フィールドに定義されるパーミッションごとに生成されます。生成されたすべてのリソースにはolm.owner: <csv_name>
およびolm.owner.namespace: <csv_namespace>
ラベルが付与されます。 -
CSV が
*
が含まれる 1 つのターゲット namespace を定義 しない 場合、olm.owner: <csv_name>
およびolm.owner.namespace: <csv_namespace>
ラベルの付いた Operator namespace にあるすべてのロールおよびロールバインディングがターゲット namespace にコピーされます。
2.4.5.7. コピーされる CSV リンクのコピーリンクがクリップボードにコピーされました!
OLM は、それぞれの Operator グループのターゲット namespace の Operator グループのすべてのアクティブな CSV のコピーを作成します。コピーされる CSV の目的は、ユーザーに対して、特定の Operator が作成されるリソースを監視するように設定されたターゲット namespace を通知することにあります。
コピーされる CSV にはステータスの理由 Copied
があり、それらのソース CSV のステータスに一致するように更新されます。olm.targetNamespaces
アノテーションは、クラスター上でコピーされる CSV が作成される前に取られます。ターゲット namespace 選択を省略すると、テナント間のターゲット namespace の重複が回避されます。
コピーされる CSV はそれらのソース CSV が存在しなくなるか、それらのソース CSV が属する Operator グループが、コピーされた CSV の namespace をターゲットに設定しなくなると削除されます。
デフォルトでは、disableCopiedCSVs
フィールドは無効になっています。disableCopiedCSVs
フィールドを有効にすると、OLM はクラスター上の既存のコピーされた CSV を削除します。disableCopiedCSVs
フィールドが無効になると、OLM はコピーされた CSV を再度追加します。
disableCopiedCSVs
フィールドを無効にします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow disableCopiedCSVs
フィールドを有効にします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4.5.8. 静的 Operator グループ リンクのコピーリンクがクリップボードにコピーされました!
Operator グループはその spec.staticProvidedAPIs
フィールドが true
に設定されると 静的 になります。その結果、OLM は Operator グループの olm.providedAPIs
アノテーションを変更しません。つまり、これを事前に設定することができます。これは、ユーザーが Operator グループを使用して namespace のセットでリソースの競合を防ぐ必要がある場合で、それらのリソースの API を提供するアクティブなメンバーの CSV がない場合に役立ちます。
以下は、something.cool.io/cluster-monitoring: "true"
アノテーションのあるすべての namespace の Prometheus
リソースを保護する Operator グループの例です。
2.4.5.9. Operator グループの交差部分 リンクのコピーリンクがクリップボードにコピーされました!
2 つの Operator グループは、それらのターゲット namespace セットの交差部分が空のセットではなく、olm.providedAPIs
アノテーションで定義されるそれらの指定 API セットの交差部分が空のセットではない場合に、交差部分のある指定 API があると見なされます。
これによって生じ得る問題として、交差部分のある指定 API を持つ複数の Operator グループは、一連の交差部分のある namespace で同じリソースに関して競合関係になる可能性があります。
交差ルールを確認すると、Operator グループの namespace は常に選択されたターゲット namespace の一部として組み込まれます。
2.4.5.9.1. 交差のルール リンクのコピーリンクがクリップボードにコピーされました!
アクティブメンバーの CSV が同期する際はいつでも、OLM はクラスターで、CSV の Operator グループとそれ以外のすべての間での交差部分のある指定 API のセットをクエリーします。その後、OLM はそのセットが空のセットであるかどうかを確認します。
true
であり、CSV の指定 API が Operator グループのサブセットである場合:- 移行を継続します。
true
であり、CSV の指定 API が Operator グループのサブセット ではない 場合:Operator グループが静的である場合:
- CSV に属するすべてのデプロイメントをクリーンアップします。
-
ステータスの理由
CannotModifyStaticOperatorGroupProvidedAPIs
のある失敗状態に CSV を移行します。
Operator グループが静的 ではない 場合:
-
Operator グループの
olm.providedAPIs
アノテーションを、それ自体と CSV の指定 API の集合に置き換えます。
-
Operator グループの
false
であり、CSV の指定 API が Operator グループのサブセット ではない 場合:- CSV に属するすべてのデプロイメントをクリーンアップします。
-
ステータスの理由
InterOperatorGroupOwnerConflict
のある失敗状態に CSV を移行します。
false
であり、CSV の指定 API が Operator グループのサブセットである場合:Operator グループが静的である場合:
- CSV に属するすべてのデプロイメントをクリーンアップします。
-
ステータスの理由
CannotModifyStaticOperatorGroupProvidedAPIs
のある失敗状態に CSV を移行します。
Operator グループが静的 ではない 場合:
-
Operator グループの
olm.providedAPIs
アノテーションを、それ自体と CSV の指定 API 間の差異部分に置き換えます。
-
Operator グループの
Operator グループによって生じる失敗状態は非終了状態です。
以下のアクションは、Operator グループが同期するたびに実行されます。
- アクティブメンバーの CSV の指定 API のセットは、クラスターから計算されます。コピーされた CSV は無視されることに注意してください。
-
クラスターセットは
olm.providedAPIs
と比較され、olm.providedAPIs
に追加の API が含まれる場合は、それらの API がプルーニングされます。 - すべての namespace で同じ API を提供するすべての CSV は再びキューに入れられます。これにより、交差部分のあるグループ間の競合する CSV に対して、それらの競合が競合する CSV のサイズ変更または削除のいずれかによって解決されている可能性があることが通知されます。
2.4.5.10. マルチテナント Operator 管理の制限事項 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、異なるバージョンの Operator を同じクラスターに同時にインストールするための限定的なサポートを提供します。Operator Lifecycle Manager (OLM) は、Operator を異なる namespace に複数回インストールします。その 1 つの制約として、Operator の API バージョンは同じである必要があります。
Operator は、Kubernetes のグローバルリソースである CustomResourceDefinition
オブジェクト (CRD) を使用するため、コントロールプレーンの拡張機能です。多くの場合、Operator の異なるメジャーバージョンには互換性のない CRD があります。これにより、クラスター上の異なる namespace に同時にインストールするのに互換性がなくなります。
すべてのテナントまたは namespace がクラスターの同じコントロールプレーンを共有します。したがって、マルチテナントクラスター内のテナントはグローバル CRD も共有するため、同じクラスターで同じ Operator の異なるインスタンスを並行して使用できるシナリオが制限されます。
サポートされているシナリオは次のとおりです。
- まったく同じ CRD 定義を提供する異なるバージョンの Operator (バージョン管理された CRD の場合は、まったく同じバージョンのセット)
- CRD を同梱せず、代わりに OperatorHub の別のバンドルで CRD を利用できる異なるバージョンの Operator
他のすべてのシナリオはサポートされていません。これは、異なる Operator バージョンからの複数の競合または重複する CRD が同じクラスター上で調整される場合、クラスターデータの整合性が保証されないためです。
2.4.5.11. Operator グループのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
2.4.5.11.1. メンバーシップ リンクのコピーリンクがクリップボードにコピーされました!
インストールプランの namespace には、Operator グループを 1 つだけ含める必要があります。namespace でクラスターサービスバージョン (CSV) を生成しようとすると、インストールプランでは、以下のシナリオの Operator グループが無効であると見なされます。
- インストールプランの namespace に Operator グループが存在しない。
- インストールプランの namespace に複数の Operator グループが存在する。
- Operator グループに、正しくないサービスアカウント名または存在しないサービスアカウント名が指定されている。
インストールプランで無効な Operator グループが検出された場合には、CSV は生成されず、
InstallPlan
リソースは関連するメッセージを出力して、インストールを続行します。たとえば、複数の Operator グループが同じ namespace に存在する場合に以下のメッセージが表示されます。attenuated service account query failed - more than one operator group(s) are managing this namespace count=2
attenuated service account query failed - more than one operator group(s) are managing this namespace count=2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、
count=
は、namespace 内の Operator グループの数を指します。-
CSV のインストールモードがその namespace で Operator グループのターゲット namespace 選択をサポートしない場合、CSV は
UnsupportedOperatorGroup
の理由で失敗状態に切り替わります。この理由で失敗した状態にある CSV は、Operator グループのターゲット namespace の選択がサポートされる設定に変更されるか、CSV のインストールモードがターゲット namespace 選択をサポートするように変更される場合に、保留状態に切り替わります。
2.4.6. マルチテナント対応と Operator のコロケーション リンクのコピーリンクがクリップボードにコピーされました!
このガイドでは、Operator Lifecycle Manager (OLM) のマルチテナント対応と Operator のコロケーションを説明します。
2.4.6.1. namespace 内での Operator コロケーション リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) は、同じ namespace にインストールされている OLM 管理 Operator を処理します。つまり、それらの Subscription
リソースは、関連する Operator として同じ namespace に配置されます。それらが実際には関連していなくても、いずれかが更新されると、OLM はバージョンや更新ポリシーなどの状態を考慮します。
このデフォルトの動作は、次の 2 つの方法で現れます。
-
保留中の更新の
InstallPlan
リソースには、同じ namespace にある他のすべての Operator のClusterServiceVersion
(CSV) リソースが含まれます。 - 同じ namespace 内のすべての Operator は、同じ更新ポリシーを共有します。たとえば、1 つの Operator が手動更新に設定されている場合は、他のすべての Operator の更新ポリシーも手動に設定されます。
これらのシナリオは、次の問題につながる可能性があります。
- 更新された Operator だけでなく、より多くのリソースが定義されているため、Operator 更新のインストール計画を推論するのは難しくなります。
- ネームスペース内の一部の Operator を自動的に更新し、他の Operator を手動で更新することは不可能になります。これは、クラスター管理者にとって一般的な要望です。
OpenShift Container Platform Web コンソールを使用して Operator をインストールすると、デフォルトの動作により、All namespaces インストールモードをサポートする Operator がデフォルトの openshift-operators
グローバル namespace にインストールされるため、これらの問題は通常表面化します。
クラスター管理者は、次のワークフローを使用して、このデフォルトの動作を手動でバイパスできます。
- Operator のインストール用の namespace を作成します。
- すべての namespace を監視する Operator グループである、カスタム グローバル Operator グループ を作成します。この Operator グループを作成した namespace に関連付けることで、インストール namespace がグローバル namespace になり、そこにインストールされた Operator がすべての namespace で使用できるようになります。
- 必要な Operator をインストール namespace にインストールします。
Operator に依存関係がある場合、依存関係は事前に作成された namespace に自動的にインストールされます。その結果、依存関係 Operator が同じ更新ポリシーと共有インストールプランを持つことが有効になります。詳細な手順は、「カスタム namespace へのグローバル Operator のインストール」を参照してください。
2.4.7. Operator 条件 リンクのコピーリンクがクリップボードにコピーされました!
以下では、Operator Lifecycle Manager (OLM) による Operator 条件の使用方法を説明します。
2.4.7.1. Operator 条件について リンクのコピーリンクがクリップボードにコピーされました!
Operator のライフサイクル管理のロールの一部として、Operator Lifecycle Manager (OLM) は、Operator を定義する Kubernetes リソースの状態から Operator の状態を推測します。このアプローチでは、Operator が特定の状態にあることをある程度保証しますが、推測できない情報を Operator が OLM と通信して提供する必要がある場合も多々あります。続いて、OLM がこの情報を使用して、Operator のライフサイクルをより適切に管理することができます。
OLM は、Operator が OLM に条件を通信できる OperatorCondition
というカスタムリソース定義 (CRD) を提供します。OperatorCondition
リソースの Spec.Conditions
配列にある場合に、OLM による Operator の管理に影響するサポートされる条件のセットがあります。
デフォルトでは、Spec.Conditions
配列は、ユーザーによって追加されるか、カスタム Operator ロジックの結果として追加されるまで、OperatorCondition
オブジェクトに存在しません。
2.4.7.2. サポートされる条件 リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) は、以下の Operator 条件をサポートします。
2.4.7.2.1. アップグレード可能な条件 リンクのコピーリンクがクリップボードにコピーされました!
Upgradeable
Operator 条件は、既存のクラスターサービスバージョン (CSV) が、新規の CSV バージョンに置き換えられることを阻止します。この条件は、以下の場合に役に立ちます。
- Operator が重要なプロセスを開始するところで、プロセスが完了するまでアップグレードしてはいけない場合
- Operator が、Operator のアップグレードの準備ができる前に完了する必要のあるカスタムリソース (CR) の移行を実行している場合
Upgradeable
Operator の条件を False
値に設定しても、Pod の中断は回避できません。Pod が中断されないようにする必要がある場合は、「追加リソース」セクションの「Pod 中断バジェットを使用して稼働させなければならない Pod の数を指定する」と「正常な終了」を参照してください。
Upgradeable
Operator 条件の例
2.4.8. Operator Lifecycle Manager メトリクス リンクのコピーリンクがクリップボードにコピーされました!
2.4.8.1. 公開されるメトリック リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) は、Prometheus ベースの OpenShift Container Platform クラスターモニタリングスタックで使用される特定の OLM 固有のリソースを公開します。
名前 | 説明 |
---|---|
| カタログソースの数。 |
|
カタログソースの状態。値 |
|
クラスターサービスバージョン (CSV) を調整する際に、(インストールされていない場合など) CSV バージョンが |
| 正常に登録された CSV の数。 |
|
CSV を調整する際に、CSV バージョンが |
| CSV アップグレードの単調 (monotonic) カウント。 |
| インストール計画の数。 |
| インストール計画に含まれる非推奨のリソースなど、リソースによって生成される警告の個数。 |
| 依存関係解決の試行期間。 |
| サブスクリプションの数。 |
|
サブスクリプション同期の単調 (monotonic) カウント。 |
2.4.9. Operator Lifecycle Manager での Webhook の管理 リンクのコピーリンクがクリップボードにコピーされました!
Webhook により、リソースがオブジェクトストアに保存され、Operator コントローラーによって処理される前に、Operator の作成者はリソースのインターセプト、変更、許可、および拒否を実行することができます。Operator Lifecycle Manager (OLM) は、Operator と共に提供される際にこれらの Webhook のライフサイクルを管理できます。
2.5. OperatorHub について リンクのコピーリンクがクリップボードにコピーされました!
2.5.1. OperatorHub について リンクのコピーリンクがクリップボードにコピーされました!
OperatorHub は OpenShift Container Platform の Web コンソールインターフェイスであり、これを使用してクラスター管理者は Operator を検出し、インストールします。1 回のクリックで、Operator をクラスター外のソースからプルし、クラスター上でインストールおよびサブスクライブして、エンジニアリングチームが Operator Lifecycle Manager (OLM) を使用してデプロイメント環境全体で製品をセルフサービスで管理される状態にすることができます。
クラスター管理者は、以下のカテゴリーにグループ化されたカタログから選択することができます。
カテゴリー | 説明 |
---|---|
Red Hat Operator | Red Hat によってパッケージ化され、出荷される Red Hat 製品。Red Hat によってサポートされます。 |
認定 Operator | 大手独立系ソフトウェアベンダー (ISV) の製品。Red Hat は ISV とのパートナーシップにより、パッケージ化および出荷を行います。ISV によってサポートされます。 |
コミュニティー Operator | redhat-openshift-ecosystem/community-operators-prod/operators GitHub リポジトリーで関連する担当者によって保守されているオプションで表示可能なソフトウェア。正式なサポートはありません。 |
カスタム Operator | 各自でクラスターに追加する Operator。カスタム Operator を追加していない場合、カスタム カテゴリーは Web コンソールの OperatorHub 上に表示されません。 |
OperatorHub の Operator は OLM で実行されるようにパッケージ化されます。これには、Operator のインストールおよびセキュアな実行に必要なすべての CRD、RBAC ルール、デプロイメント、およびコンテナーイメージが含まれるクラスターサービスバージョン (CSV) という YAML ファイルが含まれます。また、機能の詳細やサポートされる Kubernetes バージョンなどのユーザーに表示される情報も含まれます。
2.5.2. OperatorHub アーキテクチャー リンクのコピーリンクがクリップボードにコピーされました!
OperatorHub UI コンポーネントは、デフォルトで OpenShift Container Platform の openshift-marketplace
namespace で Marketplace Operator によって実行されます。
2.5.2.1. OperatorHub カスタムリソース リンクのコピーリンクがクリップボードにコピーされました!
Marketplace Operator は、OperatorHub で提供されるデフォルトの CatalogSource
オブジェクトを管理する cluster
という名前の OperatorHub
カスタムリソース (CR) を管理します。このリソースを変更して、デフォルトのカタログを有効または無効にすることができます。これは、ネットワークが制限された環境で OpenShift Container Platform を設定する際に役立ちます。
OperatorHub
カスタムリースの例
2.6. Red Hat が提供する Operator カタログ リンクのコピーリンクがクリップボードにコピーされました!
Red Hat は、デフォルトで OpenShift Container Platform に含まれる複数の Operator カタログを提供します。
OpenShift Container Platform 4.11 の時点で、デフォルトの Red Hat が提供する Operator カタログは、ファイルベースのカタログ形式でリリースされます。OpenShift Container Platform 4.6 から 4.10 までのデフォルトの Red Hat が提供する Operator カタログは、非推奨の SQLite データベース形式でリリースされました。
opm
サブコマンド、フラグ、および SQLite データベース形式に関連する機能も非推奨となり、今後のリリースで削除されます。機能は引き続きサポートされており、非推奨の SQLite データベース形式を使用するカタログに使用する必要があります。
opm index prune
などの SQLite データベース形式を使用する opm
サブコマンドおよびフラグの多くは、ファイルベースのカタログ形式では機能しません。ファイルベースのカタログを使用する方法の詳細は、カスタムカタログの管理、Operator Framework パッケージ形式、および oc-mirror プラグインを使用した非接続インストールのイメージのミラーリング を参照してください。
2.6.1. Operator カタログについて リンクのコピーリンクがクリップボードにコピーされました!
Operator カタログは、Operator Lifecycle Manager (OLM) がクエリーを行い、Operator およびそれらの依存関係をクラスターで検出し、インストールできるメタデータのリポジトリーです。OLM は最新バージョンのカタログから Operator を常にインストールします。
Operator Bundle Format に基づくインデックスイメージは、カタログのコンテナー化されたスナップショットです。これは、Operator マニフェストコンテンツのセットへのポインターのデータベースが含まれるイミュータブルなアーティファクトです。カタログはインデックスイメージを参照し、クラスター上の OLM のコンテンツを調達できます。
カタログが更新されると、Operator の最新バージョンが変更され、それ以前のバージョンが削除または変更される可能性があります。さらに OLM がネットワークが制限された環境の OpenShift Container Platform クラスターで実行される場合、最新のコンテンツをプルするためにインターネットからカタログに直接アクセスすることはできません。
クラスター管理者は、Red Hat が提供するカタログをベースとして使用して、またはゼロから独自のカスタムインデックスイメージを作成できます。これを使用して、クラスターのカタログコンテンツを調達できます。独自のインデックスイメージの作成および更新により、クラスターで利用可能な Operator のセットをカスタマイズする方法が提供され、また前述のネットワークが制限された環境の問題を回避することができます。
Kubernetes は定期的に特定の API を非推奨とし、後続のリリースで削除します。その結果、Operator は API を削除した Kubernetes バージョンを使用する OpenShift Container Platform のバージョン以降、削除された API を使用できなくなります。
レガシー形式をしようしたカスタムのカタログなど、Operator のレガシー パッケージマニフェスト形式 のサポートは、OpenShift Container Platform 4.8 以降で削除されます。
カスタムカタログイメージを作成する場合、OpenShift Container Platform 4 の以前のバージョンでは、複数のリリースで非推奨となった oc adm catalog build
コマンドの使用が必要でしたが、これは削除されました。OpenShift Container Platform 4.6 以降で Red Hat が提供するインデックスイメージが利用可能になると、カタログビルダーは opm index
コマンドを使用してインデックスイメージを管理する必要があります。
2.6.2. Red Hat が提供する Operator カタログについて リンクのコピーリンクがクリップボードにコピーされました!
Red Hat が提供するカタログソースは、デフォルトで openshift-marketplace
namespace にインストールされます。これにより、すべての namespace でクラスター全体でカタログを利用できるようになります。
以下の Operator カタログは Red Hat によって提供されます。
Catalog | インデックスイメージ | 説明 |
---|---|---|
|
| Red Hat によってパッケージ化され、出荷される Red Hat 製品。Red Hat によってサポートされます。 |
|
| 大手独立系ソフトウェアベンダー (ISV) の製品。Red Hat は ISV とのパートナーシップにより、パッケージ化および出荷を行います。ISV によってサポートされます。 |
|
| 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
2.7. マルチテナントクラスター内の Operator リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) のデフォルトの動作は、Operator のインストール時に簡素化することを目的としています。ただし、この動作は、特にマルチテナントクラスターでは柔軟性に欠ける場合があります。OpenShift Container Platform クラスター上の複数のテナントが Operator を使用するには、OLM のデフォルトの動作では、管理者が Operator を All namespaces モードでインストールする必要がありますが、これは最小特権の原則に違反すると考えられます。
以下のシナリオを考慮して、環境と要件に最適な Operator インストールワークフローを決定してください。
2.7.1. デフォルトの Operator インストールモードと動作 リンクのコピーリンクがクリップボードにコピーされました!
管理者として Web コンソールを使用して Operator をインストールする場合、通常、Operator の機能に応じて、インストールモードに 2 つの選択肢があります。
- 単一の namespace
- 選択した単一の namespace に Operator をインストールし、Operator が要求するすべての権限をその namespace で使用できるようにします。
- すべての namespace
-
デフォルトの
openshift-operators
namespace で Operator をインストールし、クラスターのすべての namespace を監視し、Operator をこれらの namespace に対して利用可能にします。Operator が要求するすべてのアクセス許可をすべての namespace で使用できるようにします。場合によっては、Operator の作成者はメタデータを定義して、その Operator が提案する namespace の 2 番目のオプションをユーザーに提供できます。
この選択は、影響を受ける namespace のユーザーが、namespace でのロールに応じて、所有するカスタムリソース (CR) を活用できる Operators API にアクセスできることも意味します。
-
namespace-admin
およびnamespace-edit
ロールは、Operator API の読み取り/書き込みが可能です。つまり、Operator API を使用できます。 -
namespace-view
ロールは、その Operator の CR オブジェクトを読み取ることができます。
Single namespace モードの場合、Operator 自体が選択した namespace にインストールされるため、その Pod とサービスアカウントもそこに配置されます。All namespaces モードの場合、Operator の権限はすべて自動的にクラスターロールに昇格されます。つまり、Operator はすべての namespace でこれらの権限を持ちます。
2.7.2. マルチテナントクラスターの推奨ソリューション リンクのコピーリンクがクリップボードにコピーされました!
Multinamespace インストールモードは存在しますが、サポートされている Operator はほとんどありません。標準 All namespaces と Single namespace インストールモードの中間的なソリューションとして、次のワークフローを使用して、テナントごとに 1 つずつ、同じ Operator の複数のインスタンスをインストールできます。
- テナントの namespace とは別のテナント Operator の namespace を作成します。
- テナントの namespace のみを対象とするテナント Operator の Operator グループを作成します。
- テナント Operator namespace に Operator をインストールします。
その結果、Operator はテナントの Operator namespace に存在し、テナントの namespace を監視しますが、Operator の Pod もそのサービスアカウントも、テナントによって表示または使用できません。
このソリューションは、より優れたテナント分離、リソースの使用を犠牲にした最小特権の原則、および制約が確実に満たされるようにするための追加のオーケストレーションを提供します。詳細な手順は、「マルチテナントクラスター用の Operator の複数インスタンスの準備」を参照してください。
制限および考慮事項
このソリューションは、次の制約が満たされている場合にのみ機能します。
- 同じ Operator のすべてのインスタンスは、同じバージョンである必要があります。
- Operator は、他の Operator に依存することはできません。
- Operator は CRD 変換 Webhook を出荷できません。
同じクラスターで同じ Operator の異なるバージョンを使用することはできません。最終的に、Operator の別のインスタンスのインストールは、以下の条件を満たす場合にブロックされます。
- インスタンスは Operator の最新バージョンではありません。
- インスタンスは、クラスターですでに使用されている新しいリビジョンに含まれる情報またはバージョンを欠いている CRD の古いリビジョンを出荷します。
「非クラスター管理者による Operator のインストールの許可」で説明されているように、非クラスター管理者が自給自足で Operator をインストールできるようにする場合は、管理者として注意してください。これらのテナントは、依存関係がないことがわかっている Operator の精選されたカタログにのみアクセスできる必要があります。これらのテナントは、CRD が変更されないようにするために、Operator の同じバージョンラインを使用することを強制する必要もあります。これには、ネームスペーススコープのカタログを使用し、グローバルなデフォルトカタログを無効にする必要があります。
2.7.3. Operator のコロケーションと Operator グループ リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) は、同じ namespace にインストールされている OLM 管理 Operator を処理します。つまり、それらの Subscription
リソースは、関連する Operator として同じ namespace に配置されます。それらが実際には関連していなくても、いずれかが更新されると、OLM はバージョンや更新ポリシーなどの状態を考慮します。
Operator のコロケーションと Operator グループの効果的な使用の詳細は、Operator Lifecycle Manager (OLM) → マルチテナント対応と Operator のコロケーション を参照してください。
2.8. CRD リンクのコピーリンクがクリップボードにコピーされました!
2.8.1. カスタムリソース定義による Kubernetes API の拡張 リンクのコピーリンクがクリップボードにコピーされました!
Operator は Kubernetes の拡張メカニズムであるカスタムリソース定義 (CRD) を使用するため、Operator によって管理されるカスタムオブジェクトは、組み込み済みのネイティブ Kubernetes オブジェクトのように表示され、機能します。以下では、CRD を作成し、管理することで、クラスター管理者が OpenShift Container Platform クラスターをどのように拡張できるかを説明します。
2.8.1.1. カスタムリソース定義 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes API では、リソース は特定の種類の API オブジェクトのコレクションを保管するエンドポイントです。たとえば、ビルトインされた Pods
リソースには、Pod
オブジェクトのコレクションが含まれます。
カスタムリソース定義 (CRD) オブジェクトは、クラスター内に新規の固有オブジェクト kind を定義し、Kubernetes API サーバーにそのライフサイクル全体を処理させます。
カスタムリソース (CR) オブジェクトは、クラスター管理者によってクラスターに追加された CRD から作成され、すべてのクラスターユーザーが新規リソースタイプをプロジェクトに追加できるようにします。
クラスター管理者が新規 CRD をクラスターに追加する際に、Kubernetes API サーバーは、クラスター全体または単一プロジェクト (namespace) によってアクセスできる新規の RESTful リソースパスを作成することによって応答し、指定された CR を提供し始めます。
CRD へのアクセスを他のユーザーに付与する必要のあるクラスター管理者は、クラスターロールの集計を使用して admin
、edit
、または view
のデフォルトクラスターロールを持つユーザーにアクセスを付与できます。また、クラスターロールの集計により、カスタムポリシールールをこれらのクラスターロールに挿入することができます。この動作は、新規リソースを組み込み型のインリソースであるかのようにクラスターの RBAC ポリシーに統合します。
Operator はとりわけ CRD を必要な RBAC ポリシーおよび他のソフトウェア固有のロジックでパッケージ化することで CRD を利用します。またクラスター管理者は、Operator のライフサイクル外にあるクラスターに CRD を手動で追加でき、これらをすべてのユーザーに利用可能にすることができます。
クラスター管理者のみが CRD を作成できる一方で、開発者は CRD への読み取りおよび書き込みパーミッションがある場合には、既存の CRD から CR を作成することができます。
2.8.1.2. カスタムリソース定義の作成 リンクのコピーリンクがクリップボードにコピーされました!
カスタムリソース (CR) オブジェクトを作成するには、クラスター管理者はまずカスタムリソース定義 (CRD) を作成する必要があります。
前提条件
-
cluster-admin
ユーザー権限を使用した OpenShift Container Platform クラスターへのアクセス
手順
CRD を作成するには、以下を実行します。
以下の例のようなフィールドタイプを含む YAML ファイルを作成します。
CRD の YAML ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
apiextensions.k8s.io/v1
API を使用します。- 2
- 定義の名前を指定します。これは
group
およびplural
フィールドの値を使用する<plural-name>.<group>
形式である必要があります。 - 3
- API のグループ名を指定します。API グループは、論理的に関連付けられるオブジェクトのコレクションです。たとえば、
Job
またはScheduledJob
などのすべてのバッチオブジェクトはバッチ API グループ (batch.api.example.com
など) である可能性があります。組織の完全修飾ドメイン名 (FQDN) を使用することが奨励されます。 - 4
- URL で使用されるバージョン名を指定します。それぞれの API グループは複数バージョンに存在させることができます (例:
v1alpha
、v1beta
、v1
)。 - 5
- カスタムオブジェクトがクラスター (
Cluster
) の 1 つのプロジェクト (Namespaced
) またはすべてのプロジェクトで利用可能であるかどうかを指定します。 - 6
- URL で使用される複数形の名前を指定します。
plural
フィールドは API URL のリソースと同じになります。 - 7
- CLI および表示用にエイリアスとして使用される単数形の名前を指定します。
- 8
- 作成できるオブジェクトの種類を指定します。タイプは CamelCase にすることができます。
- 9
- CLI でリソースに一致する短い文字列を指定します。
注記デフォルトで、CRD のスコープはクラスターで設定され、すべてのプロジェクトで利用可能です。
CRD オブジェクトを作成します。
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新規の RESTful API エンドポイントは以下のように作成されます。
/apis/<spec:group>/<spec:version>/<scope>/*/<names-plural>/...
/apis/<spec:group>/<spec:version>/<scope>/*/<names-plural>/...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow たとえば、サンプルファイルを使用すると、以下のエンドポイントが作成されます。
/apis/stable.example.com/v1/namespaces/*/crontabs/...
/apis/stable.example.com/v1/namespaces/*/crontabs/...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow このエンドポイント URL を使用して CR を作成し、管理できます。オブジェクト kind は、作成した CRD オブジェクトの
spec.kind
フィールドに基づいています。
2.8.1.3. カスタムリソース定義のクラスターロールの作成 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、既存のクラスタースコープのカスタムリソース定義 (CRD) にパーミッションを付与できます。admin
、edit
、および view
のデフォルトクラスターロールを使用する場合、これらのルールについてクラスターロールの集計を利用できます。
これらのロールのいずれかにパーミッションを付与する際は、明示的に付与する必要があります。より多くのパーミッションを持つロールはより少ないパーミッションを持つロールからルールを継承しません。ルールをあるロールに割り当てる場合、より多くのパーミッションを持つロールにもその動詞を割り当てる必要もあります。たとえば、get crontabs
パーミッションを表示ロールに付与する場合、これを edit
および admin
ロールにも付与する必要があります。admin
または edit
ロールは通常、プロジェクトテンプレートでプロジェクトを作成したユーザーに割り当てられます。
前提条件
- CRD を作成します。
手順
CRD のクラスターロール定義ファイルを作成します。クラスターロール定義は、各クラスターロールに適用されるルールが含まれる YAML ファイルです。OpenShift Container Platform Controller はデフォルトクラスターロールに指定するルールを追加します。
カスタムロール定義の YAML ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
rbac.authorization.k8s.io/v1
API を使用します。- 2 8
- 定義の名前を指定します。
- 3
- パーミッションを管理のデフォルトロールに付与するためにこのラベルを指定します。
- 4
- パーミッションを編集のデフォルトロールに付与するためにこのラベルを指定します。
- 5 11
- CRD のグループ名を指定します
- 6 12
- これらのルールが適用される CRD の複数形の名前を指定します。
- 7 13
- ロールに付与されるパーミッションを表す動詞を指定します。たとえば、読み取りおよび書き込みパーミッションを
admin
およびedit
ロールに適用し、読み取り専用パーミッションをview
ロールに適用します。 - 9
- このラベルを指定して、パーミッションを
view
デフォルトロールに付与します。 - 10
- このラベルを指定して、パーミッションを
cluster-reader
デフォルトロールに付与します。
クラスターロールを作成します。
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.8.1.4. ファイルからのカスタムリソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
カスタムリソース定義 (CRD) がクラスターに追加された後に、クラスターリソース (CR) は CR 仕様を使用するファイルを使って CLI で作成できます。
前提条件
- CRD がクラスター管理者によってクラスターに追加されている。
手順
CR の YAML ファイルを作成します。以下の定義例では、
cronSpec
とimage
のカスタムフィールドがKind: CronTab
の CR に設定されます。このKind
は、CRD オブジェクトのspec.kind
フィールドから取得されます。CR の YAML ファイルサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ファイルの作成後に、オブジェクトを作成します。
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.8.1.5. カスタムリソースの検査 リンクのコピーリンクがクリップボードにコピーされました!
CLI を使用してクラスターに存在するカスタムリソース (CR) オブジェクトを検査できます。
前提条件
- CR オブジェクトがアクセスできる namespace にあること。
手順
CR の特定の kind に関する情報を取得するには、以下を実行します。
oc get <kind>
$ oc get <kind>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc get crontab
$ oc get crontab
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME KIND my-new-cron-object CronTab.v1.stable.example.com
NAME KIND my-new-cron-object CronTab.v1.stable.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow リソース名では大文字と小文字が区別されず、CRD で定義される単数形または複数形のいずれか、および任意の短縮名を指定できます。以下に例を示します。
oc get crontabs
$ oc get crontabs
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get crontab
$ oc get crontab
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get ct
$ oc get ct
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CR の未加工の YAML データを確認することもできます。
oc get <kind> -o yaml
$ oc get <kind> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc get ct -o yaml
$ oc get ct -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.8.2. カスタムリソース定義からのリソースの管理 リンクのコピーリンクがクリップボードにコピーされました!
以下では、開発者がカスタムリソース定義 (CRD) にあるカスタムリソース (CR) をどのように管理できるかを説明します。
2.8.2.1. カスタムリソース定義 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes API では、リソース は特定の種類の API オブジェクトのコレクションを保管するエンドポイントです。たとえば、ビルトインされた Pods
リソースには、Pod
オブジェクトのコレクションが含まれます。
カスタムリソース定義 (CRD) オブジェクトは、クラスター内に新規の固有オブジェクト kind を定義し、Kubernetes API サーバーにそのライフサイクル全体を処理させます。
カスタムリソース (CR) オブジェクトは、クラスター管理者によってクラスターに追加された CRD から作成され、すべてのクラスターユーザーが新規リソースタイプをプロジェクトに追加できるようにします。
Operator はとりわけ CRD を必要な RBAC ポリシーおよび他のソフトウェア固有のロジックでパッケージ化することで CRD を利用します。またクラスター管理者は、Operator のライフサイクル外にあるクラスターに CRD を手動で追加でき、これらをすべてのユーザーに利用可能にすることができます。
クラスター管理者のみが CRD を作成できる一方で、開発者は CRD への読み取りおよび書き込みパーミッションがある場合には、既存の CRD から CR を作成することができます。
2.8.2.2. ファイルからのカスタムリソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
カスタムリソース定義 (CRD) がクラスターに追加された後に、クラスターリソース (CR) は CR 仕様を使用するファイルを使って CLI で作成できます。
前提条件
- CRD がクラスター管理者によってクラスターに追加されている。
手順
CR の YAML ファイルを作成します。以下の定義例では、
cronSpec
とimage
のカスタムフィールドがKind: CronTab
の CR に設定されます。このKind
は、CRD オブジェクトのspec.kind
フィールドから取得されます。CR の YAML ファイルサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ファイルの作成後に、オブジェクトを作成します。
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.8.2.3. カスタムリソースの検査 リンクのコピーリンクがクリップボードにコピーされました!
CLI を使用してクラスターに存在するカスタムリソース (CR) オブジェクトを検査できます。
前提条件
- CR オブジェクトがアクセスできる namespace にあること。
手順
CR の特定の kind に関する情報を取得するには、以下を実行します。
oc get <kind>
$ oc get <kind>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc get crontab
$ oc get crontab
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME KIND my-new-cron-object CronTab.v1.stable.example.com
NAME KIND my-new-cron-object CronTab.v1.stable.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow リソース名では大文字と小文字が区別されず、CRD で定義される単数形または複数形のいずれか、および任意の短縮名を指定できます。以下に例を示します。
oc get crontabs
$ oc get crontabs
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get crontab
$ oc get crontab
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get ct
$ oc get ct
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CR の未加工の YAML データを確認することもできます。
oc get <kind> -o yaml
$ oc get <kind> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
oc get ct -o yaml
$ oc get ct -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第3章 ユーザータスク リンクのコピーリンクがクリップボードにコピーされました!
3.1. インストールされた Operator からのアプリケーションの作成 リンクのコピーリンクがクリップボードにコピーされました!
以下では、開発者を対象に、OpenShift Container Platform Web コンソールを使用して、インストールされた Operator からアプリケーションを作成する例を示します。
3.1.1. Operator を使用した etcd クラスターの作成 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、Operator Lifecycle Manager (OLM) で管理される etcd Operator を使用した新規 etcd クラスターの作成を説明します。
前提条件
- OpenShift Container Platform 4.19 クラスターにアクセスできる。
- 管理者によってクラスター全体に etcd Operator がすでにインストールされている。
手順
-
この手順を実行するために OpenShift Container Platform Web コンソールで新規プロジェクトを作成します。この例では、
my-etcd
というプロジェクトを使用します。 Operators → Installed Operators ページに移動します。クラスター管理者によってクラスターにインストールされ、使用可能にされた Operator がクラスターサービスバージョン (CSV) のリストとしてここに表示されます。CSV は Operator によって提供されるソフトウェアを起動し、管理するために使用されます。
ヒント以下を使用して、CLI でこのリストを取得できます。
oc get csv
$ oc get csv
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Installed Operators ページで、etcd Operator をクリックして詳細情報および選択可能なアクションを表示します。
Provided APIs に表示されているように、この Operator は 3 つの新規リソースタイプを利用可能にします。これには、etcd クラスター (
EtcdCluster
リソース) のタイプが含まれます。これらのオブジェクトは、Deployment
またはReplicaSet
などの組み込み済みのネイティブ Kubernetes オブジェクトと同様に機能しますが、これらには etcd を管理するための固有のロジックが含まれます。新規 etcd クラスターを作成します。
- etcd Cluster API ボックスで、Create instance をクリックします。
-
次のページでは、
EtcdCluster
オブジェクト (クラスターのサイズなど) のテンプレートを起動する最小条件を変更できます。ここでは Create をクリックして確定します。これにより、Operator がトリガーされ、Pod、サービス、および新規 etcd クラスターの他のコンポーネントが起動します。
example etcd クラスター、Resources タブの順にクリックし、Operator が自動的に作成および設定した多数のリソースが含まれていることを確認します。
Kubernetes サービスが作成され、プロジェクトの他の Pod からデータベースにアクセスできることを確認します。
所定プロジェクトで
edit
ロールを持つすべてのユーザーは、クラウドサービスのようにセルフサービス方式でプロジェクトにすでに作成されている Operator によって管理されるアプリケーションのインスタンス (この例では etcd クラスター) を作成し、管理し、削除することができます。この機能を持つ追加のユーザーを有効にする必要がある場合、プロジェクト管理者は以下のコマンドを使用してこのロールを追加できます。oc policy add-role-to-user edit <user> -n <target_project>
$ oc policy add-role-to-user edit <user> -n <target_project>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
これで、etcd クラスターは Pod が正常でなくなったり、クラスターのノード間で移行する際の障害に対応し、データのリバランスを行います。最も重要な点として、適切なアクセスを持つクラスター管理者または開発者は独自のアプリケーションでデータベースを簡単に使用できるようになります。
3.2. namespace への Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者が Operator のインストールパーミッションをお使いのアカウントに委任している場合、セルフサービス方式で Operator をインストールし、これを namespace にサブスクライブできます。
3.2.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- クラスター管理者は、namespace へのセルフサービス Operator のインストールを許可するために OpenShift Container Platform ユーザーアカウントに特定のパーミッションを追加する必要があります。詳細は、クラスター管理者以外による Operator のインストールの許可 を参照してください。
3.2.2. OperatorHub を使用した Operator のインストールについて リンクのコピーリンクがクリップボードにコピーされました!
OperatorHub は Operator を検出するためのユーザーインターフェイスです。これは Operator Lifecycle Manager (OLM) と連携し、クラスター上で Operator をインストールし、管理します。
適切なパーミッションを持つユーザーとして、OpenShift Container Platform Web コンソールまたは CLI を使用して OperatorHub から Operator をインストールできます。
インストール時に、Operator の以下の初期設定を判別する必要があります。
- インストールモード
- Operator をインストールする特定の namespace を選択します。
- 更新チャネル
- Operator が複数のチャネルで利用可能な場合、サブスクライブするチャネルを選択できます。たとえば、(利用可能な場合に) stable チャネルからデプロイするには、これをリストから選択します。
- 承認ストラテジー
自動 (Automatic) または手動 (Manual) のいずれかの更新を選択します。
インストールされた Operator に自動更新を選択する場合、Operator の新規バージョンが選択されたチャネルで利用可能になると、Operator Lifecycle Manager (OLM) は人の介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。
手動更新を選択する場合、Operator の新規バージョンが利用可能になると、OLM は更新要求を作成します。クラスター管理者は、Operator が新規バージョンに更新されるように更新要求を手動で承認する必要があります。
3.2.3. Web コンソールを使用して OperatorHub からインストールする リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して OperatorHub から Operator をインストールし、これをサブスクライブできます。
前提条件
- Operator インストールパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
手順
- Web コンソールで、Operators → OperatorHub ページに移動します。
スクロールするか、キーワードを Filter by keyword ボックスに入力し、必要な Operator を見つけます。たとえば、Advanced Cluster Management for Kubernetes Operator を検索するには
advanced
を入力します。また、インフラストラクチャー機能 でオプションをフィルターすることもできます。たとえば、非接続環境 (ネットワークが制限された環境ともしても知られる) で機能する Operator を表示するには、Disconnected を選択します。
Operator を選択して、追加情報を表示します。
注記コミュニティー Operator を選択すると、Red Hat がコミュニティー Operator を認定していないことを警告します。続行する前に警告を確認する必要があります。
- Operator の情報を確認してから、Install をクリックします。
Install Operator ページで、Operator のインストールを設定します。
特定のバージョンの Operator をインストールする場合は、リストから Update channel と Version を選択します。Operator のすべてのチャネルから Operator のさまざまなバージョンを参照し、そのチャネルとバージョンのメタデータを表示して、インストールする正確なバージョンを選択できます。
注記バージョン選択のデフォルトは、選択したチャネルの最新バージョンです。チャネルの最新バージョンが選択されている場合は、自動 承認戦略がデフォルトで有効になります。それ以外の場合、選択したチャネルの最新バージョンをインストールしない場合は、手動 による承認が必要です。
手動 承認を使用して Operator をインストールすると、namespace 内にインストールされたすべての Operator が 手動 承認戦略で機能し、すべての Operator が一緒に更新されます。Operator を個別に更新する場合は、Operator を別の namespace にインストールします。
- Operator をインストールする特定の単一 namespace を選択します。Operator は監視のみを実行し、この単一 namespace で使用されるように利用可能になります。
トークン認証が有効になっているクラウドプロバイダー上のクラスターの場合:
- クラスターで AWS Security Token Service (Web コンソールの STS Mode) を使用する場合は、role ARN フィールドに、サービスアカウントの AWS IAM ロールの Amazon Resource Name (ARN) を入力します。ロールの ARN を作成するには、AWS アカウントの準備 で説明されている手順に従います。
- クラスターで Microsoft Entra Workload ID (Web コンソールの Workload Identity / Federated Identity Mode) を使用する場合は、適切なフィールドに、クライアント ID、テナント ID、サブスクリプション ID を追加します。
- クラスターで Google Cloud Platform Workload Identity (Web コンソールの GCP Workload Identity / Federated Identity Mode) を使用する場合は、適切なフィールドに、プロジェクト番号、プール ID、プロバイダー ID、サービスアカウントのメールアドレスを追加します。
Update approval で、承認ストラテジー Automatic または Manual を選択します。
重要Web コンソールに、クラスターが AWS STS、Microsoft Entra Workload ID、または GCP Workload Identity を使用していることが示されている場合は、Update approval を Manual に設定する必要があります。
更新の自動承認を使用したサブスクリプションは推奨されません。更新前に権限の変更が必要な場合があるためです。更新の手動承認を使用したサブスクリプションであれば、管理者が新しいバージョンの権限を確認し、必要な手順を実行してから更新できます。
Install をクリックし、Operator をこの OpenShift Container Platform クラスターの選択した namespace で利用可能にします。
手動 の承認ストラテジーを選択している場合、サブスクリプションのアップグレードステータスは、そのインストール計画を確認し、承認するまで Upgrading のままになります。
Install Plan ページでの承認後に、サブスクリプションのアップグレードステータスは Up to date に移行します。
- 自動 の承認ストラテジーを選択している場合、アップグレードステータスは、介入なしに Up to date に解決するはずです。
検証
サブスクリプションのアップグレードステータスが Up to date になった後に、Operators → Installed Operators を選択し、インストールされた Operator のクラスターサービスバージョン (CSV) が表示されることを確認します。Status は、関連する namespace で最終的に Succeeded に解決されるはずです。
注記All namespaces… インストールモードの場合、ステータスは
openshift-operators
namespace で Succeeded になりますが、他の namespace でチェックする場合、ステータスは Copied になります。上記通りにならない場合、以下を実行します。
-
さらにトラブルシューティングを行うために問題を報告している Workloads → Pods ページで、
openshift-operators
プロジェクト (または A specific namespace… インストールモードが選択されている場合は他の関連の namespace) の Pod のログを確認します。
-
さらにトラブルシューティングを行うために問題を報告している Workloads → Pods ページで、
Operator をインストールすると、メタデータに、インストールされているチャネルとバージョンが示されます。
注記ドロップダウンメニュー Channel および Version は、このカタログコンテキストで他のバージョンのメタデータを表示するために引き続き使用できます。
3.2.4. CLI を使用して OperatorHub からインストールする リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用する代わりに、CLI を使用して OperatorHub から Operator をインストールできます。oc
コマンドを使用して、Subscription
オブジェクトを作成または更新します。
SingleNamespace
インストールモードの場合は、関連する namespace に適切な Operator グループが存在することも確認する必要があります。OperatorGroup
で定義される Operator グループは、Operator グループと同じ namespace 内のすべての Operator に必要な RBAC アクセスを生成するターゲット namespace を選択します。
ほとんどの場合は、この手順の Web コンソール方式が推奨されます。これは、SingleNamespace
モードを選択したときに OperatorGroup
オブジェクトおよび Subscription
オブジェクトの作成を自動的に処理するなど、バックグラウンドでタスクが自動化されるためです。
前提条件
- Operator インストール権限を持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
-
OpenShift CLI (
oc
) がインストールされている。
手順
OperatorHub からクラスターで利用できる Operator のリストを表示します。
oc get packagemanifests -n openshift-marketplace
$ oc get packagemanifests -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例3.1 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要な Operator のカタログをメモします。
必要な Operator を検査して、サポートされるインストールモードおよび利用可能なチャネルを確認します。
oc describe packagemanifests <operator_name> -n openshift-marketplace
$ oc describe packagemanifests <operator_name> -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例3.2 出力例
ヒント次のコマンドを実行すると、Operator のバージョンとチャネル情報を YAML 形式で出力できます。
oc get packagemanifests <operator_name> -n <catalog_namespace> -o yaml
$ oc get packagemanifests <operator_name> -n <catalog_namespace> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace に複数のカタログがインストールされている場合は、次のコマンドを実行して、特定のカタログから Operator の使用可能なバージョンとチャネルを検索します。
oc get packagemanifest \ --selector=catalog=<catalogsource_name> \ --field-selector metadata.name=<operator_name> \ -n <catalog_namespace> -o yaml
$ oc get packagemanifest \ --selector=catalog=<catalogsource_name> \ --field-selector metadata.name=<operator_name> \ -n <catalog_namespace> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要Operator のカタログを指定しない場合、
oc get packagemanifest
およびoc describe packagemanifest
コマンドを実行すると、次の条件が満たされると予期しないカタログからパッケージが返される可能性があります。- 複数のカタログが同じ namespace にインストールされます。
- カタログには、同じ Operator、または同じ名前の Operator が含まれています。
インストールする Operator が
AllNamespaces
インストールモードをサポートしており、このモードを使用することを選択した場合は、openshift-operators
namespace にglobal-operators
と呼ばれる適切な Operator グループがデフォルトですでに配置されているため、この手順をスキップしてください。インストールする Operator が
SingleNamespace
インストールモードをサポートしており、このモードを使用することを選択した場合は、関連する namespace に適切な Operator グループが存在することを確認する必要があります。存在しない場合は、次の手順に従って作成できます。重要namespace ごとに Operator グループを 1 つだけ持つことができます。詳細は、「Operator グループ」を参照してください。
SingleNamespace
インストールモード用に、OperatorGroup
オブジェクト YAML ファイル (例:operatorgroup.yaml
) を作成します。SingleNamespace
インストールモードのOperatorGroup
オブジェクトの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroup
オブジェクトを作成します。oc apply -f operatorgroup.yaml
$ oc apply -f operatorgroup.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
namespace を Operator にサブスクライブするための
Subscription
オブジェクトを作成します。Subscription
オブジェクトの YAML ファイル (例:subscription.yaml
) を作成します。注記特定のバージョンの Operator をサブスクライブする場合は、
startingCSV
フィールドを目的のバージョンに設定し、installPlanApproval
フィールドをManual
に設定して、カタログに新しいバージョンが存在する場合に Operator が自動的にアップグレードされないようにします。詳細は、次の「特定の開始 Operator バージョンを持つSubscription
オブジェクトの例」を参照してください。例3.3
Subscription
オブジェクトの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- デフォルトの
AllNamespaces
インストールモードの使用は、openshift-operators
namespace を指定します。カスタムグローバル namespace を作成している場合はこれを指定できます。SingleNamespace
インストールモードを使用する場合は、関連する単一の namespace を指定します。 - 2
- サブスクライブするチャネルの名前。
- 3
- サブスクライブする Operator の名前。
- 4
- Operator を提供するカタログソースの名前。
- 5
- カタログソースの namespace。デフォルトの OperatorHub カタログソースには
openshift-marketplace
を使用します。 - 6
env
パラメーターは、OLM によって作成される Pod のすべてのコンテナーに存在する必要がある環境変数の一覧を定義します。- 7
envFrom
パラメーターは、コンテナーの環境変数に反映するためのソースの一覧を定義します。- 8
volumes
パラメーターは、OLM によって作成される Pod に存在する必要があるボリュームの一覧を定義します。- 9
volumeMounts
パラメーターは、OLM によって作成される Pod のすべてのコンテナーに存在する必要があるボリュームマウントの一覧を定義します。存在しないvolume
をvolumeMount
が参照すると、OLM が Operator のデプロイに失敗します。- 10
tolerations
パラメーターは、OLM によって作成される Pod の toleration の一覧を定義します。- 11
resources
パラメーターは、OLM によって作成される Pod のすべてのコンテナーのリソース制約を定義します。- 12
nodeSelector
パラメーターは、OLM によって作成される Pod のNodeSelector
を定義します。
Amazon Web Services (AWS) Security Token Service (STS)、Microsoft Entra Workload ID、Google Cloud Platform Workload Identity など、トークン認証が有効なクラウドプロバイダー上のクラスターの場合は、次の手順に従って
Subscription
オブジェクトを設定します。Subscription
オブジェクトが手動更新承認に設定されていることを確認します。例3.5 更新の手動承認を使用した
Subscription
オブジェクトの例kind: Subscription # ... spec: installPlanApproval: Manual
kind: Subscription # ... spec: installPlanApproval: Manual
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 更新の自動承認を使用したサブスクリプションは推奨されません。更新前に権限の変更が必要な場合があるためです。更新の手動承認を使用したサブスクリプションであれば、管理者が新しいバージョンの権限を確認し、必要な手順を実行してから更新できます。
関連するクラウドプロバイダー固有のフィールドを
Subscription
オブジェクトのconfig
セクションに含めます。クラスターが AWS STS モードの場合は、次のフィールドを含めます。
例3.6 AWS STS の変数を使用した
Subscription
オブジェクトの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ロール ARN の詳細を含めます。
クラスターが Workload ID モードの場合は、次のフィールドを含めます。
例3.7 Workload ID の変数を使用した
Subscription
オブジェクトの例クラスターが GCP Workload Identity モードの場合は、次のフィールドを含めます。
例3.8 GCP Workload Identity の変数を使用した
Subscription
オブジェクトの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<audience>
AUDIENCE
値は、管理者が GCP Workload Identity を設定するときに GCP で作成し、次の形式で事前にフォーマットした URL である必要があります。//iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/<pool_id>/providers/<provider_id>
//iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/<pool_id>/providers/<provider_id>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <service_account_email>
SERVICE_ACCOUNT_EMAIL
値は、Operator 操作中に権限を借用する GCP サービスアカウントのメールアドレスです。次に例を示します。<service_account_name>@<project_id>.iam.gserviceaccount.com
<service_account_name>@<project_id>.iam.gserviceaccount.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
以下のコマンドを実行して
Subscription
オブジェクトを作成します。oc apply -f subscription.yaml
$ oc apply -f subscription.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
installPlanApproval
フィールドをManual
に設定する場合は、保留中のインストールプランを手動で承認して Operator のインストールを完了します。詳細は、「保留中の Operator 更新の手動による承認」を参照してください。
この時点で、OLM は選択した Operator を認識します。Operator のクラスターサービスバージョン (CSV) はターゲット namespace に表示され、Operator で指定される API は作成用に利用可能になります。
検証
次のコマンドを実行して、インストールされている Operator の
Subscription
オブジェクトのステータスを確認します。oc describe subscription <subscription_name> -n <namespace>
$ oc describe subscription <subscription_name> -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SingleNamespace
インストールモードの Operator グループを作成した場合は、次のコマンドを実行してOperatorGroup
オブジェクトのステータスを確認します。oc describe operatorgroup <operatorgroup_name> -n <namespace>
$ oc describe operatorgroup <operatorgroup_name> -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第4章 管理者タスク リンクのコピーリンクがクリップボードにコピーされました!
4.1. クラスターへの Operator の追加 リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) を使用して、クラスター管理者は OLM ベースの Operator を OpenShift Container Platform クラスターにインストールできます。
OLM が同一 namespace に配置されたインストール済み Operator の更新を処理する方法や、カスタムグローバル Operator グループで Operator をインストールする別の方法は、マルチテナント対応と Operator のコロケーション を参照してください。
4.1.1. OperatorHub を使用した Operator のインストールについて リンクのコピーリンクがクリップボードにコピーされました!
OperatorHub は Operator を検出するためのユーザーインターフェイスです。これは Operator Lifecycle Manager (OLM) と連携し、クラスター上で Operator をインストールし、管理します。
クラスター管理者は、OpenShift Container Platform Web コンソールまたは CLI を使用して OperatorHub から Operator をインストールできます。Operator を 1 つまたは複数の namespace にサブスクライブし、Operator をクラスター上で開発者が使用できるようにできます。
インストール時に、Operator の以下の初期設定を判別する必要があります。
- インストールモード
- All namespaces on the cluster (default) を選択して Operator をすべての namespace にインストールするか、(利用可能な場合は) 個別の namespace を選択し、選択された namespace のみに Operator をインストールします。この例では、All namespaces… を選択し、Operator をすべてのユーザーおよびプロジェクトで利用可能にします。
- 更新チャネル
- Operator が複数のチャネルで利用可能な場合、サブスクライブするチャネルを選択できます。たとえば、(利用可能な場合に) stable チャネルからデプロイするには、これをリストから選択します。
- 承認ストラテジー
自動 (Automatic) または手動 (Manual) のいずれかの更新を選択します。
インストールされた Operator に自動更新を選択する場合、Operator の新規バージョンが選択されたチャネルで利用可能になると、Operator Lifecycle Manager (OLM) は人の介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。
手動更新を選択する場合、Operator の新規バージョンが利用可能になると、OLM は更新要求を作成します。クラスター管理者は、Operator が新規バージョンに更新されるように更新要求を手動で承認する必要があります。
4.1.2. Web コンソールを使用して OperatorHub からインストールする リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して OperatorHub から Operator をインストールし、これをサブスクライブできます。
前提条件
-
cluster-admin
権限を持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
手順
- Web コンソールで、Operators → OperatorHub ページに移動します。
スクロールするか、キーワードを Filter by keyword ボックスに入力し、必要な Operator を見つけます。たとえば、Advanced Cluster Management for Kubernetes Operator を検索するには
advanced
を入力します。また、インフラストラクチャー機能 でオプションをフィルターすることもできます。たとえば、非接続環境 (ネットワークが制限された環境ともしても知られる) で機能する Operator を表示するには、Disconnected を選択します。
Operator を選択して、追加情報を表示します。
注記コミュニティー Operator を選択すると、Red Hat がコミュニティー Operator を認定していないことを警告します。続行する前に警告を確認する必要があります。
- Operator の情報を確認してから、Install をクリックします。
Install Operator ページで、Operator のインストールを設定します。
特定のバージョンの Operator をインストールする場合は、リストから Update channel と Version を選択します。Operator のすべてのチャネルから Operator のさまざまなバージョンを参照し、そのチャネルとバージョンのメタデータを表示して、インストールする正確なバージョンを選択できます。
注記バージョン選択のデフォルトは、選択したチャネルの最新バージョンです。チャネルの最新バージョンが選択されている場合は、自動 承認戦略がデフォルトで有効になります。それ以外の場合、選択したチャネルの最新バージョンをインストールしない場合は、手動 による承認が必要です。
手動 承認を使用して Operator をインストールすると、namespace 内にインストールされたすべての Operator が 手動 承認戦略で機能し、すべての Operator が一緒に更新されます。Operator を個別に更新する場合は、Operator を別の namespace にインストールします。
Operator のインストールモードを確認します。
-
All namespaces on the cluster (default) は、デフォルトの
openshift-operators
namespace で Operator をインストールし、クラスターのすべての namespace を監視し、Operator をこれらの namespace に対して利用可能にします。このオプションは常に選択可能です。 - A specific namespace on the cluster では、Operator をインストールする特定の単一 namespace を選択できます。Operator は監視のみを実行し、この単一 namespace で使用されるように利用可能になります。
-
All namespaces on the cluster (default) は、デフォルトの
トークン認証が有効になっているクラウドプロバイダー上のクラスターの場合:
- クラスターで AWS Security Token Service (Web コンソールの STS Mode) を使用する場合は、role ARN フィールドに、サービスアカウントの AWS IAM ロールの Amazon Resource Name (ARN) を入力します。ロールの ARN を作成するには、AWS アカウントの準備 で説明されている手順に従います。
- クラスターで Microsoft Entra Workload ID (Web コンソールの Workload Identity / Federated Identity Mode) を使用する場合は、適切なフィールドに、クライアント ID、テナント ID、サブスクリプション ID を追加します。
- クラスターで Google Cloud Platform Workload Identity (Web コンソールの GCP Workload Identity / Federated Identity Mode) を使用する場合は、適切なフィールドに、プロジェクト番号、プール ID、プロバイダー ID、サービスアカウントのメールアドレスを追加します。
Update approval で、承認ストラテジー Automatic または Manual を選択します。
重要Web コンソールに、クラスターが AWS STS、Microsoft Entra Workload ID、または GCP Workload Identity を使用していることが示されている場合は、Update approval を Manual に設定する必要があります。
更新の自動承認を使用したサブスクリプションは推奨されません。更新前に権限の変更が必要な場合があるためです。更新の手動承認を使用したサブスクリプションであれば、管理者が新しいバージョンの権限を確認し、必要な手順を実行してから更新できます。
Install をクリックし、Operator をこの OpenShift Container Platform クラスターの選択した namespace で利用可能にします。
手動 の承認ストラテジーを選択している場合、サブスクリプションのアップグレードステータスは、そのインストール計画を確認し、承認するまで Upgrading のままになります。
Install Plan ページでの承認後に、サブスクリプションのアップグレードステータスは Up to date に移行します。
- 自動 の承認ストラテジーを選択している場合、アップグレードステータスは、介入なしに Up to date に解決するはずです。
検証
サブスクリプションのアップグレードステータスが Up to date になった後に、Operators → Installed Operators を選択し、インストールされた Operator のクラスターサービスバージョン (CSV) が表示されることを確認します。Status は、関連する namespace で最終的に Succeeded に解決されるはずです。
注記All namespaces… インストールモードの場合、ステータスは
openshift-operators
namespace で Succeeded になりますが、他の namespace でチェックする場合、ステータスは Copied になります。上記通りにならない場合、以下を実行します。
-
さらにトラブルシューティングを行うために問題を報告している Workloads → Pods ページで、
openshift-operators
プロジェクト (または A specific namespace… インストールモードが選択されている場合は他の関連の namespace) の Pod のログを確認します。
-
さらにトラブルシューティングを行うために問題を報告している Workloads → Pods ページで、
Operator をインストールすると、メタデータに、インストールされているチャネルとバージョンが示されます。
注記ドロップダウンメニュー Channel および Version は、このカタログコンテキストで他のバージョンのメタデータを表示するために引き続き使用できます。
4.1.3. CLI を使用して OperatorHub からインストールする リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用する代わりに、CLI を使用して OperatorHub から Operator をインストールできます。oc
コマンドを使用して、Subscription
オブジェクトを作成または更新します。
SingleNamespace
インストールモードの場合は、関連する namespace に適切な Operator グループが存在することも確認する必要があります。OperatorGroup
で定義される Operator グループは、Operator グループと同じ namespace 内のすべての Operator に必要な RBAC アクセスを生成するターゲット namespace を選択します。
ほとんどの場合は、この手順の Web コンソール方式が推奨されます。これは、SingleNamespace
モードを選択したときに OperatorGroup
オブジェクトおよび Subscription
オブジェクトの作成を自動的に処理するなど、バックグラウンドでタスクが自動化されるためです。
前提条件
-
cluster-admin
権限を持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
OperatorHub からクラスターで利用できる Operator のリストを表示します。
oc get packagemanifests -n openshift-marketplace
$ oc get packagemanifests -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例4.1 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要な Operator のカタログをメモします。
必要な Operator を検査して、サポートされるインストールモードおよび利用可能なチャネルを確認します。
oc describe packagemanifests <operator_name> -n openshift-marketplace
$ oc describe packagemanifests <operator_name> -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例4.2 出力例
ヒント次のコマンドを実行すると、Operator のバージョンとチャネル情報を YAML 形式で出力できます。
oc get packagemanifests <operator_name> -n <catalog_namespace> -o yaml
$ oc get packagemanifests <operator_name> -n <catalog_namespace> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace に複数のカタログがインストールされている場合は、次のコマンドを実行して、特定のカタログから Operator の使用可能なバージョンとチャネルを検索します。
oc get packagemanifest \ --selector=catalog=<catalogsource_name> \ --field-selector metadata.name=<operator_name> \ -n <catalog_namespace> -o yaml
$ oc get packagemanifest \ --selector=catalog=<catalogsource_name> \ --field-selector metadata.name=<operator_name> \ -n <catalog_namespace> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要Operator のカタログを指定しない場合、
oc get packagemanifest
およびoc describe packagemanifest
コマンドを実行すると、次の条件が満たされると予期しないカタログからパッケージが返される可能性があります。- 複数のカタログが同じ namespace にインストールされます。
- カタログには、同じ Operator、または同じ名前の Operator が含まれています。
インストールする Operator が
AllNamespaces
インストールモードをサポートしており、このモードを使用することを選択した場合は、openshift-operators
namespace にglobal-operators
と呼ばれる適切な Operator グループがデフォルトですでに配置されているため、この手順をスキップしてください。インストールする Operator が
SingleNamespace
インストールモードをサポートしており、このモードを使用することを選択した場合は、関連する namespace に適切な Operator グループが存在することを確認する必要があります。存在しない場合は、次の手順に従って作成できます。重要namespace ごとに Operator グループを 1 つだけ持つことができます。詳細は、「Operator グループ」を参照してください。
SingleNamespace
インストールモード用に、OperatorGroup
オブジェクト YAML ファイル (例:operatorgroup.yaml
) を作成します。SingleNamespace
インストールモードのOperatorGroup
オブジェクトの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroup
オブジェクトを作成します。oc apply -f operatorgroup.yaml
$ oc apply -f operatorgroup.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
namespace を Operator にサブスクライブするための
Subscription
オブジェクトを作成します。Subscription
オブジェクトの YAML ファイル (例:subscription.yaml
) を作成します。注記特定のバージョンの Operator をサブスクライブする場合は、
startingCSV
フィールドを目的のバージョンに設定し、installPlanApproval
フィールドをManual
に設定して、カタログに新しいバージョンが存在する場合に Operator が自動的にアップグレードされないようにします。詳細は、次の「特定の開始 Operator バージョンを持つSubscription
オブジェクトの例」を参照してください。例4.3
Subscription
オブジェクトの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- デフォルトの
AllNamespaces
インストールモードの使用は、openshift-operators
namespace を指定します。カスタムグローバル namespace を作成している場合はこれを指定できます。SingleNamespace
インストールモードを使用する場合は、関連する単一の namespace を指定します。 - 2
- サブスクライブするチャネルの名前。
- 3
- サブスクライブする Operator の名前。
- 4
- Operator を提供するカタログソースの名前。
- 5
- カタログソースの namespace。デフォルトの OperatorHub カタログソースには
openshift-marketplace
を使用します。 - 6
env
パラメーターは、OLM によって作成される Pod のすべてのコンテナーに存在する必要がある環境変数の一覧を定義します。- 7
envFrom
パラメーターは、コンテナーの環境変数に反映するためのソースの一覧を定義します。- 8
volumes
パラメーターは、OLM によって作成される Pod に存在する必要があるボリュームの一覧を定義します。- 9
volumeMounts
パラメーターは、OLM によって作成される Pod のすべてのコンテナーに存在する必要があるボリュームマウントの一覧を定義します。存在しないvolume
をvolumeMount
が参照すると、OLM が Operator のデプロイに失敗します。- 10
tolerations
パラメーターは、OLM によって作成される Pod の toleration の一覧を定義します。- 11
resources
パラメーターは、OLM によって作成される Pod のすべてのコンテナーのリソース制約を定義します。- 12
nodeSelector
パラメーターは、OLM によって作成される Pod のNodeSelector
を定義します。
Amazon Web Services (AWS) Security Token Service (STS)、Microsoft Entra Workload ID、Google Cloud Platform Workload Identity など、トークン認証が有効なクラウドプロバイダー上のクラスターの場合は、次の手順に従って
Subscription
オブジェクトを設定します。Subscription
オブジェクトが手動更新承認に設定されていることを確認します。例4.5 更新の手動承認を使用した
Subscription
オブジェクトの例kind: Subscription # ... spec: installPlanApproval: Manual
kind: Subscription # ... spec: installPlanApproval: Manual
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 更新の自動承認を使用したサブスクリプションは推奨されません。更新前に権限の変更が必要な場合があるためです。更新の手動承認を使用したサブスクリプションであれば、管理者が新しいバージョンの権限を確認し、必要な手順を実行してから更新できます。
関連するクラウドプロバイダー固有のフィールドを
Subscription
オブジェクトのconfig
セクションに含めます。クラスターが AWS STS モードの場合は、次のフィールドを含めます。
例4.6 AWS STS の変数を使用した
Subscription
オブジェクトの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ロール ARN の詳細を含めます。
クラスターが Workload ID モードの場合は、次のフィールドを含めます。
例4.7 Workload ID の変数を使用した
Subscription
オブジェクトの例クラスターが GCP Workload Identity モードの場合は、次のフィールドを含めます。
例4.8 GCP Workload Identity の変数を使用した
Subscription
オブジェクトの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<audience>
AUDIENCE
値は、管理者が GCP Workload Identity を設定するときに GCP で作成し、次の形式で事前にフォーマットした URL である必要があります。//iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/<pool_id>/providers/<provider_id>
//iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/<pool_id>/providers/<provider_id>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <service_account_email>
SERVICE_ACCOUNT_EMAIL
値は、Operator 操作中に権限を借用する GCP サービスアカウントのメールアドレスです。次に例を示します。<service_account_name>@<project_id>.iam.gserviceaccount.com
<service_account_name>@<project_id>.iam.gserviceaccount.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
以下のコマンドを実行して
Subscription
オブジェクトを作成します。oc apply -f subscription.yaml
$ oc apply -f subscription.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
installPlanApproval
フィールドをManual
に設定する場合は、保留中のインストールプランを手動で承認して Operator のインストールを完了します。詳細は、「保留中の Operator 更新の手動による承認」を参照してください。
この時点で、OLM は選択した Operator を認識します。Operator のクラスターサービスバージョン (CSV) はターゲット namespace に表示され、Operator で指定される API は作成用に利用可能になります。
検証
次のコマンドを実行して、インストールされている Operator の
Subscription
オブジェクトのステータスを確認します。oc describe subscription <subscription_name> -n <namespace>
$ oc describe subscription <subscription_name> -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SingleNamespace
インストールモードの Operator グループを作成した場合は、次のコマンドを実行してOperatorGroup
オブジェクトのステータスを確認します。oc describe operatorgroup <operatorgroup_name> -n <namespace>
$ oc describe operatorgroup <operatorgroup_name> -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.4. マルチテナントクラスター用の Operator の複数インスタンスの準備 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、マルチテナントクラスターで使用する Operator の複数のインスタンスを追加できます。これは、最小特権の原則に違反していると見なされる標準の All namespaces インストールモード、または広く採用されていない Multinamespace モードのいずれかを使用する代替ソリューションです。詳細は、「マルチテナントクラスター内の Operator」を参照してください。
次の手順では、テナント は、デプロイされた一連のワークロードに対する共通のアクセス権と特権を共有するユーザーまたはユーザーのグループです。テナント Operator は、そのテナントのみによる使用を意図した Operator のインスタンスです。
前提条件
インストールする Operator のすべてのインスタンスは、特定のクラスター全体で同じバージョンである必要があります。
重要この制限およびその他の制限の詳細は、「マルチテナントクラスター内の Operator」を参照してください。
手順
Operator をインストールする前に、テナントの namespace とは別のテナント Operator の namespace を作成します。たとえば、テナントの namespace が
team1
の場合、team1-operator
namespace を作成できます。Namespace
リソースを定義し、YAML ファイル (例:team1-operator.yaml
) を保存します。apiVersion: v1 kind: Namespace metadata: name: team1-operator
apiVersion: v1 kind: Namespace metadata: name: team1-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して namespace を作成します。
oc create -f team1-operator.yaml
$ oc create -f team1-operator.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
spec.targetNamespaces
リストにその 1 つの namespace エントリーのみを使用して、テナントの namespace をスコープとするテナント Operator の Operator グループを作成します。OperatorGroup
リソースを定義し、YAML ファイル (例:team1-operatorgroup.yaml
) を保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して Operator グループを作成します。
oc create -f team1-operatorgroup.yaml
$ oc create -f team1-operatorgroup.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
テナント Operator namespace に Operator をインストールします。このタスクは、CLI の代わりに Web コンソールで OperatorHub を使用することにより、より簡単に実行できます。詳細な手順は、「Web コンソールを使用した OperatorHub からのインストール」を参照してください。
注記Operator のインストールが完了すると、Operator はテナントの Operator namespace に存在し、テナントの namespace を監視しますが、Operator の Pod もそのサービスアカウントも、テナントによって表示または使用されません。
4.1.5. カスタム namespace にグローバル Operator をインストールする リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して Operator をインストールする場合、デフォルトの動作により、All namespaces インストールモードをサポートする Operator がデフォルトの openshift-operators
グローバル namespace にインストールされます。これにより、namespace 内のすべての Operator 間で共有インストールプランと更新ポリシーに関連する問題が発生する可能性があります。これらの制限の詳細は、「マルチテナント対応と Operator のコロケーション」を参照してください。
クラスター管理者は、カスタムグローバル namespace を作成し、その namespace を使用して、個々のまたは範囲指定された一連の Operator とその依存関係をインストールすることにより、このデフォルトの動作を手動でバイパスできます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
Operator をインストールする前に、目的の Operator をインストールするための namespace を作成します。このインストール namespace は、カスタムグローバル namespace になります。
Namespace
リソースを定義し、YAML ファイル (例:global-operators.yaml
) を保存します。apiVersion: v1 kind: Namespace metadata: name: global-operators
apiVersion: v1 kind: Namespace metadata: name: global-operators
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して namespace を作成します。
oc create -f global-operators.yaml
$ oc create -f global-operators.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
すべての namespace を監視する Operator グループである、カスタム global Operator group を作成します。
OperatorGroup
リソースを定義し、global-operatorgroup.yaml
などの YAML ファイルを保存します。spec.selector
フィールドとspec.targetNamespaces
フィールドの両方を省略して、すべての namespace を選択する global Operator group にします。apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: global-operatorgroup namespace: global-operators
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: global-operatorgroup namespace: global-operators
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記作成されたグローバル Operator グループの
status.namespaces
には、空の文字列 (""
) が含まれています。これは、すべての namespace を監視する必要があることを消費する Operator に通知します。以下のコマンドを実行して Operator グループを作成します。
oc create -f global-operatorgroup.yaml
$ oc create -f global-operatorgroup.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
必要な Operator をカスタムのグローバル namespace にインストールします。Web コンソールでは、Operator のインストール時に、カスタムのグローバル namespace が Installed Namespace メニューに追加されません。そのため、このインストールタスクを実行するには、OpenShift CLI (
oc
) を使用する必要があります。詳細なインストール手順は、「CLI を使用して OperatorHub からインストールする」を参照してください。注記Operator のインストールを開始すると、Operator に依存関係がある場合、その依存関係もカスタムグローバル namespace に自動的にインストールされます。その結果、依存関係 Operator が同じ更新ポリシーと共有インストールプランを持つことが有効になります。
4.1.6. Operator ワークロードの Pod の配置 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトで、Operator Lifecycle Manager (OLM) は、Operator のインストールまたはオペランドのワークロードのデプロイ時に Pod を任意のワーカーノードに配置します。管理者は、ノードセレクター、taint、および toleration の組み合わせを持つプロジェクトを使用して、Operator およびオペランドの特定のノードへの配置を制御できます。
Operator およびオペランドワークロードの Pod 配置の制御には以下の前提条件があります。
-
要件に応じて Pod のターゲットとするノードまたはノードのセットを判別します。利用可能な場合は、単数または複数のノードを特定する
node-role.kubernetes.io/app
などの既存ラベルをメモします。それ以外の場合は、コンピュートマシンセットを使用するか、ノードを直接編集して、myoperator
などのラベルを追加します。このラベルは、後のステップでプロジェクトのノードセレクターとして使用します。 -
関連しないワークロードを他のノードに向けつつ、特定のラベルの付いた Pod のみがノードで実行されるようにする必要がある場合、コンピュートマシンセットを使用するか、ノードを直接編集して taint をノードに追加します。taint に一致しない新規 Pod がノードにスケジュールされないようにする effect を使用します。たとえば、
myoperator:NoSchedule
taint は、taint に一致しない新規 Pod がノードにスケジュールされないようにしますが、ノードの既存 Pod はそのまま残ります。 - デフォルトのノードセレクターで設定され、taint を追加している場合に一致する toleration を持つプロジェクトを作成します。
この時点で、作成したプロジェクトでは、以下のシナリオの場合に指定されたノードに Pod を導くことができます。
- Operator Pod の場合
-
管理者は、次のセクションで説明するように、プロジェクトに
Subscription
オブジェクトを作成できます。その結果、Operator Pod は指定されたノードに配置されます。 - オペランド Pod の場合
- インストールされた Operator を使用して、ユーザーはプロジェクトにアプリケーションを作成できます。これにより、Operator が所有するカスタムリソース (CR) がプロジェクトに置かれます。その結果、Operator が他の namespace にクラスター全体のオブジェクトまたはリソースをデプロイしない限り、オペランド Pod は指定されたノードに配置されます。この場合、このカスタマイズされた Pod の配置は適用されません。
4.1.7. Operator のインストール場所の制御 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、Operator をインストールすると、OpenShift Container Platform は Operator Pod をワーカーノードの 1 つにランダムにインストールします。ただし、特定のノードまたはノードのセットでその Pod をスケジュールする必要がある場合があります。
以下の例では、Operator Pod を特定のノードまたはノードのセットにスケジュールする状況を説明します。
-
Operator が
amd64
やarm64
などの特定のプラットフォームを必要とする場合 - オペレータが Linux や Windows などの特定のオペレーティングシステムを必要とする場合
- 同じホストまたは同じラックに配置されたホストでスケジュールされた一緒に動作する Operator が必要な場合
- ネットワークまたはハードウェアの問題によるダウンタイムを回避するために、Operator をインフラストラクチャー全体に分散させたい場合
Operator の Subscription
オブジェクトにノードアフィニティー、Pod アフィニティー、または Pod 非アフィニティー制約を追加することで、Operator Pod がインストールされる場所を制御できます。ノードアフィニティーは、Pod の配置場所を判別するためにスケジューラーによって使用されるルールのセットです。Pod アフィニティーを使用すると、関連する Pod が同じノードにスケジュールされていることを確認できます。Pod 非アフィニティーを使用すると、ノードで Pod がスケジュールされないようにすることができます。
次の例は、ノードアフィニティーまたは Pod 非アフィニティーを使用して、Custom Metrics Autoscaler Operator のインスタンスをクラスター内の特定のノードにインストールする方法を示しています。
Operator Pod を特定のノードに配置するノードアフィニティーの例
- 1
- Operator の Pod を
ip-10-0-163-94.us-west-2.compute.internal
という名前のノードでスケジュールする必要があるノードアフィニティー。
Operator Pod を特定のプラットフォームのノードに配置するノードアフィニティーの例
- 1
- Operator の Pod を
kubernetes.io/arch=arm64
およびkubernetes.io/os=linux
ラベルを持つノードでスケジュールする必要があるノードアフィニティー。
Operator Pod を 1 つ以上の特定のノードに配置する Pod アフィニティーの例
- 1
app=test
ラベルを持つ Pod を持つノードに Operator の Pod を配置する Pod アフィニティー。
Operator Pod が 1 つ以上の特定のノードからアクセスできないようにする Pod 非アフィニティーの例
- 1
- Operator の Pod が
cpu=high
ラベルの Pod を持つノードでスケジュールされないようにする Pod 非アフィニティー。
手順
Operator Pod の配置を制御するには、次の手順を実行します。
- 通常どおり Operator をインストールします。
- 必要に応じて、ノードがアフィニティーに適切に応答するようにラベル付けされていることを確認してください。
Operator
Subscription
オブジェクトを編集してアフィニティーを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
nodeAffinity
、podAffinity
、またはpodAntiAffinity
を追加します。アフィニティーの作成は、以下のその他のリソースセクションを参照してください。
検証
Pod が特定のノードにデプロイされていることを確認するには、次のコマンドを実行します。
$ oc get pods -o wide
$ oc get pods -o wide
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES custom-metrics-autoscaler-operator-5dcc45d656-bhshg 1/1 Running 0 50s 10.131.0.20 ip-10-0-185-229.ec2.internal <none> <none>
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES custom-metrics-autoscaler-operator-5dcc45d656-bhshg 1/1 Running 0 50s 10.131.0.20 ip-10-0-185-229.ec2.internal <none> <none>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2. インストール済み Operator の更新 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、OpenShift Container Platform クラスターで Operator Lifecycle Manager (OLM) を使用し、以前にインストールされた Operator を更新できます。
OLM が同一 namespace に配置されたインストール済み Operator の更新を処理する方法や、カスタムグローバル Operator グループで Operator をインストールする別の方法は、マルチテナント対応と Operator のコロケーション を参照してください。
4.2.1. Operator 更新の準備 リンクのコピーリンクがクリップボードにコピーされました!
インストールされた Operator のサブスクリプションは、Operator の更新を追跡および受信する更新チャネルを指定します。更新チャネルを変更して、新しいチャネルからの更新の追跡と受信を開始できます。
サブスクリプションの更新チャネルの名前は Operator 間で異なる可能性がありますが、命名スキーム通常、特定の Operator 内の共通の規則に従います。たとえば、チャネル名は Operator によって提供されるアプリケーションのマイナーリリース更新ストリーム (1.2
、1.3
) またはリリース頻度 (stable
、fast
) に基づく可能性があります。
インストールされた Operator は、現在のチャネルよりも古いチャネルに切り換えることはできません。
Red Hat Customer Portal Labs には、管理者が Operator の更新を準備するのに役立つ以下のアプリケーションが含まれています。
このアプリケーションを使用して、Operator Lifecycle Manager ベースの Operator を検索し、OpenShift Container Platform の異なるバージョン間で更新チャネルごとに利用可能な Operator バージョンを確認できます。Cluster Version Operator ベースの Operator は含まれません。
4.2.2. Operator の更新チャネルの変更 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform Web コンソールを使用して、Operator の更新チャネルを変更できます。
サブスクリプションの承認ストラテジーが Automatic に設定されている場合、アップグレードプロセスは、選択したチャネルで新規 Operator バージョンが利用可能になるとすぐに開始します。承認ストラテジーが Manual に設定されている場合は、保留中のアップグレードを手動で承認する必要があります。
前提条件
- Operator Lifecycle Manager (OLM) を使用して以前にインストールされている Operator。
手順
- Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
- 更新チャネルを変更する Operator の名前をクリックします。
- Subscription タブをクリックします。
- Update channel の下にある更新チャネルの名前をクリックします。
- 変更する新しい更新チャネルをクリックし、Save をクリックします。
Automatic 承認ストラテジーのあるサブスクリプションの場合、更新は自動的に開始します。Operators → Installed Operators ページに戻り、更新の進捗をモニターします。完了時に、ステータスは Succeeded および Up to date に変更されます。
Manual 承認ストラテジーのあるサブスクリプションの場合、Subscription タブから更新を手動で承認できます。
4.2.3. 保留中の Operator 更新の手動による承認 リンクのコピーリンクがクリップボードにコピーされました!
インストールされた Operator のサブスクリプションの承認ストラテジーが Manual に設定されている場合、新規の更新が現在の更新チャネルにリリースされると、インストールを開始する前に更新を手動で承認する必要があります。
前提条件
- Operator Lifecycle Manager (OLM) を使用して以前にインストールされている Operator。
手順
- OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
- 更新が保留中の Operator は Upgrade available のステータスを表示します。更新する Operator の名前をクリックします。
- Subscription タブをクリックします。承認が必要な更新は、Upgrade status の横に表示されます。たとえば、1 requires approval が表示される可能性があります。
- 1 requires approval をクリックしてから、Preview Install Plan をクリックします。
- 更新に利用可能なリソースとして一覧表示されているリソースを確認します。問題がなければ、Approve をクリックします。
- Operators → Installed Operators ページに戻り、更新の進捗をモニターします。完了時に、ステータスは Succeeded および Up to date に変更されます。
4.3. クラスターからの Operator の削除 リンクのコピーリンクがクリップボードにコピーされました!
以下では、OpenShift Container Platform クラスター上で Operator Lifecycle Manager (OLM) を使用して以前にインストールされた Operator を削除またはアンインストールする方法を説明します。
同じ Operator の再インストールを試行する前に、Operator を正常かつ完全にアンインストールする必要があります。Operator を適切かつ完全にアンインストールできていない場合、プロジェクトや namespace などのリソースが "Terminating" ステータスでスタックし、Operator を再インストールしようとすると "error resolving resource" メッセージが表示される可能性があります。
詳細は、アンインストール失敗後の Operator の再インストール を参照してください。
4.3.1. Web コンソールの使用によるクラスターからの Operator の削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は Web コンソールを使用して、選択した namespace からインストールされた Operator を削除できます。
前提条件
-
cluster-admin
権限を持つアカウントを使用して OpenShift Container Platform クラスター Web コンソールにアクセスできる。
手順
- Operators → Installed Operators ページに移動します。
- スクロールするか、キーワードを Filter by name フィールドに入力して、削除する Operator を見つけます。次に、それをクリックします。
Operator Details ページの右側で、Actions 一覧から Uninstall Operator を選択します。
Uninstall Operator? ダイアログボックスが表示されます。
Uninstall を選択し、Operator、Operator デプロイメント、および Pod を削除します。このアクションの後には、Operator は実行を停止し、更新を受信しなくなります。
注記このアクションは、カスタムリソース定義 (CRD) およびカスタムリソース (CR) など、Operator が管理するリソースは削除されません。Web コンソールおよび継続して実行されるクラスター外のリソースによって有効にされるダッシュボードおよびナビゲーションアイテムには、手動でのクリーンアップが必要になる場合があります。Operator のアンインストール後にこれらを削除するには、Operator CRD を手動で削除する必要があります。
4.3.2. CLI の使用によるクラスターからの Operator の削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は CLI を使用して、選択した namespace からインストールされた Operator を削除できます。
前提条件
-
cluster-admin
パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。 -
OpenShift CLI (
oc
) がワークステーションにインストールされている。
手順
サブスクライブした Operator の最新バージョン (
serverless-operator
など) が、currentCSV
フィールドで識別されていることを確認します。oc get subscription.operators.coreos.com serverless-operator -n openshift-serverless -o yaml | grep currentCSV
$ oc get subscription.operators.coreos.com serverless-operator -n openshift-serverless -o yaml | grep currentCSV
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
currentCSV: serverless-operator.v1.28.0
currentCSV: serverless-operator.v1.28.0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サブスクリプション (
serverless-operator
など) を削除します。oc delete subscription.operators.coreos.com serverless-operator -n openshift-serverless
$ oc delete subscription.operators.coreos.com serverless-operator -n openshift-serverless
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
subscription.operators.coreos.com "serverless-operator" deleted
subscription.operators.coreos.com "serverless-operator" deleted
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 直前の手順で
currentCSV
値を使用し、ターゲット namespace の Operator の CSV を削除します。oc delete clusterserviceversion serverless-operator.v1.28.0 -n openshift-serverless
$ oc delete clusterserviceversion serverless-operator.v1.28.0 -n openshift-serverless
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
clusterserviceversion.operators.coreos.com "serverless-operator.v1.28.0" deleted
clusterserviceversion.operators.coreos.com "serverless-operator.v1.28.0" deleted
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.3. 障害のあるサブスクリプションの更新 リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) で、ネットワークでアクセスできないイメージを参照する Operator をサブスクライブする場合、以下のエラーを出して失敗した openshift-marketplace
namespace でジョブを見つけることができます。
出力例
ImagePullBackOff for Back-off pulling image "example.com/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c846ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"
ImagePullBackOff for
Back-off pulling image "example.com/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c846ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"
出力例
rpc error: code = Unknown desc = error pinging docker registry example.com: Get "https://example.com/v2/": dial tcp: lookup example.com on 10.0.0.1:53: no such host
rpc error: code = Unknown desc = error pinging docker registry example.com: Get "https://example.com/v2/": dial tcp: lookup example.com on 10.0.0.1:53: no such host
その結果、サブスクリプションはこの障害のある状態のままとなり、Operator はインストールまたはアップグレードを実行できません。
サブスクリプション、クラスターサービスバージョン (CSV) その他の関連オブジェクトを削除して、障害のあるサブスクリプションを更新できます。サブスクリプションを再作成した後に、OLM は Operator の正しいバージョンを再インストールします。
前提条件
- アクセス不可能なバンドルイメージをプルできない障害のあるサブスクリプションがある。
- 正しいバンドルイメージにアクセスできることを確認している。
手順
Operator がインストールされている namespace から
Subscription
およびClusterServiceVersion
オブジェクトの名前を取得します。oc get sub,csv -n <namespace>
$ oc get sub,csv -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME PACKAGE SOURCE CHANNEL subscription.operators.coreos.com/elasticsearch-operator elasticsearch-operator redhat-operators 5.0 NAME DISPLAY VERSION REPLACES PHASE clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65 OpenShift Elasticsearch Operator 5.0.0-65 Succeeded
NAME PACKAGE SOURCE CHANNEL subscription.operators.coreos.com/elasticsearch-operator elasticsearch-operator redhat-operators 5.0 NAME DISPLAY VERSION REPLACES PHASE clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65 OpenShift Elasticsearch Operator 5.0.0-65 Succeeded
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サブスクリプションを削除します。
oc delete subscription <subscription_name> -n <namespace>
$ oc delete subscription <subscription_name> -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターサービスバージョンを削除します。
oc delete csv <csv_name> -n <namespace>
$ oc delete csv <csv_name> -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-marketplace
namespace の失敗したジョブおよび関連する config map の名前を取得します。oc get job,configmap -n openshift-marketplace
$ oc get job,configmap -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME COMPLETIONS DURATION AGE job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb 1/1 26s 9m30s NAME DATA AGE configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb 3 9m30s
NAME COMPLETIONS DURATION AGE job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb 1/1 26s 9m30s NAME DATA AGE configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb 3 9m30s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ジョブを削除します。
oc delete job <job_name> -n openshift-marketplace
$ oc delete job <job_name> -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、アクセスできないイメージのプルを試行する Pod は再作成されなくなります。
設定マップを削除します。
oc delete configmap <configmap_name> -n openshift-marketplace
$ oc delete configmap <configmap_name> -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Web コンソールの OperatorHub を使用した Operator の再インストール
検証
Operator が正常に再インストールされていることを確認します。
oc get sub,csv,installplan -n <namespace>
$ oc get sub,csv,installplan -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4. Operator Lifecycle Manager 機能の設定 リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) コントローラーは、cluster
という名前の OLMConfig
カスタムリソース (CR) で設定されます。クラスター管理者は、このリソースを変更して、特定の機能を有効または無効にすることができます。
このドキュメントでは、OLMConfig
リソースによって設定されている OLM で現在サポートされている機能を概説します。
4.4.1. コピーした CSV の無効化 リンクのコピーリンクがクリップボードにコピーされました!
Operator が Operator Lifecycle Manager (OLM) によってインストールされると、そのクラスターサービスバージョン (CSV) の簡易コピーが、Operator が監視するように設定されているすべての namespace にデフォルトで作成されます。これらの CSV は、コピーされた CSV と呼ばれ、特定の namespace でリソースイベントをアクティブに調整しているコントローラーをユーザーに通知します。
Operator が AllNamespaces
インストールモードを使用するように設定されている場合、単一または指定された一連の namespace をターゲットとするのではなく、Operator のコピーされた CSV がクラスター上のすべての namespace に作成されます。特に大規模なクラスターでは、namespace およびインストールされた Operator が数百または数千の場合に、コピーされた CSV は OLM のメモリー使用量、クラスター etcd 制限、およびネットワークなどのリソースを有効にしない量を消費する可能性があります。
これらの大規模なクラスターをサポートするために、クラスター管理者は、AllNamespaces
モードでグローバルにインストールされた Operator のコピーされた CSV を無効にすることができます。
コピーされた CSV を無効にすると、AllNamespaces
モードでインストールされた Operator の CSV は、クラスター上のすべての namespace ではなく、openshift
namespace にのみコピーされます。無効なコピー CSV モードでは、Web コンソールと CLI で動作が異なります。
-
Web コンソールでは、CSV が実際にすべての namespace にコピーされない場合でも、
openshift
namespace からコピーされた CSV をすべての namespace に表示するようにデフォルトの動作が変更されます。これにより、通常のユーザーは引き続き namespace でこれらの Operator の詳細を表示し、関連するカスタムリソース (CR) を作成できます。 OpenShift CLI (
oc
) では、通常のユーザーはoc get csvs
コマンドを使用して、ユーザーの namespace に直接インストールされた Operator を表示できます。しかし、openshift
namespace からコピーされた CSV は、ユーザーの namespace には表示されません。この制限の影響を受ける Operator は引き続き利用でき、ユーザーの namespace でイベントの調整を継続します。Web コンソールの動作と同様に、インストールされているグローバル Operator の完全なリストを表示するには、認証されたすべてのユーザーが次のコマンドを実行できます。
oc get csvs -n openshift
$ oc get csvs -n openshift
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
cluster
という名前のOLMConfig
オブジェクトを編集し、spec.features.disableCopiedCSVs
フィールドをtrue
に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
AllNamespaces
インストールモード Operator 向けのコピーされた CSV を無効にしました。
検証
コピーされた CSV が無効になっている場合には、OLM は Operator の namespace のイベントでこの情報をキャプチャします。
oc get events
$ oc get events
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
LAST SEEN TYPE REASON OBJECT MESSAGE 85s Warning DisabledCopiedCSVs clusterserviceversion/my-csv.v1.0.0 CSV copying disabled for operators/my-csv.v1.0.0
LAST SEEN TYPE REASON OBJECT MESSAGE 85s Warning DisabledCopiedCSVs clusterserviceversion/my-csv.v1.0.0 CSV copying disabled for operators/my-csv.v1.0.0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec.features.disableCopiedCSVs
フィールドが欠落しているか、false
に設定されている場合に、OLM はAllNamespaces
モードでインストールされた全 Operator 向けのコピーされた CSV を再作成し、前述のイベントを削除します。
関連情報
4.5. Operator Lifecycle Manager でのプロキシーサポートの設定 リンクのコピーリンクがクリップボードにコピーされました!
グローバルプロキシーが OpenShift Container Platform クラスターに設定されている場合、Operator Lifecycle Manager (OLM) は、クラスター全体のプロキシーで管理する Operator を自動的に設定します。ただし、インストールされた Operator をグローバルプロキシーを上書きするか、カスタム CA 証明書を挿入するように設定することもできます。
- カスタム PKI の設定 (カスタム CA 証明書)
4.5.1. Operator のプロキシー設定の上書き リンクのコピーリンクがクリップボードにコピーされました!
クラスター全体の egress プロキシーが設定されている場合、Operator Lifecycle Manager (OLM) を使用して実行する Operator は、デプロイメントでクラスター全体のプロキシー設定を継承します。クラスター管理者は、Operator のサブスクリプションを設定してこれらのプロキシー設定を上書きすることもできます。
Operator は、マネージドオペランドの Pod でのプロキシー設定の環境変数の設定を処理する必要があります。
前提条件
-
cluster-admin
権限を持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
手順
- Web コンソールで、Operators → OperatorHub ページに移動します。
- Operator を選択し、Install をクリックします。
Install Operator ページで、
Subscription
オブジェクトを変更して以下の 1 つ以上の環境変数をspec
セクションに組み込みます。-
HTTP_PROXY
-
HTTPS_PROXY
-
NO_PROXY
以下に例を示します。
プロキシー設定の上書きのある
Subscription
オブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記これらの環境変数では、以前に設定されたクラスター全体またはカスタムプロキシーの設定を削除するために空の値を使用してそれらの設定を解除することもできます。
OLM はこれらの環境変数を単位として処理します。それらの環境変数が 1 つ以上設定されている場合、それらはすべて上書きされているものと見なされ、クラスター全体のデフォルト値はサブスクライブされた Operator のデプロイメントには使用されません。
-
- Install をクリックし、Operator を選択された namespace で利用可能にします。
Operator の CSV が関連する namespace に表示されると、カスタムプロキシーの環境変数がデプロイメントに設定されていることを確認できます。たとえば、CLI を使用します。
oc get deployment -n openshift-operators \ etcd-operator -o yaml \ | grep -i "PROXY" -A 2
$ oc get deployment -n openshift-operators \ etcd-operator -o yaml \ | grep -i "PROXY" -A 2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5.2. カスタム CA 証明書の挿入 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者が設定マップを使用してカスタム CA 証明書をクラスターに追加すると、Cluster Network Operator はユーザーによってプロビジョニングされる証明書およびシステム CA 証明書を単一バンドルにマージします。このマージされたバンドルを Operator Lifecycle Manager (OLM) で実行されている Operator に挿入することができます。これは、man-in-the-middle HTTPS プロキシーがある場合に役立ちます。
前提条件
-
cluster-admin
権限を持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。 - 設定マップを使用してクラスターに追加されたカスタム CA 証明書。
- 必要な Operator が OLM にインストールされ、実行される。
手順
Operator のサブスクリプションがある namespace に空の設定マップを作成し、以下のラベルを組み込みます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この設定マップの作成後すぐに、設定マップにはマージされたバンドルの証明書の内容が設定されます。
Subscription
オブジェクトを更新し、trusted-ca
設定マップをカスタム CA を必要とする Pod 内の各コンテナーにボリュームとしてマウントするspec.config
セクションを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Operator のデプロイメントは認証局の検証に失敗し、
x509 certificate signed by unknown authority
エラーが表示される可能性があります。このエラーは、Operator のサブスクリプションの使用時にカスタム CA を挿入した後でも発生する可能性があります。この場合、Operator のサブスクリプションを使用して、trusted-ca のmountPath
を/etc/ssl/certs
として設定できます。
4.6. Operator ステータスの表示 リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) のシステムの状態を理解することは、インストールされた Operator に関する問題について意思決定を行い、デバッグを行う上で重要です。OLM は、サブスクリプションおよびそれに関連するカタログソースリソースの状態および実行されたアクションに関する知見を提供します。これは、それぞれの Operator の正常性を把握するのに役立ちます。
4.6.1. Operator サブスクリプションの状態のタイプ リンクのコピーリンクがクリップボードにコピーされました!
サブスクリプションは状態に関する以下のタイプを報告します。
状態 | 説明 |
---|---|
| 解決に使用される一部のまたはすべてのカタログソースは正常ではありません。 |
| サブスクリプションのインストール計画がありません。 |
| サブスクリプションのインストール計画はインストールの保留中です。 |
| サブスクリプションのインストール計画が失敗しました。 |
| サブスクリプションの依存関係の解決に失敗しました。 |
デフォルトの OpenShift Container Platform Cluster Operator は Cluster Version Operator (CVO) によって管理され、これらの Operator には Subscription
オブジェクトがありません。アプリケーション Operator は Operator Lifecycle Manager (OLM) によって管理され、それらには Subscription
オブジェクトがあります。
4.6.2. CLI を使用した Operator サブスクリプションステータスの表示 リンクのコピーリンクがクリップボードにコピーされました!
CLI を使用して Operator サブスクリプションステータスを表示できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
Operator サブスクリプションをリスト表示します。
oc get subs -n <operator_namespace>
$ oc get subs -n <operator_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe
コマンドを使用して、Subscription
リソースを検査します。oc describe sub <subscription_name> -n <operator_namespace>
$ oc describe sub <subscription_name> -n <operator_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンド出力で、
Conditions
セクションで Operator サブスクリプションの状態タイプのステータスを確認します。以下の例では、利用可能なすべてのカタログソースが正常であるため、CatalogSourcesUnhealthy
状態タイプのステータスはfalse
になります。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
デフォルトの OpenShift Container Platform Cluster Operator は Cluster Version Operator (CVO) によって管理され、これらの Operator には Subscription
オブジェクトがありません。アプリケーション Operator は Operator Lifecycle Manager (OLM) によって管理され、それらには Subscription
オブジェクトがあります。
4.6.3. CLI を使用した Operator カタログソースのステータス表示 リンクのコピーリンクがクリップボードにコピーされました!
Operator カタログソースのステータスは、CLI を使用して確認できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
namespace のカタログソースをリスト表示します。たとえば、クラスター全体のカタログソースに使用されている
openshift-marketplace
namespace を確認することができます。oc get catalogsources -n openshift-marketplace
$ oc get catalogsources -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY TYPE PUBLISHER AGE certified-operators Certified Operators grpc Red Hat 55m community-operators Community Operators grpc Red Hat 55m example-catalog Example Catalog grpc Example Org 2m25s redhat-operators Red Hat Operators grpc Red Hat 55m
NAME DISPLAY TYPE PUBLISHER AGE certified-operators Certified Operators grpc Red Hat 55m community-operators Community Operators grpc Red Hat 55m example-catalog Example Catalog grpc Example Org 2m25s redhat-operators Red Hat Operators grpc Red Hat 55m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow カタログソースの詳細やステータスを確認するには、
oc describe
コマンドを使用します。oc describe catalogsource example-catalog -n openshift-marketplace
$ oc describe catalogsource example-catalog -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 前述の出力例では、最後に観測された状態が
TRANSIENT_FAILURE
となっています。この状態は、カタログソースの接続確立に問題があることを示しています。カタログソースが作成された namespace の Pod をリストアップします。
oc get pods -n openshift-marketplace
$ oc get pods -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace にカタログソースを作成すると、その namespace にカタログソース用の Pod が作成されます。前述の出力例では、
example-catalog-bwt8z
Pod のステータスがImagePullBackOff
になっています。このステータスは、カタログソースのインデックスイメージのプルに問題があることを示しています。oc describe
コマンドを使用して、より詳細な情報を得るために Pod を検査します。oc describe pod example-catalog-bwt8z -n openshift-marketplace
$ oc describe pod example-catalog-bwt8z -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 前述の出力例では、エラーメッセージは、カタログソースのインデックスイメージが承認問題のために正常にプルできないことを示しています。例えば、インデックスイメージがログイン認証情報を必要とするレジストリーに保存されている場合があります。
4.7. Operator 条件の管理 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Operator Lifecycle Manager (OLM) を使用して Operator 条件を管理できます。
4.7.1. Operator 条件の上書き リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者には、Operator が報告するサポートされている Operator 条件を無視することを推奨します。Operator 条件が存在する場合、Spec.Overrides
配列の Operator 条件は Spec.Conditions
配列の条件を上書きし、これによりクラスター管理者は、Operator が Operator Lifecycle Manager (OLM) に状態を誤って報告する状況に対応することができます。
デフォルトでは、Spec.Overrides
配列は、クラスター管理者によって追加されるまで、OperatorCondition
オブジェクトには存在しません。Spec.Conditions
配列も、ユーザーが追加するか、カスタム Operator ロジックの結果として追加されるまで存在しません。
たとえば、アップグレードできないことを常に通信する Operator の既知のバージョンを考えてみましょう。この場合、Operator がアップグレードできないと通信していますが、Operator をアップグレードすることを推奨します。これは、条件の type
および status
を OperatorCondition
オブジェクトの Spec.Overrides
配列に追加して Operator 条件をオーバーライドすることによって実行できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OperatorCondition
オブジェクトを持つ Operator が OLM を使用してインストールされている。
手順
Operator の
OperatorCondition
オブジェクトを編集します。oc edit operatorcondition <name>
$ oc edit operatorcondition <name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Spec.Overrides
配列をオブジェクトに追加します。Operator 条件の上書きの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- クラスター管理者は、アップグレードの準備状態を
True
に変更できます。
4.7.2. Operator 条件を使用するための Operator の更新 リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) は、調整する ClusterServiceVersion
リソースごとに OperatorCondition
リソースを自動的に作成します。CSV のすべてのサービスアカウントには、Operator が所有する OperatorCondition
と対話するための RBAC が付与されます。
Operator の作成者は、Operator が OLM によってデプロイされた後に、独自の条件を設定できるように Operator を開発し、operator-lib
ライブラリーを使用することができます。Operator 作成者として Operator 条件を設定する方法の詳細は、Operator 条件の有効化 ページを参照してください。
4.7.2.1. デフォルトの設定 リンクのコピーリンクがクリップボードにコピーされました!
後方互換性を維持するために、OLM は OperatorCondition
リソースがない状態を条件からのオプトアウトとして扱います。そのため、Operator 条件の使用にオプトインする Operator は、Pod の ready プローブが true
に設定される前に、デフォルトの条件を設定する必要があります。これにより、Operator には、条件を正しい状態に更新するための猶予期間が与えられます。
4.8. クラスター管理者以外のユーザーによる Operator のインストールの許可 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、Operator グループ を使用して、通常のユーザーが Operator をインストールできるようにすることができます。
4.8.1. Operator インストールポリシーについて リンクのコピーリンクがクリップボードにコピーされました!
Operator の実行には幅広い権限が必要になる可能性があり、必要な権限はバージョン間で異なる場合があります。Operator Lifecycle Manager (OLM) は、cluster-admin
権限で実行されます。デフォルトで、Operator の作成者はクラスターサービスバージョン (CSV) で任意のパーミッションのセットを指定でき、OLM はこれを Operator に付与します。
Operator がクラスタースコープの権限を取得できず、ユーザーが OLM を使用して権限を昇格できないようにするために、クラスター管理者は Operator をクラスターに追加する前に手動で監査できます。また、クラスター管理者には、サービスアカウントを使用した Operator のインストールまたはアップグレード時に許可されるアクションを判別し、制限するための各種ツールが提供されます。
クラスター管理者は、一連の権限が付与されたサービスアカウントに Operator グループを関連付けることができます。サービスアカウントは、ロールベースのアクセス制御 (RBAC) ルールを使用して、事前に定義された境界内でのみ実行されるように、Operator にポリシーを設定します。その結果、Operator は、それらのルールによって明示的に許可されていないことはいずれも実行できません。
Operator グループを採用することで、十分な権限を持つユーザーは、限られた範囲で Operator をインストールできます。その結果、より多くの Operator Framework ツールをより多くのユーザーが安全に利用できるようになり、Operator を使用してアプリケーションを構築するためのより豊かなエクスペリエンスが提供されます。
Subscription
オブジェクトのロールベースのアクセス制御 (RBAC) は、namespace で edit
または admin
のロールを持つすべてのユーザーに自動的に付与されます。ただし、RBAC は OperatorGroup
オブジェクトには存在しません。この不在が、通常のユーザーが Operator をインストールできない理由です。Operator グループを事前にインストールすることで、実質的にインストール権限が付与されます。
Operator グループをサービスアカウントに関連付ける際は、次の点に注意してください。
-
APIService
およびCustomResourceDefinition
リソースは、cluster-admin
ロールを使用して OLM によって常に作成されます。Operator グループに関連付けられたサービスアカウントには、これらのリソースを作成するための権限を付与できません。 - この Operator グループに関連付けられる Operator は、指定されたサービスアカウントに付与されるパーミッションに制限されるようになりました。Operator がサービスアカウントの範囲外のアクセス許可を要求した場合、インストールは適切なエラーで失敗するため、クラスター管理者は問題をトラブルシューティングして解決できます。
4.8.1.1. インストールシナリオ リンクのコピーリンクがクリップボードにコピーされました!
Operator をクラスターでインストールまたはアップグレードできるかどうかを決定する際に、Operator Lifecycle Manager (OLM) は以下のシナリオを検討します。
- クラスター管理者は新規の Operator グループプを作成し、サービスアカウントを指定します。この Operator グループに関連付けられるすべての Operator がサービスアカウントに付与される権限に基づいてインストールされ、実行されます。
- クラスター管理者は新規の Operator グループを作成し、サービスアカウントを指定しません。OpenShift Container Platform は後方互換性を維持します。そのため、デフォルト動作はそのまま残り、Operator のインストールおよびアップグレードは許可されます。
- サービスアカウントを指定しない既存の Operator グループの場合、デフォルトの動作は残り、Operator のインストールおよびアップグレードは許可されます。
- クラスター管理者は既存の Operator グループを更新し、サービスアカウントを指定します。OLM により、既存の Operator は現在の権限で継続して実行されます。このような既存 Operator がアップグレードされる場合、これは再インストールされ、新規 Operator のようにサービスアカウントに付与される権限に基づいて実行されます。
- Operator グループで指定されるサービスアカウントは、パーミッションの追加または削除によって変更されるか、既存のサービスアカウントは新しいサービスアカウントに切り替わります。既存の Operator がアップグレードされる場合、これは再インストールされ、新規 Operator のように更新されたサービスアカウントに付与される権限に基づいて実行されます。
- クラスター管理者は、サービスアカウントを Operator グループから削除します。デフォルトの動作は残り、Operator のインストールおよびアップグレードは許可されます。
4.8.1.2. インストールワークフロー リンクのコピーリンクがクリップボードにコピーされました!
Operator グループがサービスアカウントに関連付けられ、Operator がインストールまたはアップグレードされると、Operator Lifecycle Manager (OLM) は以下のワークフローを使用します。
-
指定された
Subscription
オブジェクトは OLM によって選択されます。 - OLM はこのサブスクリプションに関連する Operator グループをフェッチします。
- OLM は Operator グループにサービスアカウントが指定されていることを判別します。
- OLM はサービスアカウントにスコープが設定されたクライアントを作成し、スコープ設定されたクライアントを使用して Operator をインストールします。これにより、Operator で要求されるパーミッションは常に Operator グループのそのサービスアカウントのパーミッションに制限されるようになります。
- OLM は CSV で指定されたパーミッションセットを使用して新規サービスアカウントを作成し、これを Operator に割り当てます。Operator は割り当てられたサービスアカウントで実行されます。
4.8.2. Operator インストールのスコープ設定 リンクのコピーリンクがクリップボードにコピーされました!
Operator の Operator Lifecycle Manager (OLM) での Operator のインストールおよびアップグレードに関するスコープ設定ルールを提供するには、サービスアカウントを Operator グループに関連付けます。
この例では、クラスター管理者は一連の Operator を指定された namespace に制限できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
新規の namespace を作成します。
例4.9
Namespace
オブジェクトを作成するコマンドの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator に必要な制限が適用されるように権限を割り当てます。これを行うには、新しく作成した指定の namespace に、新しいサービスアカウント、関連するロール、およびロールバインディングを作成する必要があります。
次のコマンドを実行してサービスアカウントを作成します。
例4.10
ServiceAccount
オブジェクトを作成するコマンドの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行してシークレットを作成します。
例4.11 有効期間の長い API トークンの
Secret
オブジェクトを作成するコマンドの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- シークレットは、有効期間の長い API トークンである必要があります。これはサービスアカウントによって使用されます。
次のコマンドを実行してロールを作成します。
警告この例では、例示目的でのみ、指定の namespace ですべての操作を実行できる権限を、ロールによってサービスアカウントに付与します。実稼働環境では、よりきめ細かい権限セットを作成する必要があります。詳細は、「粒度の細かいパーミッション」を参照してください。
例4.12
Role
およびRoleBinding
オブジェクトを作成するコマンドの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、指定の namespace に
OperatorGroup
オブジェクトを作成します。この Operator グループは指定された namespace をターゲットにし、そのテナンシーがこれに制限されるようにします。さらに、Operator グループはユーザーがサービスアカウントを指定できるようにします。例4.13
OperatorGroup
オブジェクトを作成するコマンドの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 直前のステップで作成したサービスアカウントを指定します。指定された namespace にインストールされる Operator はこの Operator グループに関連付けられ、指定されるサービスアカウントに関連付けられます。
指定された namespace で
Subscription
オブジェクトを作成し、Operator をインストールします。例4.14
Subscription
オブジェクトを作成するコマンドの例この Operator グループに関連付けられる Operator は、指定されたサービスアカウントに付与されるパーミッションに制限されます。Operator がサービスアカウントの範囲外のパーミッションを要求する場合、インストールは関連するエラーを出して失敗します。
4.8.2.1. 粒度の細かいパーミッション リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) は Operator グループで指定されたサービスアカウントを使用して、インストールされる Operator に関連する以下のリソースを作成または更新します。
-
ClusterServiceVersion
-
Subscription
-
Secret
-
ServiceAccount
-
Service
-
ClusterRole
およびClusterRoleBinding
-
Role
およびRoleBinding
Operator を指定された namespace に制限するため、クラスター管理者は以下のパーミッションをサービスアカウントに付与して起動できます。
以下のロールは一般的なサンプルであり、特定の Operator に基づいて追加のルールが必要になる可能性があります。
さらに、Operator がプルシークレットを指定する場合、以下のパーミッションも追加する必要があります。
- 1
- シークレットを OLM namespace から取得するために必要です。
4.8.3. Operator カタログのアクセス制御 リンクのコピーリンクがクリップボードにコピーされました!
Operator カタログがグローバルカタログ namespace openshift-marketplace
で作成されると、カタログの Operator がクラスター全体ですべての namespace で使用できるようになります。他の namespace で作成されたカタログは、カタログの同じ namespace でのみ Operator を使用できるようにします。
クラスター管理者以外のユーザーに Operator のインストール権限が委任されているクラスターでは、クラスター管理者は、それらのユーザーがインストールできる Operator のセットをさらに制御または制限しないといけない場合があります。これは、次のアクションで実現できます。
- デフォルトのグローバルカタログをすべて無効にします。
- 関連する Operator グループがプリインストールされているのと同じ namespace で、キュレートされたカスタムカタログを有効にします。
4.8.4. パーミッションに関する失敗のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
パーミッションがないために Operator のインストールが失敗する場合は、以下の手順を使用してエラーを特定します。
手順
Subscription
オブジェクトを確認します。このステータスには、Operator の必要な[Cluster]Role[Binding]
オブジェクトの作成を試行したInstallPlan
オブジェクトをポイントするオブジェクト参照installPlanRef
があります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow InstallPlan
オブジェクトのステータスでエラーの有無を確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow エラーメッセージは、以下を示しています。
-
リソースの API グループを含む、作成に失敗したリソースのタイプ。この場合、これは
rbac.authorization.k8s.io
グループのclusterroles
です。 - リソースの名前。
-
エラーのタイプ:
is forbidden
は、ユーザーに操作を実行するための十分なパーミッションがないことを示します。 - リソースの作成または更新を試みたユーザーの名前。この場合、これは Operator グループで指定されたサービスアカウントを参照します。
操作の範囲が
cluster scope
かどうか。ユーザーは、不足しているパーミッションをサービスアカウントに追加してから、繰り返すことができます。
注記現時点で、Operator Lifecycle Manager (OLM) は最初の試行でエラーの詳細のリストを提供しません。
-
リソースの API グループを含む、作成に失敗したリソースのタイプ。この場合、これは
4.9. カスタムカタログの管理 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者および Operator カタログメンテナーは、OpenShift Container Platform で Operator Lifecycle Manager (OLM) の Bundle Format を使用してパッケージ化されたカスタムカタログを作成し、管理できます。
Kubernetes は定期的に特定の API を非推奨とし、後続のリリースで削除します。その結果、Operator は API を削除した Kubernetes バージョンを使用する OpenShift Container Platform のバージョン以降、削除された API を使用できなくなります。
4.9.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
-
opm
CLI がインストールされている。
4.9.2. ファイルベースのカタログ リンクのコピーリンクがクリップボードにコピーされました!
ファイルベースのカタログ は、Operator Lifecycle Manager (OLM) の最新バージョンのカタログ形式です。この形式は、プレーンテキストベース (JSON または YAML) であり、以前の SQLite データベース形式の宣言的な設定の進化であり、完全な下位互換性があります。
OpenShift Container Platform 4.11 の時点で、デフォルトの Red Hat が提供する Operator カタログは、ファイルベースのカタログ形式でリリースされます。OpenShift Container Platform 4.6 から 4.10 までのデフォルトの Red Hat が提供する Operator カタログは、非推奨の SQLite データベース形式でリリースされました。
opm
サブコマンド、フラグ、および SQLite データベース形式に関連する機能も非推奨となり、今後のリリースで削除されます。機能は引き続きサポートされており、非推奨の SQLite データベース形式を使用するカタログに使用する必要があります。
opm index prune
などの SQLite データベース形式を使用する opm
サブコマンドおよびフラグの多くは、ファイルベースのカタログ形式では機能しません。ファイルベースのカタログを使用する方法の詳細は、Operator Framework パッケージ形式 および oc-mirror プラグインを使用した非接続インストールのイメージのミラーリング を参照してください。
4.9.2.1. ファイルベースのカタログイメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
opm
CLI を使用して、非推奨の SQLite データベース形式を置き換えるプレーンテキストの ファイルベースのカタログ 形式 (JSON または YAML) を使用するカタログイメージを作成できます。
前提条件
-
opm
CLI がインストールされている。 -
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.19 -i registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4.19
$ opm generate dockerfile <catalog_dir> \ -i registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4.19
1 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>.Dockerfile
3 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.yaml
2 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
0
Copy 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.9.2.2. ファイルベースのカタログイメージの更新またはフィルタリング リンクのコピーリンクがクリップボードにコピーされました!
opm
CLI を使用して、ファイルベースのカタログ形式を使用するカタログイメージを更新またはフィルタリングできます。既存のカタログイメージのコンテンツを抽出すると、必要に応じてカタログを変更できます。たとえば、以下を実行できます。
- パッケージの追加
- パッケージの削除
- 既存のパッケージエントリーの更新
- パッケージ、チャネル、バンドルごとの非推奨メッセージの記載
その後、イメージをカタログの更新バージョンとして再構築できます。
または、ミラーレジストリーにカタログイメージがすでにある場合は、oc-mirror CLI プラグインを使用して、ターゲットレジストリーにミラーリングする際に、そのカタログイメージの更新されたソースバージョンから削除されたイメージを自動的にプルーニングできます。
oc-mirror プラグインとこのユースケースの詳細は、「ミラーレジストリーのコンテンツを最新の状態に維持」セクション、および「oc-mirror プラグインを使用した非接続インストールのイメージのミラーリング」の「イメージのプルーニング」サブセクションを参照してください。
前提条件
ワークステーションに以下が含まれている。
-
opm
CLI。 -
podman
version 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.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記または、
-o json
フラグを使用して JSON 形式で出力することもできます。作成された
index.yaml
ファイルの内容を仕様に合わせて変更します。重要バンドルがカタログに公開されたら、いずれかのユーザーがバンドルをインストールしていると想定します。カタログ内で以前に公開されたすべてのバンドルに、現在または新しいチャネルヘッドへの更新パスが設定されていることを確認し、そのバージョンがインストールされているユーザーが立ち往生するのを防ぎます。
- Operator を追加するには、「ファイルベースのカタログイメージの作成」手順のパッケージ、バンドル、およびチャネルエントリーを作成する手順に従います。
Operator を削除するには、パッケージに関連する
olm.package
、olm.channel
、およびolm.bundle
Blob のセットを削除します。次の例は、カタログからexample-operator
パッケージを削除するために削除する必要があるセットを示しています。例4.15 削除されたエントリーの例
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 のリストに反映されていることを確認します。
4.9.3. SQLite ベースのカタログ リンクのコピーリンクがクリップボードにコピーされました!
Operator カタログの SQLite データベース形式は非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、この製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。
OpenShift Container Platform で非推奨となったか、削除された主な機能の最新の一覧は、OpenShift Container Platform リリースノートの 非推奨および削除された機能 セクションを参照してください。
4.9.3.1. SQLite ベースのインデックスイメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
opm
CLI を使用して、SQLite データベース形式に基づいてインデックスイメージを作成できます。
前提条件
-
opm
CLI がインストールされている。 -
podman
バージョン 1.9.3 以降がある。 - バンドルイメージがビルドされ、Docker v2-2 をサポートするレジストリーにプッシュされている。
手順
新しいインデックスを開始します。
opm index add \ --bundles <registry>/<namespace>/<bundle_image_name>:<tag> \ --tag <registry>/<namespace>/<index_image_name>:<tag> \ [--binary-image <registry_base_image>]
$ opm index add \ --bundles <registry>/<namespace>/<bundle_image_name>:<tag> \
1 --tag <registry>/<namespace>/<index_image_name>:<tag> \
2 [--binary-image <registry_base_image>]
3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow インデックスイメージをレジストリーにプッシュします。
必要な場合は、ターゲットレジストリーで認証します。
podman login <registry>
$ podman login <registry>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow インデックスイメージをプッシュします。
podman push <registry>/<namespace>/<index_image_name>:<tag>
$ podman push <registry>/<namespace>/<index_image_name>:<tag>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.9.3.2. SQLite ベースのインデックスイメージの更新 リンクのコピーリンクがクリップボードにコピーされました!
カスタムインデックスイメージを参照するカタログソースを使用するように OperatorHub を設定した後に、クラスター管理者はバンドルイメージをインデックスイメージに追加して、クラスターで利用可能な Operator を最新の状態に維持することができます。
opm index add
コマンドを使用して既存インデックスイメージを更新できます。
前提条件
-
opm
CLI がインストールされている。 -
podman
バージョン 1.9.3 以降がある。 - インデックスイメージがビルドされ、レジストリーにプッシュされている。
- インデックスイメージを参照する既存のカタログソースがある。
手順
バンドルイメージを追加して、既存のインデックスを更新します。
opm index add \ --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \ --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \ --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \ --pull-tool podman
$ opm index add \ --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \
1 --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \
2 --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \
3 --pull-tool podman
4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
<registry>
-
quay.io
やmirror.example.com
などのレジストリーのホスト名を指定します。 <namespace>
-
ocs-dev
やabc
など、レジストリーの namespace を指定します。 <new_bundle_image>
-
ocs-operator
など、レジストリーに追加する新しいバンドルイメージを指定します。 <digest>
-
c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41
などのバンドルイメージの SHA イメージ ID またはダイジェストを指定します。 <existing_index_image>
-
abc-redhat-operator-index
など、以前にプッシュされたイメージを指定します。 <existing_tag>
-
以前にプッシュしたイメージのタグ (
4.19
など) を指定します。 <updated_tag>
-
更新されたインデックスイメージに適用するイメージタグ (
4.19.1
など) を指定します。
コマンドの例
opm index add \ --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \ --from-index mirror.example.com/abc/abc-redhat-operator-index:4.19 \ --tag mirror.example.com/abc/abc-redhat-operator-index:4.19.1 \ --pull-tool podman
$ opm index add \ --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \ --from-index mirror.example.com/abc/abc-redhat-operator-index:4.19 \ --tag mirror.example.com/abc/abc-redhat-operator-index:4.19.1 \ --pull-tool podman
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 更新されたインデックスイメージをプッシュします。
podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>
$ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator Lifecycle Manager (OLM) がカタログソースで参照されるインデックスイメージを一定間隔で自動的にポーリングした後に、新規パッケージが正常に追加されたことを確認します。
oc get packagemanifests -n openshift-marketplace
$ oc get packagemanifests -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.9.3.3. SQLite ベースのインデックスイメージのフィルタリング リンクのコピーリンクがクリップボードにコピーされました!
Operator Bundle Format に基づくインデックスイメージは、Operator カタログのコンテナー化されたスナップショットです。パッケージの指定された一覧以外のすべてのインデックスを プルーニング できます。これにより、必要な Operator のみが含まれるソースインデックスのコピーを作成できます。
前提条件
-
podman
バージョン 1.9.3 以降がある。 -
grpcurl
(サードパーティーのコマンドラインツール) がある。 -
opm
CLI がインストールされている。 - Docker v2-2 をサポートするレジストリーにアクセスできる。
手順
ターゲットレジストリーで認証します。
podman login <target_registry>
$ podman login <target_registry>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プルーニングされたインデックスに追加するパッケージのリストを判別します。
コンテナーでプルーニングするソースインデックスイメージを実行します。以下に例を示します。
podman run -p50051:50051 \ -it registry.redhat.io/redhat/redhat-operator-index:v4.19
$ podman run -p50051:50051 \ -it registry.redhat.io/redhat/redhat-operator-index:v4.19
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.19... Getting image source signatures Copying blob ae8a0c23f5b1 done ... INFO[0000] serving registry database=/database/index.db port=50051
Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.19... Getting image source signatures Copying blob ae8a0c23f5b1 done ... INFO[0000] serving registry database=/database/index.db port=50051
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 別のターミナルセッションで、
grpcurl
コマンドを使用して、インデックスが提供するパッケージのリストを取得します。grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out
$ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow packages.out
ファイルを検査し、プルーニングされたインデックスに保持したいパッケージ名をこのリストから特定します。以下に例を示します。パッケージリストのスニペットの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
podman run
コマンドを実行したターミナルセッションで、Ctrl と C を押してコンテナープロセスを停止します。
以下のコマンドを実行して、指定したパッケージ以外のすべてのパッケージのソースインデックスをプルーニングします。
opm index prune \ -f registry.redhat.io/redhat/redhat-operator-index:v4.19 \ -p advanced-cluster-management,jaeger-product,quay-operator \ [-i registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4.19] \ -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.19
$ opm index prune \ -f registry.redhat.io/redhat/redhat-operator-index:v4.19 \
1 -p advanced-cluster-management,jaeger-product,quay-operator \
2 [-i registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4.19] \
3 -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.19
4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、新規インデックスイメージをターゲットレジストリーにプッシュします。
podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.19
$ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.19
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<namespace>
はレジストリー上の既存の namespace になります。
4.9.4. カタログソースと Pod セキュリティー受付 リンクのコピーリンクがクリップボードにコピーされました!
Pod セキュリティー基準を確保するために、OpenShift Container Platform 4.11 で Pod セキュリティー受付 が導入されました。SQLite ベースのカタログ形式と、OpenShift Container Platform 4.11 より前にリリースされたバージョンの opm
CLI ツールを使用してビルドされたカタログソースは、制限付き Pod セキュリティーの適用下では実行できません。
OpenShift Container Platform 4.19 では、デフォルトで namespace に制限付き Pod セキュリティーが適用されず、カタログソースのデフォルトセキュリティーモードが legacy
に設定されています。
すべての namespace に対するデフォルトの制限付き適用は、将来の OpenShift Container Platform リリースに含まれる予定です。制限付き適用が発生した場合、カタログソース Pod の Pod 仕様のセキュリティーコンテキストは、制限付き Pod のセキュリティー標準に一致する必要があります。カタログソースイメージで別の Pod セキュリティー標準が必要な場合は、namespace の Pod セキュリティーアドミッションラベルを明示的に設定する必要があります。
SQLite ベースのカタログソース Pod を制限付きで実行しない場合、OpenShift Container Platform 4.19 でカタログソースを更新する必要はありません。
ただし、制限付きの Pod セキュリティー適用下でカタログソースが確実に実行されるように、今すぐ対策を講じることを推奨します。制限された Pod セキュリティー適用下でカタログソースが確実に実行されるように対策を講じないと、将来の OpenShift Container Platform リリースでカタログソースが実行されなくなる可能性があります。
カタログの作成者は、次のいずれかのアクションを実行することで、制限付き Pod セキュリティー適用との互換性を有効にすることができます。
- カタログをファイルベースのカタログ形式に移行します。
-
OpenShift Container Platform 4.11 以降でリリースされたバージョンの
opm
CLI ツールでカタログイメージを更新します。
SQLite データベースカタログ形式は非推奨ですが、Red Hat では引き続きサポートされています。将来のリリースでは、SQLite データベース形式はサポートされなくなり、カタログはファイルベースのカタログ形式に移行する必要があります。OpenShift Container Platform 4.11 の時点で、デフォルトの Red Hat が提供する Operator カタログは、ファイルベースのカタログ形式でリリースされています。ファイルベースのカタログは、制限付き Pod セキュリティー適用と互換性があります。
SQLite データベースカタログイメージを更新したり、カタログをファイルベースのカタログ形式に移行したりしたくない場合は、昇格されたアクセス許可で実行するようにカタログを設定できます。
4.9.4.1. SQLite データベースカタログをファイルベースのカタログ形式に移行する リンクのコピーリンクがクリップボードにコピーされました!
非推奨の SQLite データベース形式のカタログをファイルベースのカタログ形式に更新できます。
前提条件
- SQLite データベースカタログソースがある。
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
ワークステーションに、OpenShift Container Platform 4.19 と併せてリリースされた
opm
CLI ツールの最新バージョンがインストールされている。
手順
次のコマンドを実行して、SQLite データベースカタログをファイルベースのカタログに移行します。
opm migrate <registry_image> <fbc_directory>
$ opm migrate <registry_image> <fbc_directory>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ファイルベースのカタログ用の Dockerfile を生成します。
opm generate dockerfile <fbc_directory> \ --binary-image \ registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4.19
$ opm generate dockerfile <fbc_directory> \ --binary-image \ registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4.19
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のステップ
- 生成された Dockerfile をビルドしてタグ付けし、レジストリーにプッシュできます。
4.9.4.2. SQLite データベースカタログイメージの再構築 リンクのコピーリンクがクリップボードにコピーされました!
お使いのバージョンの OpenShift Container Platform でリリースされている最新バージョンの opm
CLI ツールを使用して、SQLite データベースカタログイメージを再構築できます。
前提条件
- SQLite データベースカタログソースがある。
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
ワークステーションに、OpenShift Container Platform 4.19 と併せてリリースされた
opm
CLI ツールの最新バージョンがインストールされている。
手順
次のコマンドを実行して、最新バージョンの
opm
CLI ツールでカタログを再構築します。opm index add --binary-image \ registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4.19 \ --from-index <your_registry_image> \ --bundles "" -t \<your_registry_image>
$ opm index add --binary-image \ registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4.19 \ --from-index <your_registry_image> \ --bundles "" -t \<your_registry_image>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.9.4.3. 昇格された権限で実行するためのカタログの設定 リンクのコピーリンクがクリップボードにコピーされました!
SQLite データベースカタログイメージを更新したり、カタログをファイルベースのカタログ形式に移行したりしたくない場合は、次のアクションを実行して、デフォルトの Pod セキュリティー適用が制限付きに変更されたときにカタログソースが確実に実行されるようにすることができます。
- カタログソース定義でカタログセキュリティーモードをレガシーに手動で設定します。このアクションにより、デフォルトのカタログセキュリティーモードが制限付きに変更された場合でも、カタログが従来のアクセス許可で実行されることが保証されます。
- ベースラインまたは特権付き Pod のセキュリティー適用のために、カタログソースの namespace にラベルを付けます。
SQLite データベースカタログ形式は非推奨ですが、Red Hat では引き続きサポートされています。将来のリリースでは、SQLite データベース形式はサポートされなくなり、カタログはファイルベースのカタログ形式に移行する必要があります。ファイルベースのカタログは、制限付き Pod セキュリティー適用と互換性があります。
前提条件
- SQLite データベースカタログソースがある。
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
Pod Security Admission 標準が
baseline
またはprivileged
に昇格された実行中の Pod をサポートするターゲット namespace がある。
手順
次の例に示すように、
spec.grpcPodConfig.securityContextConfig
ラベルをlegacy
に設定して、CatalogSource
定義を編集します。CatalogSource
定義の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow ヒントOpenShift Container Platform 4.19 では、
spec.grpcPodConfig.securityContextConfig
フィールドはデフォルトでlegacy
に設定されます。OpenShift Container Platform の将来のリリースでは、デフォルト設定がrestricted
に変更される予定です。カタログを制限付き適用で実行できない場合は、このフィールドを手動でlegacy
に設定することを推奨します。次の例に示すように、
<namespace>.yaml
ファイルを編集して、上位の Pod Security Admission 標準をカタログソース namespace に追加します。<namespace>.yaml
ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.9.5. クラスターへのカタログソースの追加 リンクのコピーリンクがクリップボードにコピーされました!
カタログソースを OpenShift Container Platform クラスターに追加すると、ユーザーの Operator の検出およびインストールが可能になります。クラスター管理者は、インデックスイメージを参照する CatalogSource
オブジェクトを作成できます。OperatorHub はカタログソースを使用してユーザーインターフェイスを設定します。
または、Web コンソールを使用してカタログソースを管理できます。Administration → Cluster Settings → Configuration → OperatorHub ページから、Sources タブをクリックして、個別のソースを作成、更新、削除、無効化、有効化できます。
前提条件
- インデックスイメージをビルドしてレジストリーにプッシュしている。
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
インデックスイメージを参照する
CatalogSource
オブジェクトを作成します。仕様を以下のように変更し、これを
catalogSource.yaml
ファイルとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- カタログソースを全 namespace のユーザーがグローバルに利用できるようにする場合は、
openshift-marketplace
namespace を指定します。それ以外の場合は、そのカタログの別の namespace を対象とし、その namespace のみが利用できるように指定できます。 - 2
- 任意:
olm.catalogImageTemplate
アノテーションをカタログイメージ名に設定し、イメージタグのテンプレートを作成する際に、1 つ以上の Kubernetes クラスターバージョン変数を使用します。 - 3
legacy
またはrestricted
の値を指定します。フィールドが設定されていない場合、デフォルト値はlegacy
です。今後の OpenShift Container Platform リリースでは、デフォルト値がrestricted
になる予定です。restricted
権限でカタログを実行できない場合は、このフィールドを手動でlegacy
に設定することを推奨します。- 4
- インデックスイメージを指定します。イメージ名の後にタグを指定した場合 (
:v4.19
など)、カタログソース Pod はAlways
のイメージプルポリシーを使用します。これは、Pod が常にコンテナーを起動する前にイメージをプルすることを意味します。@sha256:<id>
などのダイジェストを指定した場合、イメージプルポリシーはIfNotPresent
になります。これは、イメージがノード上にまだ存在しない場合にのみ、Pod がイメージをプルすることを意味します。 - 5
- カタログを公開する名前または組織名を指定します。
- 6
- カタログソースは新規バージョンの有無を自動的にチェックし、最新の状態を維持します。
このファイルを使用して
CatalogSource
オブジェクトを作成します。oc apply -f catalogSource.yaml
$ oc apply -f catalogSource.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
以下のリソースが正常に作成されていることを確認します。
Pod を確認します。
oc get pods -n openshift-marketplace
$ oc get pods -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE my-operator-catalog-6njx6 1/1 Running 0 28s marketplace-operator-d9f549946-96sgr 1/1 Running 0 26h
NAME READY STATUS RESTARTS AGE my-operator-catalog-6njx6 1/1 Running 0 28s marketplace-operator-d9f549946-96sgr 1/1 Running 0 26h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow カタログソースを確認します。
oc get catalogsource -n openshift-marketplace
$ oc get catalogsource -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY TYPE PUBLISHER AGE my-operator-catalog My Operator Catalog grpc 5s
NAME DISPLAY TYPE PUBLISHER AGE my-operator-catalog My Operator Catalog grpc 5s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow パッケージマニフェストを確認します。
oc get packagemanifest -n openshift-marketplace
$ oc get packagemanifest -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CATALOG AGE jaeger-product My Operator Catalog 93s
NAME CATALOG AGE jaeger-product My Operator Catalog 93s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
OpenShift Container Platform Web コンソールで、OperatorHub ページから Operator をインストールできるようになりました。
4.9.6. プライベートレジストリーからの Operator のイメージへのアクセス リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) によって管理される Operator に関連する特定のイメージが、認証コンテナーイメージレジストリー (別名プライベートレジストリー) でホストされる場合、OLM および OperatorHub はデフォルトではイメージをプルできません。アクセスを有効にするために、レジストリーの認証情報が含まれるプルシークレットを作成できます。カタログソースの 1 つ以上のプルシークレットを参照することで、OLM はシークレットの配置を Operator およびカタログ namespace で処理し、インストールを可能にします。
Operator またはそのオペランドで必要な他のイメージでも、プライベートレジストリーへのアクセスが必要になる場合があります。OLM は、このシナリオのターゲットテナント namespace ではシークレットの配置を処理しませんが、認証情報をグローバルクラスタープルシークレットまたは個別の namespace サービスアカウントに追加して、必要なアクセスを有効にできます。
OLM によって管理される Operator に適切なプルアクセスがあるかどうかを判別する際に、以下のタイプのイメージを考慮する必要があります。
- インデックスイメージ
-
CatalogSource
オブジェクトは、インデックスイメージを参照できます。このイメージは、Operator のバンドル形式を使用し、イメージレジストリーでホストされるコンテナーイメージとしてパッケージ化されるカタログソースです。インデックスイメージがプライベートレジストリーでホストされる場合、シークレットを使用してプルアクセスを有効にすることができます。 - バンドルイメージ
- Operator バンドルイメージは、Operator の一意のバージョンを表すコンテナーイメージとしてパッケージ化されるメタデータおよびマニフェストです。カタログソースで参照されるバンドルイメージが 1 つ以上のプライベートレジストリーでホストされる場合、シークレットを使用してプルアクセスを有効にすることができます。
- Operator イメージおよびオペランドイメージ
カタログソースからインストールされた Operator が、(Operator イメージ自体に、または監視するオペランドイメージの 1 つに) プライベートイメージを使用する場合、デプロイメントは必要なレジストリー認証にアクセスできないため、Operator はインストールに失敗します。カタログソースのシークレットを参照することで、OLM はオペランドがインストールされているターゲットテナント namespace にシークレットを配置することはできません。
代わりに、認証情報を
openshift-config
namespace のグローバルクラスタープルシークレットに追加できます。これにより、クラスターのすべての namespace へのアクセスが提供されます。または、クラスター全体へのアクセスの提供が許容されない場合、プルシークレットをターゲットテナント namespace のdefault
のサービスアカウントに追加できます。
レジストリー認証情報のシークレットを作成し、そのシークレットを関連するカタログで使用するために追加することで、プライベートレジストリーから Operator のイメージにアクセスできます。
前提条件
プライベートレジストリーで、以下を 1 つ以上ホストしている。
- インデックスイメージまたはカタログイメージ。
- Operator のバンドルイメージ
- Operator またはオペランドのイメージ。
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
必要な各プライベートレジストリーのシークレットを作成します。
プライベートレジストリーにログインして、レジストリー認証情報ファイルを作成または更新します。
podman login <registry>:<port>
$ podman login <registry>:<port>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記レジストリー認証情報のファイルパスは、レジストリーへのログインに使用されるコンテナーツールによって異なります。
podman
CLI の場合、デフォルトの場所は${XDG_RUNTIME_DIR}/containers/auth.json
です。docker
CLI の場合、デフォルトの場所は/root/.docker/config.json
です。シークレットごとに 1 つのレジストリーに対してのみ認証情報を追加し、別のシークレットで複数のレジストリーの認証情報を管理することが推奨されます。これ以降の手順で、複数のシークレットを
CatalogSource
オブジェクトに含めることができ、OpenShift Container Platform はイメージのプル時に使用する単一の仮想認証情報ファイルにシークレットをマージします。レジストリー認証情報ファイルは、デフォルトで複数のレジストリーまたはリポジトリーの詳細を 1 つのレジストリーに保存できます。ファイルの現在の内容を確認します。以下に例を示します。
複数のレジストリーの認証情報を保存するファイル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これ以降の手順で、シークレットの作成にこのファイルが使用されるため、保存できる詳細は 1 つのファイルにつき 1 つのレジストリーのみであることを確認してください。これには、以下の方法の 1 つを使用します。
-
podman logout <registry>
コマンドを使用して、必要な 1 つのレジストリーのみになるまで、追加のレジストリーの認証情報を削除します。 レジストリー認証情報ファイルを編集し、レジストリーの詳細を分離して、複数のファイルに保存します。以下に例を示します。
1 つのレジストリーの認証情報を保存するファイル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 別のレジストリーの認証情報を保存するファイル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
プライベートレジストリーの認証情報が含まれるシークレットを
openshift-marketplace
namespace に作成します。oc create secret generic <secret_name> \ -n openshift-marketplace \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjson
$ oc create secret generic <secret_name> \ -n openshift-marketplace \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjson
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この手順を繰り返して、他の必要なプライベートレジストリーの追加シークレットを作成し、
--from-file
フラグを更新して別のレジストリー認証情報ファイルのパスを指定します。
1 つ以上のシークレットを参照するように既存の
CatalogSource
オブジェクトを作成または更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow サブスクライブされた Operator によって参照される Operator イメージまたはオペランドイメージにプライベートレジストリーへのアクセスが必要な場合は、クラスター内のすべての namespace または個々のターゲットテナント namespace のいずれかにアクセスを提供できます。
クラスター内のすべての namespace へアクセスを提供するには、認証情報を
openshift-config
namespace のグローバルクラスタープルシークレットに追加します。警告クラスターリソースは新規のグローバルプルシークレットに合わせて調整する必要がありますが、これにより、クラスターのユーザービリティーが一時的に制限される可能性があります。
グローバルプルシークレットから
.dockerconfigjson
ファイルを展開します。oc extract secret/pull-secret -n openshift-config --confirm
$ oc extract secret/pull-secret -n openshift-config --confirm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow .dockerconfigjson
ファイルを、必要なプライベートレジストリーまたはレジストリーの認証情報で更新し、これを新規ファイルとして保存します。cat .dockerconfigjson | \ jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \ jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \ > new_dockerconfigjson > new_dockerconfigjson
$ cat .dockerconfigjson | \ jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \
1 > new_dockerconfigjson
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<registry>:<port>/<namespace>
をプライベートレジストリーの詳細に置き換え、<token>
を認証情報に置き換えます。
新規ファイルでグローバルプルシークレットを更新します。
oc set data secret/pull-secret -n openshift-config \ --from-file=.dockerconfigjson=new_dockerconfigjson
$ oc set data secret/pull-secret -n openshift-config \ --from-file=.dockerconfigjson=new_dockerconfigjson
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
個別の namespace を更新するには、ターゲットテナント namespace でアクセスが必要な Operator のサービスアカウントにプルシークレットを追加します。
テナント namespace で
openshift-marketplace
用に作成したシークレットを再作成します。oc create secret generic <secret_name> \ -n <tenant_namespace> \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjson
$ oc create secret generic <secret_name> \ -n <tenant_namespace> \ --from-file=.dockerconfigjson=<path/to/registry/credentials> \ --type=kubernetes.io/dockerconfigjson
Copy to Clipboard Copied! Toggle word wrap Toggle overflow テナント namespace を検索して、Operator のサービスアカウントの名前を確認します。
oc get sa -n <tenant_namespace>
$ oc get sa -n <tenant_namespace>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Operator が個別の namespace にインストールされていた場合、その namespace を検索します。Operator がすべての namespace にインストールされていた場合、
openshift-operators
namespace を検索します。
出力例
NAME SECRETS AGE builder 2 6m1s default 2 6m1s deployer 2 6m1s etcd-operator 2 5m18s
NAME SECRETS AGE builder 2 6m1s default 2 6m1s deployer 2 6m1s etcd-operator 2 5m18s
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- インストールされた etcd Operator のサービスアカウント。
シークレットを Operator のサービスアカウントにリンクします。
oc secrets link <operator_sa> \ -n <tenant_namespace> \ <secret_name> \ --for=pull
$ oc secrets link <operator_sa> \ -n <tenant_namespace> \ <secret_name> \ --for=pull
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.9.7. デフォルトの OperatorHub カタログソースの無効化 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。クラスター管理者は、デフォルトカタログのセットを無効にすることができます。
手順
disableAllDefaultSources: true
をOperatorHub
オブジェクトに追加して、デフォルトカタログのソースを無効にします。oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
または、Web コンソールを使用してカタログソースを管理できます。Administration → Cluster Settings → Configuration → OperatorHub ページから、Sources タブをクリックして、個別のソースを作成、更新、削除、無効化、有効化できます。
4.9.8. カスタムカタログの削除 リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、関連するカタログソースを削除して、以前にクラスターに追加されたカスタム Operator カタログを削除できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
- Web コンソールの Administrator パースペクティブで、Administration → Cluster Settings に移動します。
- Configuration タブをクリックしてから、OperatorHub をクリックします。
- Sources タブをクリックします。
-
削除するカタログの Options メニュー
を選択し、Delete CatalogSource をクリックします。
4.10. 非接続環境での Operator Lifecycle Manager の使用 リンクのコピーリンクがクリップボードにコピーされました!
非接続環境の OpenShift Container Platform クラスターの場合、Operator Lifecycle Manager (OLM) は、リモートレジストリーでホストされている Red Hat 提供の OperatorHub ソースにデフォルトでアクセスできません。このようなリモートソースには、完全なインターネット接続が必要であるためです。
ただし、クラスター管理者は、インターネットに完全にアクセスできるワークステーションがある場合、クラスターが非接続環境で OLM を使用できるようにすることができます。ワークステーションは、リモートソースのローカルミラーを準備するために使用され、コンテンツをミラーレジストリーにプッシュしますが、これにはリモートの OperatorHub コンテンツをプルするのに完全なインターネットアクセスが必要になります。
ミラーレジストリーは bastion ホストに配置することができます。bastion ホストには、ワークステーションと非接続クラスターの両方への接続、または完全に切断されたクラスター、またはミラーリングされたコンテンツを非接続環境に物理的に移動するためにリムーバブルメディアが必要な エアギャップ ホストへの接続が必要です。
このガイドでは、非接続環境で OLM を有効にするために必要な次のプロセスを説明します。
- OLM のデフォルトのリモート OperatorHub ソースを無効にします。
- 完全なインターネットアクセスのあるワークステーションを使用して、OperatorHub コンテンツのローカルミラーを作成し、これをミラーレジストリーにプッシュします。
- OLM を、デフォルトのリモートソースからではなくミラーレジストリーのローカルソースから Operator をインストールし、管理するように設定します。
非接続環境で OLM を有効にしたら、アクセス制限のないワークステーションを引き続き使用して、新しいバージョンの Operator のリリース時にローカルの OperatorHub ソースを継続的に更新できます。
詳細は、「非接続環境」セクションの 非接続環境での Operator Lifecycle Manager の使用 を参照してください。
4.11. カタログソース Pod のスケジューリング リンクのコピーリンクがクリップボードにコピーされました!
ソースタイプ grpc
の Operator Lifecycle Manager (OLM) カタログソースが spec.image
を定義すると、Catalog Operator は、定義されたイメージコンテンツを提供する Pod を作成します。デフォルトでは、この Pod は、その仕様で以下を定義します。
-
kubernetes.io/os=linux
ノードセレクターのみ -
デフォルトの優先クラス名:
system-cluster-critical
。 - toleration なし
管理者は、CatalogSource
オブジェクトのオプションの spec.grpcPodConfig
セクションのフィールドを変更すると、これらの値をオーバーライドできます。
Marketplace Operator の openshift-marketplace
は、デフォルトの OperatorHub
カスタムリソース (CR) を管理します。この CR は CatalogSource
オブジェクトを管理します。ユーザーが CatalogSource
オブジェクトの spec.grpcPodConfig
セクションのフィールドを変更しようとすると、Marketplace Operator によってその変更が自動的に元に戻されます。デフォルトでは、CatalogSource
オブジェクトの spec.grpcPodConfig
セクションのフィールドを変更すると、Marketplace Operator によってその変更が自動的に元に戻されます。
CatalogSource
オブジェクトに永続的な変更を適用するには、まずデフォルトの CatalogSource
オブジェクトを無効にする必要があります。
4.11.1. ローカルレベルでのデフォルト CatalogSource オブジェクトの無効化 リンクのコピーリンクがクリップボードにコピーされました!
デフォルトの CatalogSource
オブジェクトを無効にすることで、カタログソース Pod などの永続的な変更をローカルレベルで CatalogSource
オブジェクトに適用できます。デフォルトの CatalogSource
オブジェクトの設定が組織のニーズを満たさない場合は、デフォルト設定を検討してください。デフォルトでは、CatalogSource
オブジェクトの spec.grpcPodConfig
セクションのフィールドを変更すると、Marketplace Operator によってその変更が自動的に元に戻されます。
Marketplace Operator の openshift-marketplace
は、OperatorHub
のデフォルトのカスタムリソース (CR) を管理します。OperatorHub
は CatalogSource
オブジェクトを管理します。
CatalogSource
オブジェクトに永続的な変更を適用するには、まずデフォルトの CatalogSource
オブジェクトを無効にする必要があります。
手順
すべてのデフォルトの
CatalogSource
オブジェクトをローカルレベルで無効にするには、次のコマンドを入力します。oc patch operatorhub cluster -p '{"spec": {"disableAllDefaultSources": true}}' --type=merge
$ oc patch operatorhub cluster -p '{"spec": {"disableAllDefaultSources": true}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記また、デフォルトの
OperatorHub
CR を設定して、すべてのCatalogSource
オブジェクトを無効にするか、または特定のオブジェクトを無効にすることもできます。
4.11.2. カタログソース Pod のノードセレクターのオーバーライド リンクのコピーリンクがクリップボードにコピーされました!
前提条件
-
spec.image
を持つソースタイプgrpc
のCatalogSource
オブジェクトが定義されている。
手順
CatalogSource
オブジェクトを編集し、spec.grpcPodConfig
セクションを追加または変更して、以下を含めます。grpcPodConfig: nodeSelector: custom_label: <label>
grpcPodConfig: nodeSelector: custom_label: <label>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <label>
は、カタログソース Pod がスケジュールに使用するノードセレクターのラベルです。
4.11.3. カタログソース Pod の優先度クラス名のオーバーライド リンクのコピーリンクがクリップボードにコピーされました!
前提条件
-
spec.image
を持つソースタイプgrpc
のCatalogSource
オブジェクトが定義されている。
手順
CatalogSource
オブジェクトを編集し、spec.grpcPodConfig
セクションを追加または変更して、以下を含めます。grpcPodConfig: priorityClassName: <priority_class>
grpcPodConfig: priorityClassName: <priority_class>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <priority_class>
は次のいずれかです。-
Kubernetes によって提供されるデフォルトの優先度クラスの 1 つ:
system-cluster-critical
またはsystem-node-critical
-
デフォルトの優先度を割り当てる空のセット (
""
) - 既存およびカスタム定義の優先度クラス
-
Kubernetes によって提供されるデフォルトの優先度クラスの 1 つ:
以前は、オーバーライドできる唯一の Pod スケジューリングパラメーターは priorityClassName
でした。これは、operatorframework.io/priorityclass
アノテーションを CatalogSource
オブジェクトに追加することによって行われました。以下に例を示します。
CatalogSource
オブジェクトがアノテーションと spec.grpcPodConfig.priorityClassName
の両方を定義する場合、アノテーションは設定パラメーターよりも優先されます。
4.11.4. カタログソース Pod の Toleration のオーバーライド リンクのコピーリンクがクリップボードにコピーされました!
前提条件
-
spec.image
を持つソースタイプgrpc
のCatalogSource
オブジェクトが定義されている。
手順
CatalogSource
オブジェクトを編集し、spec.grpcPodConfig
セクションを追加または変更して、以下を含めます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.12. Operator 関連の問題のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
Operator に問題が発生した場合には、Operator Subscription のステータスを確認します。クラスター全体で Operator Pod の正常性を確認し、診断用に Operator ログを収集します。
4.12.1. Operator サブスクリプションの状態のタイプ リンクのコピーリンクがクリップボードにコピーされました!
サブスクリプションは状態に関する以下のタイプを報告します。
状態 | 説明 |
---|---|
| 解決に使用される一部のまたはすべてのカタログソースは正常ではありません。 |
| サブスクリプションのインストール計画がありません。 |
| サブスクリプションのインストール計画はインストールの保留中です。 |
| サブスクリプションのインストール計画が失敗しました。 |
| サブスクリプションの依存関係の解決に失敗しました。 |
デフォルトの OpenShift Container Platform Cluster Operator は Cluster Version Operator (CVO) によって管理され、これらの Operator には Subscription
オブジェクトがありません。アプリケーション Operator は Operator Lifecycle Manager (OLM) によって管理され、それらには Subscription
オブジェクトがあります。
4.12.2. CLI を使用した Operator サブスクリプションステータスの表示 リンクのコピーリンクがクリップボードにコピーされました!
CLI を使用して Operator サブスクリプションステータスを表示できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
Operator サブスクリプションをリスト表示します。
oc get subs -n <operator_namespace>
$ oc get subs -n <operator_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe
コマンドを使用して、Subscription
リソースを検査します。oc describe sub <subscription_name> -n <operator_namespace>
$ oc describe sub <subscription_name> -n <operator_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow コマンド出力で、
Conditions
セクションで Operator サブスクリプションの状態タイプのステータスを確認します。以下の例では、利用可能なすべてのカタログソースが正常であるため、CatalogSourcesUnhealthy
状態タイプのステータスはfalse
になります。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
デフォルトの OpenShift Container Platform Cluster Operator は Cluster Version Operator (CVO) によって管理され、これらの Operator には Subscription
オブジェクトがありません。アプリケーション Operator は Operator Lifecycle Manager (OLM) によって管理され、それらには Subscription
オブジェクトがあります。
4.12.3. CLI を使用した Operator カタログソースのステータス表示 リンクのコピーリンクがクリップボードにコピーされました!
Operator カタログソースのステータスは、CLI を使用して確認できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
namespace のカタログソースをリスト表示します。たとえば、クラスター全体のカタログソースに使用されている
openshift-marketplace
namespace を確認することができます。oc get catalogsources -n openshift-marketplace
$ oc get catalogsources -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY TYPE PUBLISHER AGE certified-operators Certified Operators grpc Red Hat 55m community-operators Community Operators grpc Red Hat 55m example-catalog Example Catalog grpc Example Org 2m25s redhat-operators Red Hat Operators grpc Red Hat 55m
NAME DISPLAY TYPE PUBLISHER AGE certified-operators Certified Operators grpc Red Hat 55m community-operators Community Operators grpc Red Hat 55m example-catalog Example Catalog grpc Example Org 2m25s redhat-operators Red Hat Operators grpc Red Hat 55m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow カタログソースの詳細やステータスを確認するには、
oc describe
コマンドを使用します。oc describe catalogsource example-catalog -n openshift-marketplace
$ oc describe catalogsource example-catalog -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 前述の出力例では、最後に観測された状態が
TRANSIENT_FAILURE
となっています。この状態は、カタログソースの接続確立に問題があることを示しています。カタログソースが作成された namespace の Pod をリストアップします。
oc get pods -n openshift-marketplace
$ oc get pods -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace にカタログソースを作成すると、その namespace にカタログソース用の Pod が作成されます。前述の出力例では、
example-catalog-bwt8z
Pod のステータスがImagePullBackOff
になっています。このステータスは、カタログソースのインデックスイメージのプルに問題があることを示しています。oc describe
コマンドを使用して、より詳細な情報を得るために Pod を検査します。oc describe pod example-catalog-bwt8z -n openshift-marketplace
$ oc describe pod example-catalog-bwt8z -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 前述の出力例では、エラーメッセージは、カタログソースのインデックスイメージが承認問題のために正常にプルできないことを示しています。例えば、インデックスイメージがログイン認証情報を必要とするレジストリーに保存されている場合があります。
4.12.4. Operator Pod ステータスのクエリー リンクのコピーリンクがクリップボードにコピーされました!
クラスター内の Operator Pod およびそれらのステータスをリスト表示できます。詳細な Operator Pod の要約を収集することもできます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - API サービスが機能している。
-
OpenShift CLI (
oc
) がインストールされている。
手順
クラスターで実行されている Operator をリスト表示します。出力には、Operator バージョン、可用性、およびアップタイムの情報が含まれます。
oc get clusteroperators
$ oc get clusteroperators
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator の namespace で実行されている Operator Pod をリスト表示し、Pod のステータス、再起動、および経過時間をリスト表示します。
oc get pod -n <operator_namespace>
$ oc get pod -n <operator_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細な Operator Pod の要約を出力します。
oc describe pod <operator_pod_name> -n <operator_namespace>
$ oc describe pod <operator_pod_name> -n <operator_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator の問題がノード固有の問題である場合、クエリーを実行してそのノードの Operator コンテナーのステータスを取得します。
ノードのデバッグ Pod を起動します。
oc debug node/my-node
$ oc debug node/my-node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow /host
をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の/host
にホストの root ファイルシステムをマウントします。root ディレクトリーを/host
に変更すると、ホストの実行パスに含まれるバイナリーを実行できます。chroot /host
# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform 4.19 クラスターノードは、イミュータブルです。クラスターの変更を適用するには、Operator を使用します。SSH を使用したクラスターノードへのアクセスは推奨されません。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、
oc
操作がその影響を受けます。この場合は、代わりにssh core@<node>.<cluster_name>.<base_domain>
を使用してノードにアクセスできます。状態および関連付けられた Pod ID を含む、ノードのコンテナーの詳細をリスト表示します。
crictl ps
# crictl ps
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノード上の特定の Operator コンテナーに関する情報をリスト表示します。以下の例では、
network-operator
コンテナーに関する情報をリスト表示します。crictl ps --name network-operator
# crictl ps --name network-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - デバッグシェルを終了します。
4.12.5. Operator ログの収集 リンクのコピーリンクがクリップボードにコピーされました!
Operator の問題が発生した場合、Operator Pod ログから詳細な診断情報を収集できます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - API サービスが機能している。
-
OpenShift CLI (
oc
) がインストールされている。 - コントロールプレーンまたはコントロールプレーンマシンの完全修飾ドメイン名がある。
手順
Operator の namespace で実行されている Operator Pod、Pod のステータス、再起動、および経過時間をリスト表示します。
oc get pods -n <operator_namespace>
$ oc get pods -n <operator_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator Pod のログを確認します。
oc logs pod/<pod_name> -n <operator_namespace>
$ oc logs pod/<pod_name> -n <operator_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator Pod に複数のコンテナーがある場合、前述のコマンドにより各コンテナーの名前が含まれるエラーが生成されます。個別のコンテナーに対して、ログのクエリーを実行します。
oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace>
$ oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow API が機能しない場合には、代わりに SSH を使用して各コントロールプレーンノードで Operator Pod およびコンテナーログを確認します。
<master-node>.<cluster_name>.<base_domain>
を適切な値に置き換えます。各コントロールプレーンノードの Pod をリスト表示します。
ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator Pod で
Ready
ステータスが表示されない場合は、Pod のステータスを詳細に検査します。<operator_pod_id>
を直前のコマンドの出力にリスト表示されている Operator Pod の ID に置き換えます。ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <operator_pod_id>
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <operator_pod_id>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator Pod に関連するコンテナーをリスト表示します。
ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps --pod=<operator_pod_id>
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps --pod=<operator_pod_id>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ready
ステータスが Operator コンテナーに表示されない場合は、コンテナーのステータスを詳細に検査します。<container_id>
を前述のコマンドの出力に一覧表示されているコンテナー ID に置き換えます。ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ready
ステータスが表示されない Operator コンテナーのログを確認します。<container_id>
を前述のコマンドの出力に一覧表示されているコンテナー ID に置き換えます。ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Red Hat Enterprise Linux CoreOS (RHCOS) を実行する OpenShift Container Platform 4.19 クラスターノードは、イミュータブルです。クラスターの変更を適用するには、Operator を使用します。SSH を使用したクラスターノードへのアクセスは推奨されません。SSH 経由で診断データの収集を試行する前に、
oc adm must gather
およびその他のoc
コマンドを実行して収集されるデータが十分であるかどうかを確認してください。ただし、OpenShift Container Platform API が利用できない場合や、kubelet がターゲットノードで適切に機能しない場合、oc
操作がその影響を受けます。この場合は、代わりにssh core@<node>.<cluster_name>.<base_domain>
を使用してノードにアクセスできます。
4.12.6. Machine Config Operator の自動再起動の無効化 リンクのコピーリンクがクリップボードにコピーされました!
設定変更が Machine Config Operator (MCO) によって行われる場合、Red Hat Enterprise Linux CoreOS (RHCOS) を再起動して変更を反映する必要があります。設定の変更が自動または手動であるかどうかにかかわらず、RHCOS ノードは、一時停止されない限り自動的に再起動します。
以下の変更は、ノードの再起動をトリガーしません。
MCO が以下の変更のいずれかを検出すると、ノードのドレインまたは再起動を行わずに更新を適用します。
-
マシン設定の
spec.config.passwd.users.sshAuthorizedKeys
パラメーターの SSH キーの変更。 -
openshift-config
namespace でのグローバルプルシークレットまたはプルシークレットへの変更。 -
Kubernetes API Server Operator による
/etc/kubernetes/kubelet-ca.crt
認証局 (CA) の自動ローテーション。
-
マシン設定の
MCO は、
/etc/containers/registries.conf
ファイルへの変更 (ImageDigestMirrorSet
、ImageTagMirrorSet
、またはImageContentSourcePolicy
オブジェクトの追加や編集など) を検出すると、対応するノードをドレインし、変更を適用して、ノードをスケジューリング対象に戻します。次の変更ではノードのドレインは発生しません。-
pull-from-mirror = "digest-only"
パラメーターがミラーごとに設定されたレジストリーの追加。 -
pull-from-mirror = "digest-only"
パラメーターがレジストリーに設定されたミラーの追加。 -
unqualified-search-registries
へのアイテムの追加。
-
不要な中断を防ぐために、マシン設定プール (MCP) を変更して、Operator がマシン設定を変更した後に自動再起動を防ぐことができます。
4.12.6.1. コンソールの使用による Machine Config Operator の自動再起動の無効化 リンクのコピーリンクがクリップボードにコピーされました!
Machine Config Operator (MCO) の変更から不要な中断を防ぐには、OpenShift Container Platform Web コンソールを使用してマシン設定プール (MCP) を変更し、MCO がそのプール内のノードに変更を加えられないようにすることができます。これにより、通常 MCO 更新プロセスの一部として実行される再起動ができなくなります。
Machine Config Operator の自動再起動の無効化 で、2 つ目の 注記
を参照してください。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
自動 MCO 更新の再起動の一時停止または一時停止を解除するには、以下を実行します。
自動再起動プロセスを一時停止します。
-
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。 - Compute → MachineConfigPools をクリックします。
- MachineConfigPools ページで、再起動を一時停止するノードに合わせて master または worker のいずれかをクリックします。
- master または worker ページで、YAML をクリックします。
YAML で、
spec.paused
フィールドをtrue
に更新します。MachineConfigPool オブジェクトのサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
spec.paused
フィールドをtrue
に更新し、再起動を一時停止します。
MCP が一時停止されていることを確認するには、MachineConfigPools ページに戻ります。
MachineConfigPools ページの Paused 列では、変更した MCP に対して True が報告されます。
MCP が一時停止中に保留中の変更がある場合は、Updated 列は False であり、Updating は False になります。Updated が True であり、Updating が False の場合、保留中の変更はありません。
重要保留中の変更がある場合 (Updated および Updating 列の両方が False の場合)、できるだけ早期に再起動のメンテナンス期間をスケジュールすることが推奨されます。自動再起動プロセスの一時停止を解除して、最後に再起動してからキューに追加された変更を適用するには、以下の手順に従います。
-
自動再起動プロセスの一時停止を解除するには、以下を実行します。
-
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。 - Compute → MachineConfigPools をクリックします。
- MachineConfigPools ページで、再起動を一時停止するノードに合わせて master または worker のいずれかをクリックします。
- master または worker ページで、YAML をクリックします。
YAML で、
spec.paused
フィールドをfalse
に更新します。MachineConfigPool オブジェクトのサンプル
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
spec.paused
フィールドをfalse
に更新し、再起動を許可します。
注記MCP の一時停止を解除すると、MCO は一時停止したすべての変更を適用し、必要に応じて Red Hat Enterprise Linux CoreOS (RHCOS) を再起動します。
MCP が一時停止されていることを確認するには、MachineConfigPools ページに戻ります。
MachineConfigPools ページの Paused 列では、変更した MCP に対して False が報告されます。
MCP が保留中の変更を適用する場合、Updated 列は False になり、Updating 列は True になります。Updated が True であり、Updating が False の場合、追加の変更は加えられません。
-
4.12.6.2. CLI の使用による Machine Config Operator の自動再起動の無効化 リンクのコピーリンクがクリップボードにコピーされました!
Machine Config Operator (MCO) によって加えられる変更から生じる不要な中断を防ぐには、OpenShift CLI (oc) を使用してマシン設定プール (MCP) を変更し、MCO がそのプール内のノードに変更を加えられないようにすることができます。これにより、通常 MCO 更新プロセスの一部として実行される再起動ができなくなります。
Machine Config Operator の自動再起動の無効化 で、2 つ目の 注記
を参照してください。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
自動 MCO 更新の再起動の一時停止または一時停止を解除するには、以下を実行します。
自動再起動プロセスを一時停止します。
MachineConfigPool
カスタムリソースを、spec.paused
フィールドをtrue
に設定するように更新します。コントロールプレーン (マスター) ノード
oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/master
$ oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/master
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ワーカーノード
oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/worker
$ oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/worker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow MCP が一時停止されていることを確認します。
コントロールプレーン (マスター) ノード
oc get machineconfigpool/master --template='{{.spec.paused}}'
$ oc get machineconfigpool/master --template='{{.spec.paused}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ワーカーノード
oc get machineconfigpool/worker --template='{{.spec.paused}}'
$ oc get machineconfigpool/worker --template='{{.spec.paused}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
true
true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec.paused
フィールドはtrue
であり、MCP は一時停止されます。MCP に保留中の変更があるかどうかを判別します。
oc get machineconfigpool
# oc get machineconfigpool
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CONFIG UPDATED UPDATING master rendered-master-33cf0a1254318755d7b48002c597bf91 True False worker rendered-worker-e405a5bdb0db1295acea08bcca33fa60 False False
NAME CONFIG UPDATED UPDATING master rendered-master-33cf0a1254318755d7b48002c597bf91 True False worker rendered-worker-e405a5bdb0db1295acea08bcca33fa60 False False
Copy to Clipboard Copied! Toggle word wrap Toggle overflow UPDATED 列が False であり、UPDATING が False の場合は、保留中の変更があります。UPDATED が True であり、UPDATING が False の場合、保留中の変更はありません。この例では、ワーカーノードに保留中の変更があります。コントロールプレーンノードには保留中の変更がありません。
重要保留中の変更がある場合 (Updated および Updating 列の両方が False の場合)、できるだけ早期に再起動のメンテナンス期間をスケジュールすることが推奨されます。自動再起動プロセスの一時停止を解除して、最後に再起動してからキューに追加された変更を適用するには、以下の手順に従います。
自動再起動プロセスの一時停止を解除するには、以下を実行します。
MachineConfigPool
カスタムリソースを、spec.paused
フィールドをfalse
に設定するように更新します。コントロールプレーン (マスター) ノード
oc patch --type=merge --patch='{"spec":{"paused":false}}' machineconfigpool/master
$ oc patch --type=merge --patch='{"spec":{"paused":false}}' machineconfigpool/master
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ワーカーノード
oc patch --type=merge --patch='{"spec":{"paused":false}}' machineconfigpool/worker
$ oc patch --type=merge --patch='{"spec":{"paused":false}}' machineconfigpool/worker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記MCP の一時停止を解除すると、MCO は一時停止したすべての変更を適用し、必要に応じて Red Hat Enterprise Linux CoreOS (RHCOS) を再起動します。
MCP の一時停止が解除されていることを確認します。
コントロールプレーン (マスター) ノード
oc get machineconfigpool/master --template='{{.spec.paused}}'
$ oc get machineconfigpool/master --template='{{.spec.paused}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ワーカーノード
oc get machineconfigpool/worker --template='{{.spec.paused}}'
$ oc get machineconfigpool/worker --template='{{.spec.paused}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
false
false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec.paused
フィールドはfalse
であり、マシン設定プールの一時停止は解除されます。MCP に保留中の変更があるかどうかを判別します。
oc get machineconfigpool
$ oc get machineconfigpool
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME CONFIG UPDATED UPDATING master rendered-master-546383f80705bd5aeaba93 True False worker rendered-worker-b4c51bb33ccaae6fc4a6a5 False True
NAME CONFIG UPDATED UPDATING master rendered-master-546383f80705bd5aeaba93 True False worker rendered-worker-b4c51bb33ccaae6fc4a6a5 False True
Copy to Clipboard Copied! Toggle word wrap Toggle overflow MCP が保留中の変更を適用する場合、UPDATED 列は False で、UPDATING 列は True になります。UPDATED が True であり、UPDATING が False の場合、追加の変更は加えられません。直前の例では、MCO はワーカーノードを更新しています。
4.12.7. 障害のあるサブスクリプションの更新 リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) で、ネットワークでアクセスできないイメージを参照する Operator をサブスクライブする場合、以下のエラーを出して失敗した openshift-marketplace
namespace でジョブを見つけることができます。
出力例
ImagePullBackOff for Back-off pulling image "example.com/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c846ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"
ImagePullBackOff for
Back-off pulling image "example.com/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c846ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"
出力例
rpc error: code = Unknown desc = error pinging docker registry example.com: Get "https://example.com/v2/": dial tcp: lookup example.com on 10.0.0.1:53: no such host
rpc error: code = Unknown desc = error pinging docker registry example.com: Get "https://example.com/v2/": dial tcp: lookup example.com on 10.0.0.1:53: no such host
その結果、サブスクリプションはこの障害のある状態のままとなり、Operator はインストールまたはアップグレードを実行できません。
サブスクリプション、クラスターサービスバージョン (CSV) その他の関連オブジェクトを削除して、障害のあるサブスクリプションを更新できます。サブスクリプションを再作成した後に、OLM は Operator の正しいバージョンを再インストールします。
前提条件
- アクセス不可能なバンドルイメージをプルできない障害のあるサブスクリプションがある。
- 正しいバンドルイメージにアクセスできることを確認している。
手順
Operator がインストールされている namespace から
Subscription
およびClusterServiceVersion
オブジェクトの名前を取得します。oc get sub,csv -n <namespace>
$ oc get sub,csv -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME PACKAGE SOURCE CHANNEL subscription.operators.coreos.com/elasticsearch-operator elasticsearch-operator redhat-operators 5.0 NAME DISPLAY VERSION REPLACES PHASE clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65 OpenShift Elasticsearch Operator 5.0.0-65 Succeeded
NAME PACKAGE SOURCE CHANNEL subscription.operators.coreos.com/elasticsearch-operator elasticsearch-operator redhat-operators 5.0 NAME DISPLAY VERSION REPLACES PHASE clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65 OpenShift Elasticsearch Operator 5.0.0-65 Succeeded
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サブスクリプションを削除します。
oc delete subscription <subscription_name> -n <namespace>
$ oc delete subscription <subscription_name> -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターサービスバージョンを削除します。
oc delete csv <csv_name> -n <namespace>
$ oc delete csv <csv_name> -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-marketplace
namespace の失敗したジョブおよび関連する config map の名前を取得します。oc get job,configmap -n openshift-marketplace
$ oc get job,configmap -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME COMPLETIONS DURATION AGE job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb 1/1 26s 9m30s NAME DATA AGE configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb 3 9m30s
NAME COMPLETIONS DURATION AGE job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb 1/1 26s 9m30s NAME DATA AGE configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb 3 9m30s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ジョブを削除します。
oc delete job <job_name> -n openshift-marketplace
$ oc delete job <job_name> -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow これにより、アクセスできないイメージのプルを試行する Pod は再作成されなくなります。
設定マップを削除します。
oc delete configmap <configmap_name> -n openshift-marketplace
$ oc delete configmap <configmap_name> -n openshift-marketplace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Web コンソールの OperatorHub を使用した Operator の再インストール
検証
Operator が正常に再インストールされていることを確認します。
oc get sub,csv,installplan -n <namespace>
$ oc get sub,csv,installplan -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.12.8. アンインストール失敗後の Operator の再インストール リンクのコピーリンクがクリップボードにコピーされました!
同じ Operator の再インストールを試行する前に、Operator を正常かつ完全にアンインストールする必要があります。Operator を適切かつ完全にアンインストールできていない場合、プロジェクトや namespace などのリソースが "Terminating" ステータスでスタックし、"error resolving resource" メッセージが表示されます。以下に例を示します。
Project
リソースの説明例
... message: 'Failed to delete all resource types, 1 remaining: Internal error occurred: error resolving resource' ...
...
message: 'Failed to delete all resource types, 1 remaining: Internal error occurred:
error resolving resource'
...
これらのタイプの問題は、Operator の正常な再インストールを妨げる可能性があります。
namespace を強制的に削除しても、"Terminating" 状態の問題が解決される可能性は低く、クラスターの動作が不安定または予測不能になる可能性があるため、namespace の削除を妨げている可能性のある関連リソースの特定に注力することが推奨されます。詳細は、Red Hat Knowledgebase Solution #4165791 を参照し、特に注意と警告に注目してください。
次の手順では、以前インストールされた Operator からの既存カスタムリソース定義 (CRD) が原因で関連する namespace が正常に削除されないために Operator を再インストールできない場合のトラブルシューティングを示します。
手順
"Terminating" 状態のままになっている Operator に関連する namespace があるかどうかを確認します。
oc get namespaces
$ oc get namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
operator-ns-1 Terminating
operator-ns-1 Terminating
Copy to Clipboard Copied! Toggle word wrap Toggle overflow アンインストールの失敗後も Operator に関連する CRD があるか確認します。
oc get crds
$ oc get crds
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記CRD はグローバルクラスター定義です。CRD に関連する実際のカスタムリソース (CR) インスタンスは、他の namespace にあるか、グローバルクラスターインスタンスである可能性があります。
Operator によって提供または管理されている CRD があり、その CRD をアンインストール後に削除する必要がある場合は、CRD を削除します。
oc delete crd <crd_name>
$ oc delete crd <crd_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow アンインストールした後も Operator に関連する CR インスタンスが残っているか確認し、残っている場合は CR を削除します。
アンインストール後は、検索する CR のタイプの判断が困難になり、Operator が管理する CRD を把握している必要がある場合もあります。たとえば、
EtcdCluster
CRD を提供する etcd Operator のアンインストールをトラブルシューティングする場合、namespace で残りのEtcdCluster
CR を検索できます。oc get EtcdCluster -n <namespace_name>
$ oc get EtcdCluster -n <namespace_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow もしくは、すべての namespace で検索できます。
oc get EtcdCluster --all-namespaces
$ oc get EtcdCluster --all-namespaces
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 削除する必要のある CR が残っている場合は、インスタンスを削除します。
oc delete <cr_name> <cr_instance_name> -n <namespace_name>
$ oc delete <cr_name> <cr_instance_name> -n <namespace_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
namespace の削除が正常に解決されたことを確認します。
oc get namespace <namespace_name>
$ oc get namespace <namespace_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要namespace やその他の Operator リソースが正常にアンインストールされていない場合は、Red Hat サポートにお問い合わせください。
- Web コンソールの OperatorHub を使用した Operator の再インストール
検証
Operator が正常に再インストールされていることを確認します。
oc get sub,csv,installplan -n <namespace>
$ oc get sub,csv,installplan -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第5章 Operator の開発 リンクのコピーリンクがクリップボードにコピーされました!
5.1. トークン認証 リンクのコピーリンクがクリップボードにコピーされました!
5.1.1. クラウドプロバイダー上の Operator のトークン認証 リンクのコピーリンクがクリップボードにコピーされました!
多くのクラウドプロバイダーは、短期的で権限が限定されたセキュリティー認証情報を提供するアカウントトークンを使用して認証を有効にできます。
OpenShift Container Platform には、クラウドプロバイダーの認証情報をカスタムリソース定義 (CRD) として管理するための Cloud Credential Operator (CCO) が含まれています。CCO は CredentialsRequest
カスタムリソース (CR) と同期して、OpenShift Container Platform コンポーネントが必要な特定のパーミッションを持つクラウドプロバイダーの認証情報をリクエストできるようにします。
以前は、CCO が 手動モード のクラスターでは、Operator Lifecycle Manager (OLM) によって管理される Operator が、ユーザーが必要なクラウド認証情報を手動でプロビジョニングする方法に関する詳細な手順を OperatorHub に提供することがよくありました。
OpenShift Container Platform 4.14 以降、CCO は、特定のクラウドプロバイダーで短期認証情報の使用が有効になっているクラスター上で CCO が実行していることを検出できるようになりました。その後、Operator の作成者が Operator が更新された CCO をサポートできるようにしている場合は、特定の認証情報のプロビジョニングを半自動化できます。
5.1.2. AWS STS を使用した OLM 管理 Operator 向けの CCO ベースのワークフロー リンクのコピーリンクがクリップボードにコピーされました!
AWS 上で実行している OpenShift Container Platform クラスターが Security Token Service (STS) モードである場合、クラスターは AWS と OpenShift Container Platform の機能を利用して、アプリケーションレベルで IAM ロールを使用していることを意味します。STS を使用すると、アプリケーションは IAM ロールを引き受けることができる JSON Web トークン (JWT) を提供できます。
JWT には、サービスアカウントに一時的に許可されるパーミッションを許可する sts:AssumeRoleWithWebIdentity
IAM アクションの Amazon Resource Name (ARN) が含まれています。JWT には、AWS IAM が検証できる ProjectedServiceAccountToken
の署名キーが含まれています。署名されたサービスアカウントトークン自体は、AWS ロールを引き受けるために必要な JWT として使用されます。
Cloud Credential Operator (CCO) は、クラウドプロバイダー上で実行している OpenShift Container Platform クラスターにデフォルトでインストールされる Cluster Operator です。CCO は STS のために次の機能を提供します。
- CCO が STS 対応のクラスター上で実行されているかどうかを検出する
-
CredentialsRequest
オブジェクトをチェックして、Operator に AWS リソースへのアクセスを許可するために必要な情報を提供するフィールドが存在するかどうかを確認する
CCO は、手動モードの場合でもこの検出を実行します。適切に設定されている場合、CCO は必要なアクセス情報を含む Secret
オブジェクトを Operator namespace に投影します。
OpenShift Container Platform 4.14 以降、CCO は、STS ワークフローに必要な情報を含む Secrets
の作成を要求できる CredentialsRequest
オブジェクトの使用を拡張することで、このタスクを半自動化できるようになりました。ユーザーは、Web コンソールまたは CLI から Operator をインストールするときにロール ARN を指定できます。
更新の自動承認を使用したサブスクリプションは推奨されません。更新前に権限の変更が必要な場合があるためです。更新の手動承認を使用したサブスクリプションであれば、管理者が新しいバージョンの権限を確認し、必要な手順を実行してから更新できます。
OpenShift Container Platform 4.14 以降の更新された CCO と一緒に使用するために Operator を準備する Operator 作成者は、STS トークン認証の処理に加えて、ユーザーに指示し、以前の CCO バージョンからの相違を処理するコードを追加する必要があります (Operator がまだ STS 未対応の場合)。推奨される方法は、STS 関連のフィールドを正しく入力した CredentialsRequest
オブジェクトを用意して、CCO に Secret
を作成させることです。
バージョン 4.14 より前の OpenShift Container Platform クラスターをサポートする予定がる場合は、CCO ユーティリティー (ccoctl
) を使用して STS 対応情報を含むシークレットを手動で作成する方法をユーザーに提供することを検討してください。以前の CCO バージョンはクラスター上の STS モードを認識しないため、シークレットを作成できません。
コードでは、決して表示されないシークレットをチェックし、提供したフォールバック手順に従うようにユーザーに警告する必要があります。詳細は、「代替方法」サブセクションを参照してください。
5.1.2.1. Operator が AWS STS を使用した CCO ベースのワークフローをサポートできるようにする リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) で実行するプロジェクトを設計する Operator 作成者は、Cloud Credential Operator (CCO) をサポートするようにプロジェクトをカスタマイズすることで、STS 対応の OpenShift Container Platform クラスター上で Operator が AWS に対して認証できるようにすることができます。
この方法では、Operator が CredentialsRequest
オブジェクトを作成します。Operator には、オブジェクトを作成するための RBAC 権限と、生成される Secret
オブジェクトを読み取るための RBAC 権限が必要です。
デフォルトでは、Operator デプロイメントに関連する Pod は、生成される Secret
オブジェクトでサービスアカウントトークンを参照できるように、serviceAccountToken
ボリュームをマウントします。
前提条件
- OpenShift Container Platform 4.14 以降
- STS モードのクラスター
- OLM ベースの Operator プロジェクト
手順
Operator プロジェクトの
ClusterServiceVersion
(CSV) オブジェクトを更新します。Operator が
CredentialsRequests
オブジェクトを作成する RBAC 権限を持っていることを確認します。例5.1
clusterPermissions
リストの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow AWS STS を使用したこの CCO ベースのワークフロー方式のサポートを要求するために、次のアノテーションを追加します。
# ... metadata: annotations: features.operators.openshift.io/token-auth-aws: "true"
# ... metadata: annotations: features.operators.openshift.io/token-auth-aws: "true"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator プロジェクトコードを更新します。
Subscription
オブジェクトによって Pod に設定された環境変数からロール ARN を取得します。以下に例を示します。// Get ENV var roleARN := os.Getenv("ROLEARN") setupLog.Info("getting role ARN", "role ARN = ", roleARN) webIdentityTokenPath := "/var/run/secrets/openshift/serviceaccount/token"
// Get ENV var roleARN := os.Getenv("ROLEARN") setupLog.Info("getting role ARN", "role ARN = ", roleARN) webIdentityTokenPath := "/var/run/secrets/openshift/serviceaccount/token"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow パッチを適用して適用できる
CredentialsRequest
オブジェクトがあることを確認してください。以下に例を示します。例5.2
CredentialsRequest
オブジェクトの作成例Copy to Clipboard Copied! Toggle word wrap Toggle overflow あるいは、YAML 形式の
CredentialsRequest
オブジェクトから開始している場合 (たとえば、Operator プロジェクトコードの一部として)、別の方法で処理することもできます。例5.3 YAML フォームでの
CredentialsRequest
オブジェクト作成の例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記CredentialsRequest
オブジェクトを Operator バンドルに追加することは現在サポートされていません。ロール ARN と Web ID トークンパスを認証情報リクエストに追加し、Operator の初期化中に適用します。
例5.4 Operator の初期化中に
CredentialsRequest
オブジェクトを適用する例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例に示すように、Operator が CCO から
Secret
オブジェクトが表示されるのを待機できるようにします。これは、Operator で調整している他の項目とともに呼び出されます。例5.5
Secret
オブジェクトを待機する例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
timeout
値は、CCO が追加されたCredentialsRequest
オブジェクトを検出してSecret
オブジェクトを生成する速度の推定に基づいています。Operator がまだクラウドリソースにアクセスしていない理由を疑問に思っているクラスター管理者のために、時間を短縮するか、カスタムフィードバックを作成することを検討してください。
認証情報リクエストから CCO によって作成されたシークレットを読み取り、そのシークレットのデータを含む AWS 設定ファイルを作成することで、AWS 設定をセットアップします。
例5.6 AWS 設定の作成例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要シークレットは存在すると想定されますが、このシークレットを使用する場合、CCO がシークレットを作成する時間を与えるために、Operator コードは待機して再試行する必要があります。
さらに、待機期間は最終的にタイムアウトになり、OpenShift Container Platform クラスターのバージョン、つまり CCO が、STS 検出による
CredentialsRequest
オブジェクトのワークフローをサポートしていない以前のバージョンである可能性があることをユーザーに警告します。このような場合は、別の方法を使用してシークレットを追加する必要があることをユーザーに指示します。AWS SDK セッションを設定します。以下に例を示します。
例5.7 AWS SDK セッション設定の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.1.2.2. ロールの指定 リンクのコピーリンクがクリップボードにコピーされました!
Operator の説明には、インストール前に作成する必要があるロールの詳細を、理想的には管理者が実行できるスクリプトの形式で含める必要があります。以下に例を示します。
例5.8 ロール作成スクリプトの例
5.1.2.3. トラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
5.1.2.3.1. 認証失敗 リンクのコピーリンクがクリップボードにコピーされました!
認証が成功しなかった場合は、Operator に提供されたトークンを使用して、Web ID でロールを引き受けることができることを確認してください。
手順
Pod からトークンを抽出します。
oc exec operator-pod -n <namespace_name> \ -- cat /var/run/secrets/openshift/serviceaccount/token
$ oc exec operator-pod -n <namespace_name> \ -- cat /var/run/secrets/openshift/serviceaccount/token
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod からロール ARN を抽出します。
oc exec operator-pod -n <namespace_name> \ -- cat /<path>/<to>/<secret_name>
$ oc exec operator-pod -n <namespace_name> \ -- cat /<path>/<to>/<secret_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- パスに root を使用しないでください。
Web ID トークンを使用してロールを引き受けてみます。
aws sts assume-role-with-web-identity \ --role-arn $ROLEARN \ --role-session-name <session_name> \ --web-identity-token $TOKEN
$ aws sts assume-role-with-web-identity \ --role-arn $ROLEARN \ --role-session-name <session_name> \ --web-identity-token $TOKEN
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.1.2.3.2. Secret が正しくマウントされていない リンクのコピーリンクがクリップボードにコピーされました!
非 root ユーザーとして実行する Pod は、デフォルトで AWS 共有認証情報ファイルが存在すると想定される /root
ディレクトリーに書き込むことができません。シークレットが AWS 認証情報ファイルのパスに正しくマウントされていない場合は、シークレットを別の場所にマウントし、AWS SDK で共有認証情報ファイルオプションを有効にすることを検討してください。
5.1.2.4. 代替方法 リンクのコピーリンクがクリップボードにコピーされました!
Operator 作成者向けの代替方法として、Operator をインストールする前に、ユーザーが Cloud Credential Operator (CCO) の CredentialsRequest
オブジェクトを作成する責任があることを示すことができます。
Operator の指示では、ユーザーに次のことを示す必要があります。
-
手順に YAML をインラインで指定するか、ユーザーにダウンロード場所を示すことで、
CredentialsRequest
オブジェクトの YAML バージョンを提供します。 -
ユーザーに
CredentialsRequest
オブジェクトを作成するように指示します。
OpenShift Container Platform 4.14 以降では、適切な STS 情報が追加された CredentialsRequest
オブジェクトがクラスター上に表示されると、Operator は CCO が生成した Secret
を読み取るか、クラスターサービスバージョン (CSV) でマウントを定義してマウントすることができます。
OpenShift Container Platform の以前のバージョンでは、Operator の指示でユーザーに次のことも示す必要があります。
-
CCO ユーティリティー (
ccoctl
) を使用して、CredentialsRequest
オブジェクトからSecret
YAML オブジェクトを生成します。 -
Secret
オブジェクトを適切な namespace のクラスターに適用します。
Operator は、クラウド API と通信するために、結果として得られるシークレットを利用できる必要があります。この場合、シークレットは Operator がインストールされる前にユーザーによって作成されるため、Operator は次のいずれかを実行できます。
-
CSV 内の
Deployment
オブジェクトで明示的なマウントを定義します。 -
推奨される「AWS STS を使用して Operator が CCO ベースのワークフローをサポートできるようにする」方法に示すように、API サーバーからプログラムで
Secret
オブジェクトを読み取ります。
5.1.3. Microsoft Entra Workload ID を使用した OLM 管理 Operator 向けの CCO ベースのワークフロー リンクのコピーリンクがクリップボードにコピーされました!
Azure 上で実行されている OpenShift Container Platform クラスターが Workload Identity/Federated Identity モードである場合、そのクラスターは、Azure と OpenShift Container Platform の機能を利用して、Microsoft Entra Workload ID の ユーザー割り当てマネージド ID または アプリケーション登録 をアプリケーションレベルで適用しています。
Cloud Credential Operator (CCO) は、クラウドプロバイダー上で実行している OpenShift Container Platform クラスターにデフォルトでインストールされる Cluster Operator です。OpenShift Container Platform 4.14.8 以降、CCO は Workload ID を使用した OLM 管理 Operator のワークフローをサポートします。
CCO は Workload ID のために次の機能を提供します。
- CCO が Workload ID 対応のクラスター上で実行されているかどうかを検出する
-
CredentialsRequest
オブジェクトをチェックして、Operator に Azure リソースへのアクセスを許可するために必要な情報を提供するフィールドが存在するかどうかを確認する
CCO は、CredentialsRequest
オブジェクトの使用を拡張することで、このプロセスを半自動化できます。このオブジェクトにより、Workload ID ワークフローに必要な情報を含む Secrets
の作成を要求できます。
更新の自動承認を使用したサブスクリプションは推奨されません。更新前に権限の変更が必要な場合があるためです。更新の手動承認を使用したサブスクリプションであれば、管理者が新しいバージョンの権限を確認し、必要な手順を実行してから更新できます。
Operator 作成者は、OpenShift Container Platform 4.14 以降の更新された CCO と一緒に使用する Operator を準備する際に、Workload ID トークン認証への対処 (Operator がまだ未対応の場合) に加えて、ユーザーに指示し、以前の CCO バージョンからの相違を処理するコードを追加する必要があります。推奨される方法は、Workload ID 関連のフィールドを正しく入力した CredentialsRequest
オブジェクトを用意して、CCO に Secret
オブジェクトを作成させることです。
バージョン 4.14 より前の OpenShift Container Platform クラスターをサポートする予定がる場合は、CCO ユーティリティー (ccoctl
) を使用して Workload ID 対応情報を含むシークレットを手動で作成する方法をユーザーに提供することを検討してください。以前の CCO バージョンはクラスター上の Workload ID モードを認識しないため、シークレットを作成できません。
コードでは、決して表示されないシークレットをチェックし、提供したフォールバック手順に従うようにユーザーに警告する必要があります。
Workload ID による認証には次の情報が必要です。
-
azure_client_id
-
azure_tenant_id
-
azure_region
-
azure_subscription_id
-
azure_federated_token_file
クラスター管理者は、Web コンソールの Install Operator ページを使用してこの情報をインストール時に提供できます。その場合、この情報は、Operator Pod の環境変数として Subscription
オブジェクトに伝播されます。
5.1.3.1. Operator が Microsoft Entra Workload ID を使用した CCO ベースのワークフローをサポートできるようにする リンクのコピーリンクがクリップボードにコピーされました!
Operator 作成者は、Operator Lifecycle Manager (OLM) で実行するプロジェクトを設計する際に、Cloud Credential Operator (CCO) をサポートするようにプロジェクトをカスタマイズすることで、Microsoft Entra Workload ID 対応の OpenShift Container Platform クラスターに対して Operator が認証できるようにすることができます。
この方法では、Operator が CredentialsRequest
オブジェクトを作成します。Operator には、オブジェクトを作成するための RBAC 権限と、生成される Secret
オブジェクトを読み取るための RBAC 権限が必要です。
デフォルトでは、Operator デプロイメントに関連する Pod は、生成される Secret
オブジェクトでサービスアカウントトークンを参照できるように、serviceAccountToken
ボリュームをマウントします。
前提条件
- OpenShift Container Platform 4.14 以降
- Workload ID モードのクラスター
- OLM ベースの Operator プロジェクト
手順
Operator プロジェクトの
ClusterServiceVersion
(CSV) オブジェクトを更新します。Operator が
CredentialsRequests
オブジェクトを作成する RBAC 権限を持っていることを確認します。例5.9
clusterPermissions
リストの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow Workload ID を使用したこの CCO ベースのワークフロー方式のサポートを要求するために、次のアノテーションを追加します。
# ... metadata: annotations: features.operators.openshift.io/token-auth-azure: "true"
# ... metadata: annotations: features.operators.openshift.io/token-auth-azure: "true"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator プロジェクトコードを更新します。
Subscription
オブジェクトによって Pod に設定された環境変数からクライアント ID、テナント ID、およびサブスクリプション ID を取得します。以下に例を示します。// Get ENV var clientID := os.Getenv("CLIENTID") tenantID := os.Getenv("TENANTID") subscriptionID := os.Getenv("SUBSCRIPTIONID") azureFederatedTokenFile := "/var/run/secrets/openshift/serviceaccount/token"
// Get ENV var clientID := os.Getenv("CLIENTID") tenantID := os.Getenv("TENANTID") subscriptionID := os.Getenv("SUBSCRIPTIONID") azureFederatedTokenFile := "/var/run/secrets/openshift/serviceaccount/token"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow パッチを適用して適用できる
CredentialsRequest
オブジェクトがあることを確認してください。注記CredentialsRequest
オブジェクトを Operator バンドルに追加することは現在サポートされていません。Azure 認証情報と Web ID トークンパスを認証情報リクエストに追加し、Operator の初期化中に適用します。
例5.10 Operator の初期化中に
CredentialsRequest
オブジェクトを適用する例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例に示すように、Operator が CCO から
Secret
オブジェクトが表示されるのを待機できるようにします。これは、Operator で調整している他の項目とともに呼び出されます。例5.11
Secret
オブジェクトを待機する例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
timeout
値は、CCO が追加されたCredentialsRequest
オブジェクトを検出してSecret
オブジェクトを生成する速度の推定に基づいています。Operator がまだクラウドリソースにアクセスしていない理由を疑問に思っているクラスター管理者のために、時間を短縮するか、カスタムフィードバックを作成することを検討してください。
-
CCO によって作成されたシークレットを
CredentialsRequest
オブジェクトから読み取り、Azure で認証して、必要な認証情報を受け取ります。
5.1.4. GCP Workload Identity を使用した OLM 管理 Operator 向けの CCO ベースのワークフロー リンクのコピーリンクがクリップボードにコピーされました!
Google Cloud Platform (GCP) 上で実行されている OpenShift Container Platform クラスターが GCP Workload Identity / Federated Identity モードである場合、そのクラスターは、Google Cloud Platform (GCP) と OpenShift Container Platform の機能を利用して、アプリケーションレベルで GCP Workload Identity の権限を適用しています。
Cloud Credential Operator (CCO) は、クラウドプロバイダー上で実行している OpenShift Container Platform クラスターにデフォルトでインストールされる Cluster Operator です。OpenShift Container Platform 4.17 以降、CCO は GCP Workload Identity を使用した OLM 管理 Operator のワークフローをサポートします。
CCO は GCP Workload Identity のために次の機能を提供します。
- CCO が GCP Workload Identity 対応のクラスター上で実行されているかどうかを検出する
-
CredentialsRequest
オブジェクトをチェックして、Operator に GCP リソースへのアクセスを許可するために必要な情報を提供するフィールドが存在するかどうかを確認する
CCO は、CredentialsRequest
オブジェクトの使用を拡張することで、このプロセスを半自動化できます。このオブジェクトにより、GCP Workload Identity ワークフローに必要な情報を含む Secrets
の作成を要求できます。
更新の自動承認を使用したサブスクリプションは推奨されません。更新前に権限の変更が必要な場合があるためです。更新の手動承認を使用したサブスクリプションであれば、管理者が新しいバージョンの権限を確認し、必要な手順を実行してから更新できます。
Operator 作成者は、OpenShift Container Platform 4.17 以降の更新された CCO と一緒に使用する Operator を準備する際に、GCP Workload Identity トークン認証への対処 (Operator がまだ未対応の場合) に加えて、ユーザーに指示し、以前の CCO バージョンからの相違を処理するコードを追加する必要があります。推奨される方法は、GCP Workload Identity 関連のフィールドを正しく入力した CredentialsRequest
オブジェクトを用意して、CCO に Secret
オブジェクトを作成させることです。
バージョン 4.17 より前の OpenShift Container Platform クラスターをサポートする予定がある場合は、CCO ユーティリティー (ccoctl
) を使用して GCP Workload Identity 対応情報を含むシークレットを手動で作成する方法をユーザーに提供することを検討してください。以前の CCO バージョンは、クラスター上の GCP Workload Identity モードを認識しないため、シークレットを作成できません。
コードでは、決して表示されないシークレットをチェックし、提供したフォールバック手順に従うようにユーザーに警告する必要があります。
Google Cloud Platform Workload Identity を介して有効期間の短いトークンを使用して GCP で認証するには、Operator によって次の情報を提供する必要があります。
AUDIENCE
AUDIENCE
値は、管理者が GCP Workload Identity を設定するときに GCP で作成し、次の形式で事前にフォーマットした URL である必要があります。//iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/<pool_id>/providers/<provider_id>
//iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/<pool_id>/providers/<provider_id>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SERVICE_ACCOUNT_EMAIL
SERVICE_ACCOUNT_EMAIL
値は、Operator 操作中に権限を借用する GCP サービスアカウントのメールアドレスです。次に例を示します。<service_account_name>@<project_id>.iam.gserviceaccount.com
<service_account_name>@<project_id>.iam.gserviceaccount.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
クラスター管理者は、Web コンソールの Install Operator ページを使用してこの情報をインストール時に提供できます。その場合、この情報は、Operator Pod の環境変数として Subscription
オブジェクトに伝播されます。
5.1.4.1. Operator が GCP Workload Identity を使用した CCO ベースのワークフローをサポートできるようにする リンクのコピーリンクがクリップボードにコピーされました!
Operator 作成者は、Operator Lifecycle Manager (OLM) で実行するプロジェクトを設計する際に、Cloud Credential Operator (CCO) をサポートするようにプロジェクトをカスタマイズすることで、OpenShift Container Platform クラスター上の Google Cloud Platform Workload Identity に対して Operator が認証できるようにすることができます。
この方法では、Operator が CredentialsRequest
オブジェクトを作成します。Operator には、オブジェクトを作成するための RBAC 権限と、生成される Secret
オブジェクトを読み取るための RBAC 権限が必要です。
デフォルトでは、Operator デプロイメントに関連する Pod は、生成される Secret
オブジェクトでサービスアカウントトークンを参照できるように、serviceAccountToken
ボリュームをマウントします。
前提条件
- OpenShift Container Platform 4.17 以降
- GCP Workload Identity / Federated Identity モードのクラスター
- OLM ベースの Operator プロジェクト
手順
Operator プロジェクトの
ClusterServiceVersion
(CSV) オブジェクトを更新します。Operator が Web ID でロールを引き受けることができるように、CSV 内の Operator デプロイメントに次の
volumeMounts
およびvolumes
フィールドがあることを確認します。例5.12
volumeMounts
およびvolumes
フィールドの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator が
CredentialsRequests
オブジェクトを作成する RBAC 権限を持っていることを確認します。例5.13
clusterPermissions
リストの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow GCP Workload Identity を使用したこの CCO ベースのワークフロー方式のサポートを要求するために、次のアノテーションを追加します。
# ... metadata: annotations: features.operators.openshift.io/token-auth-gcp: "true"
# ... metadata: annotations: features.operators.openshift.io/token-auth-gcp: "true"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator プロジェクトコードを更新します。
サブスクリプション設定によって Pod に設定された環境変数から
audience
とserviceAccountEmail
の値を取得します。// Get ENV var audience := os.Getenv("AUDIENCE") serviceAccountEmail := os.Getenv("SERVICE_ACCOUNT_EMAIL") gcpIdentityTokenFile := "/var/run/secrets/openshift/serviceaccount/token"
// Get ENV var audience := os.Getenv("AUDIENCE") serviceAccountEmail := os.Getenv("SERVICE_ACCOUNT_EMAIL") gcpIdentityTokenFile := "/var/run/secrets/openshift/serviceaccount/token"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow パッチを適用して適用できる
CredentialsRequest
オブジェクトがあることを確認してください。注記CredentialsRequest
オブジェクトを Operator バンドルに追加することは現在サポートされていません。GCP Workload Identity の変数を認証情報リクエストに追加し、Operator の初期化中に適用します。
例5.14 Operator の初期化中に
CredentialsRequest
オブジェクトを適用する例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次の例に示すように、Operator が CCO から
Secret
オブジェクトが表示されるのを待機できるようにします。これは、Operator で調整している他の項目とともに呼び出されます。例5.15
Secret
オブジェクトを待機する例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
timeout
値は、CCO が追加されたCredentialsRequest
オブジェクトを検出してSecret
オブジェクトを生成する速度の推定に基づいています。Operator がまだクラウドリソースにアクセスしていない理由を疑問に思っているクラスター管理者のために、時間を短縮するか、カスタムフィードバックを作成することを検討してください。
シークレットから
service_account.json
フィールドを読み取り、それを使用して GCP クライアントを認証します。service_account_json := secret.StringData["service_account.json"]
service_account_json := secret.StringData["service_account.json"]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第6章 クラスター Operator のリファレンス リンクのコピーリンクがクリップボードにコピーされました!
このリファレンスガイドは、OpenShift Container Platform のアーキテクチャー基盤として機能する、Red Hat が出荷する Cluster Operator のインデックスを作成します。Cluster Operator は、特に明記されていない限り、デフォルトでインストールされ、Cluster Version Operator (CVO) により管理されます。コントロールプレーンアーキテクチャーの詳細は、OpenShift Container Platform の Operator を参照してください。
クラスター管理者は、OpenShift Container Platform Web コンソールの Administration → Cluster Settings ページから Cluster Operator を表示できます。
Cluster Operator は、Operator Lifecycle Manager (OLM) および OperatorHub では管理されていません。OLM と OperatorHub は、Operator Framework の一部で、オプションの アドオン Operator のインストールおよび実行時に OpenShift Container Platform で使用されます。
以下の Cluster Operator の一部は、インストール前に無効にすることができます。詳細は、クラスター機能 を参照してください。
6.1. Cluster Baremetal Operator リンクのコピーリンクがクリップボードにコピーされました!
Cluster Baremetal Operator は、インストール中にクラスター管理者が無効にできる任意のクラスター機能です。オプションのクラスター機能の詳細は、インストール の「クラスター機能」を参照してください。
Cluster Baremetal Operator (CBO) は、OpenShift Container Platform コンピュートノードを実行する準備が整った、完全に機能するワーカーノードにベアメタルサーバーを導入するために必要なすべてのコンポーネントをデプロイします。CBO は、Bare Metal Operator (BMO) と Ironic コンテナーで構成される metal3 デプロイメントが、OpenShift Container Platform クラスター内のコントロールプレーンノードの 1 つで実行されるようにします。また、CBO は、監視し、適切なアクションを実行するリソースへの OpenShift Container Platform の更新をリッスンします。
6.1.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.2. Cloud Credential Operator リンクのコピーリンクがクリップボードにコピーされました!
Cloud Credential Operator (CCO) は、クラウドプロバイダーの認証情報を Kubernetes カスタムリソース定義 (CRD) として管理します。CCO は CredentialsRequest
カスタムリソース (CR) で同期し、OpenShift Container Platform コンポーネントが、クラスターの実行に必要な特定のパーミッションと共にクラウドプロバイダーの認証情報を要求できるようにします。
install-config.yaml
ファイルで credentialsMode
パラメーターに異なる値を設定すると、CCO は複数の異なるモードで動作するように設定できます。モードが指定されていない場合や、credentialsMode
パラメーターが空の文字列 (""
) に設定されている場合は、CCO はデフォルトモードで動作します。
6.2.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.2.2. CRD リンクのコピーリンクがクリップボードにコピーされました!
credentialsrequests.cloudcredential.openshift.io
- スコープ: Namespaced
-
CR:
CredentialsRequest
- 検証: Yes
6.2.3. 設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
必要な設定はありません。
6.3. Cluster Authentication Operator リンクのコピーリンクがクリップボードにコピーされました!
Cluster Authentication Operator は、クラスター内に Authentication
カスタムリソースをインストールし、維持します。これは、以下を使用して表示できます。
oc get clusteroperator authentication -o yaml
$ oc get clusteroperator authentication -o yaml
6.3.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.4. Cluster Autoscaler Operator リンクのコピーリンクがクリップボードにコピーされました!
Cluster Autoscaler Operator は cluster-api
プロバイダーを使用して OpenShift Cluster Autoscaler のデプロイメントを管理します。
6.4.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.4.2. CRD リンクのコピーリンクがクリップボードにコピーされました!
-
ClusterAutoscaler
: これは、クラスターの Autoscaler インスタンスの設定を制御するシングルトンリソースです。Operator は、管理された namespace のdefault
という名前のClusterAutoscaler
リソース (WATCH_NAMESPACE
環境変数の値) のみに応答します。 -
MachineAutoscaler
: このリソースはノードグループを対象にし、アノテーションを管理してグループの自動スケーリングを有効にし、設定します (min
およびmax
サイズ)。現時点では、MachineSet
オブジェクトのみをターゲットにすることができます。
6.5. Cloud Controller Manager Operator リンクのコピーリンクがクリップボードにコピーされました!
この Operator は、Amazon Web Services (AWS)、Google Cloud Platform (GCP)、IBM Cloud®、グローバル Microsoft Azure、Microsoft Azure Stack Hub、Nutanix、Red Hat OpenStack Platform (RHOSP)、および VMware vSphere 向けに一般提供されています。
この Operator は、IBM Power® Virtual Server では テクノロジープレビュー として提供されています。
Cloud Controller Manager Operator は、OpenShift Container Platform にデプロイされた Cloud Controller Manager を管理および更新します。Operator は Kubebuilder フレームワークおよび controller-runtime
ライブラリーに基づいています。Cluster Version Operator (CVO) を使用して、Cloud Controller Manager Operator をインストールできます。
Cloud Controller Manager Operator には、次のコンポーネントが含まれています。
- Operator
- クラウド設定のオブザーバー
デフォルトで、Operator は metrics
サービス経由で Prometheus メトリックを公開します。
6.5.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.6. Cluster CAPI Operator リンクのコピーリンクがクリップボードにコピーされました!
Cluster CAPI Operator は Cluster API リソースのライフサイクルを維持します。この Operator は、OpenShift Container Platform クラスター内での Cluster API プロジェクトのデプロイに関連するすべての管理タスクを行います。
この Operator は、Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、Red Hat OpenStack Platform (RHOSP)、および VMware vSphere クラスターの テクノロジープレビュー 機能として利用できます。
6.6.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.6.2. CRD リンクのコピーリンクがクリップボードにコピーされました!
awsmachines.infrastructure.cluster.x-k8s.io
- スコープ: Namespaced
-
CR:
awsmachine
gcpmachines.infrastructure.cluster.x-k8s.io
- スコープ: Namespaced
-
CR:
gcpmachine
azuremachines.infrastructure.cluster.x-k8s.io
- スコープ: Namespaced
-
CR:
azuremachine
openstackmachines.infrastructure.cluster.x-k8s.io
- スコープ: Namespaced
-
CR:
openstackmachine
vspheremachines.infrastructure.cluster.x-k8s.io
- スコープ: Namespaced
-
CR:
vspheremachine
metal3machines.infrastructure.cluster.x-k8s.io
- スコープ: Namespaced
-
CR:
metal3machine
awsmachinetemplates.infrastructure.cluster.x-k8s.io
- スコープ: Namespaced
-
CR:
awsmachinetemplate
gcpmachinetemplates.infrastructure.cluster.x-k8s.io
- スコープ: Namespaced
-
CR:
gcpmachinetemplate
azuremachinetemplates.infrastructure.cluster.x-k8s.io
- スコープ: Namespaced
-
CR:
azuremachinetemplate
openstackmachinetemplates.infrastructure.cluster.x-k8s.io
- スコープ: Namespaced
-
CR:
openstackmachinetemplate
vspheremachinetemplates.infrastructure.cluster.x-k8s.io
- スコープ: Namespaced
-
CR:
vspheremachinetemplate
metal3machinetemplates.infrastructure.cluster.x-k8s.io
- スコープ: Namespaced
-
CR:
metal3machinetemplate
6.7. Cluster Config Operator リンクのコピーリンクがクリップボードにコピーされました!
Cluster Config Operator は、config.openshift.io
に関連する以下のタスクを実行します。
- CRD を作成する。
- 最初のカスタムリソースをレンダリングする。
- 移行を処理する。
6.7.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.8. Cluster CSI Snapshot Controller Operator リンクのコピーリンクがクリップボードにコピーされました!
Cluster CSI Snapshot Controller Operator は、インストール中にクラスター管理者が無効にできるオプションのクラスター機能です。オプションのクラスター機能の詳細は、インストール の「クラスター機能」を参照してください。
Cluster CSI Snapshot Controller Operator は、CSI Snapshot Controller をインストールし、維持します。CSI Snapshot Controller は VolumeSnapshot
CRD オブジェクトを監視し、ボリュームスナップショットの作成および削除のライフサイクルを管理します。
6.8.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.9. Cluster Image Registry Operator リンクのコピーリンクがクリップボードにコピーされました!
Cluster Image Registry Operator は、OpenShift イメージレジストリーのシングルトンインスタンスを管理します。ストレージの作成を含む、レジストリーのすべての設定を管理します。
初回起動時に、Operator はクラスターで検出される設定に基づいてデフォルトの image-registry
リソースインスタンスを作成します。これは、クラウドプロバイダーに基づいて使用するクラウドストレージのタイプを示します。
完全な image-registry
リソースを定義するのに利用できる十分な情報がない場合は、その不完全なリソースが定義され、Operator は足りない情報を示す情報を使用してリソースのステータスを更新します。
Cluster Image Registry Operator は openshift-image-registry
namespace で実行され、その場所のレジストリーインスタンスも管理します。レジストリーのすべての設定およびワークロードリソースはその namespace に置かれます。
6.9.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.10. Cluster Machine Approver Operator リンクのコピーリンクがクリップボードにコピーされました!
Cluster Machine Approver Operator は、クラスターのインストール後に、新規ワーカーノードに要求された CSR を自動承認します。
コントロールプレーンノードの場合に、ブートストラップノードの approve-csr
サービスは、クラスターのブートストラップフェーズ時にすべての CSR を自動的に承認します。
6.10.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.11. Cluster Monitoring Operator リンクのコピーリンクがクリップボードにコピーされました!
Cluster Monitoring Operator (CMO) は、OpenShift Container Platform の上部にデプロイされた Prometheus ベースのクラスターモニタリングスタックを管理し、更新します。
プロジェクト
CRD
alertmanagers.monitoring.coreos.com
- スコープ: Namespaced
-
CR:
alertmanager
- 検証: Yes
prometheuses.monitoring.coreos.com
- スコープ: Namespaced
-
CR:
prometheus
- 検証: Yes
prometheusrules.monitoring.coreos.com
- スコープ: Namespaced
-
CR:
prometheusrule
- 検証: Yes
servicemonitors.monitoring.coreos.com
- スコープ: Namespaced
-
CR:
servicemonitor
- 検証: Yes
設定オブジェクト
oc -n openshift-monitoring edit cm cluster-monitoring-config
$ oc -n openshift-monitoring edit cm cluster-monitoring-config
6.12. Cluster Network Operator リンクのコピーリンクがクリップボードにコピーされました!
Cluster Network Operator は、OpenShift Container Platform クラスターでネットワークコンポーネントをインストールし、アップグレードします。
6.13. Cluster Samples Operator リンクのコピーリンクがクリップボードにコピーされました!
Cluster Samples Operator は、クラスター管理者がインストール中に無効にできるオプションのクラスター機能です。オプションのクラスター機能の詳細は、インストール の「クラスター機能」を参照してください。
Cluster Samples Operator は、openshift
namespace に保存されるサンプルイメージストリームおよびテンプレートを管理します。
初回起動時に、Operator はデフォルトのサンプル設定リソースを作成し、イメージストリームおよびテンプレートの作成を開始します。設定オブジェクトは、キーが cluster
で、タイプが configs.samples
のクラスタースコープのオブジェクトです。
イメージストリームは、registry.redhat.io
のイメージを参照する Red Hat Enterprise Linux CoreOS (RHCOS) ベースの OpenShift Container Platform イメージストリームです。同様に、テンプレートは OpenShift Container Platform テンプレートとして分類されます。
Cluster Samples Operator デプロイメントは openshift-cluster-samples-operator
namespace 内に含まれます。起動時に、インストールプルシークレットは OpenShift イメージレジストリーおよび API サーバーのイメージストリームのインポートロジックによって使用され、registry.redhat.io
で認証されます。管理者は、サンプルイメージストリームに使用されるレジストリーを変更する場合、追加のシークレットを openshift
namespace に作成できます。これらのシークレットが作成される場合、これらには、イメージのインポートを容易にするために必要な docker
の config.json
のコンテンツが含まれます。
Cluster Samples Operator のイメージには、関連付けられた OpenShift Container Platform リリースのイメージストリームおよびテンプレートの定義が含まれます。Cluster Samples Operator がサンプルを作成した後に、互換性のある OpenShift Container Platform バージョンを示すアノテーションを追加します。Operator はこのアノテーションを使用して、各サンプルを互換性のあるリリースバージョンに一致させるようにします。このインベントリーの外にあるサンプルは省略されるサンプルであるために無視されます。
Operator によって管理されるサンプルへの変更は、バージョンのアノテーションが変更または削除されない限り許可されます。ただし、アップグレード時に、バージョンアノテーションが変更されると、サンプルが新しいバージョンで更新されるため、これらの変更は置き換えられる可能性があります。Jenkins イメージはインストールからのイメージペイロードの一部であり、イメージストリームに直接タグ付けされます。
サンプルリソースには、削除時に以下を消去するファイナライザーが含まれます。
- Operator 管理のイメージストリーム
- Operator 管理のテンプレート
- Operator が生成する設定リソース
- クラスターステータスのリソース
サンプルリソースの削除時に、Cluster Samples Operator はデフォルト設定を使用してリソースを再作成します。
6.13.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.14. Cluster Storage Operator リンクのコピーリンクがクリップボードにコピーされました!
Cluster Storage Operator は、クラスター管理者がインストール中に無効にできるオプションのクラスター機能です。オプションのクラスター機能の詳細は、インストール の「クラスター機能」を参照してください。
Cluster Storage Operator は OpenShift Container Platform のクラスター全体のストレージのデフォルト値を設定します。これにより、OpenShift Container Platform クラスターのデフォルトの storageclass
の存在を確認できます。また、クラスターがさまざまなストレージバックエンドを使用できるようにする Container Storage Interface (CSI) ドライバーもインストールします。
6.14.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.14.2. 設定 リンクのコピーリンクがクリップボードにコピーされました!
必要な設定はありません。
6.14.3. 注記 リンクのコピーリンクがクリップボードにコピーされました!
- Operator が作成するストレージクラスは、そのアノテーションを編集することで非デフォルトにすることができますが、Operator が実行されているかぎり、このストレージクラスを削除することはできません。
6.15. Cluster Version Operator リンクのコピーリンクがクリップボードにコピーされました!
Cluster Operator は、クラスター機能の特定の領域を管理します。Cluster Version Operator (CVO) は Cluster Operator のライフサイクルを管理し、その多くはデフォルトで OpenShift Container Platform にインストールされます。
また、CVO は OpenShift Update Service をチェックし、クラスターバージョンとその Cluster Operator のステータスを収集して、現在のコンポーネントのバージョンとグラフの情報に基づき有効な更新と更新パスを確認します。このステータスには、OpenShift Container Platform クラスターの正常性と現在の状態を通知する条件タイプが含まれます。
クラスターバージョンの条件タイプに関する詳細は、「クラスターバージョンの条件タイプについて」を参照してください。
6.15.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.16. Console Operator リンクのコピーリンクがクリップボードにコピーされました!
Console Operator は、クラスター管理者がインストール中に無効にできるオプションのクラスター機能です。インストール時に Console Operator を無効にしても、クラスターは引き続きサポートされ、アップグレード可能です。オプションのクラスター機能の詳細は、インストール の「クラスター機能」を参照してください。
Console Operator は OpenShift Container Platform Web コンソールをクラスターにインストールし、維持します。Console Operator はデフォルトでインストールされ、コンソールを自動的に維持します。
6.16.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.17. Control Plane Machine Set Operator リンクのコピーリンクがクリップボードにコピーされました!
Control Plane Machine Set Operator は、OpenShift Container Platform クラスター内のコントロールプレーンマシンリソースの管理を自動化します。
この Operator は、Amazon Web Services (AWS)、Google Cloud Platform (GCP)、Microsoft Azure、Nutanix、および VMware vSphere で利用できます。
6.17.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.17.2. CRD リンクのコピーリンクがクリップボードにコピーされました!
controlplanemachineset.machine.openshift.io
- スコープ: Namespaced
-
CR:
ControlPlaneMachineSet
- 検証: Yes
6.18. DNS Operator リンクのコピーリンクがクリップボードにコピーされました!
DNS Operator は、Pod に対して名前解決サービスを提供するために CoreDNS をデプロイし、これを管理し、OpenShift Container Platform での DNS ベースの Kubernetes サービス検出を可能にします。
Operator は、クラスターの設定に基づいて作業用のデフォルトデプロイメントを作成します。
-
デフォルトのクラスタードメインは
cluster.local
です。 - CoreDNS Corefile または Kubernetes プラグインの設定はサポートされていません。
DNS Operator は、静的 IP を持つサービスとして公開される Kubernetes デーモンセットとして CoreDNS を管理します。CoreDNS は、クラスター内のすべてのノードで実行されます。
6.18.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.19. etcd cluster Operator リンクのコピーリンクがクリップボードにコピーされました!
etcd cluster Operator は etcd クラスターのスケーリングを自動化し、etcd モニタリングおよびメトリックを有効にし、障害復旧手順を単純化します。
6.19.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.19.2. CRD リンクのコピーリンクがクリップボードにコピーされました!
etcds.operator.openshift.io
- スコープ: Cluster
-
CR:
etcd
- 検証: Yes
6.19.3. 設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
oc edit etcd cluster
$ oc edit etcd cluster
6.20. Ingress Operator リンクのコピーリンクがクリップボードにコピーされました!
Ingress Operator は OpenShift Container Platform ルーターを設定し、管理します。
6.20.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.20.2. CRD リンクのコピーリンクがクリップボードにコピーされました!
clusteringresses.ingress.openshift.io
- スコープ: Namespaced
-
CR:
clusteringresses
- 検証: No
6.20.3. 設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
クラスター設定
-
タイプ名:
clusteringresses.ingress.openshift.io
-
インスタンス名:
default
コマンドの表示:
oc get clusteringresses.ingress.openshift.io -n openshift-ingress-operator default -o yaml
$ oc get clusteringresses.ingress.openshift.io -n openshift-ingress-operator default -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
タイプ名:
6.20.4. 注記 リンクのコピーリンクがクリップボードにコピーされました!
Ingress Operator はルーターを openshift-ingress
プロジェクトに設定し、ルーターのデプロイメントを作成します。
oc get deployment -n openshift-ingress
$ oc get deployment -n openshift-ingress
Ingress Operator は、network/cluster
ステータスの clusterNetwork[].cidr
を使用して、管理 Ingress Controller (ルーター) が動作するモード (IPv4、IPv6、またはデュアルスタック) を判別します。たとえば、clusterNetwork
に v6 cidr
のみが含まれる場合、Ingress Controller は IPv6 専用モードで動作します。
以下の例では、Ingress Operator に管理される Ingress Controller は、1 つのクラスターネットワークのみが存在し、ネットワークが IPv4 cidr
であるために IPv4 専用モードで実行されます。
oc get network/cluster -o jsonpath='{.status.clusterNetwork[*]}'
$ oc get network/cluster -o jsonpath='{.status.clusterNetwork[*]}'
出力例
map[cidr:10.128.0.0/14 hostPrefix:23]
map[cidr:10.128.0.0/14 hostPrefix:23]
6.21. Insights Operator リンクのコピーリンクがクリップボードにコピーされました!
Insights Operator は、クラスター管理者がインストール中に無効にできるオプションのクラスター機能です。オプションのクラスター機能の詳細は、インストール の「クラスター機能」を参照してください。
Insights Operator は OpenShift Container Platform の設定データを収集し、Red Hat に送信します。このデータは、クラスターの潜在的な問題に関する予防的な分析に基づいて推奨事項を生成するために使用されます。これらの情報は、console.redhat.com の Insights アドバイザーサービスを通じてクラスター管理者に伝えられます。
6.21.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.21.2. 設定 リンクのコピーリンクがクリップボードにコピーされました!
必要な設定はありません。
6.21.3. 注記 リンクのコピーリンクがクリップボードにコピーされました!
Insights Operator は、OpenShift Container Platform Telemetry を補完します。
6.22. Kubernetes API Server Operator リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes API Server Operator は、OpenShift Container Platform の上部にデプロイされた Kubernetes API サーバーを管理し、更新します。Operator は OpenShift Container Platform の library-go
フレームワークをベースとしており、Cluster Version Operator (CVO) でインストールされます。
6.22.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.22.2. CRD リンクのコピーリンクがクリップボードにコピーされました!
kubeapiservers.operator.openshift.io
- スコープ: Cluster
-
CR:
kubeapiserver
- 検証: Yes
6.22.3. 設定オブジェクト リンクのコピーリンクがクリップボードにコピーされました!
oc edit kubeapiserver
$ oc edit kubeapiserver
6.23. Kubernetes Controller Manager Operator リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes Controller Manager Operator は、OpenShift Container Platform にデプロイされた Kubernetes Controller Manager を管理し、更新します。Operator は OpenShift Container Platform の library-go
フレームワークをベースとしており、Cluster Version Operator (CVO) でインストールされます。
これには、以下のコンポーネントが含まれます。
- Operator
- ブートストラップマニフェストレンダラー
- 静的 Pod をベースとするインストーラー
- 設定オブザーバー
デフォルトで、Operator は metrics
サービス経由で Prometheus メトリックを公開します。
6.23.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.24. Kubernetes Scheduler Operator リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes Scheduler Operator は、OpenShift Container Platform の上部にデプロイされる Kubernetes スケジューラーを管理し、更新します。Operator は OpenShift Container Platform の library-go
フレームワークをベースとしており、Cluster Version Operator (CVO) でインストールされます。
Kubernetes Scheduler Operator には以下のコンポーネントが含まれます。
- Operator
- ブートストラップマニフェストレンダラー
- 静的 Pod をベースとするインストーラー
- 設定オブザーバー
デフォルトで、Operator はメトリックサービス経由で Prometheus メトリックを公開します。
6.24.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.24.2. 設定 リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes Scheduler の設定はマージの結果になります。
- デフォルト設定。
-
仕様
schedulers.config.openshift.io
からの観察される設定。
これらはすべてスパースな設定であり、最後に有効な設定を形成するためにマージされる無効にされた JSON スニペットです。
6.25. Kubernetes Storage Version Migrator Operator リンクのコピーリンクがクリップボードにコピーされました!
Kubernetes Storage Version Migrator Operator はデフォルトのストレージバージョンの変更を検出し、ストレージバージョンの変更時にリソースタイプの移行要求を作成し、移行要求を処理します。
6.25.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.26. Machine API Operator リンクのコピーリンクがクリップボードにコピーされました!
Machine API Operator は、Kubernetes API を拡張する特定の目的のカスタムリソース定義 (CRD)、コントローラー、および RBAC オブジェクトのライフサイクルを管理します。これにより、クラスター内のマシンの必要な状態が宣言されます。
6.26.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.26.2. CRD リンクのコピーリンクがクリップボードにコピーされました!
-
MachineSet
-
Machine
-
MachineHealthCheck
6.27. Machine Config Operator リンクのコピーリンクがクリップボードにコピーされました!
Machine Config Operator は、カーネルと kubelet 間のすべてのものを含め、ベースオペレーティングシステムおよびコンテナーランタイムの設定および更新を管理し、適用します。
以下の 4 つのコンポーネントがあります。
-
machine-config-server
: クラスターに参加する新規マシンに Ignition 設定を提供します。 -
machine-config-controller
: マシンのアップグレードをMachineConfig
オブジェクトで定義される必要な設定に調整します。マシンセットのアップグレードを個別に制御するオプションが提供されます。 -
machine-config-daemon
: 更新時に新規のマシン設定を適用します。マシンの状態を要求されたマシン設定に対して検証し、確認します。 -
machine-config
: インストール時のマシン設定の完全なソース、初回の起動、およびマシンの更新を提供します。
現在、マシン設定サーバーエンドポイントをブロックまたは制限する方法はサポートされていません。マシン設定サーバーは、既存の設定または状態を持たない新しくプロビジョニングされたマシンが設定を取得できるように、ネットワークに公開する必要があります。このモデルでは、信頼のルートは証明書署名要求 (CSR) エンドポイントであり、kubelet がクラスターに参加するための承認のために証明書署名要求を送信する場所です。このため、シークレットや証明書などの機密情報を配布するためにマシン設定を使用しないでください。
マシン設定サーバーエンドポイント、ポート 22623 および 22624 がベアメタルシナリオで確実に保護されるようにするには、顧客は適切なネットワークポリシーを設定する必要があります。
6.27.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.28. Marketplace Operator リンクのコピーリンクがクリップボードにコピーされました!
Marketplace Operator は、クラスター管理者が不要な場合に無効にできるオプションのクラスター機能です。オプションのクラスター機能の詳細は、インストール の「クラスター機能」を参照してください。
Marketplace Operator は、クラスター上の一連のデフォルトの Operator Lifecycle Manager (OLM) カタログを使用して、クラスター外の Operator をクラスターに持ち込むプロセスを簡素化します。Marketplace Operator がインストールされると、openshift-marketplace
namespace が作成されます。OLM は、openshift-marketplace
namespace にインストールされたカタログソースがクラスター上のすべての namespace で利用可能であることを保証します。
6.28.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.29. Node Tuning Operator リンクのコピーリンクがクリップボードにコピーされました!
Node Tuning Operator は、TuneD デーモンを調整することでノードレベルのチューニングを管理し、Performance Profile コントローラーを使用して低レイテンシーのパフォーマンスを実現するのに役立ちます。ほとんどの高パフォーマンスアプリケーションでは、一定レベルのカーネルのチューニングが必要です。Node Tuning Operator は、ノードレベルの sysctl の統一された管理インターフェイスをユーザーに提供し、ユーザーが指定するカスタムチューニングを追加できるよう柔軟性を提供します。
Operator は、コンテナー化された OpenShift Container Platform の TuneD デーモンを Kubernetes デーモンセットとして管理します。これにより、カスタムチューニング仕様が、デーモンが認識する形式でクラスターで実行されるすべてのコンテナー化された TuneD デーモンに渡されます。デーモンは、ノードごとに 1 つずつ、クラスターのすべてのノードで実行されます。
コンテナー化された TuneD デーモンによって適用されるノードレベルの設定は、プロファイルの変更をトリガーするイベントで、または終了シグナルの受信および処理によってコンテナー化された TuneD デーモンが正常に終了する際にロールバックされます。
Node Tuning Operator は、パフォーマンスプロファイルコントローラーを使用して自動チューニングを実装し、OpenShift Container Platform アプリケーションの低レイテンシーパフォーマンスを実現します。
クラスター管理者は、以下のようなノードレベルの設定を定義するパフォーマンスプロファイルを設定します。
- カーネルを kernel-rt に更新します。
- ハウスキーピング用の CPU を選択します。
- 実行中のワークロード用の CPU を選択します。
Node Tuning Operator は、バージョン 4.1 以降における標準的な OpenShift Container Platform インストールの一部となっています。
OpenShift Container Platform の以前のバージョンでは、Performance Addon Operator を使用して自動チューニングを実装し、OpenShift アプリケーションの低レイテンシーパフォーマンスを実現していました。OpenShift Container Platform 4.11 以降では、この機能は Node Tuning Operator の一部です。
6.29.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.30. OpenShift API Server Operator リンクのコピーリンクがクリップボードにコピーされました!
OpenShift API Server Operator は、クラスターに openshift-apiserver
をインストールし、維持します。
6.30.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.30.2. CRD リンクのコピーリンクがクリップボードにコピーされました!
openshiftapiservers.operator.openshift.io
- スコープ: Cluster
-
CR:
openshiftapiserver
- 検証: Yes
6.31. OpenShift Controller Manager Operator リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Controller Manager Operator は OpenShiftControllerManager
カスタムリソースをクラスターにインストールし、これを維持します。これは、以下で表示できます。
oc get clusteroperator openshift-controller-manager -o yaml
$ oc get clusteroperator openshift-controller-manager -o yaml
カスタムリソース定義 (CRD) openshiftcontrollermanagers.operator.openshift.io
は以下を使用してクラスターで確認できます。
oc get crd openshiftcontrollermanagers.operator.openshift.io -o yaml
$ oc get crd openshiftcontrollermanagers.operator.openshift.io -o yaml
6.31.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.32. Operator Lifecycle Manager (OLM) Classic Operator リンクのコピーリンクがクリップボードにコピーされました!
以下のセクションは、OpenShift Container Platform 4 の最初のリリース以降に同梱されている Operator Lifecycle Manager (OLM) Classic に関するものです。OLM v1 は、Operator Lifecycle Manager (OLM) v1 Operator を参照してください。
Operator Lifecycle Manager (OLM) Classic は、ユーザーが OpenShift Container Platform クラスター全体で実行される Kubernetes ネイティブアプリケーション (Operator) と関連サービスをインストール、更新、およびそれらのライフサイクルを管理するのに役立ちます。これは、Operator を効果的かつ自動化された拡張可能な方法で管理するために設計されたオープンソースツールキットの Operator Framework の一部です。
図6.1 OLM (Classic) ワークフロー
OLM は OpenShift Container Platform 4.19 でデフォルトで実行されます。これは、クラスター管理者がクラスターで実行される Operator のインストール、アップグレード、およびアクセス権の付与を行うのに役立ちます。OpenShift Container Platform Web コンソールでは、クラスター管理者が Operator をインストールし、特定のプロジェクトアクセスを付与して、クラスターで利用可能な Operator のカタログを使用するための管理画面を利用できます。
開発者の場合は、セルフサービスを使用することで、専門的な知識がなくてもデータベースのインスタンスのプロビジョニングや設定、またモニタリング、ビッグデータサービスなどを実行できます。Operator にそれらに関するナレッジが織り込まれているためです。
6.32.1. OLM Operator リンクのコピーリンクがクリップボードにコピーされました!
OLM Operator は、CSV で指定された必須リソースがクラスター内にあることが確認された後に CSV リソースで定義されるアプリケーションをデプロイします。
OLM Operator は必須リソースの作成には関与せず、ユーザーが CLI またはカタログ Operator を使用してこれらのリソースを手動で作成することを選択できます。このタスクの分離により、アプリケーションに OLM フレームワークをどの程度活用するかに関連してユーザーによる追加機能の購入を可能にします。
OLM Operator は以下のワークフローを使用します。
- namespace でクラスターサービスバージョン (CSV) の有無を確認し、要件を満たしていることを確認します。
要件が満たされている場合、CSV のインストールストラテジーを実行します。
注記CSV は、インストールストラテジーの実行を可能にするために Operator グループのアクティブなメンバーである必要があります。
6.32.2. Catalog Operator リンクのコピーリンクがクリップボードにコピーされました!
Catalog Operator はクラスターサービスバージョン (CSV) およびそれらが指定する必須リソースを解決し、インストールします。また、カタログソースでチャネル内のパッケージへの更新の有無を確認し、必要な場合はそれらを利用可能な最新バージョンに自動的にアップグレードします。
チャネル内のパッケージを追跡するために、必要なパッケージ、チャネル、および更新のプルに使用する CatalogSource
オブジェクトを設定して Subscription
オブジェクトを作成できます。更新が見つかると、ユーザーに代わって適切な InstallPlan
オブジェクトの namespace への書き込みが行われます。
Catalog Operator は以下のワークフローを使用します。
- クラスターの各カタログソースに接続します。
ユーザーによって作成された未解決のインストール計画の有無を確認し、これがあった場合は以下を実行します。
- 要求される名前に一致する CSV を検索し、これを解決済みリソースとして追加します。
- マネージドまたは必須の CRD のそれぞれについて、これを解決済みリソースとして追加します。
- 必須 CRD のそれぞれについて、これを管理する CSV を検索します。
- 解決済みのインストール計画の有無を確認し、それに関する検出されたすべてのリソースを作成します (ユーザーによって、または自動的に承認される場合)。
- カタログソースおよびサブスクリプションの有無を確認し、それらに基づいてインストール計画を作成します。
6.32.3. カタログレジストリー リンクのコピーリンクがクリップボードにコピーされました!
カタログレジストリーは、クラスター内での作成用に CSV および CRD を保存し、パッケージおよびチャネルに関するメタデータを保存します。
パッケージマニフェスト は、パッケージアイデンティティーを CSV のセットに関連付けるカタログレジストリー内のエントリーです。パッケージ内で、チャネルは特定の CSV を参照します。CSV は置き換え対象の CSV を明示的に参照するため、パッケージマニフェストは Catalog Operator に対し、CSV をチャネル内の最新バージョンに更新するために必要なすべての情報を提供します (各中間バージョンをステップスルー)。
6.32.4. CRD リンクのコピーリンクがクリップボードにコピーされました!
OLM Operator と Catalog Operator は、それぞれ OLM フレームワークの基礎となるカスタムリソース定義 (CRD) を管理します。
リソース | 短縮名 | 所有者 | 説明 |
---|---|---|---|
|
| OLM | アプリケーションのメタデータ: 名前、バージョン、アイコン、必須リソース、インストールなど。 |
|
| Catalog | CSV を自動的にインストールするか、アップグレードするために作成されるリソースの計算された一覧。 |
|
| Catalog | CSV、CRD、およびアプリケーションを定義するパッケージのリポジトリー。 |
|
| Catalog | パッケージのチャネルを追跡して CSV を最新の状態に保つために使用されます。 |
|
| OLM |
|
これらの Operator のそれぞれは以下のリソースの作成も行います。
リソース | 所有者 |
---|---|
| OLM |
| |
| |
| |
| Catalog |
|
6.32.5. クラスター Operator リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform では、OLM 機能は一連のクラスター Operator で提供されます。
operator-lifecycle-manager
-
OLM Operator を提供します。また、
olm.maxOpenShiftVersion
プロパティーに基づき、クラスターのアップグレードをブロックするインストール済み Operator があるかどうかをクラスター管理者に通知します。詳細は、「OpenShift Container Platform バージョンとの Operator 互換性の制御」を参照してください。 operator-lifecycle-manager-catalog
- Catalog Operator を提供します。
operator-lifecycle-manager-packageserver
-
クラスター上のすべてのカタログからメタデータを収集し、ユーザー向けの
PackageManifest
API を提供する API 拡張サーバーを表します。
6.33. Operator Lifecycle Manager (OLM) v1 Operator リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.18 以降では、OLM (Classic) とともに OLM v1 がデフォルトで有効になっています。この次世代の OLM では、クラスター管理者がユーザー向けに機能を拡張するために使用できる、OLM (Classic) の概念の多くを進化させて更新されたフレームワークが提供されます。
OLM v1 は、registry+v1
バンドル形式の Operator を含む新しい ClusterExtension
オブジェクトのライフサイクルを管理し、クラスター内の拡張機能のインストール、アップグレード、ロールベースのアクセス制御 (RBAC) を制御します。
OpenShift Container Platform では、OLM v1 は olm
クラスター Operator により提供されます。
olm
クラスター Operator は、olm.maxOpenShiftVersion
プロパティーに基づき、クラスターのアップグレードをブロックするインストール済みの拡張機能があるかどうかをクラスター管理者に通知します。詳細は、「OpenShift Container Platform バージョンとの互換性」を参照してください。
6.33.1. コンポーネント リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) v1 は、次のコンポーネントプロジェクトで構成されています。
- Operator Controller
- OLM v1 の中心的なコンポーネントで、API を使用して Kubernetes を拡張します。ユーザーはこれを使用して、Operator や拡張機能をインストールし、そのライフサイクルを管理できます。カタログから情報を使用します。
- Catalogd
- クラスター上のクライアントが使用する、コンテナーイメージにパッケージ化されて出荷されるファイルベースのカタログ (FBC) コンテンツを展開する Kubernetes 拡張機能です。OLM v1 マイクロサービスアーキテクチャーのコンポーネントである catalogd は、Kubernetes 拡張機能の作成者がパッケージ化した拡張機能のメタデータをホストします。これは、ユーザーがインストール可能なコンテンツを発見するのに役立ちます。
6.33.2. CRD リンクのコピーリンクがクリップボードにコピーされました!
clusterextension.olm.operatorframework.io
- スコープ: Cluster
-
CR:
ClusterExtension
clustercatalog.olm.operatorframework.io
- スコープ: Cluster
-
CR:
ClusterCatalog
6.33.3. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.34. OpenShift Service CA Operator リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Service CA Operator は、Kubernetes サービスへの証明書を作成し、提供を管理します。
6.34.1. プロジェクト リンクのコピーリンクがクリップボードにコピーされました!
6.35. vSphere Problem Detector Operator リンクのコピーリンクがクリップボードにコピーされました!
vSphere Problem Detector Operator は、一般的なインストールおよびストレージに関連する正しくない設定の問題について vSphere にデプロイされたクラスターをチェックします。
vSphere でクラスターがデプロイされていることが、Cluster Storage Operator で検出された場合にのみ、Cluster Storage Operator により vSphere Problem Detector Operator が起動されます。
6.35.1. 設定 リンクのコピーリンクがクリップボードにコピーされました!
必要な設定はありません。
6.35.2. 注記 リンクのコピーリンクがクリップボードにコピーされました!
- Operator は、vSphere での OpenShift Container Platform のインストールをサポートします。
-
Operator は
vsphere-cloud-credentials
を使用して vSphere と通信します。 - Operator はストレージに関連するチェックを実行します。
第7章 OLM v1 リンクのコピーリンクがクリップボードにコピーされました!
7.1. Operator Lifecycle Manager v1 について リンクのコピーリンクがクリップボードにコピーされました!
Operator Lifecycle Manager (OLM) は、最初のリリースから OpenShift Container Platform 4 に含まれています。OpenShift Container Platform 4.18 には、一般提供 (GA) 機能として、次世代の OLM のコンポーネントが追加されています。これは、現在のフェーズでは OLM v1 と呼ばれています。この更新されたフレームワークは、OLM の以前のバージョンの一部であった概念の多くを進化させ、新しい機能を追加します。
OpenShift Container Platform 4.17 以降、OLM v1 のドキュメントが次の新しいガイドに移動されました。
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.