OpenShift クラスタで運用しているOperatorのバージョンアップは、スムーズに行うために重要な作業ですが、どのバージョンを経由すればよいかがわからないことがよくあります。
特に非接続環境では、必要なバージョンを事前にミラーリングすることが求められます。
この記事では、Operatorのバージョンアップパスを調べる方法について、具体的なTipsを紹介します。
OpenShiftバージョンに対応するOperatorのサポートバージョンを確認する
OpenShiftのバージョンに対応するOperatorのサポートバージョンは、OpenShiftのライフサイクルマネージャーで確認できます。ライフサイクルマネージャーでは、各OperatorがどのOpenShiftバージョンでサポートされているか、または利用可能なバージョン情報を簡単に確認できます。
ライフサイクルマネージャーでの確認手順
- ライフサイクルマネージャーのページにアクセス
- 以下のリンクから、Red Hat の OpenShift Operator ライフサイクルポリシーのページにアクセスします。
- https://access.redhat.com/ja/support/policy/updates/openshift_operators
- Operatorを検索
- ページ内で、対象の Operator 名を検索します。
- Operator のサポート情報を確認
- 各 Operator のサポート情報が一覧で表示されます。
- Platform Aligned: OpenShift の特定のバージョンと連携してサポートされる Operator
- Platform Agnostic: OpenShift のバージョンに依存せず、独立してサポートされる Operator
- Rolling Stream: 継続的に更新される Operator
- 対象のOperatorの最新バージョンとサポート終了日、メンテナンスサポート終了日などの詳細も確認することができます。
- 各 Operator のサポート情報が一覧で表示されます。
Operatorのバージョンアップパスを調べる
Operatorをアップグレードする際、どのバージョン間でのアップグレードがサポートされているかを知ることが大切です。これを調べるために、OpenShiftのocコマンドを使って、OperatorのPackageManifestを確認する方法があります。skipRangeというフィールドに、どのバージョンからアップグレードが可能か、どのバージョンを経由する必要があるかが記載されています。
PackageManifestを確認する
例えば、以下のコマンドで対象のOperatorのバージョン情報を確認できます。
$ oc get packagemanifest <operator-name> -o yaml | grep -E "currentCSV|skipRange"このコマンドは、指定したOperatorのバージョンと、それに関連するskipRange情報を表示します。この情報をもとに、アップグレードが可能なバージョンや経由すべきバージョンを確認できます。
Operatorごとのアップグレードポリシーを正しく理解する
OpenShiftのOperatorは、OLM（Operator Lifecycle Manager）によってアップグレード経路が制御されています。
しかし実際にはOperatorごとに「どこまで一気に上げられるか」が異なり、olm.skipRange の定義を読み違えると、思わぬエラーや依存関係の不整合を引き起こすこともあります。
ここでは、ClusterLogging・Quay を例に、正しいアップグレードの考え方を整理します。
■ ClusterLogging Operator の例
まず、以下のような出力が得られたとします。
- currentCSV: cluster-logging.v6.1.7
currentCSVDesc:
olm.skipRange: '>=5.9.0-0 <6.1.7'
- currentCSV: cluster-logging.v6.2.3
currentCSVDesc:
olm.skipRange: '>=6.0.0-0 <6.2.3'
olm.skipRange は「このCSV（バージョン）にアップグレード可能な旧バージョンの範囲」を意味します。
つまり：
- v6.1.7 は
5.9.0 ≤ x < 6.1.7の範囲からアップグレード可能 - v6.2.3 は
6.0.0 ≤ x < 6.2.3の範囲からアップグレード可能
したがって、
🟥 v5.9.4 → v6.2.3 の直接アップグレードは範囲外（不可能）
🟩 正しい経路は次の通り：
v5.9.4 → v6.1.7 → v6.2.3
つまり、マイナーバージョンを跨ぐ際には中間バージョン（6.1系）を経由する必要があります。
また、余談ですが、OpenShift Operator ライフサイクルポリシーで ClusterLogging のサポート終了日、メンテナンスサポート終了日を確認すると、偶数バージョンのみメンテナンスサポートが設定されています。
非接続環境でアップグレードを容易に、頻繁にできない環境では、偶数バージョンを選定しておく方がサポートの観点では無難でしょう。
■ Quay Operator の例
出力例：
- currentCSV: quay-operator.v3.11.12
olm.skipRange: '>=3.8.x <3.11.12'
- currentCSV: quay-operator.v3.12.11
olm.skipRange: '>=3.9.x <3.12.11'
- currentCSV: quay-operator.v3.13.7
olm.skipRange: '>=3.10.x <3.13.7'
- currentCSV: quay-operator.v3.14.3
olm.skipRange: '>=3.11.x <3.14.3'
この場合、たとえば v3.11.12 → v3.14.3 へのアップグレードを考えると、
v3.14.3 の skipRange は >=3.11.x なので、3.11.12 は範囲内。
したがってこのケースでは、3.11系から3.14系への直接アップグレードが可能です。
🟩 正： v3.11.12 → v3.14.3（OK）
🟥 ただし、3.10.xやそれ以前からは直接不可。
このように、Quay Operatorは比較的「前の3マイナーバージン」程度までのアップグレードを許容する設計になっています。
Red Hat Quay Operator では、ClusterLogging と同様に偶数バージョンのみがメンテナンスサポート対象となっています。
そのため、アップグレード計画を立てる際は、対象となる OpenShift（OCP）バージョンと対応する Quay のメジャーバージョンを慎重に選定することが重要です。
特に非接続環境でのアップグレードでは、ミラーリングする Operator のバージョンを事前に見極めておくことで、サポート期間のずれによるトラブルを防止できます。
OCP と Quay Operator のバージョン整合性を保つことで、安定した運用と確実なサポート継続が可能になります。
※出典：Red Hat Customer Portal「製品ライフサイクル情報 – Red Hat Quay」より引用（閲覧日：2025年11月時点）
非接続環境での Operator バージョンのミラーリング
非接続環境では、必要な Operator のバージョンをミラーリングする必要があります。
この際、ライフサイクルマネージャーのページで確認したサポートされているバージョンをもとに、必要なバージョンを選定し、ミラーリングを行ってください。
参考リンク
これらのリソースを活用して、Operator のバージョンアップパスやサポート情報を確認し、適切なアップグレード計画を立ててください。
非接続環境でのアップグレードは手間がかかりますが、確実な準備と理解が成功の鍵です。
ミラーリング対象の検討、バージョン選定や事前検証を丁寧に進めて、無事にアップグレードを完了させましょう！
コメント