1. 背景
Kubernetes作为容器应用的管理中心，对集群内部所有容器的生命周期进行管理，结合自身的健康检查及错误恢复机制，实现了集群内部应用层的高可用性。
Kubernetes服务本身的稳定运行对集群管理至关重要，影响服务稳定的因素一般来说分为两种,一种是服务本身异常或者服务所在机器宕机，另一种是因为网络问题导致的服务不可用。本文将从存储层、管理层、接入层三个方面介绍高可用Kubernetes集群的原理。
Kubernetes的存储层使用的是Etcd。Etcd是CoreOS开源的一个高可用强一致性的分布式存储服务，Kubernetes使用Etcd作为数据存储后端，把需要记录的pod、rc、service等资源信息存储在Etcd中。
Etcd使用raft算法将一组主机组成集群，raft 集群中的每个节点都可以根据集群运行的情况在三种状态间切换：follower, candidate 与 leader。leader 和 follower 之间保持心跳。如果follower在一段时间内没有收到来自leader的心跳，就会转为candidate，发出新的选主请求。
集群初始化的时候内部的节点都是follower节点，之后会有一个节点因为没有收到leader的心跳转为candidate节点，发起选主请求。当这个节点获得了大于一半节点的投票后会转为leader节点，如下图所示：
当leader节点服务异常后，其中的某个follower节点因为没有收到leader的心跳转为candidate节点，发起选主请求。只要集群中剩余的正常节点数目大于集群内主机数目的一半，Etcd集群就可以正常对外提供服务。具体的恢复过程如下图所示：
当集群内部的网络出现故障集群可能会出现“脑裂”问题，这个时候集群会分为一大一小两个集群（奇数节点的集群），较小的集群会处于异常状态，较大的集群可以正常对外提供服务，出现网络故障时的恢复过程如下图所示：
Etcd集群的部署有三种方式，具体的安装步骤可以查看官方手册，此处不再详细介绍。
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节点的全局唯一性。
整体方案如下图所示：
当集群中的leader节点服务异常后，其它节点的服务会尝试更新自身为leader节点，当有多个节点同时更新endpoint时，由Etcd保证只有一个服务的更新请求能够成功。通过这种机制sheduler和controller-manager可以保证在leader节点宕机后其它的节点可以顺利选主，保证服务故障后快速恢复。
当集群中的网络出现故障时对服务的选主影响不是很大，因为scheduler和controller-manager是依赖Etcd进行选主的，在网络故障后，可以和Etcd通信的主机依然可以按照之前的逻辑进行选主，就算集群被切分，Etcd也可以保证同一时刻只有一个节点的服务处于leader状态。
4. Kubernetes apiserver服务高可用方案
Kubernetes的接入层服务主要是kube-apiserver。apiserver本身是无状态的服务，它的主要任务职责是把资源数据存储到Etcd中，后续具体的业务逻辑是由scheduler和controller-manager执行的。
可以同时起多个apiserver服务，使用nginx把客户端的流量转发到不同的后端apiserver上实现接入层的高可用。具体的实现如下图所示：
接入层的高可用分为两个部分，一个部分是多活的apiserver服务，另一个部分是一主一备的nginx服务。
本文主要从存储层，管理层和接入层三个部分介绍了Kubernetes高可用方案的原理，整体的方案架构如下图所示：
当然要真正做到Kubernetes集群的高可用，还需要考虑Kubernetes依赖的docker registry服务的高可用，以及Kubernetes依赖的网络插件（cni）的高可用等等，相关的内容会在以后的文章中进行介绍。
