第5章 更新
5.1. OpenShift Virtualization の更新
Operator Lifecycle Manager(OLM) が OpenShift Virtualization の z-stream およびマイナーバージョンの更新を提供する方法を確認します。
5.1.1. RHEL 9 上の OpenShift Virtualization
OpenShift Virtualization 4.17 は、Red Hat Enterprise Linux (RHEL) 9 をベースにしています。標準の OpenShift Virtualization 更新手順に従って、RHEL 8 をベースとするバージョンから OpenShift Virtualization 4.17 に更新できます。追加の手順は必要ありません。
以前のバージョンと同様に、実行中のワークロードを中断することなく更新を実行できます。OpenShift Virtualization 4.17 では、RHEL 8 ノードから RHEL 9 ノードへのライブマイグレーションがサポートされています。
5.1.1.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 値を変更する前に、仮想マシンをシャットダウンする必要があります。
5.1.2. OpenShift Virtualization の更新について
- Operator Lifecycle Manager(OLM) は OpenShift Virtualization Operator のライフサイクルを管理します。Red Hat OpenShift Service on AWS のインストール中にデプロイされる Marketplace Operator により、クラスターで外部 Operators を使用できるようになります。
- OLM は、OpenShift Virtualization の z-stream およびマイナーバージョンの更新を提供します。Red Hat OpenShift Service on AWS を次のマイナーバージョンに更新すると、マイナーバージョンの更新が利用可能になります。最初に Red Hat OpenShift Service on AWS を更新しない限り、OpenShift Virtualization を次のマイナーバージョンに更新できません。
- OpenShift Virtualization サブスクリプションは、stable という名前の単一の更新チャネルを使用します。stable チャネルにより、OpenShift Virtualization と Red Hat OpenShift Service on AWS のバージョンとの互換性が確保されます。
サブスクリプションの承認ストラテジーが Automatic に設定されている場合に、更新プロセスは、Operator の新規バージョンが stable チャネルで利用可能になるとすぐに開始します。サポート可能な環境を確保するために、自動 承認ストラテジーを使用することを強く推奨します。OpenShift Virtualization の各マイナーバージョンは、対応する Red Hat OpenShift Service on AWS バージョンを実行している場合にのみサポートされます。たとえば、Red Hat OpenShift Service on AWS 4.17 で OpenShift Virtualization 4.17 を実行する必要があります。
- クラスターのサポート容易性および機能が損なわれるリスクがあるので、Manual 承認ストラテジーを選択することは可能ですが、推奨していません。Manual 承認ストラテジーでは、保留中のすべての更新を手動で承認する必要があります。Red Hat OpenShift Service on AWS と OpenShift Virtualization の更新が同期していない場合、クラスターはサポートされなくなります。
- 更新の完了までにかかる時間は、ネットワーク接続によって異なります。ほとんどの自動更新は 15 分以内に完了します。
- OpenShift Virtualization を更新しても、ネットワーク接続が中断されることはありません。
- データボリュームおよびその関連付けられた永続ボリューム要求は更新時に保持されます。
AWS Elastic Block Store (EBS) ストレージを使用する仮想マシンを実行している場合、ライブマイグレーションができないため、Red Hat OpenShift Service on AWS クラスター更新がブロックされる可能性があります。
回避策として、仮想マシンを再設定し、クラスターの更新時にそれらの電源を自動的にオフになるようにできます。evictionStrategy フィールドを None に、runStrategy フィールドを Always に設定します。
5.1.2.1. ワークロードの更新について
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 回の試行のみがバッファーに保持されます。これにより、デバッグ用の情報を保持しながら、移行オブジェクトがシステムに蓄積されるのを防ぎます。
5.1.3. ワークロードの更新方法の設定
HyperConverged カスタムリソース (CR) を編集することにより、ワークロードの更新方法を設定できます。
前提条件
ライブマイグレーションを更新方法として使用するには、まずクラスターでライブマイグレーションを有効にする必要があります。
注記VirtualMachineInstanceCR にevictionStrategy: LiveMigrateが含まれており、仮想マシンインスタンス (VMI) がライブマイグレーションをサポートしない場合には、VMI は更新されません。
手順
デフォルトエディターで
HyperConvergedCR を作成するには、以下のコマンドを実行します。$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
HyperConvergedCR のworkloadUpdateStrategyスタンザを編集します。以下に例を示します。apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: workloadUpdateStrategy: workloadUpdateMethods: 1 - LiveMigrate 2 - Evict 3 batchEvictionSize: 10 4 batchEvictionInterval: "1m0s" 5 # ...- 1
- ワークロードの自動更新を実行するのに使用できるメソッド。設定可能な値は
LiveMigrateおよびEvictです。上記の例のように両方のオプションを有効にした場合に、ライブマイグレーションをサポートする VMI にはLiveMigrateを、ライブマイグレーションをサポートしない VMI にはEvictを、更新に使用します。ワークロードの自動更新を無効にするには、workloadUpdateStrategyスタンザを削除するか、workloadUpdateMethods: []を設定して配列を空のままにします。 - 2
- 中断を最小限に抑えた更新メソッド。ライブマイグレーションをサポートする VMI は、仮想マシン (VM) ゲストを更新されたコンポーネントが有効なっている新規 Pod に移行することで更新されます。
LiveMigrateがリストされている唯一のワークロード更新メソッドである場合には、ライブマイグレーションをサポートしない VMI は中断または更新されません。 - 3
- アップグレード時に VMI Pod をシャットダウンする破壊的な方法。
Evictは、ライブマイグレーションがクラスターで有効でない場合に利用可能な唯一の更新方法です。VMI がrunStrategy: Alwaysに設定されたVirtualMachineオブジェクトによって制御される場合には、新規の VMI は、更新されたコンポーネントを使用して新規 Pod に作成されます。 - 4
Evictメソッドを使用して一度に強制的に更新できる VMI の数。これは、LiveMigrateメソッドには適用されません。- 5
- 次のワークロードバッチをエビクトするまで待機する間隔。これは、
LiveMigrateメソッドには適用されません。
注記HyperConvergedCR のspec.liveMigrationConfigスタンザを編集することにより、ライブマイグレーションの制限とタイムアウトを設定できます。- 変更を適用するには、エディターを保存し、終了します。
5.1.4. 保留中の Operator 更新の承認
5.1.4.1. 保留中の Operator 更新の手動による承認
インストールされた Operator のサブスクリプションの承認ストラテジーが Manual に設定されている場合、新規の更新が現在の更新チャネルにリリースされると、インストールを開始する前に更新を手動で承認する必要があります。
前提条件
- Operator Lifecycle Manager (OLM) を使用して以前にインストールされている Operator。
手順
-
Red Hat OpenShift Service on AWS 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 に変更されます。
5.1.5. 更新ステータスの監視
5.1.5.1. OpenShift Virtualization アップグレードステータスのモニタリング
OpenShift Virtualization Operator のアップグレードのステータスをモニターするには、クラスターサービスバージョン (CSV) PHASE を監視します。Web コンソールを使用するか、ここに提供されているコマンドを実行して CSV の状態をモニターすることもできます。
PHASE および状態の値は利用可能な情報に基づく近似値になります。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにログインしている。 -
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
5.1.5.2. 以前の OpenShift Virtualization ワークロードの表示
CLI を使用して、以前のワークロードのリストを表示できます。
クラスターに以前の仮想化 Pod がある場合には、OutdatedVirtualMachineInstanceWorkloads アラートが実行されます。
手順
以前の仮想マシンインスタンス (VMI) の一覧を表示するには、以下のコマンドを実行します。
$ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces
ワークロードの更新を設定して、VMI が自動的に更新されるようにします。
