Kubernetes集群高可用的策略和实践
Kubernetes高可用也许是完成了初步的技术评估，打算将生产环境迁移进Kubernetes集群以前广泛面临的问题。html
为了减小由于服务器当机引发的业务中断，生产环境中的业务系统每每已经作好了高可用，而当引入Kubernetes这一套新的集群管理系统以后， 服务器再也不是单一的个体，位于中央位置的Kubernetes Master一旦中断服务，将致使全部Node节点均不可控，有可能形成严重的事故。git
整体来说这是一个被屡次讨论，但暂时没有造成统一解决方案的话题。今天主要介绍一些Kubernetes Master高可用的策略，供你们参考。github
基本目标
高可用是复杂的系统工程。出于篇幅的考虑以及能力的限制，今天咱们先关注一个小目标：后端
- 全部的Kubernetes Master服务器没有单点故障，任何一台服务器当机均不影响Kubernetes的正常工做。
实现这一目标带来的直接收益是咱们能够在不影响业务正常运行的前提下实现全部服务器的滚动升级，有助于完成系统组件升级以及安全补丁的下发。centos
为了实现没有单点故障的目标，须要为如下几个组件创建高可用方案：api
集群高可用技术路线示意图。安全
下面为你们逐个详细介绍各个组件的高可用策略。服务器
一、etcd高可用
etcd是Kubernetes当中惟一带状态的服务，也是高可用的难点。Kubernetes选用etcd做为它的后端数据存储仓库正是看重了其使用分布式架构，没有单点故障的特性。网络
虽然单节点的etcd也能够正常运行。可是推荐的部署方案均是采用3个或者5个节点组成etcd集群，供Kubernetes使用。架构
你们常使用的kubeadm工具默认是在一个单节点上启动etcd以及全部的Master组件。虽然使用起来很是方便，可是要用到生产环境仍是要注意这个节点当机的风险。
etcd的高可用基本有三种思路：
- 一是使用独立的etcd集群，使用3台或者5台服务器只运行etcd，独立维护和升级。甚至可使用CoreOS的
update-engine和locksmith，让服务器彻底自主的完成升级。这个etcd集群将做为基石用于构建整个集群。 采用这项策略的主要动机是etcd集群的节点增减都须要显式的通知集群，保证etcd集群节点稳定能够更方便的用程序完成集群滚动升级，减轻维护负担。 - 二是在Kubernetes Master上用static pod的形式来运行etcd，并将多台Kubernetes Master上的etcd组成集群。 在这一模式下，各个服务器的etcd实例被注册进了Kubernetes当中，虽然没法直接使用
kubectl来管理这部分实例，可是监控以及日志搜集组件都可正常工做。在这一模式运行下的etcd可管理性更强。 - 三是使用CoreOS提出的self-hosted etcd方案，将本应在底层为Kubernetes提供服务的etcd运行在Kubernetes之上。 实现Kubernetes对自身依赖组件的管理。在这一模式下的etcd集群能够直接使用etcd-operator来自动化运维，最符合Kubernetes的使用习惯。
这三种思路都可以实现etcd高可用的目标，可是在选择过程当中却要根据实际状况作出一些判断。简单来说预算充足但保守的项目选方案一， 想一步到位并愿意承担必定风险的项目选方案三。折中一点选方案二。各个方案的优劣以及作选择过程当中的取舍在这里就不详细展开了，对这块有疑问的朋友能够私下联系交流。
二、kube-apiserver高可用
apiserver自己是一个无状态服务，要实现其高可用相对要容易一些，难点在于如何将运行在多台服务器上的apiserver用一个统一的外部入口暴露给全部Node节点。
说是难点，其实对于这种无状态服务的高可用，咱们在设计业务系统的高可用方案时已经有了至关多的经验积累。须要注意的是apiserver所使用的SSL证书要包含外部入口的地址，否则Node节点没法正常访问apiserver。
apiserver的高可用也有三种基本思路：
- 一是使用外部负载均衡器，不论是使用公有云提供的负载均衡器服务或是在私有云中使用
LVS或者HaProxy自建负载均衡器均可以归到这一类。 负载均衡器是很是成熟的方案，在这里略过不作过多介绍。如何保证负载均衡器的高可用，则是选择这一方案须要考虑的新问题。 - 二是在网络层作负载均衡。好比在Master节点上用
BGP作ECMP，或者在Node节点上用iptables作NAT均可以实现。采用这一方案不须要额外的外部服务，可是对网络配置有必定的要求。 - 三是在Node节点上使用反向代理对多个Master作负载均衡。这一方案一样不须要依赖外部的组件，可是当Master节点有增减时，如何动态配置Node节点上的负载均衡器成为了另一个须要解决的问题。
从目前各个集群管理工具的选择来看，这三种模式都有被使用，目前尚未明确的推荐方案产生。建议在公有云上的集群多考虑第一种模式，在私有云环境中因为维护额外的负载均衡器也是一项负担，建议考虑第二种或是第三种方案。
三、kube-controller-manager与kube-scheduler高可用
这两项服务是Master节点的一部分，他们的高可用相对容易，仅须要运行多份实例便可。这些实例会经过向apiserver中的Endpoint加锁的方式来进行leader election， 当目前拿到leader的实例没法正常工做时，别的实例会拿到锁，变为新的leader。
目前在多个Master节点上采用static pod模式部署这两项服务的方案比较常见，激进一点也能够采用self-hosted的模式，在Kubernetes之上用DaemonSet或者Deployment来部署。
四、Kube-dns高可用
严格来讲kube-dns并不算是Master组件的一部分，由于它是能够跑在Node节点上，并用Service向集群内部提供服务的。但在实际环境中， 因为默认配置只运行了一份kube-dns实例，在其升级或是所在节点当机时，会出现集群内部dns服务不可用的状况，严重时会影响到线上服务的正常运行。
为了不故障，请将kube-dns的replicas值设为2或者更多，并用anti-affinity将他们部署在不一样的Node节点上。这项操做比较容易被疏忽，直到出现故障时才发现原来是kube-dns只运行了一份实例致使的故障。
五、方案总结
上面介绍了Kubernetes Master各个组件高可用能够采用的策略。其中etcd和kube-apiserver的高可用是整个方案的重点。因为存在多种高可用方案，集群管理员应当根据集群所处环境以及其余限制条件选择适合的方案。
这种没有绝对的通用方案，须要集群建设者根据不一样的现状在多个方案中作选择的状况在Kubernetes集群建设过程当中频频出现， 也是整个建设过程当中最有挑战的一部分。容器网络方案的选型做为Kubernetes建设过程当中须要面对的另一个大问题也属于这种状况，从此有机会再来分享这个话题。
在实际建设过程当中，在完成了上述四个组件的高可用以后，最好采起实际关机检验的方式来验证高可用方案的可靠性，并根据检验的结果不断调整和优化整个方案。
此外将高可用方案与系统自动化升级方案结合在一块儿考虑，实现高可用下的系统自动升级，将大大减轻集群的平常运维负担，值得投入精力去研究。
虽然本篇主要在讲Kubernetes Master高可用的方案，但须要指出的是，高可用也并非必须的，为了实现高可用所付出的代价并不低， 须要有相应的收益来平衡。对于大量的小规模集群来讲，业务系统并无实现高可用，贸然去作集群的高可用收益有限。这时采用单Master节点的方案，作好etcd的数据备份，不失为理性的选择。
六、参考资源
Kubernetes高可用的部署方法与实战步骤：
-
集群系统的高可用
-
应用服务的高可用