6.6. Self Node Remediation Operator を使用したノードの修復
Self Node Remediation Operator を使用して、異常なノードを自動的に再起動できます。この修復戦略は、ステートフルアプリケーションと ReadWriteOnce(RWO) ボリュームのダウンタイムを最小限に抑え、一時的な障害が発生した場合に計算能力を回復します。
6.6.1. Self Node Remediation Operator について
Self Node Remediation Operator はクラスターノードで実行され、正常でないと特定されるノードを再起動します。Operator は、MachineHealthCheck
または NodeHealthCheck
コントローラーを使用して、クラスター内のノードの正常性を検出します。ノードが異常であると識別されると、MachineHealthCheck
または NodeHealthCheck
リソースが SelfNodeRemediation
カスタムリソース (CR) を作成し、Self NodeRemediationOperator をトリガーします。
SelfNodeRemediation
CR は、次の YAML ファイルに似ています。
apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediation
metadata:
name: selfnoderemediation-sample
namespace: openshift-operators
spec:
status:
lastError: <last_error_message> 1
- 1
- 修復中に発生した最後のエラーを表示します。修復が正常に実行されるか、エラーが発生しない場合は、このフィールドは空になります。
Self Node Remediation Operator は、ステートフルアプリケーションのダウンタイムを最小限に抑え、一時的な障害が発生した場合に計算能力を回復します。この Operator は、IPMI や API などの管理インターフェイスに関係なくノードをプロビジョニングするために使用できます。また、クラスターのインストールタイプ (インストーラーでプロビジョニングされたインフラストラクチャーやユーザーでプロビジョニングされたインフラストラクチャーなど) に関係なく使用できます。
6.6.1.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 ファイルのようになります。
apiVersion: self-node-remediation.medik8s.io/v1alpha1 kind: SelfNodeRemediationConfig metadata: name: self-node-remediation-config namespace: openshift-operators spec: safeTimeToAssumeNodeRebootedSeconds: 180 1 watchdogFilePath: /dev/watchdog 2 isSoftwareRebootEnabled: true 3 apiServerTimeout: 15s 4 apiCheckInterval: 5s 5 maxApiErrorThreshold: 3 6 peerApiServerTimeout: 5s 7 peerDialTimeout: 5s 8 peerRequestTimeout: 5s 9 peerUpdateInterval: 15m 10
- 1
- 存続しているピアのタイムアウト期間を指定します。その後、オペレーターは異常なノードが再起動されたと見なすことができます。オペレーターは、この値の下限を自動的に計算します。ただし、ノードごとにウォッチドッグタイムアウトが異なる場合は、この値をより高い値に変更する必要があります。
- 2
- ノード内のウォッチドッグデバイスのファイルパスを指定します。ウォッチドッグデバイスへの誤ったパスを入力すると、Self Node Remediation Operator がソフトドッグデバイスのパスを自動的に検出します。
ウォッチドッグデバイスが使用できない場合、
SelfNodeRemediationConfig
CR はソフトウェアの再起動を使用します。 - 3
- 異常なノードのソフトウェア再起動を有効にするかどうかを指定します。デフォルトでは、
is Software Reboot Enabled
の値はtrue
に設定されています。ソフトウェアの再起動を無効にするには、パラメーター値をfalse
に設定します。 - 4
- 各 API サーバーとの接続を確認するためのタイムアウト期間を指定します。この期間が経過すると、Operator は修復を開始します。タイムアウト時間は 10 ミリ秒以上である必要があります。
- 5
- 各 API サーバーとの接続を確認する頻度を指定します。タイムアウト時間は 1 秒以上である必要があります。
- 6
- しきい値を指定します。このしきい値に達した後、ノードはピアへの接続を開始します。しきい値は、1 秒以上である必要があります。
- 7
- ピアが API サーバーに接続するためのタイムアウトの期間を指定します。タイムアウト時間は 10 ミリ秒以上である必要があります。
- 8
- ピアで接続を確立するためのタイムアウトの期間を指定します。タイムアウト時間は 10 ミリ秒以上である必要があります。
- 9
- ピアから応答を取得するためのタイムアウトの期間を指定します。タイムアウト時間は 10 ミリ秒以上である必要があります。
- 10
- IP アドレスなどのピア情報を更新する頻度を指定します。タイムアウト時間は 10 秒以上である必要があります。
Self NodeRemediationOperator によって作成された self-node-remediation-config
CR を編集できます。ただし、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"}
6.6.1.2. 自己ノード修復テンプレートの設定を理解する
Self Node Remediation Operator は、SelfNodeRemediationTemplate
カスタムリソース定義 (CRD) も作成します。この CRD は、ノードの修復ストラテジーを定義します。次の修復戦略が利用可能です。
ResourceDeletion
-
この修復戦略では、ノードオブジェクトではなく、ノード上の Pod と関連するボリュームアタッチメントが削除されます。このストラテジーは、ワークロードをより迅速に復元するのに役立ちます。
ResourceDeletion
は、デフォルトの修復戦略です。 NodeDeletion
- この修復戦略により、ノードオブジェクトが削除されます。
Self Node Remediation Operator は、戦略ごとに次の SelfNodeRemediationTemplateCR
を作成します。
-
ResourceDeletion
修復戦略が使用するself-node-remediation-resource-deletion-template
-
NodeDeletion
修復戦略が使用するself-node-remediation-node-deletion-template
SelfNodeRemediationTemplate
CR は以下の YAML ファイルのようになります。
apiVersion: self-node-remediation.medik8s.io/v1alpha1 kind: SelfNodeRemediationTemplate metadata: creationTimestamp: "2022-03-02T08:02:40Z" name: self-node-remediation-<remediation_object>-deletion-template 1 namespace: openshift-operators spec: template: spec: remediationStrategy: <remediation_strategy> 2
6.6.1.3. ウォッチドッグデバイスについて
ウォッチドッグデバイスは、次のいずれかになります。
- 電源が独立しているハードウェアデバイス
- 制御するホストと電源を共有するハードウェアデバイス
-
ソフトウェアまたは
softdog
に実装された仮想デバイス
ハードウェアウォッチドッグデバイスと softdog
デバイスには、それぞれ電子タイマーまたはソフトウェアタイマーがあります。これらのウォッチドッグデバイスは、エラー状態が検出されたときにマシンが安全な状態になるようにするために使用されます。クラスターは、ウォッチドッグタイマーを繰り返しリセットして、正常な状態にあることを証明する必要があります。このタイマーは、デッドロック、CPU の枯渇、ネットワークまたはディスクアクセスの喪失などの障害状態が原因で経過する可能性があります。タイマーが時間切れになると、ウォッチドッグデバイスは障害が発生したと見なし、デバイスがノードの強制リセットをトリガーします。
ハードウェアウォッチドッグデバイスは、softdog
デバイスよりも信頼性があります。
6.6.1.3.1. ウォッチドッグデバイスを使用した Self Node Remediation Operator の動作の理解
Self Node Remediation Operator は、存在するウォッチドッグデバイスに基づいて修復戦略を決定します。
ハードウェアウォッチドッグデバイスが設定されて使用可能である場合、Operator はそれを修復に使用します。ハードウェアウォッチドッグデバイスが設定されていない場合、Operator は修復のために softdog
デバイスを有効にして使用します。
システムまたは設定のどちらかで、いずれのウォッチドッグデバイスもサポートされていない場合、Operator はソフトウェアの再起動を使用してノードを修復します。
関連情報
6.6.2. Web コンソールを使用した Self Node Remediation Operator のインストール
OpenShift Container Platform Web コンソールを使用して、Self Node Remediation Operator をインストールできます。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
-
OpenShift Container Platform Web コンソールで、Operators
OperatorHub ページに移動します。 - 使用可能なオペレーターのリストから Self Node Remediation Operator を検索し、Install をクリックします。
-
Operator が
openshift-operators
namespace にインストールされるように、Installation mode と namespace のデフォルトの選択を維持します。 - Install をクリックします。
検証
インストールが正常に行われたことを確認するには、以下を実行します。
-
Operators
Installed Operators ページに移動します。 -
Operator が
openshift-operators
の namespace に設置されていることと、その状態がSucceeded
になっていることを確認してください。
Operator が正常にインストールされていない場合、以下を実行します。
-
Operators
Installed Operators ページに移動し、 Status
列でエラーまたは失敗の有無を確認します。 -
Workloads
Pod ページに移動し、問題を報告している self-node-remediation-controller-manager
プロジェクトの Pod のログを確認します。
6.6.3. 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) を作成します。Namespace
CR を定義し、YAML ファイルを保存します (例:self-node-remediation-namespace.yaml
)。apiVersion: v1 kind: Namespace metadata: name: self-node-remediation
Namespace
CR を作成するには、次のコマンドを実行します。$ oc create -f self-node-remediation-namespace.yaml
OperatorGroup
を作成します。OperatorGroup
CR を定義し、YAML ファイルを保存します (例:self-node-remediation-operator-group.yaml
)。apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: self-node-remediation-operator namespace: self-node-remediation
OperatorGroup
CR を作成するには、次のコマンドを実行します。$ oc create -f self-node-remediation-operator-group.yaml
Subscription
CR を作成します。Subscription
CR を定義し、YAML ファイルを保存します (例:self-node-remediation-subscription.yaml
)。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: self-node-remediation-operator namespace: self-node-remediation 1 spec: channel: stable installPlanApproval: Manual 2 name: self-node-remediation-operator source: redhat-operators sourceNamespace: openshift-marketplace package: self-node-remediation
- 1
- Self Node Remediation Operator をインストールする
Namespace
を指定します。セルフノード修復 Operator をopenshift-operators
namespace にインストールするには、Subscription
CR でopenshift-operators
を指定します。 - 2
- 指定したバージョンがカタログの新しいバージョンに置き換えられる場合に備えて、承認ストラテジーを Manual に設定します。これにより、新しいバージョンへの自動アップグレードが阻止され、最初の CSV のインストールが完了する前に手動での承認が必要となります。
Subscription
CR を作成するには、次のコマンドを実行します。$ oc create -f self-node-remediation-subscription.yaml
検証
CSV リソースを調べて、インストールが成功したことを確認します。
$ oc get csv -n self-node-remediation
出力例
NAME DISPLAY VERSION REPLACES PHASE self-node-remediation.v.0.4.0 Self Node Remediation Operator v.0.4.0 Succeeded
Self Node Remediation Operator が稼働していることを確認します。
$ oc get deploy -n self-node-remediation
出力例
NAME READY UP-TO-DATE AVAILABLE AGE self-node-remediation-controller-manager 1/1 1 1 28h
Self Node Remediation Operator が
SelfNodeRemediationConfig
CR を作成していることを確認します。$ oc get selfnoderemediationconfig -n self-node-remediation
出力例
NAME AGE self-node-remediation-config 28h
それぞれの自己ノードの修復 Pod がスケジュールされ、各ワーカーノードで実行されていることを確認します。
$ oc get daemonset -n self-node-remediation
出力例
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE self-node-remediation-ds 3 3 3 3 3 <none> 28h
注記このコマンドは、コントロールプレーンノードではサポートされていません。
6.6.4. Self Node Remediation Operator を使用するためのマシンヘルスチェックの設定
以下の手順を使用して、マシンヘルスチェックを Self Node Remediation Operator を修復プロバイダーとして使用するように設定します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
SelfNodeRemediationTemplate
CR を作成します。SelfNodeRemediationTemplate
CR を定義します。apiVersion: self-node-remediation.medik8s.io/v1alpha1 kind: SelfNodeRemediationTemplate metadata: namespace: openshift-machine-api name: selfnoderemediationtemplate-sample spec: template: spec: remediationStrategy: ResourceDeletion 1
- 1
- 修復ストラテジーを指定します。デフォルトのストラテジーは
ResourceDeletion
です。
SelfNodeRemediationTemplate
CR を作成するには、以下のコマンドを実行します。$ oc create -f <snr-name>.yaml
MachineHealthCheck
CR を作成し、SelfNodeRemediationTemplate
CR を参照するよう更新します。MachineHealthCheck
を定義または更新します。apiVersion: machine.openshift.io/v1beta1 kind: MachineHealthCheck metadata: name: machine-health-check namespace: openshift-machine-api spec: selector: matchLabels: machine.openshift.io/cluster-api-machine-role: "worker" machine.openshift.io/cluster-api-machine-type: "worker" unhealthyConditions: - type: "Ready" timeout: "300s" status: "False" - type: "Ready" timeout: "300s" status: "Unknown" maxUnhealthy: "40%" nodeStartupTimeout: "10m" remediationTemplate: 1 kind: SelfNodeRemediationTemplate apiVersion: self-node-remediation.medik8s.io/v1alpha1 name: selfnoderemediationtemplate-sample
- 1
- 修復テンプレートの詳細を指定します。
MachineHealthCheck
CR を作成するには、次のコマンドを実行します。$ oc create -f <file-name>.yaml
MachineHealthCheck
CR を更新するには、次のコマンドを実行します。$ oc apply -f <file-name>.yaml
6.6.5. Self Node Remediation Operator のトラブルシューティング
6.6.5.1. 一般的なトラブルシューティング
- 問題
- Self Node Remediation Operator の問題のトラブルシューティングが必要です。
- 解決方法
- Operator ログを確認してください。
6.6.5.2. デーモンセットの確認
- 問題
- Self Node Remediation Operator はインストールされていますが、デーモンセットはインストールされません。
- 解決方法
- エラーまたは警告がないか、オペレーターログを確認してください。
6.6.5.3. 失敗した修復
- 問題
- 不健康なノードは修正されませんでした。
- 解決方法
以下のコマンドを実行して、
SelfNodeRemediation
CR が作成されていることを確認します。$ oc get snr -A
MachineHealthCheck
コントローラーがノードが正常でない状態でSelfNodeRemediation
CR を作成しなかった場合、MachineHealthCheck
コントローラーのログを確認します。さらに、MachineHealthCheck
CR に、修復テンプレートを使用するために必要な仕様が含まれていることを確認してください。SelfNodeRemediation
CR が作成される場合、その名前が正常でないノードまたはマシンオブジェクトと一致することを確認します。
6.6.5.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 snrc <self-node-remediation-config> -n <namespace>
$ oc delete snrt <self-node-remediation-template> -n <namespace>
6.6.6. Self Node Remediation Operator に関するデータの収集
Self Node Remediation Operator に関するデバッグ情報を収集するには、must-gather
ツールを使用します。Self Node Remediation Operator の must-gather
イメージの詳細は、Gathering data about specific features を参照してください。
6.6.7. 関連情報
- Self Node Remediation Operator はネットワークが制限された環境でサポートされています。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
- クラスターからの Operator の削除