基本上有两个原因为什么人们想要/需要使用Recreate：

• 资源问题。一些集群根本没有足够的资源来调度额外的Pod，这会导致它们被卡住，更新过程也会被卡住。这尤其发生在本地开发集群和/或消耗大量资源的应用程序中。
• 糟糕的应用程序。一些应用程序（特别是遗留或单片设置）根本无法处理它时，新的Pod-做完全相同的事情，因为他们做-旋转。有太多的原因可以解释为什么会发生这种情况，但本质上这意味着应用程序不适合扩展。

+1到F1ko's answer，然而，让我也添加一些更多的细节和一些真实的世界的例子已经说过。
在一个完美的世界里，每个应用程序都可以轻松更新，没有停机时间我们将完全满足于只有滚动更新策略。
但是，由于世界不是一个完美的地方，所有的事情并不总是那么顺利，因为我们可以希望，在某些情况下，也有必要使用再造战略。
假设我们有一个有状态应用，运行在集群中，其中各个示例需要相互通信。想象一下，我们的应用程序最近经历了一次重大的重构，这个新版本不能再与运行旧版本的示例进行对话。此外，我们甚至可能不希望它们能够一起形成集群，因为我们可以预期，这可能会导致一些不可预测的混乱，因此当旧示例和新示例同时可用时，它们都无法正常工作。因此，有时候，我们最感兴趣的是能够首先关闭每个旧副本，只有当我们确保它们都没有运行时，才能生成一个运行新版本的副本。
当有一个主要的迁移时，比如说数据库结构的一个主要变化等，可能就是这种情况。并且我们希望确保在迁移期间，没有运行旧版本应用程序的pod能够将任何新数据写入数据库。
所以我想说，在大多数情况下，它是非常特定于应用程序的，涉及主要迁移，遗留应用程序等的单个场景，需要接受一定的停机时间并立即重新创建所有Pod，而不是像滚动更新策略那样逐个更新它们。
另一个我想到的例子。假设你有一个非常旧的Mongodb版本，运行在一个由3个成员组成的复制集中，你需要将它迁移到一个当前支持的现代版本。据我所知，复制集的单个成员只有在它们之间有一个主要版本差异时才能形成集群。因此，如果存在2个或更多主版本的差异，则新旧示例无论如何都无法在同一集群中继续运行。假设您有足够的资源同时运行4个副本。所以滚动更新在这种情况下帮不了你什么。要有法定人数，以便可以选举主服务器，您需要3个可用成员中至少有2个。如果新的副本无法与旧的副本形成集群，最好安排一个维护窗口，关闭所有旧的副本，并有足够的资源在旧的副本被删除后用新版本启动3个副本。