1.7. フェンシングと修復のイベントフロー
ノードが健全でなくなると、ワークロード、そして理想的にはノードを健全な状態に復元するために、ノードを検出、隔離、修復する複数のイベントが発生します。OpenShift クラスターによってトリガーされるイベントや、Workload Availability Operator による反応で発生するイベントがあります。情報に基づいた意思決定を行うには、この一連のイベントとイベント間の期間を理解することが重要です。意思決定とは、使用する修復プロバイダー、Node Health Check Operator と選択した修復プロバイダーの設定方法などを指します。
次に示す例は、イベントの段階的なフローを概説する一般的なユースケースです。Node Health Check Operator が Ready=Unknown
の異常な状態にある場合にのみ、フェーズは次のように動作します。
1.7.1. フェーズ 1 - Kubernetes ヘルスチェック (コア OpenShift) リンクのコピーリンクがクリップボードにコピーされました!
異常なノードは API サーバーとの通信を停止します。約 50 秒後、API サーバーはノードの "Ready" 状態を "Unknown" (Ready=Unknown
) に設定します。
1.7.2. フェーズ 2 - ノードヘルスチェック (NHC) リンクのコピーリンクがクリップボードにコピーされました!
Ready=Unknown
の状態が設定した期間よりも長くなると、修復が開始されます。
このフェーズ内でユーザーが設定した期間とは、不健全な状態にある期間に対して、Operator が許容できる範囲を表します。ワークロードが要求どおりに再起動している間は、リソースが "Unready" の状態になることを考慮します。
以下に例を示します。
- 再起動に時間がかかるワークロードがある場合は、タイムアウトを長くする必要があります。
- 同様に、ワークロードの再起動が短い場合、必要なタイムアウトも短くなります。
1.7.3. フェーズ 3 - ホストの修復/API の修復 (設定された修復 Operator に応じて) リンクのコピーリンクがクリップボードにコピーされました!
Machine Deletion Remediation (MDR)、Self Node Remediation (SNR) または Fence Agents Remediation (FAR) を使用して、remediator はノードを再起動してフェンスし、安全な状態に到達するためにノードを分離します。
このフェーズの詳細はユーザーによって設定され、ワークロード要件によって異なります。
以下に例を示します。
- Machine Deletion Remediation - プラットフォームの選択は、マシンの再プロビジョニングにかかる時間と、修復の期間に影響します。MDR は、Machine API を使用するクラスターにのみ適用されます。
- Self Node Remediation - 修復時間は、不健全なノードを自動的に再起動するのにかかる安全な時間や、エラー状態が検出されたときにマシンが安全な状態になるようにするために使用されるウォッチドッグデバイスなど、多くのパラメーターによって異なります。
- Fence Agents Remediation - フェンスエージェントの時間は、クラスターノード、管理インターフェイス、エージェントパラメーターなど、多くのパラメーターによって異なります。
1.7.4. フェーズ 4 - ワークロードの開始 リンクのコピーリンクがクリップボードにコピーされました!
MDR を使用すると、remediator はリソースを削除します。FAR と SNR を使用する場合、さまざまな修復ストラテジーを使用できます。1 つのストラテジーは、OutOfServiceTaint
で、out-of-service taint を使用してクラスター内のリソースの削除を許可します。どちらの場合も、リソースを削除すると、影響を受けるワークロードの再スケジュールがより速くなります。その後、ワークロードは再スケジュールされ、再開されます。
このフェーズは、フェンシングが完了すると remediator によって自動的に開始されます。フェンシングが完了せず、エスカレーション修復が必要な場合、ユーザーは修復プロセス全体のタイムアウトを秒単位で設定する必要があります。タイムアウトが経過してもノードがまだ正常でない場合、NHC は次の remediator を試して、異常なノードを修復します。