**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# ノードのヘルス問題を検出し、自動ノード修復を有効にする
ノードのヘルスとは、ワークロードを効果的に実行するための Kubernetes ノードの運用ステータスと機能を指します。正常なノードは、期待されるネットワーク接続を維持し、十分なコンピューティングリソースとストレージリソースを持ち、中断することなくワークロードを正常に実行できます。
EKS クラスター内のノードを正常な状態に維持するために、EKS には*ノードモニタリングエージェント*と*自動ノード修復*の機能があります。これらの機能は、EKS Auto Mode コンピューティングで自動的に有効になります。EKS マネージド型ノードグループと Karpenter で自動ノード修復を使用でき、AWS Fargate を除く任意の EKS コンピューティングタイプで EKS ノードモニタリングエージェントを使用することもできます。EKS ノードモニタリングエージェントと自動ノード修復は、一緒に使用すると最も効果的ですが、EKS クラスターで個別に使用することもできます。
**重要**
*ノードモニタリングエージェント*と*ノード自動修復*を使用できるのは、Linux のみです。Windows では使用できません。
## ノードモニタリングエージェント
EKS ノードモニタリングエージェントはノードログを読み取り、ヘルスの問題を検出します。ログを解析して障害を検出し、ノードのヘルスステータスに関するステータス情報を表示します。検出された問題のカテゴリごとに、エージェントはワーカーノード専用の `NodeCondition` を適用します。EKS ノードモニタリングエージェントによって検出されたノードのヘルス問題の詳細については、「[EKS ノードモニタリングエージェントのノードのヘルス問題を検出する](node-health-nma.md)」を参照してください。
EKS Auto Mode コンピューティングには、ノードモニタリングエージェントが備わっています。他の EKS コンピューティングタイプでは、ノードモニタリングエージェントを EKS アドオンとして追加することも、Helm などの Kubernetes ツールで管理することもできます。詳細については、「[ノードモニタリングエージェントを設定する](node-health-nma.md#node-monitoring-agent-configure)」を参照してください。
EKS ノードモニタリングエージェントでは、以下のカテゴリのノードのヘルス問題がノード条件として表示されます。`Ready`、`DiskPressure`、`MemoryPressure` は、EKS ノードモニタリングエージェントがない場合でも表示される標準の Kubernetes ノード条件です。
| ノードの状態 | 説明 |
| --- | --- |
| AcceleratedHardwareReady | AcceleratedHardwareReady は、ノードの高速ハードウェア (GPU、Neuron) が正しく機能しているかどうかを示します。 |
| ContainerRuntimeReady | ContainerRuntimeReady は、コンテナランタイム (containerd など) が正しく機能し、コンテナを実行できるかどうかを示します。 |
| DiskPressure | DiskPressure は、ノードにディスクプレッシャー (ディスク容量が少ない、または I/O が高い) が発生していることを示す標準の Kubernetes 条件です。 |
| KernelReady | KernelReady は、重大なエラー、パニック、またはリソースの枯渇が発生することなく、カーネルが正しく機能しているかどうかを示します。 |
| MemoryPressure | MemoryPressure は、ノードにメモリプレッシャー (使用可能なメモリが少ない) が発生していることを示す標準の Kubernetes 条件です。 |
| NetworkingReady | NetworkingReady は、ノードのネットワークスタック (インターフェイス、ルーティング、接続) が正しく機能しているかどうかを示します。 |
| StorageReady | StorageReady は、ノードのストレージサブシステム (ディスク、ファイルシステム、I/O) が正しく機能しているかどうかを示します。 |
| Ready | Ready は、ノードが正常でポッドを受け入れる準備ができていることを示す標準の Kubernetes 条件です。 |
## 自動ノード修復
EKS 自動ノード修復は、ノードのヘルスを継続的にモニタリングし、検出された問題に対応し、可能な場合はノードを置き換えるか再起動します。これにより、手動介入を最小限に抑えながらクラスターの信頼性を向上させ、アプリケーションのダウンタイムを短縮できます。
単体では、EKS 自動ノード修復は、kubelet の `Ready` 条件、手動で削除されたノードオブジェクト、クラスターに参加できない EKS マネージド型ノードグループインスタンスに対応します。ノードモニタリングエージェントをインストールした状態で EKS 自動ノード修復を有効にすると、EKS 自動ノード修復は次の追加のノード条件に対応します: `AcceleratedHardwareReady`、`ContainerRuntimeReady`、`KernelReady`、`NetworkingReady`、`StorageReady`。
EKS 自動ノード修復は、標準の Kubernetes `DiskPressure`、`MemoryPressure`、または `PIDPressure` ノード条件には対応しません。これらの条件は、多くの場合、ノードレベルの障害ではなく、アプリケーションの動作、ワークロード設定、またはリソース制限の問題を示しているため、適切なデフォルトの修復アクションを決定することは困難です。これらのシナリオでは、ワークロードは Kubernetes [ノードのプレッシャーエビクション動作](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction)の影響を受けます。
EKS 自動ノード修復の詳細については、「[EKS クラスター内のノードを自動的に修復する](node-repair.md)」を参照してください。
**Topics**
# EKS ノードモニタリングエージェントのノードのヘルス問題を検出する
このトピックでは、EKS ノードモニタリングエージェントによって検出されたノードのヘルス問題、それらの問題がノード条件またはイベントとしてどのように表示されるか、ノードモニタリングエージェントを設定する方法について説明します。
EKS ノードモニタリングエージェントは、EKS 自動ノード修復の有無にかかわらず使用できます。EKS 自動ノード修復の詳細については、「[EKS クラスター内のノードを自動的に修復する](node-repair.md)」を参照してください。
EKS ノードモニタリングエージェントのソースコードは、GitHub の [aws/eks-node-monitoring-agent](https://github.com/aws/eks-node-monitoring-agent) リポジトリに公開されています。
## ノードのヘルスの問題
次の表は、ノードモニタリングエージェントが検出できるノードのヘルス問題を示しています。次の 2 種類の問題があります。
+ 症状 – インスタンスの置き換えや再起動などの修復アクションを必要とするターミナルの問題。自動修復が有効になっている場合、Amazon EKS はノードの置換または再起動として修復アクションを実行します。詳細については、「[ノードの状態](learn-status-conditions.md#status-node-conditions)」を参照してください。
+ イベント – 一時的な問題または最適ではないノード設定。自動修復アクションは行われません。詳細については、「[ノードイベント](learn-status-conditions.md#status-node-events)」を参照してください。
## AcceleratedHardware ノードのヘルス問題
次の表に記載されている、緊急度が「条件」である問題について、モニタリング条件は `AcceleratedHardwareReady` です。以下の表のイベントと条件は、NVIDIA および Neuron 関連のノードのヘルス問題に関するものです。
| 名前 | 緊急度 | 説明 | 修復アクション |
| --- | --- | --- | --- |
| DCGMDiagnosticFailure | 条件 | DCGM アクティブ診断テストスイートからのテストケースが失敗しました。 | なし |
| DCGMError | 条件 | DCGM ホストプロセスへの接続を失ったか、確立できませんでした。 | なし |
| DCGMFieldError[Code] | イベント | DCGM が、フィールド識別子を介して GPU の劣化を検出しました。 | なし |
| DCGMHealthCode[Code] | イベント | DCGM ヘルスチェックが、致命的ではない方法で失敗しました。 | なし |
| DCGMHealthCode[Code] | 条件 | DCGM ヘルスチェックが、致命的な方法で失敗しました。 | なし |
| NeuronDMAError | 条件 | DMA エンジンで回復不可能なエラーが発生しました。 | 置換 |
| NeuronHBMUncorrectableError | 条件 | HBM で修正不可能なエラーが発生し、誤った結果が生成されました。 | 置換 |
| NeuronNCUncorrectableError | 条件 | Neuron Core の修正不可能なメモリエラーが検出されました。 | 置換 |
| NeuronSRAMUncorrectableError | 条件 | オンチップ SRAM でパリティエラーが発生し、誤った結果が生成されました。 | 置換 |
| NvidiaDeviceCountMismatch | イベント | NVML で認識される GPU の数が、ファイルシステムの NVIDIA デバイス数と一致していません。 | なし |
| NvidiaDoubleBitError | 条件 | GPU ドライバーによってダブルビットエラーが生成されました。 | 置換 |
| NvidiaNCCLError | イベント | NVIDIA Collective Communications ライブラリ (`libnccl`) でセグメンテーション違反が発生しました。 | なし |
| NvidiaNVLinkError | 条件 | NVLink エラーが GPU ドライバーによって報告されました。 | 置換 |
| NvidiaPCIeError | イベント | 送信エラーから回復するために PCIe リプレイがトリガーされました。 | なし |
| NvidiaPageRetirement | イベント | GPU ドライバーがメモリページを廃止としてマークしました。これは、1 つのダブルビットエラーが起こった場合、または同じアドレスで 2 つのシングルビットエラーが起こった場合に発生する可能性があります。 | なし |
| NvidiaPowerError | イベント | GPU の電力使用率が許容しきい値を超えました。 | なし |
| NvidiaThermalError | イベント | GPU の熱ステータスが許容しきい値を超えました。 | なし |
| NvidiaXID[Code]Error | 条件 | 重大な GPU エラーが発生しました。 | 置換または再起動 |
| NvidiaXID[Code]Warning | イベント | 重要ではない GPU エラーが発生しました。 | なし |
## NVIDIA XID エラーコード
ノードモニタリングエージェントは、GPU カーネルログから NVIDIA XID エラーを検出します。XID エラーは 2 つのカテゴリに分類されます。
+ **既知の XID コード** – ノード条件 (`AcceleratedHardwareReady=False`) を設定し、有効になっている場合に自動修復をトリガーする重大なエラー。理由コードの形式は `NvidiaXID[Code]Error` です。EKS ノードモニタリングエージェントが検出する既知の XID コードは、修復アクションを必要とする NVIDIA XID コードの完全なリストを表していない場合があります。
+ **不明な XID コード** – Kubernetes イベントとしてのみログに記録されます。これらは自動修復をトリガーしません。理由コードの形式は `NvidiaXID[Code]Warning` です。不明な XID エラーを調査するには、`dmesg | grep -i nvrm` でカーネルログを確認します。
XID エラーの詳細については、「*NVIDIA GPU のデプロイおよび管理ドキュメント*」の「[Xid エラー](https://docs.nvidia.com/deploy/xid-errors/index.html#topic_5_1)」を参照してください。個々の XID メッセージの詳細については、「*NVIDIA GPU Deployment and Management Documentation*」の「[Understanding Xid Messages](https://docs.nvidia.com/deploy/gpu-debug-guidelines/index.html#understanding-xid-messages)」を参照してください。
以下の表に、既知の XID コード、その意味、および有効になっている場合のデフォルトのノード修復アクションを示します。
| XID コード | 説明 | 修復アクション |
| --- | --- | --- |
| 13 | グラフィックエンジン例外 – GPU グラフィックエンジンエラーが発生しました。通常、ソフトウェアの問題やドライバーのバグが原因です。 | リブート |
| 31 | GPU メモリページの障害 – アプリケーションがマッピングされていない、またはアクセスできない GPU メモリにアクセスしようとしました。 | リブート |
| 48 | ダブルビット ECC エラー – GPU メモリで修正不可能なダブルビットエラーが発生しました。これはハードウェアの劣化の可能性を示しています。 | リブート |
| 63 | GPU メモリの再マッピングイベント – 検出されたエラーにより、GPU ドライバーが GPU メモリの一部を再マッピングしました。これは多くの場合、回復可能です。 | リブート |
| 64 | GPU メモリの再マッピングの失敗 – GPU が欠陥メモリを再マッピングできませんでした。これはハードウェアの問題を示しています。 | リブート |
| 74 | NVLink エラー – GPU 間の高速 NVLink 相互接続でエラーが発生しました。 | 置換 |
| 79 | GPU がバスから切断された – GPU は PCIe 経由でアクセスできなくなりました。これは通常、ハードウェアの障害や電源の問題を示しています。 | 置換 |
| 94 | 限定的なメモリエラー – メモリエラーが発生しましたが、その影響は限定的で、他のアプリケーションには影響しませんでした。 | リブート |
| 95 | 非限定的なメモリエラー – メモリエラーが発生し、他のアプリケーションやシステムメモリに影響を与えた可能性があります。 | リブート |
| 119 | GSP RPC タイムアウト – GPU システムプロセッサとの通信がタイムアウトしました。これは、ファームウェアの問題が原因である可能性があります。 | 置換 |
| 120 | GSP エラー – GPU システムプロセッサでエラーが発生しました。 | 置換 |
| 121 | C2C エラー – チップ間相互接続 (マルチダイ GPU で使用) でエラーが発生しました。 | 置換 |
| 140 | ECC 未回復エラー – ECC エラーが検出されず、データが破損した可能性があります。 | 置換 |
GPU ヘルスに関連する現在のノード条件を表示するには、以下のコマンドを実行します。
```
kubectl get nodes -o custom-columns='NAME:.metadata.name,ACCELERATOR_READY:.status.conditions[?(@.type=="AcceleratedHardwareReady")].status,REASON:.status.conditions[?(@.type=="AcceleratedHardwareReady")].reason'
```
クラスターで XID 関連のイベントを表示するには、以下のいずれかのコマンドを実行します。
```
kubectl get events | grep -i "NvidiaXID"
```
## ContainerRuntime ノードのヘルスの問題
次の表に記載されている、緊急度が「条件」である問題について、モニタリング条件は `ContainerRuntimeReady` です。
| 名前 | 緊急度 | 説明 | 修復アクション |
| --- | --- | --- | --- |
| ContainerRuntimeFailed | イベント | コンテナランタイムはコンテナの作成に失敗しました。繰り返し発生する場合は、報告された問題に関連している可能性があります。 | なし |
| DeprecatedContainerdConfiguration | イベント | 廃止されたイメージマニフェストバージョン 2、スキーマ 1 を使用するコンテナイメージが、最近 `containerd` を介してノードにプルされました。 | なし |
| KubeletFailed | イベント | kubelet が失敗状態になりました。 | なし |
| LivenessProbeFailures | イベント | ライブネスプローブの障害が検出されました。アプリケーションコードの問題や、繰り返し発生する場合はタイムアウト値が不十分である可能性を示しています。 | なし |
| PodStuckTerminating | 条件 | ポッドが終了しているか、または長時間停止していました。これは、ポッドの状態の進行を妨げる CRI エラーが原因で発生する可能性があります。 | 置換 |
| ReadinessProbeFailures | イベント | レディネスプローブの障害が検出されました。アプリケーションコードの問題や、繰り返し発生する場合はタイムアウト値が不十分である可能性を示しています。 | なし |
| [Name]RepeatedRestart | イベント | systemd ユニットが頻繁に再起動しています。 | なし |
| ServiceFailedToStart | イベント | systemd ユニットの起動に失敗しました。 | なし |
## カーネルノードのヘルスの問題
次の表に記載されている、緊急度が「条件」である問題について、モニタリング条件は `KernelReady` です。
| 名前 | 緊急度 | 説明 | 修復アクション |
| --- | --- | --- | --- |
| AppBlocked | イベント | タスクが長時間スケジュールからブロックされており、通常は入力または出力がブロックされていることが原因で発生します。 | なし |
| AppCrash | イベント | ノード上のアプリケーションがクラッシュしました。 | なし |
| ApproachingKernelPidMax | イベント | プロセスの数が、現在の `kernel.pid_max` 設定で使用可能な PID の最大数に近づいています。最大数に到達すると、これ以上プロセスを起動することはできません。 | なし |
| ApproachingMaxOpenFiles | イベント | 開いているファイルの数は、現在のカーネル設定で可能な開いているファイルの最大数に近づいています。最大数に到達すると、新しいファイルを開くことができなくなります。 | なし |
| ConntrackExceededKernel | イベント | 接続追跡がカーネルの最大数を超え、新しい接続を確立できなかったため、パケットロスが発生する可能性があります。 | なし |
| ExcessiveZombieProcesses | イベント | 完全に再要求できないプロセスが大量に蓄積されています。これはアプリケーションの問題を示しており、システムプロセスの制限に達する可能性があります。 | なし |
| ForkFailedOutOfPIDs | 条件 | フォークまたは実行の呼び出しが失敗したのは、システムがプロセス ID またはメモリ不足であるためです。これは、ゾンビプロセスまたは物理メモリの枯渇が原因である可能性があります。 | 置換 |
| KernelBug | イベント | CPU またはメモリの使用率が高いノードが原因でイベント処理が遅れることがありますが、カーネルのバグが Linux カーネル自体によって検出および報告されました。 | なし |
| LargeEnvironment | イベント | このプロセスの環境変数の数は予想よりも多く、`enableServiceLinks` が true に設定されている多くのサービスが原因で発生する可能性があります。このため、パフォーマンスの問題が発生する可能性があります。 | なし |
| RapidCron | イベント | このノードでは、cron ジョブが 5 分間隔よりも速く実行されています。このため、ジョブが大量のリソースを消費すると、パフォーマンスに影響が出る可能性があります。 | なし |
| SoftLockup | イベント | CPU が一定時間停止しました。 | なし |
## ネットワークノードのヘルスの問題
次の表に記載されている、緊急度が「条件」である問題について、モニタリング条件は `NetworkingReady` です。
| 名前 | 緊急度 | 説明 | 修復アクション |
| --- | --- | --- | --- |
| BandwidthInExceeded | イベント | インバウンド集計帯域幅がインスタンスの最大値を超えたため、パケットはキューに入れられたか、ドロップされました。 | なし |
| BandwidthOutExceeded | イベント | アウトバウンド集計帯域幅がインスタンスの最大値を超えたため、パケットはキューに入れられたか、ドロップされました。 | なし |
| ConntrackExceeded | イベント | 接続追跡がインスタンスの最大数を超え、新しい接続を確立できなかったため、パケットロスが発生する可能性があります。 | なし |
| EFAErrorMetric | イベント | EFA ドライバーメトリクスは、パフォーマンスが低下しているインターフェイスがあることを示しています。 | なし |
| IPAMDInconsistentState | イベント | ディスク上の IPAMD チェックポイントの状態が、コンテナランタイム内の IP を反映していません。 | なし |
| IPAMDNoIPs | イベント | IPAMD が IP アドレスから外れています。 | なし |
| IPAMDNotReady | 条件 | IPAMD が API サーバーに接続できません。 | 置換 |
| IPAMDNotRunning | 条件 | Amazon VPC CNI プロセスは実行中であることが確認されませんでした。 | 置換 |
| IPAMDRepeatedlyRestart | イベント | IPAMD サービスで複数の再起動が発生しました。 | なし |
| InterfaceNotRunning | 条件 | このインターフェイスは実行されていないか、ネットワークの問題があります。 | 置換 |
| InterfaceNotUp | 条件 | このインターフェイスは起動していないか、ネットワークの問題があります。 | 置換 |
| KubeProxyNotReady | イベント | Kube-proxy がリソースの監視または一覧表示に失敗しました。 | なし |
| LinkLocalExceeded | イベント | ローカルプロキシサービスへのトラフィックの PPS がネットワークインターフェイスの最大値を超えたため、パケットがドロップされました。 | なし |
| MACAddressPolicyMisconfigured | イベント | systemd-networkd のリンク設定で、`MACAddressPolicy` の値が正しくありません。 | なし |
| MissingDefaultRoutes | イベント | デフォルトのルートルールが見つかりません。 | なし |
| MissingIPRoutes | イベント | Pod IP のルートがありません。 | なし |
| MissingIPRules | イベント | Pod IP のルールがありません。 | なし |
| MissingLoopbackInterface | 条件 | このインスタンスには、ループバックインターフェイスがないため、ローカル接続によってはサービスの不具合が発生します。 | 置換 |
| NetworkSysctl | イベント | このノードのネットワーク `sysctl` 設定が正しくない可能性があります。 | なし |
| PPSExceeded | イベント | 双方向 PPS がインスタンスの最大値を超えたため、パケットはキューに入れられたか、ドロップされました。 | なし |
| PortConflict | イベント | ポッドが hostPort を使用する場合、ホストの既にバインドされているポートを上書きするように `iptables` ルールを書き込みできるため、API サーバーが `kubelet` にアクセスできなくなる可能性があります。 | なし |
| UnexpectedRejectRule | イベント | `iptables` で予期しない `REJECT` または `DROP` ルールが検出されたため、予想されたトラフィックがブロックされる可能性があります。 | なし |
## ストレージノードのヘルスの問題
次の表に記載されている、緊急度が「条件」である問題について、モニタリング条件は `StorageReady` です。
| 名前 | 緊急度 | 説明 | 修復アクション |
| --- | --- | --- | --- |
| EBSInstanceIOPSExceeded | イベント | インスタンスの最大 IOPS を超えました。 | なし |
| EBSInstanceThroughputExceeded | イベント | インスタンスの最大スループットを超えました。 | なし |
| EBSVolumeIOPSExceeded | イベント | 特定の EBS ボリュームに対する最大 IOPS を超えました。 | なし |
| EBSVolumeThroughputExceeded | イベント | 特定の Amazon EBS ボリュームに対する最大スループットを超えました。 | なし |
| EtcHostsMountFailed | イベント | `kubelet-container` オペレーション中にユーザーデータを `/var/lib/kubelet/pods` に再マウントしたため、kubelet が生成した `/etc/hosts` のマウントに失敗しました。 | なし |
| IODelays | イベント | 入力または出力の遅延がプロセスで検出されました。過剰な場合は入力/出力プロビジョニングが不十分である可能性があります。 | なし |
| KubeletDiskUsageSlow | イベント | `kubelet` は、ファイルシステムにアクセスしようとしているときにディスクの使用が遅いことを報告しています。これは、ディスクの入出力が不十分である、またはファイルシステムに問題がある可能性を示しています。 | なし |
| XFSSmallAverageClusterSize | イベント | XFS 平均クラスターサイズが小さいことは、空き領域が過度に断片化されていることを示しています。このため、inode や空き領域が使用可能であっても、ファイルを作成できない場合があります。 | なし |
## ノードモニタリングエージェントを設定する
EKS ノードモニタリングエージェントは DaemonSet としてデプロイされます。EKS アドオンとしてデプロイする場合、以下の設定値を使用してインストールをカスタマイズできます。デフォルト設定については、EKS ノードモニタリングエージェントの [Helm チャート](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml)を参照してください。
| 設定オプション | 説明 |
| --- | --- |
| `monitoringAgent.resources.requests.cpu` | モニタリングエージェントの CPU リソースリクエスト。 |
| `monitoringAgent.resources.requests.memory` | モニタリングエージェントのメモリリソースリクエスト。 |
| `monitoringAgent.resources.limits.cpu` | モニタリングエージェントの CPU リソース制限。 |
| `monitoringAgent.resources.limits.memory` | モニタリングエージェントのメモリリソース制限。 |
| `monitoringAgent.tolerations` | テイントが適用されたノードでモニタリングエージェントをスケジュールするための許容範囲。 |
| `monitoringAgent.additionalArgs` | モニタリングエージェントに渡す追加のコマンドライン引数。 |
**注記**
EKS アドオンまたは Helm インストールを使用して、`hostname-override` と `verbosity` を `monitoringAgent.additionalArgs` として設定できます。現在、EKS アドオンまたは Helm インストールでは、追加の引数を使用してノードモニタリングエージェントの `probe-address` (`8002`) または `metrics-address` (`8003`) をカスタマイズすることはできません。
ノードモニタリングエージェントには、NVIDIA GPU をモニタリングするための NVIDIA DCGM (Data Center GPU Manager) サーバーコンポーネント (`nv-hostengine`) が含まれています。このコンポーネントは、エージェントの [Helm チャート](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml)の `nodeAffinity` で示されるように、NVIDIA GPU インスタンスタイプのノードでのみ実行されます。EKS ノードモニタリングエージェントで既存の NVIDIA DCGM インストールを使用することはできません。この機能が必要な場合は、EKS ロードマップ [GitHub 問題 \$12763](https://github.com/aws/containers-roadmap/issues/2763) に関するフィードバックを提供してください。
EKS ノードモニタリングエージェントを EKS アドオンとしてデプロイする場合、以下の設定値を使用して NVIDIA DCGM のインストールをカスタマイズできます。
| 設定オプション | 説明 |
| --- | --- |
| `dcgmAgent.resources.requests.cpu` | DCGM エージェントの CPU リソースリクエスト。 |
| `dcgmAgent.resources.requests.memory` | DCGM エージェントのメモリリソースリクエスト。 |
| `dcgmAgent.resources.limits.cpu` | DCGM エージェントの CPU リソース制限。 |
| `dcgmAgent.resources.limits.memory` | DCGM エージェントのメモリリソース制限。 |
| `dcgmAgent.tolerations` | テイントが適用されたノードで DCGM エージェントをスケジュールするための許容範囲。 |
以下の AWS CLI コマンドを使用して、EKS ノードモニタリングエージェントの EKS アドオンのバージョンとスキーマに関する有用な情報を取得できます。
Kubernetes バージョンの最新のエージェントアドオンバージョンを取得します。`1.35` を Kubernetes バージョンに置き換えます。
```
aws eks describe-addon-versions \
--addon-name eks-node-monitoring-agent \
--kubernetes-version 1.35 \
--query='addons[].addonVersions[].addonVersion'
```
EKS アドオンでサポートされているエージェントアドオンスキーマを取得します。`v1.5.1-eksbuild.1` をエージェントバージョンに置き換えます。
```
aws eks describe-addon-configuration \
--addon-name eks-node-monitoring-agent \
--addon-version v1.5.1-eksbuild.1
```
# EKS クラスター内のノードを自動的に修復する
このトピックでは、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% に異常があります。
## 自動ノード修復を設定する
EKS Auto Mode を使用する場合、自動ノード修復を設定することはできません。自動ノード修復は常に Karpenter と同じデフォルト設定で有効になります。
### Karpenter
Karpenter で自動ノード修復を使用するには、機能ゲート `NodeRepair=true` を有効にします。機能ゲートは、Karpenter デプロイの `--feature-gates` CLI オプションまたは `FEATURE_GATES` 環境変数を使用して有効にできます。詳細については、[Karpenter](https://karpenter.sh/docs/concepts/disruption/#node-auto-repair) のドキュメントを参照してください。
### マネージドノードグループ
新しい 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 分後に再起動します。
# ノードのヘルスステータスを表示する
このトピックでは、Amazon EKS クラスターのノードのヘルスステータスをモニタリングするために使用可能なツールと方法について説明します。この情報には、ノードレベルの問題の特定と診断に役立つノードの状態、イベント、検出ケースが取り上げられます。ここで説明するコマンドとパターンを使用して、ノードのヘルスリソースを検査し、ステータス条件を解明し、ノードイベントを分析して運用上のトラブルシューティングを行います。
すべてのノードに対して Kubernetes コマンドを使用して、ノードのヘルス情報を取得できます。また、Amazon EKS Auto Mode または Amazon EKS マネージドアドオンを介してノードモニタリングエージェントを使用すると、トラブルシューティングに役立つさまざまなノードシグナルが得られます。ノードモニタリングエージェントによって検出されたヘルス問題の説明は、オブザーバビリティダッシュボードでも確認できます。詳細については、「[EKS ノードモニタリングエージェントのノードのヘルス問題を検出する](node-health-nma.md)」を参照してください。
## ノードの状態
ノードの状態は、インスタンスの置き換えや再起動などの修復アクションを必要とするターミナルの問題を表します。
**すべてのノードの状態を取得するには:**
```
kubectl get nodes -o 'custom-columns=NAME:.metadata.name,CONDITIONS:.status.conditions[*].type,STATUS:.status.conditions[*].status'
```
**特定のノードの詳細な状態を取得するには**
```
kubectl describe node node-name
```
**正常なノードの状態の出力の例:**
```
- lastHeartbeatTime: "2024-11-21T19:07:40Z"
lastTransitionTime: "2024-11-08T03:57:40Z"
message: Monitoring for the Networking system is active
reason: NetworkingIsReady
status: "True"
type: NetworkingReady
```
**ネットワーク形成の問題がある異常なノードの状態の例:**
```
- lastHeartbeatTime: "2024-11-21T19:12:29Z"
lastTransitionTime: "2024-11-08T17:04:17Z"
message: IPAM-D has failed to connect to API Server which could be an issue with
IPTable rules or any other network configuration.
reason: IPAMDNotReady
status: "False"
type: NetworkingReady
```
## ノードイベント
ノードイベントは、一時的な問題または最適ではない設定を示します。
**ノードモニタリングエージェントによって報告されたすべてのイベントを取得するには**
ノードモニタリングエージェントが使用可能になったら、次のコマンドを実行できます。
```
kubectl get events --field-selector=reportingComponent=eks-node-monitoring-agent
```
サンプル出力:
```
LAST SEEN TYPE REASON OBJECT MESSAGE
4s Warning SoftLockup node/ip-192-168-71-251.us-west-2.compute.internal CPU stuck for 23s
```
**すべてのノードのイベントを取得するには**
```
kubectl get events --field-selector involvedObject.kind=Node
```
**特定のノードのイベントを取得するには**
```
kubectl get events --field-selector involvedObject.kind=Node,involvedObject.name=node-name
```
**イベントをリアルタイムで監視するには**
```
kubectl get events -w --field-selector involvedObject.kind=Node
```
**イベント出力の例:**
```
LAST SEEN TYPE REASON OBJECT MESSAGE
2m Warning MemoryPressure Node/node-1 Node experiencing memory pressure
5m Normal NodeReady Node/node-1 Node became ready
```
## 一般的なトラブルシューティングのコマンド
```
# Get comprehensive node status
kubectl get node node-name -o yaml
# Watch node status changes
kubectl get nodes -w
# Get node metrics
kubectl top node
```
# kubectl と S3 を使用してマネージドノードのノードログを取得する
ノードモニタリングエージェントを備えた Amazon EKS マネージドノードのノードログを取得する方法について説明します。
## 前提条件
以下があることを確認します。
+ ノードモニタリングエージェントを備えた既存の Amazon EKS クラスター。詳細については、「[ノードのヘルス問題を検出し、自動ノード修復を有効にする](node-health.md)」を参照してください。
+ クラスターと通信するようにインストールおよび設定された `kubectl` コマンドラインツール。
+ S3 バケットとオブジェクトを作成するのに十分なアクセス許可が付与された状態でインストールおよびログインした AWS CLI。
+ インストール済みの Python 3 最新バージョン
+ インストール済みの AWS SDK for Python 3、Boto 3。
## ステップ 1: S3 バケットの宛先を作成する (任意)
ログを格納する S3 バケットがまだない場合は、作成します。次の AWS CLI コマンドを使用します。バケットのデフォルトは `private` アクセスコントロールリストです。*bucket-name* はユーザーが選択した一意のバケット名に置き換えます。
```
aws s3api create-bucket --bucket
```
## ステップ 2: HTTP Put の事前署名された S3 URL を作成する
Amazon EKS は、指定した URL に対して HTTP PUT オペレーションを実行してノードログを返します。このチュートリアルでは、事前署名された S3 HTTP PUT URL を生成します。
ログは gzip tarball として `.tar.gz` 拡張子で返されます。
**注記**
AWS API または SDK を使用して、EKS がログファイルをアップロードするための事前署名された S3 アップロード URL を作成する必要があります。AWS CLI を使用して事前署名された S3 アップロード URL を作成することはできません。
1. ログを格納するバケット内の場所を決定します。例えば、キーとして *2024-11-12/logs1.tar.gz* を使用できます。
1. *presign-upload.py* ファイルに次の Python コードを保存します。** と ** を置き換えます。キーは `.tar.gz` で終わる必要があります。
```
import boto3; print(boto3.client('s3').generate_presigned_url(
ClientMethod='put_object',
Params={'Bucket': '', 'Key': ''},
ExpiresIn=1000
))
```
1. 次を使用してスクリプトを実行します
```
python presign-upload.py
```
1. URL 出力をメモします。この値は、次のステップで *http-put-destination* として使用します。
詳細については、AWS Boto3 SDK for Python ドキュメントの「[Generate a presigned URL to upload a file](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/s3-presigned-urls.html#generating-a-presigned-url-to-upload-a-file)」を参照してください。
## ステップ 3: NodeDiagnostic リソースを作成する
ログを収集するノードの名前を特定します。
リソースの名前としてノードの名前を使用する `NodeDiagnostic` マニフェストを作成し、HTTP PUT URL の宛先を指定します。
```
apiVersion: eks.amazonaws.com/v1alpha1
kind: NodeDiagnostic
metadata:
name:
spec:
logCapture:
destination: http-put-destination
```
マニフェストをクラスターに適用します。
```
kubectl apply -f nodediagnostic.yaml
```
`NodeDiagnostic` リソースを記述することで、コレクションのステータスを確認できます。
+ ステータスが `Success` または `SuccessWithErrors` の場合は、タスクが完了し、ログが指定された宛先にアップロードされたことを示します (`SuccessWithErrors` は、一部のログが欠落している可能性があることを示します)。
+ ステータスが Failure の場合は、アップロード URL が正しい形式であり、有効期限が切れていないことを確認してください。
```
kubectl describe nodediagnostics.eks.amazonaws.com/
```
## ステップ 4: S3 からログをダウンロードする
ログをダウンロードする前に約 1 分待ちます。そして、S3 CLI を使用してログをダウンロードします。
```
# Once NodeDiagnostic shows Success status, download the logs
aws s3 cp s3:///key ./.tar.gz
```
## ステップ 5: NodeDiagnostic リソースをクリーンアップする
+ `NodeDiagnostic` リソースは自動的には削除されません。ログアーティファクトを取得したら、自分でクリーンアップする必要があります。
```
# Delete the NodeDiagnostic resource
kubectl delete nodediagnostics.eks.amazonaws.com/
```
## NodeDiagnostic `node` 宛先
ノードモニタリングエージェントのバージョン `v1.6.0` 以降では、ログ収集の宛先を `node` に設定するオプションがあります。この宛先を使用すると、ログは後で収集できるようにノード上に一時的に保持されます。この機能のほか、ノードモニタリングエージェントの GitHub リポジトリ内にインタラクションとログ収集を容易にする `kubectl` プラグインもあり、インストールして利用できます。詳細については、[`kubectl ekslogs` プラグイン](https://github.com/aws/eks-node-monitoring-agent/blob/main/tools/kubectl-ekslogs/README.md)のドキュメントを参照してください。
## 使用例
```
# Collect NodeDiagnostic logs from a single node
kubectl ekslogs
# Collect NodeDiagnostic logs from multiple nodes
kubectl ekslogs
# Collect NodeDiagnostic logs from all nodes with a specific label
kubectl ekslogs -l =
```