k8s的高可用

一、高可用原理

  配置一台新的master节点，然后在每台node节点上安装nginx，nginx通过内部的负载均衡将node节点上需要通过访问master，kube-apiserver组件的请求，反代到两台k8s-master节点上，这样就可以实现master节点的高可用，当任意一台master节点宕机后，也可以通过nginx负载均衡放文档另一个master节点上。kube-scheduler以及kube-controller-manager高可用则是在两台master配置文件设置leader-elect参数。

 

  Kubernetes的管理层服务包括kube-scheduler和kube-controller-manager。kube-scheduer和kube-controller-manager使用一主多从的高可用方案，在同一时刻只允许一个服务处以具体的任务。Kubernetes中实现了一套简单的选主逻辑，依赖Etcd实现scheduler和controller-manager的选主功能。如果scheduler和controller-manager在启动的时候设置了leader-elect参数，它们在启动后会先尝试获取leader节点身份，只有在获取leader节点身份后才可以执行具体的业务逻辑。它们分别会在Etcd中创建kube-scheduler和kube-controller-manager的endpoint，endpoint的信息中记录了当前的leader节点信息，以及记录的上次更新时间。leader节点会定期更新endpoint的信息，维护自己的leader身份。每个从节点的服务都会定期检查endpoint的信息，如果endpoint的信息在时间范围内没有更新，它们会尝试更新自己为leader节点。scheduler服务以及controller-manager服务之间不会进行通信，利用Etcd的强一致性，能够保证在分布式高并发情况下leader节点的全局唯一性。

 

 

管理平面

1. apiserver: apiserver是k8s集群的入口，为了使用方便，kubectl作为其客户端供用户使用。为了实现高可用，在3个机器上分别以静态Pod的方式部署了apiserver并挂载在同一个loadbalancer上，如此，其与其他组件的联系都经由这个负载均衡器来做转发（图中黑色连线），这样也保证了每一个用户命令都有且仅有一个apiserver来响应，并且理论上只要还有一个Pod是可用的，该组件的服务就没有问题，再加上k8s的Pod有自愈能力，apiserver高可用可以说是能够保证的。

2. controller managers: k8s自愈能力的关键所在，controller managers提供一种reconciliation的功能，简单来说就是该组件会无限循环地去通过apiserver来查看api资源的状态，并将其实际状态转变为api资源声明中的状态。比如，一个deployment设置了replicas为3，而由于某些原因集群中运行了5个这样的Pod时，controller managers就会触发工作并且调用api来删除2个Pod。同样，在k8s的master节点上，每个节点以静态Pod部署一个组件以达到高可用的目的。

3. scheduler: 该组件负责集群内部Pod的调度，主要根据集群node资源情况来平衡每个node的任务量，此外，还支持用户对Pod调度的自定义限制规则，比如NodeSelector、affinity规则等。该组件的高可用部署方案也是在每一个master节点上部署一个静态Pod。

组件controller managers和scheduler的选主是通过etcd来实现的：当一个副本不能工作时，其余副本会更新endpoint至etcd，而etcd只会接受其中一个更新请求，从而实现leader election。

执行平面

执行平面针对的就是node/slave节点，这里实际上就没有高可用一说了，即便如此，还是简单介绍一下图中出现的几个组件吧。

1. container runtime: 每个节点都需要一个容器运行时来执行容器，比如Docker。非pod启动。
2. kubelet: 用于执行apiserver下达的命令，也可以重启启动失败的pod。
3. kube-proxy: 通过修改iptables来达到网络代理、负载均衡的效果，在k8s中以Service作为代表。比如在使用NodePort进行对外提供服务时，所有node/slave节点都会生成特定的iptables，当该服务被删除或者节点断网时，iptables也会被清除。

数据平面

etcd

• 对于高可用集群来说，集群的数据至关重要，Kubernetes将etcd作为数据存储中心，其存储了所有集群相关的信息，比如：pod、node、cm… 鉴于底层系统的高可靠性，数据决不能丢。
• 如图所示，etcd在每个master节点上部署了一个实例，以保证其高可用性，实践证明，etcd挂载本地ssd的方式会大幅提高超大规模（节点大于2000）集群性能（参考资料6）。
• etcd官方给的部署模式是奇数个（大于等于3）就好了，推荐部署5个节点，这就不得不提etcd的选主协议/逻辑/算法Raft，这里有个非常生动的动画值得一看。此外，还需要注意的是所谓“脑裂”问题，这里的“脑裂”是指etcd集群出现两个甚至多个leader，如果你也是这样理解脑裂的，那就大可放心使用，因为there is no “split-brain” in etcd。
• 默认的etcd参数不太适合disk io比较低的场景