Kubernetes中如何進行多master節點容錯部署

這篇文章給大家介紹Kubernetes中如何進行多master節點容錯部署，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

Kubernetes的master服務主要包括etcd(數據存儲)、control-manager(控制器)、scheduler(調度器)、apiserver(服務接口)，我們將其部署到多節點實現容錯。

1、多master節點部署

control-manager(控制器)和scheduler(調度器)通過apiserver(服務接口)來進行集群容器實例的管理，通過向apiserver中的Endpoint加鎖的方式來進行leader election， 當目前拿到leader的實例無法正常工作時，別的實例會拿到鎖，變為新的leader。缺省情況下election=true，默認安裝即支持多實例的自動選主。

• 說明：各個節點的kubelet會自動啟動/etc/kubernetes/manifest/*.yaml里定義的pod，作為static pod運行。

首先，使用kubeadm部署第一個主節點。

第二步，安裝副節點。

• 使用kubeadm部署多個副節點。

• 或者先用kubeadm join部署為工作節點。

• 然后將/etc/kubernetes/manifest下的文件復制到各個副節點對應目錄，以及上級對應的*.conf文件。文件包括：

• etcd.yaml （之前已經修改，不能覆蓋）

• kube-apiserver.yaml 

• kube-controller-manager.yaml 

• kube-scheduler.yaml

• 重啟kubelet服務，運行命令：systemctl restart kubelet。

• 此時，在Kubernetes的Dashboard中可以看到上面的pod，但是不能進行刪除等操作。

2、apiserver的負載均衡

通過上面的方法設置多個master服務后，kube-apiserver的URL主地址全部指向的是第一個master節點IP地址，仍然存在單點失效的風險。為了實現多點容錯，有幾種方案（原理都是一樣的，只是實現方式不同）：

第一種，外部負載均衡器。

使用外部的負載均衡器分配的高可用IP作為apiserver的服務地址，所有的外部訪問以及scheduler.conf、controller-manager.conf中的server參數均指向該地址，然后將該地址映射到具體的內部服務器IP上，由外部負載均衡器來分配訪問負載。

• 在上面的各master節點上使用高可用IP作為服務地址，如--apiserver-advertise-address=10.1.1.201。

• 參考：多網卡Ubuntu服務器安裝Kubernetes

• 把副節點的IP地址加入負載均衡器。

• 將所有節點的scheduler.conf、controller-manager.conf中的server參數指向該高可用IP。

這種方式部署較為簡單，但依賴云服務商提供的負載均衡器。

如果自己安裝負載均衡器設備或軟件，需要確保其本身是高可用的。

第二種，虛擬IP+負載均衡。

使用keepalived實現虛擬IP，主節點不可用時將IP自動漂移到其它節點，工作節點基本不受影響。k8s集群按照虛擬IP進行配置，與第一種方案類似，但通過簡單的軟件即可實現k8s集群主節點的容錯。

虛擬IP（實際上是直接修改真實IP）每一時刻只運行于單個節點上。因此，其它的副節點上的apiserver服務處于standby模式。

通過添加HAProxy等做apiserver的負載均衡，之上再用keepalived做多節點的虛擬IP，可以將多節點變為支持負載均衡的互備模式。

• 在每一個副節點運行keepalived，配置為同一組和IP地址加入負載均衡器。

• 將所有節點的scheduler.conf、controller-manager.conf中的server參數指向該高可用IP。

• 注意，kubeadm安裝的kubernetes證書只能支持本機單節點授權。這種模式可能需要更換新的授權證書。

第三種，多主分治+反向代理。

每個節點單獨運行，通過etcd共享數據。

• 各個節點的scheduler.conf、controller-manager.conf的server參數指向本地apiserver。

• 部署nginx做反向代理，外部訪問通過反向代理服務分發到各個apiserver。

• 各個節點完全自治，授權證書也不相同，需要反向代理進行處理。

• 反向代理應該是高可用的，與第一種方式類似。

3、Kube-dns高可用

kube-dns并不算是Master組件的一部分，可以跑在Node節點上，并用Service向集群內部提供服務。但在實際環境中， 由于默認配置只運行了一份kube-dns實例，在其升級或是所在節點當機時，會出現集群內部dns服務不可用的情況，嚴重時會影響到線上服務的正常運行。

為了避免故障，請將kube-dns的replicas值設為2或者更多，并用anti-affinity將他們部署在不同的Node節點上。這項操作比較容易被疏忽，直到出現故障時才發現原來是kube-dns只運行了一份實例導致的故障。

關于Kubernetes中如何進行多master節點容錯部署就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。