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 逻辑全塞进
preStopshell 脚本里：没法做连接级等待，也无法感知 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”。两者必须原子化协同，缺一不可。
