Kubernetes ClusterIp Pod间通信为何设置Connection: close？能否安全修改？

为什么会覆盖HTTP响应头为Connection: close？ #

Kubernetes的ClusterIP Service转发流量时默认修改Connection: close响应头，核心原因和kube-proxy的默认工作模式（iptables）有关：

• iptables模式下，kube-proxy靠DNAT规则实现流量转发，但没有内置的连接会话跟踪能力，无法稳定维持跨请求的长连接。如果保留长连接，后续请求可能被随机转发到不同后端Pod，对依赖会话绑定的应用会引发问题。
• 早期kube-proxy设计优先保证转发稳定性，通过强制关闭连接，让每次请求重新建立连接，确保流量能被正确负载均衡到后端Pod。

无风险修改该行为的方法 #

1. 切换kube-proxy到IPVS模式 #

IPVS是专为高负载场景设计的负载均衡模式，支持长连接和会话亲和性，默认不会修改Connection响应头，是最稳妥的解决方案：

• 先确认节点已安装IPVS依赖工具（ipvsadm、ipset、conntrack），主流K8s发行版一般默认预装，未安装则手动补充。
• 编辑kube-proxy的ConfigMap：

  kubectl edit configmap kube-proxy -n kube-system
  

  找到mode字段，将值改为ipvs（默认是iptables）。
• 重启kube-proxy守护进程生效：

  kubectl rollout restart daemonset kube-proxy -n kube-system
  

2. iptables模式下的兼容调整（仅临时过渡用） #

如果暂时无法切换到IPVS，可尝试以下调整，但需先在测试环境验证兼容性：

• 在ClusterIP Service的注解中添加service.kubernetes.io/backend-protocol: "HTTP"，告知kube-proxy后端是HTTP服务，减少不必要的连接强制关闭操作。
• 确保后端应用主动返回Connection: keep-alive响应头，部分场景下可以覆盖kube-proxy的修改（取决于kube-proxy版本）。
• 调整kube-proxy的conntrack超时配置，在ConfigMap的config.conf中增加：

  conntrack:
    tcpEstablishedTimeout: 86400s
  

  延长已建立连接的超时时间，减少因超时导致的频繁断连。

注意事项 #

• 切换IPVS模式前，建议先在测试集群验证应用兼容性。
• 若使用云厂商托管K8s集群，需确认厂商支持IPVS模式，部分厂商需通过控制台配置开启。

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