我最近将 StatefulSet 中的 podManagementPolicy 字段从 default(OrderedReady) 更新为 Parallel。
我想知道在任何情况下我会遇到什么问题吗？
【问题讨论】：
标签： kubernetes cloud microservices kubernetes-pod kubernetes-statefulset
StatefulSets 中并行 podManagementPolicy 相对于 OrderedReady podManagementPolicy 有哪些优缺点？
这完全取决于您的应用程序。是否需要有序的实例扩容和缩容？
如果您共享您正在使用的应用程序，则更容易判断它是否容忍实例按特定顺序向上或向下扩展。
例如一个分布式数据库 - 将数据复制到其实例 - 可能运行 3 个实例 - 然后您希望扩展到 5 个 - 但是将数据复制到这两个新实例需要时间 /em> - 你可能会后悔扩大规模。在这种情况下，最好缩小两个尚未完全复制的实例。
【讨论】：
StatefulSet - 如果实例相互通信 - 这取决于您的应用程序需要什么。但如果实例是相对独立的 - 并行应该没问题。
我想稍微扩展一下这个话题。
OrderedReady pod management 的行为如下：
对于具有 N 个副本的 StatefulSet，在部署 Pod 时，它们是按顺序创建的，从 {0..N-1} 开始。
当 Pod 被删除时，它们会以相反的顺序被终止，从 {N-1..0} 开始。
在对 Pod 应用扩展操作之前，它的所有前辈都必须处于 Running 和 Ready 状态。
在终止 Pod 之前，它的所有后继者必须完全关闭。
告诉 StatefulSet 控制器启动或终止所有 Pod 并行，并且不等待 Pod 变为 Running 和 Ready 或 在启动或终止另一个 Pod 之前完全终止。 此选项仅影响缩放操作的行为。更新 不受影响。
理论上，您在更新应用时不会面临任何停机时间，因为parallel 策略只会影响扩展操作。正如 Jonas 已经说过的那样，如果不了解您的应用程序和架构，很难预见潜在的后果。但通常可以肯定地说，如果您的应用程序实例不相互依赖（因此不必等待每个 pod 运行并准备好），parallel 策略应该比OrderedReady 更安全且更快一。但是，如果您将来可能会遇到 StatefulSet 的任何问题并想从 Kubernetes 方面对其进行分析，那么这些 official docs 可能对您有所帮助。
【讨论】：