Kubernetes高可用也許是完成了初步的技術(shù)評估务甥，打算將生產(chǎn)環(huán)境遷移進(jìn)Kubernetes集群之前普遍面臨的問題。 為了減少因為服務(wù)器當(dāng)機(jī)引起的業(yè)務(wù)中斷，生產(chǎn)環(huán)境中的業(yè)務(wù)系統(tǒng)往往已經(jīng)做好了高可用渊季，而當(dāng)引入Kubernetes這一套新的集群管理系統(tǒng)之后唆涝， 服務(wù)器不再是單一的個體，位于中央位置的Kubernetes Master一旦中斷服務(wù)萝究，將導(dǎo)致所有Node節(jié)點均不可控免都，有可能造成嚴(yán)重的事故。
總體來講這是一個被多次討論帆竹，但暫時沒有形成統(tǒng)一解決方案的話題绕娘。今天主要介紹一些Kubernetes Master高可用的策略，供大家參考栽连。
一個小目標(biāo)
高可用是復(fù)雜的系統(tǒng)工程险领。出于篇幅的考慮以及能力的限制，今天我們先關(guān)注一個小目標(biāo)：所有的Kubernetes Master服務(wù)器沒有單點故障秒紧，任何一臺服務(wù)器當(dāng)機(jī)均不影響Kubernetes的正常工作绢陌。
實現(xiàn)這一目標(biāo)帶來的直接收益是我們可以在不影響業(yè)務(wù)正常運行的前提下實現(xiàn)所有服務(wù)器的滾動升級，有助于完成系統(tǒng)組件升級以及安全補丁的下發(fā)熔恢。
為了實現(xiàn)沒有單點故障的目標(biāo)脐湾，需要為以下幾個組件建立高可用方案：
kube-controller-manager與kube-scheduler
這些組件的關(guān)系可參考下面這張集群架構(gòu)示意圖。
下面為大家逐個詳細(xì)介紹各個組件的高可用策略叙淌。
etcd高可用
etcd是Kubernetes當(dāng)中唯一帶狀態(tài)的服務(wù)秤掌，也是高可用的難點愁铺。Kubernetes選用etcd作為它的后端數(shù)據(jù)存儲倉庫正是看重了其使用分布式架構(gòu)，沒有單點故障的特性闻鉴。
雖然單節(jié)點的etcd也可以正常運行茵乱。但是推薦的部署方案均是采用3個或者5個節(jié)點組成etcd集群，供Kubernetes使用孟岛。
大家常使用的kubeadm工具默認(rèn)是在一個單節(jié)點上啟動etcd以及所有的Master組件瓶竭。雖然使用起來非常方便，但是要用到生產(chǎn)環(huán)境還是要注意這個節(jié)點當(dāng)機(jī)的風(fēng)險渠羞。
etcd的高可用基本有三種思路：
一是使用獨立的etcd集群在验，使用3臺或者5臺服務(wù)器只運行etcd，獨立維護(hù)和升級堵未。甚至可以使用CoreOS的update-engine和locksmith腋舌，讓服務(wù)器完全自主的完成升級。這個etcd集群將作為基石用于構(gòu)建整個集群渗蟹。 采用這項策略的主要動機(jī)是etcd集群的節(jié)點增減都需要顯式的通知集群块饺，保證etcd集群節(jié)點穩(wěn)定可以更方便的用程序完成集群滾動升級，減輕維護(hù)負(fù)擔(dān)雌芽。
二是在Kubernetes Master上用static pod的形式來運行etcd授艰，并將多臺Kubernetes Master上的etcd組成集群。 在這一模式下世落，各個服務(wù)器的etcd實例被注冊進(jìn)了Kubernetes當(dāng)中淮腾，雖然無法直接使用kubectl來管理這部分實例，但是監(jiān)控以及日志搜集組件均可正常工作屉佳。在這一模式運行下的etcd可管理性更強谷朝。
三是使用CoreOS提出的self-hosted etcd方案，將本應(yīng)在底層為Kubernetes提供服務(wù)的etcd運行在Kubernetes之上武花。 實現(xiàn)Kubernetes對自身依賴組件的管理圆凰。在這一模式下的etcd集群可以直接使用etcd-operator來自動化運維，最符合Kubernetes的使用習(xí)慣体箕。
這三種思路均可以實現(xiàn)etcd高可用的目標(biāo)专钉，但是在選擇過程中卻要根據(jù)實際情況做出一些判斷。簡單來講預(yù)算充足但保守的項目選方案一累铅， 想一步到位并愿意承擔(dān)一定風(fēng)險的項目選方案三跃须。折中一點選方案二。各個方案的優(yōu)劣以及做選擇過程中的取舍在這里就不詳細(xì)展開了娃兽，對這塊有疑問的朋友可以私下聯(lián)系交流菇民。
kube-apiserver高可用
apiserver本身是一個無狀態(tài)服務(wù)，要實現(xiàn)其高可用相對要容易一些，難點在于如何將運行在多臺服務(wù)器上的apiserver用一個統(tǒng)一的外部入口暴露給所有Node節(jié)點玉雾。
說是難點，其實對于這種無狀態(tài)服務(wù)的高可用轻要，我們在設(shè)計業(yè)務(wù)系統(tǒng)的高可用方案時已經(jīng)有了相當(dāng)多的經(jīng)驗積累复旬。需要注意的是apiserver所使用的SSL證書要包含外部入口的地址，不然Node節(jié)點無法正常訪問apiserver冲泥。
apiserver的高可用也有三種基本思路：
一是使用外部負(fù)載均衡器驹碍，不管是使用公有云提供的負(fù)載均衡器服務(wù)或是在私有云中使用LVS或者HaProxy自建負(fù)載均衡器都可以歸到這一類。 負(fù)載均衡器是非常成熟的方案凡恍，在這里略過不做過多介紹志秃。如何保證負(fù)載均衡器的高可用，則是選擇這一方案需要考慮的新問題嚼酝。
二是在網(wǎng)絡(luò)層做負(fù)載均衡浮还。比如在Master節(jié)點上用BGP做ECMP，或者在Node節(jié)點上用iptables做NAT都可以實現(xiàn)闽巩。采用這一方案不需要額外的外部服務(wù)钧舌，但是對網(wǎng)絡(luò)配置有一定的要求。
三是在Node節(jié)點上使用反向代理對多個Master做負(fù)載均衡涎跨。這一方案同樣不需要依賴外部的組件洼冻，但是當(dāng)Master節(jié)點有增減時，如何動態(tài)配置Node節(jié)點上的負(fù)載均衡器成為了另外一個需要解決的問題隅很。
從目前各個集群管理工具的選擇來看撞牢，這三種模式都有被使用，目前還沒有明確的推薦方案產(chǎn)生叔营。建議在公有云上的集群多考慮第一種模式屋彪，在私有云環(huán)境中由于維護(hù)額外的負(fù)載均衡器也是一項負(fù)擔(dān)，建議考慮第二種或是第三種方案绒尊。
kube-controller-manager與kube-scheduler高可用
這兩項服務(wù)是Master節(jié)點的一部分撼班，他們的高可用相對容易，僅需要運行多份實例即可垒酬。這些實例會通過向apiserver中的Endpoint加鎖的方式來進(jìn)行l(wèi)eader election砰嘁， 當(dāng)目前拿到leader的實例無法正常工作時，別的實例會拿到鎖勘究，變?yōu)樾碌膌eader矮湘。
目前在多個Master節(jié)點上采用static pod模式部署這兩項服務(wù)的方案比較常見，激進(jìn)一點也可以采用self-hosted的模式口糕，在Kubernetes之上用DaemonSet或者Deployment來部署缅阳。
Kube-dns高可用
嚴(yán)格來說kube-dns并不算是Master組件的一部分，因為它是可以跑在Node節(jié)點上，并用Service向集群內(nèi)部提供服務(wù)的十办。但在實際環(huán)境中秀撇， 由于默認(rèn)配置只運行了一份kube-dns實例，在其升級或是所在節(jié)點當(dāng)機(jī)時向族，會出現(xiàn)集群內(nèi)部dns服務(wù)不可用的情況呵燕，嚴(yán)重時會影響到線上服務(wù)的正常運行。
為了避免故障件相，請將kube-dns的replicas值設(shè)為2或者更多再扭，并用anti-affinity將他們部署在不同的Node節(jié)點上。這項操作比較容易被疏忽夜矗，直到出現(xiàn)故障時才發(fā)現(xiàn)原來是kube-dns只運行了一份實例導(dǎo)致的故障泛范。
總結(jié)
上面介紹了Kubernetes Master各個組件高可用可以采用的策略。其中etcd和kube-apiserver的高可用是整個方案的重點紊撕。由于存在多種高可用方案罢荡，集群管理員應(yīng)當(dāng)根據(jù)集群所處環(huán)境以及其他限制條件選擇適合的方案。
這種沒有絕對的通用方案对扶，需要集群建設(shè)者根據(jù)不同的現(xiàn)狀在多個方案中做選擇的情況在Kubernetes集群建設(shè)過程中頻頻出現(xiàn)柠傍， 也是整個建設(shè)過程中最有挑戰(zhàn)的一部分。容器網(wǎng)絡(luò)方案的選型作為Kubernetes建設(shè)過程中需要面對的另外一個大問題也屬于這種情況辩稽，今后有機(jī)會再來分享這個話題惧笛。
在實際建設(shè)過程中，在完成了上述四個組件的高可用之后逞泄，最好采取實際關(guān)機(jī)檢驗的方式來驗證高可用方案的可靠性患整，并根據(jù)檢驗的結(jié)果不斷調(diào)整和優(yōu)化整個方案。
此外將高可用方案與系統(tǒng)自動化升級方案結(jié)合在一起考慮喷众，實現(xiàn)高可用下的系統(tǒng)自動升級各谚，將大大減輕集群的日常運維負(fù)擔(dān)，值得投入精力去研究到千。
雖然本篇主要在講Kubernetes Master高可用的方案昌渤，但需要指出的是，高可用也并不是必須的憔四，為了實現(xiàn)高可用所付出的代價并不低膀息， 需要有相應(yīng)的收益來平衡。對于大量的小規(guī)模集群來說了赵，業(yè)務(wù)系統(tǒng)并沒有實現(xiàn)高可用潜支，貿(mào)然去做集群的高可用收益有限。這時采用單Master節(jié)點的方案柿汛，做好etcd的數(shù)據(jù)備份冗酿，不失為理性的選擇。
