历经 7 年双 11 实战,阿里巴巴是如何定义云原生混部调度优先级及服务质量的?

本文涉及的产品
性能测试 PTS,5000VUM额度
应用实时监控服务-应用监控,每月50GB免费额度
可观测监控 Prometheus 版,每月50GB免费额度
简介: 本文将聚焦在 K8s 层的容器优先级和服务质量模型上,希望给业界提供一些可借鉴的思路。

作者:南异


引言


阿里巴巴在离线混部技术从 2014 年开始,经历了七年的双十一检验,内部已经大规模落地推广,每年为阿里集团节省数十亿的资源成本,整体资源利用率达到 70% 左右,达到业界领先。这两年,我们开始把集团内的混部技术通过产品化的方式输出给业界,通过插件化的方式无缝安装在标准原生的 K8s 集群上,配合混部管控和运维能力,提升集群的资源利用率和产品的综合用户体验。


由于混部是一个复杂的技术及运维体系,包括 K8s 调度、OS 隔离、可观测性等等各种技术,本文将聚焦在 K8s 层的容器优先级和服务质量模型上,希望给业界提供一些可借鉴的思路。


K8s 原生模型


在实际的生产实践中,即使是很多对云原生和 K8s 比较熟悉的技术人员,往往也会混淆调度优先级(Priority)和服务质量(QoS)。


所以,在谈混部的模型前,首先我们对 K8s 原生的概念做详细的介绍,详见下表:


1.png


从 API 层面详细描述的话,可以看下面这张表


2.png


混部需要解决的问题


混部主要解决的问题是,在保证部署应用的服务等级目标 SLO 的前提下,充分利用集群中的空闲资源,来提升集群整体的利用率。


当一个集群被在线服务部署分配部署完以后,由于在线应用的高保障的特性,会给容器一个 peak 的资源规格,这样有可能导致实际真实利用率很低。


3.png


我们希望将这部分空闲但是未使用的资源超卖出来提供给低 SLO 的离线作业使用,以此提高整体机器水位。这样就需要提供基于 SLO 的调度能力,以及考虑到机器真实资源水位进行调度,避免热点的产生。


另外,由于在线通常 SLO 比较高,离线 SLO 比较低,那么当机器水位整体提升过高的时候,可以通过抢占离线的作业方式,来保障在线应用的 SLO。以及需要利用率内核层面 cgroup 的隔离特性来保障高 SLO 和低 SLO 作业。


那么,在这些在线和离线的 Pod 之间,我们就需要用不同的调度优先级和服务质量等级,以满足在线和离线的实际运行需求。


云原生混部定义的应用等级模型


首先请看一下在混部中一个 Pod 的 yaml 是怎么定义的


apiVersion: v1
kind: Pod
metadata:
  annotations: 
    alibabacloud.com/qosClass: BE # {LSR,LS,BE}
  labels:
    alibabacloud.com/qos: BE  # {LSR,LS,BE} 
spec:
  containers:
  - resources:
      limits:
        alibabacloud.com/reclaimed-cpu: 1000  # 单位  milli core,1000表示1Core
        alibabacloud.com/reclaimed-memory: 2048  # 单位 字节,和普通内存一样。单位可以为 Gi Mi Ki GB MB KB
      requests:
        alibabacloud.com/reclaimed-cpu: 1000
        alibabacloud.com/reclaimed-memory: 2048


这是在混部里面我们引入的 Pod 的等级,和社区原生不同的地方在于,我们显式的在 anotation 和 label 里面申明了 3 种等级:LSR、LS、BE。这 3 种等级会同时和调度优先级(Priority)、服务质量(Qos)产生关联。


具体的每个容器的资源用量,LSR 和 LS 还是沿用原有的 cpu/memory 的配置方式,BE 类任务比较特殊,通过社区标准的 extended-resource 模式来申明资源。


那么,这 3 类等级具体代表的运行时含义又是什么呢?可以参考这个图,看下这三类应用在 CPU 上的运行时的情况


4.png


以及详细的对其他资源使用的影响:


5.png


可以看到,这个等级,不但和 Pod 在单机上运行的 CPU、内存有关,还和网络 Qos 的全链路优先级有关,避免低优的离线类任务抢占了所有的网络带宽。阿里在内核方面做的工作有效的保证了运行时的应用稳定性,2021 年双 11 期间,阿里成为全球首家将所有业务都放在自家公共云上的大型科技公司,这意味着阿里云有能力应对高难度复杂环境下的技术挑战,也带来了非常大的技术收益:阿里巴巴业务的研发效率提升了 20%、CPU 资源利用率提升 30%、应用 100% 云原生化、在线业务容器可达百万规模,同时计算效率大幅提升,双 11 整体计算成本三年下降 30%。在这个过程中,混合部署技术发挥了重要作用。内核团队及云原生团队工程师踩了无数的坑,沉淀了包括弹性 CPU 带宽、Group Identity、SMT expeller、memcg 异步回收、内存水线分级、memcg OOM 等多项高级特性,处于业界领先水平。这些工作都会在系列的文章里面后续一一介绍。


当这三种类型优先级任务实际在调度和运行时发生的行为,如下面这个表所示


6.png


也就是说,混部的优先级会同时作用于调度和运行时,最大程度的保证高 SLO 的高优、中优任务使用集群内的资源。


配额、水位线、多租隔离


本文仅聚焦讨论了 K8s 单 Pod 的调度优先级,在实际使用时,为了保证应用的 SLO,需要配合单机的水位线、租户的配额、以及 OS 隔离能力等等使用,我们会在后续文章里面详细探讨。


相关解决方案介绍


进入了 2021 年,混部在阿里内部已经成为了一个非常成熟的技术,为阿里每年节省数十亿的成本,是阿里数据中心的基本能力。而阿里云也把这些成熟的技术经过两年的时间,沉淀成为混部产品,开始服务于各行各业。


在阿里云的产品族里面,我们会把混部的能力通过 ACK 敏捷版,以及 CNStack(CloudNative Stack)产品家族,对外进行透出,并结合龙蜥操作系统(OpenAnolis),形成完整的云原生数据中心混部的一体化解决方案,输出给我们的客户。


参考文档


1)https://kubernetes.io/docs/concepts/scheduling-eviction/


2)https://kubernetes.io/docs/concepts/workloads/pods/disruptions/


3)https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/


4)https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/


5)https://kubernetes.io/docs/tasks/configure-pod-container/extended-resource/


6)https://my.oschina.net/HardySimpson/blog/1359276


文内详情链接


1)节点压力驱逐(Node-pressure Eviction):

https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/


2)PriorityClass:

https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass


3)PodDisruptionBudget:

https://kubernetes.io/docs/tasks/run-application/configure-pdb/


4)Eviction:

https://kubernetes.io/docs/concepts/scheduling-eviction/api-eviction/


5)QosClass:

https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/


6)PriorityClass:

https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass


7)PodDisruptionBudget:

https://kubernetes.io/docs/tasks/run-application/configure-pdb/


8)Eviction:

https://kubernetes.io/docs/concepts/scheduling-eviction/api-eviction/


点击此处,即可查看阿里云专有云敏捷版云原生 Stack 相关介绍!



相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
1月前
|
运维 Cloud Native 云计算
云原生之旅:Docker容器化实战
本文将带你走进云原生的世界,深入理解Docker技术如何改变应用部署与运维。我们将通过实际案例,展示如何利用Docker简化开发流程,提升应用的可移植性和伸缩性。文章不仅介绍基础概念,还提供操作指南和最佳实践,帮助你快速上手Docker,开启云原生的第一步。
|
1月前
|
边缘计算 运维 Cloud Native
云原生技术的崛起:重新定义软件开发与运维
云原生技术的崛起:重新定义软件开发与运维
|
4月前
|
运维 Cloud Native Devops
一线实战:运维人少,我们从 0 到 1 实践 DevOps 和云原生
上海经证科技有限公司为有效推进软件项目管理和开发工作,选择了阿里云云效作为 DevOps 解决方案。通过云效,实现了从 0 开始,到现在近百个微服务、数百条流水线与应用交付的全面覆盖,有效支撑了敏捷开发流程。
19378 30
|
3月前
|
运维 Cloud Native Docker
云原生技术入门:Docker容器化实战
【9月更文挑战第20天】本文将引导你走进云原生技术的世界,通过Docker容器化技术的实战演练,深入理解其背后的原理和应用。我们将一起探索如何在云平台上利用Docker简化部署、扩展和管理应用程序的过程,并揭示这一技术如何改变现代软件的开发和运维模式。
|
4月前
|
Kubernetes Cloud Native Docker
云原生入门:Docker容器化部署实战
【8月更文挑战第31天】在数字化浪潮中,云原生技术成为企业转型的助推器。本文通过Docker容器化部署的实践案例,引导读者从零基础到掌握基础的云原生应用部署技能。我们将一起探索Docker的魅力,学习如何将一个应用容器化,并在云平台上运行起来,为深入云原生世界打下坚实基础。
|
5月前
|
Cloud Native
云原生部署问题之什么是结构体,并给出一个结构体的定义和初始化示例
云原生部署问题之什么是结构体,并给出一个结构体的定义和初始化示例
56 10
|
4月前
|
Cloud Native 关系型数据库 分布式数据库
云原生数据库2.0问题之DBStack的定义如何解决
云原生数据库2.0问题之DBStack的定义如何解决
|
5月前
|
Kubernetes Cloud Native 微服务
企业级容器部署实战:基于ACK与ALB灵活构建云原生应用架构
这篇内容概述了云原生架构的优势,特别是通过阿里云容器服务Kubernetes版(ACK)和应用负载均衡器(ALB)实现的解决方案。它强调了ACK相对于自建Kubernetes的便利性,包括优化的云服务集成、自动化管理和更强的生态系统支持。文章提供了部署云原生应用的步骤,包括一键部署和手动部署的流程,并指出手动部署更适合有技术背景的用户。作者建议在预算允许的情况下使用ACK,因为它能提供高效、便捷的管理体验。同时,文章也提出了对文档改进的建议,如添加更多技术细节和解释,以帮助用户更好地理解和实施解决方案。最后,展望了ACK未来在智能化、安全性与边缘计算等方面的潜在发展。水文一篇,太忙了,见谅!
|
6月前
|
人工智能 Cloud Native 安全
云原生技术的融合与创新:构建未来的软件定义世界
【6月更文挑战第5天】随着企业数字化转型的深入,云原生技术以其灵活性、可扩展性及成本效益成为推动这一进程的关键力量。本文将探讨云原生技术的核心概念、优势以及它如何与其他先进技术如人工智能和大数据相结合,为企业带来前所未有的效率提升和业务创新。
|
7月前
|
Cloud Native 关系型数据库 分布式数据库
【PolarDB开源】PolarDB数据迁移实战:平滑过渡至云原生数据库
【5月更文挑战第24天】本文介绍了如何平滑迁移数据至阿里云的云原生数据库PolarDB,包括迁移准备、策略选择、步骤、验证及示例代码。通过需求分析、环境准备和数据评估,选择全量、增量或在线迁移策略。使用数据导出、导入及同步工具(如DTS)完成迁移,并在完成后验证数据一致性、性能和安全。正确执行可确保业务连续性和数据完整性。
246 1