深圳幻海软件技术有限公司 欢迎您!

集群节点的弹性扩缩

2023-03-20

弹性伸缩主要有三个维度:HPA,根据利用率,自动伸缩Pod数量VPA,根据历史数据,自动设置Pod的Request、LimitCA,根据使用率,自动伸缩Node数量本篇主要讨论的是节点扩缩容部分。1.自动扩缩容组件autoscalerautoscaler是Kubernetes社区维护的项目。目前au

弹性伸缩主要有三个维度:

  • HPA,根据利用率,自动伸缩 Pod 数量
  • VPA,根据历史数据,自动设置 Pod 的 Request、Limit
  • CA,根据使用率,自动伸缩 Node 数量

本篇主要讨论的是节点扩缩容部分。

1. 自动扩缩容组件 autoscaler

autoscaler 是 Kubernetes 社区维护的项目。目前 autoscaler 组件已经提供有 VPA、CA 的伸缩能力。EKS、CCE、ACK、TKE 等主流厂商,都是依赖此组件进行 CA 弹性扩容。没有找到官方数据,但和同事交流时反馈,大约都需要 2-3 分钟完成 CA 扩容。

1.1 VPA 垂直扩缩容

与 HPA 类似,需要为 Deployment 创建一个 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"
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.

VPA 与 HPA 都依赖于 Metrics-server 获取监控指标数据。autoscaler 的 VPA 内置了多种资源设置推荐器,同时对资源设置也可以进行约束。

值得注意的是 VPA 设置的资源值可能会超过命名空间下 limit ranges 的约束。

另外,VPA 与 HPA 不要同时使用。这两种方式有冲突,Pod 数量水平扩缩容和 Pod Limit 垂直扩缩容可能被同时触发。

1.2 CA 节点扩缩容

触发条件:

  • 扩容,节点无法满足 Pod Request 要求而处于 Pending 状态
  • 缩容,节点低负载,并且节点上的 Pod 能移到其他节点

支持厂商:

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

很多厂商都提供 Provider 给组件,autoscaler 采用定期检测的方式,触发厂商扩缩容的接口动作。

另外,CA 与厂商提供的 Node 垂直扩缩容不要同时使用。水平伸缩和垂直伸缩,需要找到一个平衡点,才能协同工作。

2. 云厂托管集群的弹性伸缩

EKS、CCE、ACK、TKE 无一例外都是采用 autoscaler 组件结合自身 IaaS 服务实现节点的弹性伸缩。

由于底层都是采用 autoscaler 组件,在产品层面的呈现也会有所体现。以 EKS 为例,如下图:

EKS 集群,具有若干节点组,每个节点组构成一个弹性伸缩的单元。如下图,节点组最少有 1 个节点,最多有 7 个节点:

EKS 的节点弹性是针对节点组的,同一个节点组下的节点具有相同的机器配置、污点、标签、主机启动模板。当 EKS 判断需要进行节点扩容时,会结合节点组允许的最大节点数,进行扩容。这样也保障扩容出来的节点已经打上正确的污点和标签,能够直接被 Kubernetes 调度器使用。

另外,节点组的概念,在产品和使用层面还可以包装成超级节点。只要节点数量的上限足够大,一个节点组就能提供超大的计算和内存资源池。

3. 节点储备策略

根据使用云厂的程度,可以将集群分为三类:

  • 完全托管,无法直接管理集群内的任一主机,只能使用
  • 半托管,无法管理 master 节点,云厂维护控制面
  • 非托管,基于云厂 IaaS 自己部署的集群,完全自主控制

完全托管的集群,云厂会提供扩缩容的功能。下面主要讨论的是半托管和非托管的集群。

3.1 冷备

需要新节点时,再申请全新机器,初始化配置。

优势:

  • 成本低,按需申请新节点
  • 适配性好,不用考虑集群版本,按需安装依赖
  • 操作简单,使用安装工具提供的能力,通常能够顺利完整扩容
  • 不用考虑可用区、防火墙等问题

缺点:

  • 速度慢,通常得 10 分钟以上,如果依赖源慢,可能需要更长时间
  • 无法标准化,维护的集群不是使用一个工具安装的,或者需要自行封装 Kubeadm

3.2 热备

创建一个热资源池,保持一定的资源数。当需要主机资源时,直接添加到集群。

优势:

  • 速度快

缺点:

  • 成本高,每个集群版本都需要储备节点,1.16、1.20、1.21 等
  • 热备池复杂,不同 IDC、不同 Region、不同 AZ 的节点,网络、防火墙可能不通,导致热备池复杂化

3.3 半热备

创建一个区域化的热备池,开启机器,仅安装 containerd、chrony、conntrack 等基础依赖包,但不要安装 Kubelet 等与集群版本相关的依赖。同时,提前放开储备区域对资源池的防火墙,还需要一个控制器维护热备池的主机数量。

优点:

  • 成本、效率折中

缺点:

  • 防火墙会比较开放,可能引入安全问题。如果考虑安全问题,成本又上升了

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