k8s上nginx无法正常转发socketIO

背景&前言

环境背景

公司业务组开始尝试将系统上云，因此很多虚拟机环境部署的服务需要开始迁移到k8s云厂商平台上。
当前云厂商k8s版本为：1.22。

业务场景

前端与后端需要使用socketIO进行gpt流式问答的实现。
前后端皆使用微服务形式以k8s部署，前端服务pod中集成vue打包文件且部署openresty做请求转发。

原nginx配置大致如下:

  upstream socketio {
  	ip_hash;
  	# 例中为podIP，原来为不同的虚拟机服务器ip
  	server 10.200.8.7:9877;
  	server 10.200.3.35:9877;
}

使用ip_hash的方式进行负载均衡。

openresty报错:

2024/06/03 06:32:23 31#31: *81 connect() failed (111: Connection refused) while connecting to upstream, client: 10.200.1.53, server: localhost, request: "GET /socket.io/?....

TODO

三处TODO, 待逐渐深入理解k8s和网络负载后尝试能否解决.
(需要学习的东西还很多啊QAQ)

正文

初步尝试

一开始由于k8s中podIP的随机特点，因此希望通过K8s-dns的方式由域名对pod进行定位，因此在部署后端服务时使用了statefulSet的workload类型。
由于该类型pod-name可以保持不变，因此计划使用如下方式对nginx.conf进行改造：

    upstream socketio {
		ip_hash;
    	# ks-dns可以对{pod-name.service-name.namespace-name.svc.cluster.local}进行podIP解析
		server pod-0.service.namespace.svc.cluster.local:9877;
        server pod-1.service.namespace.svc.cluster.local:9877;
	}

经试验，该方法会导致socketIO随机产生断连, 即使频率不高，但显然无法满足业务场景。

TODO：为什么这种方式会随机产生断连，是否和k8s网络有关？

再次尝试

过了较长时间, 由于另一个问题----因为云厂商平台使用keepalived-nat负载形式, 导致集群内服务无法获得源IP----的解决 , 再次重新回顾本问题 , 想到了一个新的解决方案 , 也许是在转发时设置REAL_IP出现了问题. 因为了解到在原有网络组件负载的情况下后端服务无法获得请求源IP, 猜测是该原因导致socketIO断连。

TODO: 之前解决的方式是只一个副本ip写入upstream, 实则只有一个pod在提供服务, 但模块也能正常工作, 所以个人认为应该不是网络组件导致的原因, 那到底是什么原因呢 …?

# 原nginx.conf部分
location ^~/socket.io/
{
      add_header Cache-Control no-store;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header REMOTE-HOST $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_pass http://socketio;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
}

# 新nginx.conf部分
location ^~/socket.io/
{
	  add_header Cache-Control no-store;
	  proxy_set_header Host $host;
	  # 云厂商提供的能访问请求源IP的参数 $http_x_forwarded_for
	  proxy_set_header X-Real-IP $http_x_forwarded_for;
	  proxy_set_header REMOTE-HOST $http_x_forwarded_for;
	  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	  proxy_pass http://socketio;
	  proxy_http_version 1.1;
	  proxy_set_header Upgrade $http_upgrade;
	  proxy_set_header Connection "upgrade";
}
# 新upstream部分
upstream socketio {
	  ip_hash;
	  # 为后端服务的两个podIP
	  server 10.200.8.7:9877;
	  server 10.200.3.35:9877;
}

经过测试, 该方式可以让socketio生效, 解决了之前该模块多副本导致的socketio连接异常问题.
但是, 由于在nginx中设置了ip_hash的转发, 并设置了具体的podIP, 这将导致如果该模块日常更新重新部署后podIP发生了变化则该模块无法正常提供服务. 因此考虑使用k8s的FQDN解决该问题.

upstream socketio {
  server <svc-name>.<namespace>.svc.cluster.local:<port>;
}

需要在该处删除ip_hash字段, 否则会出现异常.
经测试后, 达到预期效果.

TODO: 为什么不删除ip_hash字段会异常? nginx的ip_hash对请求造成了什么影响?