配置Envoy后K8s同Service内Pod间HTTP请求问题排查

嘿，作为K8s新手遇到这种Envoy相关的网络问题太正常了，咱们一步步拆解来看。先给你个明确结论：配置Envoy后完全可以直接请求同Service下的Pod IP，你遇到的HTTP 404是应用层的路由/转发问题，和网络连通性（能ping通）没关系，下面是具体的排查思路和配置检查点：

一、核心结论：Pod IP直接请求是可行的 #

Envoy作为Sidecar或独立Proxy，本身不会默认阻止Pod间的直接IP通信（除非你特意配置了严格的流量拦截策略）。能ping通说明网络层完全没问题，404是请求在Envoy或应用路由环节出了问题。

二、具体排查步骤与配置检查点 #

1. 确认Envoy的监听与端口转发配置 #

首先得检查Envoy在Pod内是否正确监听了你请求的端口（7079），或者是否把流量转发到了应用的实际端口。可以在发起请求的Pod内执行以下命令：

# 查看Envoy监听的所有端口（默认管理端口是9901）
curl localhost:9901/listeners
# 或者用ss命令查看端口占用情况
ss -tulpn

如果Envoy没监听7079，或者监听后转发的目标端口和应用实际运行端口不匹配，就会导致请求无法到达应用，返回404。

2. 检查Envoy的路由规则匹配情况 #

Envoy的路由配置决定了请求会被转发到哪里。你需要确认路由规则是否匹配你请求的路径（/user/1），并且指向了正确的上游目标。可以通过管理端口导出配置并筛选路由部分：

curl localhost:9901/config_dump | grep -A 20 "route_config"

重点关注：

• 路由的match规则是否包含你请求的路径前缀或精确路径
• route部分的cluster是否指向了正确的Pod应用集群，或者是否直接转发到本地应用端口（Sidecar模式下常见）

3. 排查流量劫持规则（若使用Istio等Service Mesh） #

如果你是用Istio这类基于Envoy的Service Mesh，默认会用iptables劫持Pod内的流量。需要确认劫持规则是否把Pod间的HTTP流量都导去了Envoy，但Envoy又没配置对应路由。可以在Pod内查看iptables规则：

iptables-save | grep -i envoy

如果发现所有出站流量都被劫持到Envoy，但Envoy没有针对Pod IP的路由规则，就会出现404。这种情况需要调整Sidecar注入配置，比如添加注解排除特定端口：

traffic.sidecar.istio.io/excludeOutboundPorts: "7079"

4. 对比外部与Pod内请求的流量差异 #

外部直接请求Pod IP正常，说明应用本身没问题，问题出在Pod内的流量路径。可以在目标Pod（1.2.3.4）上抓包对比：

# 在目标Pod上抓7079端口的流量
tcpdump -i any port 7079 -w pod_traffic.pcap

分析抓包内容，看Pod内发起的请求是否真的到达了应用端口，还是被Envoy拦截后转发错误。

5. 查看Envoy的访问日志定位问题 #

Envoy的访问日志能清晰展示请求的处理流程。如果是Sidecar模式，可以单独查看Envoy容器的日志：

kubectl logs <你的Pod名称> -c envoy  # 假设Envoy容器名是envoy

日志里会显示请求的路径、返回码、转发目标等信息，通过这些能快速判断是路由不匹配还是转发失败。

三、针对你的部署配置文件的重点检查点 #

结合你提供的部署配置，重点看这几点：

• Envoy容器的端口映射：是否把7079端口映射到了Envoy的监听端口，或者Envoy是否配置了监听7079并转发到应用的实际端口（比如应用在Pod内跑8080）
• Sidecar注入注解：若用Istio，检查Pod是否有sidecar.istio.io/inject: "true"注解，以及是否有排除端口的配置
• Envoy的静态/动态配置：手动配置Envoy的话，检查listener和route_config部分是否正确匹配请求路径与上游服务

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