PreStop钩子未触发即被SIGKILL终止，根本原因是其执行超时（计入terminationGracePeriodSeconds默认30秒），Kubernetes强制杀进程；Golang需显式监听SIGTERM并阻塞等待，配合HTTP Server Shutdown及第三方资源清理。
PreStop 钩子没触发，进程却直接被 SIGKILL 杀掉
根本原因是容器在 preStop 执行期间超时，Kubernetes 强制发送 SIGKILL。默认的 terminationGracePeriodSeconds 是 30 秒，而 preStop 执行时间也会计入其中——不是额外加时。
-
preStop是同步阻塞执行的：Kubernetes 会等它返回（或超时），才开始发SIGTERM - 如果你的
preStop是个exec命令（比如调用/bin/sh -c "sleep 40"），它一超时，后续所有退出逻辑都来不及走 - 更隐蔽的坑：Golang 程序里如果用了
os.Exit()或 panic 后未捕获，会导致preStop进程提前退出，但主应用进程还在跑，K8s 以为“钩子已完成”，立刻发SIGTERM，而你的程序可能根本没监听或没处理
Golang 主程序收不到 SIGTERM 或处理不生效
Go 默认对 SIGTERM 无响应，必须显式监听；且常见写法容易漏掉信号接收后的阻塞等待，导致主 goroutine 退出、程序立即终止。
- 别只写
signal.Notify(c, syscall.SIGTERM)就完事——必须有地方阻塞住，否则 main 函数结束，进程就没了 - 不要在
signal.Notify后直接log.Println("got signal")然后 return；要启动 shutdown 流程（比如关闭 HTTP server、等待活跃请求完成），再主动os.Exit(0) - HTTP server 的
Shutdown()方法需传入 context，并设好超时；若 context 被 cancel 太快，连接会被粗暴中断 - 示例关键片段：
srv := &http.Server{Addr: ":8080"}
go func() { log.Fatal(srv.ListenAndServe()) }()
c := make(chan os.Signal, 1)
signal.Notify(c, syscall.SIGTERM, syscall.SIGINT)
<-c // 阻塞等待信号
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
srv.Shutdown(ctx) // 注意这里不是 Close()
PreStop exec 和 HTTP 方式选哪个？
两种方式底层行为不同，影响可观测性与调试成本。
-
exec类型（如command: ["/bin/sh", "-c", "curl -X POST http://localhost:8080/shutdown"]）依赖容器内网络栈和目标端口可达——但 Pod 正在 terminating 时，kube-proxy 规则可能已更新，localhost请求不一定能打到本体；而且无法感知 HTTP 调用是否真成功 -
httpGet类型（如httpGet: {path: /shutdown, port: 8080}）由 kubelet 发起，绕过容器网络，更可靠；但要求你的服务必须暴露一个可被 kubelet 访问的健康/控制端点，且该端点不能依赖其他中间件（如 auth 中间件未放行会导致 401，钩子失败） - 推荐组合：用
httpGet触发 shutdown 接口，接口内部做 graceful shutdown；同时在 Golang 里保留SIGTERM监听作为兜底——防止 kubelet 因某种原因没调用钩子
HTTP Server Shutdown 后仍有 goroutine 泄露或连接卡住
常见于使用第三方库（如 database/sql、gRPC client、长轮询 handler）时，未配合 shutdown context 清理资源。
立即学习“go语言免费学习笔记（深入）”；
-
srv.Shutdown()只负责关闭 listener 并等待已有连接完成；它不会自动 cancel 你代码里自己启的 goroutine - 数据库连接池要显式调用
db.Close()，否则连接可能 hang 在conn.SetDeadline上，阻塞 shutdown - gRPC client 的
Conn.Close()是必须的；若用了WithBlock()，shutdown 时可能卡住，建议改用非阻塞 dial + context 控制 - 检查是否有 goroutine 在读写 channel 却没人 close——比如日志异步 writer，要在 shutdown 时 close input channel 并 wait 完成
