K8S高可用集群架构实现

  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掉，看是否还能够访问

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