Go服务在Kubernetes中不优雅退出主因是未正确处理SIGTERM且未与terminationGracePeriodSeconds对齐；Echo框架无内置优雅停机，需手动集成signal.Notify与server.Shutdown()，并确保Shutdown超时小于terminationGracePeriodSeconds，同时配合就绪探针状态控制与并发安全清理。
Go 服务在 Kubernetes 中不优雅退出，90% 是因为没正确处理 SIGTERM，且没和 terminationGracePeriodSeconds 对齐。Echo 框架本身不内置优雅停机逻辑，必须手动集成信号监听 + server.Shutdown()，否则 Pod 会被 SIGKILL 强杀，导致请求中断、连接泄漏、日志截断。
为什么 Echo 默认不支持优雅停机
Echo 是一个轻量 HTTP 路由框架，它的 echo.Start() 底层调用的是 Go 标准库 http.Server.Serve()，而该方法是阻塞式启动，不响应外部信号。它既不监听 SIGTERM，也不自动调用 Shutdown() —— 这些都得你自己补。
-
echo.Start()等价于http.ListenAndServe()，无上下文控制能力 - 直接用
os.Exit(0)响应信号会跳过清理，数据库连接、goroutine、日志 flush 都可能丢失 - 若未显式调用
server.Shutdown()，http.Server会在收到SIGTERM后继续接受新请求，直到被SIGKILL终止
如何用 signal.Notify + server.Shutdown 实现真正优雅退出
核心是：启动一个独立 goroutine 监听 SIGTERM（Kubernetes 发送的唯一可捕获终止信号），收到后触发 http.Server.Shutdown()，并等待所有活跃连接完成。
- 必须用
http.Server实例启动 Echo，不能用echo.Start() -
Shutdown()需传入带超时的context.Context，否则可能永久阻塞 - 建议在
Shutdown()前关闭自定义资源（如 DB 连接池、消息消费者），避免 shutdown 期间仍有新任务提交
示例关键代码：
srv := &http.Server{
Addr: ":8080",
Handler: e,
}
go func() {
if err := srv.ListenAndServe(); err != http.ErrServerClosed {
log.Fatal(err)
}
}()
quit := make(chan os.Signal, 1)
signal.Notify(quit, syscall.SIGTERM, syscall.SIGINT)
<-quit
log.Println("shutting down server...")
ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil {
log.Fatal("server shutdown error:", err)
}
与 Kubernetes terminationGracePeriodSeconds 的协同要点
terminationGracePeriodSeconds 不是“等多久再发信号”，而是“发完 SIGTERM 后最多等多久，超时就发 SIGKILL”。Echo 的 Shutdown() 超时必须严格小于它，否则必然被强杀。
- 若配置
terminationGracePeriodSeconds: 30，则Shutdown()的 context 超时建议设为25s，留出 5s 缓冲给 OS 和容器运行时 - PreStop 钩子（如
sleep 5）会占用这 30 秒的一部分，要从总宽限期里扣除 - Kubelet 在发送
SIGTERM前已将 Pod 从 Endpoints 移除，所以Shutdown()阶段只处理存量请求，不会进新流量
常见踩坑：Readiness Probe 未及时失效
即使 Echo 正确响应 SIGTERM，如果 /healthz 或其他就绪探针路径在 Shutdown() 开始后仍返回 200，Kubernetes 可能延迟摘除 Endpoint，导致新请求打到正在关闭的 Pod。
- 不要让就绪探针只检查进程存活；应结合内部状态，例如加一个
atomic.Bool标记是否已进入 shutdown 流程 - 在收到
SIGTERM后立即将就绪状态置为 false，并在Shutdown()完成后再退出，确保 probe 返回 503 - 避免使用
livenessProbe作为优雅退出判断依据——它失败会触发重启，与终止逻辑冲突
最易被忽略的是 shutdown 期间的并发安全：比如日志写入、metrics 上报、异步任务取消，都可能因 goroutine 未同步退出而 panic 或丢数据。Echo 本身不管理这些，全靠你用 sync.WaitGroup 或 context.WithCancel() 显式协调。
