如何針對因 PLEG 問題而進入 NotReady 狀態的 Amazon EKS 工作節點進行疑難排解？

解決方案

當 Amazon EKS 叢集中的工作節點進入 NotReady 或 Unknown 狀態時，該節點上排程的工作負載會中斷。若要對此問題進行疑難排解，請執行以下操作：

執行下列命令以取得工作節點的相關資訊：

$ kubectl describe node node-name

在輸出中，檢查狀況區段以找出問題的原因。

範例：

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

PLEG 運作狀態不良的最常見原因如下：

• Kubelet 無法與 Docker 常駐程式通訊，因為常駐程式忙碌或無效。例如，EKS 工作節點上的 Docker 常駐程式可能已中斷。
• 執行個體層級的記憶體不足 (OOM) 或 CPU 使用率問題造成 PLEG 運作狀態不良。
• 如果工作節點有大量的 Pod，kubelet 和 Docker 常駐程式可能會遇到較高的工作負載，進而造成 PLEG 相關錯誤。如果系統經常探查活躍度或準備度，也可能導致較高的工作負載。

檢查 kubelet 日誌

您可以檢查執行個體上的 kubelet 日誌，以找出 PLEG運作狀況不良的原因。

1.    使用 SSH 連線到執行個體並執行下列命令：

$ journalctl -u kubelet > kubelet.log

如果您使用的是 Amazon EKS 最佳化 AMI，並且未啟用 SSH，則可以使用 SSM 連線。如需詳細資訊，請參閱使用工作階段管理員連線到 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 日誌以查看是否有任何未通過準備度和活躍度探查的 Pod。這些日誌訊息看起來類似下列內容：

"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)"

使用這些日誌來識別失敗的 Pod。對於已識別的 Pod，請檢查並確認運作狀態探查已正確設定。

監控工作節點資源使用情況

檢查是否存在任何執行個體層級問題，例如由於 OOM 問題或 CPU 使用率過高而導致資源緊縮。

監控底層 Amazon Elastic Compute Cloud (Amazon EC2) 工作節點的 CPU 使用率指標。檢查此指標來查看是否有任何的突發尖峰，或 CPU 使用率是否達到 100%。

Kubelet 回報當節點達到硬移出閾值或軟移出閾值時，不論設定的寬限期為何，節點均會受到壓力。您可以透過執行下列命令來檢查節點狀況：

$ kubectl describe node <node_name>

檢查節點狀況是否在輸出中顯示為 MemoryPressure。在這些情況下，執行個體可能會因為資源無法使用而停止。這可能會導致程序變得無回應。

若要緩解資源緊縮造成的問題，最佳做法是為 Pod 設定 CPU 和記憶體使用率限制。

當您指定容器的資源限制時，kubelet 會強制執行這些限制。正在執行容器的用量不允許超過這些限制。如此可避免 Pod 佔用超過所需的記憶體，進而防止 OOM 問題發生。如需詳細資訊，請參閱 Kubernetes 網站上 Pod 和容器的資源管理。

此外，請考慮使用 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

當在執行個體上使用 Pod 的應用程式根據磁碟執行密集的 I/O 操作時，就會發生這種情況。

您可以使用 Amazon EBS 的 Amazon CloudWatch 指標來監控 Amazon EBS 磁碟區的 IOPS 使用率和輸送量。

使用下列 CloudWatch 指標來監控 Amazon EBS 磁碟區的輸送量和 IOPS：

• VolumeReadOps
• VolumeWriteOps
• VolumeReadBytes

例如，您可以使用以下公式計算以操作數/秒為單位的平均 IOPS：

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

您可以使用以下公式計算以位元組/秒為單位的平均輸送量：

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

如需詳細資訊，請參閱如何使用 CloudWatch 指標來計算 EBS 磁碟區提供的平均輸送量和平均 IOPS 數目？

若要解決此問題，請考慮增加磁碟大小或變更 EBS 磁碟區類型，以達到較佳的 I/O 輸送量。

---