嘿，这个问题问得很实在！虽然Rolling Update是大多数情况下避免服务中断的首选，但Recreate策略在某些特定场景下反而更合适，甚至是必须的。下面就聊聊哪些情况该优先考虑它：

• 应用不支持新旧版本共存：有些应用天生是单实例架构，或者新旧版本会共享无法同时访问的独占资源（比如独占数据库锁、本地绑定的存储卷），甚至新版本会修改旧版本依赖的核心数据结构——这种时候如果用Rolling Update，新旧实例同时运行会直接导致数据冲突、业务逻辑崩溃。不如先停掉所有旧实例，再启动新的，彻底避免兼容性问题。

• 集群资源紧张：如果你的K8s节点资源有限，Rolling Update需要短暂同时运行新旧实例，这会额外占用CPU、内存或存储。比如你的节点刚好只能容纳一个应用实例，Rolling Update会因为资源不足卡住。这时候Recreate就很贴心：先销毁旧实例释放资源，再用这些资源启动新实例，完全不会有资源竞争的问题。

• 需要彻底重置应用状态：如果应用运行一段时间后积累了大量缓存、临时文件，或者新版本需要完全重置配置/状态，重新启动一个干净的实例比在旧实例上更新更可靠。比如某些数据分析类应用，每次版本更新需要清空所有历史临时数据，Recreate可以一次性把旧实例的状态全部清除，新实例从零开始。

• 测试/开发环境快速验证：在测试或开发环境中，我们通常不需要保证服务持续可用，更看重部署速度。Recreate的部署流程更简单直接，不需要等待新旧实例的逐步切换，一键完成替换，能帮你节省不少验证时间。

• 短生命周期的批处理任务：比如定时运行的批处理Job、一次性任务这类应用，本身就不需要持续对外提供服务。更新的时候直接替换旧实例完全没问题，没必要用Rolling Update那套复杂的切换逻辑，徒增部署成本。

内容的提问来源于stack exchange，提问作者Aditya Bhuyan