Red Hat Summit5.2. 更新パス
インストールされたクラスター拡張機能のアップグレードパス (アップグレードエッジまたはアップグレード制約とも呼ばれる) を決定する場合、Operator Lifecycle Manager (OLM) v1 は、OpenShift Container Platform 4.16 以降で既存の OLM セマンティクスをサポートします。このサポートは、replaces、skips、skipRange ディレクティブなど、既存の OLM の動作に従いますが、いくつかの違いがあります。
既存の OLM セマンティクスをサポートすることにより、OLM v1 はカタログからの更新グラフを正確に反映します。
元の既存 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
関連情報
5.2.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
- 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 です。
関連情報
- Deprecated API Migration Guide (Kubernetes ドキュメント)
5.2.5.1. olm クラスター Operator によってブロックされたクラスターの更新
インストール済み Operator の olm.maxOpenShiftVersion フィールドが設定されており、クラスター管理者が、Operator が有効な更新パスを提供しないバージョンにクラスターを更新しようとすると、クラスターの更新が失敗し、olm クラスター Operator の Upgradeable ステータスが False に設定されます。
この問題を解決するには、クラスター管理者は、インストールされている Operator を有効な更新パスのあるバージョンに更新するか (有効な更新パスがある場合)、Operator をアンインストールする必要があります。その後、クラスターの更新を再度試みることができます。
