Kubernetes高级实践：Master高可用方案设计和踩过的那些坑

今天我将为大家介绍如何构建Kubernetes Master High Availability环境。此次分享内容是我在工作中经验总结，如果有不正确的或者需要改进的地方，欢迎各位大神指正。

Kubernetes作为容器编排管理系统，通过Scheduler、Replication Controller等组件实现了应用层的高可用，但是针对Kubernetes集群，还需要实现Master组件的高可用。

本次分享论述的Master高可用方案，主要基于社区的高可用方案（http://kubernetes.io/docs/admin/high-availability/）的实践，但是社区的高可用方案中采用的GCE的External Loadbalancer，并未论述如何实现External Loadbalancer，而且也并没有将Kubernetes集群组件容器化。所以，我们的高可用方案在社区高可用方案的基础之上进行了如下两个方面的提升：

第一，除了kubelet之外，Kubernetes所有组件容器化；

第二，通过haproxy和keepalived构建Loadbalancer实现Master的高可用。

下面我们分四个章节来详细论述Kubernetes Master High Availability环境的搭建。

1. HA Master整体架构

2. 核心技术点和难点

3. 实践中的遇到的那些坑

4. 社区关于HA Master的未来发展

一、HA Master整体架构

我们已经成功将支持Master High Availability的Kubernetes集群部署到企业私有云平台，底层采用的是Ubuntu 14.04操作系统。下面是一个典型的部署环境：

Static Pods是由其所在节点上的kubelet直接管理，而不需要通过Apiserver来监视它们。Static Pods的资源类型只能是Pod，而且不与任何的Replication Controller相关联，它们完全由kubelet来监视，并且当它们异常停止的时候由该kubelet负责重启它们。

(haproxy, keepalived)：这里表示我们将haproxy和keepalived放置在同一个pod中。

1.1  kubelet对static pod高可用的支持

我们需要为kubelet进程配置一个manifests监视目录：

• 如果有新的yaml/manifest文件添加到该目录，kubelet则根据yaml/manifest文件创建一个新的static pod；

• 如果我们把某个yaml/manifest文件从该目录删除，kubelet则会删除由该yaml/manifest文件所产生的static pod；

• 如果该目录下的yaml/manifest文件有更新，kubelet则会删除原来的static pod，而根据更新后的yaml/manifest文件重新创建一个新的static pod；

• 如果manifests目录下的文件没有任何变化，但是其下某个yaml/manifest文件所产生的static pod错误退出或者被误删后，kubelet仍然会根据该yaml/manifest文件重新创建一个新的static pod。

这样，kubelet在一定程度上保证了static pod的高可用。

1.2  kubelet进程的高可用

kubelet通过manifests监视目录保证了static pod的高可用，但是如果kubelet进程本身错误退出或者被误删后，谁来负责重新启动kubelet进程呢？

在Linux系统中，我们可以通过Monit、Upstart、Systemd、Supervisor等工具实现对服务的监控保证服务的高可用。

在Ubuntu 14.04操作系统中，我们将kubelet做成系统服务，利用Upstart来保证kubelet服务的高可用，下面是kubelet服务基于Upstart的服务启动脚本/etc/init/kubelet.conf：

 

其中:

• respawn: 该命令设置服务或任务异常停止时将自动启动。除stop命令外的停止都是异常停止。

• respawn limit: 该命令设置服务或任务异常停止后重启次数和间隔时间。

1.3 Master High Availability Kubernetes整体架构图

从架构图中我们可以看到：

1） Upstart保证docker服务和kubelet服务的高可用，而Kubernetes的其他组件将以static pod的方式由kubelet保证高可用。

2） 两台lb节点通过haproxy和keepalived构建出一个External Loadbalancer，并提供VIP供客户端访问。

3） Haproxy配置成“SSL Termination”方式，外网client通过HTTPS请求访问集群，而内网client则可以通过HTTPS/HTTP请求访问。

4） Kubernetes高可用集群通过flannel static pod构建一个Overlay网络，使集群中的docker容器能够通过Kubernetes Cluster IP进行通信。

二、核心技术点和难点

2.1  运行在特权模式的组件

Kubernetes集群中的一些组件需要通过内核模块来为集群提供服务，因此这些组件需要运行在特权模式下，以便能访问相应的内核模块。

2.1.1. 开启特权模式

为了支持docker容器在特权模式下运行，我们需要开启Kubernetes集群的特权模式权限:

这里主要体现在kubelet服务和apiserver服务。

1） Kubelet service

kubelet服务需要开启特权模式权限，以便允许docker容器向kubelet请求以特权模式运行。

2） Apiserver static pod

apiserver static pod需要开启特权模式权限，以便运行在特权模式下的docker容器能够访问apiserver服务。

2.1.2. 运行在特权模式下的docker容器

运行在特权模式下的docker容器，在yaml文件中需要添加如下字段：

这里主要体现在kubeproxy服务、flannel服务和keepalived服务。

1） Kubeproxy static pod

kubeproxy需要通过Iptables设置防火墙规则。

2） Flannel static pod

flannel需要访问vxlan、openvswitch等路由数据报文。

3） Keepalived static pod

keepalived需要访问IP_VS内核模块来建立VIP。

2.2 Static pod必须运行在主机网络下

如上所述的这些以static pod形式存在的Kubernetes集群组件，必须工作在主机网络下：

虽然Overlay网络是为了让不同节点间的docker容器进行通信，而上述以static pod形式存在的组件也都是docker容器，但是它们之间的心跳和信息交流都需要通过主机网络而不是类似于flannel等的Overlay网络。理由如下：

1. 这些static pods不同于应用的pods，它们的稳定保障了Kubernetes集群的稳定性，它们之间的心跳和信息交流都是通过它们配置文件中的静态IP地址进行的，而docker/flannel网络是动态的，我们无法保证docker/flannel网络中IP地址的稳定性，同时也无法事先知道IP地址。

2. kubeproxy、flannel、haproxy需要通过主机网络修改路由规则，从而使主机上的服务能被其他主机访问。

3. haproxy需要将外网请求重定向到内网后端服务器上，也必须需要主机网络。

2.3 External Loadbalancer部署要点

对于如何配置haproxy和keepalived，网络上有非常多的资源，所以这里不在论述。下面我们来分析一下部署过程中的一些要点。

External Loadbalancer由至少两台lb node组成，通过haproxy和keepalived pod实现Master的负载均衡，对外提供统一的VIP。

我们可以将haproxy和keepalived分别放置在不同的pod中，也可以将它们放置在同一个pod中。考虑到keepalived需要监测haproxy的状态，我们会把haproxy和keepalived放在一起做成一个loadbalancer pod。

2.3.1. lb node配置

1） 使能内核IPVS模块

由于keepalived需要通过IPVS模块实现路由转发，所以我们需要使能内核IPVS模块。

从Linux内核版本2.6起，ip_vs code已经被整合进了内核中，因此，只要在编译内核的时候选择了ipvs的功能，Linux即能支持LVS。因此我们只需要配置操作系统启动时自动加载IPVS模块：

 

我们可以通过如下命令查看ip_vs模块是否成功加载：

 

如果没有加载，我们可以通过modprobe命令加载该模块：

 

2） 修改内核参数

为了使keepalived将数据包转发到真实的后端服务器，每一个lb node都需要开启IP转发功能：

 

另外，keepalived设置的VIP有可能为非本地IP地址，所以我们还需要使能非本地IP地址绑定功能：

2.3.2. keepalived监测haproxy状态的方法

对于普通进程来说, keepalived进程可以通过“killall -0 haproxy”命令检测haproxy进程是否正常运行（注: Sending the signal 0 to a given PID just checks if any process with the given PID is running）。

然而在docker容器环境下，各容器都有自己的PidNamespace和NetworkNamespace，我们就需要开启haproxy的健康检查页面，然后keepalived通过健康检查页面的URL来检测haproxy目前是否正常运行。

haproxy健康检查页面配置：

 

keepalived对haproxy的状态检测：

2.3.3. haproxy SSL配置

haproxy代理ssl配置有两种方式：

1. haproxy本身提供SSL证书，后面的web服务器走正常的http协议；

2. haproxy本身只提供代理，直接转发client端的HTTPS请求到后端的web服务器。注意：这种模式下“mode”必须是“tcp”模式, 即仅支持4层代理。

考虑到：第一，用户亲和性访问需要7层代理的支持；第二，loadbalancer和master走的都是集群内网。所以本实践采用了第一种方式，配置如下：

 

2.3.4. haproxy配置：haproxy.cfg

 

2.3.5. keepalived配置：keepalived.conf

1） lb-1上keepalived配置

2） lb-2上keepalived配置

lb-2跟lb-1的配置差不多，除了下面两个字段：

2.4 flannel网络设置

2.4.1 Master节点flannel网络设置

对于Master节点，需要等待Etcd Pod集群启动完后，先在Master上创建Flannel网络，然后Flannel Pod客户端才可以从Etcd中获取到各个Master节点的IP网段，获取到IP网段后会在主机上产生文件：“ /var/lib/flannel/subnet.env”，然后根据该文件修改docker启动参数：

并重启docker服务。

2.4.2 非Master节点flannel网络设置

对于非Master节点，待Loadbalancer起来之后，Node节点能够访问Apiserver之后，Flannel Pod客户端才能从Etcd获取到该Node节点的IP网段，并且同样会在主机上产生文件：“ /var/lib/flannel/subnet.env”。然后修改docker启动参数，并重启docker服务。

三、实践中的遇到的那些坑

3.1 官网“haproxy docker image”的坑

Docker Hub上“haproxy image”的“docker-entrypoint.sh”内容如下:

 

问题就出在“haproxy-systemd-wrapper”。如果运行命令：“haproxy -f /etc/haproxy/haproxy.cfg”, 而实际上运行的是经过“haproxy-systemd-wrapper”包装后的命令：

执行命令“haproxy -f /etc/haproxy/haproxy.cfg”时，真正执行的是: “/usr/local/sbin/haproxy -p /run/haproxy.pid -f /etc/haproxy/haproxy.cfg -Ds”，对于“-Ds”选项, 官网是这么描述的：

原来，“haproxy”经过“haproxy-systemd-wrapper”包装后在后台执行，而docker container不允许进程后台执行，否则docker容器将该启动命令执行完后就退出了。官网image的这个坑很大。

所以，当我们用官网“haproxy image”的时候，就需要用haproxy的完全路径来执行。比如在yaml文件中：

 

3.2. haproxy container exited with 137

首先137退出码表示，其他进程向haproxy container发起了“kill”信号，导致haproxy container退出，容器日志如下：

其次，当通过“docker run”命令执行haproxy container，使用的命令与yaml文件中的一样，而且照样输出上述的“WARNING”，但是容器却不退出。

然后，无奈之下，我试着先将这个“WARNING”解决：这个错误是由于haproxy.cfg中添加了SSL证书导致的, 可以通过设置参数“default-dh-param”解决：

当我解决这个“WARNING”之后，奇迹出现了，haproxy container奇迹般的正常运行了。原来在容器的世界，一个“WARNING”也不能疏忽。

四、社区关于HA Master的未来发展

熟悉kubelet配置参数的都知道，我们在给kubelet配置apiserver的时候，可以通过“--api-servers”指定多个：

这看起来似乎已经做到apiserver的高可用配置了，但是实际上当第一个apiserver挂掉之后, 不能成功的连接到后面的apiserver，也就是说目前仍然只有第一个apiserver起作用。

如果上述问题解决之后, 似乎不需要额外的loadbalancer也能实现master的高可用了，但是，除了kubelet需要配置apiserver，controller manager和scheduler都需要配置apiserver，目前我们还只能通过“--master”配置一个apiserver，无法支持多个apiserver。

社区后续打算支持multi-master配置，实现Kubernetes Master的高可用，而且计划在Kubernetes 1.4版本中合入。

即使将来社区实现了通过multi-master配置的高可用方式，本次分享的Master High Availability仍然非常有意义，因为在私有云场景中，External Loadbalancer除了实现Master的高可用和负载均衡外，还可以针对Worker Node实现Nodeport请求的负载均衡，从而不仅实现了应用的高可用访问，同时也大大提高了应用的访问速度和性能。

参考链接：

1. https://github.com/kubernetes/kubernetes/issues/26852

2. https://github.com/kubernetes/kubernetes/pull/25428

Q&A

Q1：请问访问Docker时，k8s节点上的kubeproxy性能瓶颈如何破？

A1：这是个好问题。在我们的私有云场景，通过k8s节点上kubeproxy的请求，大部分都是来自外网，我们在每个节点上都开了NodePort。然后，仍然利用Externel LoadBalancer做NodePort的负载均衡，这样，可以避免单节点上Kubeproxy负载过重。

 

Q2：那么在2.3“External Loadbalancer部署要点”这一节中集成lvs就是解决这个问题的吗？

A2：嗯，那个就是为了实现LoadBalancer负载均衡用的。因为，我们已经将LoadBalancer也容器化了，在我们的集群里面，一个LoadBalancer就是一个Pod，这样，我们可以很快启动一个针对NodePort负载均衡的LoadBalancer。甚至，可以为任何其他服务，迅速启动LoadBalancer。另外，k8s社区后面会把kubelet也容器化。

 

Q3：为什么运行命令要经过“haproxy-systemd-wrapper”包装，是出于什么目的？

A3： 这个是haproxy官网包装的，在我的分享中， “-Ds passe en daemon systemd.  This patch adds a new option "-Ds"which is exactly like "-D", but instead of  forking n times to get n jobs running and thenexiting, prefers to wait for all the  children it just created. With this done,haproxy becomes more systemd-compliant,  without changing anything for other systems ”这段英文已经解释了，这个包装中最重要的就是加了“-Ds” 参数。