介紹
在上一期HA k8s搭建介紹有說(shuō)到,目前有兩種比較火的HA集群,那么今天我們來(lái)說(shuō)說(shuō)第二種,也是目前比較主流的部署方式,采用的是haproxy+keepalived+etcd+k8s的模式,和第一種集群相比較多了有個(gè)haproxy,它是干嘛的呢,下面是它的大概簡(jiǎn)介
HAProxy簡(jiǎn)介
(1)HAProxy 是一款提供高可用性、負(fù)載均衡以及基于TCP(第四層)和HTTP(第七層)應(yīng)用的代理軟件,支持虛擬主機(jī),它是免費(fèi)、快速并且可靠的一種解決方案。 HAProxy特別適用于那些負(fù)載特大的web站點(diǎn),這些站點(diǎn)通常又需要會(huì)話保持或七層處理。HAProxy運(yùn)行在時(shí)下的硬件上,完全可以支持?jǐn)?shù)以萬(wàn)計(jì)的 并發(fā)連接。并且它的運(yùn)行模式使得它可以很簡(jiǎn)單安全的整合進(jìn)您當(dāng)前的架構(gòu)中, 同時(shí)可以保護(hù)你的web服務(wù)器不被暴露到網(wǎng)絡(luò)上。
(2)HAProxy 實(shí)現(xiàn)了一種事件驅(qū)動(dòng)、單一進(jìn)程模型,此模型支持非常大的并發(fā)連接數(shù)。多進(jìn)程或多線程模型受內(nèi)存限制 、系統(tǒng)調(diào)度器限制以及無(wú)處不在的鎖限制,很少能處理數(shù)千并發(fā)連接。事件驅(qū)動(dòng)模型因?yàn)樵谟懈玫馁Y源和時(shí)間管理的用戶端(User-Space) 實(shí)現(xiàn)所有這些任務(wù),所以沒(méi)有這些問(wèn)題。此模型的弊端是,在多核系統(tǒng)上,這些程序通常擴(kuò)展性較差。這就是為什么他們必須進(jìn)行優(yōu)化以 使每個(gè)CPU時(shí)間片(Cycle)做更多的工作。
(3)HAProxy 支持連接拒絕 : 因?yàn)榫S護(hù)一個(gè)連接的打開(kāi)的開(kāi)銷是很低的,有時(shí)我們很需要限制攻擊蠕蟲(chóng)(attack bots),也就是說(shuō)限制它們的連接打開(kāi)從而限制它們的危害。 這個(gè)已經(jīng)為一個(gè)陷于小型DDoS攻擊的網(wǎng)站開(kāi)發(fā)了而且已經(jīng)拯救
了很多站點(diǎn),這個(gè)優(yōu)點(diǎn)也是其它負(fù)載均衡器沒(méi)有的。
(4)HAProxy 支持全透明代理(已具備硬件防火墻的典型特點(diǎn)): 可以用客戶端IP地址或者任何其他地址來(lái)連接后端服務(wù)器. 這個(gè)特性僅在Linux?2.4/2.6內(nèi)核打了cttproxy補(bǔ)丁后才可以使用. 這個(gè)特性也使得為某特殊服務(wù)器處理部分流量同時(shí)又不修改服務(wù)器的地址成為可能。
性能
HAProxy借助于OS上幾種常見(jiàn)的技術(shù)來(lái)實(shí)現(xiàn)性能的最大化。
1,單進(jìn)程、事件驅(qū)動(dòng)模型顯著降低了上下文切換的開(kāi)銷及內(nèi)存占用。
2,O(1)事件檢查器(event checker)允許其在高并發(fā)連接中對(duì)任何連接的任何事件實(shí)現(xiàn)即時(shí)探測(cè)。
3,在任何可用的情況下,單緩沖(single buffering)機(jī)制能以不復(fù)制任何數(shù)據(jù)的方式完成讀寫操作,這會(huì)節(jié)約大量的CPU時(shí)鐘周期及內(nèi)存帶寬;
4,借助于Linux 2.6 (>= 2.6.27.19)上的splice()系統(tǒng)調(diào)用,HAProxy可以實(shí)現(xiàn)零復(fù)制轉(zhuǎn)發(fā)(Zero-copy forwarding),在Linux 3.5及以上的OS中還可以實(shí)現(xiàn)零復(fù)制啟動(dòng)(zero-starting);
5,內(nèi)存分配器在固定大小的內(nèi)存池中可實(shí)現(xiàn)即時(shí)內(nèi)存分配,這能夠顯著減少創(chuàng)建一個(gè)會(huì)話的時(shí)長(zhǎng);
6,樹(shù)型存儲(chǔ):側(cè)重于使用作者多年前開(kāi)發(fā)的彈性二叉樹(shù),實(shí)現(xiàn)了以O(shè)(log(N))的低開(kāi)銷來(lái)保持計(jì)時(shí)器命令、保持運(yùn)行隊(duì)列命令及管理輪詢及最少連接隊(duì)列;
7,優(yōu)化的HTTP首部分析:優(yōu)化的首部分析功能避免了在HTTP首部分析過(guò)程中重讀任何內(nèi)存區(qū)域;
8,精心地降低了昂貴的系統(tǒng)調(diào)用,大部分工作都在用戶空間完成,如時(shí)間讀取、緩沖聚合及文件描述符的啟用和禁用等;
所有的這些細(xì)微之處的優(yōu)化實(shí)現(xiàn)了在中等規(guī)模負(fù)載之上依然有著相當(dāng)?shù)偷腃PU負(fù)載,甚至于在非常高的負(fù)載場(chǎng)景中,5%的用戶空間占用率和95%的系統(tǒng)空間占用率也是非常普遍的現(xiàn)象,這意味著HAProxy進(jìn)程消耗比系統(tǒng)空間消耗低20倍以上。因此,對(duì)OS進(jìn)行性能調(diào)優(yōu)是非常重要的。即使用戶空間的占用率提高一倍,其CPU占用率也僅為10%,這也解釋了為何7層處理對(duì)性能影響有限這一現(xiàn)象。由此,在高端系統(tǒng)上HAProxy的7層性能可輕易超過(guò)硬件負(fù)載均衡設(shè)備。
在生產(chǎn)環(huán)境中,在7層處理上使用HAProxy作為昂貴的高端硬件負(fù)載均衡設(shè)備故障故障時(shí)的緊急解決方案也時(shí)長(zhǎng)可見(jiàn)。硬件負(fù)載均衡設(shè)備在“報(bào)文”級(jí)別處理請(qǐng)求,這在支持跨報(bào)文請(qǐng)求(request across multiple packets)有著較高的難度,并且它們不緩沖任何數(shù)據(jù),因此有著較長(zhǎng)的響應(yīng)時(shí)間。對(duì)應(yīng)地,軟件負(fù)載均衡設(shè)備使用TCP緩沖,可建立極長(zhǎng)的請(qǐng)求,且有著較大的響應(yīng)時(shí)間。
????????????????????????????????????????????????????????????????????????摘抄至HAProxy用法詳解 全網(wǎng)最詳細(xì)中文文檔
一般情況下haproxy會(huì)和keepalived一起使用。
老規(guī)矩,下面附上k8s理想的高可用架構(gòu)圖。

那在本文中,我們的k8s架構(gòu)應(yīng)該是怎么樣的呢,我從網(wǎng)上找到了一個(gè)非常符合我們整個(gè)K8S HA架構(gòu)的圖,然后稍微做了修改。本文大致高可用架構(gòu)圖如下

在原圖中使用的是Nginx作為負(fù)載均衡,而我們本文中則使用的是haproxy。好了下面開(kāi)始目前主流的k8s架構(gòu)搭建
主機(jī)節(jié)點(diǎn)清單
主機(jī)名IP地址說(shuō)明組件,如果是沒(méi)搭建過(guò)k8s集群的,需要先看看我之前寫的初階k8s集群搭建,需要安裝的一些軟件和容器鏡像。
master1節(jié)點(diǎn) 192.168.100.1 4核4G內(nèi)存?
keepalived、haproxy、etcd、kubelet、kube-apiserver、kube-scheduler、kube-proxy、kube-dashboard、heapster
master2節(jié)點(diǎn) 192.168.100.2 ?4核4G內(nèi)存?
keepalived、haproxy、etcd、kubelet、kube-apiserver、kube-scheduler、kube-proxy、kube-dashboard、heapster
master3節(jié)點(diǎn) 192.168.100.3?4核4G內(nèi)存?
keepalived、haproxy、etcd、kubelet、kube-apiserver、kube-scheduler、kube-proxy、kube-dashboard、heapster
vip 192.168.100.4 keepalived?4核4G內(nèi)存?
在每個(gè)master節(jié)點(diǎn)上設(shè)置好hostname 、hosts
192.168.100.1 master1
192.168.100.2?master2
192.168.100.3?master3
由于本次安裝全部容器化部署,因此部署過(guò)程相對(duì)比較簡(jiǎn)單。
ECTD部署
在每個(gè)master節(jié)點(diǎn)上
先拉取最新的etcd官方鏡像,這可能需要翻墻,童鞋們可以改下阿里云的加速鏡像地址,這里就不做多概述了,官方最新的etcd鏡像版本對(duì)應(yīng)常規(guī)版的etcd是3.2.17版本
docker pull?quay.io/coreos/etcd
docker tag?quay.io/coreos/etcd?quay.io/coreos/etcd:3.2.17
新建一個(gè)etcd數(shù)據(jù)存儲(chǔ)路徑,下面只是例子,童鞋們自行修改
mkdir /u03/etcd_docker?
master1
docker run -d \
--restart always \
-v /etc/etcd/ssl/certs:/etc/ssl/certs \
-v /u03/etcd_docker:/var/lib/etcd \
-p 2380:2380 \
-p 2379:2379 \
--name etcd \
quay.io/coreos/etcd:3.2.17 \
etcd --name=master1 \
--advertise-client-urls=http://192.168.100.1:2379 \
--listen-client-urls=http://0.0.0.0:2379 \
--initial-advertise-peer-urls=http://192.168.100.1:2380 \
--listen-peer-urls=http://0.0.0.0:2380 \
--initial-cluster-token=etcd-cluster-0 \
--initial-cluster=master1=http://192.168.100.1:2380,master2=http://192.168.100.2:2380,master3=http://192.168.100.3:2380 \
--initial-cluster-state=new \
--auto-tls \
--peer-auto-tls \
--data-dir=/var/lib/etcd
master2
docker run -d \
--restart always \
-v /etc/etcd/ssl/certs:/etc/ssl/certs \
-v /u03/etcd_docker:/var/lib/etcd \
-p 2380:2380 \
-p 2379:2379 \
--name etcd \
quay.io/coreos/etcd:3.2.17 \
etcd --name=master2 \
--advertise-client-urls=http://192.168.100.2:2379 \
--listen-client-urls=http://0.0.0.0:2379 \
--initial-advertise-peer-urls=http://192.168.100.2:2380 \
--listen-peer-urls=http://0.0.0.0:2380 \
--initial-cluster-token=etcd-cluster-0 \
--initial-cluster=master1=http://192.168.100.1:2380,master2=http://192.168.100.2:2380,master3=http://192.168.100.3:2380 \
--initial-cluster-state=new \
--auto-tls \
--peer-auto-tls \
--data-dir=/var/lib/etcd
master3
docker run -d \
--restart always \
-v /etc/etcd/ssl/certs:/etc/ssl/certs \
-v /u03/etcd_docker:/var/lib/etcd \
-p 2380:2380 \
-p 2379:2379 \
--name etcd \
quay.io/coreos/etcd:3.2.17 \
etcd --name=master3 \
--advertise-client-urls=http://192.168.100.3:2379 \
--listen-client-urls=http://0.0.0.0:2379 \
--initial-advertise-peer-urls=http://192.168.100.3:2380 \
--listen-peer-urls=http://0.0.0.0:2380 \
--initial-cluster-token=etcd-cluster-0 \
--initial-cluster=master1=http://192.168.100.1:2380,master2=http://192.168.100.2:2380,master3=http://192.168.100.3:2380 \
--initial-cluster-state=new \
--auto-tls \
--peer-auto-tls \
--data-dir=/var/lib/etcd
這樣在三臺(tái)節(jié)點(diǎn)上完成ETCD集群的部署,在這里沒(méi)有使用https,是因?yàn)橄牒?jiǎn)化部署過(guò)程,也不需要涉及到外部網(wǎng)絡(luò),如果有安全認(rèn)證方面的需求可以按照我上一篇高階k8s HA 集群搭建(一)里搭建etcd集群的方式,照葫蘆畫瓢。
如果在部署過(guò)程中出現(xiàn)問(wèn)題,etcd容器沒(méi)有啟動(dòng)或者一直再重啟則通過(guò)docker ps -a查看容器id,通過(guò)docker logs?CONTAINER ID來(lái)排查問(wèn)題。
驗(yàn)證方式:
1.如果你安裝了etcdctl則
etcdctl --endpoints=http://192.168.100.1:2379,http://192.168.100.2:2379,http://192.168.100.3:2379 \
cluster-health
etcdctl --endpoints=http://192.168.100.1:2379,http://192.168.100.2:2379,http://192.168.100.3:2379 \
member list
2.直接到etcd容器里驗(yàn)證
docker exec -ti etcd ash
etcdctl member list
etcdctl cluster-health
exit
keepalived
在每個(gè)master節(jié)點(diǎn)上執(zhí)行
拉取keepalived鏡像
docker pull osixia/keepalived:1.4.4
載入內(nèi)核相關(guān)模塊
lsmod | grep ip_vs
modprobe ip_vs
部署keepalived
docker run --net=host --cap-add=NET_ADMIN \
-e KEEPALIVED_INTERFACE=eno16780032 \
-e KEEPALIVED_VIRTUAL_IPS="#PYTHON2BASH:['192.168.100.4']" \
-e KEEPALIVED_UNICAST_PEERS="#PYTHON2BASH:['192.168.100.1','192.168.100.2','192.168.100.3']" \
-e KEEPALIVED_PASSWORD=admin \
--name k8s-keepalived \
--restart always \
-d?osixia/keepalived:1.4.4
其中KEEPALIVED_INTERFACE填的是192.168.100.0/24網(wǎng)段所在的網(wǎng)卡,可以通過(guò)ip a命令來(lái)查看。KEEPALIVED_VIRTUAL_IPS設(shè)置的是需要用到的vip。
三臺(tái)master節(jié)點(diǎn)部署完成后通過(guò)ping?192.168.100.4的方式驗(yàn)證是否通,或者直接ip a查看第一臺(tái)部署的master,網(wǎng)卡上是不是多了一個(gè)ip。
如果出現(xiàn)問(wèn)題,也可以通過(guò)docker logs k8s-keepalived來(lái)調(diào)試。
如果失敗后清理,重新部署
docker rm -f k8s-keepalived
haproxy
在每個(gè)master上執(zhí)行
拉取haproxy鏡像
docker pull haproxy:1.7.8-alpine
創(chuàng)建haproxy配置文件夾
mkdir /etc/haproxy
創(chuàng)建haproxy配置
cat >/etc/haproxy/haproxy.cfg<<EOF
global
? log 127.0.0.1 local0 err
? maxconn 50000
? uid 99
? gid 99
? #daemon
? nbproc 1
? pidfile haproxy.pid
defaults
? mode http
? log 127.0.0.1 local0 err
? maxconn 50000
? retries 3
? timeout connect 5s
? timeout client 30s
? timeout server 30s
? timeout check 2s
listen admin_stats
? mode http
? bind 0.0.0.0:1080
? log 127.0.0.1 local0 err
? stats refresh 30s
? stats uri? ? /haproxy-status
? stats realm? Haproxy\ Statistics
? stats auth ? ?admin:admin
? stats hide-version
? stats admin if TRUE
frontend k8s-https
? bind 0.0.0.0:8443
? mode tcp
? #maxconn 50000
? default_backend k8s-https
backend k8s-https
? mode tcp
? balance roundrobin
? server master1 192.168.100.1:6443 weight 1 maxconn 1000 check inter 2000 rise 2 fall 3
? server master1 192.168.100.2:6443 weight 1 maxconn 1000 check inter 2000 rise 2 fall 3
? server master1 192.168.100.3:6443 weight 1 maxconn 1000 check inter 2000 rise 2 fall 3
EOF
啟動(dòng)haproxy
docker run -d --name my-haproxy \
-v /etc/haproxy:/usr/local/etc/haproxy:ro \
-p 8443:8443 \
-p 1080:1080 \
--restart always \
haproxy:1.7.8-alpine
驗(yàn)證
瀏覽器查看狀態(tài)
http://192.168.100.1:1080/haproxy-status
http://192.168.100.2:1080/haproxy-status
http://192.168.100.3:1080/haproxy-status
master節(jié)點(diǎn)初始化
ps:首先需要將相關(guān)軟件安裝一下,k8s相關(guān)的組件和鏡像
在第一臺(tái)master上創(chuàng)建新的token并記?。ㄒ粫?huì)兒都要用到)
kubeadm token generate
制作配置文件
vim config.yaml
apiVersion: kubeadm.k8s.io/v1alpha1
kind: MasterConfiguration
kubeProxy:
? config:
? ? featureGates:
? ? ? SupportIPVSProxyMode: true
? ? mode: ipvs
etcd:
? endpoints:
? - http://192.168.100.1:2379
? - http://192.168.100.2:2379
? - http://192.168.100.3:2379
? dataDir: /u03/etcd_docker
networking:
? serviceSubnet: 10.96.0.0/12
? podSubnet: 10.244.0.0/16
kubernetesVersion: 1.10.0
api:
? advertiseAddress: "192.168.100.1" #每個(gè)節(jié)點(diǎn)的ip
apiServerExtraArgs:
? endpoint-reconciler-type: lease
controllerManagerExtraArgs:
? node-monitor-grace-period: 10s
? pod-eviction-timeout: 10s
apiServerCertSANs:
- master1
-?master2
-?master3
-?192.168.100.1
-?192.168.100.2
-?192.168.100.3
-?192.168.100.4
token: hpobow.vw1g1ya5dre7sq06 #之前生成的token
tokenTTL: "0"?#token失效時(shí)間,0表示永不失效
featureGates:
? CoreDNS: true
我們使用CoreDNS作為k8s內(nèi)部網(wǎng)絡(luò)域名解析,使用ipvs做proxy內(nèi)網(wǎng)負(fù)載均衡
kubeadm init --config?config.yaml?
systemctl enable kubelet
保存初始化完成之后的join命令
如果丟失可以使用命令"kubeadm token list"獲取
# kubeadm join 192.168.100.1:6443 --token hpobow.vw1g1ya5dre7sq06 --discovery-token-ca-cert-hash sha256:0e4f738348be836ff810bce754e059054845f44f01619a37b817eba83282d80f
配置kubectl使用
mkdir -p$HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf$HOME/.kube/config
sudo chown $(id -u):$(id -g)$HOME/.kube/config
或者root 用戶可以直接
echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bash_profile
source ~/.bash_profile
安裝網(wǎng)絡(luò)插件(只用安裝一次)
下載配置
部署網(wǎng)絡(luò)插件我們這里使用canal,既Calico的策略+flannel的網(wǎng)絡(luò),因?yàn)樵贑alico目前還沒(méi)有很好的支持ipvs
https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/flannel
kubectl apply -f \
https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/canal/rbac.yaml
kubectl apply -f \
https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/canal/canal.yaml
由于canal一些組件需要翻墻,先wget?https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/canal/canal.yaml 下來(lái),單獨(dú)下載里面的鏡像,再部署
如果Node有多個(gè)網(wǎng)卡的話,參考flannel issues 39701,
https://github.com/kubernetes/kubernetes/issues/39701
需要在canal.yaml中使用--iface參數(shù)指定集群主機(jī)內(nèi)網(wǎng)網(wǎng)卡的名稱,
否則可能會(huì)出現(xiàn)dns無(wú)法解析。容器無(wú)法通信的情況,需要將canal.yaml下載到本地
修改如下,網(wǎng)卡名稱通過(guò)ip a自行查看
- name: kube-flannel
? ? ? ? ? image: quay.io/coreos/flannel:v0.9.1
? ? ? ? ? command: [ "/opt/bin/flanneld", "--ip-masq", "--kube-subnet-mgr", "--iface=eno16780032"?]
查看系統(tǒng)組件運(yùn)行狀況
kubectl get pods --namespace kube-system
kubectl get svc --namespace kube-system
kubectl get nodes
在另外兩臺(tái)master節(jié)點(diǎn)上初始化
將在master1 的kubeadm生成證書(shū)密碼文件分發(fā)到master2和master3上面去
scp -r /etc/kubernetes/pki master2:/etc/kubernetes/
scp -r /etc/kubernetes/pki master3:/etc/kubernetes/
生成配置文件
使用和之前master1一樣的配置文件
token保持一致
制作配置文件
vim config.yaml
apiVersion: kubeadm.k8s.io/v1alpha1
kind: MasterConfiguration
kubeProxy:
? config:
? ? featureGates:
? ? ? SupportIPVSProxyMode: true
? ? mode: ipvs
etcd:
? endpoints:
? - http://192.168.100.1:2379
? - http://192.168.100.2:2379
? - http://192.168.100.3:2379
? dataDir: /u03/etcd_docker
networking:
? serviceSubnet: 10.96.0.0/12
? podSubnet: 10.244.0.0/16
kubernetesVersion: 1.10.0
api:
? advertiseAddress: "192.168.100.2" #每個(gè)節(jié)點(diǎn)的ip
apiServerExtraArgs:
? endpoint-reconciler-type: lease
controllerManagerExtraArgs:
? node-monitor-grace-period: 10s
? pod-eviction-timeout: 10s
apiServerCertSANs:
- master1
-?master2
-?master3
-?192.168.100.1
-?192.168.100.2
-?192.168.100.3
-?192.168.100.4
token: hpobow.vw1g1ya5dre7sq06 #之前生成的token
tokenTTL: "0"?#token失效時(shí)間,0表示永不失效
featureGates:
? CoreDNS: true
執(zhí)行初始化
kubeadm init --config config.yaml
systemctl enable kubelet
保存初始化完成之后的join命令(方便工作節(jié)點(diǎn)加入)
等另外兩臺(tái)master部署完成之后
驗(yàn)證
查看狀態(tài)
kubectl get pod --all-namespaces -o wide | grep master1
kubectl get pod --all-namespaces -o wide | grep?master2
kubectl get pod --all-namespaces -o wide | grep?master3
kubectl get nodes -o wide
修改master節(jié)點(diǎn)相關(guān)組件配置指向vip(每一臺(tái)master都要執(zhí)行)
sed -i's@server: https://192.168.100.*:6443@server: https://192.168.100.4:8443@g'/etc/kubernetes/{admin.conf,kubelet.conf,scheduler.conf,controller-manager.conf}
重啟kubelet
systemctl daemon-reload
systemctl restart kubelet docker
查看所有節(jié)點(diǎn)狀態(tài)
kubectl get nodes -o wide
修改kube-proxy的配置
修改kube-proxy的配置指定vip
執(zhí)行命令
kubectl edit -n kube-system configmap/kube-proxy
將server修改為server: https://192.168.100.4:8443并保存
查看設(shè)置
kubectl get -n kube-system configmap/kube-proxy -o yaml
刪除重建kube-proxy
kubectl get pods --all-namespaces -o wide | grep proxy
all_proxy_pods=$(kubectl get pods --all-namespaces -o wide | grep proxy | awk'{print $2}'| xargs)
echo$all_proxy_pods
kubectl delete pods$all_proxy_pods-n kube-system
kubectl get pods --all-namespaces -o wide | grep proxy
這樣三臺(tái)HA master節(jié)點(diǎn)就搭建完成了
*工作節(jié)點(diǎn)
工作節(jié)點(diǎn)需要用到剛剛的kubeadm join命令添加
kubeadm join 192.168.100.4:8443 --token hpobow.vw1g1ya5dre7sq06 --discovery-token-ca-cert-hash sha256:0e4f738348be836ff810bce754e059054845f44f01619a37b817eba83282d80f
systemctl enable kubelet
需要的軟件參考我的第一篇k8s集群搭建
修改工作節(jié)點(diǎn)kubelet配置并重啟
sed -i's@server: https://192.168.100.*:6443@server: https://192.168.100.4:8443@g'/etc/kubernetes/kubelet.conf
重啟kubelet
systemctl daemon-reload
systemctl restart kubelet docker
查看所有節(jié)點(diǎn)狀態(tài)
kubectl get nodes -o wide
這樣高可用集群就搭建完成了。這樣的master節(jié)點(diǎn)相對(duì)于第一種高可用的方式多了haproxy負(fù)載均衡,通過(guò)負(fù)載均衡將三臺(tái)master apiserver調(diào)用起來(lái),實(shí)現(xiàn)資源高可用。
本文大量照搬了以下的文獻(xiàn)并做了一些自己的修改