Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

5.3. 更新パス

インストールされたクラスター拡張機能の 更新パス (アップグレードエッジまたはアップグレード制約とも呼ばれる) を決定する場合、Operator Lifecycle Manager (OLM) v1 は、OpenShift Container Platform 4.16 以降、OLM (Classic) セマンティクスをサポートします。このサポートは、replaces、skips、skipRange ディレクティブを含め、OLM (Classic) の動作に従いますが、いくつかの違いがあります。

OLM (Classic) セマンティクスをサポートすることにより、OLM v1 はカタログからの更新グラフを正確に反映します。

元の OLM (Classic) 実装との違い

  • 複数の後継候補がある場合の OLM v1 の動作は、次のように異なります。

    • OLM (Classic) では、チャネルヘッドに最も近い後継が選択されます。
    • OLM v1 では、後継の中でセマンティックバージョン (semver) が最も大きいものが選択されます。

  • 次のファイルベースカタログ (FBC) チャネルエントリーのセットを検討してください。 

    # ...
- name: example.v3.0.0
  skips: ["example.v2.0.0"]
- name: example.v2.0.0
  skipRange: >=1.0.0 <2.0.0
    Copy to Clipboard Toggle word wrap

    1.0.0 がインストールされている場合、OLM v1 の動作は次のように異なります。

    • v2.0.0 がスキップされ、replaces チェーン上にないため、OLM (Classic) は v2.0.0 への更新パスを検出しません。
    • OLM v1 には replaces チェーンの概念がないため、OLM v1 は更新パスを検出します。OLM v1 は、現在インストールされているバージョンに対応する replace、skip、または skipRange の値を持つすべてのエントリーを検索します。

5.3.1. バージョン範囲のサポート
リンクのコピー

Operator Lifecycle Manager (OLM) v1 では、Operator または拡張機能のカスタムリソース (CR) で比較文字列を使用してバージョン範囲を指定できます。CR でバージョン範囲を指定すると、OLM v1 は、そのバージョン範囲内で解決できる Operator の最新バージョンをインストールまたは更新します。

解決されるバージョンのワークフロー

  • 解決されるバージョンは、Operator と環境の制約を満たす Operator の最新バージョンです。
  • 正常に解決された場合、指定された範囲内の Operator 更新は自動的にインストールされます。
  • 指定された範囲外にある場合、または正常に解決できない場合、その更新はインストールされません。

5.3.2. バージョン比較文字列
リンクのコピー

Operator または拡張機能のカスタムリソース (CR) の spec.version フィールドに比較文字列を追加することで、バージョン範囲を定義できます。比較文字列は、スペースまたはコンマで区切られた値と、二重引用符 (") で囲まれた 1 つ以上の比較演算子のリストです。文字列の間に比較演算子の OR または二重縦棒 (||) を含めることで、別の比較文字列を追加できます。

Expand
表5.4 基本的な比較
比較演算子定義

=

等しい

!=

等しくない

>

より大きい

<

より小さい

>=

より大か等しい

<=

より小か等しい

次の例のような範囲比較を使用して、Operator または拡張機能の CR でバージョン範囲を指定できます。

バージョン範囲の比較例

apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    name: <clusterextension_name>
  spec:
    namespace: <installed_namespace>
    serviceAccount:
      name: <service_account_installer_name>
    source:
      sourceType: Catalog
      catalog:
        packageName: <package_name>
        version: ">=1.11, <1.13"
Copy to Clipboard Toggle word wrap

すべてのタイプの比較文字列でワイルドカード文字を使用できます。OLM v1 では、x、X、およびアスタリスク (*) をワイルドカード文字として使用できます。ワイルドカード文字と比較演算子の等号 (=) を使用する場合は、パッチまたはマイナーバージョンレベルでの比較を定義します。

Expand
表5.5 比較文字列内のワイルドカード文字の例
ワイルドカード比較一致する文字列

1.11.x

>=1.11.0, <1.12.0

>=1.12.X

>=1.12.0

<=2.x

<3

*

>=0.0.0

比較演算子のチルダ (~) を使用して、パッチリリースを比較できます。パッチリリースの比較では、次のメジャーバージョンまでのマイナーバージョンを指定します。

Expand
表5.6 パッチリリースの比較例
パッチリリースの比較一致する文字列

~1.11.0

>=1.11.0, <1.12.0

~1

>=1, <2

~1.12

>=1.12, <1.13

~1.12.x

>=1.12.0, <1.13.0

~1.x

>=1, <2

比較演算子のキャレット (^) を使用して、メジャーリリースを比較できます。最初の stable リリースが公開される前にメジャーリリース比較を使用する場合、マイナーバージョンにより API の安定レベルが定義されます。セマンティックバージョン (semver) 仕様では、最初の安定リリースは 1.0.0 バージョンとして公開されます。

Expand
表5.7 メジャーリリースの比較例
メジャーリリースの比較一致する文字列

^0

>=0.0.0, <1.0.0

^0.0

>=0.0.0, <0.1.0

^0.0.3

>=0.0.3, <0.0.4

^0.2

>=0.2.0, <0.3.0

^0.2.3

>=0.2.3, <0.3.0

^1.2.x

>= 1.2.0, < 2.0.0

^1.2.3

>= 1.2.3, < 2.0.0

^2.x

>= 2.0.0, < 3

^2.3

>= 2.3, < 3

5.3.3. ターゲットバージョンを指定するカスタムリソース (CR) の例
リンクのコピー

Operator Lifecycle Manager (OLM) v1 では、クラスター管理者はカスタムリソース (CR) で Operator または拡張機能のターゲットバージョンを宣言的に設定できます。

次のフィールドのいずれかを指定して、ターゲットバージョンを定義できます。

  • チャネル
  • バージョン番号
  • バージョン範囲

CR でチャネルを指定すると、OLM v1 は、指定されたチャネル内で解決できる最新バージョンの Operator または拡張機能をインストールします。指定されたチャネルに更新が公開されると、OLM v1 はそのチャネルから解決できる最新リリースに自動的に更新します。

チャネルを指定した CR の例

apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    name: <clusterextension_name>
  spec:
    namespace: <installed_namespace>
    serviceAccount:
      name: <service_account_installer_name>
    source:
      sourceType: Catalog
      catalog:
        packageName: <package_name>
        channels:
          - latest
1
Copy to Clipboard Toggle word wrap

1
オプション: 指定したチャネルから解決できる最新のリリースをインストールします。チャネルへの更新は自動的にインストールされます。channels パラメーターの値を配列として指定します。

CR で Operator または拡張機能のターゲットバージョンを指定すると、OLM v1 は指定されたバージョンをインストールします。CR でターゲットバージョンが指定されている場合、カタログに更新が公開されても OLM v1 はターゲットバージョンを変更しません。

クラスターにインストールされている Operator のバージョンを更新する必要がある場合は、Operator の CR を手動で編集する必要があります。Operator のターゲットバージョンを指定すると、Operator のバージョンが指定されたリリースに固定されます。

ターゲットバージョンを指定した CR の例

apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    name: <clusterextension_name>
  spec:
    namespace: <installed_namespace>
    serviceAccount:
      name: <service_account_installer_name>
    source:
      sourceType: Catalog
      catalog:
        packageName: <package_name>
        version: "1.11.1"
1
Copy to Clipboard Toggle word wrap

1
オプション: ターゲットバージョンを指定します。インストールされている Operator または拡張機能のバージョンを更新する必要がある場合は、CR のこのフィールドを目的のターゲットバージョンに手動で更新する必要があります。

Operator または拡張機能の許容可能なバージョン範囲を定義する場合は、比較文字列を使用してバージョン範囲を指定できます。バージョン範囲を指定すると、OLM v1 は、Operator Controller で解決できる最新バージョンの Operator または拡張機能をインストールします。

バージョン範囲を指定した CR の例

apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    name: <clusterextension_name>
  spec:
    namespace: <installed_namespace>
    serviceAccount:
      name: <service_account_installer_name>
    source:
      sourceType: Catalog
      catalog:
        packageName: <package_name>
        version: ">1.11.1"
1
Copy to Clipboard Toggle word wrap

1
オプション: 必要なバージョン範囲が、バージョン 1.11.1 より大きいことを指定します。詳細は、「バージョン範囲のサポート」を参照してください。

CR を作成または更新した後、次のコマンドを実行して設定ファイルを適用します。

コマンド構文

$ oc apply -f <extension_name>.yaml
Copy to Clipboard Toggle word wrap

5.3.4. 更新またはロールバックの強制
リンクのコピー

OLM v1 は、次のメジャーバージョンへの自動更新や以前のバージョンへのロールバックをサポートしていません。メジャーバージョンの更新またはロールバックを実行する場合は、手動で更新を確認して強制する必要があります。

警告

手動更新またはロールバックを強制した場合の影響を確認する必要があります。更新またはロールバックの強制を検証しないと、データ損失などの致命的な結果が生じる可能性があります。

前提条件

  • カタログがインストールされています。
  • Operator または拡張機能がインストールされている。
  • サービスアカウントを作成し、インストールする拡張機能をインストール、更新、管理するために十分なロールベースのアクセス制御 (RBAC) を割り当てました。詳細は サービスアカウントの作成 を参照してください。

手順

  1. 次の例に示すように、Operator または拡張機能のカスタムリソース (CR) を編集します。

    CR の例:

    apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    name: <clusterextension_name>
  spec:
    namespace: <installed_namespace>
    1 
    
    serviceAccount:
      name: <service_account_installer_name>
    2 
    
    source:
      sourceType: Catalog
      catalog:
        packageName: <package_name>
        channels:
          - <channel_name>
    3 
    
        version: <version_or_version_range>
    4 
    
        upgradeConstraintPolicy: SelfCertified
    5
    Copy to Clipboard Toggle word wrap

    1
    pipelines や my-extension など、バンドルをインストールする namespace を指定します。拡張機能は継続してクラスタースコープであり、異なる namespace にインストールされているリソースが含まれる可能性があります。
    2
    拡張機能をインストール、更新、管理するために作成したサービスアカウントの名前を指定します。
    3
    オプション: チャネル名を、pipelines-1.14 や latest などの配列の形で指定します。
    4
    オプション: インストールまたは更新するパッケージのバージョンまたはバージョン範囲 (1.14.0、1.14.x、>=1.16 など) を指定します。詳細は、「ターゲットバージョンを指定するカスタムリソース (CR) の例」および「バージョン範囲のサポート」を参照してください。
    5
    オプション: アップグレード制約ポリシーを指定します。更新またはロールバックを強制するには、フィールドを SelfCertified に設定します。指定されていない場合、デフォルト設定は CatalogProvided になります。CatalogProvided 設定が更新されるのは、新しいバージョンがパッケージ作成者によって設定されたアップグレード制約を満たしている場合だけです。

  2. 次のコマンドを実行して、Operator または拡張機能 CR に変更を適用します。 

    $ oc apply -f <extension_name>.yaml
    Copy to Clipboard Toggle word wrap

5.3.5. OpenShift Container Platform バージョンとの互換性
リンクのコピー

クラスター管理者は、OpenShift Container Platform クラスターを次のマイナーバージョンに更新する前に、インストールされているすべての Operator がクラスターの次のマイナーバージョン (4.y+1) と互換性のあるバンドルバージョンに更新されていることを確認する必要があります。

たとえば、Kubernetes は定期的に特定の API を非推奨とし、後続のリリースで削除します。拡張機能が非推奨の API を使用している場合、OpenShift Container Platform クラスターをその API が削除された Kubernetes バージョンに更新すると、拡張機能が機能しなくなる可能性があります。

Operator の作成者は、特定のバンドルバージョンがサポートされておらず、何らかの理由で特定のクラスターマイナーバージョン以降の OpenShift Container Platform で正しく動作しないことがわかっている場合、Operator と互換性のある OpenShift Container Platform の最大バージョンを設定できます。

作成者は、Operator プロジェクトのクラスターサービスバージョン (CSV) で olm.maxOpenShiftVersion アノテーションを設定することで、インストール済みの Operator を互換性のあるバージョンに更新する前に管理者がクラスターを更新するのを防ぐことができます。

olm.maxOpenShiftVersion アノテーションを含む CSV の例

apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  annotations:
    "olm.properties": '[{"type": "olm.maxOpenShiftVersion", "value": "<cluster_version>"}]'
1
Copy to Clipboard Toggle word wrap

1
Operator と互換性のある OpenShift Container Platform (4.y) の最新のマイナーバージョンを指定します。たとえば、value を 4.18 に設定すると、このバンドルがクラスターにインストールされている場合に、クラスターが 4.18 より後のマイナーバージョンに更新されなくなります。

olm.maxOpenShiftVersion フィールドが省略されている場合、この Operator によってクラスターの更新はブロックされません。

注記

OLM v1 は、クラスターの次のマイナーバージョン (4.y+1) を決定するときに、メジャーバージョンとマイナーバージョン (x と y) のみを比較対象として考慮します。パッチリリースまたはプレリリースバージョンとも呼ばれる z-stream バージョン (4.y.z) は無視されます。

たとえば、クラスターの現在のバージョンが 4.18.0 の場合、次のマイナーバージョンは 4.19 です。現在のバージョンが 4.18.0-rc1 の場合も、次のマイナーバージョンは 4.19 です。

5.3.5.1. olm クラスター Operator によってブロックされたクラスターの更新
リンクのコピー

インストール済み Operator の olm.maxOpenShiftVersion フィールドが設定されており、クラスター管理者が、Operator が有効な更新パスを提供しないバージョンにクラスターを更新しようとすると、クラスターの更新が失敗し、olm クラスター Operator の Upgradeable ステータスが False に設定されます。

この問題を解決するには、クラスター管理者は、インストールされている Operator を有効な更新パスのあるバージョンに更新するか (有効な更新パスがある場合)、Operator をアンインストールする必要があります。その後、クラスターの更新を再度試みることができます。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat