Kubernetes集群中跨Pod发送UDP响应被Service拦截问题咨询

你的问题诊断完全正确。Kubernetes的Service UDP会话基于源IP:源端口 + 目的IP:目的端口四元组做会话跟踪，POD2回包时的源IP为自身PodIP而非客户端原始请求访问的LoadBalancer VIP，kube-proxy没有对应会话条目无法完成反向SNAT转换，客户端收到源IP未知的UDP报文后自然会返回ICMP端口不可达错误。

1. 是否存在可解决该问题的原生注解 #

不存在对应的K8s或MetalLB原生注解可以直接解决跨Pod回UDP包的源IP不匹配问题。
两个常被混淆的相关注解/配置均不适用该场景：

• service.spec.externalTrafficPolicy=Local仅用于保留客户端源IP，仅会将请求转发到当前节点上的后端Pod，无法修正跨Pod回包的源IP错误
• MetalLB的metallb.universe.tf/allow-shared-ip仅支持多Service共享同一个LoadBalancer IP，和该场景无关

2. 端口映射是否由MetalLB负责 #

端口映射、会话跟踪、NAT转换逻辑均由集群节点上的kube-proxy组件负责，和MetalLB无关。
MetalLB仅承担两个职责：

• 为LoadBalancer类型Service分配可用的对外VIP
• 通过ARP（二层模式）或BGP（三层模式）将VIP的路由信息宣告到集群外部网络，保证外部流量能到达集群节点

3. 是否必须使用UDP代理，现有实现方案 #

该场景下原生K8s Service机制无法满足需求，必须做逻辑适配，可选方案按改造成本从低到高排序如下：

• 方案一：修改业务回包逻辑（最优）
  调整服务逻辑，缓存中除了存储源IP、端口、报文内容外，额外存储接收到该请求的Pod标识，回包时强制由原始接收请求的Pod执行回包操作。原始Pod回包时kube-proxy已有对应会话记录，会自动将源IP转换为LoadBalancer VIP，不存在源IP不匹配问题，不需要额外引入代理组件。
• 方案二：部署统一UDP四层代理
  部署Envoy、Nginx等支持UDP代理的组件作为统一入口，所有外部UDP请求先经过代理，代理转发到后端业务Pod，所有回包统一走代理对外发送，保证客户端收到的报文源IP始终为请求的LoadBalancer VIP。仅需要新增代理配置，不需要修改业务逻辑。
• 方案三：测试环境临时配置（不推荐生产使用）
  测试环境可临时调整节点内核参数绕过校验：

  sysctl -w net.ipv4.ip_forward=1
  sysctl -w net.ipv4.conf.all.accept_local=1
  

  该配置会引入安全风险，且节点重建后会失效，仅可用于临时验证。

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