网站建设 锋云科技,文创网站,网站建设与维护1997年,漂亮的网页设计欣赏简介#xff1a;2021年双十一是阿里巴巴集团的核心应用全面云化的第二年。今年在保证稳定性的前提下#xff0c;主要探索如何利用云原生的技术优势#xff0c;降低成本#xff0c;提升资源利用率。在今年大促中#xff0c;针对核心集群采用独享共享实例混部#xff0c;统…简介2021年双十一是阿里巴巴集团的核心应用全面云化的第二年。今年在保证稳定性的前提下主要探索如何利用云原生的技术优势降低成本提升资源利用率。在今年大促中针对核心集群采用独享共享实例混部统一了底层资源结合交易业务云盘化使得混部单元大促成本下降30%。
引言
2021年双十一是阿里巴巴集团的核心应用全面云化的第二年。今年在保证稳定性的前提下主要探索如何利用云原生的技术优势降低成本提升资源利用率。在今年大促中针对核心集群采用独享共享实例混部统一了底层资源结合交易业务云盘化使得混部单元大促成本下降30%。
云原生数据库管控
随着云原生技术的普及越来越多的应用开始运行在Kubernetes上Kubernetes有一统应用交付界面的趋势。数据库产品内部也在全面推进云原生期望通过资源池化及与云基础设施深度集成释放数据库产品能力数据库管控本全面基于Kubernetes来编排DB实例。由于单一的Kubernetes集群规模限制无法满足DB实例的部署规模所以我们设计了一套多集群的调度编排系统能够支持多个Kubernetes集群的资源调度。
接入Kubernetes集群的Node数据库不同的产品会在以下2种模式下根据业务特定自行选择
单实例独占ECS Node节点实例独占资源调度工作有ECS完成特点是节点间隔离性较好但是由于ECS的资源严格限制也导致了一些在稳定性和性能的问题ECS资源池模式数据库团队维护一个由较大规格的ECS组成的资源池由数据库的二次调度在资源池内进行调度。特点是可以在多Pod间协调资源提升产品的稳定性和性能。
对于第二种构建ECSPool由数据库团队进行二次调度的场景下要求采用cgroup隔离组的模式进行实例Pod的资源限制对于云上的客户而言存在两种实例形态
独享采用cgroup里面cpu-set的模式来进行cpu资源的绑定共享采用cgroup隔离组的里面的cpu-share来进行资源隔离并一定程度上镜像cpu资源的超卖。
底层的ECS资源池会根据两种不同隔离模式严格划分分为独占资源池和共享资源池。某一个Node一旦分配了独享实例就不再允许分配共享实例严格划分了两个独立的资源池。 一般情况下资源池由阿里云数据库团队来进行统一调度。由于节点池足够大区分不同的资源池并不会产生资源利用不佳的情况。但对于服务于企业级的客户而言由于不与其他客户进行混合部署这种严格区分的模式资源利用率就不是最佳。举个例子客户由4个实例2个采用共享模式2个需要采用独占模式按照之前的调度逻辑客户则必须采购4台机器才能完成实例的部署。因此为了解决上面的问题我们希望能够将核心实例和非核心实例混部部署在同一台机器上。同时核心实例采用CPUSet的方式保证独享部分CPU核心非核心实例采用CPUShare的方式共享剩余的CPU核心实现资源的充分利用。
CPUSet和CPUShare模式混部方案
独享共享混部的前提是独享实例的性能不受影响因为必须对共享实例使用的资源进行限制。在Kubernetes中通过cgroup可以限制pod可以使用的cpu和memory的上下限。其中对于内存的限制比较简单给pod设置一个内存最大可用内存一旦超过内存上限就会触发OOM。对于cpu的限制Kubernetes采用cfs quota来限制进程在单位时间内可用的时间片。当独享和共享实例在同一台node节点上的时候一旦实例的工作负载增加可能会导致独享实例工作负载在不同的cpu核心上来回切换影响独享实例的性能。所以为了不影响独享实例的性能我们希望在同一个node上独享实例和共享实例的cpu能够分开绑定互不影响。
Kubernetes原生混部实现
在linux中通过cgroup的cpuset子系统可以实现绑定进程到指定的CPU上面docker也有相关的启动参数来支持绑定容器到指定的CPU上。
--cpuset-cpus CPUs in which to allow execution (0-3, 0,1)
--cpuset-mems Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems.Kubernetes 从1.8版本以后提供了CPU Manager特性来支持cpuset的能力。从Kubernetes 1.12版本开始到目前的1.22版本该特性还是Beta版。CPU Manager是kubelet中的一个模块主要工作就是给某些符合绑核策略的containers绑定到指定的cpu上从而提升这些CPU敏感型任务的性能。
目前CPU Manager支持两种Policy分别为none和static通过kubelet --cpu-manager-policy设置未来会增加dynamic policy做Container生命周期内的cpuset动态调整。
none: 为cpu manager的默认值相当于没有启用cpuset的能力。cpu request对应到cpu sharecpu limit对应到cpu quota。
static: 允许为节点上具有某些资源特征的 pod 赋予增强的 CPU 亲和性和独占性。kubelet将在Container启动前分配绑定的cpu set分配时还会考虑cpu topology来提升cpu affinitystatic策略管理一个共享CPU资源池最初该资源池包含节点上所有的CPU资源。可用的独占性CPU资源数量等于节点的CPU总量减去通过 --kube-reserved 或 --system-reserved 参数保留的CPU 。从1.17版本开始CPU保留列表可以通过 kublet 的 --reserved-cpus 参数显式地设置。 通过 --reserved-cpus 指定的显式CPU列表优先于使用 --kube-reserved 和 --system-reserved 参数指定的保留CPU。 通过这些参数预留的 CPU是以整数方式按物理内 核 ID 升序从初始共享池获取的。 共享池是 BestEffort 和 Burstable pod 运行 的 CPU集合。Guaranteed pod中的容器如果声明了非整数值的CPU requests也将运行在共享池的CPU上。只有Guaranteed pod中指定了整数型CPUrequests 的容器才会被分配独占CPU资源。
Kubernetes作为通用的容器编排平台其提供的绑核功能具有一定的局限性
需要显示开启且pod的QoS必须是Guaranteed级别数据库实例资源超卖pod的request和limit设置不同。kubelet的CPU分配策略固定且不支持灵活扩展不能满足独共享混部的调度场景。 不支持动态放开绑核限制。在大促的时候为了提高数据库性能有时需要临时放开实例的资源限制kubelet不支持放开绑核。
调度平台混部实现方案
Kubernetes默认的绑核能力其中绑核策略是放在kubelet里面不易修改和扩展而针对不同的业务场景绑核策略可能不同放在调度测统一管理更加合适。由于kubelet仅负责执行绑核而具体的绑核策略需要由上层业务来指定因此在创建CPUSet模式的pod的时候我们给pod打上annotaionkubelet在启动容器之前就会将pod绑定指定的CPU上。 annotations:alloc-spec: |{cpu: Spread}alloc-status: {cpu:[0,1]}alloc-spec指定具体的分配策略支持以下几种模式
Spread在物理核上打散绑定逻辑核在同物理核对端的逻辑上适宜放置压力小的应用统一调度也提供了应用间物理核堆叠约束的编排算法。SameCoreFirst同物理核绑定优先尽量讲逻辑核分配在相同的物理核上。BindAllCPUs绑定所有的 CPU 核。
alloc-status绑定的具体cpu核数。
当调度器在节点上分配或者释放 CPUSet 模式的 Pod 之后CPUShare Pod 可使用的 CPU 核数量将发生变化可以通过修改节点的annotation来告知 kubelet可share节点的范围
kind: Node
metadata:name: xxannotations:cpu-sharepool: {cpuIDs:[0,1,2,3,4,5,6,99,100,101,102,103]}
要实现独享共享混部只需要给独享实例指定为CPUSet模式共享实例指定为CPUShare模式就可以实现共享和独享实例CPU分开绑定互不干扰。但该方案有以下限制对Kubernetes原生的kubelet组件进行了定制开发这就限制了在通用环境下的部署。
基于调度器和扩展控制器的混部实现方案
上面分析了Kubernetes原生和调度平台的混部实现方案。从分析结果看都无法完全满足数据库这边对于实现独享共享混部方案的绑核需求我们希望在不修改Kubernetes源码的基础上能够支持不同的绑核策略。
在介绍我们的实现方案前先介绍下混部在数据库管控架构下主要涉及到的三个组件。
调度器调度器具有全局的资源视图能够根据业务指定的调度策略分配不同的CPU核心。当前支持的CPU调度策略包括独共享、NUMA亲和性和反亲和性IO多队列分布等控制器负责将调度器分配的CPU核心设置到pod的annotation上并对业务提供查询接口cgroup-controller以daemonset的方式部署在每个node节点上watch本节点的pod资源当发现pod的annotation上有绑核信息时修改pod对应的cgroup cpuset配置完成绑核。
这套架构和原生Kubernetes集群相比最大的区别有两个地方第一多Kubernetes集群调度解决数据库规模化对单集群的约束第二数据库资源调度与实例创建逻辑解耦资源调度发生在pod的创建之前。在实例创建的时候先通过调度器调度分配资源成功后业务才会发起任务流拉起实例。
调度器
调度器的核心流程和Kubernetes调度器流程类似Filter - Ranker - Assume - Process pod
Filter : 过滤不符合要求的NodeRanker : 计算Node分值并选择分值最高的NodeSync Process Pod 异步处理资源申请云盘、安全组、ENI等
在独共享混部中调度器负责为独享实例分配具体的CPU核心CPU核心的分配策略支持业务自定义。在集团的独共享混部场景中主要实现了以下逻辑流程
Node CPU data/state初始化和同步
IO队列分布信息和具体的物理机型号有关node节点在上线的时候会由将node的IO队列信息打到node的annotation上调度器会watch到node节点的IO队列信息并进行有效性校验并初始化。当调度器会watch到annotation变化且满足以下两个条件会更新CPU信息。
CPU是弹升原IO队列CPU分布和新的IO队列相同CPU分布完全一致
独享实例绑核IO队列打散
在选择独享实例CPU核心的时候会考虑按IO队列打散。 打散策略依赖node的cpu分配优先级上图箭头指向是优先级由高到低
混部Filter编排
调度器解耦不同Filter以插件化编排的方式实现定义不同业务的Pipline
应用维度全部做反亲和处理
无论独享还是共享同一应用在同一台机器上只有1个节点确保集群维度在单机故障时的影响最多1/N
resourceSet.spec.scheduleConfig.policy.machineMaxList.N.key ${APP_NAME}
resourceSet.spec.scheduleConfig.policy.machineMaxList.N.value 1申请一个inver业务的PodmachineMaxKeyinve、value1过程如下 共享独享CPU混合调度
未分配的主机(104C)预留8C最大可分配是96C。调度两个32C的共享实例再释迁移一个32C的共享实例流程如下图 单个ECS独享实例可售最大CPU比例为2/3即96核物理CPU可售卖的最大独享CPU为64核剩余32核按固定超卖比超卖给其他实例 (独享实例不可占用整台机器) 可售独享实例CPU计算: 可售CPUmin(a,b)
a. 可售CPU规格单机可售物理CPU-max(共享实例规格)*2 b. 可售CPU规格 【单机可售CPU - sum(共享实例已售CPU)】/超卖比
控制器
控制器为业务屏蔽了底层Kubernetes资源接口业务所有的操作全部由控制器来统一进行转换。在独共享混部方案里面控制器负责将调度器分配的绑核信息更新到pod的annotation上并在pod启动的时候校验启动的绑核信息是否正确。同时在大促场景中一旦独享实例出现性能瓶颈需要能够临时占用整机的cpu资源控制器负责向业务提供临时放开CPU绑核的限制的接口。 #独享实例pod需要指定的annotationannotations:cpu-isolate-mode: exclusive #指定为独享实例custom-cgroup-info: {engine:{cpuset:2-3}} #指定具体容器绑定的cpu核心exclude-reserve-cpuset: true #是否需要扣除node上预留的cpu核心release-isolate-mode: true #是否需要临时放开绑核限制如果设置了可以绑定除了预留所有cpu核心大促时候的应急预案cgroup-controller
cgroup-controller是Kubernetes里面的一个扩展控制器它通过daemonset的方式部署在Kubernetes集群里面它将宿主机上的/sys/fs/cgroup/目录挂载到容器内在watch到pod需要绑核时根据pod的qos等级找到对应的cgroup配置路径直接修改cgroup的配置文件。 volumes:- hostPath:path: /var/run/type: Directoryname: docker-sock- hostPath:path: /sys/fs/cgroup/type: Directoryname: cgroups
在独共享混部的方案里面cgroup-controller除了需要能够为独享实例绑定CPU核心以外还需要维护共享实例的CPU资源池。cgroup-controller会记录当前节点上独享CPU和共享CPU的核心分布当节点上的独享实例发生变化时动态调整node上共享pod的可用的CPU列表。例如当前node节点预留CPU:[0-1]调度了一个独享实例占用CPU:[2-3]cgroup-controller会计算当前node节点上的共享CPU总的CPU-node预留-独享CPU并将共享pod全部绑定到共享CPU核心上。当再调度一个独享podcgroup-controller会更新共享CPU核心并刷新主机上所有共享POD绑定的CPU核心。 cgroup-controller通过直接修改pod的cgroup配置来实现动态调整pod的资源配额虽然不需要浸入kubernetes源码但也存在以下几个问题
cgroup-controller只能在容器启动后才能修改容器的资源配额当独享实例发现变化时会动态刷新共享实例的CPU绑核对共享实例的性能可能存在一定的影响
cgroup-controller能够直接操作DB实例cgroup的资源限额能够直接影响DB实例的数据面所以在具体执行修改时会做一些必要的安全检查。比如在设置独享实例的绑定的CPU时会校验绑定的核心是否满足IO队列分布绑定的CPU核心是否超过单节点可售卖独享CPU的核心数等。
原文链接 本文为阿里云原创内容未经允许不得转载。
