第11章 ノード
11.1. ノードのメンテナンス
oc adm ユーティリティーまたは NodeMaintenance カスタムリソース (CR) を使用してノードをメンテナンスモードにすることができます。
node-maintenance-operator (NMO) は OpenShift Virtualization に同梱されなくなりました。これは、OpenShift Container Platform 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 を使用すると、標準の OpenShift Container Platform カスタムリソース処理を使用して oc adm cordon および oc adm drain コマンドの場合と同じ結果が得られます。
11.1.1. エビクションストラテジー
ノードがメンテナンス状態になると、ノードにはスケジュール対象外のマークが付けられ、ノードからすべての仮想マシンおよび Pod がドレインされます。
仮想マシン (VM) またはクラスターのエビクションストラテジーを設定できます。
- 仮想マシンエビクションストラテジー
仮想マシンの
LiveMigrateエビクションストラテジーは、ノードがメンテナンス状態になるか、ドレイン (解放) される場合に仮想マシンインスタンスが中断されないようにします。このエビクションストラテジーを持つ VMI は、別のノードにライブマイグレーションされます。OpenShift Virtualization Web コンソールまたは コマンドライン を使用して、仮想マシン (VM) のエビクションストラテジーを設定できます。
重要デフォルトのエビクションストラテジーは
LiveMigrateです。移行不可能な仮想マシンがLiveMigrateエビクションストラテジーを使用していると、ノードのドレインが妨げられたり、インフラストラクチャーのアップグレードがブロックされたりする可能性があります。これは、その仮想マシンがノードからエビクトされないためです。この状況では、仮想マシンを手動でシャットダウンしない限り、移行はPendingまたはScheduling中の状態のままになります。移行不可能な仮想マシンのエビクションストラテジーを、アップグレードをブロックしない
LiveMigrateIfPossibleに設定する必要があります。移行すべきでない仮想マシンの場合は、Noneに設定する必要があります。
- クラスターエビクションストラテジー
- ワークロードの継続性またはインフラストラクチャーのアップグレードを優先するために、クラスターのエビクションストラテジーを設定できます。
クラスターエビクションストラテジーの設定は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
| エビクションストラテジー | 説明 | ワークフローを中断する | アップグレードをブロックする |
|---|---|---|---|
|
| アップグレードよりもワークロードの継続性を優先します。 | いいえ | はい 2 |
|
| ワークロードの継続性よりもアップグレードを優先して、環境が確実に更新されるようにします。 | はい | いいえ |
|
| エビクション戦略を使用せずに仮想マシンをシャットダウンします。 | はい | いいえ |
- マルチノードクラスターのデフォルトのエビクション戦略。
- 仮想マシンがアップグレードをブロックする場合は、仮想マシンを手動でシャットダウンする必要があります。
- シングルノード OpenShift のデフォルトのエビクション戦略。
11.1.1.1. コマンドラインを使用した仮想マシンエビクション戦略の設定
コマンドラインを使用して、仮想マシンのエビクション戦略を設定できます。
デフォルトのエビクションストラテジーは LiveMigrate です。移行不可能な仮想マシンが LiveMigrate エビクションストラテジーを使用していると、ノードのドレインが妨げられたり、インフラストラクチャーのアップグレードがブロックされたりする可能性があります。これは、その仮想マシンがノードからエビクトされないためです。この状況では、仮想マシンを手動でシャットダウンしない限り、移行は Pending または Scheduling 中の状態のままになります。
移行不可能な仮想マシンのエビクションストラテジーを、アップグレードをブロックしない LiveMigrateIfPossible に設定する必要があります。移行すべきでない仮想マシンの場合は、None に設定する必要があります。
手順
次のコマンドを実行して、
VirtualMachineリソースを編集します。$ oc edit vm <vm_name> -n <namespace>
エビクション戦略の例
apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: <vm_name> spec: template: spec: evictionStrategy: LiveMigrateIfPossible 1 # ...- 1
- エビクション戦略を指定します。デフォルト値は
LiveMigrateです。
仮想マシンを再起動して変更を適用します。
$ virtctl restart <vm_name> -n <namespace>
11.1.1.2. コマンドラインを使用したクラスターエビクション戦略の設定
コマンドラインを使用して、クラスターのエビクション戦略を設定できます。
クラスターエビクションストラテジーの設定は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
手順
次のコマンドを実行して、
hyperconvergedリソースを編集します。$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
次の例に示すように、クラスターのエビクション戦略を設定します。
クラスターエビクション戦略の例
apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: evictionStrategy: LiveMigrate # ...
11.1.2. 戦略を実行する
spec.running: true で設定された仮想マシンはすぐに再起動されます。spec.runStrategy キーを使用すると、特定の条件下で仮想マシンがどのように動作するかを決定するための柔軟性が高まります。
spec.runStrategy キーと spec.running キーは相互に排他的です。いずれか 1 つだけを使用できます。
両方のキーを含む仮想マシン設定は無効です。
11.1.2.1. 戦略を実行する
spec.runStrategy キーには 4 つの値があります。
Always-
仮想マシンインスタンス (VMI) は、仮想マシンが別のノードに作成されるときに常に存在します。元の VMI が何らかの理由で停止した場合、新しい VMI が作成されます。これは、
running: trueと同じ動作です。 RerunOnFailure- 以前のインスタンスに障害が発生した場合、VMI は別のノードで再作成されます。仮想マシンがシャットダウンされた場合など、仮想マシンが正常に停止した場合、インスタンスは再作成されません。
Manual-
VMI 状態は、virtctl クライアントコマンドの
start、stop、およびrestartを使用して手動で制御します。仮想マシンは自動的には再起動されません。 Halted-
仮想マシンの作成時には VMI は存在しません。これは、
running: falseと同じ動作です。
virtctl start、stop、および restart コマンドのさまざまな組み合わせは、実行戦略に影響します。
次の表では、仮想マシンの状態間の遷移を説明します。最初の列は、仮想マシンの初期実行戦略を示します。残りの列には、virtctl コマンドと、そのコマンドの実行後の新しい実行戦略が表示されます。
| 初期実行戦略 | Start | Stop | Restart |
|---|---|---|---|
| Always | - | Halted | Always |
| RerunOnFailure | - | Halted | RerunOnFailure |
| Manual | Manual | Manual | Manual |
| Halted | Always | - | - |
インストーラーによってプロビジョニングされたインフラストラクチャーを使用してインストールされたクラスター内のノードがマシンの健全性チェックに失敗して使用できない場合は、runStrategy: Always または runStrategy: RerunOnFailure を持つ仮想マシンが新しいノードで再スケジュールされます。
11.1.2.2. コマンドラインを使用した仮想マシン実行戦略の設定
コマンドラインを使用して、仮想マシンの実行戦略を設定できます。
spec.runStrategy キーと spec.running キーは相互に排他的です。両方のキーの値を含む仮想マシン設定は無効です。
手順
次のコマンドを実行して、
VirtualMachineリソースを編集します。$ oc edit vm <vm_name> -n <namespace>
実行戦略の例
apiVersion: kubevirt.io/v1 kind: VirtualMachine spec: runStrategy: Always # ...
11.1.3. ベアメタルノードのメンテナンス
OpenShift Container Platform をベアメタルインフラストラクチャーにデプロイする場合、クラウドインフラストラクチャーにデプロイする場合と比較すると、追加で考慮する必要のある点があります。クラスターノードが一時的とみなされるクラウド環境とは異なり、ベアメタルノードを再プロビジョニングするには、メンテナンスタスクにより多くの時間と作業が必要になります。
致命的なカーネルエラーが発生したり、NIC カードのハードウェア障害が発生する場合などにベアメタルノードに障害が発生した場合には、障害のあるノードが修復または置き換えられている間に、障害が発生したノード上のワークロードをクラスターの別の場所で再起動する必要があります。ノードのメンテナンスモードにより、クラスター管理者はノードの電源を正常に停止し、ワークロードをクラスターの他の部分に移動させ、ワークロードが中断されないようにします。詳細な進捗とノードのステータスの詳細は、メンテナンス時に提供されます。
