02 | 健康之路 kubernetes(k8s) 实践之路 : 生产可用环境及验证
上一篇《?01 | 健康之路 kubernetes(k8s) 實踐之路 : 開篇及概況?》我們介紹了我們的大體情況，也算邁出了第一步。今天我們主要介紹下我們生產可用的集群架設方案。涉及了整體拓補圖，和我們采用的硬件配置，目前存在的問題等內容。
遵循上一篇提到的系列風格，這邊不涉及基礎的內容，這些基礎的內容大家可以通過官方文檔或其它渠道進行補充，主要還是分享實踐經驗及注意點。
LVS
HAProxy
Harbor
Etcd
Kubernetes (master、node)
以上就是我們目前在生產線的整體拓補圖（隱去了IP，除了 K8S Node塊其它實例數與圖中一致）
LVS 、HAProxy 被規劃為基礎層，主要提供了一個高可用的7層負載均衡器。
由LVS keepalived 提供一個高可用的VIP（虛擬IP）。
這個VIP反代到后端的兩臺HAProxy服務器。
HAProxy反代了K8S Master和Harbor服務器，提供了K8S Master API和Harbor的高可用和負載均衡能力。
為什么不使用Nginx？
這個使用nginx也完全沒問題，根據自己的喜好選擇，這邊選擇HAProxy的主要原因是k8s官方文檔中出現了HAProxy而不是Nginx。
能否不使用HAProxy，直接從LVS轉發到Master？
理論上可行，我們沒有試驗。
如果不缺兩臺機器推薦還是架設一層具有7層代理能力的服務。
k8s apiserver、harbor、etcd都是以HTTP的方式提供的api，如果有7層代理能力的服務后續會更容易維護和擴展。
硬件配置
用途 | 數量 | CPU | 內存 |
Keepalived | 2 | 2 | 4GB |
HAProxy | 2 | 2 | 4GB |
kubernetes集群主要有兩種類型的節點：master和node。
master則是集群領導。
node是工作者節點。
可以看出這邊主要的工作在master節點，node節點根據具體需求隨意增減就好了。
master節點的高可用拓補官方給出了兩種方案。
Stacked etcd topology（堆疊etcd）
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節點的組件
apiserver
controller-manager
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/
硬件配置
etcd是一個采用了raft算法的分布式鍵值存儲系統。
這不是k8s專屬的是一個獨立的分布式系統，具體的介紹大家可以參考官網，這邊不多做介紹。
我們采用了 static pod的方式部署了etcd集群。
失敗容忍度
最小可用節點數：(n/2)+1
總數 | 健康數 | 失敗數 |
1 | 1 | 0 |
2 | 2 | 0 |
3 | 2 | 1 |
4 | 3 | 1 |
5 | 3 | 2 |
6 | 4 | 2 |
7 | 4 | 3 |
8 | 5 | 3 |
9 | 5 | 4 |
硬件配置
官網:?https://etcd.io/
官方硬件建議:?https://etcd.io/docs/v3.3.12/op-guide/hardware/
部署文檔:?https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/
harbor是一個開源的docker鏡像庫系統。
眼尖的人可以看出，拓補圖中的harbor拓補的高可用其實是存在問題的。
我們目前采用的是雙主模式：
可以發現，如果復制過程中出現了問題那么就可能會造成間歇性pull鏡像失敗。
真正推薦的做法是共享后端存儲，將harbor實例做成無狀態的：
由于我們剛起步，還沒有搭建分布式存儲系統，后面當搭建了Ceph集群后會轉成這種模式。
如果大家現狀允許可以直接采用共享存儲的方式搭建harbor。
至此生產可用的k8s集群已“搭建完成”。為什么打引號？因為我們還沒有進行測試和驗證，下面給出我們列出的上線前的驗證清單。
其中harbor由于我們采用的是雙主，所以目前還標記為警告狀態。
還有涉及的BGP相關的驗證不在此次文章內容中，后續會為大家說明。
還有一點需要注意的是物理機的可用性，如果這些虛擬機全部在一臺物理機上那么還是存在“單點問題”。這邊建議至少3臺物理機以上。
為什么需要3臺物理機以上？
主要是考慮到了etcd的問題，如果只有兩臺物理機部署了5個etcd節點，那么部署了3個etcd的那臺物理機故障了，則不滿足etcd失敗容忍度而導致etcd集群宕機，從而導致k8s集群宕機。
下一篇大概會是什么內容？
應該會寫，k8s master、node的一些可選配置調優和推薦。
原文鏈接：https://www.cnblogs.com/ants/p/11273805.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總?http://www.csharpkit.com?
總結
以上是生活随笔為你收集整理的02 | 健康之路 kubernetes(k8s) 实践之路 : 生产可用环境及验证的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： ASP.NET Core on K8S深
- 下一篇： 面对人性，有的选择向左，有的向右