彈性伸縮主要有三個(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 等主流廠商，都是依賴(lài)此組件進(jìn)行 CA 彈性擴(kuò)容。沒(méi)有找到官方數(shù)據(jù)，但和同事交流時(shí)反饋，大約都需要 2-3 分鐘完成 CA 擴(kuò)容。

1.1 VPA 垂直擴(kuò)縮容

與 HPA 類(lèi)似，需要為 Deployment 創(chuàng)建一個(gè) VPA 對(duì)象。

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
    name:       my-app
  updatePolicy:
    updateMode: "Auto"

VPA 與 HPA 都依賴(lài)于 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ú)法滿(mǎn)足 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ù)使用云廠的程度，可以將集群分為三類(lèi):

• 完全托管，無(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)
• 適配性好，不用考慮集群版本，按需安裝依賴(lài)
• 操作簡(jiǎn)單，使用安裝工具提供的能力，通常能夠順利完整擴(kuò)容
• 不用考慮可用區(qū)、防火墻等問(wèn)題

缺點(diǎn):

• 速度慢，通常得 10 分鐘以上，如果依賴(lài)源慢，可能需要更長(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ǔ)依賴(lài)包，但不要安裝 Kubelet 等與集群版本相關(guān)的依賴(lài)。同時(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??