平滑重启本质是旧pod安全退出、新pod接管流量的过程，需通过控制器滚动更新、配置prestop钩子与优雅终止窗口、合理设置就绪探针，并验证业务层面无异常。
Pod 本身没有“重启”操作，所谓平滑重启，本质是让旧 Pod 安全退出、新 Pod 顺利接管流量的过程。关键不在删或启，而在控制生命周期、信号传递和流量切换节奏。
依赖控制器滚动更新
直接删除 Pod 或用 kubectl delete pod 会中断服务，不推荐。正确做法是操作上层控制器：
- 对 Deployment：运行
kubectl rollout restart deployment/<name> -n <namespace></namespace></name>，Kubernetes 会按maxSurge和maxUnavailable策略逐个替换 Pod - 对 StatefulSet：使用
kubectl rollout restart statefulset/<name></name>，它按序号从高到低滚动重建（支持RollingUpdate策略） - 避免批量删除所有 Pod，否则调度压力大、可能触发节点资源争抢甚至雪崩
配置 preStop 钩子与优雅终止窗口
让应用有时间处理完存量请求，而不是被 SIGKILL 强杀：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 在容器 spec 中定义
lifecycle.preStop，例如执行curl -X POST http://localhost/shutdown或调用应用关闭接口 - 设置
terminationGracePeriodSeconds（默认 30 秒），确保 preStop 有足够时间执行；若应用关闭慢，可设为 60–120 秒 - preStop 是同步阻塞的，Kubernetes 会等它完成才继续下一步
配合就绪探针控制流量切换
防止新请求打到尚未就绪或正在退出的 Pod：
-
readinessProbe必须配置，且failureThreshold和periodSeconds要合理（如 3×5s） - 滚动更新时，新 Pod 就绪探针通过后，Service 才将流量导入；旧 Pod 在 preStop 开始前，就绪探针已失败，流量自动摘除
- 避免就绪探针路径返回过快（如只检查进程存在），应验证实际业务能力（如 DB 连通、缓存加载完成）
验证重启是否真正平滑
不能只看 Pod 状态，要观察业务层面表现：
- 查日志：确认旧 Pod 是否打印了“shutdown started”“graceful exit”类信息，新 Pod 是否完成初始化才上报就绪
- 看指标：监控 5xx 错误率、请求延迟突增、连接拒绝数，异常升高说明流量切换有问题
- 用
kubectl rollout status deployment/<name></name>确认更新完成，再结合kubectl get events -w查看是否有 FailedCreate、FailedKillPod 等事件
