Menu Close
Settings Close

Language and Page Formatting Options

第2章 Operator Lifecycle Manager (OLM) について

2.1. Operator Lifecycle Manager のワークフローおよびアーキテクチャー

以下では、OpenShift Container Platform における Operator Lifecycle Manager (OLM) の概念およびアーキテクチャーの概要を説明します。

2.1.1. Operator Lifecycle Manager の概要

OpenShift Container Platform 4.4 では、 Operator Lifecycle Manager (OLM) を使用することにより、ユーザーはすべての Operator およびクラスター全体で実行される関連サービスをインストールし、更新し、管理することができます。これは、Kubernetes のネイティブアプリケーション (Operator) を効果的かつ自動化された拡張可能な方法で管理するために設計されたオープンソースツールキットの Operator Framework の一部です。

図2.1 Operator Lifecycle Manager ワークフロー

OLM のワークフロー

OLM は OpenShift Container Platform 4.4 でデフォルトで実行されます。これは、クラスター管理者がクラスターで実行されている Operator をインストールし、アップグレードし、アクセスをこれに付与するのに役立ちます。OpenShift Container Platform Web コンソールは、クラスター管理者が Operator をインストールしたり、クラスターで利用可能な Operator のカタログを使用できるように特定のプロジェクトアクセスを付与したりするのに使用する管理画面を提供します。

開発者の場合には、セルフサービスを使用することで、専門的な知識がなくてもデータベースのインスタンスのプロビジョニングや設定、またモニタリング、ビッグデータサービスなどを実行できます。 Operator にそれらに関するナレッジが織り込まれているためです。

2.1.2. ClusterServiceVersion (CSV)

ClusterServiceVersion (CSV) は、Operator Lifecycle Manager (OLM) のクラスターでの Operator の実行を支援する Operator メタデータから作成される YAML マニフェストです。

CSV は、ユーザーインターフェースにロゴ、説明、およびバージョンなどの情報を設定するために使用される Operator コンテナーイメージを伴うメタデータです。また、これは Operator が必要とする RBAC ルールやそれが管理したり、依存したりするカスタムリース(Custom Resource、CR) などの、Operator を実行するために必要な技術情報の情報源にもなります。

CSV は以下で構成されます。

メタデータ
  • アプリケーションメタデータ:

    • 名前、説明、バージョン (semver 準拠)、リンク、ラベル、アイコンなど
インストールストラテジー
  • タイプ: Deployment

    • サービスアカウントおよび必要なパーミッションのセット
    • Deployment のセット。
CRD
  • タイプ
  • Owned: サービスで管理されます。
  • Required: サービスが実行されるためにクラスターに存在する必要があります。
  • Resources: Operator が対話するリソースの一覧です。
  • Descriptors: 意味情報を提供するために CRD 仕様およびステータスフィールドにアノテーションを付けます。

2.1.3. OLM での Operator のインストールおよびアップグレードのワークフロー

Operator Lifecycle Manager (OLM) エコシステムでは、以下のリソースを使用して Operator インストールおよびアップグレードを解決します。

  • ClusterServiceVersion (CSV)
  • CatalogSource
  • Subscription

CSV で定義される Operator メタデータは CatalogSource というコレクションに保存できます。OLM は CatalogSource を使用します。これは Operator Registry API を使用して利用可能な Operator やインストールされた Operator のアップグレードについてクエリーします。

図2.2 CatalogSource の概要

OLM カタログソース

CatalogSource 内で、Operator は パッケージチャネル という更新のストリームに編成されます。これは、Web ブラウザーのような継続的なリリースサイクルの OpenShift Container Platform や他のソフトウェアで使用される更新パターンです。

図2.3 CatalogSource のパッケージおよびチャネル

OLM チャネル

ユーザーは Subscription の特定の CatalogSource の特定のパッケージおよびチャネルを指定できます (例: etcd パッケージおよびその alpha チャネル)。Subscription が namespace にインストールされていないパッケージに対して作成されると、そのパッケージの最新 Operator がインストールされます。

注記

OLM では、バージョンの比較が意図的に避けられます。そのため、所定の catalogchannelpackage パスから利用可能な「latest」または「newest」 Operator が必ずしも最も高いバージョン番号である必要はありません。これは Git リポジトリーの場合と同様に、チャネルの Head リファレンスとして見なされます。

各 CSV には、これが置き換える Operator を示唆する replaces パラメーターがあります。これにより、OLM でクエリー可能な CSV のグラフが作成され、更新がチャネル間で共有されます。チャネルは、更新グラフのエントリーポイントと見なすことができます。

図2.4 利用可能なチャネル更新についての OLM グラフ

olm replaces

以下は例になります。

パッケージのチャネル

packageName: example
channels:
- name: alpha
  currentCSV: example.v0.1.2
- name: beta
  currentCSV: example.v0.1.3
defaultChannel: alpha

CatalogSource、パッケージ、チャネルおよび CSV がある状態で、OLM が更新のクエリーを実行できるようにするには、カタログが入力された CSV の置き換え (replaces) を実行する単一 CSV を明確にかつ確定的に返すことができる必要があります。

2.1.3.1. アップグレードパスの例

アップグレードシナリオのサンプルについて、CSV バージョン 0.1.1 に対応するインストールされた Operator について見てみましょう。OLM は CatalogSource をクエリーし、新規 CSV バージョン 0.1.3 についてのサブスクライブされたチャネルのアップグレードを検出します。これは、古いバージョンでインストールされていない CSV バージョン 0.1.2 を置き換えます。その後、さらに古いインストールされた CSV バージョン 0.1.1 を置き換えます。

OLM は、チャネルヘッドから CSV で指定された replaces フィールドで以前のバージョンに戻り、アップグレードパス 0.1.30.1.20.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.1.3.2. アップグレードの省略

OLM のアップグレードの基本パスは以下のとおりです。

  • CatalogSource は Operator への 1 つ以上の更新に応じて更新されます。
  • OLM は、CatalogSource に含まれる最新バージョンに到達するまで、Operator のすべてのバージョンを横断します。

ただし、この操作の実行は安全でない場合があります。公開されているバージョンの Operator がクラスターにインストールされていない場合、そのバージョンによって深刻な脆弱性が導入される可能性があるなどの理由でその Operator をがクラスターにインストールできないことがあります。

この場合、OLM は以下の 2 つのクラスターの状態を考慮に入れて、それらの両方に対応する更新グラフを提供する必要があります。

  • 「問題のある」中間 Operator がクラスターによって確認され、かつインストールされている。
  • 「問題のある」中間 Operator がクラスターにまだインストールされていない。

OLM は、新規カタログを送り、省略されたリリースを追加することで、クラスターの状態や問題のある更新が発見されたかどうかにかかわらず、単一の固有の更新を常に取得することができます。

以下は例になります。

省略されたリリースの CSV

apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  name: etcdoperator.v0.9.2
  namespace: placeholder
  annotations:
spec:
    displayName: etcd
    description: Etcd Operator
    replaces: etcdoperator.v0.9.0
    skips:
    - etcdoperator.v0.9.1

古い CatalogSource と 新規 CatalogSource についての以下の例を見てみましょう。

図2.5 更新のスキップ

olm skipping updates

このグラフは、以下を示しています。

  • 古い CatalogSource の Operator には、新規 CatalogSource の単一の置き換えがある。
  • 新規 CatalogSource の Operator には、新規 CatalogSource の単一の置き換えがある。
  • 問題のある更新がインストールされていない場合、これがインストールされることはない。

2.1.3.3. 複数 Operator の置き換え

説明されているように新規 CatalogSource を作成する場合、1 つの Operator を置き換える (replace) が、複数バージョンを省略 (skip) できる CSV を公開する必要があります。これは、skipRange アノテーションを使用して実行できます。

olm.skipRange: <semver_range>

ここで <semver_range> には、semver ライブラリーでサポートされるバージョン範囲の形式が使用されます。

カタログで更新を検索する場合、チャネルのヘッドに skipRange アノテーションがあり、現在インストールされている Operator にその範囲内のバージョンフィールドがある場合、OLM はチャネル内の最新エントリーに対して更新されます。

以下は動作が実行される順序になります。

  1. Subscription の sourceName で指定されるソースのチャネルヘッド (省略する他の条件が満たされている場合)。
  2. sourceName で指定されるソースの現行バージョンを置き換える次の Operator。
  3. Subscription に表示される別のソースのチャネルヘッド (省略する他の条件が満たされている場合)。
  4. Subscription に表示されるソースの現行バージョンを置き換える次の Operator。

以下は例になります。

skipRange のある CSV

apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
    name: elasticsearch-operator.v4.1.2
    namespace: <namespace>
    annotations:
        olm.skipRange: '>=4.1.0 <4.1.2'

2.1.3.4. z-stream サポート

z-streamまたはパッチリリースは、同じマイナーバージョンの以前のすべての z-stream リリースを置き換える必要があります。OLM は、メジャー、マイナーまたはパッチバージョンを区別せず、カタログ内で正確なグラフを作成する必要があります。

つまり、OLM では古い CatalogSource のグラフを使用し、上記のように新規 CatalogSource のグラフを生成する必要があります。

図2.6 複数 Operator の置き換え

olm z stream

このグラフは、以下を示しています。

  • 古い CatalogSource の Operator には、新規 CatalogSource の単一の置き換えがある。
  • 新規 CatalogSource の Operator には、新規 CatalogSource の単一の置き換えがある。
  • 古い CatalogSource の z-stream リリースは、新規 CatalogSource の最新 z-stream リリースに更新される。
  • 使用不可のリリースは「仮想」グラフノードと見なされる。それらのコンテンツは存在する必要がなく、レジストリーはグラフが示すように応答することのみが必要になります。

2.1.4. Operator Lifecycle Manager アーキテクチャー

Operator Lifecycle Manager は、OLM Operator および Catalog Operator の 2 つの Operator で構成されています。

これらの Operator はそれぞれ OLM フレームワークのベースとなるカスタムリソース定義 (Custom Resource Definition、CRD) を管理します。

表2.1 OLM およびカタログ Operator で管理される CRD

リソース短縮名所有する Operator説明

ClusterServiceVersion

csv

OLM

アプリケーションのメタデータ: 名前、バージョン、アイコン、必須リソース、インストールなど。

InstallPlan

ip

カタログ

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

CatalogSource

catsrc

カタログ

CSV、CRD、およびアプリケーションを定義するパッケージのリポジトリー。

Subscription

sub

カタログ

パッケージのチャネルを追跡して CSV を最新の状態に保つために使用されます。

OperatorGroup

og

OLM

複数の namespace をグループ化し、それらを Operator で使用できるように準備するために使用されます。

これらの Operator のそれぞれはリソースの作成も行います。

表2.2 OLM およびカタログ Operator によって作成されるリソース

リソース所有する Operator

Deployment

OLM

ServiceAccount

(Cluster)Role

(Cluster)RoleBinding

Custom Resource Definition (CRD)

カタログ

ClusterServiceVersion (CSV)

2.1.4.1. OLM Operator

OLM Operator は、CSV で指定された必須リソースがクラスター内にあることが確認された後に CSV リソースで定義されるアプリケーションをデプロイします。

OLM Operator は必須リソースの作成には関与せず、ユーザーが CLI を使用してこれらのリソースを手動で作成したり、カタログ Operator を使用してこれらのリソースを作成することを選択することができます。このタスクの分離により、アプリケーションに OLM フレームワークをどの程度活用するかに関連してユーザーによる追加機能の購入を可能にします。

OLM Operator はすべての namespace を監視するように設定されることが多い一方で、それらすべてが別々の namespace を管理する限り、他の OLM Operator と並行して操作することができます。

OLM Operator のワークフロー

  • namespace で ClusterServiceVersion (CSV) の有無を確認し、要件を満たしていることを確認します。その場合、CSV のインストールストラテジーを実行します。

    注記

    CSV は、インストールストラテジーの実行を可能にするには、OperatorGroup のアクティブなメンバーである必要があります。

2.1.4.2. カタログ Operator

カタログ Operator は CSV およびそれらが指定する必須リソースを解決し、インストールします。また、 CatalogSource でチャネル内のパッケージへの更新の有無を確認し、それらを利用可能な最新バージョンに (オプションで自動的に) アップグレードします。

チャネル内のパッケージを追跡する必要のあるユーザーは、必要なパッケージ、チャネル、および更新のプルに使用する CatalogSource を設定する Subscription リソースを作成します。 更新が見つかると、ユーザーに代わって適切な InstallPlan の namespace への書き込みが行われます。

また、ユーザーは必要な CSV および承認ストラテジーの名前を含む InstallPlan リソースを直接作成でき、カタログ Operator はすべての必須リソースの作成の実行計画を作成します。これが承認されると、カタログ Operator はすべてのリソースを InstallPlan に作成します。 その後、これが単独で OLM Operator の要件を満たすと、CSV のインストールに移行します。

カタログ Operator のワークフロー

  • 名前でインデックス化される CRD および CSV のキャッシュがあることを確認します。
  • ユーザーによって作成された未解決の InstallPlan の有無を確認します。

    • 要求される名前に一致する CSV を検索し、これを解決済みリソースとして追加します。
    • 管理対象または必須の CRD のそれぞれについて、これを解決済みリソースとして追加します。
    • 必須 CRD のそれぞれについて、これを管理する CSV を検索します。
  • 解決済みの InstallPlan の有無を確認し、それについての検出されたすべてのリソースを作成します (ユーザーによって、または自動的に承認される場合)。
  • CatalogSource および Subscription の有無を確認し、それらに基づいて InstallPlan を作成します。

2.1.4.3. カタログレジストリー

カタログレジストリーは、クラスター内での作成用に CSV および CRD を保存し、パッケージおよびチャネルについてのメタデータを保存します。

パッケージマニフェスト は、パッケージアイデンティティーを CSV のセットに関連付けるカタログレジストリー内のエントリーです。パッケージ内で、チャネルは特定の CSV を参照します。CSV は置き換え対象の CSV を明示的に参照するため、パッケージマニフェストはカタログ Operator に対し、CSV をチャネル内の最新バージョンに更新するために必要なすべての情報を提供します (各中間バージョンをステップスルー)。

2.1.5. 公開されるメトリクス

Operator Lifecycle Manager (OLM) は、Prometheus ベースの OpenShift Container Platform クラスターモニタリングスタックで使用される特定の OLM 固有のリソースを公開します。

表2.3 OLM によって公開されるメトリクス

名前説明

catalog_source_count

CatalogSource の数。

csv_abnormal

ClusterServiceVersion (CSV) を調整する際に、(インストールされていない場合など)CSV バージョンが Succeeded 以外の状態にあることを表します。namenamespacephasereason、および version ラベルが含まれます。Prometheus アラートは、このメトリクスが存在する場合に作成されます。

csv_count

正常に登録された CSV の数。

csv_succeeded

CSV を調整する際に、CSV バージョンが Succeeded 状態 (値 1) にあるか、またはそうでないか (値 0) を表します。namenamespace、および version ラベルが含まれます。

csv_upgrade_count

CSV アップグレードの単調 (monotonic) カウント。

install_plan_count

InstallPlan の数。

subscription_count

Subscription の数。

subscription_sync_total

Subscription 同期の単調 (monotonic) カウント。channelinstalled CSV、および Subscription name ラベルが含まれます。