2022年4月6日，阿里云原生混合系统Koordinator宣布正式开源。据介绍，Koordinator在阿里巴巴内部大规模应用实践积累多年，在2021年“双11”期间计算成本降低50%起到了关键作用。这个大规模实践项目来自于什么？阿里巴巴？它的开发背景、技术原理和开源规划是怎样的？阿里内部如何利用混合技术解决“双11”等极端场景下的资源挑战？前不久，在【TTALK】系列活动第五期中，阿里的三位技术大牛Yichuan、曾繁松、杨国栋从Koodinator项目入手，为我们分享了技术背景、实现经验和Hybrid技术对未来演化的思考与展望。【TTALK】也梳理了本次直播的核心内容，希望能给大家带来一些不一样的思考和启发：混科技术的概念可以从两个方面来理解：从节点粒度来看，混科是在同一部分部署多个容器或应用程序。其中，多容器包括多个在线容器、多个离线容器和多个离线在线容器，并不局限于传统理解中的离线容器。单节点是可以运行容器的最小单元，包括物理机、单个ECS等。另一方面，从集群粒度的定义出发，将多个应用自动部署在一个集群中，通过对应用特性的预测分析，实现业务间的移峰填谷。这是混合部署。总的来说，混合部门希望达到的是用更少的资源去跑所有的任务，从而达到降本增效的最终目的。通过上面混合系的定义，我们可以梳理出混合系的两大核心技术。1、Node-粒度容器隔离技术：包括依赖内核的kangaroo、RunC等；单机调度技术：包括单机负载感知、容器策略和阈值设置、容器优先级和伸缩控制、cpushare等；集中调度技术：支持单机粒度资源差异化SLO技术：包括差异化SLO设置、优先级设置、单机与基于差异化SLO的集中调度协同。2、集群粒度：实现基于节点粒度的中心调度技术：高性能调度、资源视图、多负载调度协同、GPU拓扑感知等；单机调度技术：任务的高频启停控制、单机多环境、硬件适配、cpu归一化等；k8s生态框架优化及配套能力建设：包括集群规模突破、稳定性提升、运维配套能力、接口与接口能力、业务对接等。作为业界混合技术的先行者之一，阿里从2011年开始探索容器技术，2016年开始混合技术的研发，至今经历了多轮技术架构升级，最终演进为今天的云原生混合系统。该架构直接采用基于K8S的云原生统一调度，实现多任务、多负载协同感知，达到全部门协同的效果。这也是目前已经验证过的最理想的架构和最好的工程实现。如今，业内很多公司都在关注混合部门，希望能够快速获得混合部门带来的收益。对此，第一个解决方案是直接采用公有云或者商业产品，默认会承载一些混合和弹性的支持。第二种方案是开源共建。这种方式既可以保证团队自建的效果，又可以利用开源社区积累的各层技术栈的经验。这是目前推荐的解决方案。阿里云原生混合系统KoordinatorKoordinator是脱胎于阿里巴巴的混合系统，于2022年4月6日正式开源（https://koordinator.sh）。Koordinator的技术基础和整套系统设计思路都来源于阿里内部多年的实践经验。阿里希望通过开源推动整个混合技术的标准化，让更多的用户应用混合并从中受益。目前Koordinator项目包含的内容分为三个部分：差异化SLO：在Kubernetes之上抽象出一套面向QoS的资源调度机制，同时在优先级内划分不同的QoS，保证每个优先级和QoS资源特性；精细化资源调度：阿里最佳实践，包括CPU拓扑感知、性能优化调度、资源预留、交互式抢占、碎片整理、资源预览、GPU共享调度、算力归一化；tasksScheduling：大数据和AI相关的任务调度，如Gang、batch、优先级抢占、弹性配额（队列间借用）等，更好的应用整个集群资源。从整体架构来看，Koordinator项目的技术也分为三个模块：最底层是Koordlet模块，负责单机对应的一些技术能力，比如特征感知，stand-单机级干扰监控，以及一些QoS管理和单机资源隔离。当然，Koordinator组件也会在单机上扩展一些运行时管理器角色，帮助适配各种运行时，同时避免对底层基础组件进行侵入式修改。中心有两个主要角色。第一部分是KoordinatorScheduler，包括调度特性和slave调度特性。虽然一般情况下，做调度的概率要比做slave调度高很多，但是slave调度也是混部门项目中非常关键的一环，可以保证整个集群资源的运行质量持续保持一个高水平。第二部分是KoordinatorManager，主要用于混合部署策略的管理，包括如何访问工作负载。此外，KoordinatorManager还集成了一个资源画像模块，目的是为了更好的支持调度器，更好的分配资源，避免本地机器出现热点，导致服务受损。以上就是Koordinator的整体结构。以上模块的核心目标是帮助大家解决混合部门的两个核心问题：第一个问题是如何对接混合部门的工作负载，让各种任务最低可以对接到Koordinator混合部门成本在框架内；第二个问题是如何让各种任务在混合的情况下运行良好，让计算任务获得需要的计算能力，不影响在线任务的运行延迟。Koordinator作为一个比较成熟的混合系统，具有“双零入侵”的特点。首先，Koordinator对应用程序工作负载管理是零干扰的。Koordinator将投入大量精力帮助用户打通典型计算负载的混合部门链接。用户只需要进行简单的配置，Koordinator会应用一些配置好的yaml自动将计算任务转换为混合部门任务。这样就避免了对这些计算框架的修改，可以帮助用户快速实现混合化到企业内部场景。第二个零入侵是指Koordinator对Kubernetes没有任何入侵。在Koordinator支持的Kubernetes版本上，用户可以将开源组件安装到自己的Kubernetes集群中，以获得相应的能力。Kubernetes的扩展性在中心端非常好，但在节点端很差。所以在Koordinator项目的Kubelet和底层容器运行池之间有一个HookManager来支持策略的扩展，从而避免了对Kubelet的需求和对底层Containerd或者Docker的Intrusive修改。在整个混合部门中，最重要的就是资源模型。混合部门最本质的是发展差异化的能力，这样才能超发资源，提高资源的利用率。这一系列过程是相反的。Koordinator定义的资源模型非常完备，可以支持在线服务、实时计算、AI训练任务、批量计算任务，甚至一些测试任务都可以通过这个资源模型来满足。此外，Koordinator还提供了各个资源维度的资源隔离技术，比如CPUcquset、LLC的一些隔离能力、操作系统提供的优先级抢占能力等。这些隔离能力以后会在Koordinator社区中呈现，大家会逐渐看到这些针对不同资源特性的隔离能力和干扰检测能力。Koordinator基于Kubernetes社区，但Koordinator不会对Kubernetes社区做任何改动。用户在使用混合技术时，首先会应用到Kubernetes上，然后在Kubernetes上安装Koordinator对应的组件。这就是Koordinator的上下游关系情况。Koordinator社区提供的能力与企业内部真实环境所需要的能力可能存在一些差异。用户可以基于社区使用自己的内部版本，结合企业特性来兼容一些老场景。通过这种方式，他们可以更好地与整个Koordinator社区协作。Koordinator社区会很快迭代。在这种模式下，用户可以不断从社区获得新的特性，只需要在内部版本中维护自己企业非专业化的部分。如今，阿里巴巴基本实现了混合部署的全量覆盖，也通过自身的实践证明了混合部署技术能够为企业带来巨大的价值。阿里希望通过开源推动混合技术的标准化，让更多的用户能够更方便地应用混合技术并从中受益。未来Koordinator社区也会定义一些不同的角色，非常欢迎大家参与其中，继续通过开源做出更多的贡献。混合部门的实践和发展前景阿里巴巴集团有两种典型的混合部门场景，其中一些是常态化的，混合部门日常主要使用的是容灾余量。进行大数据计算，提高整体资源利用率。另一部分是“双11”等应用场景。阿里的在线流量是日常流量的十倍左右。按照传统的资源准备方式，需要准备十倍的机器才能支撑大促的资源需求。而阿里则将MaxCompute、批处理、非实时任务视为线下任务，通过大量降级将资源释放给线上业务，以减少大促期间的资源购买。从阿里巴巴的技术发展来看，混合部门的适用环境可以抽象为几点：第一，企业的工作量要多样化；第二，当企业的流量和业务达到一定规模后，对资源弹性的需求需要更多的考虑降本增效。对于早期或者小规模的场景，利用ECS的灵活性，基本可以享受到混合部署和灵活性的优势。混合技术是一个系统工程，是从硬件到操作系统的调度，需要协同优化。从阿里集团的资源利用率提升阶段来看，当资源利用率从10%提升到30%时，这个阶段的技术门槛比较低，可以通过类似K8S的调度和基础实现混合部门的能力。整体负荷的增加适用于现阶段的大部分企业。但如果将混合部分的水位从30%提高到50%，挑战还是很大的。阿里的混合技术一路进化，在计算、存储、网络等方面进行了多次升级。但是到目前为止，这些仍然不能满足我们混合灵活的资源模型。这时候就需要依赖于应用架构的改进。比如阿里将本地盘从业务架构中去掉，将IO隔离问题转化为网络隔离问题。好的。另外集群本身的混合部门其实是有很高门槛的。基于简单的工作负载，可按4核或8核16G标准规格进行调度。但是，随着混合工作负载的复杂度越来越高，资源规格越来越多样化，分配问题变成了一个NP问题。这时，要解决特殊的问题，就需要使用一些类似于决策智能的更复杂的问题解决方法。算法，以及混系过程中如何做好应用画像，这些都需要打磨。可见，混合系是一个庞大的系统工程。今天，阿里通过开源向大家展示了以往在混血部落的坑和积累的经验。也希望未来有更多的合作伙伴加入进来。在收获混合部落收益的同时，探索更深层次的技术，共同构建混合部门技术生态。
