prestop没生效主因是go进程未成为pid 1：k8s信号只发给pid 1，若被shell封装则信号中断；须用entrypoint["./app"]或脚本末行加exec，确保go进程直收sigterm并配合readinessprobe实现秒级断流。
preStop 钩子为什么没生效？先看 PID 1 是不是 Go 进程
绝大多数 preStop 不触发或触发后无效果，根本原因不是 YAML 写错，而是容器启动时 Go 二进制没成为 PID 1。K8s 发出的 SIGTERM 只会发给 PID 1 进程，如果被 shell 挡住（比如 sh -c "./app"），信号就卡在 shell 层，Go 根本收不到。
验证方法：进入 Pod 执行 kubectl exec -it <pod> -- ps aux</pod>，确认 ./myapp 的 PID 是 1；如果不是，说明启动方式有问题。
- Dockerfile 中禁用
CMD ["sh", "-c", "./myapp"]，改用ENTRYPOINT ["./myapp"]或CMD ["./myapp"] - 若必须用启动脚本，最后一行必须是
exec ./myapp——exec会用 Go 进程替换当前 shell，让其获得 PID 1 和信号直通权 - preStop 执行超时默认为 30 秒，但实际建议控制在 ≤5s；别在里面做 DB 连接池 drain、远程注销等耗时操作
preStop + readinessProbe 如何配合实现“秒级断流”
只靠 Go 层调用 server.Shutdown() 不够：K8s endpoint controller 从探测失败到把 Pod 从 Endpoints 列表摘除有延迟（几百毫秒到几秒），期间新请求仍可能打进来。
真正可靠的做法是 preStop 主动触发一个“拒绝新请求”的状态切换，再配合 readinessProbe 快速反馈失败。
- preStop 使用
httpGet调用一个内部 shutdown 接口（如/shutdown），该接口需立刻关闭 listener 并返回 503 - readinessProbe 的
httpGet.path必须和 shutdown 接口一致，这样下一次探针就会立即失败，加速摘除 - shutdown 接口本身不能阻塞，它只负责标记状态、关 listener、通知长连接关闭，不等连接真正断开
WebSocket 等 Upgrade 连接为什么 Shutdown() 不管用
http.Server.Shutdown() 只管理 HTTP 请求生命周期，对 Upgrade 后的裸 TCP 连接（如 WebSocket、SSE）完全无感知——它们已脱离 HTTP 处理链，Shutdown() 不会 close、也不等待。
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
现象是调用 Shutdown() 后函数立刻返回，但客户端连接几秒后才突然 RST 断开，日志里看不到主动关闭痕迹。
- 必须自己维护长连接引用：用
sync.Map存*websocket.Conn，每次Upgrader.Upgrade()后存入 - 收到 SIGTERM 后，遍历
sync.Map调用conn.Close()，再用sync.WaitGroup或time.AfterFunc等待全部完成 - 注意：不要在 Shutdown() 前就关 listener，否则新 Upgrade 会被拒，但已有连接仍可发消息
优雅退出的边界在哪？别把 preStop 当万能清理入口
preStop 是同步阻塞执行的，它的时间计入 terminationGracePeriodSeconds，但它的职责很明确：只做“断流+通知”，不是兜底清理中心。
比如 DB 连接池 drain、缓存 flush、异步任务 checkpoint 等，应该在 Go 主进程收到 SIGTERM 后由自身逻辑处理，而不是塞进 preStop 的 shell 命令里——后者既不可靠（超时被跳过），又难以调试（日志分散、无上下文）。
真正容易被忽略的是：preStop 里任何失败都不会阻止 Pod 终止，K8s 只会记录事件但继续走下一步；而 Go 进程自己没处理好 SIGTERM，哪怕 preStop 成功了，也照样会 RST 断连、丢请求。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
