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 -
サブスクリプション
CSV で定義される Operator メタデータは、カタログソースというコレクションに保存できます。OLM はカタログソースを使用します。これは Operator Registry API を使用して利用可能な Operator やインストールされた Operator のアップグレードについてクエリーします。
図2.3 カタログソースの概要
カタログソース内で、Operator は パッケージ と チャネル という更新のストリームに編成されます。これは、Web ブラウザーのような継続的なリリースサイクルの OpenShift Container Platform や他のソフトウェアで使用される更新パターンです。
図2.4 カタログソースのパッケージおよびチャネル
ユーザーは サブスクリプション の特定のカタログソースの特定のパッケージおよびチャネルを指定できます (例: etcd パッケージおよびその alpha チャネル)。サブスクリプションが namespace にインストールされていないパッケージに対して作成されると、そのパッケージの最新 Operator がインストールされます。
OLM では、バージョンの比較が意図的に避けられます。そのため、所定の catalog
各 CSV には、これが置き換える Operator を示唆する replaces パラメーターがあります。これにより、OLM でクエリー可能な CSV のグラフが作成され、更新がチャネル間で共有されます。チャネルは、更新グラフのエントリーポイントと見なすことができます。
図2.5 利用可能なチャネル更新についての OLM グラフ
パッケージのチャネルの例
packageName: example channels: - name: alpha currentCSV: example.v0.1.2 - name: beta currentCSV: example.v0.1.3 defaultChannel: alpha
カタログソース、パッケージ、チャネルおよび 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 例
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.6 更新のスキップ
このグラフは、以下を示しています。
- 古い CatalogSource の Operator には、 新規 CatalogSource の単一の置き換えがある。
- 新規 CatalogSource の Operator には、 新規 CatalogSource の単一の置き換えがある。
- 問題のある更新がインストールされていない場合、これがインストールされることはない。
2.4.3.1.3. 複数 Operator の置き換え
説明されているように 新規 CatalogSource を作成するには、1 つの Operator を置き換える (置き換える) が、複数バージョンを省略 (skip) できる CSV を公開する必要があります。これは、skipRange アノテーションを使用して実行できます。
olm.skipRange: <semver_range>
ここで <semver_range> には、semver ライブラリー でサポートされるバージョン範囲の形式が使用されます。
カタログで更新を検索する場合、チャネルのヘッドに skipRange アノテーションがあり、現在インストールされている Operator にその範囲内のバージョンフィールドがある場合、OLM はチャネル内の最新エントリーに対して更新されます。
以下は動作が実行される順序になります。
-
サブスクリプションの
sourceNameで指定されるソースのチャネルヘッド (省略する他の条件が満たされている場合)。 -
sourceNameで指定されるソースの現行バージョンを置き換える次の Operator。 - サブスクリプションに表示される別のソースのチャネルヘッド (省略する他の条件が満たされている場合)。
- サブスクリプションに表示されるソースの現行バージョンを置き換える次の 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.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 リリースに更新される。
- 使用不可のリリースは仮想グラフノードと見なされる。それらのコンテンツは存在する必要がなく、レジストリーはグラフが示すように応答することのみが必要になります。
