使用Nginx Ingress时流量被路由至错误Pod的问题求助

结合你描述的环境（EKS 1.23 + Nginx Ingress 4.4.2 + AWS NLB + VPC Service Endpoint）和现象（不同来源访问结果不同），可以从以下几个方向入手排查：

• 检查请求头差异
  对比本地机器和Unix主机的请求头，重点看Host、X-Forwarded-For、X-Forwarded-Host这些字段。Nginx Ingress的路由规则很多依赖Host头匹配，如果Unix主机的请求Host头不正确（比如带有额外后缀、拼写错误），可能会匹配到其他Ingress规则。可以用curl -v分别在两台机器上发起请求，输出完整头信息对比。

• 验证NLB与Ingress Controller的会话粘性
  AWS NLB如果开启了会话粘性，可能会把Unix主机的请求持续路由到某一个有异常配置的Ingress Controller Pod。可以临时关闭NLB的会话粘性测试，或者手动删除异常的Ingress Pod，让新Pod接管流量。另外，检查Ingress Controller的Deployment是否配置了正确的会话亲和性（默认应该是无）。

• 检查Ingress Controller的配置一致性
  部分Ingress Pod可能存在配置同步延迟或异常，导致路由规则错误。可以进入不同的Ingress Pod，执行kubectl exec -it <ingress-pod-name> -- cat /etc/nginx/nginx.conf查看生成的路由配置是否一致，重点对比对应服务的server和location块。如果存在不一致，重启Ingress Controller的Deployment强制刷新配置。

• 排查VPC Service Endpoint的流量篡改
  VPC Service Endpoint在转发流量时可能会修改请求头或路径。可以在Ingress Controller Pod上抓包（用tcpdump或ngrep），对比本地和Unix主机的请求原始内容，看是否存在头信息被篡改的情况。比如某些场景下，VPC端点会替换Host头为NLB的内部域名，导致Ingress规则匹配失败。

• 检查Ingress规则的优先级与冲突
  即使你认为Ingress配置正确，也可能存在规则优先级问题。比如多个Ingress资源匹配同一个Host，或者使用了通配符规则导致意外匹配。可以用kubectl describe ingress <ingress-name>查看Ingress的事件和规则状态，排查是否存在规则冲突。

• 验证服务端点的正确性
  虽然你已经检查过选择器和端点，但可以再次确认目标服务的Endpoints资源是否只包含正确的Pod IP。执行kubectl get endpoints <service-name>，对比Pod的实际IP，确保没有混杂其他服务的Pod IP。

内容的提问来源于stack exchange，提问作者Arun Thundyill Saseendran