弹性伸缩主要有三个维度:
- 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 对象。
|
|
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 等与集群版本相关的依赖。同时,提前放开储备区域对资源池的防火墙,还需要一个控制器维护热备池的主机数量。
优点:
- 成本、效率折中
缺点:
- 防火墙会比较开放,可能引入安全问题。如果考虑安全问题,成本又上升了