導讀
Kubernetes高可用也許是完成了初步的技術評估，打算將生產環境遷移進Kubernetes集群之前普遍面臨的問題。為了減少因為服務器當機引起的業務中斷，生產環境中的業務系統往往已經做好了高可用，而當引入Kubernetes這一套新的集群管理系統之后， 服務器不再是單一的個體，位於中央位置的Kubernetes Master一旦中斷服務，將導致所有Node節點均不可控，有可能造成嚴重的事故。
總體來講這是一個被多次討論，但暫時沒有形成統一解決方案的話題。今天主要介紹一些Kubernetes Master高可用的策略，供大家參考。
一個小目標
高可用是復雜的系統工程。出於篇幅的考慮以及能力的限制，今天我們先關注一個小目標：所有的Kubernetes Master服務器沒有單點故障，任何一台服務器當機均不影響Kubernetes的正常工作。
實現這一目標帶來的直接收益是我們可以在不影響業務正常運行的前提下實現所有服務器的滾動升級，有助於完成系統組件升級以及安全補丁的下發。
為了實現沒有單點故障的目標，需要為以下幾個組件建立高可用方案：
- etcd
- kube-apiserver
- kube-controller-manager與kube-scheduler
- kube-dns
這些組件的關系可參考下面這張集群架構示意圖。
下面為大家逐個詳細介紹各個組件的高可用策略。
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來管理這部分實例，但是監控以及日志搜集組件均可正常工作。在這一模式運行下的etcd可管理性更強。
三是使用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的數據備份，不失為理性的選擇。