滚动更新时preStop阶段Pod连接重置问题：Bug还是预期行为？

这是Kubernetes的预期行为，不是Bug。

原因解析 #

1. Endpoint控制器的核心逻辑：当Pod进入Terminating状态时，Kubernetes的Endpoint控制器会立即将该Pod从Service的Endpoints列表中移除——这个操作和preStop钩子是否执行无关。Endpoint控制器仅关注Pod的Ready状态与生命周期阶段，一旦Pod启动终止流程，就会被标记为Not Ready，进而被从Service的后端池中剔除。
2. preStop的实际作用边界：preStop钩子的设计目的是给Pod提供一段优雅关闭的窗口，让应用可以完成现有请求处理、释放资源，但它不会阻止Endpoint控制器移除Pod的IP。也就是说，preStop只保证Pod本身不会立即退出，但Service已经不会再把任何流量（包括keep-alive会话的后续请求）转发到这个Pod了。
3. 连接重置的触发机制：客户端的keep-alive会话是与Pod A的IP建立的TCP连接，当Pod A被从Endpoints移除后，kube-proxy会将后续请求转发到其他可用Pod（比如Pod B）。但TCP连接是基于「源IP+源端口+目标IP+目标端口」的四元组标识的，Pod B没有这个会话的上下文，收到序列号不匹配的数据包后，会直接返回RST包，导致客户端出现连接重置错误。

解决方案 #

• 优化应用优雅关闭逻辑：在preStop钩子中让应用先停止接受新连接，同时继续处理现有连接。比如Spring Boot应用，可以开启Actuator并在preStop中调用/actuator/shutdown，或者自定义接口让应用关闭监听端口，等待现有连接处理完成。同时要确保terminationGracePeriodSeconds的设置长于preStop的执行时间，给应用足够的时间处理完剩余请求。
• 启用会话亲和性：给Service配置sessionAffinity: ClientIP，让同一个客户端的请求始终转发到同一个Pod。这样在滚动更新时，客户端的keep-alive会话不会被转发到其他Pod，但要注意这会降低负载均衡的灵活性。
• 调整客户端连接策略：在客户端连接池中设置合理的keep-alive超时时间，或者添加连接重置后的自动重连逻辑，避免长时间持有无效的旧连接。

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