第6章 更新


6.1. OpenShift Virtualization の更新

OpenShift Virtualization を最新の状態に保ち、OpenShift Container Platform との互換性を維持する方法を説明します。

6.1.1. OpenShift Virtualization の更新について

OpenShift Virtualization をインストールするときに、更新チャネルと承認ストラテジーを選択します。アップデートチャネルによって、使用する OpenShift Virtualization のバージョンが決まります。承認ストラテジーは、更新が自動的に行われるか、手動による承認が必要となるかを決定します。どちらの設定もサポート性に影響します。

6.1.1.2. 予想されること

OpenShift Virtualization では、更新期間、自動化、データ保持など、一貫した更新動作が期待できます。

  • アップデートの完了にかかる時間は、ネットワーク接続状況によって異なります。ほとんどの自動更新は 15 分以内に完了します。
  • OpenShift Virtualization を更新しても、ネットワーク接続が中断されることはありません。
  • アップデートによって、データボリュームおよびそれに関連付けられた永続ボリューム要求は保持されます。
重要

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

回避策として、仮想マシンを再設定して、クラスターの更新中に自動的に電源がオフになるようにしてください。evictionStrategy フィールドを None に、runStrategy フィールドを Always に設定します。

6.1.1.3. 更新の仕組み

Operator Lifecycle Manager (OLM) が OpenShift Virtualization Operator をどのように更新するか、また更新チャネルと承認ストラテジーがアップグレード動作にどのように影響するかを学びましょう。

  • Operator Lifecycle Manager(OLM) は OpenShift Virtualization Operator のライフサイクルを管理します。OpenShift Container Platform のインストール時にデプロイされるマーケットプレイス 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 コンソールにログインしました。

手順

  1. Ecosystem Installed Operators をクリックします。
  2. リストから OpenShift Virtualization を選択します。
  3. Subscription タブをクリックします。
  4. Subscription details セクションで、変更する設定をクリックします。たとえば、承認ストラテジーを Manual から Automatic に変更するには、Manual をクリックします。
  5. 開いたウィンドウで、新しい更新チャネルまたは承認ストラテジーを選択します。
  6. Save をクリックします。

6.1.1.5. 手動承認ストラテジー

手動 承認ストラテジーを使用する場合は、保留中のすべての更新を承認する必要があります。OpenShift Container Platform および OpenShift Virtualization の更新の同期が取れていない場合には、クラスターはサポートされなくなります。

クラスターのサポート性および機能性へのリスクを回避するため、自動 承認ストラテジーを使用してください。手動 承認ストラテジーを使用する必要がある場合は、保留中の Operator アップデートが利用可能になり次第、速やかに承認してください。

6.1.1.6. 保留中の Operator 更新の手動による承認

インストールされた Operator のサブスクリプションの承認ストラテジーが Manual に設定されている場合、新規の更新が現在の更新チャネルにリリースされると、インストールを開始する前に更新を手動で承認する必要があります。

前提条件

  • Operator Lifecycle Manager (OLM) を使用して以前にインストールされている Operator。

手順

  1. OpenShift Container Platform Web コンソールで、Ecosystem Installed Operators に移動します。
  2. 更新が保留中の Operators は Upgrade available のステータスを表示します。更新する Operator の名前をクリックします。
  3. Subscription タブをクリックします。承認が必要な更新は、Upgrade status の横に表示されます。たとえば、1 requires approval が表示される可能性があります。
  4. 1 requires approval をクリックしてから、Preview Install Plan をクリックします。
  5. 更新に利用可能なリソースとして一覧表示されているリソースを確認します。問題がなければ、Approve をクリックします。
  6. Ecosystem Installed Operators ページに戻って、更新の進行状況を監視します。完了時に、ステータスは Succeeded および Up to date に変更されます。

6.1.2. RHEL 9 の互換性

OpenShift Virtualization 4.20 は、Red Hat Enterprise Linux (RHEL) 9 をベースにしています。標準の OpenShift Virtualization 更新手順に従って、RHEL 8 をベースとするバージョンから OpenShift Virtualization 4.20 に更新できます。追加の手順は必要ありません。

以前のバージョンと同様に、実行中のワークロードを中断することなく更新を実行できます。OpenShift Virtualization 4.20 では、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) がインストールされている。

手順

  1. 以下のコマンドを実行します。

    $ oc get csv -n openshift-cnv
  2. 出力を確認し、PHASE フィールドをチェックします。以下に例を示します。

    VERSION  REPLACES                                        PHASE
    4.9.0    kubevirt-hyperconverged-operator.v4.8.2         Installing
    4.9.0    kubevirt-hyperconverged-operator.v4.9.0         Replacing
  3. オプション: 以下のコマンドを実行して、すべての 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 を更新すると、ライブマイグレーションをサポートしている場合には libvirtvirt-launcher、および qemu などの仮想マシンのワークロードが自動的に更新されます。

注記

各仮想マシンには、仮想マシンインスタンス (VMI) を実行する virt-launcher Pod があります。virt-launcher Pod は、仮想マシン (VM) のプロセスを管理するために使用される libvirt のインスタンスを実行します。

HyperConverged カスタムリソース (CR) の spec.workloadUpdateStrategy スタンザを編集して、ワークロードの更新方法を設定できます。ワークロードの更新方法として、LiveMigrateEvict の 2 つが利用可能です。

Evict メソッドは VMI Pod をシャットダウンするため、デフォルトでは LiveMigrate 更新ストラテジーのみが有効になっています。

LiveMigrate が有効な唯一の更新ストラテジーである場合:

  • ライブマイグレーションをサポートする VMI は更新プロセス時に移行されます。VM ゲストは、更新されたコンポーネントが有効になっている新しい Pod に移動します。
  • ライブマイグレーションをサポートしない VMI は中断または更新されません。

    • VMI に LiveMigrate 退避ストラテジーがあるが、ライブマイグレーションをサポートしていない場合、VMI は更新されません。

LiveMigrateEvict の両方を有効にした場合:

  • ライブマイグレーションをサポートする VMI は、LiveMigrate 更新ストラテジーを使用します。
  • ライブマイグレーションをサポートしない VMI は、Evict 更新ストラテジーを使用します。VMI が runStrategy: Always に設定された VirtualMachine オブジェクトによって制御される場合、新規の VMI は、更新されたコンポーネントを使用して新規 Pod に作成されます。

6.1.4.1. 移行の試行とタイムアウト

ワークロードを更新するときに、Pod が次の期間 Pending 状態の場合、ライブマイグレーションは失敗します。

5 分間
Pod が Unschedulable であるために保留中の場合。
15 分
何らかの理由で Pod が保留状態のままになっている場合。

VMI が移行に失敗すると、virt-controller は VMI の移行を再試行します。すべての移行可能な VMI が新しい virt-launcher Pod で実行されるまで、このプロセスが繰り返されます。ただし、VMI が不適切に設定されている場合、これらの試行は無限に繰り返される可能性があります。

注記

各試行は、移行オブジェクトに対応します。直近の 5 回の試行のみがバッファーに保持されます。これにより、デバッグ用の情報を保持しながら、移行オブジェクトがシステムに蓄積されるのを防ぎます。

6.1.4.2. ワークロードの更新方法の設定

ハイパーコンバージド カスタムリソース (CR) を編集することで、クラスターのアップグレード中に仮想マシンのワークロードがどのように更新されるかを設定できます。

前提条件

  • クラスターでライブマイグレーションを有効にしました。

    注記

    VirtualMachineInstance CR に evictionStrategy: LiveMigrate が含まれており、仮想マシンインスタンス (VMI) がライブマイグレーションをサポートしない場合には、VMI は更新されません。

  • OpenShift CLI (oc) がインストールされている。

手順

  1. デフォルトエディターで HyperConverged CR を作成するには、以下のコマンドを実行します。

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. HyperConverged CR の 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 は、アップグレード中に VMIPod をシャットダウンする、破壊的な方法です。Evict は、ライブマイグレーションがクラスターで有効でない場合に利用可能な唯一の更新方法です。VMI が runStrategy: Always に設定された VirtualMachine オブジェクトによって制御される場合には、新規の VMI は、更新されたコンポーネントを使用して新規 Pod に作成されます。
    • spec.workloadUpdateStrategy.batchEvictionSize はEvict メソッドを使用して一度に強制的に更新できる VMI の数を定義します。これは、LiveMigrate メソッドには適用されません。
    • spec.workloadUpdateStrategy.batchEvictionInterval は、次のワークロードのバッチを削除する前に待機する間隔を定義します。これは、LiveMigrate メソッドには適用されません。

      注記

      HyperConverged CR の spec.liveMigrationConfig スタンザを編集することにより、ライブマイグレーションの制限とタイムアウトを設定できます。

  3. 変更を適用するには、エディターを保存し、終了します。

6.1.4.3. 古くなった仮想マシンワークロードの表示

CLI を使用して、古くなった仮想マシン (VM) ワークロードのリストを表示できます。

注記

クラスターに以前の仮想化 Pod がある場合には、OutdatedVirtualMachineInstanceWorkloads アラートが実行されます。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  • 以前の仮想マシンインスタンス (VMI) の一覧を表示するには、以下のコマンドを実行します。

    $ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces

6.1.5. コントロールプレーンのみの更新

コントロールプレーンのみのアップデートを使用すると、OpenShift Container Platform の Extended Update Support (EUS) バージョン間を移行できます。これにより、中間アップグレード中に仮想マシンのワークロードが更新されるのを防ぎます。

OpenShift Container Platform の偶数番号のマイナーバージョンは、すべて Extended Update Support (EUS) バージョンです。Kubernetes では、マイナーバージョンのアップデートは順番に行われる必要がある。EUS のバージョン間で直接アップデートすることはできません。

EUS のバージョン間を移行するには、まず OpenShift Virtualization を次の奇数マイナーバージョンの最新の z-stream リリースにアップデートしてください。次に、クラスターを OpenShift Container Platform のターゲット EUS バージョンにアップデートします。クラスターの更新後、OpenShift Virtualization を対象の EUS バージョンに更新してください。

注記

OpenShift Virtualization は、中間的な z-stream アップデートを適用することなく、現在のマイナーバージョンの最新の z-stream リリースに直接アップデートできます。

EUS のバージョンに関する詳細は、OpenShift Container Platform ライフサイクルポリシー を参照してください。

6.1.5.1. コントロールプレーンのみの更新中にワークロードの更新を防止する

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 バージョンについては、RHCOS および OpenShift Container Platform で使用される RHEL バージョンを 参照してください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • あなたは現在、OpenShift Container Platform の EUS バージョンを使用しており、次の EUS バージョンにアップデートする予定です。
  • まだ中間マイナーバージョン (奇数番号) にアップデートしていません。
  • OpenShift Container Platform のドキュメントに記載されている手順に従って、ワーカーノードのマシン設定プールを一時停止しました。
  • デフォルトの 自動 承認ストラテジーを使用します。Manual 承認ストラテジーを使用する場合は、Web コンソールで保留中のすべての更新を承認する必要があります。詳細は、保留中の Operator アップデートを手動で承認するを参照してください。

手順

  1. 以下のコマンドを実行し、workloadUpdateMethods の 値を記録してください。

    $ oc get kv kubevirt-kubevirt-hyperconverged \
      -n openshift-cnv -o jsonpath='{.spec.workloadUpdateStrategy.workloadUpdateMethods}'
  2. ワークロード更新方法を無効にするには、次のコマンドを実行します。

    $ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \
      --type json -p '[{"op":"replace","path":"/spec/workloadUpdateStrategy/workloadUpdateMethods", "value":[]}]'
  3. ハイパーコンバージド Operator が アップグレード可能で あることを確認してください。

    $ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"
  4. クラスターをソースの EUS バージョンから OpenShift Container Platform の次のマイナーバージョンにアップデートします。

    $ oc adm upgrade
  5. 現在のクラスターバージョンを確認します。

    $ oc get clusterversion
    注記

    OpenShift Container Platform を次のバージョンに更新することは、OpenShift Virtualization を更新するための前提条件です。詳細は、OpenShift Container Platform のドキュメントのクラスターの更新セクションを参照してください。

  6. OpenShift Virtualization を更新します。

    • デフォルトの 自動 承認ストラテジーでは、OpenShift Container Platform のアップデートが完了すると、OpenShift Virtualization も自動的にアップデートされます。
    • 手動 承認ストラテジーを使用する場合は、Web コンソールで保留中の更新を承認してください。
  7. OpenShift 仮想化のアップデートを監視してください。

    $ oc get csv -n openshift-cnv
  8. OpenShift Virtualization が最新の z-stream 中間バージョンにアップデートされていることを確認してください。

    $ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.versions"
  9. ハイパーコンバージド Operator が再び アップグレード可能 状態を報告するまでお待ちください。
  10. OpenShift Container Platform をターゲットの EUS バージョンに更新します。
  11. クラスターのバージョンを確認します。

    $ oc get clusterversion
  12. OpenShift Virtualization をターゲットの EUS バージョンに更新します。

    • デフォルトの 自動 承認ストラテジーでは、OpenShift Virtualization は自動的に更新されます。
    • 手動 承認ストラテジーを使用する場合は、Web コンソールで保留中の更新を承認してください。
  13. アップデートを監視してください:

    $ oc get csv -n openshift-cnv

    VERSION フィールドがターゲットの EUS バージョンと一致し、PHASE フィールドが Succeeded になると、更新が完了します。

  14. ステップ 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 のバージョンに対応する 候補 アップデートチャネルに登録することで、開発ビルドにアクセスできます。

これらのリリースは Red Hat による完全なテストを受けておらず、サポート対象外です。新機能のテストやバグ修正を行う目的でのみ、非本番環境のクラスターで使用してください。

安定版 チャネルは、基盤となる OpenShift Container Platform のバージョンと一致しており、完全にテスト済みです。生産システムに適しています。OperatorHub では、安定版 チャネルと 候補版 チャネルを切り替えることができます。候補 リリースから 安定版 リリースへのアップデートは、Red Hat ではテストされていません。

Red Hat は、一部の候補リリースを 安定版 チャネルに昇格させています。他の候補リリースには、GA 版のすべての機能が含まれていない可能性があります。Red Hat は、一般提供開始前に候補ビルドから一部の機能を削除する可能性があります。候補版リリースでは、後続の一般提供版リリースへのアップデートパスが提供されない場合があります。

重要

候補チャネルは、クラスターを削除して再作成できるテスト目的でのみ使用してください。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る