第7章 OpenShift Virtualization の更新

Operator Lifecycle Manager(OLM) が OpenShift Virtualization の z-stream およびマイナーバージョンの更新を提供する方法を確認します。

注記

  • Node Maintenance Operator (NMO) は OpenShift Virtualization に同梱されなくなりました。NMO は、OpenShift Container Platform Web コンソールの OperatorHub から、または OpenShift CLI (oc) を使用して インストール できます。ノードの修復、フェンシング、メンテナンスについて、詳しくは Red Hat OpenShift のワークロードの可用性 を参照してください。

    OpenShift Virtualization 4.10.2 以降のリリースから OpenShift Virtualization 4.11 に更新する前に、以下のいずれかのタスクを実行する必要があります。

    • すべてのノードをメンテナンスモードから移動します。
    • スタンドアロン NMO をインストールし、nodemaintenances.nodemaintenance.kubevirt.io カスタムリソース (CR) を nodemaintenances.nodemaintenance.medik8s.io CR に置き換えます。

7.1. 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.12 は OpenShift Container Platform 4.12 で実行する必要があります。

    • クラスターのサポート容易性および機能が損なわれるリスクがあるので、Manual 承認ストラテジーを選択することは可能ですが、推奨していません。Manual 承認ストラテジーでは、保留中のすべての更新を手動で承認する必要があります。OpenShift Container Platform および OpenShift Virtualization の更新の同期が取れていない場合には、クラスターはサポートされなくなります。
  • 更新の完了までにかかる時間は、ネットワーク接続によって異なります。ほとんどの自動更新は 15 分以内に完了します。
  • Open Shift Virtualization を更新しても、ネットワーク接続が中断されることはありません。
  • データボリュームおよびその関連付けられた永続ボリューム要求 (PVC) は更新時に保持されます。
重要

ホストパスプロビジョナーストレージを使用する仮想マシンを実行している場合、それらをライブマイグレーションすることはできず、Open Shift Container Platform クラスターの更新をブロックする可能性があります。

回避策として、仮想マシンを再設定し、クラスターの更新時にそれらの電源を自動的にオフになるようにできます。evictionStrategy: LiveMigrate フィールドを削除し、runStrategy フィールドを Always に設定します。

7.1.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 は更新されません。

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 回の試行のみがバッファーに保持されます。これにより、デバッグ用の情報を保持しながら、移行オブジェクトがシステムに蓄積されるのを防ぎます。

7.1.2. EUS から EUS への更新について

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 バージョンに更新できるようになりました。

7.1.2.1. 更新の準備中

EUS から EUS への更新を開始する前に、次のことを行う必要があります。

  • EUS から EUS への更新を開始する前に、ワーカーノードのマシン設定プールを一時停止して、ワーカーが 2 回再起動されないようにします。
  • 更新プロセスを開始する前に、ワークロードの自動更新を無効にします。これは、ターゲットの EUS バージョンに更新するまで、OpenShift Virtualization が仮想マシン (VM) を移行または削除しないようにするためです。
注記

デフォルトでは、OpenShift Virtualization Operator を更新すると、OpenShift Virtualization は virt-launcher Pod などのワークロードを自動的に更新します。この動作は、HyperConverged カスタムリソースの spec.workloadUpdateStrategy スタンザで設定できます。

EUS から EUS への更新を実行する準備 の詳細については、こちらを参照してください。