关于Istio保留客户端源IP及externalTrafficPolicy配置的疑问

背景与测试环境 #

我们正在验证Istio“保留客户端原始源IP地址”的行为，测试环境与配置如下：

• Kubernetes集群包含node1、node2两个节点
• Istio Ingress-Gateway Pod仅运行在node1上
• httpbin Pod运行在node2上
• 已配置Gateway和VirtualService，将Istio IngressGateway Service的流量路由至httpbin Pod

流量路径：

external traffic -> istio ingress-gateway service (load balancer) -> istio ingress-gateway pod -> httpbin service -> httpbin pod

测试在Azure和GCP环境（使用Network Load Balancer）进行，已将Istio IngressGateway Service的externalTrafficPolicy设置为local。

测试命令：

curl --connect-to httpbin.example.com:80:<istio_ingress_gateway_external_ip>:80 http://httpbin.example.com/get?show_env=1

测试结果：响应中能获取到包含客户端原始IP（与节点IP不同）的X-Forwarded-For请求头，但存在两个疑问：

1. 根据Istio官方文档，若Ingress-Gateway Pod未在所有节点运行，流量应被丢弃，但我们的node2无该Pod，流量并未被丢弃
2. 设置externalTrafficPolicy=local应阻止流量发送至其他节点，但我们观察到流量被发送至node2

疑问1：未部署Gateway Pod的节点流量未被丢弃的原因 #

• 云厂商LB实现差异：Azure和GCP的Network Load Balancer在externalTrafficPolicy=local模式下，不会直接丢弃无Gateway Pod节点的流量，而是会将流量转发到运行Gateway Pod的节点（如node1）。Istio文档描述的“流量被丢弃”针对的是部分纯三层LB场景，不同云厂商的LB行为存在差异。
• 确认externalTrafficPolicy生效状态：执行命令验证配置是否正确：

  kubectl get svc istio-ingressgateway -n istio-system -o yaml | grep externalTrafficPolicy
  

  确保返回值为Local，同时检查status.loadBalancer.ingress是否关联到node1的公网IP。

疑问2：流量被发送到node2的原因 #

• externalTrafficPolicy的作用范围：该配置仅控制外部流量到IngressGateway Service的转发逻辑，确保外部流量直接打到运行Gateway Pod的节点（node1）。而Gateway Pod到httpbin Pod的流量属于集群内部Service的转发，不受externalTrafficPolicy约束，因此流量从node1的Gateway Pod转发到node2的httpbin Pod是正常的集群内部调度行为。
• 验证原始IP是否正确保留：检查httpbin响应中的X-Envoy-External-Address头（Istio Envoy自动添加），确认客户端原始IP是否正确传递，若该头值为客户端IP，则说明externalTrafficPolicy=local的核心目标（保留客户端IP）已实现。

额外验证步骤 #

1. 在node2部署临时Pod，直接访问node1上Gateway Pod的ClusterIP，验证客户端IP是否能正确传递；
2. 检查Gateway资源配置，确认未开启改写X-Forwarded-For的逻辑：

   kubectl get gateway <gateway-name> -n <namespace> -o yaml
   

   确保spec.servers下未配置会修改客户端IP的参数。

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