Kubernetes探秘-多master节点容错部署

时间 2019-11-09

标签 kubernetes 探秘 master 节点容错部署繁體版

原文原文链接

Kubernetes的master服务主要包括etcd(数据存储)、control-manager(控制器)、scheduler(调度器)、apiserver(服务接口)，咱们将其部署到多节点实现容错。在《Kubernetes探秘-etcd节点和实例扩容》中，已经将etcd服务扩展到多个节点。这里咱们将control-manager(控制器)、scheduler(调度器)、apiserver(服务接口)扩展到多个节点运行。nginx

一、多master节点部署

control-manager(控制器)和scheduler(调度器)经过apiserver(服务接口)来进行集群容器实例的管理，经过向apiserver中的Endpoint加锁的方式来进行leader election，当目前拿到leader的实例没法正常工做时，别的实例会拿到锁，变为新的leader。缺省状况下election=true，默认安装即支持多实例的自动选主。git

说明：各个节点的kubelet会自动启动/etc/kubernetes/manifest/*.yaml里定义的pod，做为static pod运行。

首先，使用kubeadm部署第一个主节点。github

第二步，安装副节点。api

使用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，可是不能进行删除等操做。

二、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。

这种方式部署较为简单，但依赖云服务商提供的负载均衡器。spa

若是本身安装负载均衡器设备或软件，须要确保其自己是高可用的。.net

第二种，虚拟IP+负载均衡。

使用keepalived实现虚拟IP，主节点不可用时将IP自动漂移到其它节点，工做节点基本不受影响。k8s集群按照虚拟IP进行配置，与第一种方案相似，但经过简单的软件便可实现k8s集群主节点的容错。代理

虚拟IP（其实是直接修改真实IP）每一时刻只运行于单个节点上。所以，其它的副节点上的apiserver服务处于standby模式。rest

经过添加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。
各个节点彻底自治，受权证书也不相同，须要反向代理进行处理。
反向代理应该是高可用的，与第一种方式相似。

三、Kube-dns高可用

kube-dns并不算是Master组件的一部分，能够跑在Node节点上，并用Service向集群内部提供服务。但在实际环境中，因为默认配置只运行了一份kube-dns实例，在其升级或是所在节点当机时，会出现集群内部dns服务不可用的状况，严重时会影响到线上服务的正常运行。

为了不故障，请将kube-dns的replicas值设为2或者更多，并用anti-affinity将他们部署在不一样的Node节点上。这项操做比较容易被疏忽，直到出现故障时才发现原来是kube-dns只运行了一份实例致使的故障。