deployment通过rollingupdate策略实现无缝滚动更新与回滚，依赖replicaset协调扩缩容，需合理配置maxsurge、maxunavailable、readinessprobe，并配合优雅终止等应用层支持。
在 Kubernetes 中，Deployment 是实现无缝滚动更新与回滚的核心工作负载资源。它通过声明式方式管理 Pod 副本，并借助 ReplicaSet 自动协调旧版本下线、新版本上线的全过程，无需停机即可完成服务升级或故障恢复。
滚动更新的关键配置项
要实现真正“无缝”的滚动更新，需合理设置以下字段：
-
strategy.type 必须设为
RollingUpdate（默认值，但建议显式声明） -
strategy.rollingUpdate.maxSurge 控制更新期间最多可额外创建多少 Pod（支持整数或百分比，如
25%），影响扩容速度和资源开销 -
strategy.rollingUpdate.maxUnavailable 控制更新期间最多允许多少 Pod 不可用（同样支持整数或百分比，如
1或0%），决定服务可用性底线；设为0%可保证全程不丢请求（需配合就绪探针） - readinessProbe 必须配置，确保新 Pod 真正就绪后才接收流量；否则可能将请求发给未启动完成的实例
触发一次安全的滚动更新
更新本质是修改 Pod 模板（如镜像 tag、环境变量、配置等），K8s 会自动创建新 ReplicaSet 并逐步扩缩容：
- 使用
kubectl set image deploy/<em>name</em> <em>container-name</em>=<em>new-image:tag</em>最快捷 - 直接编辑 YAML：
kubectl edit deploy/<em>name</em>，改完保存即触发更新 - 用
kubectl apply -f deploy.yaml重新应用已修改的声明文件（推荐 CI/CD 场景） - 更新过程中可通过
kubectl rollout status deploy/<em>name</em>实时观察进度，直到显示successfully rolled out
快速回滚到上一版本或指定版本
Deployment 会自动保留历史 ReplicaSet（默认最多保留 10 个，由 revisionHistoryLimit 控制），每个 revision 对应一次变更记录：
- 查看历史版本：
kubectl rollout history deploy/<em>name</em> - 回滚至上一版本：
kubectl rollout undo deploy/<em>name</em> - 回滚至指定 revision：
kubectl rollout undo deploy/<em>name</em> --to-revision=2 - 回滚操作本身也是一次新的 Deployment 更新，会生成新 revision，支持再次 undo
保障滚动过程真正“无缝”的实用建议
配置再正确，若应用层不配合，仍可能出现请求失败：
- Pod 必须实现优雅终止：监听
SIGTERM，停止接收新请求，处理完队列后再退出；可在容器中设置preStop生命周期钩子加几秒 sleep 或调用关闭接口 - Service 的
sessionAffinity若设为ClientIP，可能导致部分用户短暂失联，一般建议保持默认None - 避免在更新期间手动删除旧 ReplicaSet —— 这会破坏回滚能力；K8s 会自动清理超出
revisionHistoryLimit的旧版本 - 对关键服务，可先在测试命名空间验证更新流程，再同步到生产
