第6章 更新
6.1. OpenShift Virtualization の更新
Operator Lifecycle Manager(OLM) が OpenShift Virtualization の z-stream およびマイナーバージョンの更新を提供する方法を確認します。
6.1.1. RHEL 9 上の OpenShift Virtualization
OpenShift Virtualization 4.14 は、Red Hat Enterprise Linux (RHEL) 9 をベースにしています。標準の OpenShift Virtualization 更新手順に従って、RHEL 8 をベースとするバージョンから OpenShift Virtualization 4.14 に更新できます。追加の手順は必要ありません。
以前のバージョンと同様に、実行中のワークロードを中断することなく更新を実行できます。OpenShift Virtualization 4.14 では、RHEL 8 ノードから RHEL 9 ノードへのライブマイグレーションがサポートされています。
6.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
値を変更する前に、仮想マシンをシャットダウンする必要があります。
6.1.2. OpenShift Virtualization の更新について
- 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 を次のマイナーバージョンに更新できません。
- OpenShift Virtualization サブスクリプションは、stable という名前の単一の更新チャネルを使用します。stable チャネルでは、OpenShift Virtualization および OpenShift Container Platform バージョンとの互換性が確保されます。
サブスクリプションの承認ストラテジーが Automatic に設定されている場合に、更新プロセスは、Operator の新規バージョンが stable チャネルで利用可能になるとすぐに開始します。サポート可能な環境を確保するために、自動 承認ストラテジーを使用することを強く推奨します。OpenShift Virtualization の各マイナーバージョンは、対応する OpenShift Container Platform バージョンを実行する場合にのみサポートされます。たとえば、OpenShift Virtualization 4.14 は OpenShift Container Platform 4.14 で実行する必要があります。
- クラスターのサポート容易性および機能が損なわれるリスクがあるので、Manual 承認ストラテジーを選択することは可能ですが、推奨していません。Manual 承認ストラテジーでは、保留中のすべての更新を手動で承認する必要があります。OpenShift Container Platform および OpenShift Virtualization の更新の同期が取れていない場合には、クラスターはサポートされなくなります。
- 更新の完了までにかかる時間は、ネットワーク接続によって異なります。ほとんどの自動更新は 15 分以内に完了します。
- OpenShift Virtualization を更新しても、ネットワーク接続が中断されることはありません。
- データボリュームおよびその関連付けられた永続ボリューム要求は更新時に保持されます。
ホストパスプロビジョナーストレージを使用する仮想マシンを実行している場合、それらをライブマイグレーションすることはできず、OpenShift Container Platform クラスターの更新をブロックする可能性があります。
回避策として、仮想マシンを再設定し、クラスターの更新時にそれらの電源を自動的にオフになるようにできます。evictionStrategy: LiveMigrate
フィールドを削除し、runStrategy
フィールドを Always
に設定します。
6.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 回の試行のみがバッファーに保持されます。これにより、デバッグ用の情報を保持しながら、移行オブジェクトがシステムに蓄積されるのを防ぎます。
6.1.2.2. コントロールプレーンのみの更新について
4.10 および 4.12 を含む OpenShift Container Platform の偶数番号のマイナーバージョンはすべて、Extended Update Support (EUS) バージョンです。ただし、Kubernetes の設計ではシリアルマイナーバージョンの更新が義務付けられているため、ある EUS バージョンから次の EUS バージョンに直接更新することはできません。
ソース EUS バージョンから次の奇数番号のマイナーバージョンに更新した後、更新パス上にあるそのマイナーバージョンのすべての z-stream リリースに OpenShift Virtualization を順次更新する必要があります。適用可能な最新の z-stream バージョンにアップグレードしたら、OpenShift Container Platform をターゲットの EUS マイナーバージョンに更新できます。
OpenShift Container Platform の更新が成功すると、対応する OpenShift Virtualization の更新が利用可能になります。OpenShift Virtualization をターゲットの EUS バージョンに更新できるようになりました。
6.1.2.2.1. 更新の準備中
コントロールプレーンのみの更新を開始する前に、以下を行う必要があります。
- コントロールプレーンのみの更新を開始する前に、ワーカーノードのマシン設定プールを一時停止して、ワーカーが 2 回再起動しないようにします。
- 更新プロセスを開始する前に、ワークロードの自動更新を無効にします。これは、ターゲットの EUS バージョンに更新するまで、OpenShift Virtualization が仮想マシン (VM) を移行または削除しないようにするためです。
デフォルトでは、OpenShift Virtualization Operator を更新すると、OpenShift Virtualization は virt-launcher
Pod などのワークロードを自動的に更新します。この動作は、HyperConverged
カスタムリソースの spec.workloadUpdateStrategy
スタンザで設定できます。
詳細は、コントロールプレーンのみの更新を実行する を参照してください。
6.1.3. コントロールプレーンのみの更新中にワークロードの更新を防止する
ある Extended Update Support (EUS) バージョンから次のバージョンに更新する場合、自動ワークロード更新を手動で無効にして、更新プロセス中に OpenShift Virtualization がワークロードを移行または削除しないようにする必要があります。
前提条件
- OpenShift Container Platform の EUS バージョンを実行中で、次の EUS バージョンに更新する予定である。中間の奇数番号のバージョンにはまだ更新していない。
- 「コントロールプレーンのみの更新を実行するための準備」を読み、OpenShift Container Platform クラスターに関連する注意事項と要件を確認した。
- 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":[]}]'
出力例
hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patched
続行する前に、
HyperConverged
Operator がアップグレード可能
であることを確認してください。次のコマンドを入力して、出力をモニターします。$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"
例6.1 出力例
[ { "lastTransitionTime": "2022-12-09T16:29:11Z", "message": "Reconcile completed successfully", "observedGeneration": 3, "reason": "ReconcileCompleted", "status": "True", "type": "ReconcileComplete" }, { "lastTransitionTime": "2022-12-09T20:30:10Z", "message": "Reconcile completed successfully", "observedGeneration": 3, "reason": "ReconcileCompleted", "status": "True", "type": "Available" }, { "lastTransitionTime": "2022-12-09T20:30:10Z", "message": "Reconcile completed successfully", "observedGeneration": 3, "reason": "ReconcileCompleted", "status": "False", "type": "Progressing" }, { "lastTransitionTime": "2022-12-09T16:39:11Z", "message": "Reconcile completed successfully", "observedGeneration": 3, "reason": "ReconcileCompleted", "status": "False", "type": "Degraded" }, { "lastTransitionTime": "2022-12-09T20:30:10Z", "message": "Reconcile completed successfully", "observedGeneration": 3, "reason": "ReconcileCompleted", "status": "True", "type": "Upgradeable" 1 } ]
- 1
- OpenShift Virtualization Operator のステータスは
Upgradeable
です。
クラスターをソース 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-cnv
- OpenShift Virtualization を非 EUS マイナーバージョンで使用可能なすべての z-stream バージョンに更新し、前の手順で示したコマンドを実行して各更新を監視します。
以下のコマンドを実行して、OpenShift Virtualization が非 EUS バージョンの最新の z-stream リリースに正常に更新されたことを確認します。
$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.versions"
出力例
[ { "name": "operator", "version": "4.14.9" } ]
次の更新を実行する前に、
HyperConverged
Operator がUpgradeable
ステータスになるまで待ちます。次のコマンドを入力して、出力をモニターします。$ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"
- OpenShift Container Platform をターゲットの EUS バージョンに更新します。
クラスターのバージョンを確認して、更新が成功したことを確認します。
$ oc get clusterversion
OpenShift Virtualization をターゲットの EUS バージョンに更新します。
- デフォルトの 自動 承認ストラテジーでは、OpenShift Container Platform を更新した後、OpenShift Virtualization は対応するバージョンに自動的に更新します。
- 手動 承認ストラテジーを使用する場合は、Web コンソールを使用して保留中の更新を承認します。
次のコマンドを実行して、OpenShift Virtualization の更新をモニターします。
$ oc get csv -n openshift-cnv
VERSION
フィールドがターゲットの EUS バージョンと一致し、PHASE
フィールドがSucceeded
になると、更新が完了します。次のコマンドを使用して、ステップ 1 で記録した
workloadUpdateMethods
設定を復元します。$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv --type json -p \ "[{\"op\":\"add\",\"path\":\"/spec/workloadUpdateStrategy/workloadUpdateMethods\", \"value\":{WorkloadUpdateMethodConfig}}]"
出力例
hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patched
検証
次のコマンドを実行して、VM 移行のステータスを確認します。
$ oc get vmim -A
次のステップ
- ワーカーノードのマシン設定プールの一時停止を解除できるようになりました。
6.1.4. ワークロードの更新方法の設定
HyperConverged
カスタムリソース (CR) を編集することにより、ワークロードの更新方法を設定できます。
前提条件
ライブマイグレーションを更新方法として使用するには、まずクラスターでライブマイグレーションを有効にする必要があります。
注記VirtualMachineInstance
CR にevictionStrategy: LiveMigrate
が含まれており、仮想マシンインスタンス (VMI) がライブマイグレーションをサポートしない場合には、VMI は更新されません。
手順
デフォルトエディターで
HyperConverged
CR を作成するには、以下のコマンドを実行します。$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
HyperConverged
CR の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
メソッドには適用されません。
注記HyperConverged
CR のspec.liveMigrationConfig
スタンザを編集することにより、ライブマイグレーションの制限とタイムアウトを設定できます。- 変更を適用するには、エディターを保存し、終了します。
6.1.5. 保留中の Operator 更新の承認
6.1.5.1. 保留中の 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.6. 更新ステータスの監視
6.1.6.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
6.1.6.2. 以前の OpenShift Virtualization ワークロードの表示
CLI を使用して、以前のワークロードのリストを表示できます。
クラスターに以前の仮想化 Pod がある場合には、OutdatedVirtualMachineInstanceWorkloads
アラートが実行されます。
手順
以前の仮想マシンインスタンス (VMI) の一覧を表示するには、以下のコマンドを実行します。
$ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces
ワークロードの更新を設定して、VMI が自動的に更新されるようにします。