EKS CNI Metrics Helper中ec2ApiErrCount非零但CloudTrail无对应日志排查

需要检查的因素与日志 #

1. CloudTrail配置与查询优化 #

• 事件过滤条件补充：当前查询未筛选错误事件，需添加filter ispresent(errorCode)定位含错误的记录；同时确认CloudTrail是否开启数据事件，部分EC2数据平面API默认仅记录管理事件。
• 区域覆盖验证：EC2 API调用是区域级操作，确保CloudTrail监控了EKS集群所在的所有区域，避免跨区域调用的事件未被捕获。
• 时间范围匹配：CloudTrail事件存在数分钟到数小时的延迟，需确保查询时间范围完全覆盖ec2ApiErrCount指标出现非零的时间段。
• UserAgent规则调整：部分版本EKS CNI的UserAgent为amazon-vpc-cni-k8s，可将查询规则改为userAgent like "amazon-vpc-cni%"扩大匹配范围。
• 事件排除规则检查：查看CloudTrail的事件选择器，确认是否排除了CNI高频调用的EC2 API（如DescribeNetworkInterfaces）。

2. EKS CNI插件Pod日志 #

直接查看aws-node Pod日志是最直接的排查方式，CNI会在日志中详细记录EC2 API调用的错误细节：

kubectl logs -n kube-system -l app=aws-node --tail=100 | grep -i "error\|ec2\|api"

这些日志包含错误类型、调用接口、具体报错信息，不受CloudTrail记录限制，能快速定位问题根源。

3. Metrics Helper Pod日志 #

若Metrics Helper为单独部署的Pod，查看其日志可验证指标统计逻辑是否存在问题（如重复计数、误判非EC2 API错误）：

kubectl logs -n kube-system -l app=eks-cni-metrics-helper --tail=100

4. IAM权限验证 #

确认CloudTrail的IAM角色拥有cloudtrail:PutEvent等必要权限；同时检查aws-node Pod的IAM角色权限完整性，若缺少ec2:DescribeNetworkInterfaces、ec2:CreateNetworkInterface等权限，会触发ec2ApiErrCount计数。

ec2ApiErrCount显示非零值的可能原因 #

• 客户端侧网络错误：CNI Pod与EC2 API服务端之间的网络超时、DNS解析失败、TCP连接重置等，这类错误因请求未到达EC2服务端，不会被CloudTrail记录，但会被CNI计数。
• EC2 API限流（Throttling）：CNI调用EC2 API过于频繁时会触发ThrottlingException，这类错误会被CloudTrail记录，需添加filter errorCode = "ThrottlingException"到查询语句中才能看到。
• 权限不足错误：aws-node角色缺少必要EC2权限时会触发AccessDenied错误，这类错误会被CloudTrail记录，需添加filter errorCode = "AccessDenied"筛选。
• CNI重试逻辑计数：CNI会自动重试失败的API调用，ec2ApiErrCount统计所有失败尝试（包括重试失败），而CloudTrail可能仅记录最终成功的调用，或重试失败记录未被当前查询筛选到。
• 未被CloudTrail记录的API操作：极少数EC2数据平面API默认不被CloudTrail记录，这类调用的错误仅出现在CNI Pod日志中。
• Metrics统计逻辑误差：Metrics Helper的统计逻辑可能存在小范围误差，如短暂网络波动导致的指标误报，可通过对比CNI日志与指标时间戳验证。

内容的提问来源于stack exchange，提问作者Wilson Liao