帮助改进此页面
要帮助改进本用户指南,请选择位于每个页面右侧窗格中的在 GitHub 上编辑此页面链接。
启用节点自动修复并调查节点运行状况问题
节点运行状况是指节点的运行状态以及有效运行工作负载的能力。运行正常的节点可以保持预期的连接,拥有充分的资源,并且可以在不中断的情况下成功运行容器组。要了解如何获取节点详细信息,请参阅查看节点运行状况检查状态和使用 kubectl 和 S3 检索托管式节点的节点日志。
为帮助保持运行正常的节点,Amazon EKS 提供了节点监控代理和节点自动修复功能。
重要
节点监控代理和节点自动修复功能仅支持 Linux。这些功能不支持 Windows。
节点监控代理
节点监控代理会自动读取节点日志以检测某些运行状况问题。此代理会解析节点日志以检测故障,并显示有关 Worker 节点的各种状态信息。对于检测到的每类问题(例如存储和联网问题),都会在 Worker 节点上应用一个专门的 NodeCondition。对于检测到的运行状况问题,相关描述可以在可观测性控制面板中查看。有关更多信息,请参阅 节点运行状况问题。
节点监控代理是所有 Amazon EKS 自动模式集群中都包含的一项功能。对于其他集群类型,您可以将监控代理作为 Amazon EKS 附加组件添加。有关更多信息,请参阅 创建 Amazon EKS 附加组件。
节点自动修复
节点自动修复是一项附加功能,可以持续监控节点的运行状况,自动对检测到的问题做出反应,并在可能的情况下更换节点。这有助于在尽可能减少手动干预的情况下提高集群的整体可用性。如果运行状况检查失败,则会自动封锁该节点,从而确保不会在该节点上调度新的容器组。
节点自动修复功能本身可以对 kubelet 的 Ready 状况以及任何手动删除的节点对象做出反应。与节点监控代理配合使用时,节点自动修复功能可以对更多原本无法检测到的状况做出反应。这些额外的状况包括 KernelReady、NetworkingReady 和 StorageReady。
这种自动节点恢复功能可自动解决间歇性节点问题,例如加入集群失败、kubelet 无响应以及加速器(设备)错误增加等。由于提高了可靠性,因此有助于减少应用程序停机时间并优化集群运行。节点自动修复无法处理报告的某些问题,例如 DiskPressure、MemoryPressure 和 PIDPressure。Amazon EKS 会等待 10 分钟后才针对 AcceleratedHardwareReady NodeConditions 执行操作,对于所有其他状况则会等待 30 分钟。
出于安全考虑,托管式节点组在这种两种情况下还将自动禁用节点修复。在这两种情况下,以前正在进行的任何修复操作都将继续执行。
-
如果通过应用程序恢复控制器(ARC)触发了集群可用区转移,则所有后续修复操作都将停止。
-
如果节点组的节点数量超过五个,并且节点组中超过 20% 的节点处于运行不正常状态,则修复操作也将停止。
您可以在创建或编辑托管式节点组时启用节点自动修复。
-
使用 Amazon EKS 控制台时,激活托管式节点组的启用节点自动修复复选框即可。有关更多信息,请参阅 为集群创建托管式节点组。
-
使用 Amazon CLI 时,请将
--node-repair-config enabled=true添加到eks create nodegroup或eks update-nodegroup-config命令中。 -
有关使用启用了节点自动修复功能的托管式节点组的示例
eksctlClusterConfig,请参阅 GitHub 上的 44-node-repair.yaml。
Amazon EKS 通过以下方式对节点自动修复行为提供更精细的控制:
-
maxUnhealthyNodeThresholdCount和maxUnhealthyNodeThresholdPercentage-
这些字段允许您指定运行状况不佳节点的计数或百分比阈值,超过该阈值时,节点自动修复操作将停止。这可以更好地控制节点自动修复的“影响范围”。
-
您可以设置绝对计数或百分比,但不能同时设置两者。
-
-
maxParallelNodesRepairedCount和maxParallelNodesRepairedPercentage-
这些字段允许您指定可以同时或并行修复的最大节点数,以所有运行状况不佳的节点的计数或百分比表示。这让您可以更精细地控制节点更换的速度。
-
与运行状况不佳的节点阈值一样,您可以设置绝对计数或百分比,但不能同时设置两者。
-
-
nodeRepairConfigOverrides-
这是一个复杂的结构,允许您为特定修复操作设置精细的覆盖。这些覆盖可控制节点被视为符合修复条件之前的修复操作和修复延迟时间。
-
此结构中的特定字段包括:
-
nodeMonitoringCondition:节点监控代理报告的运行状况不佳。 -
nodeUnhealthyReason:节点监控代理将节点识别为运行状况不佳的原因。 -
minRepairWaitTimeMins:在节点符合修复条件之前,修复状况和运行状况不佳原因必须持续存在的最短时间(以分钟为单位)。 -
repairAction:当满足上述条件时,修复系统应采取的措施。
-
-
如果使用此字段,则必须指定结构中的所有字段。您还可以提供这些覆盖的列表。
-
nodeMonitoringCondition和nodeUnhealthyReason是手动文本输入,您将其设置为表示要偏离系统的默认行为。 -
minRepairWaitTimeMins和repairAction字段允许您指定与系统默认行为的偏差。
-
节点运行状况问题
下表介绍了节点监控代理可能会检测到的节点运行状况问题。问题有两种类型:
AcceleratedHardware 节点运行状况问题
监控条件是下表中严重性为“状况”的问题的 AcceleratedHardwareReady。
如果启用了自动修复,则列出的修复操作将在检测到问题 10 分钟后开始。有关 XID 错误的更多信息,请参阅《NVIDIA GPU 部署和管理文档》中的 Xid Errors
| 名称 | 严重性 | 说明 |
|---|---|---|
|
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 库中出现段错误 ( |
|
NvidiaNVLinkError |
条件 |
GPU 驱动程序报告了 NVLink 错误。 |
|
NvidiaPCIeError |
事件 |
触发 PCIe 重播是为了从传输错误中恢复过来。 |
|
NvidiaPageRetirement |
事件 |
GPU 驱动程序已将内存页标记为停用。如果出现单个双比特错误或在同一地址遇到两个单比特错误,则可能会发生这种情况。 |
|
NvidiaPowerError |
事件 |
GPU 的功率利用率超过了允许的阈值。 |
|
NvidiaThermalError |
事件 |
GPU 的散热状态超过了允许的阈值。 |
|
NvidiaXID[Code]Error |
条件 |
出现严重的 GPU 错误。 |
|
NvidiaXID[Code]Warning |
事件 |
出现了非严重的 GPU 错误。 |
ContainerRuntime 节点运行状况问题
监控条件是下表中严重性为“状况”的问题的 ContainerRuntimeReady。
| 名称 | 严重性 | 说明 |
|---|---|---|
|
ContainerRuntimeFailed |
事件 |
容器运行时创建容器失败,如果反复发生,则可能与任何报告的问题有关。 |
|
DeprecatedContainerdConfiguration |
事件 |
使用已弃用映像清单版本 2、架构 1 的容器映像最近通过 |
|
KubeletFailed |
事件 |
kubelet 处于某个失败状态。 |
|
LivenessProbeFailures |
事件 |
检测到存活探针失败,如果反复发生,则可能指示应用程序代码问题或超时值不足。 |
|
PodStuckTerminating |
条件 |
容器组正在或曾经过长时间停滞在正在终止状态,这可能是因 CRI 错误阻止容器组状态进展造成的。 |
|
ReadinessProbeFailures |
事件 |
检测到就绪探针失败,如果反复发生,则可能指示应用程序代码问题或超时值不足。 |
|
[Name]RepeatedRestart |
事件 |
systemd 单元频繁重启。 |
|
ServiceFailedToStart |
事件 |
系统单元启动失败。 |
节点内核运行状况问题
监控条件是下表中严重性为“状况”的问题的 KernelReady。
| 名称 | 严重性 | 说明 |
|---|---|---|
|
AppBlocked |
事件 |
任务被长时间禁止调度,这通常是由于在输入或输出时被屏蔽所致。 |
|
AppCrash |
事件 |
节点上的应用程序已崩溃。 |
|
ApproachingKernelPidMax |
事件 |
根据当前 |
|
ApproachingMaxOpenFiles |
事件 |
按照当前内核设置,打开的文件数已接近可能打开的最大文件数,之后打开新文件将失败。 |
|
ConntrackExceededKernel |
事件 |
连接跟踪超出内核的最大值且无法建立新连接可能会导致数据包丢失。 |
|
ExcessiveZombieProcesses |
事件 |
无法完全回收的进程正在大量积累,这指示存在应用程序问题,并且可能导致达到系统进程限制。 |
|
ForkFailedOutOfPIDs |
条件 |
由于系统进程 ID 或内存不足,fork 或 exec 调用失败,这可能是僵尸进程或物理内存耗尽造成的。 |
|
KernelBug |
事件 |
Linux 内核本身检测到并报告了内核错误,但这有时可能是由节点的 CPU 或内存使用率过高,导致事件处理延迟造成的。 |
|
LargeEnvironment |
事件 |
此进程的环境变量数大于预期,这可能是因许多将 |
|
RapidCron |
事件 |
cron 作业在此节点上的运行速度超过每五分钟一次,如果该作业消耗大量资源,则可能会影响性能。 |
|
SoftLockup |
事件 |
CPU 在给定时间停滞。 |
节点联网运行状况问题
监控条件是下表中严重性为“状况”的问题的 NetworkingReady。
| 名称 | 严重性 | 说明 |
|---|---|---|
|
BandwidthInExceeded |
事件 |
因入站总带宽超过实例的最大值,导致数据包已排队或被丢弃。 |
|
BandwidthOutExceeded |
事件 |
因出站总带宽超过实例的最大值,导致数据包已排队或被丢弃。 |
|
ConntrackExceeded |
事件 |
连接跟踪超出实例的最大值且无法建立新连接,这可能会导致数据包丢失。 |
|
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 链接配置的值 |
|
MissingDefaultRoutes |
事件 |
缺少默认路由规则。 |
|
MissingIPRoutes |
事件 |
容器组(pod)IP 缺少路由。 |
|
MissingIPRules |
事件 |
容器组(pod)IP 缺少规则。 |
|
MissingLoopbackInterface |
条件 |
此实例缺少环回接口,导致服务失败,具体取决于本地连接。 |
|
NetworkSysctl |
事件 |
此节点的网络 |
|
PPSExceeded |
事件 |
因双向 PPS 超过实例的最大值,数据包已排队或被丢弃。 |
|
PortConflict |
事件 |
如果容器组(pod)使用 hostPort,则可能写入会覆盖主机已经绑定端口的 |
|
UnexpectedRejectRule |
事件 |
在 |
节点存储运行状况问题
监控条件是下表中严重性为“状况”的问题的 StorageReady。
| 名称 | 严重性 | 说明 |
|---|---|---|
|
EBSInstanceIOPSExceeded |
事件 |
已超过实例的最大 IOPS。 |
|
EBSInstanceThroughputExceeded |
事件 |
已超过实例的最大吞吐量。 |
|
EBSVolumeIOPSExceeded |
事件 |
已超过特定 EBS 卷的最大 IOPS。 |
|
EBSVolumeThroughputExceeded |
事件 |
已超过特定 Amazon EBS 卷的最大吞吐量。 |
|
EtcHostsMountFailed |
事件 |
由于在 |
|
IODelays |
事件 |
在进程中检测到输入或输出延迟,如果过长,则可能表明预调配的输入输出读写操作次数不足。 |
|
KubeletDiskUsageSlow |
事件 |
|
|
XFSSmallAverageClusterSize |
事件 |
XFS 平均集群大小很小,这表示可用空间碎片过多。这可能会阻止文件创建,尽管有索引节点或可用空间可用。 |