| 编辑推荐: |
本文介绍了高可用原理以及K8S的高可用集群配置的详细过程等内容，希望对您能有所帮助。
本文来自于51cto，由火龙果软件Luca编辑、推荐。 |
|
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掉，看是否还能够访问
访问正常，高可用集群配置成功！！ |
