amazon-web-services - Kubernetes状态集，可用区和批量声明:可用区失败时会发生什么

Question

考虑3个可用区中的Statefulset(Cassandra，使用官方K8S示例):

cassandra-0->区域

cassandra-1-> b区

cassandra-2-> c区

每个Cassandra pods 均使用EBS体积。因此自动存在亲和力。例如，cassandra-0无法移动到“zone-b”，因为其体积在“zone-a”中。都好。

如果某些Kubernetes节点/工作程序失败，则将替换它们。 pods 将再次在新节点上开始，并重新附加其EBS体积。看起来什么也没发生。

现在，如果整个可用区“zone-a”掉线并且一段时间不可用(这意味着由于对同一区域中EBS的亲和力，cassandra-0无法再启动)。您剩下的是:

cassandra-1-> b区

cassandra-2-> C区

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

现在，如果最重要的是，另一个K8S节点发生故障，或者您已经设置了基础架构的自动缩放功能，则最终可能需要迁移到另一个K8S节点所需的cassandra-1或cassandra-2。
这不应该是一个问题。

但是，根据我的测试的，K8S不会这样做，因为pod cassandra-0处于脱机状态。它永远不会自我修复cassandra-1或cassandra-2(或任何cassandra-X)，因为它希望先恢复cassandra-0。并且cassandra-0无法启动，因为它的音量处于下降且无法恢复的区域中。

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

=>然后，您将松开所有的Cassandra pod 。直到zone-a重新联机

这似乎是一种危险的情况。有状态集是否有办法不关心顺序而仍然自我修复或在cassandra-3、4、5，X上启动更多pod？

Answer 1

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