集群節(jié)點(diǎn)的彈性擴(kuò)縮
彈性伸縮主要有三個(gè)維度：
- HPA，根據(jù)利用率，自動(dòng)伸縮 Pod 數(shù)量
- VPA，根據(jù)歷史數(shù)據(jù)，自動(dòng)設(shè)置 Pod 的 Request、Limit
- CA，根據(jù)使用率，自動(dòng)伸縮 Node 數(shù)量
本篇主要討論的是節(jié)點(diǎn)擴(kuò)縮容部分。
1. 自動(dòng)擴(kuò)縮容組件 autoscaler
autoscaler 是 Kubernetes 社區(qū)維護(hù)的項(xiàng)目。目前 autoscaler 組件已經(jīng)提供有 VPA、CA 的伸縮能力。EKS、CCE、ACK、TKE 等主流廠商，都是依賴此組件進(jìn)行 CA 彈性擴(kuò)容。沒(méi)有找到官方數(shù)據(jù)，但和同事交流時(shí)反饋，大約都需要 2-3 分鐘完成 CA 擴(kuò)容。
1.1 VPA 垂直擴(kuò)縮容
與 HPA 類似，需要為 Deployment 創(chuàng)建一個(gè) VPA 對(duì)象。
VPA 與 HPA 都依賴于 Metrics-server 獲取監(jiān)控指標(biāo)數(shù)據(jù)。autoscaler 的 VPA 內(nèi)置了多種資源設(shè)置推薦器，同時(shí)對(duì)資源設(shè)置也可以進(jìn)行約束。
值得注意的是 VPA 設(shè)置的資源值可能會(huì)超過(guò)命名空間下 limit ranges 的約束。
另外，VPA 與 HPA 不要同時(shí)使用。這兩種方式有沖突，Pod 數(shù)量水平擴(kuò)縮容和 Pod Limit 垂直擴(kuò)縮容可能被同時(shí)觸發(fā)。
1.2 CA 節(jié)點(diǎn)擴(kuò)縮容
觸發(fā)條件:
- 擴(kuò)容，節(jié)點(diǎn)無(wú)法滿足 Pod Request 要求而處于 Pending 狀態(tài)
- 縮容，節(jié)點(diǎn)低負(fù)載，并且節(jié)點(diǎn)上的 Pod 能移到其他節(jié)點(diǎn)
支持廠商:
- alicloud
- aws
- azure
- baiducloud
- gce
- huaweicloud
- linode
- tencentcloud
- ...
很多廠商都提供 Provider 給組件，autoscaler 采用定期檢測(cè)的方式，觸發(fā)廠商擴(kuò)縮容的接口動(dòng)作。
另外，CA 與廠商提供的 Node 垂直擴(kuò)縮容不要同時(shí)使用。水平伸縮和垂直伸縮，需要找到一個(gè)平衡點(diǎn)，才能協(xié)同工作。
2. 云廠托管集群的彈性伸縮
EKS、CCE、ACK、TKE 無(wú)一例外都是采用 autoscaler 組件結(jié)合自身 IaaS 服務(wù)實(shí)現(xiàn)節(jié)點(diǎn)的彈性伸縮。
由于底層都是采用 autoscaler 組件，在產(chǎn)品層面的呈現(xiàn)也會(huì)有所體現(xiàn)。以 EKS 為例，如下圖:
EKS 集群，具有若干節(jié)點(diǎn)組，每個(gè)節(jié)點(diǎn)組構(gòu)成一個(gè)彈性伸縮的單元。如下圖，節(jié)點(diǎn)組最少有 1 個(gè)節(jié)點(diǎn)，最多有 7 個(gè)節(jié)點(diǎn):
EKS 的節(jié)點(diǎn)彈性是針對(duì)節(jié)點(diǎn)組的，同一個(gè)節(jié)點(diǎn)組下的節(jié)點(diǎn)具有相同的機(jī)器配置、污點(diǎn)、標(biāo)簽、主機(jī)啟動(dòng)模板。當(dāng) EKS 判斷需要進(jìn)行節(jié)點(diǎn)擴(kuò)容時(shí)，會(huì)結(jié)合節(jié)點(diǎn)組允許的最大節(jié)點(diǎn)數(shù)，進(jìn)行擴(kuò)容。這樣也保障擴(kuò)容出來(lái)的節(jié)點(diǎn)已經(jīng)打上正確的污點(diǎn)和標(biāo)簽，能夠直接被 Kubernetes 調(diào)度器使用。
另外，節(jié)點(diǎn)組的概念，在產(chǎn)品和使用層面還可以包裝成超級(jí)節(jié)點(diǎn)。只要節(jié)點(diǎn)數(shù)量的上限足夠大，一個(gè)節(jié)點(diǎn)組就能提供超大的計(jì)算和內(nèi)存資源池。
3. 節(jié)點(diǎn)儲(chǔ)備策略
根據(jù)使用云廠的程度，可以將集群分為三類:
- 完全托管，無(wú)法直接管理集群內(nèi)的任一主機(jī)，只能使用
- 半托管，無(wú)法管理 master 節(jié)點(diǎn)，云廠維護(hù)控制面
- 非托管，基于云廠 IaaS 自己部署的集群，完全自主控制
完全托管的集群，云廠會(huì)提供擴(kuò)縮容的功能。下面主要討論的是半托管和非托管的集群。
3.1 冷備
需要新節(jié)點(diǎn)時(shí)，再申請(qǐng)全新機(jī)器，初始化配置。
優(yōu)勢(shì):
- 成本低，按需申請(qǐng)新節(jié)點(diǎn)
- 適配性好，不用考慮集群版本，按需安裝依賴
- 操作簡(jiǎn)單，使用安裝工具提供的能力，通常能夠順利完整擴(kuò)容
- 不用考慮可用區(qū)、防火墻等問(wèn)題
缺點(diǎn):
- 速度慢，通常得 10 分鐘以上，如果依賴源慢，可能需要更長(zhǎng)時(shí)間
- 無(wú)法標(biāo)準(zhǔn)化，維護(hù)的集群不是使用一個(gè)工具安裝的，或者需要自行封裝 Kubeadm
3.2 熱備
創(chuàng)建一個(gè)熱資源池，保持一定的資源數(shù)。當(dāng)需要主機(jī)資源時(shí)，直接添加到集群。
優(yōu)勢(shì):
- 速度快
缺點(diǎn):
- 成本高，每個(gè)集群版本都需要儲(chǔ)備節(jié)點(diǎn)，1.16、1.20、1.21 等
- 熱備池復(fù)雜，不同 IDC、不同 Region、不同 AZ 的節(jié)點(diǎn)，網(wǎng)絡(luò)、防火墻可能不通，導(dǎo)致熱備池復(fù)雜化
3.3 半熱備
創(chuàng)建一個(gè)區(qū)域化的熱備池，開(kāi)啟機(jī)器，僅安裝 containerd、chrony、conntrack 等基礎(chǔ)依賴包，但不要安裝 Kubelet 等與集群版本相關(guān)的依賴。同時(shí)，提前放開(kāi)儲(chǔ)備區(qū)域?qū)Y源池的防火墻，還需要一個(gè)控制器維護(hù)熱備池的主機(jī)數(shù)量。
優(yōu)點(diǎn):
- 成本、效率折中
缺點(diǎn):
- 防火墻會(huì)比較開(kāi)放，可能引入安全問(wèn)題。如果考慮安全問(wèn)題，成本又上升了
4. 參考
- ??https://github.com/kubernetes/autoscaler??
- ??https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/autoscaling.html??
- ??https://support.huaweicloud.com/productdesc-cce/cce_productdesc_0015.html??
- ??https://help.aliyun.com/document_detail/119099.html??
- ??https://cloud.tencent.com/document/product/457/43719??
