-
我给容器化的服务做了优雅停机、代码里明明监听了 SIGTERM 信号,可每次 kubectl 删 Pod 它都不优雅退出、非要硬等三十秒被强杀,我对着代码反复确认信号处理逻辑没问题,最后才发现根子在 Dockerfile 那行用 shell 形式写的 CMD、我的应用压根不是容器里的 1 号进程的深度复盘
我给容器化的服务做了优雅停机:收到停止信号时先停接新请求、把手头请求处理完、关好连接再退出,代码里老老实实注册了 SIGTERM 处理函数,本地手动 kill 进程完美触发。可部署上 K8s 后,每次滚动更新或 kubectl delete pod、Pod 都要卡足整整 30 秒才消失——正是 terminationGracePeriodSeconds 默认值,也就是 K8s 发了 SIGTERM…- 0
- 0
-
一个没有处理 SIGTERM 的服务,每次滚动发布都会硬生生掐断一批正在处理的请求,丢单又报错:一次优雅停机缺失的深度复盘
每次上线滚动重启,监控都准时出现一小撮 5xx 和超时,客服收到零星下单失败投诉,赶上高峰就放大成一大批丢单。根因是服务完全没做优雅停机:部署滚动更新时给老进程发 SIGTERM,而进程没捕获它,被立即终止或宽限期后 SIGKILL 强杀,正在处理的请求被硬生生掐断、连接没关、事务可能没提交。本文讲透优雅停机要解决什么和信号机制,给出捕获 SIGTERM、srv.Shutdown 停接新请求等存量…- 0
- 0
-
每次发版滚动更新都会冒出一波请求失败,我以为做了优雅停机,排查才发现应用根本没收到关闭信号,我对着 Dockerfile 用 shell 形式启动让 PID 1 吞掉 SIGTERM 这个坑排查大半天的复盘
一个让我对容器里进程怎么活怎么死彻底搞明白的 DevOps 坑,隐蔽在我明明以为做了优雅停机(应用里写了关闭钩子),发版时却总有一小波请求失败,而那个优雅停机逻辑像从没被触发过——收到的关闭信号在到达它之前就被吞掉了。每次滚动更新监控就冒出一小波 5xx,用户偶尔反馈操作失败。Dockerfile 用了 CMD java -jar app.jar(shell form)。深究才明白:容器里 PID…- 0
- 0
-
我每次发布服务监控就报一批 5xx,我一直以为是发布时正常的网络抖动,最后发现是 Pod 被杀时根本没做优雅停机、正在处理的请求被硬生生掐断的深度复盘
我的服务跑在 K8s 上滚动发布,每次发布监控都冒一批 5xx,我一直当成"发布时正常的网络抖动"没在意。可它每次必现、投诉变多,深究才知根本不是抖动:K8s 下线旧 Pod 时发 SIGTERM,而我的程序压根没处理这个信号——要么立刻退出、把正在处理的请求直接丢弃,要么被 SIGKILL 强杀;再加上 endpoints 摘除有延迟,Pod 关闭后还有新请求被误路由过来。我…- 0
- 0
-
服务优雅停机完全指南:从一次"一发版就冒 500、用户请求被拦腰斩断"看懂 SIGTERM 与连接排空
2021 年我做一个后端服务部署重启这件事我压根没多想。第一版我做得很省事要发新版本就把旧进程 kill 掉再起一个新的不就完了。本地开发时真不错 Ctrl+C 停掉改完代码再跑起来一气呵成我从没觉得停掉一个进程这件事有什么讲究。我心里很踏实重启嘛不就是杀掉旧的起来新的进程而已说停就停。可等这个服务真正上线要在有真实流量时反复发版一串问题冒了出来。第一种最先把我打懵每次一发版监控面板上就准时冒出一…- 0
- 0
优雅停机
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×