5.2. エッジのアップグレード
Operator Lifecycle Manager (OLM) v1 はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
インストールされたクラスター拡張機能のアップグレードエッジ (アップグレードパスまたはアップグレード制約とも呼ばれる) を決定する場合、Operator Lifecycle Manager (OLM) v1 は、OpenShift Container Platform 4.16 以降で既存の OLM セマンティクスをサポートします。このサポートは、replaces、skips、skipRange ディレクティブなど、既存の OLM の動作に従いますが、いくつかの違いがあります。
既存の OLM セマンティクスをサポートすることにより、OLM v1 はカタログからのアップグレードグラフを正確に尊重するようになりました。
現在、Operator Lifecycle Manager (OLM) v1 は、Red Hat が提供する Operator カタログなどのプライベートレジストリーを認証できません。これは既知の問題です。その結果、Red Hat Operators カタログがインストールされていることを前提とする OLM v1 の手順は機能しません。(OCPBUGS-36364)
元の既存 OLM 実装との違い
複数の後継候補がある場合の OLM v1 の動作は、次のように異なります。
- 既存の OLM では、チャネルヘッドに最も近い後継が選択されます。
- 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
1.0.0がインストールされている場合、OLM v1 の動作は次のように異なります。-
v2.0.0はスキップされ、replacesチェーン上にないため、既存の OLM はv2.0.0へのアップグレードエッジを検出しません。 -
OLM v1 には
replacesチェーンの概念がないため、OLM v1 はアップグレードエッジを検出します。OLM v1 は、現在インストールされているバージョンに対応するreplace、skip、またはskipRangeの値を持つすべてのエントリーを検索します。
-
5.2.1. バージョン範囲のサポート
Operator Lifecycle Manager (OLM) v1 では、Operator または拡張機能のカスタムリソース (CR) で比較文字列を使用してバージョン範囲を指定できます。CR でバージョン範囲を指定すると、OLM v1 は、そのバージョン範囲内で解決できる Operator の最新バージョンをインストールまたは更新します。
解決されるバージョンのワークフロー
- 解決されるバージョンは、Operator と環境の制約を満たす Operator の最新バージョンです。
- 正常に解決された場合、指定された範囲内の Operator 更新は自動的にインストールされます。
- 指定された範囲外にある場合、または正常に解決できない場合、その更新はインストールされません。
5.2.2. バージョン比較文字列
Operator または拡張機能のカスタムリソース (CR) の spec.version フィールドに比較文字列を追加することで、バージョン範囲を定義できます。比較文字列は、スペースまたはコンマで区切られた値と、二重引用符 (") で囲まれた 1 つ以上の比較演算子のリストです。文字列の間に比較演算子の OR または二重縦棒 (||) を含めることで、別の比較文字列を追加できます。
| 比較演算子 | 定義 |
|---|---|
|
| 等しい |
|
| 等しくない |
|
| より大きい |
|
| より小さい |
|
| より大か等しい |
|
| より小か等しい |
次の例のような範囲比較を使用して、Operator または拡張機能の CR でバージョン範囲を指定できます。
バージョン範囲の比較例
apiVersion: olm.operatorframework.io/v1alpha1 kind: ClusterExtension metadata: name: pipelines-operator spec: packageName: openshift-pipelines-operator-rh installNamespace: <namespace_name> version: ">=1.11, <1.13"
すべてのタイプの比較文字列でワイルドカード文字を使用できます。OLM v1 では、x、X、およびアスタリスク (*) をワイルドカード文字として使用できます。ワイルドカード文字と比較演算子の等号 (=) を使用する場合は、パッチまたはマイナーバージョンレベルでの比較を定義します。
| ワイルドカード比較 | 一致する文字列 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
比較演算子のチルダ (~) を使用して、パッチリリースを比較できます。パッチリリースの比較では、次のメジャーバージョンまでのマイナーバージョンを指定します。
| パッチリリースの比較 | 一致する文字列 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
比較演算子のキャレット (^) を使用して、メジャーリリースを比較できます。最初の stable リリースが公開される前にメジャーリリース比較を使用する場合、マイナーバージョンにより API の安定レベルが定義されます。セマンティックバージョン (semver) 仕様では、最初の安定リリースは 1.0.0 バージョンとして公開されます。
| メジャーリリースの比較 | 一致する文字列 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.2.3. ターゲットバージョンを指定するカスタムリソース (CR) の例
Operator Lifecycle Manager (OLM) v1 では、クラスター管理者はカスタムリソース (CR) で Operator または拡張機能のターゲットバージョンを宣言的に設定できます。
次のフィールドのいずれかを指定して、ターゲットバージョンを定義できます。
- チャネル
- バージョン番号
- バージョン範囲
CR でチャネルを指定すると、OLM v1 は、指定されたチャネル内で解決できる最新バージョンの Operator または拡張機能をインストールします。指定されたチャネルに更新が公開されると、OLM v1 はそのチャネルから解決できる最新リリースに自動的に更新します。
チャネルを指定した CR の例
apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
name: pipelines-operator
spec:
packageName: openshift-pipelines-operator-rh
installNamespace: <namespace_name>
serviceAccount:
name: <service_account>
channel: latest 1
- 1
- 指定されたチャネルから解決できる最新リリースをインストールします。チャネルへの更新は自動的にインストールされます。
CR で Operator または拡張機能のターゲットバージョンを指定すると、OLM v1 は指定されたバージョンをインストールします。CR でターゲットバージョンが指定されている場合、カタログに更新が公開されても OLM v1 はターゲットバージョンを変更しません。
クラスターにインストールされている Operator のバージョンを更新する必要がある場合は、Operator の CR を手動で編集する必要があります。Operator のターゲットバージョンを指定すると、Operator のバージョンが指定されたリリースに固定されます。
ターゲットバージョンを指定した CR の例
apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
name: pipelines-operator
spec:
packageName: openshift-pipelines-operator-rh
installNamespace: <namespace_name>
serviceAccount:
name: <service_account>
version: "1.11.1" 1
- 1
- ターゲットのバージョンを指定します。インストールされている Operator または拡張機能のバージョンを更新する必要がある場合は、CR のこのフィールドを目的のターゲットバージョンに手動で更新する必要があります。
Operator または拡張機能の許容可能なバージョン範囲を定義する場合は、比較文字列を使用してバージョン範囲を指定できます。バージョン範囲を指定すると、OLM v1 は、Operator Controller で解決できる最新バージョンの Operator または拡張機能をインストールします。
バージョン範囲を指定した CR の例
apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
name: pipelines-operator
spec:
packageName: openshift-pipelines-operator-rh
installNamespace: <namespace_name>
serviceAccount:
name: <service_account>
version: ">1.11.1" 1
- 1
- 必要なバージョン範囲が、バージョン
1.11.1より大きいことを指定します。詳細は、「バージョン範囲のサポート」を参照してください。
CR を作成または更新した後、次のコマンドを実行して設定ファイルを適用します。
コマンド構文
$ oc apply -f <extension_name>.yaml
5.2.4. 更新またはロールバックの強制
OLM v1 は、次のメジャーバージョンへの自動更新や以前のバージョンへのロールバックをサポートしていません。メジャーバージョンの更新またはロールバックを実行する場合は、手動で更新を確認して強制する必要があります。
手動更新またはロールバックを強制した場合の影響を確認する必要があります。更新またはロールバックの強制を検証しないと、データ損失などの致命的な結果が生じる可能性があります。
前提条件
- カタログがインストールされています。
- Operator または拡張機能がインストールされている。
- サービスアカウントを作成し、インストールする拡張機能をインストール、更新、管理するために十分なロールベースのアクセス制御 (RBAC) を割り当てました。詳細は GCP サービスアカウントの作成 を参照してください。
手順
次の例に示すように、Operator または拡張機能のカスタムリソース (CR) を編集します。
CR の例:
apiVersion: olm.operatorframework.io/v1alpha1 kind: Operator metadata: name: <operator_name> 1 spec: packageName: <package_name> 2 installNamespace: <namespace_name> serviceAccount: name: <service_account> version: <version> 3 upgradeConstraintPolicy: Ignore 4
次のコマンドを実行して、Operator または拡張機能 CR に変更を適用します。
$ oc apply -f <extension_name>.yaml
関連情報
