文/盛乐标 游伟倩 张予倩 周庆林

Kubernetes 自2015年正式推出之后，受到了众多软件开发和运维人员的关注。Kubernetes构建于Google公司多年生成环境经验基础之上，是用于自动部署、扩展和管理容器化应用程序的开源系统。随着微服务架构和容器技术的流行，在生产环境中部署Kubernetes集群的需求也逐渐显现。然而，传统的Kubernetes集群部署，只部署单台Kubernetes API服务器，这种部署方式存在天生的缺陷，容易出现因Kubernetes API服务器单点故障导致整个Kubernetes集群不能正常服务。借鉴高性能计算集群的高可用和负载均衡设计，本文将主要介绍Kubernetes集群部署的高可用和负载均衡策略。

1 建设Kubernetes高可用与负载均衡集群的背景

云计算、容器技术和微服务架构的发展，在很大程度上推动了Kubernetes的迅速崛起。容器技术实现了软件交付的标准化，而微服务架构实现了对软件功能的解耦。微服务与容器技术的结合，不亚于一场软件技术革命，微服务架构的优点被进一步放大，软件的敏捷性和适应性得到了有效的提升，此时，健壮灵活的容器编排系统便成为新的软件模式大范围推广与应用的基础。Kubernetes便是在这种背景之下诞生的。由于Kubernetes更侧重业务层的资源调度和众多的知名厂商支持，其一经推出，便获得了广泛关注，成为Github上最活跃的几个开源项目之一，迅速赶超另外两款容器编排系统Swarm和Mesos。

图1：HAProxy四层负载均衡NAT模式原理图

因为Kubernetes集群需要通过Master节点提供Kubernetes API服务，进行资源的调度，因此在生产环境中部署时，必须要避免Master节点的单点设计，建设高可用的Kubernetes Master节点群，并通过负载均衡分流各个Master节点的压力。

2 Kubernetes集群高可用与负载均衡设计

2.1 负载均衡模式简介

在业务比较繁重的生产环境，如果一台服务器承受过多的压力，这台服务器很可能因为资源消耗过多而导致服务器宕机。因此，在生产环境中应当让每台服务器承受的负载在合理的范围内，当一台服务器无法满足业务需求时，就需要使用多台服务器分摊这些负载，并将这些服务器当作一个整体对外提供服务。将一台服务器的负载分摊到多台服务器上的技术，就是负载均衡技术。实现负载均衡既有硬件方案和也有软件方案。硬件方案需要购买特定的负载均衡设备，成本较高，不在本文的探讨范围之内，本文的负载均衡主要涉及的是软件方案。在软件方案中，实现负载均衡的软件主要有LVS，HAProxy，NGINX等，本文的负载均衡使用HAProxy的软件方案。HAProxy可以实现四层和七层的负载均衡，并具有多种负载均衡模式。图1是HAProxy四层负载均衡NAT模式的原理图，本文中Kubernetes集群的负载均衡设计即采用此模式。

假设后端服务器全部位于内网，而负载均衡服务器则拥有公网IP地址VIP，同时为了与内网工作的后端服务器通讯，它还具有一个内网IP（LIP），后端服务器n的IP地址则表示为RIPn。当客户端（IP地址为CIP）向负载均衡服务器发送请求时，请求报文到达负载均衡服务器，报文中的目标IP（即VIP）被修改为其中一台后端服务器的IP（具体将报文转发给哪一台真实服务器则取决于所选择的负载均衡算法，最常见的便是轮询算法），例如工作服务器1的IP地址RIP1，此后报文经由Postrouting链路直接发往后端服务器1，后端服务器1接收到报文，处理后进行响应，将响应报文发回负载均衡服务器，负载均衡器将源地址RIP修改为VIP并返回给客户端。若后端服务器的网关地址不是负载服务器的地址LIP，为保证后端服务器的报文能够正常传递给负载均衡服务器，某些负载均衡策略还会对报文的源IP进行修改。

2.2 Kubernetes高可用负载均衡集群架构

Kubernetes集群的高可用和负载均衡，主要是指Kubernetes API服务器的高可用和负载均衡，而部署在集群上的各种应用的高可用与负载均衡则由Kubernetes负责处理。前面我们介绍了HAProxy基于四层网络的NAT模式，但Kubernetes集群如果像图1那样只部署一台负载均衡服务器，虽然解决了Kubernetes集群负载均衡的问题，但是负载均衡服务器本身却也带来了新的问题：如果负载均衡服务器发生单点故障怎么办？这时我们就需要借助另外的手段来实现负载均衡服务器的高可用。本文中负载均衡服务器的高可用通过Keepalived来实现。整套Kubernetes高可用负载均衡集群的架构示意图见图2。

图2：Kubernetes高可用集群总体框架图

Etcd服务器、API服务器、应用节点是Kubernetes集群的基本组成部分，这部分内容已经有专文描述[，本文中不再展开。为了实现Kubernetes集群的高可用和负载均衡 ，我们在Kubernetes API之前增加了两台HAProxy负载均衡服务器，增加负载均衡服务器是避免其单点故障的手段，但是多台负载均衡服务器便会产生多个访问IP，如何让外部客户端通过一个唯一的IP访问Kubernetes集群，这便是Keepalived需要处理的事。图2中，我们在两台负载均衡服务器上均部署了Keepalived，通过Keepalived的虚拟IP（Virtual IP，VIP）统一对外提供服务。

2.3 HAProxy服务器的部署

在两台负载均衡服务器中安装好HAProxy软件以后，需要在haproxy.cfg文件中进行相关配置，配置文件中相关内容如下：

上面的配置文件表示将任何访问本机6443端口（Kubernetes API服务端口）的TCP流量转发到三台Kubernetes API服务器（master01，master02，master03）,并且执行端口健康检查，rise 3表示成功完成三次端口检查则认为该节点工作正常，fall 3表示三次端口检查失败则认为该节点不可用。balance roundrobin表示采用轮询负载均衡算法。另外，1080端口被用来显示HAProxy的统计信息，在后面Keepalived的部署中，我们也将会使用http://localhost:1080/stats进行健康检查。

图3：Kubernetes高可用负载均衡集群网络拓扑图

2.4 Keepalived的部署

Keepalived是以虚拟路由冗余协议（Virtual Router Redundancy Protocol，VRRP）为 基 础实现高可用的。它将一组服务器组成一个服务器组，在这组服务器里有一个MASTER节点，该MASTER节点获得Keepalived的虚拟IP（Virtual IP，VIP），其它均为BACKUP节点，不能获得VIP。MASTER节点会在同网段内发送VRRP组播，当BACKUP服务器收不到VRRP包时则认为MASTER节点宕机，在BACKUP节点中根据它们的优先级选出一个新的MASTER节点，取得原MASTER节点的VIP继续对外提供服务。

本文中，Keepalived也需要在两台负载均衡服务器上同时部署，安装完 Keepalived软件后，需要进行相关配置。配置文件keepalived.conf示例如下：

Master节点需要在vrrp_instance VI_1的state中配置MASTER，优先级101，另外一台state配置为BACKUP，优先级100（低于MASTER节点的优先级）。访问该VIP的流量都会被Keepalived定向到Keepalived Master节点。因为Keepalived要与HAProxy结合使用，我们使用了检查haproxy健康状态的脚本check_haproxy.sh，脚本的详细内容如下：

2.5 配置Kubernetes集群使用Keepalived虚拟IP

部署完HAProxy和Keepalived后，我们需要将Kubernetes应用节点（Workers)对Kubernetes API服务器的访问定向到Keepalived的虚拟IP上，在Kubernetes Master节点执行如下命令：

另外，我们还需要将Kubernetes应用节点（Workers）kubelet配置文件中的server信息更改为Keepalived虚拟IP。在应用节点执行如下命令：

3 Kubernetes集群高可用与负载均衡特性的验证

经过HAProxy和Keepalived的协同部署，我们已经实现了Kubernetes集群的高可用和负载均衡。集群的网络拓扑（省去Kubernetes API服务器与应用服务器之间的网络部分）详见图3。测试结果表明，当Kubernetes应用服务器需要向Kubernetes API服务发送请求时，报文将首先寻找Keepalived的虚拟IP，而Keepalived的虚拟IP对应于其中一台负载均衡服务器（Keepalived Master节点），请求报文被发送至该节点，该节点的HAProxy根据负载均衡算法将该报文转发至其中一台Kubernetes API服务器，处理后发送响应报文给应用服务器。在整个报文发送的过程中，单点故障被有效避免，同时负载均衡也将用于分流三台Kubernetes API服务器的压力。本文中的两台负载均衡服务器上的HAProxy服务实际上是主从服务模式，一台负载均衡服务器正常工作，另一台则是作为备份服务器。如果负载均衡服务器的压力增大，可以将其设计成主主模式，同时提供负载均衡服务。主主模式可以通过应用两个Keepalived虚拟IP的方式实现，这里不再展开叙述。

这里还需要强调的是，2.3所述的HAProxy配置主要实现的是Kubernetes API服务器的负载均衡，如果应用节点上有对外服务的微服务或Web应用，并且该应用也需要进行负载均衡，也可以参考所述方法进设置。如果是http的负载均衡，也可以选择使用七层负载均衡方式。

4 结束语

Kubernetes推出以后得到了快速的发展，加上微服务架构的逐渐流行，部署具有高可用、负载均衡特性Kubernetes集群的需求越来越多。本文设计了一套简单、高效的高可用负载均衡Kubernetes集群。利用该设计原则，我们可以很方便地将集群进行水平扩展，满足一般的微服务应用场景。在本文的基础上，我们仍然可以通过使用LVS、优化负载均衡算法等获得更高性能的Kubernetes集群，进一步发挥微服务架构的优势。