全部产品

节点伸缩介绍

更新时间:2020-09-23 19:20:32

随着云计算的不断发展,应用的承载方式经历了 物理机 > 虚拟机 > 容器 > 无服务器 不断快速的转变,部署密度越来越高,应用运维的方式也在不断演进,越来越多的应用会以弹性的方式来申请物理资源,让用户越来越少地关心物理资源。那么随着应用的弹性扩缩容越来越频繁,对物理资源的日常需求变化也会越来越大,对物理资源的弹性需求也就越来越迫切。

AKS 的节点弹性伸缩是基于社区 Cluster Autoscaler 演变而来,为 Kubernetes 管理的集群提供节点弹性的能力,通过自动的扩缩容来维持集群水位在指定范围内,从而应对应用逐渐弹性化和 serverless 化。本文介绍如何通过节点弹性伸缩来做集群水位管理,并在生产环境落地。

说明:本文仅适用于旧版 AKS 集群场景,即在 AKS 集成阿里云容器服务(ACK)之前(2020年8月15号)用户创建的集群。新版 ACK 集群场景暂不支持节点伸缩功能。

社区 Cluster Autoscaler 相关技术介绍

社区 Cluster Autoscaler

如图所示,社区 Cluster Autoscaler 扩缩容是基于应用 Pod 调度资源不足来触发扩容,当集群中存在 pending Pod,则会从预先定义的节点组中通过预调度算法和资源评估算法筛选出具体的节点组以及对应节点组所需扩容的节点数量从而触发扩容,而缩容则会根据每个节点的资源使用率是否低于缩容阈值来评估是否需要进行缩容。

然而,节点伸缩无法通过简单识别集群水位是否大于预设的水位上限来触发扩容,因为集群有多种规格的节点,通过简单识别集群水位是否大于预设上限,能够判断集群是否需要扩容,但却无法确定需要扩容的节点规格。

因此,社区 Cluster Autoscaler 中采用的基于 pending Pod 策略的扩容方式,导致只能配置缩容阈值,也就是集群水位下限,却无法配置集群水位上限,并不具备完备的集群水位管理能力。同时,由于扩容是根据应用 Pod 在调度时资源不足触发计算并筛选出需要扩容的节点组和节点数量,该方法需要等到应用 Pod 都处于调度资源不足时再触发扩容,导致业务应用需等待很长时间才能调度成功。

总结一下,社区 Cluster Autoscaler 存在以下不足:

  • 无法配置集群水位上限。
  • 对于资源不足导致触发扩容的应用来说,需要等待非常长的时间才能调度成功,对于业务来说难以接受。
  • 没有较强的业务灰度迁移能力,对于业务从原有节点迁移至弹性节点不方便也不安全。

集群水位管理(Cluster Level Management)

为了解决社区 Cluster Autoscaler 中的问题,蚂蚁金服设计了一套允许配置集群的水位上下限的集群水位管理方案,集群在不断创建删除应用 Pod 过程中通过自动扩容和缩容节点,使得集群的水位始终维持在该范围内,同时通过友好的产品化方式帮助用户理解和使用集群水位管理功能。

首先,引入预留水位概念来完成集群水位上限功能,即当配置水位上限为 80% 时,则会将 20% 设定为预留水位,该部分资源不用于容纳业务 Pod,其中当预留水位配置为 0% 时,则运行效果类似社区模式。

其次,通过节点的提前扩容实现业务应用快速调度成功。通过预先使用低优先级的占位 Pod 占满预留水位的资源,利用 Kubernetes 的抢占式调度能力,当业务容器出现资源不足时优先剔除预留水位中的占位 Pod,此时业务 Pod 就能正常调度成功,而被剔除的占位 Pod 会由于没有额外的资源可以调度会处于 pending 状态,从而触发集群节点的扩容。

扩容流程如下图:

CA扩容

缩容流程如下图:

CA 缩容流程

子集群模型

由于有些业务需要稳定可靠地运行在稳定的节点中,有些业务需要根据实际情况逐步迁移至弹性节点中,同时也为了能够更安全可靠地在生产环境使用节点弹性能力,需要允许集群中既存在非弹性节点也能存在弹性节点,两者之间做好节点隔离且资源配比由集群管理人员控制,AKS 通过引入子集群的概念来满足这一需求,业务应用通过在发布时指定是否发布至弹性子集群来选择是否使用节点弹性能力。

子集群是集群内部抽象出来弱隔离的模型概念,主要用于隔离节点资源。同时,为了在引入子集群概念时不增加整个集群的管理成本,AKS 通过增强调度器来支持子集群能力,给需要发布到弹性节点上的 Pod 带上特定的 label cafe.sofastack.io/sub-cluster=default,这样既允许某些应用只安装到特定子集群,又允许某些系统应用安装到整个集群中。

subcluster