EKS集群中AWS ALB Ingress性能异常低下的排查与调试方案问询

云上老周

2026-4-29

排查EKS中ALB Ingress性能瓶颈的步骤

根据你的描述，直接访问Pod或通过NodePort访问时性能正常，但通过ALB Ingress访问时性能差2-3倍，问题确实集中在ALB到Pod的路径上。咱们从以下几个方向逐步排查：

1. 先检查ALB本身的状态和配置

查看目标组健康状态：登录AWS控制台，进入EC2 -> 负载均衡器 -> 对应的ALB -> 目标组，确认所有关联的Pod都处于健康状态，没有频繁的健康检查失败。如果部分Pod被标记为不健康，ALB会把流量集中到少数健康Pod上，导致性能下降。同时检查健康检查的阈值设置（比如间隔时间、失败次数），避免过于严格的规则导致Pod被频繁剔除。
确认ALB与Pod的AZ一致性：查看ALB所在的可用区，是否和你的Pod所在AZ完全匹配？跨AZ的流量会带来额外的延迟和带宽损耗，如果ALB和Pod不在同一个AZ，可能会显著影响性能。
分析ALB访问日志：开启ALB的访问日志（在ALB配置中指定S3存储桶），日志里的几个关键指标能帮你定位耗时环节：
- request_processing_time：ALB处理请求的时间（比如路由、SSL终止）
- target_processing_time：Pod处理请求的时间
- response_processing_time：ALB处理响应的时间
  如果request_processing_time偏高，可能是ALB本身的SSL终止开销过大；如果target_processing_time远高于直接访问Pod的耗时，说明ALB到Pod的网络存在问题。

查看控制器日志：执行以下命令查看Ingress控制器的运行日志，排查是否有配置同步错误或异常：
```
kubectl logs -n kube-system deployment/aws-load-balancer-controller
```
重点关注目标组同步、证书绑定、Ingress规则解析相关的日志，比如你的SSL重定向规则是否正常生效，有没有导致额外的请求跳转（虽然你测试的是HTTPS端点，但仍需确认）。
验证安全组配置：你使用了target-type: ip模式，ALB会直接访问Pod的IP，因此需要确保：
- ALB的安全组允许出站访问Pod所在安全组的80端口
- Pod的安全组允许来自ALB安全组的入站流量
  安全组的限制可能导致连接建立缓慢、丢包，进而影响性能。

测试ALB到Pod的延迟差异：在同一个VPC的EC2实例或Pod中，分别测试ALB端点和Pod IP的延迟：
```
# 测试ALB延迟
curl -w "%{time_total}\n" https://k8s-default-ingre-fdeb4c8b98-1975505070.us-east-1.elb.amazonaws.com/
# 测试Pod延迟
curl -w "%{time_total}\n" http://172.16.3.37/
```
如果两者延迟差异明显，说明ALB到Pod的网络路径存在问题。可以用mtr工具跟踪路由，查看是否有丢包或高延迟的节点；也可以在Pod所在节点上用tcpdump抓包，分析TCP连接的建立和传输情况。
检查VPC CNI配置：如果使用EKS默认的VPC CNI，确认节点的Pod IP分配是否充足（避免Pod被调度到跨AZ节点），同时确保CNI版本是最新的，旧版本可能存在网络性能问题。
查看TCP连接状态：在Pod所在节点上执行ss -s，查看TCP连接的状态分布。如果存在大量TIME_WAIT连接，可能是应用或ALB的Keep-Alive配置不当，导致每次请求都需要建立新的TCP连接，增加开销。

验证Service配置：检查你的app Service的配置，确认：
- sessionAffinity是否设置为ClientIP？如果是，会导致ALB的连接被绑定到特定Pod，可能造成负载不均。
- externalTrafficPolicy是否与target-type: ip冲突？虽然ip模式下该配置会被忽略，但仍需确认没有异常设置。
测试HTTPS开销影响：你直接访问Pod用的是HTTP，而ALB用的是HTTPS，SSL终止会有一定性能开销，但通常不会差2-3倍。可以临时修改Ingress配置，只开启HTTP监听，测试HTTP端点的性能：
修改Ingress的listen-ports为：
```
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
```
然后用hey测试HTTP端点，对比和HTTPS的性能差异，判断是否是SSL终止导致的问题。

检查节点资源使用率：用kubectl top nodes查看Pod所在节点的CPU、内存、网络带宽使用情况，如果节点资源（尤其是CPU或带宽）已饱和，会导致Pod无法及时处理请求。
调整ALB闲置超时：ALB默认的闲置超时是60秒，如果你的请求间隔较长，会导致连接频繁断开重建。可以通过Ingress annotation调整超时时间：
```
alb.ingress.kubernetes.io/idle-timeout: '300'
```
延长闲置超时可以提升连接复用率，减少连接建立的开销。

内容的提问来源于stack exchange，提问作者Most Wanted