Kubernetes作为近几年最具颠覆性的容器编排技术，广泛应用与企业的生产环境中，相较于前几年的docker-swarm的编排方式，Kubernetes无疑是站在一个更高的角度对容器进行管理，方便日后项目的普适性，容易对架构进行扩展。

生产环境下更注重于集群的高可用，不同于测试环境的单主节点，在生产环境下需要配置至少两个主节点两个node节点，保证在主节点挂掉之后，node节点的kubelet还能访问到另一个主节点的apiserver等组件进行运作。

在基于前面搭建的k8s集群，如下

k8s-master1 192.168.175.128

k8s-master2 192.168.175.148（新增）

k8s-node1 192.168.175.130

k8s-node2 192.168.175.131

一、高可用原理

配置一台新的master节点，然后在每台node节点上安装nginx，nginx通过内部的负载均衡将node节点上需要通过访问master，kube-apiserver组件的请求，反代到两台k8s-master节点上，这样就可以实现master节点的高可用，当任意一台master节点宕机后，也可以通过nginx负载均衡放文档另一个master节点上。kube-scheduler以及kube-controller-manager高可用则是在两台master配置文件设置leader-elect参数。

Kubernetes的管理层服务包括kube-scheduler和kube-controller-manager。kube-scheduer和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节点的全局唯一性。

二、初始化

主机k8s-master2下

关闭防火墙

# iptables -F
# setenforce 0
# mkdir -pv /opt/kubernetes/{ssl,cfg,bin}

添加了一个新的master节点到k8s集群中，相对应的也需要在密钥设置中配置该节点对应的IP到该节点中，如图所示，配置在server证书申请中，这样集群通信就包含了该IP。

重新应用了新的密钥对后，需要重启一下集群，重启k8s-master1，k8s-node1，k8s-node2，将新的密钥重新放在各个节点上，进行应用。

再将k8s-master1创建的集群间使用的通信密钥传送到k8s-master2的/opt/kubernetes/ssl下

三、配置master对应组件

在/opt/kubernetes/cfg/下配置kube-apiserver，kube-controller-manager，kube-scheduler，对应的systemd启动项与k8s-master1一致

[root@k8s-master2 ~]# cat /opt/kubernetes/cfg/kube-apiserver
KUBE_APISERVER_OPTS="--logtostderr=true 
--v=4 
--etcd-servers=https://192.168.175.128:2379, https://192.168.175.130:2379, https://192.168.175.131:2379 
--insecure-bind-address=127.0.0.1 
--bind-address=192.168.175.148 
--insecure-port=8080 
--secure-port=6443 
--advertise-address=192.168.175.148 
--allow-privileged=true 
--service-cluster-ip-range=10.10.10.0/24 
--admission-control=NamespaceLifecycle,LimitRanger, SecurityContextDeny,ServiceAccount,ResourceQuota, NodeRestriction --authorization-mode=RBAC,Node 
--kubelet-https=true 
--enable-bootstrap-token-auth 
--token-auth-file=/opt/kubernetes/cfg/token.csv 
--service-node-port-range=30000-50000 
--tls-cert-file=/opt/kubernetes/ssl/server.pem 
--tls-private-key-file=/opt/kubernetes/ssl/server-key.pem 
--client-ca-file=/opt/kubernetes/ssl/ca.pem 
--service-account-key-file=/opt/kubernetes/ssl/ca-key.pem 
--etcd-cafile=/opt/kubernetes/ssl/ca.pem 
--etcd-certfile=/opt/kubernetes/ssl/server.pem 
--etcd-keyfile=/opt/kubernetes/ssl/server-key.pem"

[root@k8s-master2 ~]# cat /opt/kubernetes/cfg/kube-controller-manager

KUBE_CONTROLLER_MANAGER_OPTS="--logtostderr=true 
--v=4 
--master=127.0.0.1:8080 
--leader-elect=true 
--address=127.0.0.1 
--service-cluster-ip-range=10.10.10.0/24 
--cluster-name=kubernetes 
--cluster-signing-cert-file=/opt/kubernetes/ssl/ca.pem 
--cluster-signing-key-file=/opt/kubernetes/ssl/ca-key.pem 
--service-account-private-key-file=/opt/kubernetes/ssl/ca-key.pem 
--root-ca-file=/opt/kubernetes/ssl/ca.pem"

[root@k8s-master2 ~]# cat /opt/kubernetes/cfg/kube-scheduler
KUBE_SCHEDULER_OPTS="--logtostderr=true 
--v=4 
--master=127.0.0.1:8080 
--leader-elect"

启动三个服务，先启动kube-apiserver，后两个无顺序要求，这个时候还无法获取后端node节点状态

四、安装nginx并配置

yum安装，配置nginx yum源

# cat > /etc/yum.repos.d/nginx.repo << EOF
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/7/$basearch/
gpgcheck=0
EOF
# yum install nginx -y

nginx配置，基于四层负载均衡，监听本机的127.0.0.1:6443端口

光更改nginx还不够，需要将node节点kubelet访问master的kubeconfig文件中的IP地址更改为本机的127.0.0.1，这样子就可以让kubelet在与master进行通信调用身份认证到本机的127.0.0.1:6443，nginx就可以捕获到这一请求，负载均衡到两个master节点上了。

五、集群测试

①master2节点正常访问

②手动将master1节点down掉，看是否还能够访问

访问正常，高可用集群配置成功！！

出处：http://www.uml.org.cn/yunjisuan/202002053.asp