Kubernetes集羣高可用的策略和實踐

時間 2019-11-06

原文原文鏈接

Kubernetes高可用也許是完成了初步的技術評估，打算將生產環境遷移進Kubernetes集羣以前廣泛面臨的問題。html

爲了減小由於服務器當機引發的業務中斷，生產環境中的業務系統每每已經作好了高可用，而當引入Kubernetes這一套新的集羣管理系統以後，服務器再也不是單一的個體，位於中央位置的Kubernetes Master一旦中斷服務，將致使全部Node節點均不可控，有可能形成嚴重的事故。git

整體來說這是一個被屢次討論，但暫時沒有造成統一解決方案的話題。今天主要介紹一些Kubernetes Master高可用的策略，供你們參考。github

基本目標

高可用是複雜的系統工程。出於篇幅的考慮以及能力的限制，今天咱們先關注一個小目標：後端

全部的Kubernetes Master服務器沒有單點故障，任何一臺服務器當機均不影響Kubernetes的正常工做。

實現這一目標帶來的直接收益是咱們能夠在不影響業務正常運行的前提下實現全部服務器的滾動升級，有助於完成系統組件升級以及安全補丁的下發。centos

爲了實現沒有單點故障的目標，須要爲如下幾個組件創建高可用方案：api

集羣高可用技術路線示意圖。安全

下面爲你們逐個詳細介紹各個組件的高可用策略。服務器

一、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的數據備份，不失爲理性的選擇。