Amazon Web Services ブログ

詳解: Amazon EKS Auto Mode によるノード障害の検出、修復、診断の仕組み

この記事は Under the hood: how Amazon EKS Auto Mode detects, repairs, and diagnoses node failures (記事公開日: 2026 年 8 月 5 日) を翻訳したものです。

GPU が PCIe バスから脱落する、ネットワークインターフェイスが応答しなくなる、コンテナランタイムが固まる。多くの Kubernetes クラスターでは、ここからオンコール対応が始まります。担当者が起こされ、ダッシュボードを確認し、SSH で接続して、cordon (スケジュール対象外としてマーク) とドレインを行い、インスタンスを手作業で終了します。Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode では、誰かがノート PC を開くより先に、障害が起きたノードが自動的に検出され、ドレインされ、置き換えられます。

この仕組みは、2 つのコンポーネントの連携で成り立っています。Amazon EKS ノードモニタリングエージェント (NMA) が障害を検出し、Kubernetes のノードの Condition として記録します。Karpenter はその Condition を読み取り、ノードを置き換えます。EKS Auto Mode では、どちらも設定なしで自動的に動作します。EKS Auto Mode 以外のコンピューティング (マネージドノードグループやセルフマネージドの Karpenter) でも、ノードモニタリングエージェントを EKS アドオンとしてインストールすれば、同じ検出シグナルが得られます。修復の動作も同じです。Auto Mode での違いは、エージェントが DaemonSet ではなく、AMI に組み込まれた systemd サービスとして動作することです。そのため、エージェントは Pod のスケジューリングが正常に機能しない状況でも動作し続け、誤って退避させられたり、誤った設定にされたりすることもありません。

この記事では、修復サイクルの動作を順を追って見ながら、特定の障害がノードの置き換えをトリガーする一方で、他の障害が通知にとどまる理由を説明します。また、安全のためのしきい値が障害の連鎖を防ぐ仕組みと、ノードにログインせずに、どのノードからでも診断情報を収集する方法も紹介します。

検出と修復が連携する仕組み

このサイクルは 2 つの部分からなり、両者の間には明確な取り決めがあります。

検出 (ノードモニタリングエージェント): エージェントは、カーネル、コンテナランタイム、ネットワーキング、ストレージ、高速コンピューティングハードウェアを監視します。そして、雑多な低レベルのシグナルを、少数の Kubernetes のノードの Condition にまとめます。障害が致命的で、ノードを置き換えるべきものであれば、エージェントは該当する Condition を False に切り替えます。

status:
  conditions:
  - type: AcceleratedHardwareReady
    status: "False"
    reason: NvidiaDeviceCountMismatch
    message: "Expected 8 GPUs, found 7."

修復 (Karpenter): Karpenter は、EKS Auto Mode のすべてのノードのプロビジョニングとスケーリングをすでに担っている、マネージドのコンピューティングコントローラーです。Karpenter は、これらの Condition を直接読み取ります。修復のために別のバックエンドを有効にする必要も、ノードグループごとにオプトインする必要もありません。ノードを起動したコントローラーが、そのままノードの置き換えも行います。Karpenter のクラウドプロバイダーが修復ポリシーを定義します。各ポリシーは、Condition のタイプと「このノードを置き換える」ことを意味するステータスを対応づけます。

置き換えが、Karpenter の唯一の修復アクションです。この点は、マネージドノードグループの自動修復と異なります。マネージドノードグループでは、Condition に応じてインスタンスの再起動か置き換えかを選びます。EKS Auto Mode では、異常なノードは常に新しいノードに置き換えられます。ノードがポリシーの条件に当てはまり、猶予期間を過ぎてもその状態が続くと、Karpenter が動きます。ノードに Taint を付与し、ドレインし、インスタンスを終了して、代替ノードを起動します。

ノードの Condition が、2 つの部分をつなぐ唯一のインターフェイスです。エージェントは Karpenter を呼び出さず、Karpenter はエージェントがどのように判定したかを知りません。エージェントは Kubernetes の標準の仕組みで Condition を書き込み、Karpenter はその Condition を見て動作します。両者が共有するのは Kubernetes API サーバーだけです。この疎結合によって、サイクルの信頼性が保たれています。

エージェントが検出するもの

エージェントは、検出内容を 5 つのモニタリング用の Condition に分類します。KernelReady、ContainerRuntimeReady、NetworkingReady、StorageReady、AcceleratedHardwareReady です。検出には、2 つの重大度のどちらかが付きます。Condition 重大度の検出は致命的な障害で、該当する Condition を False に切り替え、ノードを置き換えの対象にします。Event 重大度の検出は一時的な問題や最適でない設定で、ノードは稼働を続けたまま、状況を把握できるように Kubernetes イベントとして通知されます。修復を実行するかどうかは、この重大度で決まります。

修復をトリガーする障害は、そのままでは回復を待てないものです。高速コンピューティングインスタンスでは、GPU のデバイス数の不一致、重大な XID エラー、ダブルビット ECC エラーがこれにあたります。NVLink と NVSwitch のファブリック障害、Fabric Manager の欠落、Neuron の DMA、HBM、SRAM の訂正不能エラーも含まれます。これらは自然には回復しないハードウェア障害で、ノードを稼働させたままにすると、トレーニングのステップごとに GPU 時間を無駄にします。ネットワークでは、Amazon Virtual Private Cloud (Amazon VPC) Container Networking Interface (CNI) のプロセスの停止や、IPAMD が API サーバーに到達できない状態がこれにあたります。インターフェイスが起動しない場合や、ループバックがない場合も含まれます。カーネルとランタイムにも、それぞれ致命的なケースがあります。PID やメモリの枯渇による fork の失敗と、コンテナランタイムの故障により Pod が Terminating 状態のままになることです。

エージェントは、Event 重大度の検出も行います。こちらは Condition 重大度とは異なり、通知にとどまります。エージェントは Kubernetes イベントを発行し、ノードは稼働を続けます。対象は、帯域幅の上限、接続追跡 (conntrack) の上限、Amazon Elastic Block Store (Amazon EBS) の IOPS のスロットリング、I/O の遅延などです。ファイルシステムの断片化、クロックドリフト、Probe の失敗、kube-proxy の異常、GPU の温度と電力の警告も通知します。これらは、障害が致命的になる前に、その兆候を読み取る手がかりになります。理由コードとその重大度の一覧は、ノードヘルスのドキュメントにあります。NVIDIA の GPU については、DCGM によって幅広い項目を検出します。DCGM は NVML の上に構築されていて、NVML の情報に加えて、プッシュ型のポリシーイベント、診断、NVSwitch のファブリックのヘルスを提供します。P5e や P6 のような複数の GPU を搭載したインスタンスでは、1 つの不良デバイスがトレーニングジョブ全体を止めてしまうことがあるため、この検出範囲が欠かせません。

Condition が False になってから新しいノードが動くまで

ここからは、検出がどのようにノードの置き換えにつながるかを説明します。Karpenter の AWS クラウドプロバイダーは、一連の修復ポリシーを定義します。各ポリシーは、Condition のタイプと、異常とみなされるステータス、そして修復を開始する前に Condition が異常な状態を維持しなければならない許容ウィンドウ (toleration window) を対応づけます。

モニタリング用の Condition ステータス 修復までの許容ウィンドウ
NodeReady (kubelet) False 30 分
NodeReady (kubelet) Unknown 30 分
KernelReady False 30 分
ContainerRuntimeReady False 30 分
NetworkingReady False 30 分
StorageReady False 30 分
AcceleratedHardwareReady False 10 分

処理の流れは次のとおりです。

  1. エージェントが Condition を切り替える。Condition 重大度の検出は、該当するノードの Condition を False に設定し、理由コード (reason) と、人が読めるメッセージ (message) を付けます。Event 重大度の検出は、このステップに進みません。Kubernetes イベントを発行するだけで、ノードの Condition は True のままです。
  2. Karpenter のヘルスコントローラーが時間を計る。Karpenter はノードの Condition を監視し、Condition の LastTransitionTime を起点にタイマーを開始します。許容ウィンドウが経過する前に自然に解消する一時的な問題であれば、タイマーがリセットされるだけで、ノードはまったく影響を受けません。
  3. 許容ウィンドウが修復の速さを決める。高速コンピューティングハードウェアの障害は 10 分待ちます。カーネル、ランタイム、ネットワーキング、ストレージの障害と、kubelet が報告する NodeReady は 30 分待ちます。
  4. セーフティゲートがフリートを守る。NodePool またはクラスター内の異常なノードがしきい値 (20%) を超えると、Karpenter は修復を行いません。また、Amazon Application Recovery Controller (ARC) のゾーンシフトが有効な間も、自動修復は停止します。この仕組みの狙いは、1 台の不良ノードを修復することであり、広範囲の問題を決して拡大させないことです。
  5. 修復が実行される。許容ウィンドウを過ぎ、安全のためのしきい値の範囲内であれば、Karpenter はノードに Taint を付与して新しい Pod のスケジューリングを止め、Pod Disruption Budget に従って実行中の Pod をドレインします。その後、インスタンスを終了し、退避させた Pod に見合うサイズの代替ノードをプロビジョニングします。分散トレーニングのようなステートフルなワークロードでは、回復できるかどうかは、ワークロードがチェックポイントから再開できるかどうかで決まります。システムはノードを置き換えて Pod を再スケジュールしますが、最後に保存した状態から再開するのはワークロードの役割です。

訳注: 2026 年 10 月時点では、EKS Auto Mode の自動修復は、通常のドレインではなく、ごく短い猶予期間で異常なノードの Pod を削除し、Pod Disruption Budget を考慮しません。猶予期間を設けて Pod Disruption Budget を考慮するのは、セルフマネージドの Karpenter v1.15.0 以降です。また、ARC のゾーンシフトで自動修復が停止するのは、マネージドノードグループの場合です。詳細については、Automatically repair nodes in EKS clusters のドキュメントをご覧ください。

この一連の処理は、人手を介さずに実行されます。代替ノードは起動するとクラスターに登録され、新しいエージェントによる監視が始まり、すぐにワークロードを実行できる状態になります。

大規模な運用から得た教訓

ノードモニタリングエージェントを数千のクラスターで運用するなかで、紹介しておきたい設計原則がいくつか見えてきました。

障害を致命的なものと通知だけのものに分ける理由: PCIe バスから脱落した GPU は、再起動しない限り回復しません。この障害を Warning のままにしていたため、性能が低下したノードにワークロードがスケジュールされ続けていました。一方、帯域幅の上限は一時的なもので、ワークロードによって変わります。分類のルールは次のとおりです。どの Pod が実行されているかに関係なく障害が続き、自然に回復しない場合は、Condition 重大度として置き換えをトリガーします。ワークロードの動作によって変わる場合や、自然に解消する場合は、Event 重大度として通知にとどめます。

安全のためのしきい値を 20% にした理由: フリート全体の上限がなければ、同じ原因による誤検知で、正常なノードが数十台同時に異常と判定されるおそれがあります。不良な AMI、コントロールプレーンの一時的な不調、モニターの設定の誤りが、大量の置き換えを引き起こしかねません。上限を 20% にすることで、Karpenter が一度に終了するノードは NodePool の 5 分の 1 までになり、実際の障害は修復しながら、キャパシティの大部分を維持できます。このしきい値は Karpenter のヘルスコントローラーで固定されていて、NodePool の設定では変えられません。上限に達して修復が止まると、Karpenter はノードに NodeRepairBlocked イベントを発行し、5 分ごとに再確認します。

許容ウィンドウが異なる理由: 高速コンピューティングハードウェアの障害の許容ウィンドウが 10 分なのは、判定がはっきりしていて (バス上に GPU があるかないかのどちらか)、放置すると損失が大きいからです。カーネル、ランタイム、ネットワーキング、ストレージの障害が 30 分なのは、これらのサブシステムでは一時的な状態が自然に解消することがあるからです。ネットワークの瞬断やランタイムの一時的な再起動で、ノードを失うべきではありません。

理由コードはパブリック API として扱う: 理由コードを利用する下流のもの (修復コントローラー、ダッシュボード、お客様の自動化) はすべて、理由コードの文字列の完全一致で判定しています。v1.6.2 で、NvidiaDeviceCountMismatch の重大度を Warning から Fatal に変更しました。技術的には妥当な判断でしたが、古い重大度を前提に修復を設定していたお客様の自動化が動かなくなりました。それ以来、理由コードの追加は機能の開発として、重大度の変更は破壊的変更として扱っています。

「Condition がない」ことを「正常」と同じに扱ってはならない: モニターが無効になっているとき、エージェントは True も Unknown も書き込まず、Condition そのものを出力しません。True を書き込むと、エージェントが監視していないのに、ノードが正常だと自動修復に伝えてしまいます。Unknown を書き込むと意味があいまいになり、不要な修復をトリガーするおそれがあります。何も出力しないことが、唯一の安全な選択です。

修復サイクルの実際の動作

次の例では、稼働中の Amazon EKS Auto Mode クラスターで、修復サイクルが最初から最後まで実行される様子を示します。

このクラスターには、Bottlerocket の EKS Auto Nvidia バリアントで動作する g6e.xlarge の GPU ノードがあります。GPU が正常なとき、NMA はすべてのノードの Condition を正常 (True) と報告します。

$ kubectl get node i-0981...e7d \
    -o jsonpath='{range .status.conditions[*]}{.type}={.status} ({.reason}){"\n"}{end}'
AcceleratedHardwareReady=True (NvidiaGPUIsReady)
ContainerRuntimeReady=True (ContainerRuntimeIsReady)
NetworkingReady=True (NetworkingIsReady)
KernelReady=True (KernelIsReady)
StorageReady=True (DiskIsReady)

シリコンが実際に故障するのを待たずに GPU の障害を再現するため、ノードの DCGM ホストエンジンにダブルビット ECC エラーを注入します。DCGM ホストエンジンは、NMA がテレメトリを読み取っている情報源そのものです。EKS Auto Mode のノードは、SSH でアクセスできないマネージドインスタンスです。そこで、障害を注入するために、DCGM のツールを含む特権 Pod を実行します。

apiVersion: v1
kind: Pod
metadata:
  name: dcgm-inject
spec:
  nodeName: i-0981...e7d
  hostPID: true
  containers:
  - name: dcgm
    image: nvcr.io/nvidia/cloud-native/dcgm:3.3.7-1-ubuntu22.04
    command: ["sleep", "3600"]
    securityContext:
      privileged: true
    volumeMounts:
    - name: dev
      mountPath: /dev
  volumes:
  - name: dev
    hostPath:
      path: /dev
  tolerations:
  - operator: Exists

この Pod がホストの DCGM エンジンと通信するには、privileged: true と hostPID: true が必要です。Pod が起動したら、exec で Pod に入り、障害を注入します。

$ kubectl exec dcgm-inject -- dcgmi test --inject --gpuid 0 -f 319 -v 4
Successfully injected field info.

NMA は数秒後の次のポーリングでこのエラーを検出し、Condition を False に切り替えます。

$ kubectl get node i-0981...e7d -o jsonpath='{range .status.conditions[?(@.type=="AcceleratedHardwareReady")]}{.status} {.reason}: {.message}{"\n"}{end}'
False NvidiaDoubleBitError: detected 4 Nvidia Double Bit error(s) on location Device

エージェントは、この Condition の切り替えをノードのイベントとして記録します。Karpenter が監視しているのは、このシグナルです。

$ kubectl get events --field-selector involvedObject.name=i-0981...e7d
... AcceleratedHardwareReady  Status condition transitioned, Type: AcceleratedHardwareReady,
    Status: True -> False, Reason: NvidiaDoubleBitError,
    Message: detected 4 Nvidia Double Bit error(s) on location Device

ここから先は、誰も何も操作しません。Condition が False になってから 10 分後 (高速コンピューティングハードウェアの許容ウィンドウ)、Karpenter が自動で修復を始めます。異常なノードをドレインしながら、代替ノードを起動します。

$ kubectl get nodeclaims
NAME             TYPE          ZONE         NODE           READY
gpu-demo-fdthm   g6e.xlarge   us-west-2c                  Unknown   # 代替ノード、起動中
gpu-demo-xfqcb   g6e.xlarge   us-west-2b   i-0981...e7d     True      # 異常、ドレイン中

数分後には、異常なノードはなくなり、新しいノードが代わりに稼働して、ワークロードが再び実行されています。

$ kubectl get node i-0bb2...fb4 -o jsonpath='{range .status.conditions[?(@.type=="AcceleratedHardwareReady")]}{.status} {.reason}{"\n"}{end}'
True NvidiaGPUIsReady
$ kubectl get pods -l app=gpu-demo -o wide
NAME                          READY   STATUS    NODE
gpu-demo-workload-...-j97n5     1/1     Running   i-0bb2...fb4

障害を 1 回注入すると、数秒で Condition が切り替わり、意図して設けた 10 分の許容ウィンドウの後、およそ 90 秒で再プロビジョニングとクラスターへの再参加が終わります。最初から最後まで、人手は要りません。

リソースのクリーンアップ

手順を試した後は、テスト用のリソースを削除します。

kubectl delete pod dcgm-inject

SSH を使わない診断: ノードに障害が起きた原因を調べる

自動修復が対応するのは、よくあるケースです。異常なノードは置き換えられ、ワークロードは動き続けます。しかし、ノードに障害が起きた原因を知る必要がある場合もあります。同じ障害が繰り返し起きている場合や、サポートケースで証拠が必要な場合です。

従来の EKS ノードで診断情報を集めるには、ノードに SSH でアクセスし、ログ収集のスクリプトを手作業で実行する必要がありました。NodeDiagnostic カスタムリソース定義 (CRD) は、この方法に代わる手段です。SSH でのアクセスはコンプライアンス上禁止されていることが多く、ネットワークに障害があると使えません。EKS Auto Mode では、この方法はまったく使えません。Auto Mode のノードは、設計上 SSH でアクセスできない Amazon Elastic Compute Cloud (Amazon EC2) マネージドインスタンスだからです。これらのノードで何が起きたかを知る手段は、NodeDiagnostic CRD と kubectl ekslogs だけです。

kubectl ekslogs の仕組み

kubectl-ekslogs プラグインは、NodeDiagnostic の一連の手順を 1 つのコマンドにまとめたものです。

$ kubectl ekslogs i-0abc123def456
✔ Transfer mode: node proxy API
⟳ Validating node(s)...
✔ 1 node validated
⟳ Creating NodeDiagnostic resources...
⟳ Waiting for log collection to complete (timeout: 300s)...
✔ Log collection completed on 1 node
⟳ Downloading log bundles...
✔ Saved: ./i-0abc123def456-logs.tar.gz (288K)
✔ Done: 1 log bundle downloaded to ./

内部的には、このプラグインは次の処理を行います。

  1. ノード名と destination: node を指定して、NodeDiagnostic カスタムリソースを作成します。
  2. 対象のノードで動くエージェントが、Kubernetes の watch でそのリソースを検出します。
  3. エージェントが、システムログ、カーネルメッセージ、ネットワーキングの状態、ランタイムの診断情報を集め、圧縮した tarball にまとめます。
  4. エージェントが、tarball をノードに一時的に保存します (10 分間取得可能)。
  5. プラグインが、kubelet の Node Log Query API (KEP-2258、Kubernetes 1.36 で一般提供) を使って tarball をダウンロードします。

SSH も、セキュリティグループの変更も、キーペアも必要ありません。シェルでアクセスできない Auto Mode のマネージドインスタンスでも使えます。

ログを kubelet API 経由でストリーミングせずに Amazon Simple Storage Service (Amazon S3) に保存したい場合は、NodeDiagnostic の宛先に S3 の署名付き PUT URL を指定します。手順はノードログの取得のドキュメントで順を追って説明しています。同じ仕組みでネットワークトラフィックをキャプチャすることもできます。エージェントがノードで tcpdump を実行し、キャプチャファイルを圧縮して、指定したバケットにアップロードします。

検出と診断は別々の役割

このアーキテクチャでは、検出と診断を意図的に分けています。検出は「このノードは正常か」に答えるもので、最小限のオーバーヘッドで常に動作し、ノードの Condition を書き込みます。診断は「何が問題だったのか」に答えるもので、必要なときにだけ動作し、NodeDiagnostic を通じて詳細な情報を集めます。検出と診断は同じエージェントのバイナリで動きますが、結果を使う相手が違います。検出の結果は修復サイクルが使います。診断の結果は、事後に原因を調べる人が使います。

役割を分けているので、検出が証拠集めのために遅くなることはなく、診断を常に動かしておく必要もありません。自動修復がすでに異常と判定したものの、まだ終了していないノードを診断することもできます。

EKS Auto Mode で得られるもの

ノードのヘルスモニタリングは、Auto Mode の AMI に組み込まれている機能の 1 つです。全体像は Auto Mode のアーキテクチャの記事で紹介しています。この記事で説明した機能は、すべてデフォルトで有効です。必要に応じて用意するのは、手元の端末にインストールする診断ツールだけです。

必要なときに診断するには、kubectl-ekslogs プラグインをインストールし、kubectl ekslogs <node-name> を実行して、ログ一式を取得します。ネットワークのキャプチャには、宛先に tcpdump を指定した NodeDiagnostic リソースを作成します。

EKS Auto Mode 以外のコンピューティングでは、同じ仕組みを自分で構成できます。ノードモニタリングエージェントを EKS アドオンとしてインストールし、バージョンを最新に保ち、ノードグループごとに修復にオプトインします。インストールとオプトインの手順は、ノードモニタリングと自動修復のドキュメントで説明しています。

まとめ

この記事では、Amazon EKS Auto Mode が人手を介さずにノード障害を検出、修復、診断する仕組みを紹介しました。ノードモニタリングエージェントは低レベルの障害を Kubernetes のノードの Condition に変換し、Karpenter はその Condition に基づいてノードを置き換えます。両者の間の取り決めはノードの Condition だけで、ノードの Condition はごく普通の Kubernetes の仕組みにすぎません。だからこそ、このサイクルは信頼できます。修復を実行するかどうかは重大度で決まります。Condition 重大度の検出は置き換えをトリガーし、Event 重大度の検出は通知にとどまり、ノードは稼働を続けます。

このシステムは、すぐに反応するのではなく、意図的に慎重に動くように作られています。許容ウィンドウによって一時的な障害が自然に解消するのを待ち、フリート全体の安全のためのしきい値によって、同じ原因の障害が拡大するのを防ぎます。また、理由コードをパブリック API として扱うので、理由コードを前提に作った自動化が知らないうちに動かなくなることはありません。そして、ノードに障害が起きた原因を知りたいときは、NodeDiagnostic CRD と kubectl ekslogs で、Kubernetes API を通じてログ一式を取得できます。SSH は不要で、ログインできないマネージドインスタンスでも使えます。

EKS Auto Mode では、これらはどれも、自分で有効にする機能ではありません。アドオンも、オプトインのフラグも、管理するバージョンもありません。検出、修復、診断は、AWS がお客様に代わって運用するデータプレーンのライフサイクルの一部で、クラスターを作成したときから有効です。

EKS Auto Mode がコンピューティングを管理するので、お客様はワークロードに時間を使えます。また、ノードモニタリングエージェントはオープンソースなので、お客様が大規模な運用で遭遇した障害モードを、プルリクエストで新しい検出に直接反映できます。

関連情報

翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文はこちらです。