Kubernetes跨集群场景下基于clientIP的会话亲和性失效：TCP请求后UDP请求无法路由至同一Pod的技术问询

这个问题我之前处理过类似的场景，核心问题出在跨集群访问时的源IP丢失和Service亲和性的生效条件上，下面一步步给你拆解解决方法：

一、先搞清楚为什么clientIP亲和性没生效 #

当Pod A从Cluster 1访问Cluster 2的NodePort/LoadBalancer Service时，默认情况下Cluster 1的节点会对Pod A的流量做SNAT（源地址转换），把Pod A的IP换成Cluster 1节点的IP。这时候Cluster 2的Service看到的源IP是Cluster 1的节点IP，而不是Pod A的真实IP：

• 如果Cluster 1有多个节点，后续UDP请求可能从不同节点发出，导致Service把流量路由到不同Pod；
• 就算是同一个节点，基于节点IP的亲和性绑定也不稳定，很容易因为节点调度变化导致路由目标切换。

二、针对性解决方案 #

1. 配置Cluster 2的Service保留源IP #

修改Cluster 2的Service，添加externalTrafficPolicy: Local配置，这样Service会直接把流量转发到本地节点上的Pod，并且保留客户端的真实源IP（Pod A的IP）：

apiVersion: v1
kind: Service
metadata:
  name: your-app-service
spec:
  type: NodePort # 或 LoadBalancer
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 3600 # 延长超时，确保UDP请求在亲和有效期内发起
  externalTrafficPolicy: Local # 关键配置：保留源IP
  ports:
  - name: tcp-main
    protocol: TCP
    port: 8080 # 你的TCP服务端口
    targetPort: 8080
  - name: udp-data
    protocol: UDP
    port: 8081 # 若Pod使用动态UDP端口，需确保Service端口范围覆盖Pod的动态端口范围
    targetPort: 8081

注意：externalTrafficPolicy: Local要求Cluster 2的每个节点上至少有一个Pod副本，否则未运行Pod的节点会丢弃流量。如果你的Cluster 2节点数量多于Pod副本数，可以调整Pod的调度策略，让每个节点都分配到一个Pod。

2. 确保TCP和UDP共用同一个Service #

必须把TCP和UDP端口定义在同一个Service下，这样Kubernetes会基于同一个源IP（Pod A的IP）维护亲和性条目，TCP连接绑定到Pod C后，后续的UDP请求只要在超时时间内，就会被路由到同一个Pod。

3. 备选方案：用Headless Service直接访问Pod #

如果上面的方法还是有问题，可以考虑在Cluster 2使用Headless Service（clusterIP: None），这样Service会直接返回Pod的真实IP：

apiVersion: v1
kind: Service
metadata:
  name: your-app-headless
spec:
  clusterIP: None
  ports:
  - name: tcp-main
    protocol: TCP
    port: 8080
    targetPort: 8080
  - name: udp-data
    protocol: UDP
    port: 8081
    targetPort: 8081
  selector:
    app: your-app # 和Pod的标签匹配

然后在Cluster 1中通过跨集群服务发现（比如配置CoreDNS跨集群解析）获取Pod C的IP，让Pod A直接连接Pod C的IP，这样TCP和UDP都直接指向Pod C，完全绕过Service的路由逻辑，从根本上解决亲和性问题。不过这个方案需要你配置跨集群的服务发现能力。

4. 检查亲和性超时时间 #

默认的clientIP亲和性超时是300秒（5分钟），如果你的UDP请求在TCP连接后超过5分钟才发起，亲和性绑定会失效。所以建议把timeoutSeconds调整到3600秒（1小时）或者更长，确保UDP请求在有效期内。

三、验证方法 #

1. 在Pod A上发起TCP请求到Cluster 2的Service，记录返回的UDP端口；
2. 用tcpdump在Cluster 2的Pod C和Pod D上抓UDP流量，确认请求只发送到Pod C；
3. 查看Cluster 2的Service亲和状态：kubectl describe service your-app-service，检查Session Affinity相关信息，确认源IP（Pod A的IP）绑定到了Pod C。

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