滚动更新

【背景】 做 K8s 容器化运维 5 年，探针配置是每个集群都绕不开、但几乎没人认真讨论过的配置项。我复盘过两次线上事故，恰好踩在两个极端： 事故一（重启风暴）：一个 Java 订单服务，livenessProbe 配的是 "httpGet

背景 12 节点 K8s 1.28.9 + Istio 1.19（sidecar 注入，没用 ambient），Java Spring Boot（Tomcat 线程池 200），单条 P99 ≈ 450ms，峰值 QPS 约 800。滚动更

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

«结论先行："preStop" 里写一个 "sleep 5" 并不是"优雅下线"，它只是在赌 kube-proxy / iptables 规则的下发速度。 下面是一次真实的滚动更新事故复盘，以及我们最终落地的完整优雅下线方案。» 一、现象与

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

«结论先行："terminationGracePeriodSeconds" 的计时器从 Kubelet 开始执行停机（含 preStop）那一刻就启动了，preStop sleep 不是"额外加"的缓冲，而是从总窗口里"扣"掉的。当你 pr

背景 我做了 15 年运维，最近团队一个 3 副本的 Java 业务（K8s 1.28.9，containerd 1.7.13，cgroup v2）做 rolling update 时翻车：老 Pod 卡在 "Terminating" 状态