微服务应用视角解读如何选择 K8s 的弹性策略

头：潘俊峰

前言

微服务架构的出现，拆分了庞大的单体应用，让业务之间的开发与协作变得更加灵活。当面临业务流量增加的场景时，往往需要对一些应用组件进行扩容。K8s 在应用层面提供了 HPA，围绕 HPA 开源社区延伸出了 KEDA 这样的弹性组件，为微服务应用以业务指标执行弹性策略提供了实现的可能性。但 HPA 正常工作的一个大前提是需要保证集群资源充足，为此用户必须提前对集群扩容或时常保持集群资源冗余。

对于集群资源弹性这一命题，K8s 社区给出了Cluster Autoscaler（CA）和Virtual Kubelet（VK）两种解决方案。本文围绕着微服务应用的形态与特点，剖析了 CA 与 VK 各自适用的场景，并总结了微服务架构下应用该如何选择集群资源弹性。

微服务应用形态与特点

在微服务应用架构，微服务架构将一个庞大的应用系统拆分成了一个个离散的应用组件，这些组件通过 RPC 串在一起，对外提供完整的服务。每个组件是离散的，大部分组件可以通过水平扩缩从而调整服务容量。非核心链路上的组件，是允许延迟扩容或者不扩容，甚至是缩容让出资源。

微服务架构下在弹性场景存在五大特征点：

水平伸缩可以调整系统容量： 在外部资源充足的情况下，微服务应用组件水平扩容可以提升业务系统的容量。
应用间存在依赖关系： 单个微服务应用并不能提供完整的服务，扩容单个微服务组件，对系统容量的提升非常有限，往往需要和依赖的服务一起扩容才能有效提升系统容量。
应用本身是无状态的： 若微服务应用本身有状态，对于水平扩容是不利的，例如对磁盘有强依赖，在扩容场景下需要注意调度亲和性以打散 Pod，避免同类型应用在同一节点对磁盘 IO 抢占，同时缩容时还需要考虑对于状态数据的处理。因此需要尽量改造成无状态应用。
启动速度快且服务上下线流量无损： 服务上下线流量无损对于自动扩缩容场景至关重要，尤其是在大流量高并发场景下扩容，冷启动的新 Pod 很容易被大流量击溃，并且在健康探针的作用下，扩容出的新 Pod 不断被 K8s 重启，最终实现的是无效扩容。
流量具有周期性： 绝大多数微服务架构应用面向的是在线服务，因此可以用二八定律来描述它，即 20% 的时间处理了 80% 的流量。对于业务流量而言，最显著的特征是存在周期性的变化，且往往这个变化是快速的，所以微服务应用容量扩缩的响应速度对于业务系统的稳定起重要作用。

在微服务应用架构中配置应用弹性时，我们所需要考虑的是选择合适的指标来衡量系统容量。在配置集群资源弹性时，我们所需要考虑的是扩容出的计算资源是否能够满足应用所需。

K8s 集群资源弹性技术方案

如前言中所提及，K8s 社区给出了两份“标准答案”的框架，具体的资源弹性实现还依赖云厂商的技术形态与产品能力。

虚拟节点：VK

Virtual Kubelet 是根据 Kubelet 定义提出的一个“虚拟节点”的概念，允许云厂商将云服务包装成一个“虚拟节点”，加入到 Kubernetes 集群中。虚拟节点的背后往往是云厂商的大资源池，因此理论上我们可以认为虚拟节点的资源是无限的，当然实际情况还要以云厂商的规模和产品能力来做判断。

在这里插入图片描述

节点伸缩：CA

Cluster Autoscaler 是 K8s 社区给出的集群节点伸缩方案。CA 监听集群中所有 Pod 事件，当有 Pod 因为资源不足而无法调度时，CA 会根据伸缩组信息进行模拟扩容并调度计算，最后按照预设的节点扩张策略进行真实节点扩容。同时 CA 监听集群整体资源利用率，当利用率低于预设的缩容阈值时，CA 进行模拟缩容调度计算，排除各种影响因素后，CA 对可缩容节点执行打污点、排水、删除这一系列操作。

在这里插入图片描述

各方案特点比对

以 CA 技术形态为主的真实节点伸缩与以 VK 技术形态为主的虚拟节点，这两种主流技术手段有着各自特点，其中最主要的区别如下：

在这里插入图片描述

简而言之，CA 伸缩真实节点以提供完整 K8s 能力，但响应速度较慢；VK 由云厂商资源池驱动，提供了秒级、无限资源的弹性能力，但不存在真实节点，从而失去了部分 K8s 特性。

云厂商解决方案

在 VK 和 CA 这两种主要资源弹性技术方向上，各个云厂商也纷纷推出了对应产品以提供相应的解决方案。

在这里插入图片描述

Serverless 方向主要是 Serverless Instance 与 Serverless Cluster。Serverless Instance 产品有 ECI、Fargate、ACI 这类，以快速、无限资源为显著特点。Serverless Cluster 产品有阿里云的 ASK、谷歌的 GKE Autopilot，由云厂商维护所有集群资源，对用户而言开箱即用免运维。

节点伸缩方向 AWS 还推出了开源组件 Karpenter，它绕过了 CA 中伸缩组的概念，从而让扩缩容时对于资源的选择更加灵活。

资源弹性策略选择与考量因素

对于资源弹性问题，我们首要考虑的是能力。即新的计算资源是否能够满足业务使用需求。以 VK 技术形态为主的弹性方案，受限于架构设计、安全、性能等因素，天然地缺失了节点特性、容器特权等能力。对于有这部分诉求的业务应用应尽可能地进行改造，以移除相关依赖。

其次我们考虑的是成本与效率。对于企业应用而言，成本预算是不可避免的话题，定价规则以及计费模式不同，最终带来的资源成本不同，势必会影响我们对于某项技术的偏好。在当前的 Serverless 场景下，计算资源大体上采用的还是按量计费模式，对于一些长时运行的应用上，采用预付费模式的计算资源是否能达到更节省成本，还需要我们进一步去调研与尝试。成本这一层面不仅包含资源成本，还包含运维成本、团队技术学习成本以及依赖具体云厂商所隐含的迁移成本等等，这些成本在当下可能对企业的收益影响有限，但从企业长远发展角度来看，这一部分不可忽视。同时对于技术团队而言，选择相应技术方案在节约运维成本和降低团队学习成本的同时，需要理性看待这部分成本节省与团队成长所带来的收益之间的关系。

效率是影响业务收益成本的重要因素之一，从流量来袭，到 HPA 根据指标做出响应，再到资源弹性做出动作，最后到应用启动服务上线。这之中每一个环节都存在时间成本，通常情况下这个时间成本越小越好，但也存在一些业务对于时间成本不敏感。对于扩容的每个环节，都延伸出了相应的技术解决方案。如 HPA 被动式响应，阿里云推出了 AHPA 带指标预测的提前扩容能力。如 JAVA 应用启动慢，GraalVM、Alibaba Dragonwell 都在冷启动上做出了一些努力。对于明确业务周期的应用，设置好定时弹性提前扩容，这些问题自然引刃而解。

最后还有一些场景问题需要考虑，对当前应用架构进行升级、迁移、重建时，我们需要把高弹性因素纳入考虑范围，进行合适的技术选型。

综上所述，我们总结了一张资源弹性选择策略图，列举了通用场景下对集群弹性选型时需要考虑的因素点。

在这里插入图片描述

总结

在微服务架构中，我们需要从业务视角梳理与划分应用组件。对于核心链路组件，要尽可能的保证这些组件的健壮性，并调整成一个高可用、高弹性的架构，从而让核心业务长久运行。对于外围链路组件，需要权衡成本与高可用、高弹性带来的效益。

在 K8s 资源弹性问题上，现有技术手段中，我们需要考量兼容性、效率与成本，从而选择合适于自身业务的集群弹性策略。

阿里云的微服务应用托管平台 EDAS 在资源弹性场景下，不仅针对性的对于独享资源型业务虚拟机 ECS 集群，池化资源型业务 K8s 集群，以及全托管免运维的阿里云 Serverless 集群均做了很好的支持；同时基于结合阿里云容器服务和 ECI ，同时提供了针对池化资源 + Serverless Instance 的形态场景支撑，让我们微服务的业务在可以充分利用云技术所带来的技术红利。