集群节点的弹性扩缩

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

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

  • 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"

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. 参考

责任编辑:武晓燕 来源: 陈少文
相关推荐

2021-01-28 10:36:09

Redis扩缩容架构

2022-12-30 08:37:25

Kubernetes垂直水平

2018-12-05 10:40:54

MySQL架构分布式

2021-12-23 17:34:23

腾讯云TDSQL数据库

2014-07-01 09:53:21

DockerHadoop集群

2016-09-28 15:02:39

数据库防火墙高性能

2021-07-15 10:25:15

集群节点检查

2020-07-06 07:52:10

Kubernetes网络通信

2019-09-03 16:18:03

Vagran虚拟机集群

2022-08-28 19:36:15

数据分片KafkaRocketMQ

2011-11-17 08:58:37

TD-LTE

2022-09-15 08:04:54

k8skubernetes

2015-05-27 10:29:41

DockerHadoopHadoop集群

2022-02-25 08:02:41

集群ceph16集群恢复

2022-08-01 07:47:03

虚拟化容器Pod

2020-03-02 16:59:58

数据恢复微盟删库

2022-05-19 17:50:31

bookie集群延迟消息存储服务
点赞
收藏

51CTO技术栈公众号