3月21日，在巴黎举办的云原生顶级峰会KubeCon+CloudNativeCon Europe 2024上 ，华为云首席架构师顾炯炯在 “Cloud Native x AI：以持续开源创新开启智能时代” 的主题演讲中指出，云原生和AI技术的融合，是推动产业深刻变革的关键所在。华为云将持续进行开源创新，与开发者共启智能时代。  ▲华为云首席架构师顾炯炯发表演讲AI对于云原生范式提出关键挑战在过去的几年里，云原生彻底改变了传统的IT系统，催化了互联网和政府服务等领域的数字飞跃。云原生范式带来的新的可能性，例如闪电般的快速销售和基于微服务治理的敏捷应用DevOps，已经深入人心。同时，人工智能的快速发展和广泛采用，包括大规模模型，已经成为行业智能的跳动心脏。根据Epoch 2023年的调研数据，基础模型所需的计算能力每18个月就会增长10倍，是摩尔定理揭示的通用计算能力增长率的5倍。AI带来的新摩尔定律和大规模AI模型的主导地位对云原生范式提出了挑战，顾炯炯总结了其中关键的4点：首先，低GPU/NPU平均利用率导致AI训练和推理的高成本；其次，大模型训练集群频繁的失败率限制了训练效率；第三，大规模模型的复杂配置导致AI开发门槛高；第四，大规模的AI推理部署面临着不可预测的最终用户访问延迟和数据隐私问题的风险。华为云AI创新为开发者迎接挑战提供思路随着AI模型变得越来越大，对计算能力的需求也呈指数级增长。这种需求不仅给云原生技术带来了挑战，也为业界提供了创新机遇。顾炯炯分享了一些华为云在AI创新方面的故事，为开发者解决这些挑战提供了参考。在云原生边缘计算平台KubeEdge的基础上，华为云实现了一个云原生多机器人调度管理平台。用户可以通过自然语言命令在云端输入任务指令，由系统协调边缘的多个机器人共同协作完成复杂任务。为了克服自然语言命令理解、大量机器人高效调度管理以及跨类型机器人访问管理的三个挑战，该系统采用了云端、边缘节点和机器人三个部分的架构，通过大模型执行自然语言命令，并进行流量预测、任务分配和路由规划。这一架构显著提高了机器人平台的灵活性，管理效率提升25%，系统部署周期缩短30%，新机器人的部署时间从月级缩短到天级。中国某顶级内容分享社区，每月活跃用户超过1亿。它的核心服务之一是主页上的推荐功能。推荐模型有近1000亿个参数。训练集群有数千个计算节点。一个训练作业需要数百个参数服务器和worker。因此，该社区对最优拓扑调度、高性能、高吞吐量有着强烈的需求。开源项目Volcano可以更好地支持在Kubernetes上运行的AI/ML工作负载，并提供了一系列作业管理和高级调度策略。Volcano项目引入了拓扑感知调度、装箱、SLA感知调度等算法，帮助社区将整体训练性能提升了20%，运维复杂度也大大降低。Serverless AI引领云原生发展趋势如何高效、稳定地运行AI应用，同时降低运营成本，成为摆在众多企业和开发者面前的一大挑战。为此，华为云总结了云原生AI平台的关键要求，提出了一种全新的云原生AI平台理念——Serverless AI。顾炯炯提到，从开发者的视角来看，Serverless AI致力于智能地推荐并行策略，让复杂的训练和推理任务变得轻而易举。它提供自适应的GPU/NPU自动扩展功能，能够根据工作负载的实时变化动态调整资源分配，确保任务的高效执行。同时，Serverless AI还维护着一个无故障的GPU/NPU集群，让开发者无需担心硬件故障带来的中断风险。更值得一提的是，该平台保持与主流AI框架的兼容性，让开发者能够无缝集成现有的AI工具和模型。对于云服务提供商而言，Serverless AI同样具有深远的意义。它不仅能够提高GPU/NPU的利用率，使训练、推理和开发混合工作负载得以高效运行，还能通过优化能效实现绿色计算，降低能耗成本。此外，Serverless AI平台还能实现跨多个租户的空间和时间GPU/NPU共享，提高资源的复用率。最重要的是，它为训练和推理任务提供了有保证的QoS和SLA，确保了服务质量和稳定性。Serverless AI平台采用了构建在操作系统和虚拟化之上的灵活的资源调度层，将应用程序框架的关键功能封装于应用资源中介层中。顾炯炯现场展示了Serverless AI平台的参考架构。他认为，这种架构设计，使得Serverless AI平台具有了大规模AI资源自动驱动引擎的特点，包括精确了解应用资源利用模式的资源分析，实现异构硬件资源池化的资源共享，基于GPU/NPU虚拟化和负载热迁移的AI训练任务容错能力，以及提高资源利用率的多维度调度和自适应弹性伸缩等优点。分论坛上，华为云技术专家提到，Kubernetes上运行AI/ML工作负载的使用量不断增加，许多公司在分布于数据中心和各种GPU类型的多个 Kubernetes 集群上构建云原生AI平台。使用Karmada和Volcano，可轻松实现多集群的GPU工作负载智能调度、集群故障转移支持，在保障集群内和跨集群的两级调度一致性和效率，并平衡系统整体资源的利用率和不同优先级工作负载的QoS，以应对大规模、异构的GPU环境管理中面临的挑战。Karmada为多云和混合云场景中的多集群应用管理提供即时可用的自动化管理，越来越多的用户在生产环境中使用Karmada构建灵活高效的解决方案。Karmada已于2023年正式升级为CNCF孵化项目，期待与更多伙伴与开发者们共建繁荣社区。Volcano与主流AI/大数据框架实现了无缝集成，有效解决了AI/大数据任务的作业管理，资源分配，资源调度等问题与挑战，为业界提供了分布式作业训练的最佳实践。在大模型日新月异的今天，Volcano将持续发力，解决多集群AI任务调度等难题，助推大模型训练与推理快速发展。“云原生技术的敏捷性和异构AI计算平台的创新性，将是提升AI生产力的关键。” 顾炯炯谈到，未来，华为云将持续致力于开源创新，与业界同仁、伙伴共同开启智能时代的新篇章。更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

12月12日，云原生计算基金会（CNCF）宣布，CNCF技术监督委员会（TOC）已投票通过 Karmada 为正式孵化项目。Karmada 是华为云捐赠的云计算开源技术，是业界首个多云多集群容器编排项目。正式晋升 CNCF 孵化级，也意味着 Karmada 的技术生态受到全球业界广泛认可，在分布式云原生技术领域领域进入了成熟新阶段。作为 CNCF 首个跨云跨集群容器编排引擎，Karmada 由华为云、工商银行、小红书、中国一汽等八家企业联合发起。项目于2021年4月正式开源，2021年9月加入CNCF 成为沙箱项目。Karmada 的贡献者来自世界各地，覆盖全球22个国家和地区的60多家组织，包括华为、DaoCloud、浙江大学、滴滴、腾讯、小红书、新浪、Intel、IBM、Red Hat、Comcast 等公司。截至目前，项目在开源软件项目托管平台 GitHub 已收获超过3600 Star。华为云 CTO 张宇昕表示：华为云长期致力于云原生技术、产业和生态的建设。Karmada源于社区和华为云在多云管理领域的深厚沉淀，为企业提供了从单集群到分布式云架构的平滑演进方案。“作为 Karmada 项目的发起者和主要贡献者之一，华为云将继续与 CNCF 和社区合作，释放无处不在的云原生价值。”“Karmada 开源以来受到了广泛的关注和支持，并帮助越来越多的最终用户在多云环境中高效管理 Kubernetes 集群和分布式应用。”Karmada 社区创始人兼维护者王泽锋表示：“我们很高兴 Karmada 已达到 CNCF 孵化状态，并将继续致力于将其发展成更为完善的国际化社区。”CNCF 技术监督委员会（TOC）委员Nikhita Raghunath 表示：Karmada 填补了Kubernetes 多云和多集群环境中的调度和编排方面的空白，可以为分布式组织提供更好的性能并降低成本。“自从加入 CNCF Sandbox 以来，项目团队一直不懈地努力添加新特性和功能，以融入更广阔的云原生生态。我们期待看到该项目的持续成长。”目前，项目已在华为云、兴业数金、中国移动云、中国联通、携程、vivo、飓风引擎、VIPKID、有赞、网易、快手、之江实验室等20多家企业和单位落地应用，以开源创新促进云原生产业发展，项目全球生态发展迅速。Karmada 的创新优势，也得到了企业用户的高度认可。“Karmada 使我们能够为 Zendesk 的内部工程团队提供多集群架构，同时保持身份验证、配置交付和服务管理的单点访问。”Zendesk 计算团队工程经理 Adam Minasian 说到，“随着 Karmada 项目进入 CNCF 孵化阶段，我们很高兴能够继续与该项目合作。”“Karmada 为企业落地多云战略提供了便捷的基础设施。它基于中立、厂商无关的设计，让用户在极小代价情况下，灵活接入和切换多云和混合云；同时它为客户在微服务跨集群编排、跨集群弹性伸缩，多云化的访问、容灾等场景带来了便利性。”DaoCloud 联合创始人兼首席架构师颜开表示。基于对可持续供应的考虑，以及对业务快速扩展的需求，混合云多云已成为携程集团的技术优选。“Karmada 以其标准的 K8s API 兼容性、关注点分离的原则、活跃的社区，帮助我们构建了混合多云的控制面，降低了架构迁移成本和异构环境的管理复杂性。”携程集团容器与混合云团队总监乐鸿辉表示，携程借助于Karmada 实现的故障隔离架构和多集群 HPA，也帮助公司成功应对旅游业的强劲复苏。“Karmada 简化了多集群环境中的集群与应用的交付和管理，实现跨集群的资源协调，以增强应用程序的可用性和弹性。它确保稳定、高效、可控的应用程序部署和更新。”Shopee 专家工程师李鹤表示。“Karmada 作为开源的多云容器编排平台，为云原生中间件提供了灵活性和可靠的跨平台、跨区域、跨云的资源管理，为中间件同城跨机房高可用提供了基石。”网易资深开发工程师孟祥勇表示。目前，Karmada 社区已累计更新67个版本。晋级 CNCF 孵化项目后，项目进一步规划了社区发展路标，并正在积极添加新功能和特性，如多集群安全、大规模场景应用、多集群可观测性、多集群应用分发、生态融合发展等。作为 CNCF 亚洲唯一创始成员、白金会员，华为云在CNCF贡献量、Kubernetes社区和 Istio 社区的代码贡献量持续多年稳居亚洲第一，已向 CNCF 贡献了业界首个云原生边缘计算项目 KubeEdge、首个云原生批量算力项目 Volcano 等多个重量级云原生开源项目，并持续开源 Kurator、Kappital、Kuasar 等创新项目，与全球云原生社区共同发展。华为云分布式云原生 UCS 基于 Karmada 项目构建全新的应用算力供给模式，解决资源供应，协同全局资源，提供领先的分布式云原生应用服务。Karmada 正式晋级 CNCF 孵化项目，进一步展现了华为云持续践行开源、拥抱开源，与全球开发者共创先进技术的理念，持续助力云上开源创新生态发展。未来，Karmada 将持续探索云原生多云多集群领域技术创新，让基于 Karmada 的多云方案融入更广泛的云原生技术生态。Karmada官网：https://karmada.io/项目地址：cid:link_0Slack地址：https://slack.cncf.io/

作者：华为云云原生团队随着云原生技术在越来越多的企业和组织中的大规模落地，如何高效、可靠地管理大规模资源池以应对不断增长的业务挑战成为了当下云原生技术的关键挑战。在过去的很长一段时间内，不同厂商尝试通过扩展单集群的规模来扩展资源池。然而，Kubernetes社区很早就发布了大规模集群的最佳实践，其中包括几项关键数据：节点数不超过5k，Pod数不超过150k，单个节点的Pod数量不超过110 k等。这侧面说明了支持超大规模的集群不是Kubernetes社区主要努力的方向。同时，以单集群的方式扩展资源池通常需要定制Kubernetes的原生组件，这在增加了架构复杂度的同时也带来了不少弊端：（1）集群运维复杂度急剧增加。（2）与社区演进方向相左，后续的维护成本上升，升级路径不清晰。（3）单集群本质上属于单个故障域，集群故障时将导致无法控制爆炸半径。而多集群技术能在不侵入修改Kubernetes单集群的基础上横向扩展资源池的规模，在扩展资源池的同时降低了企业的运维管理等成本。此外，多集群系统天然支持多故障域，符合多数业务场景，如多地数据中心、CDN就近提供服务等。Karmada作为CNCF首个多云容器编排项目，提供了包括Kubernetes原生API支持、多层级高可用部署、多集群故障迁移、多集群应用自动伸缩、多集群服务发现等关键特性，致力于让用户轻松管理无限可伸缩的资源池，为企业提供从单集群到多云架构的平滑演进方案。随着以Karmada为代表的多集群架构在企业的逐步落地，大规模场景下多集群系统的性能问题往往是用户的核心关注点之一。本文将围绕以下几个问题，结合Karmada社区对大规模场景的思考，揭示Karmada稳定支持100个大规模集群、管理超过50万个节点和200万个Pod背后的原理。（1） 如何衡量一个多集群系统资源池的维度与阈值？（2） 对多集群系统进行大规模环境的压测时，我们需要观测哪些指标？（3） Karmada是如何支撑100个大规模K8s集群并纳管海量应用的？（4） 在Karmada的生产落地过程中，有哪些最佳实践和参数优化手段可以参考？▎多集群系统资源池的维度与阈值当前，业界对于多云资源池的Scalability尚未达成统一标准，为此，Karmada社区结合企业用户的实践，率先对这一问题进行了深入探索。一个多集群系统资源池规模不单指集群数量，实际上它包含很多维度的测量标准，在不考虑其他维度的情况下只考虑集群数量是毫无意义的。在若干因素中，社区按照优先级将其描述为以下三个维度：（1） 集群数量。集群数量是衡量一个多集群系统资源池规模和承载能力最直接且最重要的维度。（2） 资源（API对象）数量。对于多集群系统的控制面来说，存储并不是无限的，在控制面创建的资源对象的数量和总体大小受限于系统控制面的存储，也是制约多集群系统资源池规模的重要维度。这里的资源对象不仅指下发到成员集群的资源模板，而且还包括集群的调度策略、多集群服务等资源。（3） 集群规模。集群规模是衡量一个多集群系统资源池规模不可忽视的维度。一方面，集群数量相等的情况下，单个集群的规模越大，整个多集群系统的资源池越大。另一方面，多集群系统的上层能力依赖系统对集群的资源画像，例如在多集群应用的调度过程中，集群资源是不可或缺的一个因素。综上所述，单集群的规模与整个多集群系统息息相关，但单集群的规模同样不是制约多集群系统的限制因素。用户可以通过优化原生的Kubernetes组件的方式来提升单集群的集群规模，达到扩大整个多集群系统的资源池的目的，但这不是衡量多集群系统性能的关注点。在集群的标准配置中，Node与Pod毫无疑问是其中最重要的两个资源，Node是计算、存储等资源的最小载体，而Pod数量则代表着一个集群的应用承载能力。▎大规模场景下多集群系统的性能指标在多集群系统的大规模落地进程中，如何衡量多集群联邦的服务质量是一个不可避免的问题。在参考了Kubernetes社区的SLI(Service Level Indicator)/SLO(Service Level Objectives)和多集群系统的落地应用后，Karmada社区定义了以下SLI/SLO来衡量大规模场景下多集群联邦的服务质量。API Call LatencyStatusSLISLOOfficial最近5min的单个Object Mutating API P99 时延除聚合API和CRD外，P99 <= 1sOfficial最近5min的non-streaming read-only P99 API时延除聚合API和CRD外P99 :(a) <= 1s if scope=resource (b) <= 30s otherwise (if scope=namespace or scope=cluster)注：API调用时延仍然是衡量基于Kubernetes的多集群系统服务质量的关键指标。Karmada兼容Kubernetes原生API，用户除了使用原生API创建K8s的资源模板外，也可以使用Karmada自有API来创建多集群策略和访问跨集群的资源。Resource Distribution LatencyStatusSLISLOOfficial用户在联邦控制面提交资源模板和下发策略后到资源在成员集群上被创建的P99时延，不考虑控制面与成员集群之间的网络波动P99 <= 2sCluster Registration LatencyStatusSLISLOWIP集群从接入联邦控制面到状态能被控制面正常收集的P99时延，不考虑控制面与成员集群之间的网络波动TBD注：集群注册时延是从集群注册到控制面到集群在联邦侧可用的时延，它反映了控制面接入集群以及管理集群的生命周期的性能。但它在某种程度上取决于控制面如何收集成员集群的状态。因此，我们不会对这个指标进行强制的限制。Resource UsageStatusSLISLOWIP在接入一定数量的集群后集群联邦维持其正常工作所必需的资源使用量TBD注：资源使用量是多集群系统中非常重要的指标，我们希望在纳管海量的集群和资源的同时消耗尽量少的系统资源。但由于不同的多集群系统提供的上层服务不同，因此对于不同的系统，其对资源的要求也会不同。因此，我们不会对这个指标进行强制的限制。▎Karmada百倍集群规模基础设施揭秘Karmada社区在结合对上述两个问题的思考以及用户在落地过程中的反馈后，测试了Karmada同时管理100个5K节点和2w Pod的Kubernetes集群的场景。本文不详细描述具体的测试环境信息与测试过程，而是侧重于对测试结果进行分析在整个测试过程中，API调用时延均符合上述定义的SLI/SLO。图一：只读API（cluster-scope）调用时延图二：只读API(namespace-scope)调用时延图三：只读API(resource-scope)调用时延图四：Mutating API调用时延Karmada在百倍集群规模下，仍能做到快速的API响应，这取决于Karmada独特的多云控制面架构。事实上，Karmada在架构设计之初就采用了关注点分离的设计理念，使用Kubernetes原生API来表达集群联邦资源模板，使用可复用的策略API来表达多集群的管理策略，同时控制面的资源模板作为应用的模板，不会在控制面生成具体的Pod。不同集群的应用在控制面的映射（Work对象）通过命名空间来进行安全隔离。完整的API工作流如下图所示。如此设计，不仅可以让Karmada能够轻松集成Kubernetes的生态, 同时也大大减少了控制面的资源数量和承载压力。基于此，控制面的资源数量不取决于集群的数量，而是取决于多集群应用的数量。此外，Karmada的架构极具简洁性和扩展性。karmada-apiserver作为控制面的入口与kube-apiserver类似，即使是在百倍集群规模下，Karmada仍能保持快速API响应。Karmada支持通过命令行快速接入集群，以及集群的全生命周期管理。Karmada会实时采集集群心跳和状态，其中集群状态包括集群版本、支持的API列表、集群健康状态以及集群资源使用量等。其中，Karmada会基于集群资源使用量对成员集群进行建模，这样调度器可以更好地为应用选择资源足够的目标集群。在这种情况下，集群注册时延与集群的规模息息相关。下表展示了加入一个5,000节点的集群直至它可用所需的时延。你可以通过关闭集群资源建模来使集群注册时延与集群的大小无关，在这种情况下，集群注册时延这个指标将小于2s。Cluster Registration Latency:metricP50(ms)P90(ms)P99(ms)SLOcluster_register535661256904N/AKarmada支持多模式的集群统一接入，在Push模式下，Karmada控制面直连成员集群的kube-apiserver，而在Pull模式下，Karmada将在成员集群中安装agent组件，并委托任务给它。因此Push模式多用于公有云的K8s集群，需要暴露APIServer在公网中，而Pull模式多用于私有云的K8s集群。下表展示了Karmada在不同模式下下发一个应用到成员集群所需的时延。Resource Distribution Latency:MetricP50(ms)P90(ms)P99(ms)SLOcluster_schedule121532N/Aresource_distribution(Push)70689912982000resource_distribution(Pull)6128819892000结论：我们容易得出，不论是Push模式还是Pull模式，Karmada都能高效地将资源下发到成员集群中。在Karmada演进的数个版本中，大规模场景下使用Karmada管理多云应用的资源消耗一直是用户比较关注的问题。Karmada社区做了许多工作来减少Karmada管理大型集群的资源使用量，比如我们优化了Informer的缓存，剔除了资源无关的节点、Pod元数据；减少了控制器内不必要的类型转换等等。相较于1.2版本，当前Karmada在大规模集群场景下减少了85%的内存消耗和32%的CPU消耗。下图展示了不同模式下Karmada控制面的资源消耗情况。Push模式：Pull模式：总的来说，系统消耗的资源在一个可控制面的范围，其中Pull模式在内存使用上有明显的优势，而在其他资源上相差的不大。▎Karmada大规模环境下的最佳实践Karmada支持性能参数的可配置化，用户可以通过调整组件的参数来调整同一时间段内并发处理Karmada内部对象的数量、系统的吞吐量等以优化性能。同时Karmada在不同模式下的性能瓶颈并不相同，以下着重对此进行分析。在Push模式中，控制面的资源消耗主要集中在karmada-controller-manager（约70%），而Karmada控制面基座（etcd/karmada-apiserver）的压力不大。结合karmada-apiserver的qps以及karmada-etcd的请求时延我们可以看出karmada-apiserver的请求量保持在一个较低的水平。在Push模式中，绝大多数的请求来自karmada-controller-manager。因此我们可以通过调整karmada-controller-manager的--concurrent-work-syncs来调整同一时间段并发work的数量来提升应用下发的速度，也可以配置--kube-api-qps和--kube-api-burst这两个参数来控制Karmada控制面的整体流控。在Pull模式中，控制面的资源消耗主要集中在karmada-apiserver，而不是karmada-controller-manager。结合karmada-apiserver的qps以及karmada-etcd的请求时延我们可以看出karmada-apiserver的请求量保持在一个较高的水平。在Pull模式中，每个成员集群的karmada-agent需要维持一条与karmada-apiserver通信的长连接。我们很容易得出：在下发应用至所有集群的过程中请求总量是karmada-agent中配置的N倍(N=#Num of clusters)。因此，在大规模Pull模式集群的场景下，Pull模式在资源下发/状态收集方面有更好的性能，但同时需要考虑控制面的抗压能力以及各个karmada-agent和控制面的整体流控。当前，Karmada提供了集群资源模型的能力来基于集群空闲资源做调度决策。在资源建模的过程中，它会收集所有集群的节点与Pod的信息。这在大规模场景下会有一定的内存消耗。如果用户不使用这个能力，用户可以关闭集群资源建模来进一步减少资源消耗。▎总结根据上述测试结果分析，Karmada可以稳定支持100个大规模集群，管理超过50万个节点和200万个Pod。在Karmada落地进程中，用户可以根据使用场景选择不同的部署模式，通过参数调优等手段来提升整个多集群系统的性能。受限于测试环境和测试工具，上述测试尚未测试到Karmada多集群系统的上限，同时多集群系统的分析理论以及测试方法仍处于方兴未艾的阶段，下一步我们将继续优化多集群系统的测试工具，系统性地整理测试方法，以覆盖更大的规模和更多的典型场景。添加小助手微信k8s2222，进入云原生交流群