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 コンソールの OperatorHub から、または 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 がドレインされます。

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

仮想マシンエビクションストラテジー

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

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

重要

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

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

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

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

重要

デフォルトのエビクションストラテジーは LiveMigrate です。移行不可能な仮想マシンが LiveMigrate エビクションストラテジーを使用していると、ノードのドレインが妨げられたり、インフラストラクチャーのアップグレードがブロックされたりする可能性があります。これは、その仮想マシンがノードからエビクトされないためです。この状況では、仮想マシンを手動でシャットダウンしない限り、移行は 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.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.1 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