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 の新規バージョンを追加するには、以下を実行します。

  1. versions セクションに CRD リソースの新規エントリーを追加します。

    たとえば、現在の CRD に 1 つのバージョン v1alpha1 があり、新規バージョン v1beta1 を追加し、これを新規のストレージバージョンとしてマークをする場合に、以下を実行します。 

    versions:
  - name: v1alpha1
    served: true
    storage: false
  - name: v1beta1 1
    served: true
    storage: true
    1
    v1beta1の新規エントリーを追加します。

  2. CSV で新規バージョンが使用されることが意図される場合は、CSV の owned セクションの CRD の参照バージョンが更新されていることを確認します。 

    customresourcedefinitions:
  owned:
  - name: cluster.example.com
    version: v1beta1 1
    kind: cluster
    displayName: Cluster
    1
    version を更新します。
  3. 更新された CRD および CSV をバンドルにプッシュします。

2.2.2.2. CRD バージョンの非推奨または削除

OLM は、CRD の有効にされたバージョンがすぐに削除されることを許可しません。その代わりに、CRD の非推奨バージョンを CRD の served フィールドを false に設定して無効にする必要があります。その後に、無効にされたバージョンではないバージョンを後続の CRD アップグレードで削除できます。

手順

特定バージョンの CRD を非推奨にし、削除するには、以下を実行します。

  1. 非推奨バージョンを non-serving (無効にされたバージョン) とマークして、このバージョンが使用されなくなり、後続のアップグレードで削除される可能性があることを示します。例: 

    versions:
  - name: v1alpha1
    served: false 1
    storage: true
    1
    falseに設定します。

  2. 非推奨となるバージョンが現在 storage バージョンの場合、storage バージョンを有効にされたバージョンに切り替えます。例: 

    versions:
  - name: v1alpha1
    served: false
    storage: false 1
  - name: v1beta1
    served: true
    storage: true 2
    1 2
    storage フィールドを適宜更新します。
    注記

    CRD から storage バージョンであるか、このバージョンであった特定のバージョンを削除するために、そのバージョンが CRD のステータスの storedVersion から削除される必要があります。OLM は、保存されたバージョンが新しい CRD に存在しないことを検知した場合に、この実行を試行します。

  3. 上記の変更内容で CRD をアップグレードします。

  4. 後続のアップグレードサイクルでは、無効にされたバージョンを CRD から完全に削除できます。例: 

    versions:
  - name: v1beta1
    served: true
    storage: true
  5. 該当バージョンが 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 つのケースです。