在机架之间的裂脑场景中，Kubernetes HA群集故障行为是什么？

我对多主Kubernetes在发生不同类型的故障时的行为感兴趣，特别是当主设备位于不同机架上时

• 情景：
  • 2个机架，R1和R2

  • API母版：
    • R1上的M1，R2上的M2
  • 工作节点：
    • R1上为W1，R2上为W2
  • Etcd：
    • 由3个节点组成的完全独立的HA Etcd群集（即，它不在API主节点上运行）

我的失败问题基本上都是关于大脑分裂的情况：

如果M1是活动主机，R1与Etcd和R2失去连接，但R2/M2与Etcd有连接，会发生什么情况？i、 e.领导层选举的具体原因是什么

如果R1/W1上有一个Pod P1，M1是活动主机，R1与R2和Etcd断开，会发生什么情况？P1是继续前进，还是被杀死？M2是否在R2上启动一个单独的P（P2）实例？如果是，P1和P2是否可以同时运行

---

如果R2/W2上有一个Pod P2，M1是活动主机（即Pod位于主机的单独机架上），并且R1与R2和Etcd失去连接，P2会发生什么情况？它继续运行，M2接管吗？

船长持有etcd的租约。如果租约到期，活动主机将退出其进程（期望重新启动）。另一位船长将观察租约到期，并试图在etcd中获得租约。只要M2可以到达etcd并且etcd有法定人数，第二个主控器就会接管

就竞争对手而言，一般来说，Kubernetes仍然使用etcd执行一致性更新，即即使同时处于活动状态的两位大师仍在竞争对etcd执行相同的操作，etcd具有很强的一致性，因此通常的结果就是更新失败。守护进程集和复制集就是一个不属于这种情况的例子——两个活动主机可能会创建多个POD，然后当它们意识到每个节点的POD太多或与所需的规模相比时，就会将它们缩小。但由于守护程序集或复制集都不能保证这种行为（复制集可以在任何时候运行>scale pod，守护程序集可以在每个节点上短暂地运行两个pod），因此它本身并没有中断

如果您最多需要X个pods行为，那么现在只有statefulset提供这种保证