考虑跨 3 个可用区的 Statefulset（Cassandra 使用官方 K8S 示例）：
每个 Cassandra Pod 都使用一个 EBS 卷。所以自然而然就有了亲和力。例如，cassandra-0 无法移动到“zone-b”，因为它的卷位于“zone-a”中。都好。
如果某些 Kubernetes 节点/worker 发生故障，它们将被替换。Pod 将在新节点上再次启动并重新附加其 EBS 卷。看上去就像什么都没发生一样。
现在，如果整个可用区“zone-a”出现故障并且在一段时间内不可用（意味着 cassandra-0 由于同一区域中的 EBS 的亲和力而无法再启动）。你剩下：
只要“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 + 并且遇到 …