6.28. Operator Lifecycle Manager Operator
目的
Operator Lifecycle Manager (OLM) を使用することにより、ユーザーは Kubernetes ネイティブアプリケーション (Operator) および OpenShift Container Platform クラスター全体で実行される関連サービスについてインストール、更新、およびそのライフサイクルの管理を実行できます。これは、Operator を効果的かつ自動化された拡張可能な方法で管理するために設計されたオープンソースツールキットの Operator Framework の一部です。
図6.1 Operator Lifecycle Manager ワークフロー
OLM は OpenShift Container Platform 4.7 でデフォルトで実行されます。これは、クラスター管理者がクラスターで実行されている Operator をインストールし、アップグレードし、アクセスをこれに付与するのに役立ちます。OpenShift Container Platform Web コンソールは、クラスター管理者が Operator をインストールしたり、クラスターで利用可能な Operator のカタログを使用できるように特定のプロジェクトアクセスを付与したりするのに使用する管理画面を提供します。
開発者の場合は、セルフサービスを使用することで、専門的な知識がなくてもデータベースのインスタンスのプロビジョニングや設定、またモニターリング、ビッグデータサービスなどを実行できます。 Operator にそれらに関するナレッジが織り込まれているためです。
CRD
Operator Lifecycle Manager (OLM) は、OLM Operator および Catalog Operator の 2 つの Operator で設定されています。
これらの Operator はそれぞれ OLM フレームワークのベースとなるカスタムリソース定義 (CRD) を管理します。
| リソース | 短縮名 | 所有する Operator | 説明 |
|---|---|---|---|
|
|
| OLM | アプリケーションのメタデータ: 名前、バージョン、アイコン、必須リソース、インストールなど。 |
|
|
| カタログ | CSV を自動的にインストールするか、またはアップグレードするために作成されるリソースの計算された一覧。 |
|
|
| カタログ | CSV、CRD、およびアプリケーションを定義するパッケージのリポジトリー。 |
|
|
| カタログ | パッケージのチャネルを追跡して CSV を最新の状態に保つために使用されます。 |
|
|
| OLM |
|
これらの Operator のそれぞれは以下のリソースの作成も行います。
| リソース | 所有する Operator |
|---|---|
|
| OLM |
|
| |
|
| |
|
| |
|
| カタログ |
|
|
OLM Operator
OLM Operator は、CSV で指定された必須リソースがクラスター内にあることが確認された後に CSV リソースで定義されるアプリケーションをデプロイします。
OLM Operator は必須リソースの作成には関与せず、ユーザーが CLI またはカタログ Operator を使用してこれらのリソースを手動で作成することを選択できます。このタスクの分離により、アプリケーションに OLM フレームワークをどの程度活用するかに関連してユーザーによる追加機能の購入を可能にします。
OLM Operator は以下のワークフローを使用します。
- namespace でクラスターサービスバージョン (CSV) の有無を確認し、要件を満たしていることを確認します。
要件が満たされている場合、CSV のインストールストラテジーを実行します。
注記CSV は、インストールストラテジーの実行を可能にするために Operator グループのアクティブなメンバーである必要があります。
カタログ Operator
カタログ Operator はクラスターサービスバージョン (CSV) およびそれらが指定する必須リソースを解決し、インストールします。また、カタログソースでチャネル内のパッケージへの更新の有無を確認し、必要な場合はそれらを利用可能な最新バージョンに自動的にアップグレードします。
チャネル内のパッケージを追跡するために、必要なパッケージ、チャネル、および更新のプルに使用する CatalogSource オブジェクトを設定して Subscription オブジェクトを作成できます。更新が見つかると、ユーザーに代わって適切な InstallPlan オブジェクトの namespace への書き込みが行われます。
カタログ Operator は以下のワークフローを使用します。
- クラスターの各カタログソースに接続します。
ユーザーによって作成された未解決のインストール計画の有無を確認し、これがあった場合は以下を実行します。
- 要求される名前に一致する CSV を検索し、これを解決済みリソースとして追加します。
- 管理対象または必須の CRD のそれぞれについて、これを解決済みリソースとして追加します。
- 必須 CRD のそれぞれについて、これを管理する CSV を検索します。
- 解決済みのインストール計画の有無を確認し、それについての検出されたすべてのリソースを作成します (ユーザーによって、または自動的に承認される場合)。
- カタログソースおよびサブスクリプションの有無を確認し、それらに基づいてインストール計画を作成します。
カタログレジストリー
カタログレジストリーは、クラスター内での作成用に CSV および CRD を保存し、パッケージおよびチャネルについてのメタデータを保存します。
パッケージマニフェスト は、パッケージアイデンティティーを CSV のセットに関連付けるカタログレジストリー内のエントリーです。パッケージ内で、チャネルは特定の CSV を参照します。CSV は置き換え対象の CSV を明示的に参照するため、パッケージマニフェストはカタログ Operator に対し、CSV をチャネル内の最新バージョンに更新するために必要なすべての情報を提供します (各中間バージョンをステップスルー)。
