**このページの改善にご協力ください** 

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。

# EKS クラスター内のノードを自動的に修復する
<a name="node-repair"></a>

このトピックでは、EKS 自動ノード修復の動作と、要件を満たすように設定する方法について詳しく説明します。EKS 自動ノード修復は EKS Auto Mode でデフォルトで有効になっており、EKS マネージド型ノードグループと Karpenter で使用できます。

デフォルトの EKS 自動ノード修復アクションは、以下の表にまとめられており、EKS Auto Mode、EKS マネージド型ノードグループ、Karpenter の動作に適用されます。EKS Auto Mode または Karpenter を使用する場合、すべての `AcceleratedHardwareReady` 修復アクションは `Replace` であり、EKS マネージド型ノードグループのみが修復アクションとして `Reboot` をサポートします。

EKS ノードモニタリングエージェントによって検出されたノードのヘルス問題とその対応するノード修復アクションの詳細なリストについては、「[EKS ノードモニタリングエージェントのノードのヘルス問題を検出する](node-health-nma.md)」を参照してください。


| ノードの状態 | 説明 | 修復までの時間 | 修復アクション | 
| --- | --- | --- | --- | 
|  AcceleratedHardwareReady  |  AcceleratedHardwareReady は、ノードの高速ハードウェア (GPU、Neuron) が正しく機能しているかどうかを示します。  |  10m  |  置換または再起動  | 
|  ContainerRuntimeReady  |  ContainerRuntimeReady は、コンテナランタイム (containerd など) が正しく機能し、コンテナを実行できるかどうかを示します。  |  30m  |  置換  | 
|  DiskPressure  |  DiskPressure は、ノードにディスクプレッシャー (ディスク容量が少ない、または I/O が高い) が発生していることを示す標準の Kubernetes 条件です。  |  該当なし  |  なし  | 
|  KernelReady  |  KernelReady は、重大なエラー、パニック、またはリソースの枯渇が発生することなく、カーネルが正しく機能しているかどうかを示します。  |  30m  |  置換  | 
|  MemoryPressure  |  MemoryPressure は、ノードにメモリプレッシャー (使用可能なメモリが少ない) が発生していることを示す標準の Kubernetes 条件です。  |  該当なし  |  なし  | 
|  NetworkingReady  |  NetworkingReady は、ノードのネットワークスタック (インターフェイス、ルーティング、接続) が正しく機能しているかどうかを示します。  |  30m  |  置換  | 
|  StorageReady  |  StorageReady は、ノードのストレージサブシステム (ディスク、ファイルシステム、I/O) が正しく機能しているかどうかを示します。  |  30m  |  置換  | 
|  Ready  |  Ready は、ノードが正常でポッドを受け入れる準備ができていることを示す標準の Kubernetes 条件です。  |  30m  |  置換  | 

EKS 自動ノード修復アクションは、以下のシナリオではデフォルトで無効になっています。進行中のノード修復アクションは、各シナリオで続行されます。これらのデフォルト設定を上書きする方法については、「[自動ノード修復を設定する](#configure-node-repair)」を参照してください。

 **EKS マネージド型ノードグループ** 
+ ノードグループに 5 つを超えるノードがあり、そのうち 20% を超えるノードに異常があります。
+ クラスターのゾーンシフトは、Application Recovery Controller (ARC) を介してトリガーされます。

 **EKS Auto Mode と Karpenter** 
+ NodePool 内のノードのうち、20% を超えるノードに異常があります。
+ スタンドアロン NodeClaims の場合、クラスター内のノードの 20% に異常があります。

## 自動ノード修復を設定する
<a name="configure-node-repair"></a>

EKS Auto Mode を使用する場合、自動ノード修復を設定することはできません。自動ノード修復は常に Karpenter と同じデフォルト設定で有効になります。

### Karpenter
<a name="configure-node-repair-karpenter"></a>

Karpenter で自動ノード修復を使用するには、機能ゲート `NodeRepair=true` を有効にします。機能ゲートは、Karpenter デプロイの `--feature-gates` CLI オプションまたは `FEATURE_GATES` 環境変数を使用して有効にできます。詳細については、[Karpenter](https://karpenter.sh/docs/concepts/disruption/#node-auto-repair) のドキュメントを参照してください。

### マネージドノードグループ
<a name="configure-node-repair-mng"></a>

新しい EKS マネージド型ノードグループを作成するとき、または既存の EKS マネージド型ノードグループを更新することで、自動ノード修復を有効にできます。
+  **Amazon EKS コンソール** – マネージド型ノードグループの **[ノード自動修復を有効にする]** チェックボックスを選択します。詳細については、「[クラスターのマネージドノードグループを作成する](create-managed-node-group.md)」を参照してください。
+  **AWS CLI** – `--node-repair-config enabled=true` を [https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html](https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html) または [https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html](https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html) コマンドに追加します。
+  **eksctl** – `managedNodeGroups.nodeRepairConfig.enabled: true` を設定します。[eksctl GitHub](https://github.com/eksctl-io/eksctl/blob/main/examples/44-node-repair.yaml) の例を参照してください。

EKS マネージド型ノードグループを使用する場合、以下の設定でノード自動修復の動作を制御できます。

ノード自動修復がいつアクションを停止するかを制御するには、ノードグループ内の異常のあるノードの数に基づいてしきい値を設定します。絶対数またはパーセンテージのいずれかを設定します。両方を設定することはできません。


| 設定 | 説明 | 
| --- | --- | 
|   `maxUnhealthyNodeThresholdCount`   |  ノード自動修復が停止する異常ノードの絶対数。これを使用して、修復の範囲を制限します。  | 
|   `maxUnhealthyNodeThresholdPercentage`   |  ノード自動修復が停止する異常ノードの割合 (0～100)。  | 

同時に修復するノードの数を制御するには、修復並列処理を設定できます。異常のあるノードしきい値と同様に、絶対数またはパーセンテージのいずれかを設定します。両方を設定することはできません。


| 設定 | 説明 | 
| --- | --- | 
|   `maxParallelNodesRepairedCount`   |  同時に修復するノードの最大数。  | 
|   `maxParallelNodesRepairedPercentage`   |  同時に修復する異常ノードの最大パーセンテージ (0～100)。  | 

`nodeRepairConfigOverrides` では、特定の条件に合わせて修復動作をカスタマイズできます。これは、さまざまな問題タイプに対して異なる修復アクションまたは待機時間が必要な場合に使用します。

上書きにはそれぞれ、以下のすべてのフィールドが必要です。


| フィールド | 説明 | 
| --- | --- | 
|   `nodeMonitoringCondition`   |  ノードモニタリングエージェントによって報告されたノードの状態タイプ。例えば、`AcceleratedHardwareReady`、`NetworkingReady`、`StorageReady`、`KernelReady` などです。  | 
|   `nodeUnhealthyReason`   |  異常状態の特定の理由コード。例: `NvidiaXID31Error`、`IPAMDNotRunning`。  | 
|   `minRepairWaitTimeMins`   |  ノードが修復対象となるまでに、その状態が継続している必要がある最小時間 (分単位)。これは、一時的な問題のためにノードを修復しないようにする場合に使用します。  | 
|   `repairAction`   |  条件が満たされたときに実行するアクション。有効な値: `Replace` (ノードを終了して置き換える)、`Reboot` (ノードを再起動する)、または `NoAction` (修復アクションなし)。  | 

以下の AWS CLI の例では、カスタム修復設定を使用してノードグループを作成します。

```
aws eks create-nodegroup \
  --cluster-name my-cluster \
  --nodegroup-name my-nodegroup \
  --node-role arn:aws:iam::111122223333:role/NodeRole \
  --subnets subnet-0123456789abcdef0 \
  --node-repair-config '{
    "enabled": true,
    "maxUnhealthyNodeThresholdPercentage": 10,
    "maxParallelNodesRepairedCount": 3,
    "nodeRepairConfigOverrides": [
      {
        "nodeMonitoringCondition": "AcceleratedHardwareReady",
        "nodeUnhealthyReason": "NvidiaXID64Error",
        "minRepairWaitTimeMins": 5,
        "repairAction": "Replace"
      },
      {
        "nodeMonitoringCondition": "AcceleratedHardwareReady",
        "nodeUnhealthyReason": "NvidiaXID31Error",
        "minRepairWaitTimeMins": 15,
        "repairAction": "NoAction"
      }
    ]
  }'
```

この設定では、以下のことが行われます。
+ ノード自動修復を有効にする
+ 10% を超えるノードに異常がある場合に修復アクションを停止する
+ 一度に最大 3 つのノードを修復する
+ XID 64 エラー (GPU メモリの再マッピングの失敗) を上書きして、5 分後にノードを置き換える。デフォルトでは 10 分後に再起動します。
+ XID 31 エラー (GPU メモリページの障害) を上書きして、アクションを実行しない。デフォルトでは 10 分後に再起動します。