2.5. Self Node Remediation Operator の設定


Self Node Remediation Operator は、SelfNodeRemediationConfig CR と SelfNodeRemediationTemplate カスタムリソース定義 (CRD) を作成します。

注記

特定のノードで予期しない再起動が発生しないようにするために、Node Maintenance Operator はノードをメンテナンスモードに設定し、特定のノードで SNR daemonset が実行されないようにするノードセレクターを自動的に追加します。

2.5.1. Self Node Remediation Operator 設定について

Self Node Remediation Operator は、self-node-remediation-config という名前の SelfNodeRemediationConfig CR を作成します。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-workload-availability
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

  hostPort: 30001 
11

  customDsTolerations: 
12

      - effect: NoSchedule
        key: node-role.kubernetes.io.infra
        operator: Equal
        value: "value1"
        tolerationSeconds: 3600
1
正常でないノードで実行されていて影響を受けるワークロードを回復する前に Operator が待機するオプションの期間を指定します。障害が発生したノードで実行中の代替 Pod を開始すると、データの破損や 1 回実行セマンティクスの違反が生じる可能性があります。Operator は、ApiServerTimeoutApiCheckIntervalMaxApiErrorThresholdPeerDialTimeout、および PeerRequestTimeout フィールドの値、およびウォッチドッグタイムアウトと修復時のクラスターサイズを使用して、最小期間を計算します。最小期間の計算をチェックするには、マネージャー Pod のログを表示し、calculated minimum time in seconds への参照を確認します。

最小期間よりも短い値を指定した場合、Operator は最小期間を使用します。ただし、期間をこの最小値よりも大きい値に増やす場合は、safeTimeToAssumeNodeRebootedSeconds を最小期間よりも大きい値に設定できます。

2
ノード内のウォッチドッグデバイスのファイルパスを指定します。ウォッチドッグデバイスへの誤ったパスを入力すると、Self Node Remediation Operator がソフトドッグデバイスのパスを自動的に検出します。

ウォッチドッグデバイスが使用できない場合、SelfNodeRemediationConfig CR はソフトウェアの再起動を使用します。

3
正常でないノードのソフトウェア再起動を有効にするかどうかを指定します。デフォルトでは、isSoftwareRebootEnabled の値は true に設定されています。ソフトウェアの再起動を無効にするには、パラメーター値を false に設定します。
4
各 API サーバーとの接続を確認するためのタイムアウト期間を指定します。この期間が経過すると、Operator は修復を開始します。タイムアウト期間は 10 ミリ秒以上である必要があります。
5
各 API サーバーとの接続を確認する頻度を指定します。タイムアウト期間は 1 秒以上である必要があります。
6
しきい値を指定します。このしきい値に達した後、ノードはピアへの接続を開始します。しきい値は 1 秒以上である必要があります。
7
ピアが API サーバーに接続するためのタイムアウトの期間を指定します。タイムアウト期間は 10 ミリ秒以上である必要があります。
8
ピアで接続を確立するためのタイムアウトの期間を指定します。タイムアウト期間は 10 ミリ秒以上である必要があります。
9
ピアから応答を取得するためのタイムアウトの期間を指定します。タイムアウト期間は 10 ミリ秒以上である必要があります。
10
IP アドレスなどのピア情報を更新する頻度を指定します。タイムアウト期間は 10 秒以上である必要があります。
11
任意の値を指定して、Self Node Remediation エージェントが内部通信に使用するポートを変更します。値は 0 より大きくなければなりません。デフォルト値はポート 30001 です。
12
さまざまなタイプのノードの修復をサポートするために、DaemonSet で実行されているカスタム Self Node Remediation エージェントを指定します。次のフィールドを設定できます。
  • effect : effect は一致するテイント効果を示します。このフィールドが空の場合、すべてのテイント効果が一致します。指定する場合、使用な可能な値は NoSchedulePreferNoSchedule、および NoExecute です。
  • key: キーは、toleration が適用される taint キーです。このフィールドが空の場合、すべてのテイントキーが一致します。key が空の場合、operator フィールドは Exists である必要があります。この組み合わせは、すべての値とすべてのキーが一致することを意味します。
  • operator: Operator はキーと値の関係を表します。有効な Operator は Exists および Equal です。デフォルトは Equal です。Exists は、値のワイルドカードと同等であるため、Pod は特定のカテゴリーのすべてのテイントを許容できます。
  • value: toleration が一致する taint の値です。Operator が Exists の場合、値は空である必要があります。それ以外の場合は、通常の文字列になります。
  • tolerationSeconds: toleration (NoExecute が有効である必要があり、そうでない場合はこのフィールドは無視されます) が taint を許容する期間を表します。デフォルトでは設定されていないため、テイントを永久に許容します (退避されません)。ゼロ値と負の値は、システムによって 0 (すぐに退避) として扱われます。
  • カスタム toleration により、toleration を Self Node Remediation エージェント Pod に追加できます。詳細は、toleration を使用した OpenShift Logging Pod の配置の制御 を参照してください。
注記
  • Self Node Remediation Operator は、デプロイメント namespace にデフォルトで CR を作成します。
  • CR の名前は self-node-remediation-config にする必要があります。
  • SelfNodeRemediationConfig CR は 1 つだけ使用できます。
  • SelfNodeRemediationConfig CR を削除すると、Self Node Remediation が無効になります。
  • Self Node Remediation Operator によって作成された 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-workload-availability' {"selfnoderemediationconfig":
"openshift-workload-availability/selfnoderemediationconfig-copy"}

2.5.2. 自己ノード修復テンプレートの設定を理解する

Self Node Remediation Operator は、SelfNodeRemediationTemplate カスタムリソース定義 (CRD) も作成します。この CRD は、ワークロードをより速く回復することを目的としたノードの修復ストラテジーを定義します。次の修復ストラテジーが利用できます。

Automatic
この修復ストラテジーでは、Self Node Remediation Operator がクラスターに最適な修復戦略を決定できるようにすることで、修復プロセスを簡素化します。このストラテジーは、OutOfServiceTaint ストラテジーがクラスターで利用できるかどうかを確認します。OutOfServiceTaint ストラテジーが利用可能な場合、Operator は OutOfServiceTaint ストラテジーを選択します。OutOfServiceTaint ストラテジーが利用できない場合、Operator は ResourceDeletion ストラテジーを選択します。Automatic は、デフォルトの修復ストラテジーです。
ResourceDeletion
この修復ストラテジーは、ノードオブジェクトではなく、ノード上の Pod を削除します。
OutOfServiceTaint
この修復戦略により、ノードオブジェクトではなく、ノード上の Pod および関連するボリュームアタッチメントが暗黙的に削除されます。これは、ノードに OutOfServiceTaint ストラテジーを配置することによって実現されます。このストラテジーは、OpenShift Container Platform バージョン 4.13 以降のテクノロジープレビューでサポートされており、OpenShift Container Platform バージョン 4.15 以降の一般提供ではサポートされています。

Self Node Remediation Operator は、Automatic 修復ストラテジーが使用する self-node-remediation-automatic-strategy-template ストラテジーの SelfNodeRemediationTemplate CR を作成します。

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-workload-availability
spec:
  template:
    spec:
      remediationStrategy: <remediation_strategy>  
2
1
修復ストラテジーに基づいて修復テンプレートのタイプを指定します。<remediation_object>resource または node のいずれかに置き換えます (例: self-node-remediation-resource-deletion-template)。
2
修復ストラテジーを指定します。デフォルトの修復ストラテジーは Automatic です。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る