如何对由于 PLEG 问题而进入“NotReady”（未就续）状态的 Amazon EKS Worker 节点进行故障排查？

解决方法

当您的 Amazon EKS 集群中的 Worker 节点进入 NotReady（未就续）或 Unknown（未知）状态时，在该节点上计划的工作负载就会中断。要排查此问题，请执行以下操作：

通过运行以下命令获取有关该 Worker 节点的信息：

$ kubectl describe node node-name

在输出中，查看 Conditions（条件）部分以找出问题的原因。

示例：

KubeletNotReady  PLEG is not healthy: pleg was last seen active xx

PLEG 未正常运行的最常见原因如下：

• Kubelet 无法与 Docker 进程守护程序通信，因为该进程守护程序正忙或已停止运行。例如，您的 EKS Worker 节点上的 Docker 进程守护程序可能已损坏。
• 实例级别的内存不足（OOM）或 CPU 利用率问题导致 PLEG 变得无法正常运行。
• 如果 Worker 节点有大量容器组，kubelet 和 Docker 进程守护程序可能会遇到更高的工作负载，从而导致 PLEG 相关错误。如果频繁探测活跃度或就绪状态，也可能会导致工作负载增加。

查看 kubelet 日志

您可以检查实例的 kubelet 日志，以确定 PLEG 未正常运行的原因。

1.    使用 SSH 连接到实例并运行以下命令：

$ journalctl -u kubelet > kubelet.log

如果您使用的是 Amazon EKS 优化的 AMI 且未启用 SSH，可以使用 SSM 进行连接。有关更多信息，请参阅使用 Session Manager 连接到 Linux 实例。

2.    查看 kubelet 在这些日志中发布的 PLEG 相关事件：

示例：

28317 kubelet.go:1873] "Skipping pod synchronization" err="PLEG is not healthy: pleg was last seen active 4h5m43.659028227s ago; threshold is 3m0s"
28317 kubelet.go:1873] "Skipping pod synchronization" err="PLEG is not healthy: pleg was last seen active 4h5m48.659213288s ago; threshold is 3m0s"

3.    查看 kubelet 日志，看看是否有未准备就绪的容器组和活跃度探测失败情况。这些日志消息看起来类似以下内容：

"Probe failed" probeType="Liveness" pod="nginx/bus" podUID=2527afb7-b32c-4c84-97e2-246eb48c97a9 containerName="nginx" probeResult=failure output="Get \"http://192.168.154.18:15020/app-health/livez\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)"

使用这些日志来识别出现故障的容器组。对于已识别的容器组，请检查并确保正确配置了运行状况探测。

监控 Worker 节点资源使用情况

检查是否存在任何实例级别的问题，例如由于 OOM 问题或 CPU 利用率过高导致的资源紧张。

监控底层 Amazon Elastic Compute Cloud（Amazon EC2）Worker 节点的 CPU 利用率指标。检查此指标以查看是否出现突然峰值或 CPU 利用率是否达到 100%。

Kubelet 报告说，无论配置的宽限期如何，当节点达到硬驱逐或软驱逐阈值时，节点都会承受压力。您可以通过运行以下命令来检查节点状况：

$ kubectl describe node <node_name>

检查输出中的节点条件是否指示 MemoryPressure。在这些情况下，由于资源不可用，实例可能会停止运行。这可能会导致进程变得无响应。

为了缓解资源紧张造成的问题，最佳做法是为容器组设置 CPU 和内存利用率限制。

当您为容器指定资源限制时，kubelet 会强制执行这些限制。正在运行的容器的使用情况不得超过这些限制。这样可以防止容器组占用超过需要的内存，从而防止出现 OOM 问题。有关更多信息，请参阅 Kubernetes 网站上的容器组和容器的资源管理。

此外，还可以考虑使用 Container Insights 来收集、聚合和汇总容器化应用程序和微服务的指标和日志。有关更多信息，请参阅 Amazon EKS 和 Kubernetes Container Insights 指标。您可以使用 node_cpu_utilization 和 node_memory_utilization 来监控节点级别的资源利用率。您还可以设置警报，以便在达到特定阈值时收到通知。

监控根 Amazon EBS 卷性能

由于您的 Amazon Elastic Block Store（Amazon EBS）卷存在磁盘问题，PLEG 可能未正常运行。在这种情况下，kubelet 日志看起来类似以下内容：

fs: disk usage and inodes count on following dirs took 1.262610491s: [/var/lib/docker/overlay2/709e904d843733d746e5134e55e3c6553db4c0f5297d5e3c3a86c206bcb6b172/diff /var/lib/docker/containers/158725d2d97578713034c5f5c16291a068349b7e989b417324c142bb584f79ad]; will not log again for this container unless duration exceeds 2s

当使用实例上的容器组的应用程序对磁盘执行密集的 I/O 操作时，就会发生这种情况。

您可以使用 Amazon EBS 的 Amazon CloudWatch 指标来监控 Amazon EBS 卷的 IOPS 利用率和吞吐量。

可使用以下 CloudWatch 指标来监控 Amazon EBS 卷的吞吐量和 IOPS：

• VolumeReadOps
• VolumeWriteOps
• VolumeReadBytes

例如，您可以使用以下公式计算以每秒操作数（ops/s）为单位的平均 IOPS：

((VolumeReadOps) + (VolumeWriteOps)) / (Period)

您可以使用以下公式计算以字节/秒为单位的平均吞吐量：

((VolumeReadBytes) + (VolumeWriteBytes)) / (Period)

有关更多信息，请参阅我该如何使用 CloudWatch 指标来计算我的 EBS 卷所提供的平均吞吐量和平均 IOPS 数量？

要解决此问题，请考虑增加磁盘大小或更改 EBS 卷类型，以实现更好的 I/O 吞吐量。

---