Kubernetes v1.9.7安装部署-ApiServer高可用

1、HAProxy是什么?

HAProxy是由 WillyTarreau开发的一款具备高可用性、负载均及基于 TCP和 HTTP的应用代理开源软件,基于HAProxy的负载均衡架构是最为常见的免费、快速且具备可靠性的集群负载均衡架构解决方案。此外,HAProxy特别适合应用于需要会话保持或七层处理的高负载 web站点,就当前常见硬件体系架构,基于HAProxy的负载均衡系统完全可以支撑数以万计的并发连接.同时,HAProxy的运行模式使其整合到用户当前的基础架构中是个非常简单且安全的过程。通过 HAProxy的代理,还可以避免用户的 Web服务器直接暴露到外部网络中。

HAProxy实现的是一种事件驱动、单一进程的架构模型,此类模型的优点在于能够支撑高并发大规模的连接。反之,多进程或多线程模型受内存和系统调度器的限制以及无处不在的锁限制,很难应对数以万计的高并发连接。HAProxy支持连接拒绝,通过拒绝连接,可以限制某些非法或有意的攻击型连接,从而降低其对网站带来的危害。的这一功能已成为目前应对小型 DDOS攻击的主要方法之一,并且其他负载均衡器很难做到这点。此外, HAProxy还支持全透明代理,即可以将客户端地址或者任何指定地址直接连接到后端服务器,通过全透明代理,可以不用修改某些特殊服务器地址而使其直接接收并处理部分特定流量。

HAProxy主要为基于 HTTP和 TCP访问的应用服务提供负载均衡,如基于 Internet的连接服务和基于 web的应用服务。通过负载均衡算法, HAproxy能够接受数以万计的访问请求并将其转发到后端服务器池中进行处理,而后端服务器池就如一个强大的虚拟服务器接受 HAProxy转发的请求并进行处理。 HAproxy的请求调度器(Scheduler)决定了后端服务器中每个服务器接受和处理的请求量,在没有权重的调度算法下,调度器为每台服务器分配相同数量的请求,而在加权调度算法下,调度器根据每台服务器的权重为每个后端服务器分配不同数量的请求。 HAProxy允许用户自定义多个代理,并为每个代理提供负载均衡服务,代理由一个前端和一个或多个后端构成,前端定义了代理监听的IP地址(Virtual IP )和端口,同时还需在前端定义中关联与其相关的后端,而在HAProxy中,后端主要用于定义服务器池和负载均衡算法。HAProxy的负载均衡服务在7层,即应用层,在很多情况下,由于商业应用连续性的要求,管理员通常需要部署HAProxy,从而为基于HTTP的应用提供负载均衡和高可用性。

HAProxy的配置文件是/etc/haproxy/haproxy.cfg,该文件是 HAProxy功能配置的集中文件,其代理和负载均衡功能的配置均位于该配置文件中。 HAProxy的配置文件主要分为四个部分,即全局功能配置段、默认属性配置段、前端代理配置段、后端负载均衡配置段,各个配置段常见属性设置和功能描述如下。

HAProxy官网地址:https://www.haproxy.com/

2、KeepAlived是什么?

Keepalived软件起初是专为LVS负载均衡软件设计的,用来管理并监控LVS集群系统中各个服务节点的状态,后来又加入了可以实现高可用的VRRP功能。因此,Keepalived除了能够管理LVS软件外,还可以作为其他服务(例如:Nginx、Haproxy、MySQL等)的高可用解决方案软件。

Keepalived软件主要是通过VRRP协议实现高可用功能的。VRRP是Virtual Router RedundancyProtocol(虚拟路由器冗余协议)的缩写,VRRP出现的目的就是为了解决静态路由单点故障问题的,它能够保证当个别节点宕机时,整个网络可以不间断地运行。

所以,Keepalived 一方面具有配置管理LVS的功能,同时还具有对LVS下面节点进行健康检查的功能,另一方面也可实现系统网络服务的高可用功能。

keepalived官网 http://www.keepalived.org KeepAlived配置参考文章:https://www.cnimages.com/clsn/p/8052649.html

KeepAlived的三个核心功能:

管理LVS负载均衡软件

实现LVS集群节点的健康检查中

作为系统网络服务的高可用性(failover)

KeepAlived高可用故障切换转移原理

Keepalived高可用服务对之间的故障切换转移,是通过 VRRP (Virtual Router Redundancy Protocol ,虚拟路由器冗余协议)来实现的。

在 Keepalived服务正常工作时,主 Master节点会不断地向备节点发送(多播的方式)心跳消息,用以告诉备Backup节点自己还活看,当主 Master节点发生故障时,就无法发送心跳消息,备节点也就因此无法继续检测到来自主 Master节点的心跳了,于是调用自身的接管程序,接管主Master节点的 IP资源及服务。而当主 Master节点恢复时,备Backup节点又会释放主节点故障时自身接管的IP资源及服务,恢复到原来的备用角色。那么,什么是VRRP呢?

VRRP ,全 称 Virtual Router Redundancy Protocol ,中文名为虚拟路由冗余协议 ,VRRP的出现就是为了解决静态踣甶的单点故障问题,VRRP是通过一种竞选机制来将路由的任务交给某台VRRP路由器的。

KeepAlived高可用架构

img

Keepalived的工作原理

Keepalived高可用对之间是通过VRRP通信的,因此,我们从 VRRP开始了解起:

1) VRRP,全称 Virtual Router Redundancy Protocol,中文名为虚拟路由冗余协议,VRRP的出现是为了解决静态路由的单点故障。

2) VRRP是通过一种竟选协议机制来将路由任务交给某台 VRRP路由器的。

3) VRRP用 IP多播的方式(默认多播地址(224.0_0.18))实现高可用对之间通信。

4) 工作时主节点发包,备节点接包,当备节点接收不到主节点发的数据包的时候,就启动接管程序接管主节点的开源。备节点可以有多个,通过优先级竞选,但一般 Keepalived系统运维工作中都是一对。

5) VRRP使用了加密协议加密数据,但Keepalived官方目前还是推荐用明文的方式配置认证类型和密码。

介绍完 VRRP,接下来我再介绍一下 Keepalived服务的工作原理:

Keepalived高可用对之间是通过 VRRP进行通信的, VRRP是遑过竞选机制来确定主备的,主的优先级高于备,因此,工作时主会优先获得所有的资源,备节点处于等待状态,当主挂了的时候,备节点就会接管主节点的资源,然后顶替主节点对外提供服务。在 Keepalived服务对之间,只有作为主的服务器会一直发送 VRRP广播包,告诉备它还活着,此时备不会枪占主,当主不可用时,即备监听不到主发送的广播包时,就会启动相关服务接管资源,保证业务的连续性.接管速度最快可以小于1秒。

按照上面的方式在master01与master02机器上安装kube-apiserver、kube-controller-manager、kube-scheduler,但是现在我们还是手动指定访问的6443和8080端口的,因为我们的域名k8s-api.virtual.local对应的master01节点直接通过http 和https 还不能访问,这里我们使用haproxy 来代替请求。

注释:就是我们需要将http默认的80端口请求转发到apiserver的8080端口,将https默认的443端口请求转发到apiserver的6443端口,所以我们这里使用haproxy来做请求转发。

注释:下面所有的操作分别在两台LB上面进行。

1、安装haproxy

$ yum install -y haproxy

2、配置haproxy

由于集群内部有的组建是通过非安全端口访问apiserver 的,有的是通过安全端口访问apiserver 的,所以我们要配置http 和https 两种代理方式,配置文件 /etc/haproxy/haproxy.cfg:

listen stats
  bind    *:9000
  mode    http
  stats   enable
  stats   hide-version
  stats   uri       /stats
  stats   refresh   30s
  stats   realm     Haproxy\ Statistics
  stats   auth      Admin:Password

frontend k8s-api
    bind 192.168.1.137:443
    mode tcp
    option tcplog
    tcp-request inspect-delay 5s
    tcp-request content accept if { req.ssl_hello_type 1 }
    default_backend k8s-api

backend k8s-api
    mode tcp
    option tcplog
    option tcp-check
    balance roundrobin
    default-server inter 10s downinter 5s rise 2 fall 2 slowstart 60s maxconn 250 maxqueue 256 weight 100
    server k8s-api-1 192.168.1.137:6443 check
    server k8s-api-2 192.168.1.138:6443 check

frontend k8s-http-api
    bind 192.168.1.137:80
    mode tcp
    option tcplog
    default_backend k8s-http-api

backend k8s-http-api
    mode tcp
    option tcplog
    option tcp-check
    balance roundrobin
    default-server inter 10s downinter 5s rise 2 fall 2 slowstart 60s maxconn 250 maxqueue 256 weight 100
    server k8s-http-api-1 192.168.1.137:8080 check
    server k8s-http-api-2 192.168.1.138:8080 check

通过上面的配置文件我们可以看出通过https的访问将请求转发给apiserver 的6443端口了,http的请求转发到了apiserver 的8080端口。

3、启动haproxy

$ sudo systemctl start haproxy
$ sudo systemctl enable haproxy
$ sudo systemctl status haproxy

然后我们可以通过上面9000端口监控我们的haproxy的运行状态(172.16.200.17:9000/stats):

img

问题:上面我们的haproxy的确可以代理我们的两个master 上的apiserver 了,但是还不是高可用的,如果master01 这个节点down 掉了,那么我们haproxy 就不能正常提供服务了。这里我们可以使用两种方法来实现高可用。

方式1:使用阿里云SLB

这种方式实际上是最省心的,在阿里云上建一个内网的SLB,将master01 与master02 添加到SLB 机器组中,转发80(http)和443(https)端口即可(注意下面的提示)。

注意:阿里云的负载均衡是四层TCP负责,不支持后端ECS实例既作为Real Server又作为客户端向所在的负载均衡实例发送请求。因为返回的数据包只在云服务器内部转发,不经过负载均衡,所以在后端ECS实例上去访问负载均衡的服务地址是不通的。什么意思?就是如果你要使用阿里云的SLB的话,那么你不能在apiserver节点上使用SLB(比如在apiserver 上安装kubectl,然后将apiserver的地址设置为SLB的负载地址使用),因为这样的话就可能造成回环了,所以简单的做法是另外用两个新的节点做HA实例,然后将这两个实例添加到SLB 机器组中。

4、安装KeepAlived

方式2:使用keepalived

KeepAlived 是一个高可用方案,通过 VIP(即虚拟 IP)和心跳检测来实现高可用。其原理是存在一组(两台)服务器,分别赋予 Master、Backup 两个角色,默认情况下Master 会绑定VIP 到自己的网卡上,对外提供服务。Master、Backup 会在一定的时间间隔向对方发送心跳数据包来检测对方的状态,这个时间间隔一般为 2 秒钟,如果Backup 发现Master 宕机,那么Backup 会发送ARP 包到网关,把VIP 绑定到自己的网卡,此时Backup 对外提供服务,实现自动化的故障转移,当Master 恢复的时候会重新接管服务。非常类似于路由器中的虚拟路由器冗余协议(VRRP)。

开启路由转发,这里我们定义虚拟IP为:172.16.200.20

$ vi /etc/sysctl.conf
# 添加以下内容
net.ipv4.ip_forward = 1
net.ipv4.ip_nonlocal_bind = 1

# 验证并生效
$ sysctl -p
# 验证是否生效
$ cat /proc/sys/net/ipv4/ip_forward
1

安装keepalived:

yum install -y keepalived

我们这里将master01 设置为Master,master02 设置为Backup,修改配置:

$ vi /etc/keepalived/keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
   }
   router_id kube_api
}

vrrp_script check_haproxy {
    # 自身状态检测
    script "killall -0 haproxy"
    interval 3
    weight 5
}

vrrp_instance haproxy-vip {
    # 使用单播通信,默认是组播通信
    unicast_src_ip 172.16.200.17
    unicast_peer {
        172.16.200.18
    }
    # 初始化状态
    state MASTER
    # 虚拟ip 绑定的网卡 (这里根据你自己的实际情况选择网卡)
    interface eth0
    # 此ID 要与Backup 配置一致
    virtual_router_id 51
    # 默认启动优先级,要比Backup 大点,但要控制量,保证自身状态检测生效
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        # 虚拟ip 地址
        172.16.200.20
    }
    track_script {
        check_haproxy
    }
}

virtual_server 172.16.200.20 80 {
  delay_loop 5
  lvs_sched wlc
  lvs_method NAT
  persistence_timeout 1800
  protocol TCP

  real_server 172.16.200.17 80 {
    weight 1
    TCP_CHECK {
      connect_port 80
      connect_timeout 3
    }
  }
}

virtual_server 172.16.200.20 443 {
  delay_loop 5
  lvs_sched wlc
  lvs_method NAT
  persistence_timeout 1800
  protocol TCP

  real_server 172.16.200.17 443 {
    weight 1
    TCP_CHECK {
      connect_port 443
      connect_timeout 3
    }
  }
}

注释:统一的方式在master02 节点上安装keepalived,修改配置,只需要将state 更改成BACKUP,priority更改成99,unicast_src_ip 与unicast_peer 地址修改即可。

创建check_haproxy.sh监测文件:

if [(ps -C haproxy –no-header | wc -l) -eq 0 ]; then(ps−Chaproxy–no−header∣wc−l)−eq0]; then
    systemctl  start   haproxy
fi
sleep 2
if [(ps -C haproxy –no-header | wc -l) -eq 0 ]; then
    systemctl  stop    keepalived
fi

启动keepalived:

$ systemctl start keepalived
$ systemctl enable keepalived
# 查看日志
$ journalctl -f -u keepalived

验证虚拟IP:

# 使用ifconfig -a 命令查看不到,要使用ip addr     
[root@LBA keepalived]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
        valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host
        valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:50:00:00:08:00 brd ff:ff:ff:ff:ff:ff
    inet 172.16.200.17/24 brd 172.16.200.255 scope global eth0
        valid_lft forever preferred_lft forever
    inet 172.16.200.20/32 scope global eth0
        valid_lft forever preferred_lft forever
    inet6 fe80::ad13:b94f:e098:b6fe/64 scope link tentative dadfailed
        valid_lft forever preferred_lft forever
    inet6 fe80::e417:b7d8:b28:8f6a/64 scope link tentative dadfailed
        valid_lft forever preferred_lft forever
    inet6 fe80::6b6:f8ad:4a1f:e786/64 scope link tentative dadfailed
        valid_lft forever preferred_lft forever
[root@LBA keepalived]#

注释:1、到这里,我们就可以将上面的6443端口和8080端口去掉了,可以手动将Master节点kubectl生成的config文件(~/.kube/config)中的server 地址6443端口去掉,另外kube-controller-manager和kube-scheduler的master参数中的8080端口去掉了,然后分别重启这两个组件即可。

img

2、删除Node节点的bootstrap.kubeconfig kubelet.kubeconfig和kube-proxy.kubeconfig文件的6443端口。

img

删除之后重启服务、systemctl daemon-reload一下配置生效:

systemctl daemon-reload
systemctl restart kubelet
systemctl restart kube-proxy

验证apiserver:关闭master01 节点上的kube-apiserver 进程,然后查看虚拟ip是否漂移到了master02 节点。

然后我们就可以将第一步在/etc/hosts里面设置的域名对应的IP 更改为我们的虚拟IP了

master01 与master 02 节点都需要安装keepalived 和haproxy,实际上我们虚拟IP的自身检测应该是检测haproxy,脚本大家可以自行更改。

img

这样我们就实现了接入层apiserver 的高可用了,一个部分是多活的apiserver 服务,另一个部分是一主一备的haproxy 服务。

kube-controller-manager 和kube-scheduler 的高可用

Kubernetes 的管理层服务包括kube-scheduler和kube-controller-manager。kube-scheduler和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状态。

推荐文章