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

本文涉及的产品
MSE Nacos/ZooKeeper 企业版试用,1600元额度,限量50份
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,182元/月
简介: 微服务架构的出现,拆分了庞大的单体应用,让业务之间的开发与协作变得更加灵活。当面临业务流量增加的场景时,往往需要对一些应用组件进行扩容。K8S在应用层面提供了HPA,围绕HPA开源社区延伸出了KEDA这样的弹性组件,为微服务应用以业务指标执行弹性策略提供了实现的可能性。但HPA正常工作的一个大前提是需要保证集群资源充足,为此用户必须提前对集群扩容或时常保持集群资源冗余。本文中就会详细的为你解读一下。

前言


微服务架构的出现,拆分了庞大的单体应用,让业务之间的开发与协作变得更加灵活。当面临业务流量增加的场景时,往往需要对一些应用组件进行扩容。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集群中。虚拟节点的背后往往是云厂商的大资源池,因此理论上我们可以认为虚拟节点的资源是无限的,当然实际情况还要以云厂商的规模和产品能力来做判断。

image.png


节点伸缩:CA


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


image.png


各方案特点比对


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


image.png


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


云厂商解决方案


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


image.png


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都在冷启动上做出了一些努力。对于明确业务周期的应用,设置好定时弹性提前扩容,这些问题自然引刃而解。


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


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

image.png


总结


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

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


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


相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
5月前
|
Cloud Native Serverless 流计算
云原生时代的应用架构演进:从微服务到 Serverless 的阿里云实践
云原生技术正重塑企业数字化转型路径。阿里云作为亚太领先云服务商,提供完整云原生产品矩阵:容器服务ACK优化启动速度与镜像分发效率;MSE微服务引擎保障高可用性;ASM服务网格降低资源消耗;函数计算FC突破冷启动瓶颈;SAE重新定义PaaS边界;PolarDB数据库实现存储计算分离;DataWorks简化数据湖构建;Flink实时计算助力风控系统。这些技术已在多行业落地,推动效率提升与商业模式创新,助力企业在数字化浪潮中占据先机。
342 12
|
10月前
|
Kubernetes Cloud Native 持续交付
容器化、Kubernetes与微服务架构的融合
容器化、Kubernetes与微服务架构的融合
353 82
|
7月前
|
监控 Kubernetes Cloud Native
基于阿里云容器服务Kubernetes版(ACK)的微服务架构设计与实践
本文介绍了如何基于阿里云容器服务Kubernetes版(ACK)设计和实现微服务架构。首先概述了微服务架构的优势与挑战,如模块化、可扩展性及技术多样性。接着详细描述了ACK的核心功能,包括集群管理、应用管理、网络与安全、监控与日志等。在设计基于ACK的微服务架构时,需考虑服务拆分、通信、发现与负载均衡、配置管理、监控与日志以及CI/CD等方面。通过一个电商应用案例,展示了用户服务、商品服务、订单服务和支付服务的具体部署步骤。最后总结了ACK为微服务架构提供的强大支持,帮助应对各种挑战,构建高效可靠的云原生应用。
|
6月前
|
存储 NoSQL 关系型数据库
微服务——MongoDB的应用场景
随着Web2.0时代的到来,传统关系型数据库(如MySQL)在高并发读写、海量数据存储及高可扩展性需求方面逐渐力不从心。而MongoDB凭借其灵活的文档结构和高效性能,在社交、游戏、物流、物联网和视频直播等场景中表现出色。这些场景通常具有数据量大、写入频繁且对事务要求不高的特点。选择MongoDB适合以下情况:应用无需复杂事务与join支持、需求不确定需快速迭代、需处理高QPS读写或超大规模数据存储、追求高可用性和快速水平扩展能力。相比MySQL,MongoDB能以更低的学习、开发和运维成本满足现代应用需求。
231 0
|
7月前
|
监控 Cloud Native Java
基于阿里云容器服务(ACK)的微服务架构设计与实践
本文介绍如何利用阿里云容器服务Kubernetes版(ACK)构建高可用、可扩展的微服务架构。通过电商平台案例,展示基于Java(Spring Boot)、Docker、Nacos等技术的开发、容器化、部署流程,涵盖服务注册、API网关、监控日志及性能优化实践,帮助企业实现云原生转型。
|
9月前
|
关系型数据库 MySQL Docker
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
496 24
|
10月前
|
Cloud Native 安全 持续交付
深入理解微服务架构及其在现代软件开发中的应用
深入理解微服务架构及其在现代软件开发中的应用
260 33
|
9月前
|
关系型数据库 MySQL Docker
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
528 6
|
10月前
|
运维 Kubernetes Docker
深入理解容器化技术及其在微服务架构中的应用
深入理解容器化技术及其在微服务架构中的应用
649 1
|
4月前
|
资源调度 Kubernetes 调度
从单集群到多集群的快速无损转型:ACK One 多集群应用分发
ACK One 的多集群应用分发,可以最小成本地结合您已有的单集群 CD 系统,无需对原先应用资源 YAML 进行修改,即可快速构建成多集群的 CD 系统,并同时获得强大的多集群资源调度和分发的能力。
172 9

推荐镜像

更多