彈性伸縮主要有三個維度：

• HPA，根據(jù)利用率，自動伸縮 Pod 數(shù)量
• VPA，根據(jù)歷史數(shù)據(jù)，自動設(shè)置 Pod 的 Request、Limit
• CA，根據(jù)使用率，自動伸縮 Node 數(shù)量

本篇主要討論的是節(jié)點擴縮容部分。

1. 自動擴縮容組件 autoscaler

autoscaler 是 Kubernetes 社區(qū)維護的項目。目前 autoscaler 組件已經(jīng)提供有 VPA、CA 的伸縮能力。EKS、CCE、ACK、TKE 等主流廠商，都是依賴此組件進行 CA 彈性擴容。沒有找到官方數(shù)據(jù)，但和同事交流時反饋，大約都需要 2-3 分鐘完成 CA 擴容。

1.1 VPA 垂直擴縮容

與 HPA 類似，需要為 Deployment 創(chuàng)建一個 VPA 對象。

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 都依賴于 Metrics-server 獲取監(jiān)控指標數(shù)據(jù)。autoscaler 的 VPA 內(nèi)置了多種資源設(shè)置推薦器，同時對資源設(shè)置也可以進行約束。

值得注意的是 VPA 設(shè)置的資源值可能會超過命名空間下 limit ranges 的約束。

另外，VPA 與 HPA 不要同時使用。這兩種方式有沖突，Pod 數(shù)量水平擴縮容和 Pod Limit 垂直擴縮容可能被同時觸發(fā)。

1.2 CA 節(jié)點擴縮容

觸發(fā)條件:

• 擴容，節(jié)點無法滿足 Pod Request 要求而處于 Pending 狀態(tài)
• 縮容，節(jié)點低負載，并且節(jié)點上的 Pod 能移到其他節(jié)點

支持廠商:

• alicloud
• aws
• azure
• baiducloud
• gce
• huaweicloud
• linode
• tencentcloud
• ...

很多廠商都提供 Provider 給組件，autoscaler 采用定期檢測的方式，觸發(fā)廠商擴縮容的接口動作。

另外，CA 與廠商提供的 Node 垂直擴縮容不要同時使用。水平伸縮和垂直伸縮，需要找到一個平衡點，才能協(xié)同工作。

2. 云廠托管集群的彈性伸縮

EKS、CCE、ACK、TKE 無一例外都是采用 autoscaler 組件結(jié)合自身 IaaS 服務(wù)實現(xiàn)節(jié)點的彈性伸縮。

由于底層都是采用 autoscaler 組件，在產(chǎn)品層面的呈現(xiàn)也會有所體現(xiàn)。以 EKS 為例，如下圖:

EKS 集群，具有若干節(jié)點組，每個節(jié)點組構(gòu)成一個彈性伸縮的單元。如下圖，節(jié)點組最少有 1 個節(jié)點，最多有 7 個節(jié)點:

EKS 的節(jié)點彈性是針對節(jié)點組的，同一個節(jié)點組下的節(jié)點具有相同的機器配置、污點、標簽、主機啟動模板。當 EKS 判斷需要進行節(jié)點擴容時，會結(jié)合節(jié)點組允許的最大節(jié)點數(shù)，進行擴容。這樣也保障擴容出來的節(jié)點已經(jīng)打上正確的污點和標簽，能夠直接被 Kubernetes 調(diào)度器使用。

另外，節(jié)點組的概念，在產(chǎn)品和使用層面還可以包裝成超級節(jié)點。只要節(jié)點數(shù)量的上限足夠大，一個節(jié)點組就能提供超大的計算和內(nèi)存資源池。

3. 節(jié)點儲備策略

根據(jù)使用云廠的程度，可以將集群分為三類:

• 完全托管，無法直接管理集群內(nèi)的任一主機，只能使用
• 半托管，無法管理 master 節(jié)點，云廠維護控制面
• 非托管，基于云廠 IaaS 自己部署的集群，完全自主控制

完全托管的集群，云廠會提供擴縮容的功能。下面主要討論的是半托管和非托管的集群。

3.1 冷備

需要新節(jié)點時，再申請全新機器，初始化配置。

優(yōu)勢:

• 成本低，按需申請新節(jié)點
• 適配性好，不用考慮集群版本，按需安裝依賴
• 操作簡單，使用安裝工具提供的能力，通常能夠順利完整擴容
• 不用考慮可用區(qū)、防火墻等問題

缺點:

• 速度慢，通常得 10 分鐘以上，如果依賴源慢，可能需要更長時間
• 無法標準化，維護的集群不是使用一個工具安裝的，或者需要自行封裝 Kubeadm

3.2 熱備

創(chuàng)建一個熱資源池，保持一定的資源數(shù)。當需要主機資源時，直接添加到集群。

優(yōu)勢:

• 速度快

缺點:

• 成本高，每個集群版本都需要儲備節(jié)點，1.16、1.20、1.21 等
• 熱備池復雜，不同 IDC、不同 Region、不同 AZ 的節(jié)點，網(wǎng)絡(luò)、防火墻可能不通，導致熱備池復雜化

3.3 半熱備

創(chuàng)建一個區(qū)域化的熱備池，開啟機器，僅安裝 containerd、chrony、conntrack 等基礎(chǔ)依賴包，但不要安裝 Kubelet 等與集群版本相關(guān)的依賴。同時，提前放開儲備區(qū)域?qū)Y源池的防火墻，還需要一個控制器維護熱備池的主機數(shù)量。

優(yōu)點:

• 成本、效率折中

缺點:

• 防火墻會比較開放，可能引入安全問題。如果考慮安全問題，成本又上升了

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??