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

Question

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

• 场景：

  • 2 个机架，R1，R2。

  • API 大师：

    • R1 上的 M1，R2 上的 M2。

  • 工作节点：

    • R1 上的 W1，R2 上的 W2。

  • 等：

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

我的失败问题基本上是关于脑裂的场景：

如果 M1 是活动的主设备，并且 R1 失去与 Etcd 和 R2 的连接，但 R2/M2 与 Etcd 有连接，会发生什么情况？即是什么具体导致了领导选举？

如果 R1/W1 上有 Pod P1，M1 是 active master，R1 与 R2 和 Etcd 断开连接，会发生什么？ P1 是继续运行，还是被杀死？ M2 是否在 R2 上启动 P (P2) 的单独实例？如果可以，P1 和 P2 可以同时运行吗？

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

Answer 1

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

就竞争的 Master 而言，一般来说 Kubernetes 仍然使用 etcd 来执行一致的更新 - 即即使是同时活跃的两个 Master 仍然在竞争对 etcd 做同样的事情，这具有很强的一致性，所以通常的结果只是更新失败。不是这种情况的一个例子是 daemonsets 和 ReplicaSets——两个活动的 Master 可能会创建多个 Pod，然后当他们意识到每个节点有太多 Pod 或与所需规模进行比较时缩小它们。但是由于 daemonsets 或 ReplicaSets 无论如何都不能保证这种行为（ReplicaSets 可以在任何时候运行> scale pods，daemonsets 每个节点可以有两个pods），它本身并没有被破坏。

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