精华内容
下载资源
问答
  • 导语: 我们通常使用Prometheus来对Kubernetes运行情况进行监控。并根据监控数据来扩容或者缩容。通常的扩/缩容都是根据内存或者...自动弹性伸缩是一种基于资源使用情况自动弹性伸缩工作负载的方法。 Kubernetes的...

    导语: 我们通常使用Prometheus来对Kubernetes运行情况进行监控。并根据监控数据来扩容或者缩容。通常的扩/缩容都是根据内存或者CPU的使用,但是很多时候我们扩/缩容的依据通常是业务监控指标。如何根据业务监控指标来进行扩/缩容,本文作者给出了很优雅的方式。

    Kubernetes自动弹性伸缩

    自动弹性伸缩是一种基于资源使用情况自动弹性伸缩工作负载的方法。
    Kubernetes的自动弹性伸缩有两个维度:

    • 处理node缩放操作的Cluster Autoscaler

    • 自动弹性伸缩部署副本集Pod数量的Horizontal Pod Autoscaler(HPA)。

    Cluster Autoscaling和Horizontal Pod Autoscaler(HPA)可用于动态调整计算能力以满足系统SLA的要求。
    虽然群集Cluster Autoscaler高度依赖云提供程序的底层功能,但HPA可以独立于IaaS / PaaS提供程序运行。

     

    HPA的演变

    Horizontal Pod Autoscaler功能首次在Kubernetes V1.1中引入,自那时起已经发展了很久。 HPA V1版本基于观察到的CPU利用率和内存使用情况来自动伸缩POD。 在Kubernetes 1.6中引入了新的API自定义度量API,使HPA可以访问任意度量标准。 最终,Kubernetes 1.7引入了聚合层,允许第三方应用程序通过将自己注册为API附加组件来扩展Kubernetes API。
    Custom Metrics API和聚合层使得Prometheus等监控系统可以向HPA控制器公开特定于应用的指标。
    Horizontal Pod Autoscaler使用控制循环来实现功能,它定期查询Resource Metrics API的核心度量标准,如CPU /内存和Custom Metrics API以获取特定于应用程序的度量标准。

    以下是关于为Kubernetes 1.9或更高版本配置HPA v2的指南:

    1. 安装提供核心指标的Metrics Server插件。

    2. 使用demo应用根据CPU和内存使用情况展示pod自动调节。

    3. 部署Prometheus和一个自定义的API服务器。 将自定义API服务器注册到聚合层。

    4. demo应用程序使用自定义指标配置HPA。

    在开始之前,您需要安装Go 1.8或更高版本,并在您的GOPATH克隆k8s-prom-hpa[1]:

    1. 设置Metrics server

    Kubernetes Metrics Server[2]是一个集群范围的资源使用数据聚合器,是Heapster[3]的继任者。 Metrics Server通过汇集来自kubernetes.summary_api.数据来收集node和POD的CPU和内存使用情况。summary API是用于将数据从Kubelet / cAdvisor传递到Metrics Server的API(基于内存十分高效)。

    如果在HPA的第一个版本中,您需要Heapster提供CPU和内存指标,但在HPA v2和Kubernetes 1.8中,只有启用horizontal-pod-autoscaler-use-rest-clients时才需要Metrics Server。 Kubernetes 1.9默认启用HPA rest 客户端。 GKE 1.9预装了Metrics Server。
    在kube-system命名空间中部署Metrics Server:

    kubectl create -f ./metrics-server

    一分钟后, metric-server开始报告node和POD的CPU和内存使用情况。

    查看node指标:

     

    kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes" | jq .

    查看pods指标:

    kubectl get --raw "/apis/metrics.k8s.io/v1beta1/pods" | jq .

     

    2.基于CPU和内存使用情况的Auto Scaling

    我们将使用一个基于Golang的小型Web应用程序来测试Horizontal Pod Autoscaler(HPA)。
    将podinfo[4]部署到default名称空间:

    kubectl create -f ./podinfo/podinfo-svc.yaml,./podinfo/podinfo-dep.yaml

    使用http://<K8S_PUBLIC_IP>:31198.上的NodePort服务访问podinfo。
    接下来定义一个保持最少两个副本的HPA,如果CPU平均值超过80%或内存超过200Mi,则可扩展到10:

    创建HPA:

    kubectl create -f ./podinfo/podinfo-hpa.yaml

    几秒钟后,HPA控制器联系Metrics Server,然后获取CPU和内存使用情况:

    为了增加CPU压力,使用rakyll / hey运行负载测试:

    暂时删除podinfo。 稍后将在本教程中再次部署它:

    kubectl delete -f ./podinfo/podinfo-hpa.yaml,./podinfo/podinfo-dep.yaml,./podinfo/podinfo-svc.yaml

     

    3.设置自定义Metrics Server

    为了根据自定义指标进行缩放,您需要两个组件。 一个从您的应用程序收集指标并将它们存储在Prometheus[5]时间序列数据库中。 第二个组件使用collect, k8s-prometheus适配器[6]提供的度量标准扩展Kubernetes自定义指标API。
     

    您将在专用命名空间中部署Prometheus和适配器。
    创建monitoring名称空间:

    kubectl create -f ./namespaces.yaml

    在monitoring命名空间中部署Prometheus v2:

    kubectl create -f ./prometheus

    生成Prometheus适配器所需的TLS证书:

    make certs

    部署Prometheus自定义指标API适配器:

    kubectl create -f ./custom-metrics-api

    列出Prometheus提供的自定义指标:

    kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq .

    获取monitoring命名空间中所有POD的FS使用情况:

    kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/monitoring/pods/*/fs_usage_bytes" | jq .

     

    4.基于自定义指标的Auto Scaling

    在default命名空间中创建podinfoNodePort服务并部署:

    kubectl create -f ./podinfo/podinfo-svc.yaml,./podinfo/podinfo-dep.yaml

    podinfo应用程序公开名为http_requests_total的自定义指标。 Prometheus适配器移除_total后缀并将度量标记为计数器度量。
    从自定义指标API获取每秒的总请求数:

    m代表milli-units,例如, 901m 意味着901 milli-requests (就是大约0.9个请求)。
    创建一个HPA,如果请求数量超过每秒10个,将增加podinfo:

    在default名称空间中部署podinfoHPA:

    kubectl create -f ./podinfo/podinfo-hpa-custom.yaml

    几秒钟后,HPA从度量API获取http_requests值:

    以每秒25个请求的速度为podinfo服务加压:

    几分钟后,HPA开始增加POD数量:

    按照目前每秒的请求速度,部署将永远不会达到10个POD的最大值。 三个副本足以使每个POD的RPS保持在10以下。
    负载测试完成后,HPA会将部署缩减为其初始副本数量:

    您可能已经注意到自动调节器不会立即响应峰值。 默认情况下,指标同步每30秒一次。 如果在最近3-5分钟内没有重新缩放,才能进行扩容/缩容。这确保了HP以防止冲突决策快速执行,并为Cluster Autoscaler提供了时间。

     

    结论

    并非所有系统都可以通过单独依靠CPU /内存使用量度来满足其SLA,但大多数Web和移动后端均需要基于每秒请求数来对任何流量突发进行处理。

    对于ETL应用程序,自动弹性伸缩可能由作业队列长度超过某个阈值引发,等等。
    通过使用Prometheus提供的适用于自动弹性伸缩的指标,您可以微调应用程序以更好地处理突发事件并确保高可用性。

     

    参考链接

    [1] https://github.com/stefanprodan/k8s-prom-hpa

    [2] https://github.com/kubernetes-incubator/metrics-server

    [3] https://github.com/kubernetes/heapster

    [4] https://github.com/stefanprodan/k8s-podinfo

    [5] https://prometheus.io

    [6] https://github.com/DirectXMan12/k8s-prometheus-adapter

    展开全文
  • 弹性伸缩具有应突发、省成本、自动化的业务价值。平台侧将各业务零散、闲置资源进行整合,形成一个大规模资源池,通过弹性调度、库存管控技术在公司运营成本和业务体感中寻求较好的平衡。本文将介绍美团...

    弹性伸缩具有应突发、省成本、自动化的业务价值。平台侧将各业务零散、闲置资源进行整合,形成一个大规模资源池,通过弹性调度、库存管控技术在公司运营成本和业务体感中寻求较好的平衡。

    本文将介绍美团弹性伸缩系统落地过程中面临的技术挑战、推广以及在运营层面的一些思考。在美团这种多样化的业务场景中落地弹性伸缩,与业界公有云、自建私有云的公司相比,既有共性又有自己的特点,希望能为大家提供新的思路或者启发。

    • 前言

    • 一、弹性伸缩系统演进

    • 二、挑战与应对之策

      • 2.1 技术挑战

      • 2.2 推广思路

      • 2.3 运营难题

    • 三、业务赋能场景

      • 3.1 节假日扩缩容

      • 3.2 日常高峰期扩容

      • 3.3 应急资源保障

      • 3.4 服务链路扩缩容

    • 四、弹性伸缩未来规划

    • 作者简介

    • 招聘信息

    前言

    稳定、高效、可靠的基础设施是互联网企业应对业务高峰流量的底层基石。作为美团统一的基础技术平台,基础技术部一直致力于通过业内前沿技术的落地,保障公司内部所有业务在线生产系统所依赖的基础技术平台能稳定、安全、低成本、可持续地运行与发展。

    弹性伸缩系统是基于Docker开发的自动弹性伸缩平台,在美团经历了多年的发展。

    早在2016年,美团就在线上环境中尝试使用容器环境,推出了基于OpenStack的容器集群平台Hulk 1.0。随着容器的落地,弹性伸缩1.0版本应运而生,它解决了扩容实例慢、扩容上线慢、资源回收慢、计算资源冗余等问题。

    结合前两年的探索和实践以及业界相关领域技术的成熟度,2018年至今,我们对容器集群平台进行了一次自底向上的的整体升级,也就是现在的Hulk 2.0平台。在底层,Hulk 2.0建设了自研的操作系统、容器引擎,并将OpenStack替换成了容器编排的事实标准Kubernetes;在上层弹性伸缩系统PaaS层面,推出了弹性伸缩系统2.0,解决了弹性伸缩1.0实践过程中面临的很多业务痛点,包括:

    • 扩出的业务代码版本不一致:导致业务逻辑异常,造成资损。

    • 部分服务高峰期资源不足:导致业务无法有效承载流量,引起资损,

    • 平台维护成本高:北京、上海的业务各自一套弹性伸缩用户端管理平台、弹性逻辑(因为美团、大众点评合并前期,服务治理框架、CMDB系统、发布系统尚未标准化)。

    • 配置使用灵活性低:业务集群每增/减一个IDC均需在平台做相匹配的配置操作,在资源的调控上无法和公司的流量调度体系包括单元化架构、同地域、同中心调用有效地进行匹配。

    一、弹性伸缩系统演进

    弹性伸缩1.0架构

    我们首先看一下,产品演进路线和弹性伸缩1.0架构图。

    产品演进路线

    弹性伸缩1.0架构

    自左向右、自上而下进行模块介绍:

    • 用户端Portal:OCTO管理端,OCTO是美团服务治理平台,出于北京业务操作服务节点习惯的考虑,在其上开发了对应的弹性伸缩管理页面;TTT管理端,TTT是上海侧(原大众点评侧)的CMDB管理平台,出于上海侧业务操作服务节点习惯的考虑,我们在其上开发了对应的弹性伸缩管理页面。

    • Hulk-ApiServer:Hulk 1.0容器平台的网关服务。

    • Hulk-Policy:弹性伸缩系统1.0的业务逻辑模块,其中涵盖了具体的指标聚合、扩缩容逻辑、策略等,主从架构模式,使用Zookeeper进行Master选举,从是冷备。

    • Hulk数据源:OCTO,美团服务治理平台;CAT,美团服务端、移动端监控平台,主要负责应用层面;Falcon,基于开源Falcon定制化的系统监控平台,主要负责机器层面。

    • Scheduler:Hulk 1.0容器平台的调度系统,基于OpenStack做了二次开发。

    弹性伸缩2.0架构

    弹性伸缩系统2.0主要在以下四个方面进行了架构演进:

    1)调度系统-替换:将OpenStack替换成了容器编排的事实标准Kubernetes,并且在常驻资源池的基础上,新托管了专区资源池以及应急资源池。 

    2)单体服务-微服务化。

    a. API-Server:弹性伸缩-网关服务。

    b. Engine:弹性伸缩-引擎,负责各服务实例扩缩的发起、终止,主从架构模式,使用Zookeeper进行Master选举,从是热备。

    c. Metrics-Server、Metrics-Data:【新增】弹性伸缩指标服务,负责Raptor、OCTO等数据源的采集&聚合。

    d. Resource-Server:【新增】弹性伸缩-库存管控服务,为各服务自动扩缩的资源需求保驾护航。 

    3)服务画像-数据平台化:Portrait-Server、Portrait-Data,弹性伸缩系统内部自建的服务画像数据体系。 

    4)可观测性:【新增】Alarm、Scanner,负责弹性伸缩的监控告警、运营治理等工作。

    弹性伸缩2.0架构

    二、挑战与应对之策

    在介绍前,有必要重点说明下2018年这个时间节点。如前言中所述,2018年以前弹性伸缩1.0这个PaaS平台存在的一些问题,以及整体Hulk 1.0容器平台落地过程中遇到的一些问题,在产品战略上我们提出了Hulk 2.0的计划,它涵盖调度系统、容器引擎、内核隔离增强、弹性伸缩增强等领域;在战术上,遵循自顶向下的设计原则、自底向上的实施原则。

    在2018年4月前比较长的一段时间内,Hulk容器平台的研发主要聚焦在底层系统的升级上(优先打通Hulk 2.0容器编排Kubernetes、容器创建/销毁的流程),在弹性伸缩PaaS平台的投入约为0.5个人力,增量业务停止接入,存量业务继续维护。在Hulk 2.0底层系统基本成型后,容器平台团队一方面开始着手将未接入弹性伸缩平台的Hulk 1.0容器平滑迁移至Hulk 2.0容器。另外一方面,开始着手组建人力建设可对接Hulk 2.0容器平台编排能力的弹性伸缩2.0系统,为已接入弹性伸缩平台的Hulk 1.0容器平滑迁移过来做技术储备。

    在弹性伸缩2.0系统的演进过程中遵循“技术”、“推广”、“运营”的演进策略。我们可以先来看下在搭建平台的过程中面临的一些挑战以及解法。

    2.1 技术挑战

    结合当下弹性伸缩系统面临的处境,并对业界弹性伸缩产品做过一番调研后,在平台搭建上确定了如下三期目标:

    • 一期目标:弹性伸缩2.0系统MVP版本,简单来说是把底层OpenStack相关生态更换成Kubernetes周边生态,上层功能先维持不变。

    • 二期目标:业务上,找同部门业务先行试点,基于反馈,小步快跑,快速迭代;技术上,对北京、上海服务治理平台,CMDB系统等相关业务逻辑进行融合。

    • 三期目标:1.0系统的用户端融合为一套,减少业务侧的理解成本、研发侧的开发/维护成本。

    在上述三期目标基本落地后,弹性伸缩2.0系统基本可以跑起来,处于一个不比弹性伸缩1.0系统差的阶段,接下来基于过往运维问题汇总以及业务访谈诉求,在后端架构上做了几个比较大的升级。

    2.1.1 弹性调度

    正如前言所述,和大部分弹性伸缩产品类似,早期启用弹性伸缩的过程如下:

    • 创建弹性分组:弹性分组是弹性伸缩管理的基本单元,弹性分组用来管理同质化的业务实例,在美团的实践中,主要是同一个IDC中的实例。

    • 创建弹性伸缩配置:用于确定扩容出来的弹性伸缩实例的机型配置,比如:CPU、内存、硬盘大小等。

    • 创建弹性伸缩规则:具体来讲就是扩容几台、缩容几台。

    • 创建弹性伸缩任务:监控任务、定时任务。

    在美团的落地场景中,我们遇到如下问题:

    • 该扩未扩,业务集群新部署一个IDC的实例时,不容易联想到需要给这个IDC实例创建弹性分组,导致的问题是高峰期其他IDC可正常扩容,这个IDC无法正常扩容。

    • 不该扩却扩,业务集群不再使用某个IDC后,未联想到需要关停这个弹性分组,导致的问题是一些定时任务依旧扩容出这个IDC的实例,部分情况下会引发业务异常。

    • IDC视角的扩缩局限性,未站在“上帝视角”做扩缩容决策,会导致部分IDC资源紧缺时,比较难以Fail-Fast。

    • 业务在不同IDC的业务逻辑不一致,部分业务把具体的策略耦合在业务逻辑中,一个业务集群使用一套镜像弹性扩容,会引发业务异常。

    基于以上种种原因,我们拉通了各PaaS方,梳理了流量分组、弹性分组、发布分组之间的关系,以保证弹性伸缩在美团私有云中的扩容准确性。

    分组关系图
    • 流量分组:划分来源于美团服务治理平台-OCTO、SET化平台-大禹,比如这个服务走的是SET化方式(类业界单元化架构),那么每一个SET就是一个流量分组;依次类推,设置的是无差别调用方式,那么全局就是一个流量分组;设置的是同地域(Region)调用方式,那么每个Region就是一个流量分组;设置的是同中心调用方式,那么每个中心就是一个流量分组;设置的是同IDC优先调用方式,那么每个IDC就是一个流量分组。

    • 弹性分组:无需手动划分,一个流量分组就对应一个弹性分组,直接Mapping创建即可。

    • 发布分组:划分来源于美团发布平台-Plus,对于未采用SET化架构的业务集群,则仅有一个Default-发布分组;针对采用SET化架构的集群,每个SET对应一个SET-发布分组,它们的代码/镜像可以不一样;基于同一个SET下又可能有多个地域、多个中心、多个IDC(目前美团的SET化架构以同IDC调用为主),所以和流量分组之间是1对N的关系。

    同地域访问的方式比较有代表性,这里对同地域调用&未SET化、同地域调用&SET化的业务集群自动扩容方式进行展开说明,其他组合可依次类推。

    分组明细图

    2.1.2 库存管控

    弹性伸缩系统如果只是单纯地提供一个IaaS资源的自动供给能力,这件事情并不难。然而实际情况下,弹性伸缩系统在落地过程中需要解决资源上面临的问题。

    • 业务关注点:资源如何保障?过往在弹性伸缩系统1.0遇到过多次扩不出资源的情况。

    • 组织关注点:弹性资源池该划分为多大合适?如果储备大量的资源,却无法较好的进行分时复用,作为PaaS平台本身会造成资源闲置。

    针对业务的这个关注点,目前业界公有云厂商的做法基本是不做SLA承诺或者说很难做到SLA承诺,因此也自然不会面临到组织的关注点问题。具体来说,在美团主要是通过以下几个措施来解决。

    2.1.2.1 多租户管理

    资源多租户图

    平台给到每个业务线的资源并非无限,会给每个业务集群的弹性分组,设置一个默认的资源Quota。如果业务觉得默认Quota不够,可通过工单的方式进行一轮评估调整(从实践来看,绝大部分情况无需调整)。针对这个资源Quota,平台侧承诺的SLA:99.9%的扩容成功率。

    这里会有个问题:是不是给业务Quota后,这部分资源就直接划分给这个业务独占了?答案:不是的。这只是一个逻辑上的划分,资源本身是各业务混用的,平台需控制资源闲置率,本身会做些“超售”,但过程中需解决好“超售”可能面临的问题,这就是水位线监管机制。

    2.1.2.2 常态-资源保障

    常规-资源保障,指的是平日、小节假日下的资源供给机制,这部分的资源来源于常驻资源池(架构图所示),平台会对已接入平台的所有服务,进行小时粒度的资源重预估。具体示意图如下:

    资源保障图

    新增/更新服务的伸缩任务、伸缩规则时,会对当前变更对整体资源池水位的影响进行预估,如果在叠加时间点将超过整体资源池的水位,平台会拒绝执行变更操作,并给到用户和平台管理员消息推送,用户可通过工单方式进行资源请求说明(需保障存量服务的资源可靠性)。

    库存&实时用量
    库存&预估用量

    2.1.2.3 应急-资源保障

    常驻资源池的大小是有限的,应急-资源保障指的是业务拉新、大促、大节假日等非常态的资源供给机制,这部分的资源来源于常驻资源池+应急资源池(架构图所示)。应急资源池简单来说就是,我们按用量计费模式购买的公有云资源,这是一种更灵活的资源池模式(具备一定的租约)。在此基础上,我们构建了更省成本的混合云弹性调度能力(在此之前仅在私有云的常驻资源池调度)。

    • 弹性扩容:常驻资源池实例优先占用,应急资源池实例次之。

    • 弹性缩容:应急资源池实例先缩容,常驻资源池实例次之。

    以下示意图展示的是一个服务在大促期间(维持T天)需要208台容器实例,其中8台为常态下的资源诉求,200台为应急资源诉求。

    大促前:

    大促后(T+1):

    T+1天后,这些应急资源池将被腾退回公有云厂商,公司无需为后续继续付费。多业务都应急的场景其实会偏复杂些;特殊情况下,需要采用重调度、治理。

    2.2 推广思路

    在2020年之前,是弹性伸缩2.0系统的练内功阶段,并未大规模向业务推广Hulk 2.0弹性伸缩系统,主要原因归结为两方面:

    • 公司还处在从虚拟机、Hulk 1.0容器迁移至Hulk 2.0容器阶段,Hulk 2.0容器实例还处于打磨以及逐步赢得业务信任的过程中,推广弹性弹性伸缩2.0系统,容器化是第一步。

    • Hulk 2.0系统在基础功能上不足以满足相对复杂的业务场景,比如SET化架构的业务。

    截止2020年年底,共接入了约500个服务。这里主要以弹性伸缩1.0系统中平滑迁移过来的服务,同部门的服务(Eat Your Own Dog Food)为主。

    在2020年-2021年,是弹性伸缩2.0系统的规模化阶段。

    • 数据驱动:从数万个服务中,通过自建的服务画像数据体系挖掘出数千个美团适合接入弹性伸缩的服务,主要是参考高低峰、是否有状态、实例配置、业务集群规模等因素,并将其下钻到各业务部门,共建设30+运营大盘,锁定了平台侧希望去赋能的业务群体。

    • 价值量化:这里面经历了一些认知迭代的过程,最后提炼出来主要是三方面:“应突发”、“省成本”、“自动化”。

    • 深入业务:在前面500多个服务相对比较稳定之后,大概花了两三个月,和美团的各个业务线负责人去聊,主要围绕业务介绍(只有了解它,才有可能为它赋能),弹性伸缩价值介绍(横向拉通其他业务的最佳实践),业务今年的OKR是哪几块(评估弹性伸缩三方面的价值是否可以帮助业务更好的达成业绩、合作共赢),一起讨论当前业务接入后可能看到的收益。

    • 技术培训:根据前期深入业务,获得的反馈。业务比较关注技术原理、接入成本、系统健壮性、最佳实践、有哪些潜在的坑。团队同学把这些进行了提炼总结,输出了弹性伸缩白皮书(技术原理、FAQ手册、最佳实践等)、避坑指南,并在有需要的业务部门进行VIP式的技术分享,一次不够、可以来两次,大大小小的业务团队、公司级的分享,我们做了十几二十次。

    • 渠道闭环:公司层面上要做一些大促活动,如“安心复苏计划”、“517吃货节”、“1001夜直播”,这些活动只要我们知道了,我们就主动加入进去看看能帮助哪些,从结果来看,效果还是挺好的。我们还在公司的COE系统(故障复盘分析工具)去搜“负载”、“秒杀”、“暴涨”、“扩容”之类的关键字,学习问题的处理过程以及待办事项,评估后发现能帮上的,我们就主动联系业务去沟通。

    • 业务回访:虽然我们会在技术支持群内会做答疑,且每周会进行值班问题的汇总Review,但相对来说会偏零散些。我们开始是采用问卷调查的方式去获取反馈,但是践行下来效果比较一般。因此,我们还是采用比较原始的方式——“促膝长谈”,我们主动从业务侧去拉取接入后遇到的问题,在评估优先级后快速迭代系统本身。

    经过以上这些工作,我们80%+的服务接入了弹性,覆盖了公司90%+的业务线。回到那句话,如果弹性伸缩系统只是单纯地提供一个IaaS资源的自动供给能力,这件事情并不难,而我们的定位是PaaS平台。

    2.3 运营难题

    这部分主要介绍向业务交付弹性容器实例后,碰到的三类典型问题:配置启动性能。这些问题大部分不是弹性伸缩2.0这个PaaS平台本身领域内可直接闭环解决的事项,这往往取决于各PaaS平台是否已全量标准化、业务自身逻辑、以及基础设施层性能等因素,催化我们多去做这一步的原因只有一个:弹性扩容出的实例只有很好的帮助业务分担负载,才可真正帮助业务解决问题

    2.3.1 配置问题

    2.3.2 启动问题

    启动问题,大部分解决的是容器的这种开箱即用方式所面临的问题,而非过往的采用先申请机器、再在这上面发布代码包的方式。而且这里面会经常要面临着业务的质疑,为什么我手动发布的时候不存在这个问题,采用弹性扩容就出现了?

    2.3.3 性能问题

    生产环境中,业务容器的性能问题其实是比较复杂的,可能涉及到重IO容器影响、宿主机Load过高、多个容器突发占用CPU过高导致影响某个业务容器问题。相对于不使用弹性时囤积算力的稳定场景,弹性扩缩容场景中,因对资源的频繁调配会更容易遇到资源性能的问题。为了保障使用效果,Hulk项目组主要从三个角度对性能问题完整解决:

    • 事前:服务粒度配置个性化调度策略。

    • 事中:基于服务画像数据平台提供服务时序特征、宿主机时序特征,建设多维度资源打散能力的调度算法。

    • 事后:针对存量Node上的重IO、重CPU等容器进行重调度。

    三、业务赋能场景

    3.1 节假日扩缩容

    业务场景:有着明显的“七节二月”特性,就流量而言周末是工作日的1.5倍左右,节假日流量是周末的3~5倍左右。服务机器基本上是按照节假日的流量部署,平时机器使用率很低。

    如何使用弹性伸缩:

    • 接入弹性伸缩定时任务,节假日期间弹性扩容,应对节假日流量高峰;非节假日高峰,弹性缩容,减少服务器资源开销。

    • 任务配置示例:节前配置定时任务扩容;节后配置定时任务缩容;监控扩容任务作为托底。

    接入效果:业务侧平均节约成本20.4%。

    3.2 日常高峰期扩容

    业务场景:配送是外卖服务的下游,具有明显的午高峰特性。

    如何使用弹性伸缩:

    • 设置定时任务:在午高峰来临前扩容出足量的机器,在午高峰结束后缩掉富余的机器,如示例,分组【global - banner-east - 无swimlane】绑定了2个定时任务,每天09:55扩容125台机器;每天14:00缩容125台机器。

    接入效果:接入弹性之前,为应对午高峰流量,该服务需要常驻机器2420台;接入弹性之后常驻机器释放了365台,高峰期弹性机器占总机器数的15%。

    3.3 应急资源保障

    业务场景:风控反爬服务,是公司业务的服务安全盾和数据安全盾。目前,已有上百个业务方接入反爬服务,每天处理百亿级重点流量,为各大业务方防控恶意流量,保障业务稳定、数据安全及统计数据的正确性。风控反爬相关服务,活动节假日期间,服务负载会受业务影响增长明显,需要活动节假日期间补充大量资源。

    如何使用弹性策略:活动节假日期间,风控反爬业务,申请弹性应急资源(采购公有云宿主机),提升活动期间弹性扩容总量,提升服务稳定性。活动节假日过后,缩容应急资源,腾退公有云宿主机,节约资源。

    服务A
    服务B

    接入效果:为风控业务支持了5次大规模线上活动,基于弹性伸缩的应急-资源保障机制,累计提供公有云资源700+台高配容器,约7000+CPU资源。

    3.4 服务链路扩缩容

    业务场景:餐饮SaaS采取“火车模型发布的模式”交付功能,需要为70+服务申请专用的灰度链路机器,用于云端功能的灰度验证。但机器每月仅需使用2~3个工作日,一直持有机器,造成机器资源浪费;最初团队是通过每月定时手动申请、释放机器来解决,耗费较大人力,一定程度上影响到了研发的效率。

    如何使用弹性策略:

    • 配置链路拓扑。

    • 每月活动开始前,配置链路任务,设置:扩缩容时间、机器SET/LiteSet标识、链路服务扩容机器数量。

    • 到达设定时间,自动扩容、缩容机器。

    接入效果

    • 使用前:火车发版涉及70+服务,每月需要70+服务负责人各自在发版前扩容机器,验证完成后缩容机器。

    • 使用后:首次配置链路拓扑后,此后每月仅需一名RD同学,统一配置一个链路任务,达到预设时间,自动扩、缩容,大大提高效率。

    四、弹性伸缩未来规划

    随着弹性伸缩系统2.0在美团的规模化落地,我们未来会从稳定性、易用性、业务解决方案、新技术探索四个方面去做深、做广:

    1)稳定性:基础服务的稳定性是一切的基石,而这往往是不少研发同学容易忽视的一点,研发同学需“在晴天时修屋顶”。

    • 系统自身的健壮性:集群全链路拆分(缩爆炸半径)、池化、资源QoS保障能力建设。

    • 弹性实例的稳定性:加固发现能力,持续完善异常检测工具(区别于常规的健康检测,会从异构算力的宿主机、不同内核参数、各系统指标层面进行综合决策),自动进行异常实例的替换;加强数据运营,提升反馈能力,持续协同调度算法进行演进。

    2)易用性

    • 强化预演模式:可以预测当前的弹性伸缩规则,服务接下来24小时的扩缩是怎么样的。这块我们目前做了个MVP版本,接下来除了会进一步提升用户触达率,另外也计划在用户端为接入的用户呈现使用后收益数据。

    • 自动任务配置:基于阈值的配置方式不小程度上取决于工程师经验,可能会因为工程师过于“年轻”而没有做正确的配置,导致一些异常;目前在接入侧已经对部分业务放开了任务推荐的功能;计划基于运营数据进一步打磨工具后,会周期性的自动帮助业务调整配置。

    3)业务解决方案

    • 链路伸缩:目前已经实现了基于链路拓扑批量配置、对各服务伸缩规则进行拆分的能力;接下来会将服务与服务之间,服务与中间件、存储之间的背压反馈作用于弹性决策中。

    • 专区弹性伸缩:目前已在金融业务线、美团七层负载均衡服务网关Oceanus中发挥弹性伸缩系统的“应突发”价值,未来计划为更多有专区场景的业务提供弹性伸缩支持。

    4)新技术探索:借鉴Knative、Keda的设计理念,为云原生业务场景的弹性伸缩做技术储备。

    作者简介

    涂扬,现任基础架构部弹性策略团队负责人。

    展开全文
  • 由于大部分云资源是按需取用,按量计费模式,相比使用 IDC,使用云的用户从弹性伸缩获得的成本优势是非常明显的,弹性伸缩也是大多数云上用户的选择。而关于如何用好弹性伸缩,一直是用户非常关心的问题,本文尝试...

    929头图.png

    作者 | 三未

    前言

    弹性伸缩是一种为了满足业务需求、保证服务质量、平衡服务成本的重要应用管理策略。弹性伸缩让应用的部署规模能够根据实时的业务量产生动态调整,在业务高峰期扩大部署规模,保证服务不被业务冲垮;在业务低谷期缩减部署规模,避免资源浪费。

    由于大部分云资源是按需取用,按量计费模式,相比使用 IDC,使用云的用户从弹性伸缩获得的成本优势是非常明显的,弹性伸缩也是大多数云上用户的选择。而关于如何用好弹性伸缩,一直是用户非常关心的问题,本文尝试围绕这个话题,给出一些相关的思考和优化实践。

    有两种实现弹性伸缩方法,一种是“垂直弹性”,即“Scale Up”,另一种是“水平弹性”,也就是“Scale Out”。

    1. 垂直弹性伸缩

    垂直弹性伸缩一般是指通过升降服务器的规格来实现的弹性伸缩。这种伸缩方式对应用本身几乎没有约束,可以被大部分应用或组件使用,它的问题主要在两个方面:

    • 动态调整服务器的规格而不影响上层部署的应用,对基础设施要求比较高,对于许多云厂商而言是个难题,并不能实现业务完全无感的动态变配;

    • 垂直弹性无法突破单台物理设备的规格限制,面向巨量的突发业务增长,垂直弹性的应对能力是有上限的。

    2. 水平弹性伸缩

    而水平弹性伸缩恰恰相反,它依靠增减服务器的数量来实现弹性伸缩,对基础设施的要求不高,水平弹性除了可以解决容量上限的问题,多副本部署还能带来更高的可靠性,因为被广泛的使用在生产系统中,很多时候水平弹性也成了弹性伸缩的代名词,所以我们后文的讲述的主要也是水平弹性。

    微服务与弹性伸缩

    水平弹性虽然存在诸多优势,但它对于应用本身的要求相比垂直弹性是更高的,开发者在使用前需要要考虑好以下的问题:

    • 多副本部署要求应用本身无状态化,如何抽离应用中的状态信息并保持配置同步?

    • 弹性伸缩导致应用实例本身是不稳定的,如何保证应用实例之间能实现可靠的相互调用?

    这些恰好也是微服务架构要解决的问题,而 SpringCloud 作为广泛使用的微服务框架自然不例外,拿问题对号入座的来看:

    • 其一,通过 SpringCloud,开发者可以将原先单体应用中无状态的部分拆解出来,以服务的形式来组织业务逻辑,无状态的服务本身是可以进行水平伸缩的,另外 SpringCloud 提供了很易用的集中式配置管理能力,确保了配置信息可以被高效的分发和同步;

    • 其二,SpringCloud 的服务注册和发现机制,使得服务可以动态的增加或移除实例,通过熔断等服务治理机制可以进一步提升远程调用的可靠性。

    换个角度看,催生微服务的驱动力之一,就是开发者希望利用云的弹性伸缩能力来实现运营成本和服务质量的平衡,因此微服务从设计上就考虑到了要利用弹性伸缩的能力,它们之间是本来就是相辅相成,紧密相关的。

    原生的弹性伸缩

    应用架构支持只是使用弹性伸缩的必要条件之一,想用好弹性伸缩,另外还有两个关键点需要考虑:在什么时机触发弹性伸缩,以及弹性伸缩产生出来的应用如何部署,即规则触发实例调度

    在云原生的体系中,K8s 控制了应用的生命周期管理,在弹性规则触发与实例调度方面,K8s 也提供了相关的能力,足够完成应用弹性伸缩的整个过程。

    K8s 中,无状态应用通常以 Deployment 的形式进行部署,弹性伸缩过程由 Horizontal Pod Autoscaler(HPA)来进行控制,开发者设定 CPU 或内存的目标使用率与 Deployment 的副本数区间,由 HPA 负责定时从监控数据中计算并设定目标的副本数,至于实例的调度过程则交由 K8s 的 Scheduler 来控制。

    参考:https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

    1.png

    如何优化弹性伸缩?

    看起来借助 K8s 的 HPA 机制就可以很轻易的给微服务应用提供弹性伸缩能力,但这样真的就足够了吗?没有那么简单,在弹性伸缩上,目前 SpringCloud 和 K8s 的默认机制仍然存在诸多不足,如果缺少完备而健壮的方案,将其直接用于生产系统,其实是很容易踩坑的。怎么做才能保证弹性伸缩精准到位,过程如丝般顺滑,这是我们写作本文,提供最佳实践的意义。

    EDAS 作为一站式的分布式应用管理平台,对于弹性伸缩这样涉及应用监、管、控全方位的场景,在对弹性伸缩的支持上做了系统的设计,打磨出许多功能点,目的是为用户使用弹性伸缩的“减负”,使其能真正落地到用户生产系统中。

    顺着刚提到的两个关键点,规则触发与实例调度,我们来看 EDAS 在优化弹性伸缩方面是如何思考与实现的。

    1. 规则触发

    常用的弹性伸缩规则是基于监控数据来进行触发的,K8s 也自带了基于 CPU 和内存监控来触发弹性伸缩的功能。但仅有这两种指标并不够,相比基础监控数据,应用指标数据对于业务量的反馈更为直接和敏感,可以说是适合弹性伸缩参考的“黄金指标”。

    但由于 K8s 无法获取到应用的监控信息,这些信息只能通过自定义扩展 API 的方式来实现,对于用户来说,需要理解 K8s 的扩展机制,有一定的学习成本;而且,基于监控数据的规则无法实现实例数从 0 到 1 的扩容,这也不利于实现极致的成本控制。

    1)KEDA

    针对这些痛点,开源社区发展了很多项目,其中最为典型的是 KEDA(Kubernetes Event-driven Autoscaling),通过事件流来辅助 K8s 进行弹性伸缩,架构如下:

    2.png

    KEDA 项目地址:https://keda.sh/

    KEDA 可以被方便地安装到任意的 K8s 集群,它的 Controller(Operator)提供了将应用从 0 副本扩缩的能力,KEDA 也提供了监控指标服务,通过不同的 Scaler 来对接各种开源与供应商的监控指标,并将这些指标提供给 HPA 控制器,来完成多副本的弹性伸缩。

    2)EDAS 的应用弹性策略

    KEDA 的功能很强大,但对于一般用户而言使用的门槛比较高,为了解决这一问题,EDAS 结合 ARMS 提供的应用监控能力,在保留 KEDA 核心功能同时对其做了增强,使得弹性的规则配置更为易用。

    EDAS 的弹性伸缩既支持 K8s 原生的 HPA 规则的配置能力:

    3.png

    还能使用应用黄金指标,如服务每秒请求量(QPS)和平均响应时间(RT):

    4.png

    此外,EDAS 不仅支持指标弹性,还支持定时弹性,通过为不同时段设置合理的副本数区间,定时弹性能最大程度的保证用户体验:

    5.png

    2. 实例调度

    弹性伸缩的规则触发将产生实例调度的请求,但如何将这些请求分配到节点,并在节点部署应用实例,调度是必经的流程,也是 K8s 的核心能力。对于弹性伸缩这一场景,由于涉及大量新实例创建和旧实例的替换,实例调度的动作非常频繁,首先选择合适的调度策略就非常重要。

    1)调度策略

    K8s 提供了丰富配置项供开发者设定调度策略,比如节点选择,节点亲和,污点和容忍等。但如何搭配所需的调度规则并没有放之四海而皆准的做法,需要根据业务实际情况来进行制定,这里列举一些设置调度规则时,常见的考虑:

    • 弹性伸缩发生时系统往往处于比较繁忙状态,尽可能将新增实例发布到不同节点,可以有效避免集群压力分布不均带来的服务质量受损或资源浪费;

    • 将节点分开并均衡部署到多个可用区能有效提升系统的可用性;

    • 对于具有密切关联性的应用实例,可以考虑部署到同样的节点或可用区,可以减少调用开销,提升稳定性。

    对于第 3 点,仅靠调整调度规则还不够,还要依赖微服务治理的能力,使得关联实例能完成就近的服务路由,这也是 EDAS 正在解决的问题之一,而对同应用分节点或者可用区部署 EDAS 已经提供了直接的支持,用户只需要部署时勾选即可:

    6.png

    弹性伸缩时另一个常见的问题是集群节点资源被用尽,因为 K8s 不会主动扩展节点,此时即使弹性伸缩产生了准确的调度请求,K8s 也无法分配出新的应用实例。考虑到这种可能性,这要求用户预留一部分节点资源以应对弹性的需求,但由于资源池的存在,导致用户付出的成本并非是完全的按用量计费,这又与弹性伸缩的初衷相悖,我们不禁会想,怎么做能让节点资源既能物尽其用又能取之不竭?

    2)Cluster AutoScaler

    社区的 Cluster AutoScaler 项目提供了集群节点的自动扩缩,一定程度上解决了资源的按需申请问题,各容器服务提供商也提供了对应的 Cluster AutoScaler 实现,阿里云也不例外,在 ACK 的管控台可以直接配置集群的自动伸缩:

    7.png

    但 Cluster AutoScaler 也有其不足的地方,比如:

    • 首先,Cluster AutoScaler 是在产生了无法满足的实例调度请求之后才开始介入的,而购买新实例的时间比较长(可能在分钟级),远大于 Pod 的启动时间,这等于降低了弹性伸缩的灵敏度,增加了服务受损的风险;

    • 其次,在缩容时,由于应用实例是随机释放的,因此会产生一些遗留的应用实例分散在不同节点上,变成碎片,Cluster AutoScaler 在缩容节点前会尝试迁移这些实例,需要消耗时间甚至引发稳定性问题,也不利于成本控制。

    3)Serverless Kubernetes

    问题的根本还是出在调度上,K8s 需要匹配实例与节点,在这个过程中有太多的复杂度需要用户去考虑和处理。那是否消除掉 K8s 集群的节点,去掉调度的过程,就是通往极致的弹性的方向?答案是肯定的,而且阿里云的 Serverless Kubernetes 服务(ASK)在这个方向上提供了一条现成的途径。

    使用 ASK 服务,用户不用关心节点资源是否充足,应用实例秒级调度,按量计费,完美的契合了弹性伸缩的需求:

    8.png

    EDAS 也支持了 ASK 集群的接管,用户可以直接在 EDAS 创建 Serverless 应用,就能得到“彻底”的弹性伸缩能力:

    9.png

    结语

    本文介绍了微服务应用在云原生体系下的弹性伸缩的用法,并尝试从弹性伸缩的两个关键点来探讨优化的方向和做法,以及 EDAS 是如何看待并解决这些问题的。

    弹性伸缩包含了应用生命周期的整个过程,这过程中就涉及到多项应用管理能力的联动,举个例子,如应用实例缩容时如何进行节点的无损下线,这在弹性伸缩过程中就是非常重要的功能,类似的场景非常多,受限于篇幅,本文不做展开。

    对于 EDAS 来说,弹性伸缩就是一场综合的能力测验,只有在每个环节都做到位,才能更好的用户业务保驾护航。而我们也相信 EDAS 通过与云原生技术和云产品的全面融合,能带给用户更佳的体验,助用户“躺着”用好弹性伸缩,享受到云的福利。

    相关文章推荐:

    课程推荐

    去年,CNCF 与 阿里云联合发布了《云原生技术公开课》已经成为了 Kubernetes 开发者的一门“必修课”。

    今天,阿里云再次集结多位具有丰富云原生实践经验的技术专家,正式推出《云原生技术实践公开课》。课程内容由浅入深,专注讲解“ 落地实践”。还为学习者打造了真实、可操作的实验场景,方便验证学习成果,也为之后的实践应用打下坚实基础。点击链接查看课程:https://developer.aliyun.com/learning/roadmap/cloudnative2020

    阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

    展开全文
  • 总第443篇2021年 第013篇弹性伸缩具有应突发、省成本、自动化的业务价值。平台侧将各业务零散、闲置资源进行整合,形成一个大规模资源池,通过弹性调度、库存管控技术在公司运营成本和业务体...

     

    弹性伸缩具有应突发、省成本、自动化的业务价值。平台侧将各业务零散、闲置资源进行整合,形成一个大规模资源池,通过弹性调度、库存管控技术在公司运营成本和业务体感中寻求较好的平衡。

    本文将介绍美团弹性伸缩系统落地过程中面临的技术挑战、推广以及在运营层面的一些思考。在美团这种多样化的业务场景中落地弹性伸缩,与业界公有云、自建私有云的公司相比,既有共性又有自己的特点,希望能为大家提供新的思路或者启发。

    • 前言

    • 一、弹性伸缩系统演进

    • 二、挑战与应对之策

      • 2.1 技术挑战

      • 2.2 推广思路

      • 2.3 运营难题

    • 三、业务赋能场景

      • 3.1 节假日扩缩容

      • 3.2 日常高峰期扩容

      • 3.3 应急资源保障

      • 3.4 服务链路扩缩容

    • 四、弹性伸缩未来规划

    • 作者简介

    • 招聘信息

    前言

    稳定、高效、可靠的基础设施是互联网企业应对业务高峰流量的底层基石。作为美团统一的基础技术平台,基础技术部一直致力于通过业内前沿技术的落地,保障公司内部所有业务在线生产系统所依赖的基础技术平台能稳定、安全、低成本、可持续地运行与发展。

    弹性伸缩系统是基于Docker开发的自动弹性伸缩平台,在美团经历了多年的发展。

    早在2016年,美团就在线上环境中尝试使用容器环境,推出了基于OpenStack的容器集群平台Hulk 1.0。随着容器的落地,弹性伸缩1.0版本应运而生,它解决了扩容实例慢、扩容上线慢、资源回收慢、计算资源冗余等问题。

    结合前两年的探索和实践以及业界相关领域技术的成熟度,2018年至今,我们对容器集群平台进行了一次自底向上的的整体升级,也就是现在的Hulk 2.0平台。在底层,Hulk 2.0建设了自研的操作系统、容器引擎,并将OpenStack替换成了容器编排的事实标准Kubernetes;在上层弹性伸缩系统PaaS层面,推出了弹性伸缩系统2.0,解决了弹性伸缩1.0实践过程中面临的很多业务痛点,包括:

    • 扩出的业务代码版本不一致:导致业务逻辑异常,造成资损。

    • 部分服务高峰期资源不足:导致业务无法有效承载流量,引起资损,

    • 平台维护成本高:北京、上海的业务各自一套弹性伸缩用户端管理平台、弹性逻辑(因为美团、大众点评合并前期,服务治理框架、CMDB系统、发布系统尚未标准化)。

    • 配置使用灵活性低:业务集群每增/减一个IDC均需在平台做相匹配的配置操作,在资源的调控上无法和公司的流量调度体系包括单元化架构、同地域、同中心调用有效地进行匹配。

    一、弹性伸缩系统演进

    弹性伸缩1.0架构

    我们首先看一下,产品演进路线和弹性伸缩1.0架构图。

    产品演进路线

    弹性伸缩1.0架构

    自左向右、自上而下进行模块介绍:

    • 用户端PortalOCTO管理端,OCTO是美团服务治理平台,出于北京业务操作服务节点习惯的考虑,在其上开发了对应的弹性伸缩管理页面;TTT管理端,TTT是上海侧(原大众点评侧)的CMDB管理平台,出于上海侧业务操作服务节点习惯的考虑,我们在其上开发了对应的弹性伸缩管理页面。

    • Hulk-ApiServer:Hulk 1.0容器平台的网关服务。

    • Hulk-Policy:弹性伸缩系统1.0的业务逻辑模块,其中涵盖了具体的指标聚合、扩缩容逻辑、策略等,主从架构模式,使用Zookeeper进行Master选举,从是冷备。

    • Hulk数据源OCTO,美团服务治理平台;CAT,美团服务端、移动端监控平台,主要负责应用层面;Falcon,基于开源Falcon定制化的系统监控平台,主要负责机器层面。

    • Scheduler:Hulk 1.0容器平台的调度系统,基于OpenStack做了二次开发。

    弹性伸缩2.0架构

    弹性伸缩系统2.0主要在以下四个方面进行了架构演进:

    1)调度系统-替换:将OpenStack替换成了容器编排的事实标准Kubernetes,并且在常驻资源池的基础上,新托管了专区资源池以及应急资源池。 

    2)单体服务-微服务化。

    a. API-Server:弹性伸缩-网关服务。

    b. Engine:弹性伸缩-引擎,负责各服务实例扩缩的发起、终止,主从架构模式,使用Zookeeper进行Master选举,从是热备。

    c. Metrics-Server、Metrics-Data:【新增】弹性伸缩指标服务,负责Raptor、OCTO等数据源的采集&聚合。

    d. Resource-Server:【新增】弹性伸缩-库存管控服务,为各服务自动扩缩的资源需求保驾护航。 

    3)服务画像-数据平台化:Portrait-Server、Portrait-Data,弹性伸缩系统内部自建的服务画像数据体系。 

    4)可观测性:【新增】Alarm、Scanner,负责弹性伸缩的监控告警、运营治理等工作。

    弹性伸缩2.0架构

    二、挑战与应对之策

    在介绍前,有必要重点说明下2018年这个时间节点。如前言中所述,2018年以前弹性伸缩1.0这个PaaS平台存在的一些问题,以及整体Hulk 1.0容器平台落地过程中遇到的一些问题,在产品战略上我们提出了Hulk 2.0的计划,它涵盖调度系统、容器引擎、内核隔离增强、弹性伸缩增强等领域;在战术上,遵循自顶向下的设计原则、自底向上的实施原则。

    在2018年4月前比较长的一段时间内,Hulk容器平台的研发主要聚焦在底层系统的升级上(优先打通Hulk 2.0容器编排Kubernetes、容器创建/销毁的流程),在弹性伸缩PaaS平台的投入约为0.5个人力,增量业务停止接入,存量业务继续维护。在Hulk 2.0底层系统基本成型后,容器平台团队一方面开始着手将未接入弹性伸缩平台的Hulk 1.0容器平滑迁移至Hulk 2.0容器。另外一方面,开始着手组建人力建设可对接Hulk 2.0容器平台编排能力的弹性伸缩2.0系统,为已接入弹性伸缩平台的Hulk 1.0容器平滑迁移过来做技术储备。

    在弹性伸缩2.0系统的演进过程中遵循“技术”、“推广”、“运营”的演进策略。我们可以先来看下在搭建平台的过程中面临的一些挑战以及解法。

    2.1 技术挑战

    结合当下弹性伸缩系统面临的处境,并对业界弹性伸缩产品做过一番调研后,在平台搭建上确定了如下三期目标:

    • 一期目标:弹性伸缩2.0系统MVP版本,简单来说是把底层OpenStack相关生态更换成Kubernetes周边生态,上层功能先维持不变。

    • 二期目标:业务上,找同部门业务先行试点,基于反馈,小步快跑,快速迭代;技术上,对北京、上海服务治理平台,CMDB系统等相关业务逻辑进行融合。

    • 三期目标:1.0系统的用户端融合为一套,减少业务侧的理解成本、研发侧的开发/维护成本。

    在上述三期目标基本落地后,弹性伸缩2.0系统基本可以跑起来,处于一个不比弹性伸缩1.0系统差的阶段,接下来基于过往运维问题汇总以及业务访谈诉求,在后端架构上做了几个比较大的升级。

    2.1.1 弹性调度

    正如前言所述,和大部分弹性伸缩产品类似,早期启用弹性伸缩的过程如下:

    • 创建弹性分组:弹性分组是弹性伸缩管理的基本单元,弹性分组用来管理同质化的业务实例,在美团的实践中,主要是同一个IDC中的实例。

    • 创建弹性伸缩配置:用于确定扩容出来的弹性伸缩实例的机型配置,比如:CPU、内存、硬盘大小等。

    • 创建弹性伸缩规则:具体来讲就是扩容几台、缩容几台。

    • 创建弹性伸缩任务:监控任务、定时任务。

    在美团的落地场景中,我们遇到如下问题:

    • 该扩未扩,业务集群新部署一个IDC的实例时,不容易联想到需要给这个IDC实例创建弹性分组,导致的问题是高峰期其他IDC可正常扩容,这个IDC无法正常扩容。

    • 不该扩却扩,业务集群不再使用某个IDC后,未联想到需要关停这个弹性分组,导致的问题是一些定时任务依旧扩容出这个IDC的实例,部分情况下会引发业务异常。

    • IDC视角的扩缩局限性,未站在“上帝视角”做扩缩容决策,会导致部分IDC资源紧缺时,比较难以Fail-Fast。

    • 业务在不同IDC的业务逻辑不一致,部分业务把具体的策略耦合在业务逻辑中,一个业务集群使用一套镜像弹性扩容,会引发业务异常。

    基于以上种种原因,我们拉通了各PaaS方,梳理了流量分组、弹性分组、发布分组之间的关系,以保证弹性伸缩在美团私有云中的扩容准确性。

    分组关系图
    • 流量分组:划分来源于美团服务治理平台-OCTO、SET化平台-大禹,比如这个服务走的是SET化方式(类业界单元化架构),那么每一个SET就是一个流量分组;依次类推,设置的是无差别调用方式,那么全局就是一个流量分组;设置的是同地域(Region)调用方式,那么每个Region就是一个流量分组;设置的是同中心调用方式,那么每个中心就是一个流量分组;设置的是同IDC优先调用方式,那么每个IDC就是一个流量分组。

    • 弹性分组:无需手动划分,一个流量分组就对应一个弹性分组,直接Mapping创建即可。

    • 发布分组:划分来源于美团发布平台-Plus,对于未采用SET化架构的业务集群,则仅有一个Default-发布分组;针对采用SET化架构的集群,每个SET对应一个SET-发布分组,它们的代码/镜像可以不一样;基于同一个SET下又可能有多个地域、多个中心、多个IDC(目前美团的SET化架构以同IDC调用为主),所以和流量分组之间是1对N的关系。

    同地域访问的方式比较有代表性,这里对同地域调用&未SET化、同地域调用&SET化的业务集群自动扩容方式进行展开说明,其他组合可依次类推。

    分组明细图

    2.1.2 库存管控

    弹性伸缩系统如果只是单纯地提供一个IaaS资源的自动供给能力,这件事情并不难。然而实际情况下,弹性伸缩系统在落地过程中需要解决资源上面临的问题。

    • 业务关注点:资源如何保障?过往在弹性伸缩系统1.0遇到过多次扩不出资源的情况。

    • 组织关注点:弹性资源池该划分为多大合适?如果储备大量的资源,却无法较好的进行分时复用,作为PaaS平台本身会造成资源闲置。

    针对业务的这个关注点,目前业界公有云厂商的做法基本是不做SLA承诺或者说很难做到SLA承诺,因此也自然不会面临到组织的关注点问题。具体来说,在美团主要是通过以下几个措施来解决。

    2.1.2.1 多租户管理

    资源多租户图

    平台给到每个业务线的资源并非无限,会给每个业务集群的弹性分组,设置一个默认的资源Quota。如果业务觉得默认Quota不够,可通过工单的方式进行一轮评估调整(从实践来看,绝大部分情况无需调整)。针对这个资源Quota,平台侧承诺的SLA:99.9%的扩容成功率。

    这里会有个问题:是不是给业务Quota后,这部分资源就直接划分给这个业务独占了?答案:不是的。这只是一个逻辑上的划分,资源本身是各业务混用的,平台需控制资源闲置率,本身会做些“超售”,但过程中需解决好“超售”可能面临的问题,这就是水位线监管机制。

    2.1.2.2 常态-资源保障

    常规-资源保障,指的是平日、小节假日下的资源供给机制,这部分的资源来源于常驻资源池(架构图所示),平台会对已接入平台的所有服务,进行小时粒度的资源重预估。具体示意图如下:

    资源保障图

    新增/更新服务的伸缩任务、伸缩规则时,会对当前变更对整体资源池水位的影响进行预估,如果在叠加时间点将超过整体资源池的水位,平台会拒绝执行变更操作,并给到用户和平台管理员消息推送,用户可通过工单方式进行资源请求说明(需保障存量服务的资源可靠性)。

    库存&实时用量

    库存&预估用量

    2.1.2.3 应急-资源保障

    常驻资源池的大小是有限的,应急-资源保障指的是业务拉新、大促、大节假日等非常态的资源供给机制,这部分的资源来源于常驻资源池+应急资源池(如架构图所示)。应急资源池简单来说就是,我们按用量计费模式购买的公有云资源,这是一种更灵活的资源池模式(具备一定的租约)。在此基础上,我们构建了更省成本的混合云弹性调度能力(在此之前仅在私有云的常驻资源池调度)。

    • 弹性扩容:常驻资源池实例优先占用,应急资源池实例次之。

    • 弹性缩容:应急资源池实例先缩容,常驻资源池实例次之。

    以下示意图展示的是一个服务在大促期间(维持T天)需要208台容器实例,其中8台为常态下的资源诉求,200台为应急资源诉求。

    大促前:

    大促后(T+1):

    T+1天后,这些应急资源池将被腾退回公有云厂商,公司无需为后续继续付费。多业务都应急的场景其实会偏复杂些;特殊情况下,需要采用重调度、治理。

    2.2 推广思路

    在2020年之前,是弹性伸缩2.0系统的练内功阶段,并未大规模向业务推广Hulk 2.0弹性伸缩系统,主要原因归结为两方面:

    • 公司还处在从虚拟机、Hulk 1.0容器迁移至Hulk 2.0容器阶段,Hulk 2.0容器实例还处于打磨以及逐步赢得业务信任的过程中,推广弹性弹性伸缩2.0系统,容器化是第一步。

    • Hulk 2.0系统在基础功能上不足以满足相对复杂的业务场景,比如SET化架构的业务。

    截止2020年年底,共接入了约500个服务。这里主要以弹性伸缩1.0系统中平滑迁移过来的服务,同部门的服务(Eat Your Own Dog Food)为主。

    在2020年-2021年,是弹性伸缩2.0系统的规模化阶段。

    • 数据驱动:从数万个服务中,通过自建的服务画像数据体系挖掘出数千个美团适合接入弹性伸缩的服务,主要是参考高低峰、是否有状态、实例配置、业务集群规模等因素,并将其下钻到各业务部门,共建设30+运营大盘,锁定了平台侧希望去赋能的业务群体。

    • 价值量化:这里面经历了一些认知迭代的过程,最后提炼出来主要是三方面:“应突发”、“省成本”、“自动化”。

    • 深入业务:在前面500多个服务相对比较稳定之后,大概花了两三个月,和美团的各个业务线负责人去聊,主要围绕业务介绍(只有了解它,才有可能为它赋能),弹性伸缩价值介绍(横向拉通其他业务的最佳实践),业务今年的OKR是哪几块(评估弹性伸缩三方面的价值是否可以帮助业务更好的达成业绩、合作共赢),一起讨论当前业务接入后可能看到的收益。

    • 技术培训:根据前期深入业务,获得的反馈。业务比较关注技术原理、接入成本、系统健壮性、最佳实践、有哪些潜在的坑。团队同学把这些进行了提炼总结,输出了弹性伸缩白皮书(技术原理、FAQ手册、最佳实践等)、避坑指南,并在有需要的业务部门进行VIP式的技术分享,一次不够、可以来两次,大大小小的业务团队、公司级的分享,我们做了十几二十次。

    • 渠道闭环:公司层面上要做一些大促活动,如“安心复苏计划”、“517吃货节”、“1001夜直播”,这些活动只要我们知道了,我们就主动加入进去看看能帮助哪些,从结果来看,效果还是挺好的。我们还在公司的COE系统(故障复盘分析工具)去搜“负载”、“秒杀”、“暴涨”、“扩容”之类的关键字,学习问题的处理过程以及待办事项,评估后发现能帮上的,我们就主动联系业务去沟通。

    • 业务回访:虽然我们会在技术支持群内会做答疑,且每周会进行值班问题的汇总Review,但相对来说会偏零散些。我们开始是采用问卷调查的方式去获取反馈,但是践行下来效果比较一般。因此,我们还是采用比较原始的方式——“促膝长谈”,我们主动从业务侧去拉取接入后遇到的问题,在评估优先级后快速迭代系统本身。

    经过以上这些工作,我们80%+的服务接入了弹性,覆盖了公司90%+的业务线。回到那句话,如果弹性伸缩系统只是单纯地提供一个IaaS资源的自动供给能力,这件事情并不难,而我们的定位是PaaS平台。

    2.3 运营难题

    这部分主要介绍向业务交付弹性容器实例后,碰到的三类典型问题:配置启动性能。这些问题大部分不是弹性伸缩2.0这个PaaS平台本身领域内可直接闭环解决的事项,这往往取决于各PaaS平台是否已全量标准化、业务自身逻辑、以及基础设施层性能等因素,催化我们多去做这一步的原因只有一个:弹性扩容出的实例只有很好的帮助业务分担负载,才可真正帮助业务解决问题

    2.3.1 配置问题

    2.3.2 启动问题

    启动问题,大部分解决的是容器的这种开箱即用方式所面临的问题,而非过往的采用先申请机器、再在这上面发布代码包的方式。而且这里面会经常要面临着业务的质疑,为什么我手动发布的时候不存在这个问题,采用弹性扩容就出现了?

    2.3.3 性能问题

    生产环境中,业务容器的性能问题其实是比较复杂的,可能涉及到重IO容器影响、宿主机Load过高、多个容器突发占用CPU过高导致影响某个业务容器问题。相对于不使用弹性时囤积算力的稳定场景,弹性扩缩容场景中,因对资源的频繁调配会更容易遇到资源性能的问题。为了保障使用效果,Hulk项目组主要从三个角度对性能问题完整解决:

    • 事前:服务粒度配置个性化调度策略。

    • 事中:基于服务画像数据平台提供服务时序特征、宿主机时序特征,建设多维度资源打散能力的调度算法。

    • 事后:针对存量Node上的重IO、重CPU等容器进行重调度。

    三、业务赋能场景

    3.1 节假日扩缩容

    业务场景:有着明显的“七节二月”特性,就流量而言周末是工作日的1.5倍左右,节假日流量是周末的3~5倍左右。服务机器基本上是按照节假日的流量部署,平时机器使用率很低。

    如何使用弹性伸缩:

    • 接入弹性伸缩定时任务,节假日期间弹性扩容,应对节假日流量高峰;非节假日高峰,弹性缩容,减少服务器资源开销。

    • 任务配置示例:节前配置定时任务扩容;节后配置定时任务缩容;监控扩容任务作为托底。

    接入效果:业务侧平均节约成本20.4%。

    3.2 日常高峰期扩容

    业务场景:配送是外卖服务的下游,具有明显的午高峰特性。

    如何使用弹性伸缩:

    • 设置定时任务:在午高峰来临前扩容出足量的机器,在午高峰结束后缩掉富余的机器,如示例,分组【global - banner-east - 无swimlane】绑定了2个定时任务,每天09:55扩容125台机器;每天14:00缩容125台机器。

    接入效果:接入弹性之前,为应对午高峰流量,该服务需要常驻机器2420台;接入弹性之后常驻机器释放了365台,高峰期弹性机器占总机器数的15%。

    3.3 应急资源保障

    业务场景:风控反爬服务,是公司业务的服务安全盾和数据安全盾。目前,已有上百个业务方接入反爬服务,每天处理百亿级重点流量,为各大业务方防控恶意流量,保障业务稳定、数据安全及统计数据的正确性。风控反爬相关服务,活动节假日期间,服务负载会受业务影响增长明显,需要活动节假日期间补充大量资源。

    如何使用弹性策略:活动节假日期间,风控反爬业务,申请弹性应急资源(采购公有云宿主机),提升活动期间弹性扩容总量,提升服务稳定性。活动节假日过后,缩容应急资源,腾退公有云宿主机,节约资源。

    服务A

    服务B

    接入效果:为风控业务支持了5次大规模线上活动,基于弹性伸缩的应急-资源保障机制,累计提供公有云资源700+台高配容器,约7000+CPU资源。

    3.4 服务链路扩缩容

    业务场景:餐饮SaaS采取“火车模型发布的模式”交付功能,需要为70+服务申请专用的灰度链路机器,用于云端功能的灰度验证。但机器每月仅需使用2~3个工作日,一直持有机器,造成机器资源浪费;最初团队是通过每月定时手动申请、释放机器来解决,耗费较大人力,一定程度上影响到了研发的效率。

    如何使用弹性策略:

    • 配置链路拓扑。

    • 每月活动开始前,配置链路任务,设置:扩缩容时间、机器SET/LiteSet标识、链路服务扩容机器数量。

    • 到达设定时间,自动扩容、缩容机器。

    接入效果

    • 使用前:火车发版涉及70+服务,每月需要70+服务负责人各自在发版前扩容机器,验证完成后缩容机器。

    • 使用后:首次配置链路拓扑后,此后每月仅需一名RD同学,统一配置一个链路任务,达到预设时间,自动扩、缩容,大大提高效率。

    四、弹性伸缩未来规划

    随着弹性伸缩系统2.0在美团的规模化落地,我们未来会从稳定性、易用性、业务解决方案、新技术探索四个方面去做深、做广:

    1)稳定性:基础服务的稳定性是一切的基石,而这往往是不少研发同学容易忽视的一点,研发同学需“在晴天时修屋顶”。

    • 系统自身的健壮性:集群全链路拆分(缩爆炸半径)、池化、资源QoS保障能力建设。

    • 弹性实例的稳定性:加固发现能力,持续完善异常检测工具(区别于常规的健康检测,会从异构算力的宿主机、不同内核参数、各系统指标层面进行综合决策),自动进行异常实例的替换;加强数据运营,提升反馈能力,持续协同调度算法进行演进。

    2)易用性

    • 强化预演模式:可以预测当前的弹性伸缩规则,服务接下来24小时的扩缩是怎么样的。这块我们目前做了个MVP版本,接下来除了会进一步提升用户触达率,另外也计划在用户端为接入的用户呈现使用后收益数据。

    • 自动任务配置:基于阈值的配置方式不小程度上取决于工程师经验,可能会因为工程师过于“年轻”而没有做正确的配置,导致一些异常;目前在接入侧已经对部分业务放开了任务推荐的功能;计划基于运营数据进一步打磨工具后,会周期性的自动帮助业务调整配置。

    3)业务解决方案

    • 链路伸缩:目前已经实现了基于链路拓扑批量配置、对各服务伸缩规则进行拆分的能力;接下来会将服务与服务之间,服务与中间件、存储之间的背压反馈作用于弹性决策中。

    • 专区弹性伸缩:目前已在金融业务线、美团七层负载均衡服务网关Oceanus中发挥弹性伸缩系统的“应突发”价值,未来计划为更多有专区场景的业务提供弹性伸缩支持。

    4)新技术探索:借鉴Knative、Keda的设计理念,为云原生业务场景的弹性伸缩做技术储备。

    作者简介

    涂扬,现任基础架构部弹性策略团队负责人。

    阅读更多

    ---

    前端 |  算法 | 后端 | 数据

    安全 | Android | iOS  | 运维 | 测试

    ----------  END  ----------

    招聘信息

    美团基础架构团队诚招高级、资深技术专家,Base北京、上海。我们致力于建设美团全公司统一的高并发高性能分布式基础架构平台,涵盖数据库、分布式监控、服务治理、高性能通信、消息中间件、基础存储、容器化、集群调度等基础架构主要的技术领域。欢迎有兴趣的同学投送简历至:edp.itu.zhaopin@meituan.com。

    也许你还想看

      | 美团OCTO万亿级数据中心计算引擎技术解析

      | 美团容器平台HULK的调度系统

      | 美团集群调度系统HULK技术演进

    展开全文
  • 文章来源:架构头条,嘉宾 | 杨森,编辑 | 李忠良面对节假日常规促销、618/ 双 11 购物节等配送业务订单量的暴增,达达集团通过智能弹性伸缩架构和精细化的容量管理,有效地做到了业务系...
  • 本期溪歪歪专栏将带大家一起探索,关于腾讯云弹性计算产品的技术设计要点。 在各行各业都一定程度上适用这句话:Those who talk don’t know, and those who know don’t talk. —— 而我相信,你终将成为那个懂得...
  • 由于大部分云资源是按需取用,按量计费模式,相比使用 IDC,使用云的用户,从弹性伸缩获得的成本,优势是非常明显的,弹性伸缩也是大多数云上用户的选择。 而关于如何用好弹性伸缩,一直是用户非常关心的问题,本文...
  • 下面我们就详细讲述Pravega动态弹性伸缩特性的实现和应用实例。 动态伸缩性 对于分布式消息系统来说,一个设计良好的,可扩展的分区机制必不可少。分区机制使得读写的并行化成为可能,而一个良好的分区扩展机制使得...
  • 版本标签:"release" : "stable" , "release" : "canary" 环境标签:"environment" : "dev" , "environment" : "...weekly
  • 简介:在这篇博文中,我们将简要解释需要考虑的领域,KEDA 如何使应用自动伸缩变得简单,以及为什么阿里云企业分布式应用服务(EDAS)在 KEDA 上完全标准化。联合作者 | Yan Xun,阿里云 EDAS 团队高级工程师...
  • ,这是大多数互联网公司已经有了,这类应用负载均衡不需要做会话保持,大量的状态都是放在共享的 Redis 或数据库中,这种应用能快速上云,能快速部署、弹性伸缩、自动容错,因为容器比较小,而且同时在一个集群中...
  • 知道了这两种具有“弹性”的架构模式,你该如何判断什么情况下需要搬出来用呢?   Z哥带你来分析一下每一种架构的优缺点,就能发现它适用的场景。     事件驱动架构 它的优点是: 通过「...
  • 自动缩放可以使用云托管环境的弹性的同时降低管理开销。不再需要操作员对系统性能持续监视,然后做出添加删除资源的决策。应用程序伸缩主要有两种方式:垂直缩放,也称为增加和减少,表示改变资源容量。...
  • 需要针对工厂现有资源和新建业务系统资源,部署一套基于云原生架构的混合云管理平台,构建混合云管理能力,支撑业务系统一致性部署、资源弹性伸缩、应用云化迁移、应用跨集群部署、构建云原生微服务体系。...
  • 可通过将任务处理单元进行独立部署和伸缩来提高性能、可伸缩性和可重用性。问题背景应用程序需要执行不同复杂任务,每个任务包含不同的信息。一种不太灵活的实现方式是将应用程序作为一个整体模块来执行。但是如果...
  • 弹性裸金属服务器有哪些特点优势?我们将弹性裸金属服务器分...2017年10月鹿晗关晓彤恋情引发微博瘫痪,此类业务特征是:业务流量瞬时暴涨,需要后台必须具备分钟级业务弹性伸缩能力。此种情况下,弹性裸金属服务器...
  • 碳纳米晶体 北京时间9月6日消息,芯片制造商现在面临一定的困难,它们要用更小的制程制造更快的CPU,正因如此,芯片企业已经开始寻找“硅”的替代品,比如碳纳米,最近,碳纳米技术取得了重要突破。 美国...
  • 节点的增加涉及到的组件有,节点准备,弹性伸缩(ESS),管控,Cluster Autoscaler 以及调度器。 手动添加已有节点 节点准备,其实就是把一个普通的 ECS 实例,安装配置成为一个 K8s 集群节点的过程。这个过程仅靠一...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 6,885
精华内容 2,754
关键字:

弹性伸缩管