在机架之间的裂脑情况下，Kubernetes HA群集故障行为是什么？

Question

我对多主Kubernetes在不同类型的故障情况下的行为感兴趣，特别是如果主人在不同的机架上。

• 情景：

  • 2个机架，R1，R2。

  • API大师：

    • R1上的M1，R2上的M2。

  • 工作人员节点：

    • R1上的W1，R2上的W2。

  • ETCD：

    • 一个完全独立的HA Etcd群集，包含3个节点（即它未在API主节点上运行）。

我的失败问题主要围绕裂脑情景：

如果M1是活动主设备且R1与Etcd和R2失去连接，但R2 / M2与Etcd连接，会发生什么？什么特别导致领导选举？

如果R1 / W1上有Pod P1，M1是活动主站，R1与R2和Etcd断开连接，会发生什么？ P1继续前进，还是被杀？ M2会在R2上启动单独的P（P2）实例吗？如果是这样，P1＆amp; P2都在同一时间运行？

如果R2 / W2上有Pod P2且M1是主动主机（即pod位于与主机分开的机架上）并且R1失去与R2和Etcd的连接，那么P2会发生什么？它继续进行，M2接管吗？

Answer 1

船长持有etd的租约。如果租约到期，则活动主服务器退出其进程（期望重新启动）。另一个主人会观察租约到期并尝试在etcd中获取它。只要M2能够达到etcd并且etcd有一个法定人数，第二个主人就会接管。

就竞争对手的大师而言，总的来说Kubernetes仍然使用etcd来执行一致的更新 - 即使两个同时活跃的大师仍然在竞争对etcd做同样的事情，因为它具有很强的一致性，因此通常的结果只是失败的更新。不是这种情况的一个例子是daemonsets和ReplicaSets - 两个活动的Masters可以创建多个pod，然后当他们意识到每个节点太多或者与所需的比例相比时缩小它们。但是既然daemonsets或ReplicaSets都不能保证这种行为（ReplicaSets可以随时运行＆gt;缩放pod，daemonmon可以简单地为每个节点提供两个pod），它本身并没有被破坏。

如果您需要最多的X pod行为，那么今天只有StatefulSets提供该保证。