Pod卡在Terminating状态的根本原因有三：finalizer未清理、kubelet失联（节点NotReady）或网络分区；其中finalizer机制不可被--force绕过，而SIGTERM未响应仅导致30秒延迟。
服务进程卡在 Terminating 状态，先看是否收到 SIGTERM
根本问题常不在 Kratos 本身，而在信号是否真正抵达应用主 goroutine。Kubernetes 发出 SIGTERM 后，若进程没响应，terminationGracePeriodSeconds 耗尽就会强杀——但很多挂起其实是“信号压根没进到 Go runtime”。
常见陷阱：
- 容器启动命令写成
sh -c "exec ./app"或bash -c "./app"：shell 占用 PID 1，不转发信号，Go 进程收不到SIGTERM - 使用
supervisord、entrypoint.sh等中间层且未加exec：同样导致信号断链 -
signal.Notify注册后，监听 goroutine 被提前退出（比如主函数 return 了）：信号通道被 close，后续信号静默丢弃
验证方式：kill -SIGTERM <pid></pid> 后立刻 ps aux | grep <pid></pid>，看进程是否仍在；再用 strace -p <pid> -e trace=rt_sigaction,rt_sigprocmask</pid> 确认信号注册和接收行为。
app.WithBeforeStop 里 deregister 失败导致阻塞
Kratos 的 app.Run 默认不处理优雅退出，必须手动用 app.WithBeforeStop 插入反注册逻辑。但若 registry.Deregister 调用失败且没设超时或重试，整个 shutdown 流程会卡住。
实操要点：
-
registry.Deregister是网络调用，必须带 context 并设 timeout（建议 ≤3s），不能依赖默认无限制等待 - 失败后不应直接跳过，应记录 warn 日志并最多重试 2 次；重试间隔用
time.Sleep(500 * time.Millisecond)，避免打爆注册中心 - 若用
contrib/registry/nacos或etcd，注意其Deregister方法不自带重试，需自行包装
典型错误写法：reg.Deregister(ctx, instance) 直接传入 context.Background() —— 一旦网络抖动，这里就永久 hang 住。
HTTP/gRPC Server Shutdown 超时或未触发 draining
Kratos 底层复用 Go 标准库的 http.Server 和 grpc.Server，它们的 Shutdown / GracefulStop 行为依赖配置。不设超时、不控连接生命周期，会导致 shutdown 阻塞在“等连接自然关闭”上。
关键参数必须显式设置：
-
http.Server.ReadTimeout和WriteTimeout：防止慢请求拖垮 shutdown，建议设为 5–10s -
http.Server.IdleTimeout：控制 keep-alive 连接空闲多久后自动关闭，避免长连接滞留 - gRPC 侧启用
KeepaliveParams，设置MaxConnectionAge（如 30m）和MaxConnectionAgeGrace（如 1m），让客户端主动重建连接，减少 shutdown 时待 drain 的连接数
别依赖 http.Server.Close()：它粗暴关闭监听器，不等活跃连接，会中断正在处理的请求。
goroutine 泄漏让 ctx.Done() 永远不 closed
如果业务代码中启用了长期运行的 goroutine（如轮询、watch、定时任务），且它们用的是 context.Background() 或未监听 app.StopChan()，那么即使 app.WithBeforeStop 执行完，主 goroutine 退出，这些 goroutine 仍存活，导致进程无法真正退出。
排查手段：
-
go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2查看阻塞在 channel receive 或 select 上的 goroutine -
lsof -p <pid></pid>看文件/网络句柄数是否异常高（>500 很可疑） - 检查所有
go func() { ... }()是否都绑定了可取消 context，并在app.WithAfterStop中显式 cancel
最易忽略的一点：数据库连接池、Redis 客户端、gRPC 客户端这些资源的 Close() 方法必须在 WithAfterStop 中调用，否则底层连接不会释放，shutdown 就永远等不到“所有连接关闭”。
