kubernetes haproxy+keepalive实现master集群高可用

前言

master的HA，实际是apiserver的HA。Master的其余组件controller-manager、scheduler都是能够经过etcd作选举（--leader-elect），而APIServer设计的就是可扩展性，因此作到APIServer很容易，只要前面加一个负载均衡轮训转发请求便可。下面简单描述下haproxy和keepalive。
注意⚠️便于你们使用，因此先码部署，有兴趣的能够看下后面的原理。

1、实操篇

1. haproxy部署

1.1. 安装haproxy

yum -y install haproxy生产环境能够用二进制包部署

1.2. 修改配置文件

cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg-back
vim /etc/haproxy/haproxy.cfg

global
    log         127.0.0.1 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats

defaults
    mode                    tcp
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

frontend  main *:16443
    acl url_static       path_beg       -i /static /images /javascript /stylesheets
    acl url_static       path_end       -i .jpg .gif .png .css .js
    use_backend static          if url_static
    default_backend             kube-apiserver

backend static
    balance     roundrobin
    server      static 127.0.0.1:4331 check

backend kube-apiserver
    balance     roundrobin
    server  k8s1-matser1 10.8.4.91:6443 check
    server  k8s1-matser2 10.8.4.92:6443 check
    server  k8s1-matser3 10.8.4.93:6443 check

⚠️注意

1. defaults 模块中的 mode http 要改成 tcp（或者在下面的 frontend 和 backend 模块中单独定义 mode tcp ）若是不改，后续 kubectl get node 会处于 NotReady 状态。
2. frontend 端口需指定非 6443 端口，要否则其余 master 节点会启动异常（若是 haproxy 单独主机，则可用 6443 端口）

3. 配置文件能够拷贝其余节点，配置文件保持同样。

   1.3.启动haproxy

   systemctl start haproxy && systemctl enable haproxy && systemctl status haproxy

   2. keepalive部署

   2.1. 安装keepalive

   yum install -y keepalived

   2.2. 修改配置文件

   cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf-back
vim /etc/keepalived/keepalived.conf

! Configuration File for keepalived

global_defs {
   router_id LVS_1
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        10.8.4.55/24
    }
}

⚠️注意

1. global_defs 只保留 router_id（每一个节点都不一样）；
2. 修改 interface（vip绑定的网卡），及 virtual_ipaddress（vip地址及掩码长度）；
3. 删除后面的示例

4. 其余节点只需修改 state 为 BACKUP，优先级 priority 低于100便可。

   2.3. 启动keeplive

systemctl start keepalived && systemctl enable keepalived && systemctl status keepalived

2.4. 查看状态

ip addr show eth0如图

能够看到vip只在一台机器上；若是两个机器都有vip，多是防火墙拦截了vrrp协议。

2、概述篇(做者摘抄整理)

1.haproxy+keepalived实现高可用负载均衡

软件负载均衡通常经过两种方式来实现：基于操做系统的软负载实现和基于第三方应用的软负载实现。LVS就是基于Linux操做系统实现的一种软负载，HAProxy就是开源的而且基于第三应用实现的软负载。

HAProxy相比LVS的使用要简单不少，功能方面也很丰富。当前，HAProxy支持两种主要的代理模式:"tcp"也即4层（大多用于邮件服务器、内部协议通讯服务器等），和7层（HTTP）。在4层模式 下，HAProxy仅在客户端和服务器之间转发双向流量。7层模式下，HAProxy会分析协议，而且能经过容许、拒绝、交换、增长、修改或者删除请求 (request)或者回应(response)里指定内容来控制协议，这种操做要基于特定规则。

1.1.Haproxy简介

反向代理服务器,支持双机热备支持虚拟主机,但其配置简单,拥有很是不错的服务器健康检查功能,当其代理的后端服务器出现故障, HAProxy会自动将该服务器摘除,故障恢复后再自动将该服务器加入｡自1.3引入了frontend,backend；frontend根据任意 HTTP请求头内容作规则匹配,而后把请求定向到相关的backend.

1.2.keepalived简介

keepalived是一个相似于layer3, 4 & 5交换机制的软件，也就是咱们平时说的第3层、第4层和第5层交换。Keepalived的做用是检测web服务器的状态，若是有一台web服务器死机，或工做出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工做正常后Keepalived自动将web服务器加入到服务器群中，这些工做所有自动完成，不须要人工干涉，须要人工作的只是修复故障的web服务器。

⚠️相似的HA工具还有heatbeat、drbd等，heatbeat、drbd配置都较为复杂。

1.2.1. keepalived理论工做原理

keepalived可提供vrrp以及health-check功能，能够只用它提供双机浮动的vip（vrrp虚拟路由功能），这样能够简单实现一个双机热备高可用功能。

keepalived是一个相似于layer3, 4 & 5交换机制的软件，也就是咱们平时说的第3层、第4层和第5层交换。Keepalived的做用是检测web 服务器的状态。 Layer3,4&5工做在IP/TCP协议栈的IP层，TCP层，及应用层,原理分别以下：

• Layer3：Keepalived使用Layer3的方式工做式时，Keepalived会按期向服务器群中的服务器发送一个ICMP的数据包（既咱们平时用的Ping程序）,若是发现某台服务的IP地址没有激活，Keepalived便报告这台服务器失效，并将它从服务器群中剔除，这种状况的典型例子是某台服务器被非法关机。Layer3的方式是以服务器的IP地址是否有效做为服务器工做正常与否的标准。
• Layer4:若是您理解了Layer3的方式，Layer4就容易了。Layer4主要以TCP端口的状态来决定服务器工做正常与否。如web server的服务端口通常是80，若是Keepalived检测到80端口没有启动，则Keepalived将把这台服务器从服务器群中剔除。
• Layer5：Layer5就是工做在具体的应用层了，比Layer3,Layer4要复杂一点，在网络上占用的带宽也要大一些。Keepalived将根据用户的设定检查服务器程序的运行是否正常，若是与用户的设定不相符，则Keepalived将把服务器从服务器群中剔除。

vip即虚拟ip，是附在主机网卡上的，即对主机网卡进行虚拟，此IP仍然是占用了此网段的某个IP。

1.2.2.tcp层的keepalive原理(本文所用)

tcp的keepalive是侧重在保持客户端和服务端的链接，一方会不按期发送心跳包给另外一方，当一方端掉的时候，没有断掉的定时发送几回心跳包，若是间隔发送几回，对方都返回的是RST，而不是ACK，那么就释放当前连接。设想一下，若是tcp层没有keepalive的机制，一旦一方断开链接却没有发送FIN给另一方的话，那么另一方会一直觉得这个链接仍是存活的，几天，几月。那么这对服务器资源的影响是很大的。

tcp的keepalive就是为了检测连接的可用性。主要调节的参数有三个：

• tcp_keepalive_time // 距离上次传送数据多少时间未收到判断为开始检测
• tcp_keepalive_intvl // 检测开始每多少时间发送心跳包
• tcp_keepalive_probes // 发送几回心跳包对方未响应则close链接
  基本上的流程：

1. 在客户端和服务端进行完三次握手以后，客户端和服务端都处在ESTABLISH状态，这个时候进行正常的PSH和ACK交互，可是一旦一方服务中断了，另外一方在距离上次PSH时间tcp_keepalive_time发现对方未发送数据，则开始心跳检测。
2. 心跳检测实际就是发送一个PSH的空心跳包，这里说的空心跳包就是包的数据为空，可是TCP包的头部的数据和标识和正常包同样。若是这个包获取到的是RST返回的话，下面就会继续每隔tcp_keepalive_intval的时长发送一个空心跳包，若是tcp_keepalive_probes次心跳包对方都是返回RST而不是ACK，则心跳发起方就判断这个链接已经失效，主动CLOST这个链接。
   这三个参数能够每一个TCP链接都不一样，使用tcp设置变量的函数能够设置当前tcp链接的这三个对应的值。

int setsockopt(int s, int level, int optname,
               const void *optval, socklen_t optlen)

⚠️ http层的keepalive原理 http的keep-alive通常咱们都会带上中间的横杠，普通的http链接是客户端链接上服务端，而后结束请求后，由客户端或者服务端进行http链接的关闭。下次再发送请求的时候，客户端再发起一个链接，传送数据，关闭链接。这么个流程反复。可是一旦客户端发送connection:keep-alive头给服务端，且服务端也接受这个keep-alive的话，两边对上暗号，这个链接就能够复用了，一个http处理完以后，另一个http数据直接从这个链接走了。