摘要：官方隻提到了一句“使用負載均衡器将 apiserver 暴露給工作節點”，而這恰恰是部署過程中需要解決的重點問題。
本文分享自華為雲社群《Kubernetes 高可用叢集落地二三事》，作者：zuozewei。
可以設定 HA 叢集：
使用堆疊（stacked）控制平面節點，其中 etcd 節點與控制平面節點共存；
使用外部 etcd 節點，其中 etcd 在與控制平面不同的節點上運作；
在設定 HA 叢集之前，應該仔細考慮每種拓撲的優缺點。
主要特點：
etcd 分布式資料存儲叢集堆疊在 kubeadm 管理的控制平面節點上，作為控制平面的一個元件運作。
每個控制平面節點運作 kube-apiserver，kube-scheduler 和 kube-controller-manager 執行個體。
kube-apiserver 使用 LB 暴露給工作節點。
每個控制平面節點建立一個本地 etcd 成員（member），這個 etcd 成員隻與該節點的 kube-apiserver 通信。這同樣适用于本地 kube-controller-manager 和 kube-scheduler 執行個體。
簡單概況：每個 master 節點上運作一個 apiserver 和 etcd, etcd 隻與本節點 apiserver 通信。
這種拓撲将控制平面和 etcd 成員耦合在同一節點上。相對使用外部 etcd 叢集，設定起來更簡單，而且更易于副本管理。
然而堆疊叢集存在耦合失敗的風險。如果一個節點發生故障，則 etcd 成員和控制平面執行個體都将丢失，并且備援會受到影響。可以通過添加更多控制平面節點來降低此風險。應該為 HA 叢集運作至少三個堆疊的控制平面節點（防止腦裂）。
這是 kubeadm 中的預設拓撲。當使用 kubeadm init 和 kubeadm join --control-plane 時，在控制平面節點上會自動建立本地 etcd 成員。
具有外部 etcd 的 HA 叢集是一種這樣的拓撲，其中 etcd 分布式資料存儲叢集在獨立于控制平面節點的其他節點上運作。
就像堆疊的 etcd 拓撲一樣，外部 etcd 拓撲中的每個控制平面節點都運作 kube-apiserver，kube-scheduler 和 kube-controller-manager 執行個體。
同樣 kube-apiserver 使用負載均衡器暴露給工作節點。但是，etcd 成員在不同的主機上運作，每個 etcd 主機與每個控制平面節點的 kube-apiserver 通信。
簡單概況： etcd 叢集運作在單獨的主機上，每個 etcd 都與 apiserver 節點通信。
這種拓撲結構解耦了控制平面和 etcd 成員。是以，它提供了一種 HA 設定，其中失去控制平面執行個體或者 etcd 成員的影響較小，并且不會像堆疊的 HA 拓撲那樣影響叢集備援。
但是，此拓撲需要兩倍于堆疊 HA 拓撲的主機數量。具有此拓撲的 HA 叢集至少需要三個用于控制平面節點的主機和三個用于 etcd 節點的主機。
需要單獨設定外部 etcd 叢集。
官方這裡主要是解決了高可用場景下 apiserver 與 etcd 叢集的關系，以及控制平面節點防止單點故障。但是叢集對外通路接口不可能将三個 apiserver 都暴露出去，一個節點挂掉時還是不能自動切換到其他節點。官方隻提到了一句“使用負載均衡器将 apiserver 暴露給工作節點”，而這恰恰是部署過程中需要解決的重點問題。
Notes: 此處的負載均衡器并不是 kube-proxy，此處的 Load Balancer 是針對 apiserver 的。
最後，我們總結一下兩種拓撲：
堆疊（Stacked） etcd 拓撲：設定簡單，易于副本管理 ，不過存在耦合失敗風險。如果節點發生故障，則 etcd 成員和控制平面執行個體有丢失的可能，推薦測試開發環境；
外部 etcd 拓撲：解耦了控制平面和 etcd 成員，不會像堆疊的 HA 拓撲那樣有影響叢集備援的風險，不過需要兩倍于堆疊 HA 拓撲的主機數量，設定相對複雜，推薦生産環境。
以下是我們在測試環境所用的部署架構：
這裡采用 kubeadm 方式搭建高可用 k8s 叢集，k8s 叢集的高可用實際是 k8s 各核心元件的高可用，這裡使用主備模式：
apiserver 通過 keepalived+haproxy 實作高可用，當某個節點故障時觸發 keepalived vip 轉移，haproxy 負責将流量負載到 apiserver 節點；
controller-manager k8s 内部通過選舉方式産生上司者(由 --leader-elect 選型控制，預設為 true)，同一時刻叢集内隻有一個 controller-manager 元件運作，其餘處于 backup 狀态；
scheduler k8s 内部通過選舉方式産生上司者(由 --leader-elect 選型控制，預設為 true)，同一時刻叢集内隻有一個scheduler元件運作，其餘處于 backup 狀态；
etcd 通過運作 kubeadm 方式自動建立叢集來實作高可用，部署的節點數為奇數，3節點方式最多容忍一台機器當機。
主機清單：
這裡共有 12 台主機，3 台 control plane，9 台 worker。
haproxy提供高可用性，負載均衡，基于 TCP 和 HTTP 的代理，支援數以萬記的并發連接配接。
haproxy 可安裝在主機上，也可使用 docker 容器實作。文本采用第一種。
建立配置檔案 /etc/haproxy/haproxy.cfg，重要配置以中文注釋标出：
分别在三個 master 節點啟動 haproxy。
keepalived 是以 VRRP(虛拟路由備援協定)協定為基礎, 包括一個 master 和多個 backup。 master 劫持 vip 對外提供服務。master 發送多點傳播，backup 節點收不到 vrrp 包時認為 master 當機，此時選出剩餘優先級最高的節點作為新的 master, 劫持 vip。keepalived 是保證高可用的重要元件。
keepalived 可安裝在主機上，也可使用 docker 容器實作。文本采用第一種。
配置 keepalived.conf, 重要部分以中文注釋标出：
vrrp_script 用于檢測 haproxy 是否正常。如果本機的 haproxy 挂掉，即使 keepalived 劫持vip，也無法将流量負載到 apiserver。
我所查閱的網絡教程全部為檢測程序, 類似 killall -0 haproxy。這種方式用在主機部署上可以，但容器部署時，在 keepalived 容器中無法知道另一個容器 haproxy 的活躍情況，是以我在此處通過檢測端口号來判斷 haproxy 的健康狀況。
weight 可正可負。為正時檢測成功 +weight，相當與節點檢測失敗時本身 priority 不變，但其他檢測成功節點 priority 增加。為負時檢測失敗本身 priority 減少。
另外很多文章中沒有強調 nopreempt 參數，意為不可搶占，此時 master 節點失敗後，backup 節點也不能接管 vip，是以我将此配置删去。
分别在三台節點啟動 keepalived，檢視 keepalived master 日志：
檢視 master vip:
可以看到 vip 已綁定到 keepalived master
下面進行破壞性測試：
暫停 keepalived master 節點 haproxy:
檢視 keepalived k8s-master-1 節點日志:
可以看到 haproxy 檢測失敗，priority 降低，同時另一節點 priority 比 k8s-master-1 節點高， k8s-master-1 置為 backup
檢視 k8s-master-2 節點 keepalived日志：
可以看到 k8s-master-2 被選舉為新的 master。
參考上文 使用 kubeadm 安裝單master kubernetes 叢集（腳本版）
kubeadm.conf 為初始化的配置檔案：
初始化 k8s-master-1：
可以和第一個Master節點一起初始化第二、三個Master節點，也可以從單Master節點調整過來，隻需要：
增加 Master 的 LoadBalancer
将所有節點的 /etc/hosts 檔案中 apiserver.demo 解析為 LoadBalancer 的位址
添加第二、三個Master節點
初始化 master 節點的 token 有效時間為 2 小時
這裡我們示範第一個Master節點初始化2個小時後再初始化：
獲得 join 指令：
則，第二、三個 master 節點的 join 指令如下：
檢查 master 初始化結果:
針對所有的 worker 節點執行:
檢查 worker 初始化結果:
本文資料：
https://github.com/zuozewei/blog-example/tree/master/Kubernetes/k8s-install-HA-cluster
參考資料：
[1]：https://www.kuboard.cn/install/install-kubernetes.html
[2]：https://github.com/loong576/Centos7.6-install-k8s-v1.16.4-HA-cluster
[3]：https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/ha-topology/
[4]：https://www.kubernetes.org.cn/6964.html
點選關注，第一時間了解華為雲新鮮技術~