关于阿里云:微服务应用视角解读如何选择-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 的状态场景撑持，让咱们微服务的业务在能够充分利用云技术所带来的技术红利。