Kubernetes高可用也許是完成了初步的技術評估，打算將生產環境遷移進Kubernetes叢集之前普遍面臨的問題。 為了減少因為伺服器當機引起的業務中斷，生產環境中的業務系統往往已經做好了高可用，而當引入Kubernetes這一套新的叢集管理系統之後， 伺服器不再是單一的個體，位於中央位置的Kubernetes Master一旦中斷服務，將導致所有Node節點均不可控，有可能造成嚴重的事故。

總體來講這是一個被多次討論，但暫時沒有形成統一解決方案的話題。今天主要介紹一些Kubernetes Master高可用的策略，供大家參考。

一個小目標

高可用是複雜的系統工程。出於篇幅的考慮以及能力的限制，今天我們先關注一個小目標：所有的Kubernetes Master伺服器沒有單點故障，任何一臺伺服器當機均不影響Kubernetes的正常工作。

實現這一目標帶來的直接收益是我們可以在不影響業務正常執行的前提下實現所有伺服器的滾動升級，有助於完成系統元件升級以及安全補丁的下發。

為了實現沒有單點故障的目標，需要為以下幾個元件建立高可用方案：

這些元件的關係可參考下面這張叢集架構示意圖。

下面為大家逐個詳細介紹各個元件的高可用策略。

etcd高可用

etcd是Kubernetes當中唯一帶狀態的服務，也是高可用的難點。Kubernetes選用etcd作為它的後端資料儲存倉庫正是看重了其使用分散式架構，沒有單點故障的特性。

雖然單節點的etcd也可以正常執行。但是推薦的部署方案均是採用3個或者5個節點組成etcd叢集，供Kubernetes使用。

大家常使用的kubeadm工具預設是在一個單節點上啟動etcd以及所有的Master元件。雖然使用起來非常方便，但是要用到生產環境還是要注意這個節點當機的風險。

etcd的高可用基本有三種思路：

一是使用獨立的etcd叢集，使用3臺或者5臺伺服器只執行etcd，獨立維護和升級。甚至可以使用CoreOS的update-engine和locksmith，讓伺服器完全自主的完成升級。這個etcd叢集將作為基石用於構建整個叢集。 採用這項策略的主要動機是etcd叢集的節點增減都需要顯式的通知叢集，保證etcd叢集節點穩定可以更方便的用程式完成叢集滾動升級，減輕維護負擔。

二是在Kubernetes Master上用static pod的形式來執行etcd，並將多臺Kubernetes Master上的etcd組成叢集。 在這一模式下，各個伺服器的etcd例項被註冊進了Kubernetes當中，雖然無法直接使用kubectl

三是使用CoreOS提出的self-hosted etcd方案，將本應在底層為Kubernetes提供服務的etcd執行在Kubernetes之上。 實現Kubernetes對自身依賴元件的管理。在這一模式下的etcd叢集可以直接使用etcd-operator來自動化運維，最符合Kubernetes的使用習慣。

這三種思路均可以實現etcd高可用的目標，但是在選擇過程中卻要根據實際情況做出一些判斷。簡單來講預算充足但保守的專案選方案一， 想一步到位並願意承擔一定風險的專案選方案三。折中一點選方案二。各個方案的優劣以及做選擇過程中的取捨在這裡就不詳細展開了，對這塊有疑問的朋友可以私下聯絡交流。

kube-apiserver高可用

apiserver本身是一個無狀態服務，要實現其高可用相對要容易一些，難點在於如何將執行在多臺伺服器上的apiserver用一個統一的外部入口暴露給所有Node節點。

說是難點，其實對於這種無狀態服務的高可用，我們在設計業務系統的高可用方案時已經有了相當多的經驗積累。需要注意的是apiserver所使用的SSL證書要包含外部入口的地址，不然Node節點無法正常訪問apiserver。

apiserver的高可用也有三種基本思路：

一是使用外部負載均衡器，不管是使用公有云提供的負載均衡器服務或是在私有云中使用LVS或者HaProxy自建負載均衡器都可以歸到這一類。 負載均衡器是非常成熟的方案，在這裡略過不做過多介紹。如何保證負載均衡器的高可用，則是選擇這一方案需要考慮的新問題。

二是在網路層做負載均衡。比如在Master節點上用BGP做ECMP，或者在Node節點上用iptables做NAT都可以實現。採用這一方案不需要額外的外部服務，但是對網路配置有一定的要求。

三是在Node節點上使用反向代理對多個Master做負載均衡。這一方案同樣不需要依賴外部的元件，但是當Master節點有增減時，如何動態配置Node節點上的負載均衡器成為了另外一個需要解決的問題。

從目前各個叢集管理工具的選擇來看，這三種模式都有被使用，目前還沒有明確的推薦方案產生。建議在公有云上的叢集多考慮第一種模式，在私有云環境中由於維護額外的負載均衡器也是一項負擔，建議考慮第二種或是第三種方案。

kube-controller-manager與kube-scheduler高可用

這兩項服務是Master節點的一部分，他們的高可用相對容易，僅需要執行多份例項即可。這些例項會通過向apiserver中的Endpoint加鎖的方式來進行leader election， 當目前拿到leader的例項無法正常工作時，別的例項會拿到鎖，變為新的leader。

目前在多個Master節點上採用static pod模式部署這兩項服務的方案比較常見，激進一點也可以採用self-hosted的模式，在Kubernetes之上用DaemonSet或者Deployment來部署。

Kube-dns高可用

嚴格來說kube-dns並不算是Master元件的一部分，因為它是可以跑在Node節點上，並用Service向叢集內部提供服務的。但在實際環境中， 由於預設配置只運行了一份kube-dns例項，在其升級或是所在節點當機時，會出現叢集內部dns服務不可用的情況，嚴重時會影響到線上服務的正常執行。

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

總結

上面介紹了Kubernetes Master各個元件高可用可以採用的策略。其中etcd和kube-apiserver的高可用是整個方案的重點。由於存在多種高可用方案，叢集管理員應當根據叢集所處環境以及其他限制條件選擇適合的方案。

這種沒有絕對的通用方案，需要叢集建設者根據不同的現狀在多個方案中做選擇的情況在Kubernetes叢集建設過程中頻頻出現， 也是整個建設過程中最有挑戰的一部分。容器網路方案的選型作為Kubernetes建設過程中需要面對的另外一個大問題也屬於這種情況，今後有機會再來分享這個話題。

在實際建設過程中，在完成了上述四個元件的高可用之後，最好採取實際關機檢驗的方式來驗證高可用方案的可靠性，並根據檢驗的結果不斷調整和優化整個方案。

此外將高可用方案與系統自動化升級方案結合在一起考慮，實現高可用下的系統自動升級，將大大減輕叢集的日常運維負擔，值得投入精力去研究。

雖然本篇主要在講Kubernetes Master高可用的方案，但需要指出的是，高可用也並不是必須的，為了實現高可用所付出的代價並不低， 需要有相應的收益來平衡。對於大量的小規模叢集來說，業務系統並沒有實現高可用，貿然去做叢集的高可用收益有限。這時採用單Master節點的方案，做好etcd的資料備份，不失為理性的選擇。