K8s环境下Go长连接Pod有状态平滑下线方案实施

今日不肯埋头，明日何以抬头！每日一句努力自己的话哈哈~哈喽，今天我将给大家带来一篇《K8s环境下Go长连接Pod有状态平滑下线方案实施》，主要内容是讲解等等，感兴趣的朋友可以收藏或者有更好的建议在评论提出，我都会认真看的！大家一起进步，一起学习！

readinessProbe 必须在 SIGTERM 后立即失败：Go 应用需收到信号后立即将 /readyz 返回 503，配合 failureThreshold: 1 和 periodSeconds: 5 实现秒级摘流，并同步执行连接排空（如 GracefulStop 或 Shutdown），确保长连接请求处理完毕。

readinessProbe 必须在 SIGTERM 后立即失败

Service 和 Ingress（如 ALB/NLB）只看 readinessProbe 状态决定是否把新请求转发过来。哪怕容器已收到 SIGTERM、preStop 也执行完了，只要 probe 还返回 200，流量就照进不误——这是长连接场景下残留请求的根源。

Go 应用必须主动控制就绪状态：收到 SIGTERM 后立即将 /readyz 返回 503，但保持 /healthz 可用（避免被 livenessProbe 误杀重启）。

• failureThreshold: 1 是硬性要求，确保第一次 probe 失败就触发 Endpoint 移除
• periodSeconds: 5 配合 ALB 默认 5–10 秒调谐周期，能在 5 秒内完成摘流
• 别复用 /healthz 做 readiness 检查——它只反映进程存活，不反映业务就绪

Go 服务必须实现连接排空（drain），不能只关 listener

HTTP/1.1 或 gRPC（HTTP/2）长连接下，“关闭 listener”只是拒新不拒旧。已有连接上的请求、流式响应、未 flush 的 buffer 都还在跑，直接退出等于截断请求。

标准做法是分两步：先停收新流量（靠 readiness 探针失败），再等老连接自然结束（靠 drain）。

• gRPC：调用 server.GracefulStop() —— 它会发 GOAWAY、等待所有 stream 完成、再退出
• HTTP：http.Server.Shutdown() 必须配合 context.WithTimeout(ctx, 45*time.Second)，且 handler 内要检查 ctx.Done()
• 别依赖 Shutdown() 自动等完所有后台 goroutine —— 它只等 handler 函数返回，不等你启的异步写 DB 或发消息

terminationGracePeriodSeconds 要大于 drain 最大耗时

K8s 在发送 SIGTERM 后，如果超过 terminationGracePeriodSeconds（默认 30 秒）还没退出，就会发 SIGKILL 强杀。而你的 drain 时间可能远超 30 秒——比如慢查询、大文件上传、流式日志推送。

• 设为 60 或 120，留足缓冲；同时在 Go 代码里用 context.WithTimeout 主动控制最大等待时间，避免无限 hang
• 在 preStop 里加 sleep 是无效的——它不阻塞 SIGTERM 到达应用，也不影响 readiness 状态更新
• 不要把 drain 逻辑全塞进 preStop shell 脚本里：没法做连接级等待，也无法感知 HTTP 流或 gRPC stream 的实际完成

滚动更新时 maxUnavailable 需按业务敏感度调整

默认 maxUnavailable: 25% 在低副本数场景很危险。比如 2 副本更新时，K8s 先启 1 新 Pod、再删 1 旧 Pod，瞬间变成 2→3→2。若新 Pod 尚未通过 readinessProbe，旧 Pod 却已被摘流+drain，就可能丢请求。

• 写敏感服务（如订单、支付）建议设 maxUnavailable: 0，强制等旧 Pod 全退完再启新 Pod（本质是蓝绿）
• 读多写少+有缓存的服务，可用 maxSurge: 1 + maxUnavailable: 0，兼顾速度与安全
• 永远别设 maxSurge: 0 —— rollout 会卡死，新 Pod 根本起不来

最易被忽略的是 readiness 状态变更与 drain 的时序耦合：不是“先等 drain 再改 readiness”，而是“改 readiness 立即摘流 + 同时启动 drain”。两者必须原子化协同，缺一不可。

今天关于《K8s环境下Go长连接Pod有状态平滑下线方案实施》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！