EKSのノードが突然消えたときの原因調査と監視対策メモ
本番環境でEKSを運用していると、
「Auto Scaling GroupにはEC2が存在しているのに、kubectl get nodesに表示されない」
という現象に突如直面することがあります。
ここでは、その原因と、再発防止のための監視方法をまとめています。
現象の概要
-
kubectl get nodesの結果にノードが表示されない -
kubectl get podsの出力で、PodがPendingのまま進まない - Auto Scaling Group (ASG) には正常な状態のEC2インスタンスが存在する
よくある原因と対処ミス
1. kubelet の起動失敗
- 以下のログで原因を確認する：
/var/log/messages/var/log/user-data.logjournalctl -u kubelet
- 主な原因：
-
bootstrap.shの実行失敗 - ネットワークの不具合
- TLS証明書エラーなど
-
2. IAM Role に必要な権限が不足
- ノードのIAMロールに以下のポリシーが必要：
AmazonEKSWorkerNodePolicyAmazonEKS_CNI_PolicyAmazonEC2ContainerRegistryReadOnly
- これらが欠けていると、kubeletがEKS APIと通信できずノード登録に失敗
3. 古いノードの再起動による不一致
- 以前クラスタから削除したノードと同じ名前でEC2が起動すると、
EKS側では「すでに削除済みのノード」とみなされ、再登録されないことがある
実際に発生したときの対処法
- 該当のEC2インスタンスをASGからデタッチして削除
- ASGが新しいインスタンスを自動起動
- 新しいノードがEKSに正常参加 →
kubectl get nodesでReady確認
本番環境での予防策
☑ Auto Scaling GroupのminSizeを1以上に設定
- 常に少なくとも1台のノードを維持するようにしておく
☑ Fargate profile を作成
- ラベルやネームスペースでPodをFargateへ振り分けることで、ノード依存を軽減
☑ EC2に監視スクリプトを配置
- 定期的に
curlやkubectl get nodesを実行してクラスタの状態を確認
監視スクリプト例
サイトの疎通確認
#!/bin/bash
URL="https://your-service.example.com"
STATUS=$(curl -s -o /dev/null -w "%{http_code}" $URL)
if [ "$STATUS" -ne 200 ]; then
echo "$(date): Site unreachable! HTTP $STATUS" >> /var/log/eks-site-health.log
fi
ノードのReady状態確認
#!/bin/bash
READY_NODES=$(kubectl get nodes --no-headers | grep -c " Ready")
if [ "$READY_NODES" -eq 0 ]; then
echo "$(date): No ready nodes!!" >> /var/log/eks-nodes.log
fi
まとめ
- EC2インスタンスが存在していても、EKSがそれを「ノード」として認識しているかどうかが重要
- 「ASGにはインスタンスがあるのに、ノードとして見えない」という状況は、
多くの場合 kubeletの起動失敗 や IAM設定ミス が原因 - 発生したら該当インスタンスをASGから外してやり直すのが手っ取り早い
- 監視スクリプトを導入して、異常をすぐに検知できるようにしておく
ちなみに、
なぜかノードグループからインスタンスが勝手に外れることがある理由は、まだよくわかっていません……。