Kubernetes状态集，AZ和卷索赔:当AZ失败时会发生什么

Question

考虑跨越三个可用性区域的状态集(Cassandra使用正式的K8S示例)：

• 卡桑德拉-0 ->区a
• 卡桑德拉-1 ->区b区
• 卡桑德拉-2 ->区c区

每个卡桑德拉荚使用一个EBS音量。所以自动有亲缘关系。例如，cassandra-0不能移动到"zone-b“，因为它的卷位于"zone-a”中。一切都很好。

如果一些Kubernetes节点/工作人员失败，它们将被替换。豆荚将在新节点上重新启动，并重新附加其EBS卷。好像什么都没发生。

现在，如果整个AZ“区域-a”下降并在一段时间内不可用(意味着cassandra-0由于在同一区域的EBS的亲和力而不能再启动)。留给你的是：

• 卡桑德拉-1 ->区b区
• 卡桑德拉-2 ->区c区

库伯内特斯将永远无法开始卡桑德拉-0，只要“区域-a”是不可用的。这都很好，因为卡桑德拉-1和卡桑德拉-2可以满足请求。

现在，如果在此基础上，另一个K8S节点出现故障，或者您已经设置了基础设施的自动缩放，那么您可能最终需要使用cassandra-1或cassandra-2移动到另一个K8S节点。不应该是个问题。

，但是从我的测试，K8S不会这样做，因为pod卡桑德拉-0离线。它永远不会自我治愈卡桑德拉-1或卡桑德拉-2(或任何卡桑德拉-X)，因为它希望卡桑德拉-0首先回来。而卡桑德拉-0不能启动，因为它的音量在一个区域，正在下降，没有恢复。

因此，如果您使用状态集+ VolumeClaim +跨区域，并且您经历了整个AZ故障，您在另一个AZ中经历了EC2故障，或者您的基础设施自动缩放。

=>，然后你会解开你所有的卡桑德拉吊舱。直到区域-a恢复联机为止

这似乎是个危险的局面。有没有一种方式让有状态的设置不关心秩序，仍然自我治愈或启动更多的吊舱卡桑德拉-3，4，5，X？

Answer 1

从Kubernetes1.7开始，您可以告诉Kubernetes使用podManagementPolicy选项(文档)放松podManagementPolicy排序保证。通过将该选项设置为Parallel，Kubernetes将不再保证在启动或停止荚和启动荚并行时的任何排序。这可能会对您的服务发现产生影响，但应该可以解决您正在讨论的问题。

Answer 2

有两种选择：

选项1：使用podManagementPolicy并将其设置为并行。豆荚-1和荚-2会崩溃几次，直到种子节点(荚-0)可用为止.这发生在第一次创建状态集时。还请注意，Cassandra文档曾经建议不要并行创建多个节点，但是最近的更新似乎使这一点变得不正确。多个节点可以同时添加到集群中。

问题发现:如果使用两个种子节点，您将得到一个分裂的大脑场景。每个种子节点将同时创建，并创建两个独立的逻辑Cassandra集群。

选项1 b：使用podManagementPolicy并将其设置为并行并使用ContainerInit。与选项1相同，但使用initContainer https://kubernetes.io/docs/concepts/workloads/pods/init-containers/。init容器是一个短暂的容器，它的作用是在启动实际容器之前检查种子节点是否可用。这是不需要的，如果我们很高兴荚崩溃，直到种子节点再次可用，问题是，Init容器将始终运行，这是不需要的。我们希望确保卡桑德拉集群在第一次创建时就形成良好。在那之后就不重要了

选项2：创建3种不同的状态。

每个AZ/Rack设置1个状态。每个状态集都有约束，因此只能在特定AZ中的节点上运行。我还拥有3个存储类(同样是对特定区域的约束)，以确保状态集不会在错误的区域中提供EBS (状态集还没有动态地处理这个问题)，在每个状态集中，我都有一个Cassandra种子节点(定义为环境变量CASSANDRA_SEEDS，它在运行时填充SEED_PROVIDER )。这就产生了3个种子，这是足够的。由于复制因子=3，我的设置可以在完全区域中断时存活下来。

提示：

• 种子节点列表包含用逗号分隔的所有3个节点："cassandra-a-0.cassandra.MYNAMESPACE.svc.cluster.local，cassandra-b-0.cassandra.MYNAMESPACE.svc.cluster.local，cassandra-c-0.cassandra.MYNAMESPACE.svc.cluster.local“
• 在创建其他两个状态集之前，等待第一个种子(Cassandraa-0)准备就绪。否则你的大脑就会裂开。这只是创建群集时的一个问题。在此之后，您可以不受影响地松开一两个种子节点，因为第三个节点知道所有其他节点。

Answer 3

我认为，如果您可以控制每个吊舱的部署(cassandra-0、cassandra-1、cassandra-2有三个不同的yaml部署文件)，则可以将podAffinity设置为每个吊舱的特定区域。

一旦区域上的节点失败，并且必须重新安排运行在该服务器中的吊舱，这种亲缘关系将迫使Kubernetes在同一区域的不同节点上部署pod，如果同一区域上没有可用的节点，Kubernetes应该无限期地保持该吊舱不变。

例如，您可以创建一个具有三个不同managedNodeGroup的Kubernetes集群，每个区域一个(标签为" zone "："a“、"b”、"c“，每个组至少有两个节点)，并使用podAffinity。

注意:不要将x1.32x大型机器用于节点:-)