poddisruptionbudget未拦住滚动更新的根本原因是minavailable/maxunavailable设置与实际pod数量不匹配，尤其副本数为1或2时极易失效；pdb只保证不跌破下限，不保证零中断，需配合prestop、优雅退出及合理超时配置才能实现真正优雅发布。
PodDisruptionBudget 为什么没拦住滚动更新？
根本原因通常是 minAvailable 或 maxUnavailable 设置与实际 Pod 数量不匹配，尤其在副本数为 1 或 2 时极易失效。K8s 的 PDB 不保证“不中断”，只保证“不跌破下限”——比如设了 minAvailable: 1，但 Deployment 只有 1 个副本，那驱逐时就只剩 0，直接违反 PDB，但 K8s 仍可能允许（取决于 eviction API 是否被 controller 拦截）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
kubectl get pdb -n <ns></ns>确认 PDB 已生效，且ALLOWED DISRUPTIONS列不是0 - 检查关联的 Deployment/StatefulSet 标签是否与 PDB 的
selector.matchLabels完全一致（大小写、键名、值都需精确） - 副本数 ≤2 时，优先用
minAvailable: 1；副本数 ≥3 时，maxUnavailable: 1更直观 - Go 应用若依赖本地状态或长连接，光靠 PDB 不够，得配合
preStophook + 优雅退出逻辑
Go 服务怎么配合 PDB 实现真正优雅发布？
PDB 是调度层约束，Go 进程本身必须感知并响应终止信号，否则即使 Pod 没被强制 kill，HTTP 连接也会被粗暴断开。关键不在“不删 Pod”，而在“删之前清完活”。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在 main 启动后立即监听
os.Interrupt和syscall.SIGTERM，不要只监听 Ctrl+C - 收到信号后，先调用
http.Server.Shutdown()，传入 context.WithTimeout()，超时建议 ≥30s（给 LB 和客户端缓冲） - Shutdown 返回后，再关闭数据库连接池、gRPC client、消息消费者等资源
- 务必在
preStop中加 sleep（如sleep 30），确保 Go 有足够时间执行 Shutdown，否则 K8s 可能在你刚收到 SIGTERM 就发 SIGKILL
如何验证 PDB + Go 退出逻辑真起作用？
本地跑 go run 没用，必须在集群里模拟真实驱逐。常见错误是只测了 kubectl delete pod，但这绕过了 PDB 的 admission 控制（PDB 只约束 eviction 子资源，不拦直接删 Pod）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
kubectl drain <node> --dry-run=client -o yaml</node>看预演是否报错“Cannot evict pod” - 真实测试用
kubectl create -f https://k8s.io/examples/controllers/pod-disruption-budget-pdb.yaml配合kubectl drain <node> --ignore-daemonsets</node> - 在 Go 日志里打上 “SIGTERM received”, “HTTP server shutdown started”, “shutdown complete” 三段标记，用
kubectl logs -f观察是否完整打出 - 用
curl -v http://<svc>/healthz</svc>在 drain 过程中持续请求，确认 5xx 出现时间点晚于日志里的 shutdown start，且持续时间 ≤ shutdown timeout
Go 应用里哪些细节会让 PDB 形同虚设？
最隐蔽的坑不是配置错，而是 Go runtime 自身行为和 K8s 机制错位：比如 HTTP handler 里用了无缓冲 channel 写日志、goroutine 泄漏、或 sync.WaitGroup 忘记 Done —— 这些都会让 Shutdown() 卡住，最终触发 K8s 的 terminationGracePeriodSeconds 强杀。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有长期运行的 goroutine 必须有明确退出路径，且绑定到同一个
context.Context（传入主 shutdown context） - 避免在 handler 里启动匿名 goroutine 处理耗时逻辑（如发 MQ、调第三方），改用带 cancel 的子 context
- 用
runtime.NumGoroutine()在 healthz 接口暴露 goroutine 数，发布前后对比，突增说明泄漏 -
terminationGracePeriodSeconds建议设为 60（默认 30 不够），且必须 ≥ Go 里Shutdown()的 timeout
复杂点在于：PDB 是声明式约束，Go 退出是命令式流程，两者之间没有自动对齐机制。你得手动把信号传递、资源释放顺序、超时时间、K8s 生命周期钩子全部串成一条不松动的链——少一环，高可用就断在那个点上。
