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掉，看是否還能夠訪問
訪問正常，高可用集羣配置成功！！