面試官:有做過高可用的K8S集羣部署方案嗎?

本文已收錄GitHub,更有互聯網大廠面試真題,面試攻略,高效學習資料等

一、涉及到的內容

  • LVS
  • HAProxy
  • Harbor
  • etcd
  • Kubernetes (Master Worker)

二、整體拓補圖

以上是最小生產可用的整體拓補圖(相關節點根據需要進行增加,但不能減少)

按功能組劃分

  • SLB
    • LVS
    • HAProxy
  • etcd
  • K8S Node (Master / Worker)

三、SLB

LVS 、HAProxy 被規劃爲基礎層,主要提供了一個高可用的7層負載均衡器。

由LVS keepalived 提供一個高可用的VIP(虛擬IP)。

這個VIP DR模式轉發到後端的HAProxy服務器。

HAProxy反代了K8S Master服務器,提供了K8S Master API的高可用和負載均衡能力。

1. 可以使用Nginx代替HAProxy嗎

是可以的,這邊使用HAproxy是因爲k8s文檔中出現了HAproxy,且後續可能會有4層反代的要求,從而使用了HAProxy。

2. 可以直接從LVS轉發到Master嗎

理論上可行,我沒有試驗。

如果不缺兩臺機器推薦還是架設一層具有7層代理能力的服務。

k8s apiserver、harbor、etcd都是以HTTP的方式提供的api,如果有7層代理能力的服務後續會更容易維護和擴展。

3. 推薦配置

四、etcd

etcd是一個採用了raft算法的分佈式鍵值存儲系統。

這不是k8s專屬的是一個獨立的分佈式系統,具體的介紹大家可以參考官網,這邊不多做介紹。

我們採用了 static pod的方式部署了etcd集羣。

1. 失敗容忍度

最小可用節點數:(n/2)+1,下面是一個參考表格,其中加粗的是推薦的節點數量:

2. 推薦配置

括號內是官方推薦的配置

五、Kubernetes集羣

kubernetes集羣主要有兩種類型的節點:Master和Worker。

  • Master則是集羣領導。
  • Worker是工作者節點。

可以看出這邊主要的工作在Master節點,Worker節點根據具體需求隨意增減就好了。

Master節點的高可用拓補官方給出了兩種方案。

  1. Stacked etcd topology(堆疊etcd)
  2. External etcd topology(外部etcd)

可以看出最主要的區別在於etcd的部署方式。

第一種方案是所有k8s Master節點都運行一個etcd在本機組成一個etcd集羣。

第二種方案則是使用外部的etcd集羣(額外搭建etcd集羣)。

1. Master節點的組件

  • apiserver
  • controller-manager
  • scheduler

一個master節點主要含有上面3個組件 ( 像cloud-controller-manager這邊就不多做說明了,正常不會用到 )

  • apiserver: 一個api服務器,所有外部與k8s集羣的交互都需要經過它。(可水平擴展)
  • controller-manager: 執行控制器邏輯(循環通過apiserver監控集羣狀態做出相應的處理)(一個master集羣中只會有一個節點處於激活狀態)
  • scheduler: 將pod調度到具體的節點上(一個master集羣中只會有一個節點處於激活狀態)

可以看到除了apiserver外都只允許一個 實例處於激活狀態(類HBase)運行於其它節點上的實例屬於待命狀態,只有當激活狀態的實例不可用時纔會嘗試將自己設爲激活狀態。
這邊牽扯到了領導選舉(zookeeper、consul等分佈式集羣系統也是需要領導選舉)

2. Master高可用需要幾個節點?失敗容忍度是多少

k8s依賴etcd所以不存在數據一致性的問題(把數據一致性壓到了etcd上),所以k8s master不需要採取投票的機制來進行選舉,而只需節點健康就可以成爲leader。

所以這邊master並不要求奇數,偶數也是可以的。

那麼master高可用至少需要2個節點,失敗容忍度是(n/0)+1,也就是隻要有一個是健康的k8s master集羣就屬於可用狀態。(這邊需要注意的是master依賴etcd,如果etcd不可用那麼master也將不可用)

3. 硬件配置

六、高可用驗證

至此生產可用的k8s集羣已“搭建完成”。爲什麼打引號?因爲還沒有進行測試和驗證,下面給出我列出的驗證清單

還有涉及的BGP相關的驗證不在此次文章內容中,後續會爲大家說明。

七、寫在最後

還有一點需要注意的是物理機的可用性,如果這些虛擬機全部在一臺物理機上那麼還是存在“單點問題”。這邊建議至少3臺物理機以上

爲什麼需要3臺物理機以上

主要是考慮到了etcd的問題,如果只有兩臺物理機部署了5個etcd節點,那麼部署了3個etcd的那臺物理機故障了,則不滿足etcd失敗容忍度而導致etcd集羣宕機,從而導致k8s集羣宕機。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章