検索

第6章 更新

download PDF

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 を更新すると、ライブマイグレーションをサポートしている場合には 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 に作成されます。
移行の試行とタイムアウト

ワークロードを更新するときに、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 の更新を手動で承認する」セクションを参照してください。

手順

  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":[]}]'

    出力例

    hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patched

  3. 続行する前に、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 です。
  4. クラスターをソース EUS バージョンから OpenShift Container Platform の次のマイナーバージョンに手動で更新します。

    $ oc adm upgrade

    検証

    • 次のコマンドを実行して、現在のバージョンを確認します。

      $ oc get clusterversion
      注記

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

  5. OpenShift Virtualization を更新します。

    • デフォルトの 自動 承認ストラテジーでは、OpenShift Container Platform を更新した後、OpenShift Virtualization は対応するバージョンに自動的に更新します。
    • 手動 承認ストラテジーを使用する場合は、Web コンソールを使用して保留中の更新を承認します。
  6. 次のコマンドを実行して、OpenShift Virtualization の更新をモニターします。

    $ oc get csv -n openshift-cnv
  7. OpenShift Virtualization を非 EUS マイナーバージョンで使用可能なすべての z-stream バージョンに更新し、前の手順で示したコマンドを実行して各更新を監視します。
  8. 以下のコマンドを実行して、OpenShift Virtualization が非 EUS バージョンの最新の z-stream リリースに正常に更新されたことを確認します。

    $ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.versions"

    出力例

    [
      {
        "name": "operator",
        "version": "4.14.9"
      }
    ]

  9. 次の更新を実行する前に、HyperConverged Operator が Upgradeable ステータスになるまで待ちます。次のコマンドを入力して、出力をモニターします。

    $ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o json | jq ".status.conditions"
  10. OpenShift Container Platform をターゲットの EUS バージョンに更新します。
  11. クラスターのバージョンを確認して、更新が成功したことを確認します。

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

    • デフォルトの 自動 承認ストラテジーでは、OpenShift Container Platform を更新した後、OpenShift Virtualization は対応するバージョンに自動的に更新します。
    • 手動 承認ストラテジーを使用する場合は、Web コンソールを使用して保留中の更新を承認します。
  13. 次のコマンドを実行して、OpenShift Virtualization の更新をモニターします。

    $ 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}}]"

    出力例

    hyperconverged.hco.kubevirt.io/kubevirt-hyperconverged patched

    検証

    • 次のコマンドを実行して、VM 移行のステータスを確認します。

      $ oc get vmim -A

次のステップ

  • ワーカーノードのマシン設定プールの一時停止を解除できるようになりました。

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

HyperConverged カスタムリソース (CR) を編集することにより、ワークロードの更新方法を設定できます。

前提条件

  • ライブマイグレーションを更新方法として使用するには、まずクラスターでライブマイグレーションを有効にする必要があります。

    注記

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

手順

  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: 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スタンザを編集することにより、ライブマイグレーションの制限とタイムアウトを設定できます。

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

6.1.5. 保留中の Operator 更新の承認

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

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

前提条件

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

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Operators Installed Operators に移動します。
  2. 更新が保留中の Operator は Upgrade available のステータスを表示します。更新する Operator の名前をクリックします。
  3. Subscription タブをクリックします。承認が必要な更新は、Upgrade status の横に表示されます。たとえば、1 requires approval が表示される可能性があります。
  4. 1 requires approval をクリックしてから、Preview Install Plan をクリックします。
  5. 更新に利用可能なリソースとして一覧表示されているリソースを確認します。問題がなければ、Approve をクリックします。
  6. 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) がインストールされている。

手順

  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.6.2. 以前の OpenShift Virtualization ワークロードの表示

CLI を使用して、以前のワークロードのリストを表示できます。

注記

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

手順

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

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

ワークロードの更新を設定して、VMI が自動的に更新されるようにします。

6.1.7. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

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

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

会社概要

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

© 2024 Red Hat, Inc.