优雅退出

【背景】 做了 5 年 K8s 运维，最近半年帮 3 个团队排查「发布期 502 / 连接被 RST」，根因惊人地一致：不是探针配错，而是对「优雅退出到底在保护什么」没有共识。我抽出来的典型现象： 1. Service 摘流（iptable

背景 我维护一个 20 节点（16C64G，K8s 1.28.9，containerd 1.7.13，cgroup v2）生产集群，其中 60% 节点是 Spot 抢占式实例（阿里云，按量+抢占混合池），核心服务是 Java 17 无状态

背景 12 节点（16C64G），Kubernetes 1.28.9，containerd 1.7.13，cgroup v2。 订单服务 Pod 里两个容器： - main：Java 17 / Spring Boot 3，"-Xmx3g"，

背景 15 年嵌入式出身，早期 MCU 上"退出"就是把外设时钟关掉、把中断清掉、关键变量落 flash，然后系统复位——几乎没有"优雅"空间，因为资源就那么点，多一毫秒都是钱。这两年主力转容器化和 K8s 运维，反而发现"优雅退出"在容器

一、现象：一次常规发布，2 个 Pod 卡 Terminating 90 秒，用户侧 3 个请求 502 上周三下午 15:40，我们给一个 Go 服务（Kubernetes 1.28.9，containerd 1.6.24，Deploym

背景 我在一个 12 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2）的在线业务集群里，日志采集一直用老式 sidecar 模式——主容器跑业务，sidecar 容器跑 fil