aws-node CNI IPAM Daemon Diagnosis¶
概念概覽
精確失敗訊號：:50051 gRPC Port¶
核心知識¶
精確失敗訊號：:50051 gRPC Port¶
aws-node Pod 呈 ½ Running 並反覆 CrashLoopBackOff 時，查看 describe events 會看到：
Warning Unhealthy kubelet Readiness probe failed: {"msg":"timeout: failed to connect service \":50051\" within 5s"}
Warning Unhealthy kubelet Liveness probe failed: {"msg":"timeout: failed to connect service \":50051\" within 5s"}
這代表 IPAM daemon 無法啟動，而不是網路連線問題。
init container 正常 ≠ CNI 正常¶
aws-vpc-cni-init init container 成功完成（CNI init container done）只代表 CNI binary 安裝到 host 上，與主容器 IPAM daemon 是否能啟動無關。IPAM daemon 需要呼叫 EC2 API 才能獲取 ENI 資訊。
三層排查：hop limit / SG / IAM Policy¶
hop limit（常見誤導）¶
實測確認 eksctl 建立的 nodegroup 的 hop limit 通常已為 2，不是 AWS 預設的 1。不要在未實測前就假設 hop limit 是根因。確認方式：
aws ec2 describe-instances --instance-ids <id> \
--query 'Reservations[0].Instances[0].MetadataOptions'
Security Group¶
Outbound 全開（0.0.0.0/0）、Inbound 含 SG 互通規則時，SG 通常不是根因。
IAM Node Role vs IRSA¶
# 確認是否使用 IRSA
kubectl get sa aws-node -n kube-system -o jsonpath='{.metadata.annotations}'
# annotation 為 null → 使用 node IAM role，非 IRSA
使用 node IAM role（非 IRSA） 時，AmazonEKS_CNI_Policy 必須附加在 Node Instance Role 上，否則 IPAM daemon 無法呼叫 EC2 API，卡在 Checking for IPAM connectivity...。
經驗教訓¶
-
hop limit=1 假設是常見誤導，必須實測確認後再採取行動，否則浪費時間
-
aws-node ½ Running 的根因診斷要同時確認 hop limit、SG、IAM Policy 三個面向
-
init container 成功不等於 CNI 正常，兩者解決不同問題
常見陷阱¶
-
hop limit 預設假設是常見陷阱——eksctl 建立的 ng 通常已設 hop limit=2，不要未測就修改
-
init container 正常完成不代表 CNI 正常，主容器 IPAM daemon 還需要 EC2 API 存取
-
aws-node ServiceAccount annotation 為 null 代表用 node IAM role，此時必須確認 AmazonEKS_CNI_Policy 已附加
最佳實踐¶
-
建立 ng 前先確認 Node Role 附加 AmazonEKS_CNI_Policy：aws iam list-attached-role-policies
-
使用 IRSA 而非 node IAM role，更安全且符合最小權限原則
-
aws-node 診斷順序：½ Running → probe :50051 → init container → hop limit 實測 → IAM Policy
相關概念¶
- EKS Cluster Version Upgrade
- EKS Node Group Migration Runbook
- Istio Cross-Namespace xDS Authentication
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-23 | 030a873f-a7ad-47be-aaa1-7556ee57df36 | 推翻 hop limit=1 假設、確認 :50051 gRPC 為精確失敗訊號、釐清 IRSA vs Node IAM Role 對 aws-node 的影響 |