2.2. Operator Lifecycle Manager の依存関係の解決
本書では、OpenShift Container Platform の Operator Lifecycle Manager (OLM) 内の依存関係の解決およびカスタムリソース定義 (CRD) アップグレードライフサイクルについて説明します。
2.2.1. 依存関係の解決
OLM は、実行中の Operator の依存関係の解決およびアップグレードライフサイクルを管理します。多くの場合、OLM が直面する問題は yum や rpm などの他のオペレーティングシステムパッケージマネージャーと同様です。
ただし、OLM には通常同様のシステムには 1 つの制約があります。それは、Opearator は常に実行中であるため、OLM は相互に機能しない Operator のセットの共存を防ごうとする点です。
つまり、これは OLM が以下を実行しないことを意味します。
- 提供できない API を必要とする Operator のセットのインストール
- Operator と依存関係のあるものに障害を発生させる仕方での Operator の更新
2.2.2. カスタムリソース定義 (Custom Resource Definition、CRD) のアップグレード
OLM は、単一の Cluster Service Version (CSV) によって所有されている場合にはカスタムリソース定義 (CRD) をすぐにアップグレードします。CRD が複数の CSV によって所有されている場合、CRD は、以下の後方互換性の条件のすべてを満たす場合にアップグレードされます。
- 現行 CRD の既存の有効にされたバージョンすべてが新規 CRD に存在する。
- 検証が新規 CRD の検証スキーマに対して行われる場合、CRD の有効にされたバージョンに関連付けられる既存インスタンスまたはカスタムリソース (CR) すべてが有効である。
2.2.2.1. 新規 CRD バージョンの追加
手順
CRD の新規バージョンを追加するには、以下を実行します。
versionsセクションに CRD リソースの新規エントリーを追加します。たとえば、現在の CRD に 1 つのバージョン
v1alpha1があり、新規バージョンv1beta1を追加し、これを新規のストレージバージョンとしてマークをする場合に、以下を実行します。versions: - name: v1alpha1 served: true storage: false - name: v1beta1 1 served: true storage: true- 1
v1beta1の新規エントリーを追加します。
CSV で新規バージョンが使用されることが意図される場合は、CSV の
ownedセクションの CRD の参照バージョンが更新されていることを確認します。customresourcedefinitions: owned: - name: cluster.example.com version: v1beta1 1 kind: cluster displayName: Cluster- 1
versionを更新します。
- 更新された CRD および CSV をバンドルにプッシュします。
2.2.2.2. CRD バージョンの非推奨または削除
OLM は、CRD の有効にされたバージョンがすぐに削除されることを許可しません。その代わりに、CRD の非推奨バージョンを CRD の served フィールドを false に設定して無効にする必要があります。その後に、無効にされたバージョンではないバージョンを後続の CRD アップグレードで削除できます。
手順
特定バージョンの CRD を非推奨にし、削除するには、以下を実行します。
非推奨バージョンを non-serving (無効にされたバージョン) とマークして、このバージョンが使用されなくなり、後続のアップグレードで削除される可能性があることを示します。例:
versions: - name: v1alpha1 served: false 1 storage: true- 1
falseに設定します。
非推奨となるバージョンが現在
storageバージョンの場合、storageバージョンを有効にされたバージョンに切り替えます。例:versions: - name: v1alpha1 served: false storage: false 1 - name: v1beta1 served: true storage: true 2注記CRD から
storageバージョンであるか、このバージョンであった特定のバージョンを削除するために、そのバージョンが CRD のステータスのstoredVersionから削除される必要があります。OLM は、保存されたバージョンが新しい CRD に存在しないことを検知した場合に、この実行を試行します。- 上記の変更内容で CRD をアップグレードします。
後続のアップグレードサイクルでは、無効にされたバージョンを CRD から完全に削除できます。例:
versions: - name: v1beta1 served: true storage: true-
該当バージョンが CRD から削除される場合、CSV の
ownedセクションにある CRD の参照バージョンも更新されていることを確認します。
2.2.3. 依存関係解決のシナリオ例
以下の例で、プロバイダー は CRD または APIService を「所有」する Operator です。
例: 依存 API を非推奨にする
A および B は API である (例: CRD):
- A のプロバイダーは B に依存する。
- B のプロバイダーには Subscription がある。
- B のプロバイダーは C を提供するように更新するが、B を非推奨にする。
この結果は以下のようになります。
- B にはプロバイダーがなくなる。
- A は機能しなくなる。
これは OLM がアップグレードストラテジーで回避するケースです。
例: バージョンのデッドロック
A および B は API である:
- A のプロバイダーには B が必要。
- B のプロバイダーには A が必要。
- A のプロバイダーは (A2 を提供し、B2 を必要とするように) 更新され、A を非推奨にする。
- B のプロバイダーは (B2 を提供し、A2 を必要とするように) 更新され、B を非推奨にする。
OLM が B を同時に更新せずに A を更新しようとする場合や、その逆の場合、OLM は、新しい互換性のあるセットが見つかったとしても Operator の新規バージョンに進むことができません。
これは OLM がアップグレードストラテジーで回避するもう 1 つのケースです。
