Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第12章 Nodes

12.1. ノードのメンテナンス
リンクのコピー

oc adm ユーティリティーまたは NodeMaintenance カスタムリソース (CR) を使用してノードをメンテナンスモードにすることができます。

注記

node-maintenance-operator (NMO) は OpenShift Virtualization に同梱されなくなりました。これは、Red Hat OpenShift Service on AWS Web コンソールのソフトウェアカタログから、または OpenShift CLI (oc) を使用してスタンドアロン Operator としてデプロイされます。

ノードの修復、フェンシング、メンテナンスの詳細は、Red Hat OpenShift のワークロードの可用性 を参照してください。

重要

仮想マシンでは、共有 ReadWriteMany (RWX) アクセスモードを持つ永続ボリューム要求 (PVC) のライブマイグレーションが必要です。

Node Maintenance Operator は、新規または削除された NodeMaintenance CR をモニタリングします。新規の NodeMaintenance CR が検出されると、新規ワークロードはスケジュールされず、ノードは残りのクラスターから遮断されます。退避できるすべての Pod はノードから退避されます。NodeMaintenance CR が削除されると、CR で参照されるノードは新規ワークロードで利用可能になります。

注記

ノードメンテナンスタスクに NodeMaintenance CR を使用すると、標準の Red Hat OpenShift Service on AWS カスタムリソース処理を使用した oc adm cordon および oc adm drain コマンドと同じ結果が得られます。

12.1.1. エビクションストラテジー
リンクのコピー

ノードがメンテナンス状態になると、ノードにはスケジュール対象外のマークが付けられ、ノードからすべての仮想マシンおよび Pod の drain (Pod の退避) が実行されます。

仮想マシン (VM) またはクラスターの退避ストラテジーを設定できます。

仮想マシン退避ストラテジー

仮想マシンの LiveMigrate 退避ストラテジーは、ノードがメンテナンス状態になるか、drain (Pod の退避) が実行される場合に仮想マシンインスタンスが中断されないようにします。この退避ストラテジーを持つ VMI は、別のノードにライブマイグレーションされます。

Red Hat OpenShift Service on AWS Web コンソールまたは コマンドライン を使用して、仮想マシン (VM) のエビクションストラテジーを設定できます。

重要

デフォルトの退避ストラテジーは LiveMigrate です。移行不可能な仮想マシンが LiveMigrate 退避ストラテジーを使用していると、ノードの drain が妨げられたり、インフラストラクチャーのアップグレードがブロックされたりする可能性があります。これは、その仮想マシンがノードから退避されないためです。この状況では、仮想マシンを手動でシャットダウンしない限り、移行は Pending または Scheduling 中の状態のままになります。

移行不可能な仮想マシンの退避ストラテジーを、アップグレードをブロックしない LiveMigrateIfPossible に設定する必要があります。移行すべきでない仮想マシンの場合は、None に設定する必要があります。

クラスター退避ストラテジー
ワークロードの継続性またはインフラストラクチャーのアップグレードを優先するために、クラスターの退避ストラテジーを設定できます。
Expand
表12.1 クラスター退避ストラテジー
退避ストラテジー説明ワークフローを中断するアップグレードをブロックする

LiveMigrate 1

アップグレードよりもワークロードの継続性を優先します。

いいえ

はい 2

LiveMigrateIfPossible

ワークロードの継続性よりもアップグレードを優先して、環境が確実に更新されるようにします。

はい

いいえ

None 3

退避ストラテジーを使用せずに仮想マシンをシャットダウンします。

はい

いいえ

  1. マルチノードクラスターのデフォルトの退避ストラテジー。
  2. 仮想マシンがアップグレードをブロックする場合は、仮想マシンを手動でシャットダウンする必要があります。
  3. シングルノード OpenShift のデフォルトの退避ストラテジー。

12.1.1.1. CLI を使用した仮想マシンの退避ストラテジーの設定
リンクのコピー

コマンドラインを使用して、仮想マシン (VM) の退避ストラテジーを設定できます。

重要

デフォルトの退避ストラテジーは LiveMigrate です。移行不可能な仮想マシンが LiveMigrate 退避ストラテジーを使用していると、ノードの drain が妨げられたり、インフラストラクチャーのアップグレードがブロックされたりする可能性があります。これは、その仮想マシンがノードから退避されないためです。この状況では、仮想マシンを手動でシャットダウンしない限り、移行は Pending または Scheduling 中の状態のままになります。

移行不可能な仮想マシンの退避ストラテジーを、アップグレードをブロックしない LiveMigrateIfPossible に設定する必要があります。移行すべきでない仮想マシンの場合は、None に設定する必要があります。

前提条件

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

手順

  1. 次のコマンドを実行して、VirtualMachine リソースを編集します。 

    $ oc edit vm <vm_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    退避ストラテジーの例

    apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: <vm_name>
spec:
  template:
    spec:
      evictionStrategy: LiveMigrateIfPossible
    1 
    
# ...
    Copy to Clipboard Toggle word wrap

    1
    退避ストラテジーを指定します。デフォルト値は LiveMigrate です。

  2. 仮想マシンを再起動して変更を適用します。 

    $ virtctl restart <vm_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

12.1.1.2. CLI を使用したクラスターの退避ストラテジーの設定
リンクのコピー

コマンドラインを使用して、クラスターの退避ストラテジーを設定できます。

前提条件

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

手順

  1. 次のコマンドを実行して、hyperconverged リソースを編集します。 

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
    Copy to Clipboard Toggle word wrap

  2. 次の例に示すように、クラスターの退避ストラテジーを設定します。

    クラスターの退避ストラテジーの例

    apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
spec:
  evictionStrategy: LiveMigrate
# ...
    Copy to Clipboard Toggle word wrap

12.1.2. 実行ストラテジー
リンクのコピー

spec.runStrategy キーは、特定の条件下での仮想マシンの動作を決定します。

12.1.2.1. 実行ストラテジー
リンクのコピー

spec.runStrategy キーには 4 つの値があります。

Always
仮想マシンインスタンス (VMI) は、仮想マシンが別のノードに作成されるときに常に存在します。元の VMI が何らかの理由で停止した場合、新しい VMI が作成されます。
RerunOnFailure
以前のインスタンスに障害が発生した場合、VMI は別のノードで再作成されます。仮想マシンがシャットダウンされた場合など、仮想マシンが正常に停止した場合、インスタンスは再作成されません。
Manual
VMI 状態は、virtctl クライアントコマンドの start、stop、および restart を使用して手動で制御します。仮想マシンは自動的には再起動されません。
Halted
仮想マシンの作成時には VMI は存在しません。

virtctl start、stop、および restart コマンドのさまざまな組み合わせが、実行ストラテジーに影響します。

次の表では、仮想マシンの状態間の遷移を説明します。最初の列には、仮想マシンの初期実行ストラテジーを示します。残りの列には、virtctl コマンドと、そのコマンドを実行した後の新しい実行ストラテジーを示します。

Expand
表12.2 virtctl コマンド前後の実行ストラテジー
初期実行ストラテジーStartStopRestart

Always

-

Halted

Always

RerunOnFailure

RerunOnFailure

RerunOnFailure

RerunOnFailure

Manual

Manual

Manual

Manual

Halted

Always

-

-

注記

インストーラーによってプロビジョニングされたインフラストラクチャーを使用してインストールされたクラスター内のノードがマシンの健全性チェックに失敗して使用できない場合は、runStrategy: Always または runStrategy: RerunOnFailure を持つ仮想マシンが新しいノードで再スケジュールされます。

12.1.2.2. CLI を使用した仮想マシン実行ストラテジーの設定
リンクのコピー

コマンドラインを使用して、仮想マシン (VM) の実行ストラテジーを設定できます。

前提条件

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

手順

  • 次のコマンドを実行して、VirtualMachine リソースを編集します。 

    $ oc edit vm <vm_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    実行ストラテジーの例

    apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  runStrategy: Always
# ...
    Copy to Clipboard Toggle word wrap

12.1.3. ベアメタルノードのメンテナンス
リンクのコピー

Red Hat OpenShift Service on AWS をベアメタルインフラストラクチャーにデプロイする場合は、クラウドインフラストラクチャーにデプロイする場合と比べて、考慮すべき追加の事項があります。クラスターノードが一時的とみなされるクラウド環境とは異なり、ベアメタルノードを再プロビジョニングするには、メンテナンスタスクにより多くの時間と作業が必要になります。

致命的なカーネルエラーが発生したり、NIC カードのハードウェア障害が発生する場合などにベアメタルノードに障害が発生した場合には、障害のあるノードが修復または置き換えられている間に、障害が発生したノード上のワークロードをクラスターの別の場所で再起動する必要があります。ノードのメンテナンスモードにより、クラスター管理者はノードの電源をグレースフルに停止し、ワークロードをクラスターの他の部分に移動させ、ワークロードが中断されないようにします。詳細な進捗とノードのステータスの詳細は、メンテナンス時に提供されます。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat