开发者学堂课程【云原生技术趋势与行业发展解读：混部开源 Koordinator 背后的故事】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1035/detail/15147
混部开源 Koordinator 背后的故事
十二、互动与讨论
（1）阿里巴巴对混部技术发展的期待
阿里巴巴双11大量依靠离在线混部节约了整个大促的成本，目前阿里巴巴整个离在线混部具有一个专门的工程，其在阿里巴巴集团被成为快上快下。个人希望阿里混部能够不断完善与发展，能够更大程度减少在双11开发同学对混部的感知，也即为希望混部系统能够向更加自动化的方向发展。在今年，阿里巴巴具有一个大的目标，即为希望真正能做到大促零成本，其也即为混部十分具有挑战的事情。
（2）企业应用混部技术所面临的最大的挑战与应对挑战的经验分享
因为企业做混部，并不要求企业做混部的技术有多高或者一个产品有多厉害，而是企业要有能力解决企业自身混部的问题。个人仍旧需要将企业整体成本和利用率做好，因为其为混部最大的收益，个人如何提升资源效率，降低运营成本。
此时即需要结合企业内部的业务特点进行梳理，到底哪一些业务适不适合做混部，例如如果全都是以同一时刻单一种类的产品、业务或对外的服务，其即很难进行混部，因为其风骨是没有办法使用差异化的任务去填的，所以此部分要求个人从自身的业务特点进行分析，例如延迟敏感型的业务与存储型的业务就很难进行混部或者做混部的必要性与整体的收益就需要做权衡的分析。集团应先讲清其收益和价值，但是收益和价值需要结合企业自身的业务特点与企业自身的流量或者所承担的业务特性、技术指标进行分析。第二个挑战为假设其做了且获得了收益，企业内部也已经确定了战略等待推进，则第二条即回归混部技术本身。
混部技术本身在当前通常基于k8s 进行。在k8s的生态里面，首先个人把整个k8s 的架构搭建起来，其对k8s 资源调度与管理模型比较了解，由此其并不算挑战，其仅仅为一个正常的门槛。当真正进行混步的时候，如何回答业务上所要求的解决混部干扰性并增强隔离性的问题，解决中心调度上的一些在混部差异化资源或服务等级上做的事情，为达成目的，其要具有一定程度的抽象并且其基本上需要一定程度的抽象才能够实现和设计。
其中也会涉及一些容器，例如安全容器、SA 容器、中心调度选择根据上层选择的内容选择相应技术。最后其在单机上可能还会具有一些保障机制，比如当出现资源抢占与超发的情况，如何进行避让，如何通过协调进行整体的控制。
最后一个即为技术已经完备且业务特点收益都可获得，则应当关注在落地的过程中，如何有节奏的逐渐的把一套系统稳定的推广到整个生产集群中，从而解决所有业务混部的需求和问题。此处设计较为繁琐，其本身为一个规模化带来的工程问题。
因为小规模验证一些小业务不会产生太大的风险，但也会存在很多问题，其也为Koodinator 社区推出来的内容，其希望用户进行测试，其也基本上不会产生应用较大安全性的问题与很大性能的挑战，因为在较少应用数量的情况下，其对于指标的敏感性都不强，利用率本身也不高。当单位代码大规模使用后，其所遇到的挑战就较多了，其延迟敏感型的应用会发生剧烈抖动，其抖动原因可能是因为内存带宽的抢占或网络隔离不好。
另外一个部分为规模化带来的工程问题需要仔细的进行打磨，需要对整个系统的稳定性和可靠性做设计，对其所支持的业务种类与详细的各种策略进行配置，对其参数进行仔细的梳理。在完成前部分操作后，其要推进配套的系统和运维能力和运维职责的建设和梳理，其实此也是一个很重要的过程。同时，此过程也要需要一定的组织保障，也需要其对整个混部具有一定的经验，将混部里面可能遇到的问题提前准备好，从而做好应对措施与预案，来避免混部出现一定规模的问题，阿里将其缩短到一定范围之内，从而使得其可控且不影响业务稳定的部分。根据阿里多年经验出发，此事情是完全具有可行性的，但是建议整体的系统经过一段时间的打磨，在遇到一些问题并解决问题后，整个系统的稳定性和可靠性才会达到整个符合企业内部的一个生产的过程。
（3）驱动阿里去做混部开源项目的原因
实际上是混部技术在整个行业大企业里面实际上为一个已经研发多年且比较成熟技术。阿里巴巴在当前基本上做到了全量的混部覆盖，阿里通过自身的实践也证明了混部技术能够给企业产生很大的价值并且将混部整体规模做的非常大。
在次之后，阿里巴巴有更大的信心去把混部技术去标准化，其希望能够让更多的企业使用混部的技术。当在混部整个发展阶段里面，在不同利用率下会有不同的挑战。如果个人关注到行业上所发布的一些数据，例如aws 在2021年发布的数据里面会显示整个aws 的资源利用率实际上迄今为止也保持在12%-17%的水平，即为行业的巨头只要整体能够看到行业情况，其仍旧处在一个比较低位的。每一个企业公司内部如果能够看到该数据，其心里面都会有一个水位线，阿里希望通过混部的项目，能够使个人更好的将自身的计算资源充分的发挥与利用。
另外一个出发点为在近两年疫情的当下，很多的企业都会进行降本增效的诉求，所以阿里也希望通过混部开源的项目能够助力其他企业更好的进行开源与降本增效的事情。
十三、Q&A 环节
（1）云原生混部的资源配额和k8s 社区原生的配额有什么区别
首先其应该非常清楚complex 社区的资源配合机制，其会提供到一些个人去支持做到的例如next phase 级别的限制，使得某些用户或者某些任务的资源不超过一个总量。
在整个Koodinator 里面，在当前版本上可能不存在，但实际上其是在阿里规划中的。因为阿里为了使任务能够充分的利用到集群资源，其整个的培养机制会设计mihumax 的弹性模型，即为最小的min 得到保证的部分通常个人要去做资源规划，比如整个集群会有一万核，其会卖多少min出去，此即有一个比较确定的资源规划。在整体使用资源的时候，因为每个任务都会有峰值的需求，所以阿里会允许任务做一定的资源超发，其可以使用操作密度小于max 的资源。如何保证各个资源之间的公平性，为此阿里拥有一套比较成熟的机制去确保当任务有资源需求时，阿里会合理的抢占超额使用资源部分的配额，回收其资源，从而分配给有需求的计算任务。另外其也存在细节上的区别，因为从实践经验出发，许多计算类型的任务会将不同的任务提交到同一个space 或一个任务可能分配到不同的space，所以阿里未来Koordinator 的配额机制将相对更灵活，阿里会通过labsnake 的方式进行关联，而不是通过限定napsnake 的方式。
（2）如何定义云原生混部调度优先级
如果个人进入过阿里巴巴官网，实际上可以看到阿里整体上会把任务的优先级进行分大类，阿里会区分延迟特别敏感的product 的资源优先级，然后通常优先级里面会指代例如中间键、阿里微服务、gb 或snake 类型等。再往下部分，阿里会有典型dase 的资源类型，它对通常对应着阿里大量的大数据的批处理计算类型的作业。中间会存在一个名为meet 的资源类型，它通常对应着比大气要求更高的内容，比如实时类的计算作业、AI 的训练作业等形态。然后再往下，阿里会有一个最低名为free 的资源优先级，它对应的为发掘集训中的空闲资源，其通常适用于不太需要保障的内容，比如研发个人临时提交的测试作业、个人要进行的调研作业等，其会以最低优先级的方式去运行。
总结起来为根据阿里巴巴内部职称特别多的工作时间的经验，整体上将阿里巴巴的优先级划分为四大类别，在类别内部其也支持不同的细化的优先等级。
（3）云原生混部是如何解决云上、云调度体系不一致带来的复杂性
首先，此复杂性是一定会存在的，毕竟云上和云下是两套体系和系统，在云上和云下也有自身不同的配套组件、UA 方式、资源管理方式。比如自身的账号、周边的管理系统等可能都存在差异。不一样的问题并不能仅仅通过一套稳固系统来解决，其复杂性天生是存在的。其相应的解决办法通过混部是很难把它的大部分复杂性消除，阿里希较好解决该问题的方式为其在云下的资源和云上资源的部分和服务都采用相类似或者至少接口相同的技术栈来保证阿里的资源可以在云上和云下做成类似的部属，即为部属方式比较一致。第二个为阿里在两套系统都采用K8S ，其能够让这k8s 都使用相同的资源管理模式，比如提供相同的配置文件，使用相同的混部参数等，都可以达到相类似的效果。
最后，阿里技术的底层都采用相类似的容器隔离技术，其也会很大程度上简化两套系统之间的配置、转换和切换。
由此，综合起来最好为相同的技术站，使用云上和云下一体的方式。其次，阿里也要采用一定程度接口的兼容性与配置的兼容性，其能够降低两侧之间配置管理的不同。最后，如果集团拥有此类云产品或者能够打通的底座的服务，可以使得集团在云上和云下保持一个比较一致的管理方式，由此，集团可以在云下将资源不足、需要弹性的资源放在云上去弹，通过云的资源开出来，给叠加系统进行管理和协同。此种方式在一定程度上会进行简化，但此问题随着集团使用公有云的形式越来越多，其一定会普遍存在，所以在一段时间之内，此种产品一定会越来越成熟，从而阿里实现一个本地和公有云在整体资源与容器层面上的资源整合与协调或者是在K8S 集群层面的打通和协调或者在上层的应用的管理部分做打通和协同的产品可能会更多，其形态和种类都会更加丰富，稳定性也会更好，所以基本上即可将成本降低。
（4）混部是否具有实际应用价值
混部其实包含两部分逻辑，一个即为通常在一台大物理机，其上面可以跑多个应用，类似的混部应为常态化的，其也已经不是当今阿里所强调的混部技术，今天阿里核心强调的是混部弹性的技术，其包括资源超卖、在离线优先级等混部场景。
对于中小企业而言，其核心的问题为是否存在在离线的任务类别，另外为他们之间是否存在类似于时分复用或者应用上互补的特性，比如存在计算密集的任务与io 密集的任务，将其放在一台机器上，则有可能节省整体的成本。
如果一个workload 较为匮乏的企业，建议其直接采用类似于ecs 的，因为ecs 本身即有混部的基础能力，即为用自己单一的workload 的特征，享受整个ecs 池子里面与其他公司的workload 进行混部，此操作可以从整体上节约资源的成本。比如云上的eci、针对离线作业的support instance 等情况都为对于中小企业最开始比较好的一个选择。此外，在线即有云上机器，又有云下的机器，则调度体系如何进行工作的问题，其会不会存在多个的复杂性问题。阿里巴巴当今有此种现实的场景，阿里巴巴从去年开始实现了所有新增的预算上云，其实阿里线下也有很多之前存量的部分机器，则从整体角度出发，解法为阿里核心依靠调度一层，即为混部技术落地的一层，其就是依赖于标准的调度系统，然后阿里屏蔽了底层基础设施的差异，那么阿里所有比较大的差异例如本地磁盘、云上ecs 等，其都是通过调度系统的扩展插件去屏蔽掉此种的差异。
（5）无状态下可以进行混部，那么在有状态下混部应如何进行操作
不仅仅为无状态可以混部，其实有状态也可以进行混合。刚才所提及的混部弹性的逻辑，其实为希望在针对弹性能力不强的workload 旁边跑一些轻量级的应用，当带状态的部分应用需要资源的时候，阿里能够轻易的把轻量级的应用迁移走。
比如旁边跑着离线任务，阿里通过线上即时的一线作业的压制来保证此部分带有状态的应用的资源诉求，此恰好为混部在解的一个核心的逻辑，即为整个应用弹性不足，其需要用混部技术进行兜底。另外一个为有存储部分，其截止今天，存储部分隔离的技术依然不是非常成熟，由此阿里一个较为核心的解法为依靠的整个应用架构的升级来解决该部分问题。
整个带存储比较重的部分，架构上整体去做存算分的架构升级，阿里会将存储部分进行剥离，将其在调度里面作为一些work load 进行编排。在其上面，阿里将其该部分计算逻辑是做的较为轻量，甚至有一些极端的workload 场景，阿里进行了在线存储计算分离。此部分为阿里后端的存储集群，其是把存储部分挪到另外一个存储集群去做io 服务。存储其实在阿里巴巴集团里面有名为盘古集群的项目，盘古自身为进行多处作物的迟化，其本身为一个偏应用级别的混部形态。
（6）集群底层使用虚拟机还是物理机居多，资源分配会超分多少
实际上因为阿里整体上做了很多年，其目前主主体上是云上的神农架ecs 的形态为资源主体，所以其应该更多关注为此内容。第二个为关于资源超分的问题，如果个人使用云上ecs 独享型，则其底层肯定没有资源超分。在集团购买ecs 之后，个人构建一个Kubernetes 集群，此时标准的Kubernetes 集群实际上是不会进行资源超分的，而阿里的Koodinator 混部项目实际上为帮助个人在标准的Kubernetes 集群之上进行资源的超分，但具体超分多少并不是一个静态的比例，阿里会根据已经分配的资源使用的情况，比如其负载特别低且此节点可用资源比较多，则阿里会多调动一些任务，如果其本身的负载比较高，则可能其也没有办法额外超分出更多的资源。所以具体能超分多少并没有一个固定的说法，可能个人更多需要关注为标准的Kubernetes 集群的分配率与集群里面所有节点的资源使用率之间的Gan，此可以用来衡量整体Kubernetes 集群是否具备了混部的潜力。比如有非常多且适合混部的负载，但其最大可以填充到的可能性为整体的从分配到使用中间的一段Gan，其会为稳定性预留一些方法，但整体上去衡量一个集群理论上最大的可混部状态，实际上看其整体的节点利用率的平均情况。
（7）离线作业跑到线上集群上还是跑到应离线集群上
离线作业其实是有几种形态的，一种为离线作业独占集群，此也为目前很常见的一种方式，即为离线集群单独搭建一个spark。在此种情形下，其实也需要隔离及一定程度的抢占和超发及so，本身离线作业是一大类，只不过它的类型属于离线作业，但并不代表所有的离线作业都为低优先级的作业，都不需要做抢占超发并且离线集群利用率非常高，并且在此情形下，其混部与抢占也是非常重要的。其对调度器的性能要求要求也很高，因为它影响了整体的吞吐，影响了整个作业的时延，尤其个人进行许多并行计算相关的任务，单一作业的卡顿都会影响整体的分组。第二个部分为离在线混部，离在线混部通常听到较少，因为通常情况下都为在离线混部，其先后顺序其实有一定的关系。
离在线混部即为离线的任务会跑到在线的集群上，run 通过在线集训的作业给离线提供服务。此种情况下，利用在线集群的闲置资源将离线跑起来，此即为第二种形态。此种形态其实为日常生活较为常见的，也是挑战最大的部分。因为在线资源整体是属于在线的，阿里所有的离线任务其实是属于借用或者为一定程度的分配了在线的资源，但是又需要在离线资源需要的情况下将其退回给在线。所以此种情况下会出现一定问题，例如在线原来单独继续运行，其互相之间利用率也不高，干扰也弱，此影响几乎可以忽略，但是将离线任务放后，随着利用率的提升与各种资源的抢占，各种资源的抢占与超发就会出现。所以，在此情况之下其被认为是最难解决的问题，即为如何使得离线跑上来并且在其跑得好的情况下，又不影响在线，离在线互相之间没有干扰。此为目前差异化so Koordinator 里面提供的主体功能区，其用于解决这一类的混部、隔离与抢占的问题。通过设计差异化的so，把整个集群的资源进行分类，然后高地又分别进行填充，通过调度器和单机的格局参数进行配置所整体的协同。离在线为另外一种情况，其就是以离线为主体，整个集群的任务都属于离线的，但是上面有一定程度的资源可以空闲出来给在线或者在一定条件下可贡献出来给在线使用，此在某些特定场景里面也会出现并且此种场景下相比于在离线而言，其对于整个资源的腾挪和资源的准备时间要求比较高，对整个离线调度器作业的协调配合要求比较高，对于在线而言，其根据设定模式的不同，有可能为离线，尽管为以离线为主的集群，但是还是把主体高优先级的资源都交给在线来使用，此时对在线而言，其与在离线的影响并不大。另外一种为在线需要容忍并且做一些容错，其需要容忍一定程度的失败，在此种情况下，对于在线而言，在线就需要挑任务与混部的方式来做，但是其需要具体情况具体分析。如果资源整体不足，其就不得不进行一些协调避让。最后一种为纯在线。其实在线的种类具有很多，例如目前的实时计算、以计算为主的负载等，原来并为对其归类，但现在其属于在线的部分，其即在在线区内做很高的利用率。此种情况也会存在于业务特点本身即为整体都属于在线任务，但是里面有一部分属于计算密集型或内存等，此类型的任务也可以放在一起进行混部。在此种形态下，其实其混部的挑战呢与前面几种存在一些不同，不同即为都是在线任务，也都需要考的好，但是还需要利用率较高。此种情况下，其收益也比较巨大。收益较高因为我同样的资源，高优先级的资源可以同等程度的节省，但是挑战也较大，因为其对所有的资源要求都较为苛刻，所以此种挑战对整体的挑战也是较大的。其还包括差异化硬件，比如ego硬件上具有gpu 和cpu，其是否能够进行混部，其实是可以的。各自的业务特点都具有各自要求，整个的要求也各有不同，但此些不同如果每个业务单独打磨，其实个人都可以将其做出，但如果个人想做一个系统，将整个都串连起来，每个业务都打磨较好，然后做一些混部，因为业务种类可能较多且每个都不带，其实建议个人采用Koodinator 的开源框架直接在Koodinator 设计的思路和当前交付的开放性的框架基础上,个人进行做这个二次的作业适配改造与做贡献的方式，逐渐地将其打磨出来，从而做成这样的混部系统，可能较为符合最终的混部形态。
（8）系统学习的路线
混部的技术其实是一个领域很宽的技术，其中其实涉及到整个计算机体系结构以及操作系统的，特别像内核的调度、内存、内存管理以及io 调度器的领域。
再往上层出发即到整个调度的一层。调度的核心技术点，其实个人可以去参加社区了解K8S 以及今天在k8s 体系下发混部技术，此些点在分布式系统调度层的分支系统。在其中核心的调度逻辑为哪些作业可以跑到一起，其中其实又涉及到数据分析、应用画像以及决策智能，该部分的逻辑都是在调度里面涉及到的，此即为混部的底座。
其实其中个人为了能够将混部跑好，即为真实地将利用率提供，其中实际上谈论内容即为整个应用架构如何与底层的调度系统进行配合，其中特别包括设计的中间价。
流量调度部分其实是需要引起关注的内容，因为混部在目前的技术下，特别在高水位缓和的情况下，整体的业务的抖动或者为对在线延时，其实阿里是有百分之十几的增加，其中其实需要整个应用架构进行升级与改造，以此来适应整个的混部体系。
