PLEG の問題が原因で NotReady ステータスになる Amazon EKS ワーカーノードをトラブルシューティングする方法を教えてください。

所要時間2分

Pod Lifecycle Event Generator (PLEG) が正常でないため、Amazon Elastic Kubernetes Service (Amazon EKS) ワーカーノードが NotReady または Unknown ステータスになります。

解決方法

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 が異常になりました。
ワーカーノードに多数のポッドがある場合、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)"

これらのログを使用して、障害が発生しているポッドを特定します。識別されたポッドについては、ヘルスプローブが正しく設定されていることを確認します。

ワーカーノードのリソース使用状況をモニタリングします

OOM の問題や CPU 使用率の高さによるリソース不足など、インスタンスレベルの問題がないかどうかを確認します。

基盤となる Amazon Elastic Compute Cloud (Amazon EC2) ワーカーノードの CPU 使用率メトリクスをモニタリングします。このメトリクスをチェックして、突然の急上昇がないか、または CPU 使用率が 100% に達していないかを確認してください。

Kubelet は、設定された猶予期間に関係なく、ノードがハードエビクションまたはソフトエビクションの閾値に達すると、ノードにプレッシャーがかかっていると報告します。ノードの状態を確認するには、次のコマンドを実行します。

$ kubectl describe node <node_name>

ノードの状態が出力に MemoryPressure と表示されているかどうかを確認します。このような場合、リソースが使用できないためにインスタンスが停止する可能性があります。これにより、プロセスが応答しなくなる可能性があります。

リソース不足による問題を軽減するには、ポッドの CPU とメモリの使用率の上限を設定するのがベストプラクティスです。

コンテナにリソース制限を指定すると、kubelet はこれらの制限を適用します。実行中のコンテナの使用は、これらの制限を超えることはできません。これにより、ポッドが必要以上にメモリを消費することがなくなり、OOM の問題が防止されます。詳細については、Kubernetes ウェブサイトの「ポッドとコンテナのリソース管理」を参照してください。

また、コンテナインサイトを使用して、コンテナ化されたアプリケーションやマイクロサービスからメトリクスやログを収集、集計、要約することも検討してください。詳細については、「Amazon EKS と Kubernetes コンテナインサイトのメトリクス」を参照してください。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 をモニタリングしてください。