机架间裂脑场景下 Kubernetes HA 集群故障行为是什么？

Question

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

• 设想：

  • 2 个机架，R1、R2。

  • API 大师：

    • R1 上的 M1，R2 上的 M2。

  • 工作节点：

    • W1 在 R1 上，W2 在 R2 上。

  • 等：

    • 一个完全独立的 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和P2可以同时运行吗？

如果 R2/W2 上有一个 Pod P2，并且 M1 是活动主服务器（即 pod 位于与主服务器不同的机架上），并且 R1 失去了与 R2 和 Etcd 的连接，那么 P2 会发生什么情况？它会继续发展并由 M2 接管吗？

Answer 1

master 持有 etcd 的租约。如果租约到期，活动主服务器将退出它的\xe2\x80\x99s进程（预计会重新启动）。另一个主机会观察到租约到期并尝试在 etcd 中获取它。只要 M2 可以到达 etcd 并且 etcd 有法定人数，第二个 master 就会接管。

\n\n

就竞争的 Master 而言，一般来说 Kubernetes 仍然使用 etcd 来执行一致的更新 - 即即使两个 Master 同时活跃，仍然会竞争对 etcd 做同样的事情，而 etcd 具有很强的一致性，所以通常的结果就是失败更新。一个情况并非如此的例子是 daemonsets 和 ReplicaSets - 两个活动的 Master 可能会创建多个 Pod，然后当它们意识到每个节点的数量太多或与所需的规模相比时缩小它们。但由于 daemonsets 或 ReplicaSets 都不能保证该行为（ReplicaSets 可以随时运行 > 规模的 pod，daemonsets 可以在每个节点短暂拥有两个 pod），所以它\xe2\x80\x99s 本身并没有被破坏。

\n\n

如果您需要最多 X 个 pod 行为，那么目前只有 StatefulSet 可以提供这种保证。

\n