第5章 更新
5.1. OpenShift Virtualization の更新
OpenShift Virtualization を最新の状態に保ち、Red Hat OpenShift Service on AWS との互換性を維持する方法について説明します。
5.1.1. OpenShift Virtualization の更新について
OpenShift Virtualization をインストールするときに、更新チャネルと承認ストラテジーを選択します。更新チャネルによって、OpenShift Virtualization が更新されるバージョンが決まります。承認ストラテジー設定により、更新が自動的に行われるか、手動の承認が必要かどうかが決まります。どちらの設定もサポート性に影響を与える可能性があります。
5.1.1.1. 推奨設定
サポート可能な環境を維持するには、次の設定を使用します。
- 更新チャネル: stable
- 承認ストラテジー: Automatic
これらの設定により、Operator の新しいバージョンが stable チャネルで利用可能になると、更新プロセスが自動的に開始されます。これにより、OpenShift Virtualization と Red Hat OpenShift Service on AWS のバージョンの互換性が確保され、OpenShift Virtualization のバージョンが実稼働環境に適したものになります。
OpenShift Virtualization の各マイナーバージョンは、対応する Red Hat OpenShift Service on AWS バージョンを実行している場合にのみサポートされます。たとえば、Red Hat OpenShift Service on AWS 4.18 で OpenShift Virtualization 4.18 を実行する必要があります。
5.1.1.2. 予想されること
- 更新の完了までにかかる時間は、ネットワーク接続によって異なります。ほとんどの自動更新は 15 分以内に完了します。
- OpenShift Virtualization を更新しても、ネットワーク接続が中断されることはありません。
- データボリュームとそれに関連付けられた永続ボリューム要求は、更新中に保持されます。
AWS Elastic Block Store (EBS) ストレージを使用する仮想マシンを実行している場合、ライブマイグレーションができないため、Red Hat OpenShift Service on AWS クラスター更新がブロックされる可能性があります。
回避策として、仮想マシンを再設定し、クラスターの更新時にそれらの電源を自動的にオフになるようにできます。evictionStrategy
フィールドを None
に、runStrategy
フィールドを Always
に設定します。
5.1.1.3. 更新の仕組み
- 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 を次のマイナーバージョンに更新できません。
5.1.1.4. RHEL 9 の互換性
OpenShift Virtualization 4.18 は、Red Hat Enterprise Linux (RHEL) 9 をベースにしています。標準の OpenShift Virtualization 更新手順に従って、RHEL 8 をベースとするバージョンから OpenShift Virtualization 4.18 に更新できます。追加の手順は必要ありません。
以前のバージョンと同様に、実行中のワークロードを中断することなく更新を実行できます。OpenShift Virtualization 4.18 では、RHEL 8 ノードから RHEL 9 ノードへのライブマイグレーションがサポートされています。
5.1.1.4.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 の更新のステータスをモニターするには、クラスターサービスバージョン (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.3. 仮想マシンワークロードの更新
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.1. ワークロードの更新方法の設定
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
スタンザを編集することにより、ライブマイグレーションの制限とタイムアウトを設定できます。- 変更を適用するには、エディターを保存し、終了します。
5.1.3.2. 古くなった仮想マシンワークロードの表示
CLI を使用して、古くなった仮想マシン (VM) ワークロードのリストを表示できます。
クラスターに以前の仮想化 Pod がある場合には、OutdatedVirtualMachineInstanceWorkloads
アラートが実行されます。
手順
以前の仮想マシンインスタンス (VMI) の一覧を表示するには、以下のコマンドを実行します。
$ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces
VMI が自動的に更新されるようにするには、ワークロードの更新を設定します。
5.1.4. 高度なオプション
ほとんどの OpenShift Virtualization インストールでは、stable リリースチャネルと Automatic 承認ストラテジーが推奨されます。リスクを理解している場合にのみ、他の設定を使用してください。
5.1.4.1. 更新設定の変更
Web コンソールを使用して、OpenShift Virtualization Operator サブスクリプションの更新チャネルと承認ストラテジーを変更できます。
前提条件
- OpenShift Virtualization Operator がインストールされている。
- 管理者権限がある。
手順
-
Operators
Installed Operators をクリックします。 - リストから OpenShift Virtualization を選択します。
- Subscription タブをクリックします。
- Subscription details セクションで、変更する設定をクリックします。たとえば、承認ストラテジーを Manual から Automatic に変更するには、Manual をクリックします。
- 開いたウィンドウで、新しい更新チャネルまたは承認ストラテジーを選択します。
- Save をクリックします。
5.1.4.2. 手動承認ストラテジー
Manual 承認ストラテジーを使用する場合は、すべての保留中の更新を手動で承認する必要があります。Red Hat OpenShift Service on AWS と OpenShift Virtualization の更新が同期していない場合、クラスターはサポートされなくなります。クラスターのサポート性と機能性を危険にさらさないようにするには、Automatic 承認ストラテジーを使用します。
Manual 承認ストラテジーを使用する必要がある場合は、保留中の Operator 更新が利用可能になり次第承認し、サポート可能なクラスターを維持します。
5.1.4.3. 保留中の 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 に変更されます。