4

我对多主 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 接管吗？

4

1 回答 1

4

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

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

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

于 2017-11-07T02:19:29.337 回答