在Kubernetes部署中，我应该何时使用部署策略

Kubernetes为我们提供了两种部署策略。一个是，另一个是。当我不想停止播放时，我应该使用滚动更新。但是我应该在什么时候使用Recreate？

基本上有两个原因可以解释为什么需要使用Recreate：

• 资源问题。有些集群根本没有足够的资源来安排额外的pod，这会导致它们被卡住，并导致更新过程。这尤其适用于本地开发集群和/或消耗大量资源的应用程序
• 糟糕的应用程序。一些应用程序（尤其是传统的或单片式的设置）根本无法处理新的吊舱（它们做的事情与它们做的完全相同）启动时的问题。这里有太多的原因来解释为什么会覆盖所有这些因素，但本质上这意味着应用程序不适合扩展
+1然而，让我也为已经说过的话添加一些更多的细节和一些现实世界的例子
在一个完美的世界里，每一个应用程序都可以轻松地更新，而且不需要停机，我们完全可以满足于只有策略
但是，由于世界并不是一个完美的地方，所有事情也并非总是像我们希望的那样顺利进行，在某些情况下，也需要使用策略
假设我们有一个有状态的应用程序，在集群中运行，其中各个实例需要相互通信。想象一下，我们的应用程序最近经历了一次重大重构，而这个新版本不能再与运行旧版本的实例对话了。此外，我们甚至可能不希望它们能够形成一个集群，因为我们可以预期，这可能会导致一些不可预测的混乱，因此，当旧实例和新实例同时可用时，它们都无法正常工作。因此，有时，能够首先关闭每个旧复制副本符合我们的最佳利益，只有在我们确保它们都没有运行时，才能生成一个运行新版本的复制副本
当发生重大迁移时可能会出现这种情况，比如说数据库结构发生重大变化等。我们希望确保在迁移期间，运行旧版本应用程序的pod不能将任何新数据写入数据库
所以我想说，在大多数情况下，它是非常特定于应用程序的，涉及重大迁移、遗留应用程序等的单个场景，需要同时接受一定的停机时间和所有POD，而不是像策略中那样逐个更新它们

---

我想到的另一个例子。假设您有一个非常旧的Mongodb版本运行在由3个成员组成的replicaset中，您需要将其迁移到当前支持的现代版本。据我所知，只有当复制集的单个成员之间存在一个主要版本差异时，它们才能形成集群。因此，如果两个或多个主要版本之间存在差异，那么新旧实例将无法在同一集群中继续运行。假设您有足够的资源同时只运行4个副本。因此，在这种情况下，滚动更新不会对您有多大帮助。要达到法定人数，以便选出船长，您需要至少从3名可用成员中选出2名。如果新副本无法与旧副本组成集群，那么最好安排一个维护窗口，关闭所有旧副本，并在删除旧副本后有足够的资源以新版本启动3个副本。
Hello@AdityaBhuyan。下面的答案有帮助吗？