滚动更新由Deployment控制器触发，依赖strategy.type设为"RollingUpdate"及rollingUpdate.maxSurge、maxUnavailable配置；其本质是逐批扩缩Pod，而非Kubernetes直接滚动。
滚动更新是怎么触发的？靠 Deployment 的 strategy.type 和 rollingUpdate 配置
Kubernetes 本身不直接“滚动”，真正执行滚动更新的是 Deployment 控制器。它通过声明式配置决定如何替换旧 Pod：只要把 strategy.type 设为 "RollingUpdate"（默认值），再配好 rollingUpdate.maxSurge 和 rollingUpdate.maxUnavailable，控制器就会按策略逐批扩缩。
常见误配点：
-
maxSurge: 1表示最多允许比期望副本数多启动 1 个新 Pod；设成"25%"则按百分比向上取整（比如 replicas=4 时，允许最多多启 1 个） -
maxUnavailable: 0意味着更新期间不允许任何服务中断——必须先扩出新 Pod 并就绪，才能删旧 Pod；但若新 Pod 卡在ContainerCreating或健康检查失败，滚动会卡住 - 没写
rollingUpdate块？K8s 会用默认值：maxSurge=25%,maxUnavailable=25%，这在小规模集群（如 replicas=1）下可能直接导致服务不可用
kubectl set image 和 kubectl apply -f 更新行为一样吗？
本质一样，都是修改 Deployment 的 spec.template.spec.containers[*].image 字段，触发控制器重建 Pod。但操作路径不同，影响也不同：
-
kubectl set image deploy/myapp mycontainer=nginx:1.25是命令式修改，适合快速迭代；但它绕过本地 YAML 文件，容易和 GitOps 流程脱节 -
kubectl apply -f deploy.yaml是声明式更新，推荐用于生产；注意：如果 YAML 中没显式写strategy，apply 后会继承默认策略，而非保留上次手动设置的值 - 两者都会导致
deployment.kubernetes.io/revision注解递增，且旧 ReplicaSet 不会被立即删除（默认保留revisionHistoryLimit: 10个）
滚动过程中 Pod 为什么卡在 Terminating 状态？
这不是滚动机制的问题，而是容器自身生命周期没处理好。K8s 发送 SIGTERM 后，会等待 terminationGracePeriodSeconds（默认 30 秒）再发 SIGKILL。如果应用没响应 SIGTERM、或清理逻辑阻塞（比如数据库连接未关闭、文件句柄未释放），Pod 就会 hang 在 Terminating。
- 检查容器是否捕获并处理
SIGTERM：Node.js 应用需监听process.on("SIGTERM", ...)；Java 应用建议用spring-boot-starter-actuator+livenessProbe配合优雅停机 - 确认
terminationGracePeriodSeconds是否足够：高负载场景下可设为60或120 - 避免在
preStophook 中执行长耗时命令（如sleep 30），它会进一步延长 Terminating 时间
滚动更新失败后怎么回滚？kubectl rollout undo 能恢复到哪一版？
kubectl rollout undo deployment/myapp 默认回滚到上一个 ReplicaSet（即 revision-1），前提是那个 ReplicaSet 还存在（受 revisionHistoryLimit 限制）。它本质是把当前 Deployment 的 spec.template 替换为历史版本的模板，并触发新一轮滚动。
- 想回滚到特定版本？加
--to-revision=3；用kubectl rollout history deploy/myapp查看可用 revision 列表 - 回滚不是“撤销命令”，而是另一次滚动更新——所以同样受
maxUnavailable等策略约束，也可能失败 - 如果已手动删过旧 ReplicaSet，或
revisionHistoryLimit太小（比如设为 1），就只能靠重新apply旧版 YAML 来恢复
真正难的不是触发滚动，而是让每个 Pod 在新旧交替时既不丢请求，也不卡退出——这取决于镜像里程序怎么写，而不是 K8s 配置怎么写。
