Kubernetes探祕-多master節點容錯部署

時間 2019-11-09

標籤 kubernetes 探祕 master 節點容錯部署简体版

原文原文鏈接

Kubernetes的master服務主要包括etcd(數據存儲)、control-manager(控制器)、scheduler(調度器)、apiserver(服務接口)，咱們將其部署到多節點實現容錯。在《Kubernetes探祕-etcd節點和實例擴容》中，已經將etcd服務擴展到多個節點。這裏咱們將control-manager(控制器)、scheduler(調度器)、apiserver(服務接口)擴展到多個節點運行。nginx

一、多master節點部署

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

說明：各個節點的kubelet會自動啓動/etc/kubernetes/manifest/*.yaml裏定義的pod，做爲static pod運行。

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

第二步，安裝副節點。api

使用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，可是不能進行刪除等操做。

二、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。

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

若是本身安裝負載均衡器設備或軟件，須要確保其自己是高可用的。.net

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

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

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

經過添加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。
各個節點徹底自治，受權證書也不相同，須要反向代理進行處理。
反向代理應該是高可用的，與第一種方式相似。

三、Kube-dns高可用

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

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