第6章 更新
6.1. OpenShift Virtualization の更新 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization を最新の状態に保ち、OpenShift Container Platform との互換性を維持する方法を説明します。
6.1.1. OpenShift Virtualization の更新について リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization をインストールするときに、更新チャネルと承認ストラテジーを選択します。更新チャネルによって、OpenShift Virtualization が更新されるバージョンが決まります。承認ストラテジー設定により、更新が自動的に行われるか、手動の承認が必要かどうかが決まります。どちらの設定もサポート性に影響を与える可能性があります。
6.1.1.1. 推奨設定 リンクのコピーリンクがクリップボードにコピーされました!
サポート可能な環境を維持するには、次の設定を使用します。
- 更新チャネル: stable
- 承認ストラテジー: Automatic
ほとんどの OpenShift Virtualization インストールでは、stable リリースチャネルと Automatic 承認ストラテジーが推奨されます。リスクを理解している場合にのみ、他の設定を使用してください。
これらの設定により、Operator の新しいバージョンが stable チャネルで利用可能になると、更新プロセスが自動的に開始されます。これにより、OpenShift Virtualization と OpenShift Container Platform のバージョンの互換性が維持され、OpenShift Virtualization のバージョンが実稼働環境に適したものになります。
OpenShift Virtualization の各マイナーバージョンは、対応する OpenShift Container Platform バージョンを実行する場合にのみサポートされます。たとえば、OpenShift Virtualization 4.19 は OpenShift Container Platform 4.19 で実行する必要があります。
6.1.1.2. 予想されること リンクのコピーリンクがクリップボードにコピーされました!
- 更新の完了までにかかる時間は、ネットワーク接続によって異なります。ほとんどの自動更新は 15 分以内に完了します。
- OpenShift Virtualization を更新しても、ネットワーク接続が中断されることはありません。
- データボリュームとそれに関連付けられた永続ボリューム要求は、更新中に保持されます。
ホストパスプロビジョナーストレージを使用する仮想マシンを実行している場合、それらをライブマイグレーションすることはできず、OpenShift Container Platform クラスターの更新をブロックする可能性があります。
回避策として、仮想マシンを再設定し、クラスターの更新時にそれらの電源を自動的にオフになるようにできます。evictionStrategy フィールドを None に、runStrategy フィールドを Always に設定します。
6.1.1.3. 更新の仕組み リンクのコピーリンクがクリップボードにコピーされました!
- Operator Lifecycle Manager(OLM) は OpenShift Virtualization Operator のライフサイクルを管理します。OpenShift Container Platform のインストール時にデプロイされる Marketplace Operator により、クラスターで外部 Operator が利用できるようになります。
- OLM は、OpenShift Virtualization の z-stream およびマイナーバージョンの更新を提供します。OpenShift Container Platform を次のマイナーバージョンに更新すると、マイナーバージョンの更新が利用可能になります。OpenShift Container Platform を最初に更新しない限り、OpenShift Virtualization を次のマイナーバージョンに更新できません。
6.1.1.4. 更新設定の変更 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization Operator サブスクリプションで、更新チャネルと承認ストラテジーを変更することで、更新をいつ、どのようにインストールするかを制御できます。
前提条件
- OpenShift Virtualization Operator がインストールされている。
- クラスター管理者として OpenShift Container Platform の Web コンソールにログインしている。
手順
-
Operators
Installed Operators をクリックします。 - リストから OpenShift Virtualization を選択します。
- Subscription タブをクリックします。
- Subscription details セクションで、変更する設定をクリックします。たとえば、承認ストラテジーを Manual から Automatic に変更するには、Manual をクリックします。
- 開いたウィンドウで、新しい更新チャネルまたは承認ストラテジーを選択します。
- Save をクリックします。
6.1.1.5. 手動承認ストラテジー リンクのコピーリンクがクリップボードにコピーされました!
Manual 承認ストラテジーを使用する場合は、すべての保留中の更新を手動で承認する必要があります。OpenShift Container Platform および OpenShift Virtualization の更新の同期が取れていない場合には、クラスターはサポートされなくなります。クラスターのサポート性と機能性を危険にさらさないようにするには、Automatic 承認ストラテジーを使用します。
Manual 承認ストラテジーを使用する必要がある場合は、保留中の Operator 更新が利用可能になり次第承認し、サポート可能なクラスターを維持します。
6.1.1.6. 保留中の Operator 更新の手動による承認 リンクのコピーリンクがクリップボードにコピーされました!
インストールされた Operator のサブスクリプションの承認ストラテジーが Manual に設定されている場合、新規の更新が現在の更新チャネルにリリースされると、インストールを開始する前に更新を手動で承認する必要があります。
前提条件
- Operator Lifecycle Manager (OLM) を使用して以前にインストールされている Operator。
手順
-
OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Operators
Installed Operators に移動します。 - 更新が保留中の Operator は Upgrade available のステータスを表示します。更新する Operator の名前をクリックします。
- Subscription タブをクリックします。承認が必要な更新は、Upgrade status の横に表示されます。たとえば、1 requires approval が表示される可能性があります。
- 1 requires approval をクリックしてから、Preview Install Plan をクリックします。
- 更新に利用可能なリソースとして一覧表示されているリソースを確認します。問題がなければ、Approve をクリックします。
-
Operators
Installed Operators ページに戻り、更新の進捗をモニターします。完了時に、ステータスは Succeeded および Up to date に変更されます。
6.1.2. RHEL 9 の互換性 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization 4.19 は、Red Hat Enterprise Linux (RHEL) 9 をベースにしています。標準の OpenShift Virtualization 更新手順に従って、RHEL 8 をベースとするバージョンから OpenShift Virtualization 4.19 に更新できます。追加の手順は必要ありません。
以前のバージョンと同様に、実行中のワークロードを中断することなく更新を実行できます。OpenShift Virtualization 4.19 では、RHEL 8 ノードから RHEL 9 ノードへのライブマイグレーションがサポートされています。
6.1.2.1. RHEL 9 マシンタイプ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization に含まれるすべての仮想マシンテンプレートは、デフォルトで RHEL 9 マシンタイプ machineType: pc-q35-rhel9.<y>.0 を使用するようになりました。この場合の <y> は RHEL 9 の最新のマイナーバージョンに対応する 1 桁の数字です。たとえば、RHEL 9.2 の場合は pc-q35-rhel9.2.0 の値が使用されます。
OpenShift Virtualization を更新しても、既存仮想マシンの machineType 値は変更されません。これらの仮想マシンは、引き続き更新前と同様に機能します。RHEL 9 での改良を反映するために、オプションで仮想マシンのマシンタイプを変更できます。
仮想マシンの machineType 値を変更する前に、仮想マシンをシャットダウンする必要があります。
6.1.3. 更新ステータスの監視 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization Operator の更新のステータスをモニターするには、クラスターサービスバージョン (CSV) PHASE を監視します。Web コンソールまたは CLI を使用して、CSV の状態を監視することもできます。
PHASE および状態の値は利用可能な情報に基づく近似値になります。
前提条件
- クラスター管理者として OpenShift Container Platform クラスターにログインしている。
-
OpenShift CLI (
oc) がインストールされている。
手順
以下のコマンドを実行します。
$ oc get csv -n openshift-cnv出力を確認し、
PHASEフィールドをチェックします。以下に例を示します。出力例
VERSION REPLACES PHASE 4.9.0 kubevirt-hyperconverged-operator.v4.8.2 Installing 4.9.0 kubevirt-hyperconverged-operator.v4.9.0 Replacingオプション: 以下のコマンドを実行して、すべての OpenShift Virtualization コンポーネントの状態の集約されたステータスをモニターします。
$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv \ -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}'アップグレードが成功すると、以下の出力が得られます。
出力例
ReconcileComplete True Reconcile completed successfully Available True Reconcile completed successfully Progressing False Reconcile completed successfully Degraded False Reconcile completed successfully Upgradeable True Reconcile completed successfully
6.1.4. 仮想マシンワークロードの更新 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Virtualization を更新すると、ライブマイグレーションをサポートしている場合には libvirt、virt-launcher、および qemu などの仮想マシンのワークロードが自動的に更新されます。
各仮想マシンには、仮想マシンインスタンス (VMI) を実行する virt-launcher Pod があります。virt-launcher Pod は、仮想マシン (VM) のプロセスを管理するために使用される libvirt のインスタンスを実行します。
HyperConverged カスタムリソース (CR) の spec.workloadUpdateStrategy スタンザを編集して、ワークロードの更新方法を設定できます。ワークロードの更新方法として、LiveMigrate と Evict の 2 つが利用可能です。
Evict メソッドは VMI Pod をシャットダウンするため、デフォルトでは LiveMigrate 更新ストラテジーのみが有効になっています。
LiveMigrate が有効な唯一の更新ストラテジーである場合:
- ライブマイグレーションをサポートする VMI は更新プロセス時に移行されます。VM ゲストは、更新されたコンポーネントが有効になっている新しい Pod に移動します。
ライブマイグレーションをサポートしない VMI は中断または更新されません。
-
VMI に
LiveMigrateエビクションストラテジーがあるが、ライブマイグレーションをサポートしていない場合、VMI は更新されません。
-
VMI に
LiveMigrate と Evict の両方を有効にした場合:
-
ライブマイグレーションをサポートする VMI は、
LiveMigrate更新ストラテジーを使用します。 -
ライブマイグレーションをサポートしない VMI は、
Evict更新ストラテジーを使用します。VMI がrunStrategy: Alwaysに設定されたVirtualMachineオブジェクトによって制御される場合、新規の VMI は、更新されたコンポーネントを使用して新規 Pod に作成されます。
移行の試行とタイムアウト
ワークロードを更新するときに、Pod が次の期間 Pending 状態の場合、ライブマイグレーションは失敗します。
- 5 分間
-
Pod が
Unschedulableであるために保留中の場合。 - 15 分
- 何らかの理由で Pod が保留状態のままになっている場合。
VMI が移行に失敗すると、virt-controller は VMI の移行を再試行します。すべての移行可能な VMI が新しい virt-launcher Pod で実行されるまで、このプロセスが繰り返されます。ただし、VMI が不適切に設定されている場合、これらの試行は無限に繰り返される可能性があります。
各試行は、移行オブジェクトに対応します。直近の 5 回の試行のみがバッファーに保持されます。これにより、デバッグ用の情報を保持しながら、移行オブジェクトがシステムに蓄積されるのを防ぎます。
6.1.4.1. ワークロードの更新方法の設定 リンクのコピーリンクがクリップボードにコピーされました!
HyperConverged カスタムリソース (CR) を編集することで、クラスターのアップグレード中に仮想マシンのワークロードがどのように更新されるかを設定できます。
前提条件
クラスターでライブマイグレーションを有効化している。
注記VirtualMachineInstanceCR にevictionStrategy: LiveMigrateが含まれており、仮想マシンインスタンス (VMI) がライブマイグレーションをサポートしない場合には、VMI は更新されません。-
OpenShift CLI (
oc) がインストールされている。
手順
デフォルトエディターで
HyperConvergedCR を作成するには、以下のコマンドを実行します。$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvHyperConvergedCR のworkloadUpdateStrategyスタンザを編集します。以下に例を示します。apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: workloadUpdateStrategy: workloadUpdateMethods: - LiveMigrate - Evict batchEvictionSize: 10 batchEvictionInterval: "1m0s" # ...spec.workloadUpdateStrategy.workloadUpdateMethodsは、ワークロードの自動更新を実行するために使用できる方法を定義します。設定可能な値はLiveMigrateおよびEvictです。上記の例のように両方のオプションを有効にした場合に、ライブマイグレーションをサポートする VMI にはLiveMigrateを、ライブマイグレーションをサポートしない VMI にはEvictを、更新に使用します。ワークロードの自動更新を無効にするには、workloadUpdateStrategyスタンザを削除するか、workloadUpdateMethods: []を設定して配列を空のままにします。-
LiveMigrateは、最も影響の少ない更新方法です。ライブマイグレーションをサポートする VMI は、仮想マシン (VM) ゲストを更新されたコンポーネントが有効なっている新規 Pod に移行することで更新されます。LiveMigrateがリストされている唯一のワークロード更新メソッドである場合には、ライブマイグレーションをサポートしない VMI は中断または更新されません。 -
Evictは、アップグレード時に VMI Pod をシャットダウンする破壊的な方法です。Evictは、ライブマイグレーションがクラスターで有効でない場合に利用可能な唯一の更新方法です。VMI がrunStrategy: Alwaysに設定されたVirtualMachineオブジェクトによって制御される場合には、新規の VMI は、更新されたコンポーネントを使用して新規 Pod に作成されます。
-
-
spec.workloadUpdateStrategy.batchEvictionSizeは、Evictメソッドを使用して一度に強制的に更新できる VMI の数を定義します。これは、LiveMigrateメソッドには適用されません。 spec.workloadUpdateStrategy.batchEvictionIntervalは、次のワークロードのバッチをエビクトさせるまでの待ち時間を定義します。これは、LiveMigrateメソッドには適用されません。注記HyperConvergedCR のspec.liveMigrationConfigスタンザを編集することにより、ライブマイグレーションの制限とタイムアウトを設定できます。
- 変更を適用するには、エディターを保存し、終了します。
6.1.4.2. 古くなった仮想マシンワークロードの表示 リンクのコピーリンクがクリップボードにコピーされました!
CLI を使用して、古くなった仮想マシン (VM) ワークロードのリストを表示できます。
クラスターに以前の仮想化 Pod がある場合には、OutdatedVirtualMachineInstanceWorkloads アラートが実行されます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
以前の仮想マシンインスタンス (VMI) の一覧を表示するには、以下のコマンドを実行します。
$ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces
6.1.5. Control Plane Only の更新 リンクのコピーリンクがクリップボードにコピーされました!
Control Plane Only の更新を使用すると、中間アップグレード中に仮想マシンのワークロードが更新されるのを防ぎながら、OpenShift Container Platform の Extended Update Support (EUS) バージョン間を更新できます。
OpenShift Container Platform の偶数番号のマイナーバージョンは、すべて Extended Update Support (EUS) バージョンです。ただし、Kubernetes では、マイナーバージョンの更新を順次行う必要があります。そのため、ある EUS バージョンから次の EUS バージョンへ直接更新することはできません。
EUS のバージョン間を移行するには、まず OpenShift Virtualization を次の奇数マイナーバージョンの最新の z-stream リリースに更新する必要があります。クラスターが OpenShift Container Platform のターゲット EUS バージョンに更新されると、OpenShift Virtualization の対応する更新が利用可能になります。その後、OpenShift Virtualization をターゲットの EUS バージョンに更新できます。
現在のマイナーバージョン内であれば、中間の各 z-stream 更新を適用しなくても、OpenShift Virtualization を最新の z-stream リリースに直接更新できます。
EUS バージョンの詳細は、OpenShift Container Platform ライフサイクルポリシー を参照してください。
6.1.5.1. Control Plane Only の更新中にワークロードの更新を防止する リンクのコピーリンクがクリップボードにコピーされました!
Extended Update Support (EUS) バージョンをあるバージョンから次のバージョンに更新する場合、OpenShift Virtualization がアップグレードプロセス中に仮想マシンを移行またはエビクトしないように、ワークロードの自動更新を一時的に無効にする必要があります。
OpenShift Container Platform 4.16 では、基盤となる Red Hat Enterprise Linux CoreOS (RHCOS) が Red Hat Enterprise Linux (RHEL) バージョン 9.4 にアップグレードされました。正しく動作するには、クラスター内のすべての virt-launcher Pod で同じバージョンの RHEL を使用する必要があります。
以前のバージョンから OpenShift Container Platform 4.16 にアップグレードした後、OpenShift Virtualization でワークロードの更新を再度有効にして、virt-launcher Pod を更新できるようにします。次の OpenShift Container Platform バージョンにアップグレードする前に、すべての VMI が最新のワークロードを使用していることを確認します。
$ oc get kv kubevirt-kubevirt-hyperconverged -o json -n openshift-cnv | jq .status.outdatedVirtualMachineInstanceWorkloads
前のコマンドが 0 より大きい値を返す場合は、古い virt-launcher Pod を持つすべての VMI をリスト表示し、ライブマイグレーションを開始してそれらを更新します。
$ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces
サポートされている OpenShift Container Platform リリースと各リリースで使用される RHEL バージョンのリストは、RHEL Versions Utilized by RHCOS and OpenShift Container Platform を参照してください。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - OpenShift Container Platform の EUS バージョンを実行中で、次の EUS バージョンに更新する計画がある。
- まだ中間マイナーバージョン (奇数番号) に更新していない。
- OpenShift Container Platform のドキュメントの説明に従って、ワーカーノードのマシン設定プールを一時停止している。
- デフォルトの Automatic 承認ストラテジーを使用することを推奨します。Manual 承認ストラテジーを使用する場合は、Web コンソールで保留中のすべての更新を承認する必要があります。詳細は、「保留中の Operator 更新の手動による承認」を参照してください。
手順
次のコマンドを実行し、
workloadUpdateMethods設定を記録します。$ oc get kv kubevirt-kubevirt-hyperconverged \ -n openshift-cnv -o jsonpath='{.spec.workloadUpdateStrategy.workloadUpdateMethods}'ワークロード更新方法を無効にするには、次のコマンドを実行します。
$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op":"replace","path":"/spec/workloadUpdateStrategy/workloadUpdateMethods", "value":[]}]'続行する前に、
HyperConvergedOperator がUpgradeableであることを確認します。$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"クラスターをソース EUS バージョンから OpenShift Container Platform の次のマイナーバージョンに手動で更新します。
$ oc adm upgrade現在のクラスターバージョンを確認します。
$ oc get clusterversion注記OpenShift Container Platform を次のバージョンに更新することは、OpenShift Virtualization を更新するための前提条件です。詳細は、OpenShift Container Platform ドキュメントの「クラスターの更新」セクションを参照してください。
OpenShift Virtualization を更新します。
- デフォルトの 自動 承認ストラテジーでは、OpenShift Container Platform の更新が完了すると、OpenShift Virtualization も自動的に更新されます。
- 手動 承認ストラテジーを使用する場合は、Web コンソールで保留中の更新を承認します。
OpenShift Virtualization の更新を監視します。
$ oc get csv -n openshift-cnvOpenShift Virtualization が、中間バージョンの最新の z-stream リリースに更新されたことを確認します。
$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.versions"-
HyperConvergedOperator が再びUpgradeable状態を報告するまで待機します。 - OpenShift Container Platform をターゲットの EUS バージョンに更新します。
クラスターのバージョンを確認します。
$ oc get clusterversionOpenShift Virtualization をターゲットの EUS バージョンに更新します。
- デフォルトの 自動 承認ストラテジーでは、OpenShift Virtualization は自動的に更新されます。
- 手動 承認ストラテジーを使用する場合は、Web コンソールで保留中の更新を承認します。
更新を監視します。
$ oc get csv -n openshift-cnvVERSIONフィールドがターゲットの EUS バージョンと一致し、PHASEフィールドがSucceededになると、更新が完了します。ステップ 1 で記録した
workloadUpdateMethods設定を復元します。$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv --type json -p \ "[{\"op\":\"add\",\"path\":\"/spec/workloadUpdateStrategy/workloadUpdateMethods\", \"value\":{WorkloadUpdateMethodConfig}}]"
検証
仮想マシン移行のステータスを確認します。
$ oc get vmim -A
次のステップ
- 各コンピュートノードのマシン設定プールを一時停止解除します。
6.1.6. 早期アクセスリリース リンクのコピーリンクがクリップボードにコピーされました!
ご使用の OpenShift Virtualization バージョンの candidate 更新チャネルをサブスクライブすると、開発中のビルドにアクセスできます。早期アクセスリリースは、Red Hat によって完全にテストされておらず、サポート対象でもありませんが、そのバージョン用に開発している機能やバグ修正をテストするために、非実稼働クラスターで使用することができます。
stable チャネルは実稼働システムに適しています。このチャネルは基盤となる OpenShift Container Platform のバージョンと一致し、完全にテストされています。OperatorHub で stable チャネルと candidate チャネルを切り替えることができます。ただし、candidate チャネルリリースから stable チャネルリリースへの更新は Red Hat によってテストされていません。
一部の candidate リリースは stable チャネルに昇格されます。ただし、candidate チャネルにのみ存在するリリースには、一般提供 (GA) されるすべての機能が含まれていない可能性があります。また、candidate ビルドの一部の機能は GA の前に削除される可能性があります。さらに、candidate リリースには、後の GA リリースへの更新パスがない場合があります。
candidate チャネルは、クラスターの破棄と再作成が許容されるテスト目的にのみ適しています。