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

 

1、高可用原理

  配置一臺新的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節點的全局惟一性。

2、初始化

  主機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下

3、配置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節點狀態

4、安裝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節點上了。

5、集羣測試

①master2節點正常訪問

②手動將master1節點down掉，看是否還可以訪問

訪問正常，高可用集羣配置成功！！