共计 2218 个字符，预计需要花费 6 分钟才能阅读完成。
这篇文章给大家介绍 Kubernetes 中如何进行多 master 节点容错部署，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
Kubernetes 的 master 服务主要包括 etcd(数据存储)、control-manager(控制器)、scheduler(调度器)、apiserver(服务接口)，我们将其部署到多节点实现容错。
1、多 master 节点部署
control-manager(控制器) 和 scheduler(调度器) 通过 apiserver(服务接口) 来进行集群容器实例的管理，通过向 apiserver 中的 Endpoint 加锁的方式来进行 leader election，当目前拿到 leader 的实例无法正常工作时，别的实例会拿到锁，变为新的 leader。缺省情况下 election=true，默认安装即支持多实例的自动选主。
说明：各个节点的 kubelet 会自动启动 /etc/kubernetes/manifest/*.yaml 里定义的 pod，作为 static pod 运行。
首先，使用 kubeadm 部署第一个主节点。
第二步，安装副节点。
使用 kubeadm 部署多个副节点。
或者先用 kubeadm join 部署为工作节点。
然后将 /etc/kubernetes/manifest 下的文件复制到各个副节点对应目录，以及上级对应的 *.conf 文件。文件包括：
etcd.yaml（之前已经修改，不能覆盖）
kube-apiserver.yaml
kube-controller-manager.yaml
kube-scheduler.yaml
重启 kubelet 服务，运行命令：systemctl restart kubelet。
此时，在 Kubernetes 的 Dashboard 中可以看到上面的 pod，但是不能进行删除等操作。
2、apiserver 的负载均衡
通过上面的方法设置多个 master 服务后，kube-apiserver 的 URL 主地址全部指向的是第一个 master 节点 IP 地址，仍然存在单点失效的风险。为了实现多点容错，有几种方案（原理都是一样的，只是实现方式不同）：
第一种，外部负载均衡器。
使用外部的负载均衡器分配的高可用 IP 作为 apiserver 的服务地址，所有的外部访问以及 scheduler.conf、controller-manager.conf 中的 server 参数均指向该地址，然后将该地址映射到具体的内部服务器 IP 上，由外部负载均衡器来分配访问负载。
在上面的各 master 节点上使用高可用 IP 作为服务地址，如 –apiserver-advertise-address=10.1.1.201。
参考：多网卡 Ubuntu 服务器安装 Kubernetes
把副节点的 IP 地址加入负载均衡器。
将所有节点的 scheduler.conf、controller-manager.conf 中的 server 参数指向该高可用 IP。
这种方式部署较为简单，但依赖云服务商提供的负载均衡器。
如果自己安装负载均衡器设备或软件，需要确保其本身是高可用的。
第二种，虚拟 IP+ 负载均衡。
使用 keepalived 实现虚拟 IP，主节点不可用时将 IP 自动漂移到其它节点，工作节点基本不受影响。k8s 集群按照虚拟 IP 进行配置，与第一种方案类似，但通过简单的软件即可实现 k8s 集群主节点的容错。
虚拟 IP（实际上是直接修改真实 IP）每一时刻只运行于单个节点上。因此，其它的副节点上的 apiserver 服务处于 standby 模式。
通过添加 HAProxy 等做 apiserver 的负载均衡，之上再用 keepalived 做多节点的虚拟 IP，可以将多节点变为支持负载均衡的互备模式。
在每一个副节点运行 keepalived，配置为同一组和 IP 地址加入负载均衡器。
将所有节点的 scheduler.conf、controller-manager.conf 中的 server 参数指向该高可用 IP。
注意，kubeadm 安装的 kubernetes 证书只能支持本机单节点授权。这种模式可能需要更换新的授权证书。
第三种，多主分治 + 反向代理。
每个节点单独运行，通过 etcd 共享数据。
各个节点的 scheduler.conf、controller-manager.conf 的 server 参数指向本地 apiserver。
部署 nginx 做反向代理，外部访问通过反向代理服务分发到各个 apiserver。
各个节点完全自治，授权证书也不相同，需要反向代理进行处理。
反向代理应该是高可用的，与第一种方式类似。
3、Kube-dns 高可用
kube-dns 并不算是 Master 组件的一部分，可以跑在 Node 节点上，并用 Service 向集群内部提供服务。但在实际环境中，由于默认配置只运行了一份 kube-dns 实例，在其升级或是所在节点当机时，会出现集群内部 dns 服务不可用的情况，严重时会影响到线上服务的正常运行。
为了避免故障，请将 kube-dns 的 replicas 值设为 2 或者更多，并用 anti-affinity 将他们部署在不同的 Node 节点上。这项操作比较容易被疏忽，直到出现故障时才发现原来是 kube-dns 只运行了一份实例导致的故障。
关于 Kubernetes 中如何进行多 master 节点容错部署就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
