StatefulSets 中并行 podManagementPolicy 相对于 OrderedReady podManagementPolicy 有哪些优缺点？

Question

我最近将 StatefulSet 中的 podManagementPolicy 字段从默认（OrderedReady）更新为 Parallel。

• 它显着减少了放大和缩小时间。
• 到目前为止，我还没有看到这一变化的任何缺点，但我担心是否会出现任何可能给我带来问题的情况？

我想知道我是否会遇到任何问题？

Answer 1

我想稍微扩展一下这个话题。

PodOrderedReady管理的行为如下：

• 对于具有 N 个副本的 StatefulSet，在部署 Pod 时，会按照从 {0..N-1} 的顺序依次创建 Pod。

• 当 Pod 被删除时，它们会以相反的顺序终止，从 {N-1..0} 开始。

• 在将扩展操作应用于 Pod 之前，其所有前任都必须处于 Running 和 Ready 状态。

• 在 Pod 终止之前，其所有后继者必须完全关闭。

而ParallelPod 管理：

告诉 StatefulSet 控制器并行启动或终止所有 Pod，并且在启动或终止另一个 Pod 之前不要等待 Pod 变为“正在运行”和“就绪”状态或完全终止。此选项仅影响缩放操作的行为。更新不受影响。

理论上，您在更新应用程序时不会面临任何停机，因为parallel策略只会影响扩展操作。正如乔纳斯已经说过的，如果不了解你的应用程序和架构，就很难预见潜在的后果。但通常可以肯定地说，如果您的应用程序的实例不相互依赖（因此不必等待每个 Pod 运行并准备就绪），则该parallel策略应该比该策略更安全且更快OrderedReady。但是，如果您StatefulSet将来可能遇到任何问题并希望从 Kubernetes 方面进行分析，这些官方文档可能会对您有所帮助。

Answer 2

StatefulSets 中并行 podManagementPolicy 相对于 OrderedReady podManagementPolicy 有哪些优缺点？

这完全取决于您的应用程序。是否需要有序实例扩展和缩减？

如果您共享您正在使用的应用程序，则可以更轻松地判断它是否容忍实例按特定顺序纵向扩展或缩减。

例如，一个分布式数据库（将数据复制到其实例）可能会运行 3 个实例，然后您希望扩展到 5 个实例，但需要时间将数据复制到这两个新实例，并且您可能会后悔扩大规模。在这种情况下，最好缩小尚未完全复制的两个实例。