时间戳

首页 > 解决方案 > High Availability Master 是如何选择的？

kubernetes - High Availability Master 是如何选择的？

问题描述

所以我刚刚启动了 kubernetes，想知道如果我创建了多个 master，那么 pod 的调度是如何完成的，如果 master 宕机了，连接到它的工作节点会发生什么？

标签： kuberneteskubeadm

解决方案

High Availability Master 是如何选择的？

下面的etcd数据库是大部分高可用性的来源。它使用raft 协议的实现来达成共识。etcd 需要一定数量的实例可供 Kubernetes 使用，以便能够将更新写入集群。如果您的可用空间少于 1/2，etcd 将进入“只读”模式，这意味着无法安排任何新内容。N/2 + 1

kube-apiserver将以主动/主动模式在多个节点上运行。所有实例都使用相同的 etcd 集群，因此呈现相同的数据。工作节点将需要某种方式来对可用的 apiservers 进行负载平衡/故障转移。故障转移需要 Kubernetes 之外的组件，如 HAProxy 或负载均衡器设备（如 AWS 提供的）。

kube-scheduler将在多个主节点上运行，并且应该访问 kube-apiserver 的本地实例。调度器将选举一个领导者来锁定它管理的数据。当前的leader信息可以在endpoint中找到：

kubectl -n kube-system get endpoints kube-scheduler \
  -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'

kube-controller-manager将在多个主节点上运行，并且应该访问 kube-apiserver 的本地实例。控制器将选举一个领导者来锁定它管理的数据。可以在端点中找到领导者信息：

kubectl -n kube-system get endpoints kube-controller-manager \
 -o jsonpath='{.metadata.annotations.control-plane\.alpha\.kubernetes\.io/leader}'

如果主服务器宕机，连接到它的工作节点会发生什么？

他们继续以当前状态运行。不会安排新的 Pod，也不会推出对集群现有状态的任何更改。您的 pod 将继续运行，直到它们以本地 kubelet 无法恢复的方式失败。

推荐阅读