HPA缩容导致Go长连接Pod断连，根本原因是K8s终止流程与Go应用优雅关闭未协同：未监听SIGTERM、未调用http.Server.Shutdown()、terminationGracePeriodSeconds不足或readinessProbe/preStop未配合，致Endpoint未及时摘除而新请求仍被路由至终止中Pod。
为什么HPA缩容会导致Go长连接Pod断连
HPA缩容时直接销毁Pod，而Go应用若未正确处理SIGTERM信号、也未实现优雅关闭（graceful shutdown），连接会立即中断。这不是K8s问题，是应用层与调度层的协作断点。
关键矛盾在于：K8s默认等待terminationGracePeriodSeconds（默认30秒）后强制发送SIGKILL；但Go程序若没监听SIGTERM、或未在该窗口内完成连接 draining，就会丢请求。
- Go标准库
http.Server.Shutdown()必须显式调用，否则ListenAndServe()会忽略信号 - 反向代理（如Nginx/Ingress Controller）若未配置
proxy_next_upstream error timeout http_502，会把502当永久错误，不重试 - 客户端若使用短连接池（如Go
http.DefaultTransport未设MaxIdleConnsPerHost），缩容瞬间大量连接被复位，触发TCP RST
Go服务必须加的优雅退出代码片段
以下逻辑必须嵌入主函数，且不能依赖第三方中间件自动注入：
srv := &http.Server{Addr: ":8080", Handler: mux}
done := make(chan error, 1)
go func() {
if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
done <- err
}
}()
// 等待系统信号
sig := make(chan os.Signal, 1)
signal.Notify(sig, syscall.SIGINT, syscall.SIGTERM)
<-sig // 阻塞直到收到信号
// 启动优雅关闭
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil {
log.Printf("HTTP server shutdown error: %v", err)
}
<-done // 等待ListenAndServe退出
注意：Shutdown()只关闭监听，已接受的连接仍可处理完；但必须确保所有goroutine（如心跳协程、DB连接池）也在同一ctx下受控退出。
HPA缩容前必须检查的三个配置项
K8s侧配置不到位，再好的Go代码也白搭：
-
terminationGracePeriodSeconds至少设为45：给Go应用留出足够draining时间（建议比代码中context.WithTimeout多15秒缓冲） -
readinessProbe必须用httpGet而非exec：确保新Pod真正ready才加入Service endpoints；否则缩容时旧Pod还在服务，新Pod又没准备好，流量黑洞 -
minReadySeconds在Deployment中设为10：防止ReplicaSet过早认为Pod ready，避免滚动更新期间误切流
漏掉任一配置，都可能让HPA在连接高峰期“暴力摘机”。
Ingress/Service层如何避免切流抖动
即使Pod优雅退出，上游负载均衡器若缓存了失效endpoint，仍会转发请求过去。必须打破这个链路：
- 确认Ingress Controller（如nginx-ingress）启用
service-upstream模式，而非endpoints直连：它会监听Endpoints变化并主动剔除节点，延迟 - Service的
sessionAffinity: ClientIP必须禁用：长连接本就不该绑定IP，否则缩容时affinity规则会让部分客户端永远打不到存活Pod - 如果用NodePort或LoadBalancer类型Service，检查云厂商SLB健康检查间隔——阿里云SLB默认5s探测，需调至≤3s，并勾选“失败连续次数=1”
最隐蔽的坑是：某些Ingress Controller（如早期traefik v2.4）对EndpointSlice事件响应有10秒级延迟，升级到v2.9+可修复。
