Kubernetes 有状态集、可用区和卷声明：可用区失败时会发生什么

Question

考虑跨 3 个可用区的 Statefulset（Cassandra 使用官方 K8S 示例）：

• cassandra-0 -> 区域 a
• cassandra-1 -> 区域 b
• cassandra-2 -> c 区

每个 Cassandra Pod 都使用一个 EBS 卷。所以自然而然就有了亲和力。例如，cassandra-0 无法移动到“zone-b”，因为它的卷位于“zone-a”中。都好。

如果某些 Kubernetes 节点/worker 发生故障，它们将被替换。Pod 将在新节点上再次启动并重新附加其 EBS 卷。看上去就像什么都没发生一样。

现在，如果整个可用区“zone-a”出现故障并且在一段时间内不可用（意味着 cassandra-0 由于同一区域中的 EBS 的亲和力而无法再启动）。你剩下：

• cassandra-1 -> 区域 b
• cassandra-2 -> c 区

只要“zone-a”不可用，Kubernetes 将永远无法启动 cassandra-0。这一切都很好，因为 cassandra-1 和 cassandra-2 可以处理请求。

现在，如果除此之外，另一个 K8S 节点出现故障或者您设置了基础设施的自动扩展，则最终可能需要将 cassandra-1 或 cassandra-2 迁移到另一个 K8S 节点。这应该不是问题。

但根据我的测试，K8S 不会这样做，因为 pod cassandra-0 已离线。它永远不会自我修复 cassandra-1 或 cassandra-2（或任何 cassandra-X），因为它希望首先恢复 cassandra-0。cassandra-0 无法启动，因为它的卷处于已关闭且无法恢复的区域。

因此，如果您跨区域使用Statefulset + VolumeClaim + 并且遇到整个可用区故障 并且在另一个可用区中遇到 EC2 故障或者对基础设施进行自动扩展

=> 那么你将失去所有的 Cassandra pod。直到a区重新上线

这看起来是一个危险的情况。有没有办法让有状态集不关心顺序并仍然自我修复或在 cassandra-3、4、5、X 上启动更多 pod？

Answer 1

podManagementPolicy从 Kubernetes 1.7 开始，您可以使用选项（文档）告诉 Kubernetes 放宽 StatefulSet 排序保证。通过将该选项设置为ParallelKubernetes，将不再保证启动或停止 pod 以及并行启动 pod 时的任何顺序。这可能会对您的服务发现产生影响，但应该可以解决您正在讨论的问题。