poststart 和 prestop 是 kubernetes 由 kubelet 自动触发的生命周期钩子，非 go 手动调用；需通过 exec、httpget 或 http handler 响应，且须配合 sigterm 捕获与 terminationgraceperiodseconds 实现优雅终止。
PostStart 和 PreStop 不是 Go 代码里“手动调用”的钩子
它们是 Kubernetes Pod 生命周期的一部分，由 kubelet 在容器启动后或停止前自动触发，Go 程序本身不实现 PostStart 或 PreStop 函数——你只能通过容器镜像里的可执行文件、脚本或 HTTP handler 来响应这些事件。
常见错误现象：exec 类型的 PostStart 钩子失败（比如命令不存在、权限不足、超时）会导致 Pod 卡在 ContainerCreating；httpGet 类型的钩子若服务未就绪，也会反复重试直至超时。
- 使用场景：初始化本地缓存、热加载配置、建立连接池（
PostStart）；优雅关闭连接、刷盘、通知注册中心下线（PreStop） -
PostStart没有超时保障，实际由 kubelet 控制（默认 30s），且不保证一定执行成功后才继续调度下一个容器 -
PreStop触发后，kubelet 会等待容器退出，再发送 SIGTERM；若容器没响应，会在terminationGracePeriodSeconds（默认 30s）后强制 kill
在 Go 应用中真正能控制的是 HTTP handler 或信号处理
如果你用 httpGet 方式配置 PreStop，就得在 Go 服务里暴露一个 endpoint；如果用 exec，就得确保容器内有对应二进制或脚本能被调用。
典型错误：Go 服务监听 localhost:8080，但 httpGet 钩子访问的是 127.0.0.1:8080/healthz，结果因服务未绑定 0.0.0.0 而失败。
立即学习“go语言免费学习笔记（深入）”；
- HTTP handler 示例（精简）：
http.HandleFunc("/shutdown", func(w http.ResponseWriter, r *http.Request) { // 执行清理：关闭 DB 连接、等待 pending 请求完成等 cleanup() w.WriteHeader(http.StatusOK) }) - 必须确保该 handler 在容器启动后即可访问，不要依赖延迟初始化逻辑
- 避免在 handler 里做阻塞操作（如长轮询、同步写磁盘），它应快速返回，清理逻辑建议异步触发 + 主动等待
PreStop 的最佳实践：配合 terminationGracePeriodSeconds 和信号捕获
仅靠 PreStop 不足以保证优雅终止，Go 程序必须自己监听 SIGTERM 并配合 PreStop 的触发时机做协同。
常见坑：PreStop 执行完，主进程却还在跑，或者主进程收到 SIGTERM 后立刻退出，导致 PreStop 来不及触发。
- Pod YAML 中至少设
terminationGracePeriodSeconds: 60，给 Go 程序留出足够时间 - Go 里用
signal.Notify捕获SIGTERM，启动 shutdown 流程（如关闭 HTTP server、等待 worker 退出） -
PreStop和SIGTERM是并行发生的，不是先后关系；别假设 “先执行 PreStop 再发信号” - 若用
exec做PreStop，脚本里不要调用kill -TERM 1，这会干扰 kubelet 自己的终止流程
调试钩子失败最有效的三件事
钩子失败不会直接报错在 kubectl logs 里，得去 kubelet 日志或容器事件里找线索。
典型错误信息：FailedPostStartHook、FailedPreStopHook、container exited abruptly。
- 查事件：
kubectl describe pod <pod-name></pod-name>，重点看 Events 区域 - 查 kubelet 日志（节点上）：
journalctl -u kubelet -n 100 --no-pager | grep -A 2 -B 2 "hook" - 临时把
exec钩子改成sleep 10，确认是否真能触发；或加echo "prestop ran" > /tmp/prestop.log看文件是否存在
最容易被忽略的一点：钩子运行在容器的同一个命名空间里，但它的 stdin/stdout 是丢弃的，所有输出必须显式重定向到文件或日志系统才能排查。
