高可用的K8S叢集部署方案涉及到的内容整體拓補圖SLBetcd

涉及到的内容

1. LVS
2. HAProxy
3. Harbor
4. etcd
5. Kubernetes (Master Worker)

整體拓補圖

以上是最小生産可用的整體拓補圖（相關節點根據需要進行增加，但不能減少）

按功能組劃分

1. SLB
3. K8S Node (Master / Worker)

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

由LVS keepalived 提供一個高可用的VIP（虛拟IP）。

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

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

可以使用Nginx代替HAProxy嗎？

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

可以直接從LVS轉發到Master嗎？

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

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

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

推薦配置

用途	數量	CPU	記憶體
Keepalive	2	4	4GB

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

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

我們采用了 static pod的方式部署了etcd叢集。

失敗容忍度

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

總數	最少存活	失敗容忍
1
3
5
6
7
8
9

括号内是官方推薦的配置

		4 (8~16)	8GB (16GB~64GB)

官網: https://etcd.io/ 官方硬體建議: https://etcd.io/docs/v3.3.12/op-guide/hardware/ Static Pod部署文檔: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/

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叢集）。

我們采用的是第二種，外部etcd，拓補圖如下：

如果采用堆疊的etcd拓補圖則是：

這邊大家可以根據具體的情況選擇，推薦使用第二種，外部的etcd。

參考來源: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/

Master節點的元件

1. apiserver
2. controller-manager
3. scheduler

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

apiserver: 一個api伺服器，所有外部與k8s叢集的互動都需要經過它。（可水準擴充）

controller-manager: 執行控制器邏輯（循環通過apiserver監控叢集狀态做出相應的處理）（一個master叢集中隻會有一個節點處于激活狀态）

scheduler: 将pod排程到具體的節點上（一個master叢集中隻會有一個節點處于激活狀态）

可以看到除了apiserver外都隻允許一個 執行個體處于激活狀态（類HBase）運作于其它節點上的執行個體屬于待命狀态，隻有當激活狀态的執行個體不可用時才會嘗試将自己設為激活狀态。

這邊牽扯到了上司選舉（zookeeper、consul等分布式叢集系統也是需要上司選舉）

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

k8s依賴etcd是以不存在資料一緻性的問題（把資料一緻性壓到了etcd上），是以k8s master不需要采取投票的機制來進行選舉，而隻需節點健康就可以成為leader。

是以這邊master并不要求奇數，偶數也是可以的。

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

Master元件說明: https://kubernetes.io/docs/concepts/overview/components/ 部署文檔: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/

硬體配置

Master			8GB

高可用驗證

至此生産可用的k8s叢集已“搭建完成”。為什麼打引号？因為還沒有進行測試和驗證，下面給出我列出的驗證清單

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

寫在最後

還有一點需要注意的是實體機的可用性，如果這些虛拟機全部在一台實體機上那麼還是存在“單點問題”。這邊建議至少3台實體機以上。

為什麼需要3台實體機以上？

主要是考慮到了etcd的問題，如果隻有兩台實體機部署了5個etcd節點，那麼部署了3個etcd的那台實體機故障了，則不滿足etcd失敗容忍度而導緻etcd叢集當機，進而導緻k8s叢集當機。