# 

滚动发布期间，网关侧出现了一小段 502。查下来容器里配了退出前钩子，日志也确确实实打印了钩子里等待的那几秒，但仍有请求在退出过程中被拒绝。

钩子跑了，和请求不被打断，是两件不同的事。

## 容器退出时到底发生了什么？

删除一个 Pod 时，控制面先把它标记为删除，然后节点上的组件按顺序处理：先执行容器里配置的退出前钩子，钩子结束后再给容器主进程发终止信号，进程自己收尾退出。

容器状态在接口里能看到三种：

| 状态 | 含义 | 常见原因 |
| --- | --- | --- |
| Waiting | 尚未运行 | 镜像拉取中、挂载未就绪 |
| Running | 正在运行 | 正常服务中 |
| Terminated | 已结束 | 正常退出、被强制杀死、启动失败 |

排查退出问题，先看状态里的原因和退出码，比翻应用日志快得多。退出码能直接告诉你进程是「自己走的」还是「被杀的」。

三种状态是互斥的，同一个时刻只会有一个。所以查问题时可以先确认状态，再看那个状态里的细分字段：等待态看原因，运行态看启动时间，结束态看退出码和信号。

## 官方文档怎么描述钩子与状态的关系？

文档里这句话确定了顺序：

> If a container has a preStop hook configured, this hook runs before the container enters the Terminated state.

翻译过来：容器如果配置了退出前钩子，这个钩子在容器进入「已结束」状态之前执行。也就是说它是同步的，钩子跑完，容器才被标记为结束。

宽限期在文档里也有明确定义：

> A Pod is granted a term to terminate gracefully, which defaults to 30 seconds.

含义是：Pod 会被给予一段优雅终止的时间，默认三十秒。

## 宽限期和钩子是什么关系？

这里要谨慎一点：上面那一页文档并没有逐字写「宽限期覆盖钩子与进程退出的总和」。这个结论是按字段定义推出来的——宽限期是 Pod 级别的字段，从删除动作开始计时，时间到就强制结束；钩子执行在删除之后、进程退出之前。两者共用同一个倒计时。

所以实际可用的时间是：钩子耗时加上应用排空耗时，必须小于宽限期。不是各自独立拥有三十秒。

这条推论有实践依据：把钩子里的等待设成超过宽限期，容器会在钩子还没结束时被强制终止，日志里能直接看出钩子没跑完。

反过来说，调大宽限期不是万能解。宽限期变长，发布整体变慢，节点资源释放也变慢，滚动过程中的容量会短暂下降。它应该刚好覆盖前面的时间预算，而不是越大越安全。

## 为什么钩子跑了请求还是被打断？

四个原因，按出现频率排。

第一，流量没有提前摘除。钩子只负责「通知应用准备退出」，它不负责把请求从负载均衡里摘掉。摘除是通过就绪状态传播的，存在延迟；在这段延迟里新请求仍然会进来。

第二，应用没处理终止信号。很多镜像用 shell 启动应用，主进程是 shell，信号发给了 shell 却没有转给应用，应用根本没收到，最后被强制杀死。

第三，钩子时间不够。钩子只是等了几秒，应用自己在处理长连接、批量任务，排空时间远大于剩余宽限期。

第四，探针没配对。就绪探针只看端口通不通，不看是否还能处理请求，退出过程中仍然报就绪。

| 现象 | 最可能的原因 |
| --- | --- |
| 退出码 137 | 被强制杀死，宽限期用尽 |
| 钩子日志有，应用收尾日志没有 | 信号没传到应用进程 |
| 每次发布固定丢几十个请求 | 端点摘除与应用退出并发 |
| 只有长连接报错 | 排空时间不足 |
| 容器反复重启 | 启动探针过严，与退出无关 |

第三行最难解释清楚，因为它的量级非常稳定：每次发布丢的请求数几乎一样，看着不像故障，更像一个固定损耗。

还有一个伴随现象：故障只在滚动发布时出现，单实例重启反而不明显。原因是单实例重启时流量本来就被挪走了，掩盖了摘除延迟这个环节。

## 正确的配置长什么样？

目标是让三段时间串起来，而不是并起来：先摘流量，再让应用停止接新请求，最后处理完在途请求退出。

```yaml
spec:
  terminationGracePeriodSeconds: 45   # 钩子 + 排空 + 余量
  containers:
    - name: api
      lifecycle:
        preStop:
          exec:
            command: ["sleep", "10"]   # 等端点摘除传播
      # 应用侧收到终止信号后：停止接受新连接、处理完在途、退出
```

四十五秒不是拍脑袋：十秒等摘除，二十秒排空，十五秒余量。三个数都要在压测里验证过，不能只看配置写得好不好看。

| 时间段 | 典型取值 | 作用 | 少了会怎样 |
| --- | --- | --- | --- |
| 钩子等待 | 5 到 10 秒 | 等端点摘除传播 | 新请求继续打到正在退出的实例 |
| 应用排空 | 按实测上界 | 处理完在途请求 | 长连接被硬断 |
| 安全余量 | 30% 左右 | 吸收高峰抖动 | 平时正常、大促超时 |

镜像这一侧要保证应用自己是主进程：

```dockerfile
# 用 exec 形式，让应用成为 1 号进程，才能收到终止信号
ENTRYPOINT ["/app/server"]
# 不要写成 ENTRYPOINT /app/server && ...
```

如果应用是常见的那几种运行时，还要在代码里注册终止信号处理，显式关闭监听、等待在途请求结束。默认行为往往是立即退出，正在处理的请求直接断掉。

这一层不能用钩子里多等几秒来替代。钩子等的是「外部流量走开」，代码等的是「自己手里的活干完」，两件事的完成条件不同，谁也覆盖不了谁。

## 怎么确认钩子到底有没有跑完？

三步。第一步看 Pod 事件，重点看终止和杀死的时间点，能看出宽限期是不是用尽了。第二步看容器状态里的退出码，137 说明是被强制终止。第三步进容器看 1 号进程是谁，如果不是应用本身，信号链路就有问题。

```bash
# 看退出码与原因：137 = 被 SIGKILL
kubectl get pod <name> -o jsonpath='{.status.containerStatuses[*].state.terminated}'
# 看 1 号进程是不是应用
kubectl exec <name> -- ps -o pid,comm -p 1
```

还有一点容易忽略：钩子里的命令要有超时意识。有些钩子调用外部接口做注销，接口一慢，钩子自己就把宽限期耗光了，这时候表现和「没配钩子」几乎一样。

## 这套配置后来怎么固化的？

我们把宽限期、钩子、排空时间做成模板里的固定三项，新服务接入时按模板填，不允许留空。模板旁边附了验证步骤：发布前在低流量环境跑一次滚动更新，看网关侧有没有 5xx。

这套模板最初是在一次大促前的压测里攒的，后来用 AI墨衍 把几次发布事故的现象整理成「现象、原因、改哪一项」的对照，现在成了接入流程的一部分。

## 不用钩子能不能做到？

可以，但要求更高。一种做法是应用自己在收到终止信号后先等几秒再停服务，等价于把钩子搬进代码。另一种是依赖就绪状态的传播足够快，这在跨可用区、跨网关的场景下并不可靠。

钩子的价值在于它不依赖应用代码，换了语言、换了框架都不用重写。代价是多一段固定等待，发布节奏会慢一点。

还有一种折中：把钩子做得极短，只负责把一个本地的健康标记置为不健康，让探针立刻把实例从端点里摘掉，剩下的排空交给应用自己做。这样等待时间可控，也不用猜传播延迟。

## 这个时间该怎么定？

从后往前推。先量出应用在满负载下排空在途请求需要多久，取那个值的上界；再加上端点摘除的传播延迟，这个延迟与网关类型、节点数量有关，只能实测；最后留一段余量。

余量的作用是吸收抖动。少了它，压测刚好够、线上高峰就超时，表现成「平时没问题、大促必挂」。

三个数加起来才是宽限期，缺一项都会退化成「某个环节刚好卡在边界上」，而边界问题最难复现。

## 排空时该拒绝还是该继续服务？

标准做法是「拒绝新连接、服务完存量」。只拒绝不服务，在途请求会收到错误；只服务不拒绝，排空永远结束不了，因为总有新请求进来。

实现上通常两步：先关闭监听端口，不再接受新连接；再等连接池里在途的请求数归零；最后退出进程。等待要有上限，超过上限就强制退出，否则一个卡住的请求能把整个发布拖住。

## 小结

三句话：钩子先于终止状态执行，但流量摘除是另一条链路；宽限期是钩子与排空共用的总额度；应用必须是 1 号进程才收得到信号。


滚动发布期间，网关侧出现了一小段 502。查下来容器里配了退出前钩子，日志也确确实实打印了钩子里等待的那几秒，但仍有请求在退出过程中被拒绝。

容器优雅退出的钩子跑了，请求还是被打断

人工智能

滚动发布时容器退出阶段偶发502：preStop钩子执行完毕并不等同于请求不被打断。核心链路是流量摘除延迟、应用未处理终止信号、宽限期（默认30秒）为钩子与排空共用总额度。配置需串行安排摘流量、停新请求、处理在途，应用须为1号进程，退出码137及Pod事件是排查关键。

负载均衡

代码解释

容器

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

容器优雅退出的钩子跑了，请求还是被打断-腾讯云开发者社区-腾讯云

容器优雅退出的钩子跑了，请求还是被打断

容器优雅退出的钩子跑了，请求还是被打断

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐