AWS EKS集群无明显原因启停异常，访问时出现503错误求助
2026-7-17
排查步骤建议
一、Ingress 与负载均衡层排查
- 检查ALB/NLB目标组健康状态：登录AWS控制台找到对应负载均衡的目标组，查看访问出现503时，目标实例（Pod对应的节点ENI）的健康检查失败记录，确认是否是临时健康检查失败导致流量被切走，或是健康检查配置（超时、阈值）过于严格，Pod短暂响应慢就被标记为不健康。
- 查看Ingress Controller日志：若使用AWS Load Balancer Controller，执行
kubectl logs -n kube-system deployment/aws-load-balancer-controller查看日志，搜索503相关条目，排查是否存在流量路由异常、目标组同步错误等信息。 - 验证Pod端口监听状态：在问题Pod所在节点执行
netstat -tulpn | grep <pod-port>，确认容器内端口是否持续监听，有没有短暂停止监听的情况。
二、Pod 与应用层排查
- 查看Pod事件日志：执行
kubectl describe pod <pod-name>，重点检查事件列表中是否有重启、OOMKilled、容器退出记录，哪怕是短暂重启也会引发503。 - 抓取应用容器日志：用
kubectl logs <pod-name> --previous查看容器重启前的日志（若有重启），或用kubectl logs -f <pod-name>实时查看日志，结合访问时间点排查应用内部是否存在未被Newrelic捕获的异常——比如部分异常处理程序仅吞掉错误未记录日志，或是Newrelic Agent配置遗漏了某些日志路径。 - 关联CPU飙升事件：确认6月26日10点的CPU飙升是单个Pod CPU突增，还是集群节点整体CPU上升。用
kubectl top pods（或查看历史监控）定位引发CPU上涨的Pod，确认这些Pod是否与出现503的服务相关。CPU达60%本身一般不会直接导致服务停止，但如果应用是单线程、CPU绑定类型，可能因CPU占满无法处理请求，触发健康检查失败。
三、集群组件层面排查
- 检查kubelet日志：在出现问题的节点上查看kubelet日志（AWS EKS节点路径一般为
/var/log/kubelet.log），搜索是否存在Pod被驱逐、容器运行时（containerd/docker）异常的记录。 - 排查节点隐性资源瓶颈：尽管内存、磁盘使用率正常，仍需检查节点的**CPU节流（CPU Throttling）**情况。执行
kubectl describe node <node-name>查看Conditions中的CPUThrottlingHigh状态，或通过监控工具查看Pod的CPU节流指标——若Pod的CPU请求设置过低，实际使用超过请求时会被kubelet节流，导致应用响应变慢甚至无法处理请求。 - 检查集群DNS服务：若服务间调用依赖DNS，短暂的DNS解析失败也可能引发503。查看CoreDNS日志
kubectl logs -n kube-system deployment/coredns，排查是否存在解析超时、错误的记录。
四、监控盲区补充排查
- 手动触发健康检查：模拟负载均衡的健康检查请求（如
curl <pod-ip>:<port>/health-check-path），在出现503的时间段内持续执行，确认是服务本身无法处理健康检查，还是负载均衡的路由问题。 - 验证Newrelic配置：确认Newrelic Agent是否正确采集了应用的所有错误日志，比如是否配置了忽略某些错误级别，或是应用的异常处理程序未抛出可被Agent捕获的异常（仅返回503但未记录错误栈）。
内容的提问来源于stack exchange，提问作者johnny68
相关产品推荐
相关产品推荐
