共計 2218 個字符，預計需要花費 6 分鐘才能閱讀完成。

這篇文章給大家介紹 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 節點容錯部署就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。