haproxy检查脚本

cat /etc/keepalived/chk_haproxy_master.sh
#!/bin/bash
if [ $(ps -C haproxy --no-header | wc -l) -eq 0 ]; then
   systemctl start haproxy
   sleep 3

   if [ $(ps -C haproxy --no-header | wc -l) -eq 0 ]; then
        systemctl stop keepalived
   fi
fi

chmod +x /etc/keepalived/chk_haproxy_master.sh

启动keepalived服务

systemctl enable keepalived
systemctl start keepalived

2: ens192:  mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:98:2e:9c brd ff:ff:ff:ff:ff:ff
    inet 192.168.16.245/24 brd 192.168.16.255 scope global noprefixroute ens192
       valid_lft forever preferred_lft forever
    inet 192.168.16.247/32 scope global ens192
       valid_lft forever preferred_lft forever
    inet6 fe80::822:4c72:993b:a056/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::6450:5694:d6c3:b30e/64 scope link tentative noprefixroute dadfailed
       valid_lft forever preferred_lft forever

另外节点也这样安装

后面验证下vip漂移就ok

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状态。