修復、フェンシング、およびメンテナンス
Workload Availability の修復、フェンシング、およびメンテナンス
概要
はじめに リンクのコピーリンクがクリップボードにコピーされました!
Workload Availability for Red Hat OpenShift に関するフィードバック リンクのコピーリンクがクリップボードにコピーされました!
Red Hat ドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。改善点を報告する場合は、以下のように行います。
- JIRA の Web サイトにアクセスします。
- Summary フィールドにわかりやすいタイトルを入力します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
- Reporter フィールドにユーザー名を入力します。
- Affects Version/s フィールドに、影響を受けるバージョンを入力します。
- ダイアログの下部にある Create をクリックします。
第1章 ノードの修復、フェンシング、およびメンテナンスについて リンクのコピーリンクがクリップボードにコピーされました!
ハードウェアは不完全であり、ソフトウェアにはバグが含まれています。カーネルのハングやネットワークインターフェイスコントローラー (NIC) の障害などのノードレベルの障害が発生した場合、クラスターから必要な作業は減少せず、影響を受けるノードからのワークロードをどこかで再起動する必要があります。ただし、ReadWriteOnce (RWO) ボリュームや StatefulSet などの一部のワークロードでは、最大で 1 つのセマンティクスが必要になる場合があります。
これらのワークロードに影響を与える障害は、データの損失、破損、またはその両方のリスクを伴います。ワークロードの回復 (remediation と、理想的にはノードの回復とも呼ばれます) を開始する前に、fencing と呼ばれる安全な状態にノードが達していることを確認することが重要です。
ノードとワークロードの true のステータスを確認するために管理者の介入に依存することは、必ずしも現実的ではありません。このような介入を容易にするために、Red Hat OpenShift は、障害検出、フェンシング、および修復を自動化するための複数のコンポーネントを提供します。
1.1. Self Node Remediation リンクのコピーリンクがクリップボードにコピーされました!
Self Node Remediation Operator は Red Hat OpenShift アドオンオペレーターであり、異常なノードを再起動し、Pod や VolumeAttachments などのリソースを削除するフェンシングと修復の外部システムを実装します。再起動によりワークロードが確実に隔離され、リソースの削除により影響を受けるワークロードの再スケジュールが加速します。他の外部システムとは異なり、自己ノード修復には、Intelligent Platform Management Interface (IPMI) やノードプロビジョニング用の API などの管理インターフェイスは必要ありません。
セルフノード修復は、マシンヘルスチェックやノードヘルスチェックなどの障害検出システムで使用できます。
1.2. Machine Health Check リンクのコピーリンクがクリップボードにコピーされました!
Machine Health Check は、マシンのステータスとノードの状態をモニターする Red Hat OpenShift ビルトインの失敗検出、フェンシング、修復システムを利用します。マシンヘルスチェックは、セルフノード修復などの外部フェンシングおよび修復システムをトリガーするように設定できます。
1.3. Node Health Check リンクのコピーリンクがクリップボードにコピーされました!
Node Health Check Operator は、ノードの状態をモニターする障害検出システムを実装する Red Hat OpenShift アドオンオペレーターです。フェンシングまたは修復システムが組み込まれていないため、そのような機能を提供する外部システムで設定する必要があります。デフォルトでは、セルフノード修復システムを利用するように設定されています。
1.4. ノードのメンテナンス リンクのコピーリンクがクリップボードにコピーされました!
管理者は、ドライブ、RAM、または NIC を交換するなど、クラスターを中断する必要がある状況に直面します。
このメンテナンスの前に、影響を受けるノードを遮断してドレインする必要があります。ノードが遮断されると、そのノードで新しいワークロードをスケジュールできなくなります。ノードがドレインされると、ダウンタイムを回避または最小化するために、影響を受けるノードのワークロードが他のノードに転送されます。
このメンテナンスはコマンドラインツールを使用して実行できますが、Node Maintenance Operator は、カスタムリソースを使用してこれを達成するための宣言的なアプローチを提供します。そのようなリソースがノードに存在する場合、オペレーターは、リソースが削除されるまでノードを遮断してドレインします。
第2章 自己ノード修復の使用 リンクのコピーリンクがクリップボードにコピーされました!
Self Node Remediation Operator を使用して、異常なノードを自動的に再起動できます。この修復戦略は、ステートフルアプリケーションと ReadWriteOnce(RWO) ボリュームのダウンタイムを最小限に抑え、一時的な障害が発生した場合に計算能力を回復します。
2.1. Self Node Remediation Operator について リンクのコピーリンクがクリップボードにコピーされました!
Self Node Remediation Operator はクラスターノードで実行され、正常でないと特定されるノードを再起動します。Operator は、MachineHealthCheck または NodeHealthCheck コントローラーを使用して、クラスター内のノードの正常性を検出します。ノードが異常であると識別されると、MachineHealthCheck または NodeHealthCheck リソースが SelfNodeRemediation カスタムリソース (CR) を作成し、Self Node Remediation Operator をトリガーします。
SelfNodeRemediation CR は、次の YAML ファイルに似ています。
Self Node Remediation Operator は、ステートフルアプリケーションのダウンタイムを最小限に抑え、一時的な障害が発生した場合に計算能力を回復します。この Operator は、IPMI や API などの管理インターフェイスに関係なくノードをプロビジョニングするために使用できます。また、クラスターのインストールタイプ (インストーラーでプロビジョニングされたインフラストラクチャーやユーザーでプロビジョニングされたインフラストラクチャーなど) に関係なく使用できます。
2.1.1. ウォッチドッグデバイスについて リンクのコピーリンクがクリップボードにコピーされました!
ウォッチドッグデバイスは、次のいずれかになります。
- 電源が独立しているハードウェアデバイス
- 制御するホストと電源を共有するハードウェアデバイス
-
ソフトウェアまたは
softdogに実装された仮想デバイス
ハードウェアウォッチドッグデバイスと softdog デバイスには、それぞれ電子タイマーまたはソフトウェアタイマーがあります。これらのウォッチドッグデバイスは、エラー状態が検出されたときにマシンが安全な状態になるようにするために使用されます。クラスターは、ウォッチドッグタイマーを繰り返しリセットして、正常な状態にあることを証明する必要があります。このタイマーは、デッドロック、CPU の枯渇、ネットワークまたはディスクアクセスの喪失などの障害状態が原因で経過する可能性があります。タイマーが時間切れになると、ウォッチドッグデバイスは障害が発生したと見なし、デバイスがノードの強制リセットをトリガーします。
ハードウェアウォッチドッグデバイスは、softdog デバイスよりも信頼性があります。
2.1.1.1. ウォッチドッグデバイスを使用した Self Node Remediation Operator の動作の理解 リンクのコピーリンクがクリップボードにコピーされました!
Self Node Remediation Operator は、存在するウォッチドッグデバイスに基づいて修復戦略を決定します。
ハードウェアウォッチドッグデバイスが設定されて使用可能である場合、Operator はそれを修復に使用します。ハードウェアウォッチドッグデバイスが設定されていない場合、Operator は修復のために softdog デバイスを有効にして使用します。
システムまたは設定のどちらかで、いずれのウォッチドッグデバイスもサポートされていない場合、Operator はソフトウェアの再起動を使用してノードを修復します。
2.2. コントロールプレーンフェンシング リンクのコピーリンクがクリップボードにコピーされました!
以前のリリースでは、ワーカーノードでセルフノード修復とノードヘルスチェックを有効にすることができました。ノード障害が発生した場合、コントロールプレーンノードの修復戦略に従うこともできるようになりました。
自己ノード修復は、主に 2 つのシナリオで発生します。
API サーバー接続
- このシナリオでは、修復されるコントロールプレーンノードは分離されていません。API サーバーに直接接続することも、API サーバーに直接接続されているワーカーノードまたはコントロールプレーンノードを介して API サーバーに間接的に接続することもできます。
-
API サーバー接続がある場合、コントロールプレーンノードは、Node Health Check Operator がノードの
SelfNodeRemediationカスタムリソース (CR) を作成した場合にのみ修復されます。
API サーバー接続なし
- このシナリオでは、修復されるコントロールプレーンノードは API サーバーから分離されています。ノードは API サーバーに直接または間接的に接続できません。
API サーバー接続がない場合、コントロールプレーンノードは次の手順で説明されているように修正されます。
ピアワーカーノードの大部分を含むコントロールプレーンノードのステータスを確認します。ピアワーカーノードの大部分に到達できない場合、ノードはさらに分析されます。
コントロールプレーンノードのステータスを自己診断する
- 自己診断に合格した場合、アクションは実行されません。
- 自己診断に失敗した場合、ノードは隔離され、修復されます。
-
現在サポートされている自己診断では、
kubeletサービスのステータスをチェックし、opt in設定を使用してエンドポイントの可用性をチェックしています。
- ノードがほとんどのワーカーピアと通信できなかった場合は、コントロールプレーンノードと他のコントロールプレーンノードとの接続を確認します。ノードが他のコントロールプレーンピアと通信できる場合、アクションは実行されません。それ以外の場合、ノードは隔離され、修正されます。
2.3. Web コンソールを使用した Self Node Remediation Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Web コンソールを使用して、Self Node Remediation Operator をインストールできます。
Node Health Check Operator は、Self Node Remediation Operator をデフォルトの修復プロバイダーとしてインストールします。
前提条件
-
cluster-admin権限を持つユーザーとしてログインしている。
手順
- Red Hat OpenShift Web コンソールで、Operators → OperatorHub に移動します。
- 使用可能なオペレーターのリストから Self Node Remediation Operator を検索し、Install をクリックします。
-
Operator が
openshift-operatorsnamespace にインストールされるように、Installation mode と namespace のデフォルトの選択を維持します。 - Install をクリックします。
検証
インストールが正常に行われたことを確認するには、以下を実行します。
- Operators → Installed Operators ページに移動します。
-
Operator が
openshift-operatorsの namespace に設置されていることと、その状態がSucceededになっていることを確認してください。
Operator が正常にインストールされていない場合、以下を実行します。
-
Operators → Installed Operators ページに移動し、
Status列でエラーまたは失敗の有無を確認します。 -
Workloads → Pod ページに移動し、
openshift-operatorsプロジェクト内のself-node-remediation-controller-managerPod およびself-node-remediation-dsPod のログで、報告された問題がないか確認します。
2.4. CLI を使用した Self Node Remediation Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift CLI (oc) を使用して、Self Node Remediation Operator をインストールできます。
Self Node Remediation Operator は、独自の namespace または openshift-operators namespace にインストールできます。
独自の namespace に Operator をインストールするには、手順に従います。
openshift-operators namespace に Operator をインストールするには、手順の 3 にスキップします。これは、新しい Namespace カスタムリソース (CR) と OperatorGroup CR を作成する必要がないためです。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
Self Node Remediation Operator の
Namespaceカスタムリソース (CR) を作成します。NamespaceCR を定義し、YAML ファイルを保存します (例:self-node-remediation-namespace.yaml)。apiVersion: v1 kind: Namespace metadata: name: self-node-remediation
apiVersion: v1 kind: Namespace metadata: name: self-node-remediationCopy to Clipboard Copied! Toggle word wrap Toggle overflow NamespaceCR を作成するには、次のコマンドを実行します。oc create -f self-node-remediation-namespace.yaml
$ oc create -f self-node-remediation-namespace.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
OperatorGroupを作成します。OperatorGroupCR を定義し、YAML ファイルを保存します (例:self-node-remediation-operator-group.yaml)。apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: self-node-remediation-operator namespace: self-node-remediation
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: self-node-remediation-operator namespace: self-node-remediationCopy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroupCR を作成するには、次のコマンドを実行します。oc create -f self-node-remediation-operator-group.yaml
$ oc create -f self-node-remediation-operator-group.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
SubscriptionCR を作成します。SubscriptionCR を定義し、YAML ファイルを保存します (例:self-node-remediation-subscription.yaml)。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Self Node Remediation Operator をインストールする
Namespaceを指定します。セルフノード修復 Operator をopenshift-operatorsnamespace にインストールするには、SubscriptionCR でopenshift-operatorsを指定します。 - 2
- 指定したバージョンがカタログの新しいバージョンに置き換えられる場合に備えて、承認ストラテジーを Manual に設定します。これにより、新しいバージョンへの自動アップグレードが阻止され、最初の CSV のインストールが完了する前に手動での承認が必要となります。
SubscriptionCR を作成するには、次のコマンドを実行します。oc create -f self-node-remediation-subscription.yaml
$ oc create -f self-node-remediation-subscription.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
CSV リソースを調べて、インストールが成功したことを確認します。
oc get csv -n self-node-remediation
$ oc get csv -n self-node-remediationCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY VERSION REPLACES PHASE self-node-remediation.v.0.6.0 Self Node Remediation Operator v.0.6.0 Succeeded
NAME DISPLAY VERSION REPLACES PHASE self-node-remediation.v.0.6.0 Self Node Remediation Operator v.0.6.0 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow Self Node Remediation Operator が稼働していることを確認します。
oc get deploy -n self-node-remediation
$ oc get deploy -n self-node-remediationCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY UP-TO-DATE AVAILABLE AGE self-node-remediation-controller-manager 1/1 1 1 28h
NAME READY UP-TO-DATE AVAILABLE AGE self-node-remediation-controller-manager 1/1 1 1 28hCopy to Clipboard Copied! Toggle word wrap Toggle overflow Self Node Remediation Operator が
SelfNodeRemediationConfigCR を作成していることを確認します。oc get selfnoderemediationconfig -n self-node-remediation
$ oc get selfnoderemediationconfig -n self-node-remediationCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE self-node-remediation-config 28h
NAME AGE self-node-remediation-config 28hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 各セルフノード修復 Pod がスケジュールされ、各ワーカーノードとコントロールプレーンノードで実行されていることを確認します。
oc get daemonset -n self-node-remediation
$ oc get daemonset -n self-node-remediationCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE self-node-remediation-ds 6 6 6 6 6 <none> 28h
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE self-node-remediation-ds 6 6 6 6 6 <none> 28hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5. Self Node Remediation Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
Self Node Remediation Operator は、SelfNodeRemediationConfig CR と SelfNodeRemediationTemplate カスタムリソース定義 (CRD) を作成します。
2.5.1. Self Node Remediation Operator 設定について リンクのコピーリンクがクリップボードにコピーされました!
Self Node Remediation Operator は、self-node-remediation-config という名前の SelfNodeRemediationConfigCR を作成します。CR は Self Node Remediation Operator の namespace に作成されます。
SelfNodeRemediationConfig CR の変更により、Self Node Remediation デーモンセットが再作成されます。
SelfNodeRemediationConfig CR は以下の YAML ファイルのようになります。
- 1
- Operator が、正常でないノードで実行中の影響を受けるワークロードを復元するまで待機する期間を指定します。障害が発生したノードで実行中の代替 Pod を開始すると、データの破損や 1 回実行セマンティクスの違反が生じる可能性があります。これを防ぐために、Operator は、
ApiServerTimeout、ApiCheckInterval、maxApiErrorThreshold、peerDialTimeout、およびpeerRequestTimeoutフィールドから計算された最小値よりも小さい値を無視します。 - 2
- ノード内のウォッチドッグデバイスのファイルパスを指定します。ウォッチドッグデバイスへの誤ったパスを入力すると、Self Node Remediation Operator がソフトドッグデバイスのパスを自動的に検出します。
ウォッチドッグデバイスが使用できない場合、
SelfNodeRemediationConfigCR はソフトウェアの再起動を使用します。 - 3
- 異常なノードのソフトウェア再起動を有効にするかどうかを指定します。デフォルトでは、
isSoftwareRebootEnabledの値はtrueに設定されています。ソフトウェアの再起動を無効にするには、パラメーター値をfalseに設定します。 - 4
- 各 API サーバーとの接続を確認するためのタイムアウト期間を指定します。この期間が経過すると、Operator は修復を開始します。タイムアウト期間は 10 ミリ秒以上である必要があります。
- 5
- 各 API サーバーとの接続を確認する頻度を指定します。タイムアウト期間は 1 秒以上である必要があります。
- 6
- しきい値を指定します。このしきい値に達した後、ノードはピアへの接続を開始します。しきい値は 1 秒以上である必要があります。
- 7
- ピアが API サーバーに接続するためのタイムアウトの期間を指定します。タイムアウト期間は 10 ミリ秒以上である必要があります。
- 8
- ピアで接続を確立するためのタイムアウトの期間を指定します。タイムアウト期間は 10 ミリ秒以上である必要があります。
- 9
- ピアから応答を取得するためのタイムアウトの期間を指定します。タイムアウト期間は 10 ミリ秒以上である必要があります。
- 10
- IP アドレスなどのピア情報を更新する頻度を指定します。タイムアウト期間は 10 秒以上である必要があります。
- Self Node Remediation Operator は、deployment namespace にデフォルトで CR を作成します。
-
CR の名前は
self-node-remediation-configである必要があります。 -
指定できるのは、1 つの
SelfNodeRemediationConfigCR のみです。 -
SelfNodeRemediationConfigCR を削除すると、セルフノード修復が無効になります。 -
Self Node Remediation Operator によって作成された
self-node-remediation-configCR を編集できます。ただし、Self Node Remediation Operator の新しい CR を作成しようとすると、次のメッセージがログに表示されます。
controllers.SelfNodeRemediationConfig
ignoring selfnoderemediationconfig CRs that are not named 'self-node-remediation-config'
or not in the namespace of the operator:
'openshift-operators' {"selfnoderemediationconfig":
"openshift-operators/selfnoderemediationconfig-copy"}
controllers.SelfNodeRemediationConfig
ignoring selfnoderemediationconfig CRs that are not named 'self-node-remediation-config'
or not in the namespace of the operator:
'openshift-operators' {"selfnoderemediationconfig":
"openshift-operators/selfnoderemediationconfig-copy"}
2.5.2. 自己ノード修復テンプレートの設定を理解する リンクのコピーリンクがクリップボードにコピーされました!
Self Node Remediation Operator は、SelfNodeRemediationTemplate カスタムリソース定義 (CRD) も作成します。この CRD は、ワークロードをより速く回復することを目的としたノードの修復ストラテジーを定義します。次の修復戦略が利用可能です。
ResourceDeletion-
この修復戦略では、ノードオブジェクトではなく、ノード上の Pod と関連するボリュームアタッチメントが削除されます。
ResourceDeletionは、デフォルトの修復戦略です。 OutOfServiceTaint-
この修復戦略により、ノードオブジェクトではなく、ノード上の Pod および関連するボリュームアタッチメントが暗黙的に削除されます。これは、ノードに
OutOfServiceTaintストラテジーを配置することによって実現されます。このストラテジーにより、ワークロードがより迅速に回復されます。このストラテジーは、OpenShift Container Platform バージョン 4.13 以降のテクノロジープレビューでサポートされており、OpenShift Container Platform バージョン 4.15 以降の一般提供ではサポートされています。
Self Node Remediation Operator は、ResourceDeletion 修復ストラテジーが使用するストラテジー self-node-remediation-resource-deletion-template の SelfNodeRemediationTemplate CR を作成します。
SelfNodeRemediationTemplate CR は以下の YAML ファイルのようになります。
2.5.3. Self Node Remediation Operator のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
2.5.3.1. 一般的なトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
- 問題
- Self Node Remediation Operator の問題のトラブルシューティングが必要です。
- 解決方法
- Operator ログを確認してください。
2.5.3.2. デーモンセットの確認 リンクのコピーリンクがクリップボードにコピーされました!
- 問題
- Self Node Remediation Operator はインストールされていますが、デーモンセットはインストールされません。
- 解決方法
- エラーまたは警告がないか、オペレーターログを確認してください。
2.5.3.3. 失敗した修復 リンクのコピーリンクがクリップボードにコピーされました!
- 問題
- 不健康なノードは修正されませんでした。
- 解決方法
以下のコマンドを実行して、
SelfNodeRemediationCR が作成されていることを確認します。oc get snr -A
$ oc get snr -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow MachineHealthCheckコントローラーがノードが正常でない状態でSelfNodeRemediationCR を作成しなかった場合、MachineHealthCheckコントローラーのログを確認します。さらに、MachineHealthCheckCR に、修復テンプレートを使用するために必要な仕様が含まれていることを確認してください。SelfNodeRemediationCR が作成される場合、その名前が正常でないノードまたはマシンオブジェクトと一致することを確認します。
2.5.3.4. Operator をアンインストールした後でも、デーモンセットおよびその他の Self Node Remediation Operator リソースが存在する リンクのコピーリンクがクリップボードにコピーされました!
- 問題
- デーモンセット、設定 CR、修復テンプレート CR などの Self Node Remediation Operator リソースは、Operator をアンインストールした後も存在します。
- 解決方法
Self Node Remediation Operator リソースを削除するには、リソースタイプごとに次のコマンドを実行してリソースを削除します。
oc delete ds <self-node-remediation-ds> -n <namespace>
$ oc delete ds <self-node-remediation-ds> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete snrc <self-node-remediation-config> -n <namespace>
$ oc delete snrc <self-node-remediation-config> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete snrt <self-node-remediation-template> -n <namespace>
$ oc delete snrt <self-node-remediation-template> -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5.4. Self Node Remediation Operator に関するデータの収集 リンクのコピーリンクがクリップボードにコピーされました!
Self Node Remediation Operator に関するデバッグ情報を収集するには、must-gather ツールを使用します。Self Node Remediation Operator の must-gather イメージの詳細は、特定の機能に関するデータの収集 を参照してください。
2.5.5. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
第3章 マシンヘルスチェックを使用したノードの修復 リンクのコピーリンクがクリップボードにコピーされました!
マシンのヘルスチェックは特定のマシンプールの正常ではないマシンを自動的に修復します。
3.1. マシンのヘルスチェック リンクのコピーリンクがクリップボードにコピーされました!
マシンのヘルスチェックは、コントロールプレーンマシンセットを使用するクラスター上のコントロールプレーンマシンにのみ適用できます。
マシンの正常性を監視するには、リソースを作成し、コントローラーの設定を定義します。5 分間 NotReady ステータスにすることや、node-problem-detector に永続的な条件を表示すること、および監視する一連のマシンのラベルなど、チェックする条件を設定します。
MachineHealthCheck リソースを監視するコントローラーは定義済みのステータスをチェックします。マシンがヘルスチェックに失敗した場合、このマシンは自動的に検出され、その代わりとなるマシンが作成されます。マシンが削除されると、machine deleted イベントが表示されます。
マシンの削除による破壊的な影響を制限するために、コントローラーは 1 度に 1 つのノードのみをドレイン (解放) し、これを削除します。マシンのターゲットプールで許可される maxUnhealthy しきい値を上回る数の正常でないマシンがある場合、修復が停止するため、手動による介入が可能になります。
タイムアウトについて注意深い検討が必要であり、ワークロードと要件を考慮してください。
- タイムアウトの時間が長くなると、正常でないマシンのワークロードのダウンタイムが長くなる可能性があります。
-
タイムアウトが短すぎると、修復ループが生じる可能性があります。たとえば、
NotReadyステータスを確認するためのタイムアウトは、マシンが起動プロセスを完了できるように十分な時間を設定する必要があります。
チェックを停止するには、リソースを削除します。
3.1.1. マシンヘルスチェックのデプロイ時の制限 リンクのコピーリンクがクリップボードにコピーされました!
マシンヘルスチェックをデプロイする前に考慮すべき制限事項があります。
- マシンセットが所有するマシンのみがマシンヘルスチェックによって修復されます。
- マシンのノードがクラスターから削除される場合、マシンヘルスチェックはマシンが正常ではないとみなし、すぐにこれを修復します。
-
nodeStartupTimeoutの後にマシンの対応するノードがクラスターに加わらない場合、マシンは修復されます。 -
MachineリソースフェーズがFailedの場合、マシンはすぐに修復されます。
3.2. Self Node Remediation Operator を使用するためのマシンヘルスチェックの設定 リンクのコピーリンクがクリップボードにコピーされました!
次の手順を使用して、Self Node Remediation Operator を修復プロバイダーとして使用するようにワーカーまたはコントロールプレーンマシンのヘルスチェックを設定します。
Self Node Remediation Operator をマシンの健全性チェックの修復プロバイダーとして使用するには、マシンに、クラスター内に関連付けられたノードが配置されている必要があります。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
SelfNodeRemediationTemplateCR を作成します。SelfNodeRemediationTemplateCR を定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 修復ストラテジーを指定します。デフォルトのストラテジーは
ResourceDeletionです。
SelfNodeRemediationTemplateCR を作成するには、以下のコマンドを実行します。oc create -f <snrt-name>.yaml
$ oc create -f <snrt-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
MachineHealthCheckCR を作成し、SelfNodeRemediationTemplateCR を参照するよう更新します。MachineHealthCheckを定義または更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow MachineHealthCheckCR を作成するには、次のコマンドを実行します。oc create -f <mhc-name>.yaml
$ oc create -f <mhc-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow MachineHealthCheckCR を更新するには、次のコマンドを実行します。oc apply -f <mhc-name>.yaml
$ oc apply -f <mhc-name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第4章 ノードヘルスチェックを使用したノードの修復 リンクのコピーリンクがクリップボードにコピーされました!
Node Health Check Operator を使用して、不健全なノードを特定できます。Operator は、Self Node Remediation Operator を使用して、不健全なノードを修復します。
Self Node Remediation Operator の詳細は、自己ノード修復の使用 の章を参照してください。
Red Hat OpenShift Service on AWS (ROSA) クラスターにはマシンヘルスチェックがプリインストールされているため、Node Health Check Operator はそのような環境では機能しません。
4.1. Node Health Check Operator について リンクのコピーリンクがクリップボードにコピーされました!
Node Health Check Operator は、クラスター内のノードの健全性を検出します。NodeHealthCheck コントローラーは、NodeHealthCheck カスタムリソース (CR) を作成します。これは、ノードの状態を判断するための一連の基準としきい値を定義します。
Node Health Check Operator は、Self Node Remediation Operator をデフォルトの修復プロバイダーとしてインストールします。
Node Health Check Operator は異常なノードを検出すると、修復プロバイダーをトリガーする修復 CR を作成します。たとえば、コントローラーは SelfNodeRemediation CR を作成し、Self Node Remediation Operator をトリガーして正常でないノードを修復します。
NodeHealthCheck CR は、修復プロバイダーとして自己ノード修復を使用した次の YAML ファイルに似ています。
- 1
- 修復プロバイダーがターゲットプール内のノードを同時に修復するために必要な正常なノードの数 (パーセンテージまたは数) を指定します。正常なノードの数が
minHealthyで設定された制限以上の場合、修復が行われます。デフォルト値は 51% です。 - 2
- 新しい修復が開始されないようにし、進行中の修復を継続できるようにします。デフォルト値は空です。ただし、修復を一時停止する原因を特定する文字列の配列を入力できます。たとえば、
pause-test-cluster。注記アップグレードプロセス中に、クラスター内のノードが一時的に使用できなくなり、異常として識別される場合があります。ワーカーノードの場合、オペレーターはクラスターがアップグレード中であることを検出すると、新しい異常なノードの修正を停止して、そのようなノードが再起動しないようにします。
- 3
- 修復プロバイダーからの修復テンプレートを指定します。たとえば、Self Node Remediation Operator のようになります。
remediationTemplateはescalatingRemediationと相互排他的です。 - 4
- 順序フィールドとタイムアウトフィールドを含む
RemediationTemplateのリストを指定します。正常なノードを取得するには、このフィールドを使用して複数の修復を順序付けし、設定します。この戦略により、成功しない可能性のある単一の修復に依存するのではなく、正常なノードを取得できる可能性が高まります。orderフィールドは、修復が呼び出される順序を決定します (低い順序 = 早い呼び出し)。timeoutフィールドは、次の修復がいつ呼び出されるかを決定します。escalatingRemediationはremediationTemplateと相互排他的です。 - 5
- チェックするラベルまたは式に一致する selector を指定します。1 つの CR でコントロールプレーンノードとワーカーノードの両方を選択しないでください。
- 6
- ノードが異常と見なされるかどうかを決定する条件のリストを指定します。
- 7 8
- ノード条件のタイムアウト期間を指定します。タイムアウトの期間中に条件が満たされた場合、ノードは修正されます。タイムアウトが長いと、異常なノードのワークロードで長期間のダウンタイムが発生する可能性があります。
NodeHealthCheck CR は、修復プロバイダーとして metal3 を使用した、次の YAML ファイルに似ています。
matchExpressions は例です。特定のニーズに基づいてマシングループをマッピングする必要があります。
Metal3RemediationTemplate は、修復プロバイダーとして metal3 を使用した、次の YAML ファイルに似ています。
NodeHealthCheck CR の作成に加えて、Metal3RemediationTemplate も作成する必要があります。
4.1.1. Node Health Check Operator のワークフローを理解する リンクのコピーリンクがクリップボードにコピーされました!
ノードが異常であると識別されると、Node Health Check Operator は他にいくつのノードが異常であるかをチェックします。健康なノードの数が NodeHealthCheck CR の minHealthy フィールドで指定された量を超えた場合、コントローラーは、修復プロバイダーによって外部の修復テンプレートで提供される詳細から修復 CR を作成します。修復後、kubelet はノードのヘルスステータスを更新します。
ノードが正常になると、コントローラーは外部修復テンプレートを削除します。
4.1.2. ノードのヘルスチェックによるマシンヘルスチェックの競合 リンクのコピーリンクがクリップボードにコピーされました!
ノードヘルスチェックとマシンヘルスチェックの両方がデプロイメントされている場合、ノードヘルスチェックはマシンヘルスチェックとの競合を回避します。
Red Hat OpenShift は machine-api-termination-handler をデフォルトの MachineHealthCheck リソースとしてデプロイします。
次のリストは、ノードヘルスチェックとマシンヘルスチェックがデプロイメントされたときのシステムの動作をまとめたものです。
デフォルトのマシンヘルスチェックのみが存在する場合、ノードヘルスチェックは引き続き異常なノードを識別します。ただし、ノードヘルスチェックは、Terminating 状態の異常なノードを無視します。デフォルトのマシンヘルスチェックは、異常なノードを Terminating 状態で処理します。
ログメッセージの例
INFO MHCChecker ignoring unhealthy Node, it is terminating and will be handled by MHC {"NodeName": "node-1.example.com"}INFO MHCChecker ignoring unhealthy Node, it is terminating and will be handled by MHC {"NodeName": "node-1.example.com"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow デフォルトのマシンヘルスチェックが変更された場合 (たとえば、
unhealthyConditionsがReadyの場合)、または追加のマシンヘルスチェックが作成された場合、ノードヘルスチェックは無効になります。ログメッセージの例
INFO controllers.NodeHealthCheck disabling NHC in order to avoid conflict with custom MHCs configured in the cluster {"NodeHealthCheck": "/nhc-worker-default"}INFO controllers.NodeHealthCheck disabling NHC in order to avoid conflict with custom MHCs configured in the cluster {"NodeHealthCheck": "/nhc-worker-default"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでも、デフォルトのマシンヘルスチェックのみが存在する場合、ノードヘルスチェックが再度有効になります。
ログメッセージの例
INFO controllers.NodeHealthCheck re-enabling NHC, no conflicting MHC configured in the cluster {"NodeHealthCheck": "/nhc-worker-default"}INFO controllers.NodeHealthCheck re-enabling NHC, no conflicting MHC configured in the cluster {"NodeHealthCheck": "/nhc-worker-default"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2. コントロールプレーンフェンシング リンクのコピーリンクがクリップボードにコピーされました!
以前のリリースでは、ワーカーノードでセルフノード修復とノードヘルスチェックを有効にすることができました。ノード障害が発生した場合、コントロールプレーンノードの修復戦略に従うこともできるようになりました。
ワーカーノードとコントロールプレーンノードに同じ NodeHealthCheck CR を使用しないでください。ワーカーノードとコントロールプレーンノードを一緒にグループ化すると、正常なノードの最小数が正しく評価されず、予期しない修復または欠落した修復が発生する可能性があります。これは、Node Health Check Operator がコントロールプレーンノードを処理する方法が原因です。コントロールプレーンノードを独自のグループにグループ化し、ワーカーノードを独自のグループにグループ化する必要があります。必要に応じて、複数のワーカーノードグループを作成することもできます。
修復戦略に関する考慮事項:
- 予期しない動作が発生する可能性があるため、同じノードに重複する複数の設定を含むノードヘルスチェック設定は避けてください。この提案は、ワーカープレーンノードとコントロールプレーンノードの両方に適用されます。
- Node Health Check Operator は、一度に最大 1 つのコントロールプレーンノードを修正するというハードコーディングされた制限を実装します。複数のコントロールプレーンノードを同時に修復しないでください。
4.3. Web コンソールを使用したノードヘルスチェックオペレーターのインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Web コンソールを使用して、Node Health Check Operator をインストールできます。
前提条件
-
cluster-admin権限を持つユーザーとしてログインしている。
手順
- Red Hat OpenShift Web コンソールで、Operators → OperatorHub に移動します。
- Node Health Check Operator を検索し、Installをクリックします。
-
Operator が
openshift-operatorsnamespace にインストールされるように、Installation mode と namespace のデフォルトの選択を維持します。 -
Console plug-in が
Enableに設定されていることを確認します。 - Install をクリックします。
検証
インストールが正常に行われたことを確認するには、以下を実行します。
- Operators → Installed Operators ページに移動します。
-
Operator が
openshift-operatorsの namespace 内に設置されていることと、その状態がSucceededとなっていることを確認してください。
Operator が正常にインストールされていない場合、以下を実行します。
-
Operators → Installed Operators ページに移動し、
Status列でエラーまたは失敗の有無を確認します。 -
Workloads → Podsページにナビゲートし、問題を報告している
openshift-operatorsプロジェクトの Pod のログを確認します。
4.4. CLI を使用した Node Health Check Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift CLI( oc ) を使用して、Node Health Check Operator をインストールできます。
独自の namespace に Operator をインストールするには、手順に従います。
openshift-operators namespace に Operator をインストールするには、手順の 3 にスキップします。これは、新しい Namespace カスタムリソース (CR) と OperatorGroup CR を作成する必要がないためです。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
Node Health Check Operator の
Namespaceカスタムリソース (CR) を作成します。NamespaceCR を定義し、YAML ファイルを保存します (例:node-health-check-namespace.yaml)。apiVersion: v1 kind: Namespace metadata: name: node-health-check
apiVersion: v1 kind: Namespace metadata: name: node-health-checkCopy to Clipboard Copied! Toggle word wrap Toggle overflow NamespaceCR を作成するには、次のコマンドを実行します。oc create -f node-health-check-namespace.yaml
$ oc create -f node-health-check-namespace.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
OperatorGroupを作成します。OperatorGroupCR を定義し、YAML ファイルを保存します (例:node-health-check-operator-group.yaml)。apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: node-health-check-operator namespace: node-health-check
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: node-health-check-operator namespace: node-health-checkCopy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroupCR を作成するには、次のコマンドを実行します。oc create -f node-health-check-operator-group.yaml
$ oc create -f node-health-check-operator-group.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
SubscriptionCR を作成します。SubscriptionCR を定義し、YAML ファイルを保存します (例:node-health-check-subscription.yaml)。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Node Health Check Operator をインストールする
Namespaceを指定します。Node Health Check Operator をopenshift-operatorsnamespace にインストールするには、SubscriptionCR でopenshift-operatorsを指定します。 - 2
- サブスクリプションのチャネル名を指定します。Node Health Check Operator の最新バージョンにアップグレードするには、サブスクリプションのチャネル名を
candidateからstableに手動で変更する必要があります。 - 3
- 指定したバージョンがカタログの新しいバージョンに置き換えられる場合に備えて、承認ストラテジーを Manual に設定します。これにより、新しいバージョンへの自動アップグレードが阻止され、最初の CSV のインストールが完了する前に手動での承認が必要となります。
SubscriptionCR を作成するには、次のコマンドを実行します。oc create -f node-health-check-subscription.yaml
$ oc create -f node-health-check-subscription.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
CSV リソースを調べて、インストールが成功したことを確認します。
oc get csv -n openshift-operators
$ oc get csv -n openshift-operatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY VERSION REPLACES PHASE node-healthcheck-operator.v0.5.0. Node Health Check Operator 0.5.0 Succeeded
NAME DISPLAY VERSION REPLACES PHASE node-healthcheck-operator.v0.5.0. Node Health Check Operator 0.5.0 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow Node Health Check Operator が稼働していることを確認します。
oc get deploy -n openshift-operators
$ oc get deploy -n openshift-operatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY UP-TO-DATE AVAILABLE AGE node-health-check-operator-controller-manager 1/1 1 1 10d
NAME READY UP-TO-DATE AVAILABLE AGE node-health-check-operator-controller-manager 1/1 1 1 10dCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5. ノードヘルスチェックの作成 リンクのコピーリンクがクリップボードにコピーされました!
Web コンソールを使用して、ノードヘルスチェックを作成して異常なノードを特定し、修正する修復タイプとストラテジーを指定できます。
手順
- Red Hat OpenShift Web コンソールの Administrator の観点から、Compute → NodeHealthChecks → CreateNodeHealthCheck をクリックします。
- Form ビュー または YAML ビュー を使用してノードのヘルスチェックを設定するかどうかを指定します。
- ノードヘルスチェックの 名前 を入力します。名前は小文字、英数字、'-'、または '.' で構成され、英数字で開始および終了する必要があります。
- Remediator タイプ、および Self node remediation または Other を指定します。Self node remediation オプションは、Node Health Check Operator でインストールされる Self Node Remediation Operator の一部です。Other を選択するには、API バージョン、Kind、Name、および Namespace を入力する必要があります。これは、修正の修復テンプレートリソースを指します。
修復する ノード のラベルを指定して、ノードを選択します。選択した内容は、確認するラベルと一致します。複数のラベルを指定する場合、ノードには各ラベルが含まれている必要があります。デフォルト値は空で、ワーカーノードとコントロールプレーンノードの両方を選択します。
注記Self Node Remediation Operator を使用してノードヘルスチェックを作成する場合、
node-role.kubernetes.io/workerまたはnode-role.kubernetes.io/control-planeのいずれかを値として選択する必要があります。- NodeHealthCheck がターゲットプール内のノードを修復するために必要な、正常なノードの最小数をパーセンテージまたは数値で指定します。正常なノードの数が Min healthy によって設定された制限以上の場合には、修復が行われます。デフォルト値は 51% です。
- ノードが一致した場合に、ノードが異常であると見なされ、修復が必要かどうかを決定する、異常な条件 のリストを指定します。Type、Status、および Duration を指定できます。独自のカスタムタイプを作成することもできます。
- Create をクリックしてノードヘルスチェックを作成します。
検証
- Compute → NodeHealthCheck ページに移動し、対応するノードヘルスチェックが一覧表示され、それらのステータスが表示されることを確認します。作成が完了すると、ノードヘルスチェックを一時停止、変更、および削除できます。
4.6. Node Health Check Operator に関するデータの収集 リンクのコピーリンクがクリップボードにコピーされました!
Node Health Check Operator に関するデバッグ情報を収集するには、must-gather ツールを使用します。Node Health Check Operator の must-gather イメージの詳細は、特定の機能に関するデータの収集 を参照してください。
4.7. 関連情報 リンクのコピーリンクがクリップボードにコピーされました!
第5章 Node Maintenance Operator を使用してノードをメンテナンスモードにする リンクのコピーリンクがクリップボードにコピーされました!
oc adm ユーティリティーまたは NodeMaintenance カスタムリソース (CR) を使用して、Node Maintenance Operator を使用してノードをメンテナンスモードにすることができます。
5.1. Node Maintenance Operator について リンクのコピーリンクがクリップボードにコピーされました!
Node Maintenance Operator は、新規または削除された NodeMaintenance CR をモニタリングします。新規の NodeMaintenance CR が検出されると、新規ワークロードはスケジュールされず、ノードは残りのクラスターから遮断されます。エビクトできるすべての Pod はノードからエビクトされます。NodeMaintenance CR が削除されると、CR で参照されるノードは新規ワークロードで利用可能になります。
ノードのメンテナンスタスクに NodeMaintenance CR を使用すると、標準の Red Hat OpenShift CR 処理を使用して oc adm cordon および oc adm drain コマンドの場合と同じ結果が得られます。
5.2. Node Maintenance Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
Node Maintenance Operator は、Web コンソールまたは OpenShift CLI (oc) を使用してインストールできます。
OpenShift Virtualization バージョン 4.10 以下がクラスターにインストールされている場合は、古いバージョンの Node Maintenance Operator が含まれています。
5.2.1. Web コンソールを使用した Node Maintenance Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Web コンソールを使用して、Node Maintenance Operator をインストールできます。
前提条件
-
cluster-admin権限を持つユーザーとしてログインしている。
手順
- Red Hat OpenShift Web コンソールで、Operators → OperatorHub に移動します。
- Node Maintenance Operator を検索し、Install をクリックします。
-
Operator が
openshift-operatorsnamespace にインストールされるように、Installation mode と namespace のデフォルトの選択を維持します。 - Install をクリックします。
検証
インストールが正常に行われたことを確認するには、以下を実行します。
- Operators → Installed Operators ページに移動します。
-
Operator が
openshift-operatorsの namespace 内に設置されていることと、その状態がSucceededとなっていることを確認してください。
Operator が正常にインストールされていない場合、以下を実行します。
-
Operators → Installed Operators ページに移動し、
Status列でエラーまたは失敗の有無を確認します。 -
Operators → Installed Operators → Node Maintenance Operator → Details ページに移動し、Pod を作成する前に
Conditionsセクションでエラーを調べます。 -
Workloads → Pods ページに移動し、インストールされた namespace で
Node Maintenance OperatorPod を検索し、Logsタブでログを確認します。
5.2.2. CLI を使用した Node Maintenance Operator のインストール リンクのコピーリンクがクリップボードにコピーされました!
OpenShift CLI (oc) を使用して、Node Maintenance Operator をインストールできます。
Node Maintenance Operator は、独自の namespace または openshift-operators namespace にインストールできます。
独自の namespace に Operator をインストールするには、手順に従います。
openshift-operators namespace に Operator をインストールするには、手順の 3 にスキップします。これは、新しい Namespace カスタムリソース (CR) と OperatorGroup CR を作成する必要がないためです。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
Node Maintenance Operator の
NamespaceCR を作成します。NamespaceCR を定義し、YAML ファイルを保存します (例:node-maintenance-namespace.yaml)。apiVersion: v1 kind: Namespace metadata: name: nmo-test
apiVersion: v1 kind: Namespace metadata: name: nmo-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow NamespaceCR を作成するには、次のコマンドを実行します。oc create -f node-maintenance-namespace.yaml
$ oc create -f node-maintenance-namespace.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
OperatorGroupを作成します。OperatorGroupCR を定義し、YAML ファイルを保存します (例:node-maintenance-operator-group.yaml)。apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: node-maintenance-operator namespace: nmo-test
apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: node-maintenance-operator namespace: nmo-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroupCR を作成するには、次のコマンドを実行します。oc create -f node-maintenance-operator-group.yaml
$ oc create -f node-maintenance-operator-group.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
SubscriptionCR を作成します。SubscriptionCR を定義し、YAML ファイルを保存します (例:node-maintenance-subscription.yaml)。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Node Maintenance Operator をインストールする
Namespaceを指定します。
重要Node Maintenance Operator を
openshift-operatorsnamespace にインストールするには、SubscriptionCR でopenshift-operatorsを指定します。SubscriptionCR を作成するには、次のコマンドを実行します。oc create -f node-maintenance-subscription.yaml
$ oc create -f node-maintenance-subscription.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
CSV リソースを調べて、インストールが成功したことを確認します。
oc get csv -n openshift-operators
$ oc get csv -n openshift-operatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME DISPLAY VERSION REPLACES PHASE node-maintenance-operator.v5.1.0 Node Maintenance Operator 5.1.0 Succeeded
NAME DISPLAY VERSION REPLACES PHASE node-maintenance-operator.v5.1.0 Node Maintenance Operator 5.1.0 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow Node Maintenance Operator が実行されていることを確認します。
oc get deploy -n openshift-operators
$ oc get deploy -n openshift-operatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY UP-TO-DATE AVAILABLE AGE node-maintenance-operator-controller-manager 1/1 1 1 10d
NAME READY UP-TO-DATE AVAILABLE AGE node-maintenance-operator-controller-manager 1/1 1 1 10dCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Node Maintenance Operator は、制限されたネットワーク環境でサポートされています。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
5.3. ノードのメンテナンスモードへの設定 リンクのコピーリンクがクリップボードにコピーされました!
NodeMaintenance CR を使用して、Web コンソールまたは CLI からノードをメンテナンスモードにすることができます。
5.3.1. Web コンソールでのノードのメンテナンスモードへの設定 リンクのコピーリンクがクリップボードにコピーされました!
ノードをメンテナンスモードに設定するために、Web コンソールを使用して NodeMaintenance カスタムリソース (CR) を作成できます。
前提条件
-
cluster-admin権限を持つユーザーとしてログインしている。 - OperatorHub から Node Maintenance Operator をインストールします。
手順
- Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
- Operator リストから Node Maintenance Operator を選択します。
- Node Maintenance タブで Create NodeMaintenance をクリックします。
-
Create NodeMaintenance ページで、Form view または YAML view t を選択して
NodeMaintenanceCR を設定します。 -
設定した
NodeMaintenanceCR を適用するには、Create をクリックします。
検証
Node Maintenance タブで Status 列を調べ、そのステータスが Succeeded であることを確認します。
5.3.2. CLI を使用してノードをメンテナンスモードに設定する場合 リンクのコピーリンクがクリップボードにコピーされました!
NodeMaintenance カスタムリソース (CR) を使用して、ノードをメンテナンスモードにすることができます。NodeMaintenance CR を適用すると、許可されているすべての Pod が削除され、ノードがスケジュール不能になります。エビクトされた Pod は、クラスター内の別のノードに移動するようにキューに置かれます。
前提条件
-
Red Hat OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。
手順
次の
NodeMaintenanceCR を作成し、ファイルをnodemaintenance-cr.yamlとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ノードメンテナンス CR を適用します。
oc apply -f nodemaintenance-cr.yaml
$ oc apply -f nodemaintenance-cr.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、メンテナンスタスクの進捗状況を確認します。
oc describe node <node-name>
$ oc describe node <node-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <node-name>はノードの名前です。たとえば、node-1.example.comなどになります。出力例を確認します。
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal NodeNotSchedulable 61m kubelet Node node-1.example.com status is now: NodeNotSchedulable
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal NodeNotSchedulable 61m kubelet Node node-1.example.com status is now: NodeNotSchedulableCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.3. 現在の NodeMaintenance CR タスクのステータスの確認 リンクのコピーリンクがクリップボードにコピーされました!
現在の NodeMaintenance CR タスクのステータスを確認できます。
前提条件
-
Red Hat OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてログインします。
手順
以下のコマンドを実行して、現在のノードのメンテナンスタスクのステータスを確認します (例:
NodeMaintenanceCR またはnm)。oc get nm -o yaml
$ oc get nm -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4. メンテナンスモードからのノードの再開 リンクのコピーリンクがクリップボードにコピーされました!
NodeMaintenance CR を使用して、Web コンソールまたは CLI から、メンテナンスモードからノードを再開できます。ノードを再起動することにより、ノードをメンテナンスモードから切り替え、再度スケジュール可能な状態にできます。
5.4.1. Web コンソールを使用してノードをメンテナンスモードから再開する方法 リンクのコピーリンクがクリップボードにコピーされました!
ノードをメンテナンスモードから再開するために、Web コンソールを使用して NodeMaintenance カスタムリソース (CR) を削除できます。
前提条件
-
cluster-admin権限を持つユーザーとしてログインしている。 - OperatorHub から Node Maintenance Operator をインストールします。
手順
- Web コンソールの Administrator パースペクティブで、Operators → Installed Operators に移動します。
- Operator リストから Node Maintenance Operator を選択します。
-
Node Maintenance タブで、削除する
NodeMaintenanceCR を選択します。 -
ノードの末尾の Options メニュー
をクリックし、Delete NodeMaintenance を選択します。
検証
- Red Hat OpenShift コンソールで、Compute → Nodes をクリックします。
-
NodeMaintenanceCR を削除したノードのStatus列を調べて、その状況がReadyであることを確認します。
5.4.2. CLI を使用してノードをメンテナンスモードから再開する方法 リンクのコピーリンクがクリップボードにコピーされました!
NodeMaintenance CR を削除することにより、NodeMaintenance CR で開始されたメンテナンスモードからノードを再開できます。
前提条件
-
Red Hat OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。
手順
ノードのメンテナンスタスクが完了したら、アクティブな
NodeMaintenanceCR を削除します。oc delete -f nodemaintenance-cr.yaml
$ oc delete -f nodemaintenance-cr.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
nodemaintenance.nodemaintenance.medik8s.io "maintenance-example" deleted
nodemaintenance.nodemaintenance.medik8s.io "maintenance-example" deletedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、メンテナンスタスクの進捗状況を確認します。
oc describe node <node-name>
$ oc describe node <node-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <node-name>はノードの名前です。たとえば、node-1.example.comなどになります。出力例を確認します。
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal NodeSchedulable 2m kubelet Node node-1.example.com status is now: NodeSchedulable
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal NodeSchedulable 2m kubelet Node node-1.example.com status is now: NodeSchedulableCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5. ベアメタルノードの操作 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルノードを含むクラスターの場合、Web コンソールの アクション コントロールを使用して、ノードをメンテナンスモードにしたり、ノードをメンテナンスモードから再開したりできます。
ベアメタルノードを含むクラスターは、概説したように、Web コンソールと CLI を使用して、ノードをメンテナンスモードにしたり、ノードをメンテナンスモードから再開したりすることもできます。これらのメソッドは、Web コンソールの アクション コントロールを使用して、ベアメタルクラスターにのみ適用できます。
5.5.1. ベアメタルノードのメンテナンス リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift をベアメタルインフラストラクチャーにデプロイする場合、クラウドインフラストラクチャーにデプロイする場合と比較すると、追加で考慮する必要のある点があります。クラスターノードが一時的とみなされるクラウド環境とは異なり、ベアメタルノードを再プロビジョニングするには、メンテナンスタスクにより多くの時間と作業が必要になります。
カーネルエラーや NIC カードのハードウェア障害が原因でベアメタルノードに障害が発生した場合には、障害のあるノードが修復または置き換えられている間に、障害が発生したノード上のワークロードをクラスターのノードで再起動する必要があります。ノードのメンテナンスモードにより、クラスター管理者はノードを正常にオフにし、ワークロードをクラスターの他の部分に移動させ、ワークロードが中断されないようにします。詳細な進捗とノードのステータスの詳細は、メンテナンス時に提供されます。
5.5.2. ベアメタルノードをメンテナンスモードに設定する リンクのコピーリンクがクリップボードにコピーされました!
Compute → Nodes 一覧で各ノードにある Options メニュー
を使用するか、Node Details 画面の Actions コントロールを使用して、ベアメタルノードをメンテナンスモードに設定します。
手順
- Web コンソールの 管理者 パースペクティブから、Compute → Nodes をクリックします。
この画面からノードをメンテナンスモードに設定することができます。これにより、複数のノードでアクションを簡単に実行できるようになります。または、選択したノードの包括的な詳細を表示できる Node Details 画面からも実行できるようになります。
-
ノードの末尾の Options メニュー
をクリックし、Start Maintenance を選択します。
- ノード名をクリックし、Node Details 画面を開いて Actions → Start Maintenance をクリックします。
-
ノードの末尾の Options メニュー
- 確認ウィンドウで Start Maintenance をクリックします。
ノードはスケジュール可能ではなくなりました。LiveMigration エビクションストラテジーを使用する仮想マシンがあった場合は、それらをライブマイグレーションします。このノードの他のすべての Pod および仮想マシンは削除され、別のノードで再作成されます。
検証
-
Compute → Nodes ページに移動し、対応するノードのステータスが
Under maintenanceであることを確認します。
5.5.3. メンテナンスモードからのベアメタルノードの再開 リンクのコピーリンクがクリップボードにコピーされました!
Compute → Nodes リストの各ノードにあるオプションメニュー
を使用して、または Node Details 画面の Actions コントロールを使用して、メンテナンスモードからベアメタルノードを再開します。
手順
- Web コンソールの 管理者 パースペクティブから、Compute → Nodes をクリックします。
複数のノードでアクションを簡単に実行できるこの画面からノードを再開できます。または、選択したノードの包括的な詳細を表示できる Node Details 画面からもノードを再開できます。
-
ノードの末尾の Options メニュー
をクリックし、Stop Maintenance を選択します。
- ノード名をクリックし、Node Details 画面を開いて Actions → Stop Maintenance をクリックします。
-
ノードの末尾の Options メニュー
- 確認ウィンドウで Stop Maintenance をクリックします。
ノードがスケジュール可能になります。メンテナンス前にノードで実行されていた仮想マシンインスタンスがあった場合、それらは自動的にこのノードに移行されません。
検証
-
Compute → Nodes ページに移動し、対応するノードのステータスが
Readyであることを確認します。
5.6. Node Maintenance Operator に関するデータの収集 リンクのコピーリンクがクリップボードにコピーされました!
Node Maintenance Operator に関するデバッグ情報を収集するには、must-gather ツールを使用します。Node Maintenance Operator の must-gather イメージの詳細は、特定の機能に関するデータの収集 を参照してください。