**帮助改进此页面** 

要帮助改进本用户指南，请选择位于每个页面右侧窗格中的**在 GitHub 上编辑此页面**链接。

# 检测节点运行状况问题并启用自动节点修复
<a name="node-health"></a>

节点运行状况是指节点的运行状态以及有效运行工作负载的能力。运行正常的节点可以保持预期的网络连接，拥有充分的计算和存储资源，并能成功运行工作负载而不中断。

为帮助保持 EKS 集群中运行正常的节点，EKS 提供了*节点监控代理*和*节点自动修复*功能。这些功能在 EKS Auto Mode 计算中会自动启用。您也可以将自动节点修复与 EKS 托管节点组和 Karpenter 结合使用，并可以将 EKS 节点监控代理与除 AWS Fargate 之外的任何 EKS 计算类型结合使用。EKS 节点监控代理和自动节点修复功能结合使用效果最佳，但也可以在 EKS 集群中单独使用。

**重要**  
*节点监控代理*和*节点自动修复*功能仅支持 Linux。这些功能不支持 Windows。

## 节点监控代理
<a name="node-monitoring-agent"></a>

Amazon EKS 节点监控代理会读取节点日志以检测运行状况问题。此代理会解析节点日志以检测故障，并显示有关节点运行状况的状态信息。对于检测到的每一类问题，代理都会对工作节点应用专用的 `NodeCondition`Worker 节点。有关 EKS 节点监控代理检测到的节点运行状况问题的详细信息，请参阅 [使用 EKS 节点监控代理检测节点运行状况问题](node-health-nma.md)。

EKS Auto Mode 计算包含节点监控代理。对于其他 EKS 计算类型，您可以将节点监控代理作为 EKS 附加组件添加，或者使用 Kubernetes 工具（如 Helm）进行管理。有关更多信息，请参阅 [配置节点监控代理](node-health-nma.md#node-monitoring-agent-configure)。

使用 EKS 节点监控代理，以下类别的节点运行状况问题会以节点状况的形式呈现。注意、`Ready`、`DiskPressure` 和 `MemoryPressure` 是标准的 Kubernetes 节点状况，即使没有 EKS 节点监控代理也会呈现。


| 节点状况 | 说明 | 
| --- | --- | 
|  AcceleratedHardwareReady  |  AcceleratedHardwareReady 表示节点上的加速硬件（GPU、Neuron）是否正常运行。  | 
|  ContainerRuntimeReady  |  ContainerRuntimeReady 表示容器运行时（containererd 等）是否正常运行并能运行容器。  | 
|  DiskPressure  |  DiskPressure 是一个标准的 Kubernetes 状况，表示节点正在经历磁盘压力（磁盘空间不足或 I/O 过高）。  | 
|  KernelReady  |  KernelReady 表示内核是否运行正常，无严重错误、死锁或资源耗尽问题。  | 
|  MemoryPressure  |  MemoryPressure 是一个标准的 Kubernetes 状况，表示节点正在经历内存压力（可用内存不足）。  | 
|  NetworkingReady  |  NetworkingReady 表示节点的网络堆栈（接口、路由、连接）是否正常运行。  | 
|  StorageReady  |  StorageReady 表示节点的存储子系统（磁盘、文件系统、I/O）是否正常运行。  | 
|  Ready  |  Ready 是标准的 Kubernetes 状况，表示节点运行正常并已准备好接收容器组（pod）。  | 

## 自动节点修复
<a name="node-auto-repair"></a>

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 节点监控代理检测节点运行状况问题
<a name="node-health-nma"></a>

本主题详细介绍了 EKS 节点监控代理检测到的节点运行状况问题、如何将这些问题显示为节点条件或事件，以及如何配置节点监控代理。

无论是否使用 EKS 自动节点修复，均可使用 EKS 节点监控代理。有关 EKS 自动节点修复的更多信息，请参阅 [自动修复 EKS 集群中的节点](node-repair.md)。

EKS 节点监控代理的源代码发布在 GitHub 上的 [aws/eks-node-monitoring-agent](https://github.com/aws/eks-node-monitoring-agent) 存储库中。

## 节点运行状况问题
<a name="node-health-issues"></a>

下表介绍了节点监控代理可能会检测到的节点运行状况问题。问题有两种类型：
+ 状况 – 需要采取补救措施（例如替换实例或重启实例）的终端问题。启用自动修复后，Amazon EKS 将执行修复操作，可能是替换或重启节点。有关更多信息，请参阅 [节点状况](learn-status-conditions.md#status-node-conditions)。
+ 事件 – 暂时性问题或节点配置不佳问题。不会执行任何自动修复操作。有关更多信息，请参阅 [节点事件](learn-status-conditions.md#status-node-events)。

## AcceleratedHardware 节点运行状况问题
<a name="node-health-AcceleratedHardware"></a>

监控条件是下表中严重性为“状况”的问题的 `AcceleratedHardwareReady`。下表中的事件和条件适用于与 NVIDIA 和 Neuron 相关的节点运行状况问题。


| 名称 | 严重性 | 说明 | 修复操作 | 
| --- | --- | --- | --- | 
|  DCGMDiagnosticFailure  |  条件  |  DCGM 主动诊断测试套件中的测试用例失败。  |  无  | 
|  DCGMError  |  条件  |  到 DCGM 主机进程的连接已断开或无法建立。  |  无  | 
|  DCGMFieldError[Code]  |  事件  |  DCGM 通过字段标识符检测到 GPU 降级。  |  无  | 
|  DCGMHealthCode[Code]  |  事件  |  DCGM 运行状况检查以非致命方式失败。  |  无  | 
|  DCGMHealthCode[Code]  |  条件  |  DCGM 运行状况检查以致命方式失败。  |  无  | 
|  NeuronDMAError  |  条件  |  DMA 引擎遇到不可恢复的错误。  |  Replace（替换）  | 
|  NeuronHBMUncorrectableError  |  条件  |  HBM 遇到无法纠正的错误并产生了不正确的结果。  |  Replace（替换）  | 
|  NeuronNCUncorrectableError  |  条件  |  检测到无法纠正的 Neuron Core 内存错误。  |  Replace（替换）  | 
|  NeuronSRAMUncorrectableError  |  条件  |  片上 SRAM 遇到奇偶校验错误并产生了不正确的结果。  |  Replace（替换）  | 
|  NvidiaDeviceCountMismatch  |  事件  |  通过 NVML 可见的 GPU 数量与文件系统中的 NVIDIA 设备计数不一致。  |  无  | 
|  NvidiaDoubleBitError  |  条件  |  GPU 驱动程序产生了双比特错误。  |  Replace（替换）  | 
|  NvidiaNCCLError  |  事件  |  NVIDIA Collective Communications 库中出现段错误 (`libnccl`)。  |  无  | 
|  NvidiaNVLinkError  |  条件  |  GPU 驱动程序报告了 NVLink 错误。  |  Replace（替换）  | 
|  NvidiaPCIeError  |  事件  |  触发 PCIe 重播是为了从传输错误中恢复过来。  |  无  | 
|  NvidiaPageRetirement  |  事件  |  GPU 驱动程序已将内存页标记为停用。如果出现单个双比特错误或在同一地址遇到两个单比特错误，则可能会发生这种情况。  |  无  | 
|  NvidiaPowerError  |  事件  |  GPU 的功率利用率超过了允许的阈值。  |  无  | 
|  NvidiaThermalError  |  事件  |  GPU 的散热状态超过了允许的阈值。  |  无  | 
|  NvidiaXID[Code]Error  |  条件  |  出现严重的 GPU 错误。  |  更换或重启  | 
|  NvidiaXID[Code]Warning  |  事件  |  出现了非严重的 GPU 错误。  |  无  | 

## NVIDIA XID 错误代码
<a name="nvidia-xid-codes"></a>

节点监控代理从 GPU 内核日志中检测 NVIDIA XID 错误。XID 错误分为两类：
+  **众所周知的 XID 代码**–关键错误会设置节点条件 (`AcceleratedHardwareReady=False`)，并在启用时触发自动修复。推理代码格式为 `NvidiaXID[Code]Error`。EKS 节点监控代理检测到的众所周知的 XID 代码可能不代表需要修复操作的 NVIDIA XID 代码的完整列表。
+  **未知的 XID 代码**–仅作为 Kubernetes 事件记录。这些不会触发自动修复。推理代码格式为 `NvidiaXID[Code]Warning`。要调查未知的 XID 错误，请使用 `dmesg | grep -i nvrm` 查看内核日志。

有关 XID 错误的更多信息，请参阅《NVIDIA GPU 部署和管理文档》中的 [Xid Errors](https://docs.nvidia.com/deploy/xid-errors/index.html#topic_5_1)**。有关单个 XID 消息的更多信息，请参阅《NVIDIA GPU 部署和管理文档》中的 [Understanding Xid Messages](https://docs.nvidia.com/deploy/gpu-debug-guidelines/index.html#understanding-xid-messages)**。

下表列出了众所周知的 XID 代码、其含义以及启用后的默认节点修复操作（如果启用）。


| XID 代码 | 说明 | 修复操作 | 
| --- | --- | --- | 
|  13  |  图形引擎异常–出现 GPU 图形引擎错误，通常由软件问题或驱动程序错误引起。  |  Reboot  | 
|  31  |  GPU 内存页面错误–应用程序试图访问无法映射或无法访问的 GPU 内存。  |  Reboot  | 
|  48  |  双位 ECC 错误–GPU 内存中发生无法纠正的双位错误，表示可能出现硬件性能下降。  |  Reboot  | 
|  63  |  GPU 内存重新映射事件–由于检测到错误，GPU 驱动程序重新映射了部分 GPU 内存。这通常是可以恢复的。  |  Reboot  | 
|  64  |  GPU 内存重新映射失败–GPU 无法重新映射有缺陷的内存，这表明存在硬件问题。  |  Reboot  | 
|  74  |  NVLink 错误–GPU 之间的高速 NVLink 互连出现错误。  |  Replace（替换）  | 
|  79  |  GPU 已从总线上掉线–GPU 已无法通过 PCIe 访问，这通常表示硬件故障或电源问题。  |  Replace（替换）  | 
|  94  |  受控内存错误 – 发生了内存错误，但该错误已被隔离，未影响其他应用程序。  |  Reboot  | 
|  95  |  未受控内存错误–发生了可能影响其他应用程序或系统内存的内存错误。  |  Reboot  | 
|  119  |  GSP RPC 超时–与 GPU 系统处理器的通信超时，可能是由于固件问题导致。  |  Replace（替换）  | 
|  120  |  GSP 错误–GPU 系统处理器中发生错误。  |  Replace（替换）  | 
|  121  |  C2C 错误–芯片间互连（用于多芯片 GPU）发生错误。  |  Replace（替换）  | 
|  140  |  ECC 未恢复错误–ECC 错误突破了隔离范围，可能导致数据损坏。  |  Replace（替换）  | 

要查看与 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 节点运行状况问题
<a name="node-health-ContainerRuntime"></a>

监控条件是下表中严重性为“状况”的问题的 `ContainerRuntimeReady`。


| 名称 | 严重性 | 说明 | 修复操作 | 
| --- | --- | --- | --- | 
|  ContainerRuntimeFailed  |  事件  |  容器运行时创建容器失败，如果反复发生，则可能与任何报告的问题有关。  |  无  | 
|  DeprecatedContainerdConfiguration  |  事件  |  使用已弃用映像清单版本 2、架构 1 的容器映像最近通过 `containerd` 拉取到了节点上。  |  无  | 
|  KubeletFailed  |  事件  |  kubelet 处于某个失败状态。  |  无  | 
|  LivenessProbeFailures  |  事件  |  检测到存活探针失败，如果反复发生，则可能指示应用程序代码问题或超时值不足。  |  无  | 
|  PodStuckTerminating  |  条件  |  容器组正在或曾经过长时间停滞在正在终止状态，这可能是因 CRI 错误阻止容器组状态进展造成的。  |  Replace（替换）  | 
|  ReadinessProbeFailures  |  事件  |  检测到就绪探针失败，如果反复发生，则可能指示应用程序代码问题或超时值不足。  |  无  | 
|  [Name]RepeatedRestart  |  事件  |  systemd 单元频繁重启。  |  无  | 
|  ServiceFailedToStart  |  事件  |  系统单元启动失败。  |  无  | 

## 节点内核运行状况问题
<a name="node-health-Kernel"></a>

监控条件是下表中严重性为“状况”的问题的 `KernelReady`。


| 名称 | 严重性 | 说明 | 修复操作 | 
| --- | --- | --- | --- | 
|  AppBlocked  |  事件  |  任务被长时间禁止调度，这通常是由于在输入或输出时被屏蔽所致。  |  无  | 
|  AppCrash  |  事件  |  节点上的应用程序已崩溃。  |  无  | 
|  ApproachingKernelPidMax  |  事件  |  根据当前 `kernel.pid_max` 设置，进程数量已接近可用 PID 的最大数量，之后将无法启动更多进程。  |  无  | 
|  ApproachingMaxOpenFiles  |  事件  |  按照当前内核设置，打开的文件数已接近可能打开的最大文件数，之后打开新文件将失败。  |  无  | 
|  ConntrackExceededKernel  |  事件  |  连接跟踪超出内核的最大值且无法建立新连接可能会导致数据包丢失。  |  无  | 
|  ExcessiveZombieProcesses  |  事件  |  无法完全回收的进程正在大量积累，这指示存在应用程序问题，并且可能导致达到系统进程限制。  |  无  | 
|  ForkFailedOutOfPIDs  |  条件  |  由于系统进程 ID 或内存不足，fork 或 exec 调用失败，这可能是僵尸进程或物理内存耗尽造成的。  |  Replace（替换）  | 
|  KernelBug  |  事件  |  Linux 内核本身检测到并报告了内核错误，但这有时可能是由节点的 CPU 或内存使用率过高，导致事件处理延迟造成的。  |  无  | 
|  LargeEnvironment  |  事件  |  此进程的环境变量数大于预期，这可能是因许多将 `enableServiceLinks` 设置为 true 的服务造成的，因为这可能导致性能问题。  |  无  | 
|  RapidCron  |  事件  |  cron 作业在此节点上的运行速度超过每五分钟一次，如果该作业消耗大量资源，则可能会影响性能。  |  无  | 
|  SoftLockup  |  事件  |  CPU 在给定时间停滞。  |  无  | 

## 节点联网运行状况问题
<a name="node-health-Networking"></a>

监控条件是下表中严重性为“状况”的问题的 `NetworkingReady`。


| 名称 | 严重性 | 说明 | 修复操作 | 
| --- | --- | --- | --- | 
|  BandwidthInExceeded  |  事件  |  因入站总带宽超过实例的最大值，导致数据包已排队或被丢弃。  |  无  | 
|  BandwidthOutExceeded  |  事件  |  因出站总带宽超过实例的最大值，导致数据包已排队或被丢弃。  |  无  | 
|  ConntrackExceeded  |  事件  |  连接跟踪超出实例的最大值且无法建立新连接，这可能会导致数据包丢失。  |  无  | 
|  EFAErrorMetric  |  事件  |  EFA 驱动程序指标显示存在性能下降的接口。  |  无  | 
|  IPAMDInconsistentState  |  事件  |  磁盘上 IPAMD 检查点的状态不反映容器运行时中的 IP。  |  无  | 
|  IPAMDNoIPs  |  事件  |  IPAMD 的 IP 地址已用完。  |  无  | 
|  IPAMDNotReady  |  条件  |  IPAMD 无法连接到 API 服务器。  |  Replace（替换）  | 
|  IPAMDNotRunning  |  条件  |  未发现 Amazon VPC CNI 进程正在运行。  |  Replace（替换）  | 
|  IPAMDRepeatedlyRestart  |  事件  |  IPAMD 服务已多次重启。  |  无  | 
|  InterfaceNotRunning  |  条件  |  此接口似乎未运行或存在网络问题。  |  Replace（替换）  | 
|  InterfaceNotUp  |  条件  |  此接口似乎未启动或存在网络问题。  |  Replace（替换）  | 
|  KubeProxyNotReady  |  事件  |  Kube-proxy 无法观察或列出资源。  |  无  | 
|  LinkLocalExceeded  |  事件  |  由于到本地代理服务的流量 PPS 超出网络接口的最大值，数据包被丢弃。  |  无  | 
|  MACAddressPolicyMisconfigured  |  事件  |  systemd-networkd 链接配置的值 `MACAddressPolicy` 不正确。  |  无  | 
|  MissingDefaultRoutes  |  事件  |  缺少默认路由规则。  |  无  | 
|  MissingIPRoutes  |  事件  |  容器组（pod）IP 缺少路由。  |  无  | 
|  MissingIPRules  |  事件  |  容器组（pod）IP 缺少规则。  |  无  | 
|  MissingLoopbackInterface  |  条件  |  此实例缺少环回接口，导致服务失败，具体取决于本地连接。  |  Replace（替换）  | 
|  NetworkSysctl  |  事件  |  此节点的网络 `sysctl` 设置可能不正确。  |  无  | 
|  PPSExceeded  |  事件  |  因双向 PPS 超过实例的最大值，数据包已排队或被丢弃。  |  无  | 
|  PortConflict  |  事件  |  如果容器组（pod）使用 hostPort，则可能写入会覆盖主机已经绑定端口的 `iptables` 规则，这可能会阻止 API 服务器访问 `kubelet`。  |  无  | 
|  UnexpectedRejectRule  |  事件  |  在 `iptables` 中发现了可能阻止预期流量的异常 `REJECT` 或 `DROP` 规则。  |  无  | 

## 节点存储运行状况问题
<a name="node-health-Storage"></a>

监控条件是下表中严重性为“状况”的问题的 `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 平均集群大小很小，这表示可用空间碎片过多。这可能会阻止文件创建，尽管有索引节点或可用空间可用。  |  无  | 

## 配置节点监控代理
<a name="node-monitoring-agent-configure"></a>

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（数据中心 GPU 管理器）服务器组件（`nv-hostengine`）。此组件仅在属于 NVIDIA GPU 实例类型的节点上运行，如代理的 [Helm 图表](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml)中的 `nodeAffinity` 所示。您无法将现有的 NVIDIA DCGM 安装与 EKS 节点监控代理配合使用，如有此功能需求，请通过 EKS 路线图 [GitHub issue \$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 集群中的节点
<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 表示容器运行时（containererd 等）是否正常运行并能运行容器。  |  30m  |  Replace（替换）  | 
|  DiskPressure  |  DiskPressure 是一个标准的 Kubernetes 状况，表示节点正在经历磁盘压力（磁盘空间不足或 I/O 过高）。  |  不适用  |  无  | 
|  KernelReady  |  KernelReady 表示内核是否运行正常，无严重错误、死锁或资源耗尽问题。  |  30m  |  Replace（替换）  | 
|  MemoryPressure  |  MemoryPressure 是一个标准的 Kubernetes 状况，表示节点正在经历内存压力（可用内存不足）。  |  不适用  |  无  | 
|  NetworkingReady  |  NetworkingReady 表示节点的网络堆栈（接口、路由、连接）是否正常运行。  |  30m  |  Replace（替换）  | 
|  StorageReady  |  StorageReady 表示节点的存储子系统（磁盘、文件系统、I/O）是否正常运行。  |  30m  |  Replace（替换）  | 
|  Ready  |  Ready 是标准的 Kubernetes 状况，表示节点运行正常并已准备好接收容器组（pod）。  |  30m  |  Replace（替换）  | 

默认情况下，EKS 自动节点修复操作在以下场景中处于禁用状态。在每个场景中，正在进行的节点修复操作仍在继续。有关如何覆盖这些默认设置的信息，请参阅 [配置自动节点修复](#configure-node-repair)。

 **EKS 托管式节点组** 
+ 节点组的节点数量超过五个，并且节点组中超过 20% 的节点运行状况不佳。
+ 集群的可用区转移通过应用程序恢复控制器（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 分钟后重启。

# 查看节点运行状况检查状态
<a name="learn-status-conditions"></a>

本主题介绍可用于监控 Amazon EKS 集群中节点运行状况检查状态的工具和方法。这些信息涵盖有助您识别和诊断节点级别问题的节点状况、事件和检测案例。使用本文描述的命令和模式来检查节点运行状况资源、解释状态条件，以及分析节点事件以进行运行故障排除。

您可以对所有节点使用 Kubernetes 命令来获取节点的某些运行状况信息。如果您通过 Amazon EKS 自动模式或 Amazon EKS 托管式附加组件使用节点监控代理，则将可获得更多种类的节点信号来帮助进行故障排除。对于节点监控代理检测到的运行状况问题，相关描述也可以在可观测性控制面板中查看。有关更多信息，请参阅 [使用 EKS 节点监控代理检测节点运行状况问题](node-health-nma.md)。

## 节点状况
<a name="status-node-conditions"></a>

节点状况表示需要采取补救措施（例如更换实例或重启实例）的终端问题。

 **获取所有节点的状况：**

```
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
```

## 节点事件
<a name="status-node-events"></a>

节点事件指示暂时性问题或配置不佳问题。

 **获取节点监控代理报告的所有事件** 

当节点监控代理可用时，您可以运行以下命令。

```
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
```

## 常用故障排除命令
<a name="status-node-troubleshooting"></a>

```
# 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 检索托管式节点的节点日志
<a name="auto-get-logs"></a>

了解如何检索具有节点监控代理的 Amazon EKS 托管式节点的节点日志。

## 先决条件
<a name="_prerequisites"></a>

确保您已满足以下条件：
+ 一个具有节点监控代理的现有 Amazon EKS 集群。有关更多信息，请参阅 [检测节点运行状况问题并启用自动节点修复](node-health.md)。
+ 已安装并配置好 `kubectl` 命令行工具，以便与您的集群通信。
+ 已安装 AWS CLI 并登录，并且拥有创建 S3 存储桶和对象的充分权限。
+ 已安装 Python 3 的最新版本
+ 已安装适用于 Python 3、Boto 3 的 AWS SDK。

## 第 1 步：创建 S3 存储桶目标（可选）
<a name="_step_1_create_s3_bucket_destination_optional"></a>

如果您还没有用来存储日志的 S3 存储桶，请创建一个。使用以下 AWS CLI 命令。存储桶默认为 `private` 访问控制列表。将 *bucket-name* 替换为您选择的唯一存储桶名称。

```
aws s3api create-bucket --bucket <bucket-name>
```

## 第 2 步：创建用于 HTTP Put 的预签名 S3 URL
<a name="_step_2_create_pre_signed_s3_url_for_http_put"></a>

Amazon EKS 通过对您指定的 URL 执行 HTTP PUT 操作来返回节点日志。在本教程中，我们将生成一个预签名的 S3 HTTP PUT URL。

日志将以 gzip 压缩包的形式返回，扩展名为 `.tar.gz`。

**注意**  
您必须使用 AWS API 或 SDK 创建预签名的 S3 上传 URL，以便 EKS 上传日志文件。您无法使用 AWS CLI 创建预签名的 S3 上传 URL。

1. 确定要用于存储桶日志的位置。例如，可能将 *2024-11-12/logs1.tar.gz* 作为键。

1. 将以下 Python 代码保存到 *presign-upload.py* 文件中。替换 *<bucket-name>* 和 *<key>*。键应以 `.tar.gz` 结尾。

   ```
   import boto3; print(boto3.client('s3').generate_presigned_url(
      ClientMethod='put_object',
      Params={'Bucket': '<bucket-name>', 'Key': '<key>'},
      ExpiresIn=1000
   ))
   ```

1. 运行脚本

   ```
   python presign-upload.py
   ```

1. 记下 URL 输出。在下一步中，请将此值用作 *http-put-destination*。

有关更多信息，请参阅适用于 Python 的 AWS Boto3 SDK 文档中的 [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 步：创建节点诊断资源
<a name="_step_3_create_nodediagnostic_resource"></a>

确定需要从中收集日志的节点的名称。

创建一个 `NodeDiagnostic` 清单，将节点名称作为资源名称，并提供 HTTP PUT URL 目标位置。

```
apiVersion: eks.amazonaws.com/v1alpha1
kind: NodeDiagnostic
metadata:
    name: <node-name>
spec:
    logCapture:
        destination: http-put-destination
```

将清单应用于集群。

```
kubectl apply -f nodediagnostic.yaml
```

您可以通过描述 `NodeDiagnostic` 资源来检查收集状态：
+ 如果状态为 `Success` 或 `SuccessWithErrors`，则表示任务已完成且日志已上传到提供的目标位置（`SuccessWithErrors` 表示可能缺失某些日志）
+ 如果状态为“失败”，请确认上传 URL 格式正确且未过期。

```
kubectl describe nodediagnostics.eks.amazonaws.com/<node-name>
```

## 第 4 步：从 S3 下载日志
<a name="_step_4_download_logs_from_s3"></a>

等待大约一分钟，然后再尝试下载日志。然后使用 S3 CLI 下载日志。

```
# Once NodeDiagnostic shows Success status, download the logs
aws s3 cp s3://<bucket-name>/key ./<path-to-node-logs>.tar.gz
```

## 第 5 步：清除节点诊断资源
<a name="_step_5_clean_up_nodediagnostic_resource"></a>
+  `NodeDiagnostic` 资源不会被自动删除。获取日志构件后，您需要自行清理这些文件

```
# Delete the NodeDiagnostic resource
kubectl delete nodediagnostics.eks.amazonaws.com/<node-name>
```

## NodeDiagnostic `node` 目标
<a name="_nodediagnostic_node_destination"></a>

从 Node Monitoring Agent 的 `v1.6.0` 版本开始，可以选择将日志收集目标设置为 `node`。使用此目标将导致日志在节点上收集并临时保留，以供后续收集。除此功能外，节点监控代理的 GitHub 存储库中还有一个 `kubectl` 插件，您可以安装该插件以便于交互和日志收集。有关更多信息，[请参阅 `kubectl ekslogs` 插件的文档](https://github.com/aws/eks-node-monitoring-agent/blob/main/tools/kubectl-ekslogs/README.md)。

## 示例用法
<a name="_example_usage"></a>

```
# Collect NodeDiagnostic logs from a single node
kubectl ekslogs <node-name>

# Collect NodeDiagnostic logs from multiple nodes
kubectl ekslogs <node-name-1> <node-name-2> <node-name-3>

# Collect NodeDiagnostic logs from all nodes with a specific label
kubectl ekslogs -l <key>=<value>
```