要在Kubernetes中对无状态服务的Deployment执行不停机滚动更新，必须依赖Deployment控制器内置的RollingUpdate机制，并确保Pod生命周期管理与服务流量切换协同工作；默认启用该策略，需验证YAML中未显式设为Recreate，否则将强制终止全部旧Pod导致中断；推荐用kubectl set image命令触发镜像更新，或kubectl edit修改YAML，严禁手动删除Pod；更新中应观察新旧Pod共存、持续HTTP请求返回200以验证服务不中断；异常时可用kubectl rollout undo回滚，全程保持在线。
要在Kubernetes中对无状态服务的Deployment执行不停机滚动更新，必须依赖Deployment控制器内置的RollingUpdate机制，并确保Pod生命周期管理与服务流量切换协同工作。
确认Deployment已启用滚动更新策略
默认情况下，所有新创建的Deployment都使用RollingUpdate策略，但需验证YAML中未显式覆盖为Recreate。执行：kubectl get deployment <strong>my-app</strong> -o yaml | grep -A 5 "strategy:"，输出中应包含type: RollingUpdate。
若缺失或显示type: Recreate，则本次更新将强制终止全部旧Pod再启动新Pod，必然导致服务中断——【必须修正为RollingUpdate才能实现零停机】。
触发镜像版本更新
方法一：使用kubectl set image命令（推荐）
执行：kubectl set image deployment/my-app my-app=nginx:1.25.4。该命令直接修改Deployment的Pod模板中容器镜像字段，立即触发滚动更新流程。
方法二：直接编辑YAML并应用
运行kubectl edit deployment/my-app，定位到spec.template.spec.containers[0].image行，修改镜像标签后保存退出。Kubernetes会自动检测变更并启动更新。
⚠️ 注意：不要手动删除旧Pod或缩容ReplicaSet——这会绕过Deployment控制逻辑，破坏滚动节奏，可能引发流量黑洞或502错误。
监控滚动过程并验证服务连续性
第一步：观察更新状态
执行kubectl rollout status deployment/my-app，等待输出deployment "my-app" successfully rolled out。此命令阻塞直到所有新Pod就绪且旧Pod完全终止。
第二步：检查Pod版本混合状态
运行kubectl get pods -l app=my-app -o wide，在更新中途应看到新旧镜像版本Pod共存，例如nginx-7d8c9f6b5-abcde（v1.25.3）与nginx-5c9d7f8b4-fghij（v1.25.4）同时运行。
第三步：验证服务未中断
在另一个终端持续请求服务：while true; do curl -s -o /dev/null -w "%{http_code}\n" http://my-app-svc; sleep 0.5; done。全程应始终返回200，无502或连接拒绝。
这一步不可跳过——【仅看Pod状态不等于服务可用，必须通过真实HTTP探活验证】。
回滚到上一个稳定版本
若更新后发现异常（如日志报错、延迟飙升、5xx上升），立即执行：kubectl rollout undo deployment/my-app。
该操作将Deployment的Pod模板恢复至上一版本配置，并再次触发一次滚动更新流程，用旧镜像重建Pod。整个过程仍保持服务在线，无需人工干预Pod生命周期。
回滚后建议立刻执行kubectl rollout status确认完成，避免误判为“已回滚”而实际仍在更新中。
