开源之夏是由中国科学院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源软件社区的蓬勃发展，助力开源软件供应链建设。学生通过远程线上协作方式，通过社区资深导师指导，参与到开源社区各组织项目开发中，收获证书及8000/12000元奖金。活动官网：https://summer-ospp.ac.cn/Volcano云原生批量计算社区已连续6年加入开源之夏。今年社区为同学们带来8项课题，欢迎高校同学选报，报名将于5月9日正式启动，截止时间6月9日18:00 （UTC+8）。Volcano是业界首个云原生批量计算社区，也是 CNCF 首个及唯一孵化级批量计算项目。Volcano主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，完成对 Spark、Flink、Ray、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持。社区已吸引5.8万+全球开发者，获得4.6k+Star 和1100+ Fork。Volcano现已在60多家企业中实现了生产落地，广泛应用于互联网、人工智能、自动驾驶、大数据处理、高性能计算、金融、娱乐、医疗、财经传媒、生命科学等多个行业和场景。🏷️ 社区地址：https://github.com/volcano-sh/volcano   开源之夏 2025 Volcano 课题介绍   课题一：面向云原生场景的Device Plugin GPU虚拟化与型号上报统一管理项目编号：253ba0225项目难度：基础/Basic项目社区导师：archlitchi导师联系邮箱：391013634@qq.com项目简述：Volcano Device Plugin 目前分别在不同分支提供了 GPU 虚拟化（基于较旧上游版本）和 GPU 型号上报（基于较新 v0.16.1 版本）两项重要功能。为了解决由此带来的维护和使用不便，本项目计划将这两项能力整合到统一的代码分支中，并进行适当重构。最终目标是提供一个功能完备、接口统一的 Device Plugin，更好地支持云原生环境下的 GPU 资源虚拟化和精细化管理，提升用户体验并促进社区协作。项目链接：https://summer-ospp.ac.cn/org/prodetail/253ba0225课题二：增强Volcano Agent以支持Cgroup V2与Systemd项目编号：253ba0247项目难度：基础/Basic项目社区导师：guoqinwill导师联系邮箱：gq411will@163.com项目简述：Volcano Agent 是云原生混部场景下的核心 SLO (Service Level Objective) Agent，通过统一调度、资源隔离和动态资源超卖等机制提高了资源利用率，并通过 OoS (Out-of-Service) 保障机制确保高优先级任务的服务质量。当前，Volcano Agent 主要支持 Cgroup v1，这与目前主流操作系统逐步迁移至 Cgroup v2 和 Systemd 的趋势不符，同时也限制了与配置不同 cgroup-driver 的 Kubelet 节点的兼容性，阻碍了端到端混部能力的完整实现。本项目旨在增强 Volcano Agent 的基础能力，使其能够原生支持 Cgroup v2 和 Systemd。通过适配新的资源管理机制，Volcano Agent 将能更好地与现代操作系统集成，并与配置不同 cgroup-driver 的 Kubelet 节点协同工作，为用户提供一致的混部体验，从而进一步完善其在云原生混部场景下的资源管理和 SLO 保障能力。项目链接：https://summer-ospp.ac.cn/org/prodetail/253ba0247课题三：Volcano准入控制从Webhook到声明式策略的演进与迁移项目编号：253ba0259项目难度：基础/Basic项目社区导师：JesseStutler导师联系邮箱：jessestutler97@gmail.com项目简述：当前，Volcano 依赖大量的 Webhook 组件对 Kubernetes 集群中的 Pod、VCJob、Queue 等核心资源进行准入控制，包括验证资源的有效性（Validating）和根据策略进行默认值设置或修改（Mutating）。虽然 Webhook 机制能够实现灵活的准入控制逻辑，但在 Kubernetes 高版本集群中，引入了更高效且与 CRD 深度集成的声明式准入控制方案，例如 Kubebuilder 对 CEL (Common Expression Language) 的支持，以及 Kubernetes 原生的 ValidatingAdmissionPolicy 和 MutatingAdmissionPolicy API。本项目旨在对 Volcano 现有的准入控制机制进行现代化改造，核心目标是将当前由 Webhook 实现的部分或全部准入控制逻辑迁移到这些声明式的策略定义中。通过利用 CEL 在 CRD 层面定义校验规则，以及使用 ValidatingAdmissionPolicy 和 MutatingAdmissionPolicy API 实现更灵活的资源准入控制，可以减少外部 Webhook 调用的开销，潜在地提升 Volcano 的性能，并简化准入控制策略的管理和维护。此外，为了保证与不同 Kubernetes 集群版本的兼容性，本项目还需要考虑在 Helm 安装时提供灵活的部署选项。对于不支持 CEL 和 Admission Policy API 的旧版本集群，应继续使用现有的 Webhook 机制。而对于支持这些新特性的高版本集群，则默认或可选地启用新的声明式准入控制模式。通过本次项目的实施，Volcano 将能够更好地融入现代 Kubernetes 生态，提升在高版本集群中的运行效率和可维护性，并为未来的准入控制策略扩展奠定基础。项目链接：https://summer-ospp.ac.cn/org/prodetail/253ba0259课题四：Volcano 原生异构资源管理：集成昇腾 NPU 调度插件项目编号：253ba0293项目难度：进阶/Advanced项目社区导师：lowang-bh导师联系邮箱：lhui_wang@163.com项目简述：Volcano 作为首个云原生批量计算平台，旨在提供对包括 GPU、NPU、x86、ARM 等异构资源的统一管理和调度能力。目前，针对昇腾 NPU 资源的调度支持以独立插件的形式在昇腾社区维护，这导致用户在使用 Volcano 调度 NPU 时需要依赖外部组件，增加了复杂性和维护成本。本项目旨在将昇腾社区维护的 NPU 调度逻辑作为 Volcano 社区的原生插件进行集成和统一管理。通过将现有的独立插件迁移到 Volcano 社区并进行重构，使其完全融入 Volcano 的架构体系，用户将能够更方便地在 Volcano 框架内直接使用 NPU 调度能力，无需额外依赖和维护第三方组件。项目链接：https://summer-ospp.ac.cn/org/prodetail/253ba0293课题五：Volcano 子项目 CI/CD 流程、Helm 发布与自动化测试体系建设项目难度：253ba0295项目难度：基础/Basic项目社区导师：box导师联系邮箱：wszwbsddbk@gmail.com项目简述：随着 Volcano 社区的不断发展，涌现出越来越多的新子项目，例如 descheduler、volcano-global、dashboard 等。然而，这些新创建的子项目目前普遍缺乏完善的 CI/CD（持续集成/持续交付）流水线 workflow、自动化 Helm 发布包构建流程以及充分的自动化测试覆盖（包括单元测试 UT 和端到端测试 E2E）。基础设施的缺失会影响项目的开发效率、代码质量、发布流程的标准化以及最终产品的稳定性。本项目旨在为 Volcano 社区中尚未具备完整 CI/CD、Helm 发布和自动化测试体系的新子项目进行全面的基础设施建设。目标是建立一套标准化的流程和工具链，使得新子项目能够快速地实现自动化构建、测试、打包和发布，并具备足够的自动化测试覆盖以保障代码质量。项目链接：https://summer-ospp.ac.cn/org/prodetail/253ba0295课题六：Volcano 大规模场景性能瓶颈分析与持续优化项目难度：253ba0300项目难度：进阶/Advanced项目社区导师：李鑫导师联系邮箱：hwdefcom@outlook.com项目简述：性能一直是 Volcano 社区高度关注并持续优化的关键领域。随着用户使用场景的日益丰富、集群规模的不断扩大以及 Volcano 功能的逐步增强，对 Volcano 在大规模场景下的性能提出了越来越高的要求。尽管 Volcano 在早期已经进行了一系列性能优化工作，但为了更好地应对未来的挑战，进一步提升其在大规模场景下的性能至关重要。本项目旨在深入分析 Volcano 在大规模场景下的性能瓶颈，并制定和实施持续的优化策略。具体而言，将借助现有的开源工具，例如 Kubernetes 模拟器 KWOK 以及调度器性能压测工具等，对 Volcano 在处理大规模批量下发 Deployment 和 Volcano Job 等典型场景下的性能表现进行细致的分析。通过性能指标采集与分析、性能瓶颈识别、阶段耗时分析、开源工具应用、优化方案制定与实施、性能回归测试以及持续性能监控与告警等环节，全面提升 Volcano 在大规模场景下的性能，为用户提供更稳定、更高效的任务调度服务。项目链接：https://summer-ospp.ac.cn/org/prodetail/253ba0300课题七：基于 Hugo 的 Volcano 官网重构与功能定制开发项目难度：253ba0307项目难度：基础/Basic项目社区导师：常旭征导师联系邮箱：cxz2536818783@gmail.com项目简述：Volcano 社区的官方网站 (https://github.com/volcano-sh/website和https://volcano.sh/) 是用户了解、使用和参与 Volcano 项目的关键入口。当前网站基于 Hugo 静态站点生成器构建，但在用户界面、用户体验和功能性方面仍有提升空间。本项目旨在对 Volcano 官网进行前端功能的深度开发与用户界面和用户体验的全面升级，重点在于增强文档的搜索和导航能力，优化现有的文档版本管理机制，构建全新的用户展示平台（Adopter Group 页面），并进行整体的用户界面和交互体验优化。此外，本项目还将涵盖对核心组件和功能的文档进行细致的更新和完善，确保文档的准确性和实用性。本课题的目标是增强 Volcano 官网的功能性与用户体验。项目链接：https://summer-ospp.ac.cn/org/prodetail/253ba0307课题八：基于数据依赖的任务编排与 Volcano Global 调度项目难度：253ba0314项目难度：进阶/Advanced项目社区导师：汪洋导师联系邮箱：wysea1990@163.com项目简述：Volcano Global 作为 Volcano 社区新发布的多集群调度平台，旨在为 AI、大数据、HPC 等高性能计算任务提供跨集群的统一调度能力，目前已支持队列和作业优先级、以及多租户公平调度。然而，在大数据场景下，任务之间往往存在复杂的数据依赖关系，例如任务 C 依赖任务 A 生成的数据。当前 Volcano Global 尚不支持此类依赖约束，导致在跨集群调度时，任务的实际可调度性受限于数据在目标集群上的可用性。运维人员需要人工分析和配置任务与数据源的对应关系，这不仅效率低下，还容易导致集群负载不均衡。尤其是在跨数据中心场景下，由于无法直接跨集群读写数据，需要通过平台的数据同步管道来保证数据安全，使得数据依赖的满足更加复杂。本项目旨在为 Volcano Global 设计并实现一个可插拔的第三方依赖检测机制，以支持大数据任务的数据依赖约束调度。该机制允许用户在任务定义中声明其所需的数据表（或其他数据源）以及目标集群，通过外挂的依赖检测插件，Volcano Global 可以在调度时查询集群的数据可用性，从而将任务调度到满足其数据依赖的集群上。项目链接：https://summer-ospp.ac.cn/org/prodetail/253ba0295▍如何报名开源之夏Volcano课题？报名对象本活动面向年满 18 周岁的高校在校学生。在9月30日开发结束之前，学生需保持在校学生状态。若已收到研究生或博士生录取通知，可提供录取通知书及相关说明材料。中国籍学生参与活动时需提供有效期内的身份证、学生证、教育部学籍在线验证报告（学信网）或在读证明。外籍学生参与活动时需提供护照，同时提供录取通知书、有效期内的学生证、在读证明等文件。学生报名时间学生可在系统（https://summer-ospp.ac.cn/）注册账号并填写个人资料提交审核。资料审核通过的学生 5月9日 起可在系统提交项目申请书，学生课题申请截止时间为6月9日18:00。学生可以收获什么？结识开源界小伙伴和技术大牛获得社区导师的专业指导，与开源项目开发者深度交流丰富项目实践经验，提升项目开发技能，为工作履历增光添彩为学习方向提供参考，为职业发展积累人脉通过结项考核的学生将获得结项奖金和结项证书（基础难度税前8000元RMB，进阶难度税前12000元RMB），更有机会获选优秀学生▍Volcano社区技术交流与联系Volcano社区开源之夏2025交流群添加社区小助手k8s2222回复Volcano开源之夏咨询【更多Volcano干货推荐】Volcano云原生批量计算公开课Volcano云原生批量计算公开课Volcano云原生批量计算公开课由CNCF首个批量计算社区Volcano核心贡献者开发，通过理论学习+实践操作，帮助学习者由浅入深了解批量计算原理和生产场景应用，晋升批量计算达人！点击免费学习Volcano云原生批量计算公开课（https://edu.huaweicloud.com/roadmap/cloudnative.html）社区介绍：Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene、Ray 等众多主流计算框架的支持，并构建起完善的上下游生态。Volcano官网：https://volcano.shGitHub: https://github.com/volcano-sh/volcano每周例会：https://zoom.us/j/91804791393

北京时间2025年4月23日，哔哩哔哩、中电信人工智能科技、商汤科技、联通云等多家行业领军企业共同宣布加入Volcano[1]社区用户组。这一重要合作将重点推动AI训练推理、大数据分析等业务场景在云原生平台的规模化落地，标志着Volcano社区在技术创新和生态建设方面取得重大突破。通过本次合作，各方将充分发挥各自在人工智能、云计算等领域的技术优势，共同构建开放、协同、创新的云原生开源生态。这不仅将加速企业级云原生解决方案的实践应用，也将为开发者社区提供更完善的技术支持和发展平台。Volcano社区将持续优化平台能力，携手合作伙伴推动云原生技术在各行业的深入应用。关于Volcano社区用户组Volcano作为业界首个云原生批量计算引擎，已经在60多家企业中实现了生产落地，广泛应用于互联网、人工智能、自动驾驶、大数据处理、高性能计算、金融、娱乐、医疗、财经传媒、生命科学等多个行业和场景。随着Volcano社区生态圈的不断扩大，越来越多的用户表达了加入社区的强烈意愿。为了帮助用户快速融入社区，加速落地实践，Volcano社区在前期已经携手11家首批合作伙伴，共同启动了社区共建计划[2]。Volcano社区共建计划现已升级为Volcano社区用户组[3]（Adopter Group），旨在与社区用户建立更紧密的合作关系，携手共建开放、繁荣、创新的社区生态。有关Volcano社区用户组的详细信息，请参阅：https://github.com/volcano-sh/community/tree/master/adopter-group首批加入的合作伙伴[4] 包括：百度、博云、第四范式、唯品会、锐天投资、中科类脑、品览、360、网易数帆、喜马拉雅、BOSS直聘。Bilibili、中电信人工智能科技、商汤科技、联通云等正式加入▍关于BilibiliBilibili（简称B站）成立于2009年，是一家提供视频、直播、游戏、广告等业务的互联网公司。借助Volcano的批调度、队列等高阶能力，B站的AI、大数据等业务实现了高效的资源调度管理和平滑的云原生迁移。目前，Volcano已在B站内部的AI平台上实现了稳定的生产落地。通过Volcano Job API，B站对海量视频编解码任务进行了有效的调度和管理。同时，借助Volcano的PodGroup调度抽象和层级队列等功能，B站成功将大数据业务从Spark、Yarn迁移到云原生平台。B站的工程师团队，包括@Wang-Kai、@LivingCcj、@WulixuanS、@bufan，贡献了队列优先级、性能优化等核心特性，为Volcano社区的发展提供了重要支持。▍关于中电信人工智能科技中电信人工智能科技成立于2023年，是中国电信旗下专注于大数据及人工智能业务的科技型、能力型、平台型专业公司。公司致力于人工智能领域核心技术攻坚、前沿技术研发和产业空间拓展，成功自研了星辰AI大模型、星海智算中台、星河AI平台等创新应用成果。中电信人工智能科技的星海多模态融合PaaS底座，通过高效算力管理调度、高性能存算分离技术、高容错大模型运维技术、网络虚拟化技术、多模态数据汇聚加工等技术，成为构建高质量数据加工和AI训练推理基础设施的坚实底座。该平台在24年支撑了中国电信星辰千亿万亿参数大模型在全国产万卡训练集群上的全训练生命周期，并在内外部训推场景上大规模应用。其中高效算力管理调度构建在Volcano基础上，并密切与Volcano社区合作开发，实现了多级队列管理、AI训练推理任务调度、网络拓扑感知、断点续训等能力，大幅提升集群资源利用率。中电信AI公司的工程师团队，包括@Xu-Wentao、@weapons97和@zhutong196，贡献了网络拓扑感知调度、层级队列等核心特性。中电信AI公司PaaS研发总监杨磊表示：“ 中电信TAP平台基于Volcano实现了AI与大数据场景的全栈调度支持，在AI领域，通过多级队列调度与GPU算力池化技术，显著提升分布式训练效率；在大数据场景中，灵活调度Spark、Flink等异构计算引擎，打破资源孤岛。感谢Volcano社区的技术沉淀与开放协作，期待与社区共同协作，为上层应用提供更灵活的算力管理与调度能力。”▍关于商汤科技作为人工智能软件公司，商汤科技以“坚持原创，让AI引领人类进步”为使命，持续引领人工智能前沿研究，打造更具拓展性和普惠性的人工智能软件平台，推动经济、社会和人类发展。同时，商汤科技注重吸引和培养顶尖人才，共同塑造未来。在技术实践方面，商汤科技采用Volcano进行AI工作负载的调度和管理，深度利用Volcano Job等特性统一管理并高效分发AI任务。通过Volcano Job对AI工作负载的统一抽象，能够支持主流AI计算框架，并借助其重启策略，在AI训练场景中实现细粒度的故障恢复和灵活的任务重启。此外，商汤科技的工程师@kingeasternsun和@zhengxinwei在Volcano社区中积极参与性能优化等工作，为提升调度效率和系统稳定性做出了重要贡献。商汤科技SenseCore IaaS 产品技术负责人项铁尧表示：“ Volcano 是一个由 CNCF 托管的云原生批量计算平台，它弥补了 Kubernetes 在 AI、HPC 和大数据工作负载方面缺失的关键能力。Volcano通过高阶的批量调度、公平资源分配和弹性扩展等特性增强了原生 Kubernetes能力，显著提升了集群利用率和效率。通过支持异构硬件（GPU、NPU 等），并与 TensorFlow 和 Spark 等框架无缝集成，Volcano 简化了大规模任务的编排，同时降低了基础设施开销。作为超大规模 AI 训练/推理基础设施的先驱，SenseCore IaaS 利用 Volcano 为分布式深度学习和大规模并行工作负载提供极致的效率。通过与 PyTorch、Ray 和其他领先框架无缝集成，并针对 GPU、NPU 和异构硬件进行优化，SenseCore 使企业能够更快地进行训练、更智能地扩展，并以前所未有的效率部署尖端 AI 技术。Volcano 专为大规模 AI/ML 而构建，通过智能调度、弹性扩展和公平共享资源管理增强了 Kubernetes，使其成为下一代 AI 基础架构的核心支撑。凭借 SenseCore 久经考验的编排能力和 Volcano 的开源敏捷性，团队可以专注于突破性创新，摆脱基础架构的限制。”▍关于联通云联通云成立于2013年，是中国联通旗下的云服务品牌，由联通云数据有限公司研发，是全球领先的云计算服务商，云服务器提供商。联通云以云计算国家队、数字化转型算力引擎的责任担当，立足自主创新，实现全新升级，树立“安全数智云”品牌形象，形成了“安全可靠、云网一体、数智相融、专属定制、多云协同”的特色优势，提供“联接+感知+计算+智能”的算网一体化服务，打造数字经济“第一算力引擎”。联通云的工程师团队，包括@sailorvii和@linuxfhy，贡献了vGPU虚拟化等核心特性。联通云容器团队负责人王琦表示：“ 容器团队选择 Volcano 作为调度器，基于多维度的综合考量。在资源管理方面，Volcano 对各类资源的把控细致入微。它不仅能精准洞悉 CPU、内存、存储等常规资源的使用情况，提升资源整体利用率，在 GPU 资源调度上更是表现卓越。Volcano 具备强大的 GPU 感知调度能力，支持多种GPU调度方式。在任务编排领域，Volcano 支持复杂任务拓扑结构，能依据任务间的依赖关系有序启动和停止容器，保障业务流程顺畅运转。” 欢迎加入Volcano用户组加入Volcano社区用户组将获得以下权益：直接交流机会：针对用户的特殊场景进行交流与分析，直接解决问题并保护项目隐私。分析落地过程中的疑难问题，提升问题解决效率。直接反馈技术迭代需求，获得更快速的响应。官方媒体宣传机会：入选项目将在官方平台展示。在项目落地过程中，社区将在关键里程碑节点协助进行媒体推广。提升技术影响力的机会：项目完成并落地后，社区会对主要贡献者表示真挚谢意。公司（或组织）Logo有机会在官方网站上展示。获得线上/线下技术分享机会。获得在KubeCon Volcano专题环节发言的机会。有机会联合主办技术峰会、沙龙、Meetup等社区活动。 结 语随着Bilibili、中电信人工智能科技、商汤科技、联通云等用户的加入，Volcano社区的生态圈进一步扩大。这些用户和伙伴的加入不仅为社区带来了丰富的实践经验和技术创新，也为Volcano在云原生领域的持续发展注入了新的活力。未来，Volcano社区将继续与更多合作伙伴携手，共同推动云原生技术的进步，为各行各业提供更高效、更灵活的云原生AI资源调度与管理支持。相关资料 [1] Volcano 官网: https://volcano.sh/ [2] Volcano社区共建计划: https://volcano.sh/zh/blog/volcano-community-co-construction-program/ [3] Volcano用户组: https://github.com/volcano-sh/community/tree/master/adopter-group [4] 华为云携手11家合作伙伴启动Volcano社区共建计划: https://mp.weixin.qq.com/s/LIzk0sPakgt6wVr2CPtAlg【更多Volcano干货推荐】Volcano云原生批量计算公开课Volcano云原生批量计算公开课Volcano云原生批量计算公开课由CNCF首个批量计算社区Volcano核心贡献者开发，通过理论学习+实践操作，帮助学习者由浅入深了解批量计算原理和生产场景应用，晋升批量计算达人！点击免费学习Volcano云原生批量计算公开课社区介绍：Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene、Ray 等众多主流计算框架的支持，并构建起完善的上下游生态。Volcano官网：https://volcano.shGitHub: https://github.com/volcano-sh/volcano每周例会：https://zoom.us/j/91804791393扫码添加社区小助手回复Volcano进交流群

作者：王彬丞&杨志佳&刘家伟针对新版本 Device-IoT 领域的更新，我们计划推出一系列的文章对这些特性进行详细的介绍，大致的文章大纲为：1. 基于物模型的设备管理 API 设计与实现2. DMI 数据面能力设计与实现3. Mapper 开发框架 Mapper-Framework 设计与实现4. 如何使用 Mapper 完成视频流数据处理5. 如何使用 Mapper 实现设备数据写入6. 如何从头开发一个 Mapper（以 modbus 为例）在本系列的前几篇文章中，我们详细介绍了基于物模型的设备管理 API、DMI 数据面能力的增强、Mapper-Framework 开发框架的原理、使用 Mapper 进行视频流数据采集上报以及设备数据写入等核心特性，作为系列文章的最终部分，我们将展示如何从零开始开发一个 Mapper 工程，并通过该工程实现对边缘设备的管理。  定义Device CRD  用户需要按照 KubeEdge v1beta1 版本的 Device CRD 定义，以物模型的形式构建 device-model 与 device-instance，具体的定义细节可以参考本系列的第一篇文章。👇🏻 以下是一个具体的示例：apiVersion: devices.kubeedge.io/v1beta1kind: DeviceModelmetadata: name: temperature-modelspec: properties: - name: temp # define device property description: The temperature collected by the sensor type: INT # date type of device property accessMode: ReadWrite protocol: modbus # protocol for device, need to be same with device instance首先，我们定义了一个名为 temperature-model 的 device-model，该模型用于定义一类温度传感器的共同特性。在这个示例中，temperature-model 描述了温度传感器的一个重要属性 temp。该属性表示温度传感器采集到的温度值，数据类型为 int。此外，设备的通信协议采用了 Modbus 协议，并且 temp 属性的访问方式被设置为“读写”模式。这意味着，Mapper 将会对从设备采集到的数据进行归一化或其他处理后，返回标准化的结果。apiVersion: devices.kubeedge.io/v1beta1kind: Devicemetadata: name: temperature-instance-01 labels: model: temperature-modelspec: deviceModelRef: name: temperature-model protocol: protocolName: modbus configData: serialPort: '/dev/ttyS0' baudRate: 9600 dataBits: 8 parity: even stopBits: 1 nodeName: edge-node properties: - name: temp visitors: protocolName: modbus configData: register: HoldingRegister offset: 2 limit: 1 scale: 1 isSwap: true isRegisterSwap: true reportCycle: 10000 collectCycle: 10000 reportToCloud: true pushMethod: mqtt: address: tcp://127.0.0.1:1883 topic: temperature qos: 0 retained: false接下来，我们定义了一个名为 temperature-instance-01 的 device-instance，代表一个实际的 Modbus 温度传感器设备。在定义中，spec.protocol 字段需要具体说明设备的通信协议参数，在示例中使用 Modbus 协议，并为其定义了典型的通信参数，如串口、波特率等。Mapper 将根据这些参数与设备进行通信，完成数据的采集与交互。在 spec.properties 字段中，我们定义了与设备模型中一致的 temp 属性，并进一步细化了访问方式。在 visitors 字段中，我们详细列出了 temp 属性的访问方式，包括寄存器类型、寄存器地址以及偏移量等信息。根据这些定义，Mapper 会准确地访问设备的寄存器，从而获取所需的数据。最后，在 spec.properties.pushMethod 字段中，我们定义了设备数据的推送方式。DMI 数据面支持将设备数据推送到多种目标，包括数据库、用户应用等。具体的推送方式可以参考本系列的第二篇文章。  构建Modbus Mapper工程如果开发者需要构建自定义的 Mapper 插件，可以通过 KubeEdge 的 Mapper-Framework 子仓库生成 Mapper 工程模板。接下来，开发者只需根据设备的具体信息，填充设备初始化、数据采集等功能，即可完成自定义 Mapper 插件的构建。👇🏻 以下是相关示例：1、生成 Mapper 工程开发者首先通过 git clone 命令克隆 KubeEdge 的 Mapper-Framework 仓库[1] ，随后使用 git checkout 指令切换到稳定版本（目前支持的版本为1.16至1.20）并执行 make generate 命令，输入自定义 Mapper 的名称及是否处理流数据等信息，最终生成 Mapper 工程：生成的 modbus mapper 工程将会被构建到 Mapper-Framework 的同级目录，工程结构可以参考本系列的第三篇文章中提供的详细说明。2、实现设备驱动功能在大多数情况下，开发者需要填充 Mapper 工程中的 driver 目录下的两个文件以及 Mapper 的配置文件。主要的工作集中在 devicetype.go 和 driver.go 文件中。在 devicetype.go 文件中，开发者需要填充设备协议的配置信息及属性访问的字段，而在 driver.go 文件中，需要实现设备初始化、数据获取等具体功能。👇🏻 以下是相关文件的示例：type ProtocolConfig struct { ProtocolName string `json:"protocolName"` ConfigData `json:"configData"`}type ConfigData struct { // TODO: add your protocol config data SerialPort string `json:"serialPort"` DataBits int `json:"dataBits"` BaudRate int `json:"baudRate"` Parity string `json:"parity"` StopBits int `json:"stopBits"`}type VisitorConfig struct { ProtocolName string `json:"protocolName"` VisitorConfigData `json:"configData"`}type VisitorConfigData struct { // TODO: add your visitor config data DataType string `json:"dataType"` Register string `json:"register"` Offset uint16 `json:"offset"` Limit int `json:"limit"` Scale float64 `json:"scale"` IsSwap bool `json:"isSwap"` IsRegisterSwap bool `json:"isRegisterSwap"`}在 devicetype.go 文件中，开发者需要填充协议参数（如 ConfigData）和属性访问参数（如 VisitorConfigData）。这些定义必须与 device-instance 中的字段保持一致，以确保 Mapper 能正确解析来自 device-instance 配置文件的参数值，从而实现设备与应用之间的数据交互。var clients *sync.Mapvar clientInit sync.Oncefunc initMap() { clientInit.Do(func() { if clients == nil { clients = new(sync.Map) } })}func NewClient(protocol ProtocolConfig) (*CustomizedClient, error) { client := &CustomizedClient{ ProtocolConfig: protocol, deviceMutex: sync.Mutex{}, // TODO initialize the variables you added } return client, nil}func (c *CustomizedClient) InitDevice() error { initMap() klog.Infoln("SerialPort : ", c.ProtocolConfig.SerialPort) v, ok := clients.Load(c.ProtocolConfig.SerialPort) if ok { c.ModbusClient = v.(modbus.Client) return nil } handler := modbus.NewRTUClientHandler(c.ProtocolConfig.SerialPort) handler.BaudRate = c.ProtocolConfig.BaudRate handler.DataBits = c.ProtocolConfig.DataBits handler.Parity = parity(c.ProtocolConfig.Parity) handler.StopBits = c.ProtocolConfig.StopBits client := modbus.NewClient(handler) clients.Store(c.ProtocolConfig.SerialPort, &client) c.ModbusClient = client return nil}func (c *CustomizedClient) GetDeviceData(visitor *VisitorConfig) (interface{}, error) { c.deviceMutex.Lock() defer c.deviceMutex.Unlock() var results []byte var err error switch visitor.Register { case "CoilRegister": results, err = c.ModbusClient.ReadCoils(visitor.Offset, uint16(visitor.Limit)) case "DiscreteInputRegister": results, err = c.ModbusClient.ReadDiscreteInputs(visitor.Offset, uint16(visitor.Limit)) case "HoldingRegister": results, err = c.ModbusClient.ReadHoldingRegisters(visitor.Offset, uint16(visitor.Limit)) case "InputRegister": results, err = c.ModbusClient.ReadInputRegisters(visitor.Offset, uint16(visitor.Limit)) default: return nil, errors.New("Bad register type") } klog.V(2).Info("Get result: ", results) return results, err}func (c *CustomizedClient) StopDevice() error { // TODO: stop device // you can use c.ProtocolConfig err := c.ModbusClient.Close() if err != nil { return err } return nil}在 driver.go 文件中，开发者根据 devicetype.go 中解析得到的协议配置字段和属性访问参数，实现设备驱动的具体功能。例如，在上面的示例中，我们实现了 Modbus 设备的初始化、数据获取以及设备停止等功能。具体实现需要根据所使用设备的协议和操作需求进行定制。除了设备驱动的实现外，开发者还需要修改 Mapper 的配置文件 config.yaml。一般来说，开发者只需填充 Mapper 的协议名字段（protocol）即可：grpc_server: socket_path: /etc/kubeedge/modbus.sockcommon: name: Modbus-mapper version: v1.13.0 api_version: v1.0.0 protocol: modbus # TODO add your protocol name address: 127.0.0.1 edgecore_sock: /etc/kubeedge/dmi.sock   部署自定义Mapper插件完成自定义 Mapper 工程的构建后，接下来就可以进行编译并将其部署到 KubeEdge 集群中。目前，推荐使用两种部署方式：二进制部署和 Deployment 部署。➤ 二进制部署二进制部署适合在开发和调试阶段使用。这种方式操作简便，适合快速运行和排查错误。通过以下命令，开发者可以直接在本地编译并运行 Mapper 插件：go run cmd/main.go --v <log level,like 3> --config-file <path to config yaml>在这条命令中，--v 参数用来设置日志级别，日志级别越高，输出的信息越详细；--config-file 参数则指定了 Mapper 配置文件的路径。➤ Deployment 部署当 Mapper 插件经过充分调试并能够稳定运行后，建议将其以容器的形式部署到 KubeEdge 集群中。通过使用 Mapper-Framework 生成的 Dockerfile，开发者可以构建 Docker 镜像并创建 Kubernetes Deployment，以便在生产环境中稳定运行。👇🏻 以下是一个示例 Deployment 配置：apiVersion: apps/v1kind: Deploymentmetadata: name: modbus-mapperspec: replicas: 1 selector: matchLabels: app: demo template: metadata: labels: app: demo spec: nodeName: edge-node # replace with your edge node name containers: - name: demo volumeMounts: # Required, mapper need to communicate with grpcclient and get the config - name: test-volume mountPath: /etc/kubeedge image: modbus-mapper:v1.0.0 # Replace with your mapper image name imagePullPolicy: IfNotPresent resources: limits: cpu: 300m memory: 500Mi requests: cpu: 100m memory: 100Mi command: ["/bin/sh","-c"] args: ["/kubeedge/main --config-file /kubeedge/config.yaml --v 4"] volumes: - name: test-volume hostPath: path: /etc/kubeedge type: Directory完成自定义 Mapper 插件的部署后，用户可以向集群创建 device-model 和 device-instance 资源，随后 Mapper 将收到通知并开始进行设备的管理，定期获取设备数据并进行推送。这样，就完成了边缘设备的云原生化管理，使设备的生命周期、数据采集、处理和推送过程都能够在云原生架构下高效、可靠地进行。通过本系列技术文章的深入探讨，我们全面分析了 KubeEdge 在 Device-IoT 领域的创新与实践，重点涵盖了基于物模型的设备管理 API、DMI 数据面能力的增强、Mapper-Framework 的设计与实现、使用 Mapper 完成视频流数据处理、设备数据写入以及自定义 Mapper 工程开发的实际案例。这些内容充分展示了 KubeEdge 如何有效推动边缘计算与物联网技术的融合，为边缘设备的云原生化管理提供了切实可行的解决方案。随着物联网设备的日益普及以及边缘计算需求的持续增长，KubeEdge 在设备管理和数据处理方面的独特优势将愈发突出。通过这一系列功能的实现，KubeEdge 为物联网设备的管理、数据流的处理以及边缘计算任务的执行提供了强大支持。我们期待更多开发者加入 KubeEdge 社区，共同为全球的边缘计算生态贡献力量。 相关链接：[1] Mapper-Framework 仓库：cid:link_6扫码回复“KubeEdge”进入技术交流群【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_5KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_7Slack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

由 Linux 基金会、云原生计算基金会 (CNCF）主办的全球云原生与开源顶级盛会 KubeCon + CloudNativeCon Europe 2025 [1] 近日于欧洲顺利落下帷幕。本届大会汇聚全球12000+参会者和4000多家与会企业，为期4天的日程包含300余场Keynote与Session，于泰晤士河畔共绘云原生与AI前沿技术图谱，共建云原生技术与应用繁荣生态。华为云在本届大会上携云原生与AI技术创新成果与展览展示精彩亮相，与全球开发者探讨云原生 AI 基础设施、多集群编排调度、边缘 AI、流量治理等开源领域发展成果与产业应用。正如会场随处可见的英伦风 Slogan “Mind the CrashLoop”，技术火花在欧洲碰撞，并为全球智能化演进注入新锐动能。作为云原生领域的先锋创新者与践行者，华为云对 Kubernetes、Istio 等社区的贡献一直位居全球前列，先后主导开源了业界首个智能边缘计算项目 KubeEdge、业界首个云原生 AI 调度引擎 Volcano、业界首个云原生多云容器编排引擎 Karmada 等多个 CNCF 项目，并持续带来了 Kuasar、Kmesh 等项目创新，拥有在任 CNCF 技术监督委员会 TOC 成员，多个 CNCF 项目技术委员会，治理委员会成员及核心 Maintainer 席位。下面，一起看看华为云在本次大会上的精彩分享。全球顶尖技术领袖，共启云原生下一个十年3月31日大会前一天，与会的 CNCF 技术监督委员会成员（TOC）[2] 集体亮相 Maintainer Summit，拉开本届KubeCon大会序幕。CNCF TOC 是云原生计算基金会的最高技术治理组织，由全球顶尖云原生技术专家组成，负责制定CNCF技术战略、审核项目准入与毕业、协调跨项目协作并推动生态演进，引领全球云原生技术方向。会上，TOC成员们介绍了委员会发展动向、GB、最终用户社区、入选标准等话题，和现场Maintainers畅聊未来协作与技术发展。Kevin Wang （右三）Lead of Cloud Native Open Source Team, Huawei Cloud; CNCF TOC  同时，CNCF Technical Advisory Groups 也正为云原生下一个十年倾注准备。在《 Preparing for the Next 10 Years in Cloud Native》演讲中，CNCF TOC 代表成员分享和讨论了全新的TAG结构、涉及的领域以及如何利用新的TAG来实现技术理念并带来ROI。华为云云原生团队开源负责人，中国本土唯一TOC成员王泽锋联合发表演讲，共启云原生下一个十年。 携手客户伙伴，华为云多领域前沿技术精彩亮相▍ AI基础设施构建与效能优化当前，大模型技术的快速发展正推动着模型参数和训练数据规模的持续增长，这给分布式训练系统的网络性能带来了新的挑战。作为CNCF认证的 Cloud-Native AI五大核心项目之一，Volcano项目针对LLMs训练与推理场景，提出了基于网络拓扑感知的高性能调度方案，该方案通过对任务调度算法和资源管理模型的深度优化，有效提升了分布式训练任务的执行效率。在网络拓扑感知、资源调度等方面，Volcano展现出了显著的技术优势，为AI大模型的训练和推理提供了更高效的底层支持。在本次技术大会上，Volcano社区核心维护者团队带来了精彩的技术分享。华为云云原生团队开源负责人王泽锋，Volcano社区Maintainer常旭征在议题《Cloud Native AI: Harness the Power of Advanced Scheduling for High-Performance AI/ML Training》[3] 中向与会者详细解读了Volcano在智能调度领域的最新突破，包括：基于拓扑感知的任务调度带来的性能提升方案、多集群AI任务调度、云原生混部等。这些创新成果为大规模模型训练提供了强有力的底层支撑。同时，受资源可用性、平台规模、高可用性保障以及业务资源池整合等关键因素影响，多集群AI基础设施已成为行业普遍选择。在实际生产部署中，通过实施智能调度策略配置、优化工作负载管理机制以及采用拓扑感知调度技术，能够有效平衡资源利用率与工作负载优先级，满足不同类型AI工作负载的差异化需求，从而显著提升AI训练和推理任务的整体效率。在《Balancing Cost and Efficiency: Day2 Optimization of Multi-Cluster AI Infrastructure》[4] 专题演讲中，王泽锋深入分享了多集群AI基础设施的持续优化实践，重点探讨了Day2阶段运维中的关键技术挑战和解决方案，为与会者提供了宝贵的实践经验参考。▍ 边云AI协同创新与应用随着5G网络、工业互联网、人工智能等技术的快速发展，边缘计算在推动数智化转型中发挥了重要作用，也迎来了诸多全新的挑战。来自华为云的云原生技术专家徐飞、鲍玥、王彬丞携手DaoCloud、谐云、Second State 等社区伙伴带来了云原生边缘计算的最新发展趋势分享。在系列演讲中，KubeEdge技术专家们就应对管理大规模异构边缘节点的关键挑战，在网络不稳定的情况下对 K8s List-watch 进行优化，避免频繁 relist 对服务端带宽的影响，如何使用KubeEdge和WasmEdge无缝管理边缘和云上的云原生LLM工作负载，如何通过协同算法实现跨云和边缘的灵活AI任务部署，以满足对实时性、准确性和隐私的多样化需求等边缘技术创新与应用领域进行了细致解析与探讨。今年，KubeEdge作为CNCF毕业项目参会，吸引了与会者的广泛关注，从零开始打造多元协作的开源社区成为现场开发者与企业关心的话题。KubeEdge的维护者们向与会者分享了KubeEdge的技术规划、社区治理、开发者成长和项目维护等方面的关键战略及毕业后的社区更新，介绍了KubeEdge在各种边缘环境（如智慧城市、工业物联网、边缘AI、机器人和零售）中的成功案例和见解。KubeEdge技术分享及演讲材料详见：主会场议题[5] ； 同场活动议题[6]▍ 多集群技术面向AI应用全景Karmada 是一个 Kubernetes 管理系统，让用户能够跨多个 Kubernetes 集群和云运行云原生应用程序。本届大会上，华为云云原生团队技术专家，Karmada社区 Maintainer 任洪彩联合社区伙伴在分享了 Karmada 的核心功能、生产环境案例以及过去一年的功能更新。在 KubeCon 前一日的 Maintainer Summit 上，Karmada 的社区用户与开发者，包括来自 Bloomberg 等的用户伙伴，共同组织了Karmada Project Meeting，就社区的发展的路线、特性研发、生产应用展开深度探讨。值得一提的是，本次大会上，Bloomberg 团队与社区深度合作，探讨了如何在多集群 K8s 上构建弹性数据管道，在多集群 K8s 上进行智能调度有状态工作负载、提高弹性和确保故障转移等复杂情况下的 Karmada 应对策略，以及如何利用 Karmada 支持其他有状态用例。Karmada 技术分享及演讲材料详见：Karmada议程 [7]▍ 云原生AI时代的 “ 流量 ” 密码云原生AI浪潮下，流量治理效能及安全性的重要性尤为凸显。Service Mesh 为云原生应用带来了透明的治理功能，虽然服务网格已经成为微服务管理的事实标准，但传统的 sidecar 实现面临着严峻的挑战：巨大的资源开销（内存/CPU消耗30-50%）和时延，Sidecar 生命周期与应用紧耦合，运维成本复杂。Kmesh[8] 将流量治理下沉内核 eBPF，提供高性能无边车服务网格解决方案，为业界带来流量治理创新的架构演进。通过战略性地将 eBPF 与远程代理集成，Kmesh 与基于边车的网格相比，资源消耗减少了90%。此新一代架构在保持完整的 Istio API 兼容性的同时，实现了10倍的 CPU 使用率提升、2倍的连接数提升和1.5倍的延迟优化，提供了传统服务网格的生产就绪替代方案。华为云云原生团队专家徐中虎，Kmesh 社区核心成员田慕阳在会上诠释了这一稳定易用的高性能 Sidecarless 服务网格方案。 持续开放创新，共启AI-Native Cloud体验在 N350 华为展台，华为云向与会者展示了 AI-Native Cloud 创新产品，“ AI 计算云服务”、“加速数智融合”、“ Serverless 云原生基础设施”等主题展屏与专家讲解，将 AI 驱动的产品和产业生态娓娓道来。云容器实例（CCI）[9]、云容器引擎（CCE）[10] 、分布式云原生服务(UCS)[11] 等AI原生基础设施产品也在本次云原生盛会上备受关注。与此同时，华为云及社区伙伴讲解专家，也在 KubeEdge、Volcano、Karmada、Kmesh 等 CNCF 项目展台，与参会者们面对面畅谈云原生边缘 AI、智能调度、多云容器、流量治理等技术创新发展趋势与行业应用。Mind the CrashLoop！持续开放创新，华为云领先构筑AI-Native 基础设施，加速企业数智化转型。作为CNCF在亚洲唯一创始成员，华为云早自2015年起，就投身于云原生社区建设，贡献多项 K8s 关键技术特性，在 Istio 等社区代码贡献量连续多年排名亚洲 No.1。结合在云原生领域的长期深耕与创新，华为云在云原生 Al 、Serverless 架构、多云和混合云战略、云边端协同等领域均有领先的商用级产品，以技术革新为驱动，打造业界领先的云原生解决方案，连续八次中国容器软件市场份额 TOP1，为企业数智化转型提供强大动力。通过持之以恒的产业实践、贡献投入与生态合作，我们期待共同促进云原生产业生态的繁荣，共赢更加创新、智能的未来。我们的实践也将不断向 AI-Native 的云演进，加速全球智能化发展。 相关资料[1] KubeCon + CloudNativeCon Europe 2025: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/[2] CNCF 技术监督委员会成员（TOC）: https://www.cncf.io/people/technical-oversight-committee/[3] Cloud Native AI: Harness the Power of Advanced Scheduling for High-Performance AI/ML Training》: https://sched.co/1td1E[4] 《Balancing Cost and Efficiency: Day2 Optimization of Multi-Cluster AI Infrastructure》: https://sched.co/1tx7c[5] KubeEdge 主会场议题: https://kccnceu2025.sched.com/?searchstring=KubeEdge[6] KubeEdge同场活动议题: https://colocatedeventseu2025.sched.com/?searchstring=KubeEdge[7] Karmada议程: https://kccnceu2025.sched.com/?searchstring=Karmada[8] Kmesh: https://kmesh.net/en/[9] 云容器实例（CCI）: cid:link_4[10] 云容器引擎（CCE）: cid:link_5[11] 华为云 UCS: cid:link_6 【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_3 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

    关注容器魔方获取更多华为云参会动态

作者：王彬丞&杨志佳&刘家伟针对新版本 Device-IoT 领域的更新，我们计划推出一系列的文章对这些特性进行详细的介绍，大致的文章大纲为：1. 基于物模型的设备管理 API 设计与实现2. DMI 数据面能力设计与实现3. Mapper 开发框架 Mapper-Framework 设计与实现4. 如何使用 Mapper 完成视频流数据处理5. 如何使用 Mapper 实现设备数据写入6. 如何从头开发一个 Mapper（以 modbus 为例）  在上一篇文章中，我们介绍了通过 Mapper-Framework 实现摄像头设备的纳管以及视频流数据处理的功能，显著提升了设备数据的采集和读取能力，使数据面的能力进一步增强。 然而，在实际的生产环境中，设备管理不仅涉及数据的读取，还可能需要将处理后的数据回写到设备，以执行特定的控制指令或调整运行参数。因此在KubeEdge 1.19版本中，Mapper-Framework 增强了对设备的管理能力，新增了设备数据写入的功能，使边缘设备的管控更加完善。  Device Method API 简介  从物模型的传统定义来看，设备的参数按照功能类型通常分为三类：属性（Property）：用于描述设备状态，例如温度传感器所读取的环境温度、插座的开关状态等。方法（Method）：设备可被外部调用并执行的方法，例如调整设备参数等。事件（Event）：描述设备上报云端的事件。在本系列的第一篇文章中，我们已经在 v1beta1 版本的设备管理 API 中引入了设备属性（Property） 的定义，使用户可以获取设备的状态。而在 KubeEdge 1.19 版本中，我们进一步扩展了 API，引入了设备方法（Device Method），允许用户调用设备方法实现对设备属性的动态控制。Device Method 的 API 定义如下：// DeviceMethod describes the specifics all the methods of the device. type DeviceMethod struct { // Required: The device method name to be accessed. It must be unique. Name string `json:"name,omitempty"` // Define the description of device method. // +optional Description string `json:"description,omitempty"` // PropertyNames are list of device properties that device methods can control. // Required: A device method can control multiple device properties. PropertyNames []string `json:"propertyNames,omitempty"` }在 Device Method 的设计中，它主要由以下三个核心字段构成：➤ Name：用于标识设备方法，在同一device-instance 内，每个方法的名称必须是唯一的。➤ Description：用于说明该方法的具体用途。➤ PropertyNames：定义该方法能够操作的设备属性列表，一个方法可以控制多个设备属性下面是一个 device-instance 配置文件示例，展示了如何添加 Device Method：apiVersion: devices.kubeedge.io/v1beta1 kind: Device metadata: name: sensor-tag-instance-02 namespace: default spec: deviceModelRef: name: sensor-tag-model nodeName: edge-node properties: - name: temperature visitors: ... methods: - name: setValue description: This method aim to writing values to device properties propertyNames: - temperature - name2这里我们为 sensor-tag-instance-02 的设备定义了一个 setValue 方法，该方法允许用户修改 temperature 和 name2 这两个设备属性的值。需要注意的是，在 device-instance 配置文件中定义的 Device Method 仅是方法的框架性定义，具体的功能实现仍然需要在 mapper 设备驱动层完成。  Mapper-Framework    设备数据写入接口  用户通过 Device Method API 定义设备方法的框架之后，需要在 mapper 设备驱动层根据预定义的方法，实现相应的数据写入逻辑。为简化用户操作，1.19版本的 Mapper-Framework 实现了设备写入的接口：func (c *CustomizedClient) DeviceDataWrite(visitor *VisitorConfig, deviceMethodName string, propertyName string, data interface{}) error { // TODO: add the code to write device's data // you can use c.ProtocolConfig and visitor return nil }具体来说，用户可以调用 device-instance CRD 中设备协议配置信息（ProtocolConfig）以及设备属性访问配置（VisitorConfig），实现对设备寄存器的写入操作。例如，在 Modbus 设备中，用户可以根据 VisitorConfig 访问特定的 Modbus 寄存器地址并写入新值，进而控制设备的运行状态。 Mapper-Framework Restful API 能力增强  在KubeEdge 1.19版本中，Mapper-Framework 扩展了 Restful API，使用户可以更加便捷地查询和调用 Device Method，具体功能如下：➤ 获取设备的所有设备方法Url: https://{mapper-pod-ip}:{mapper-api-port}/api/v1/devicemethod/{deviceNamespace}/{deviceName} Response: { "Data": { "Methods": [ { "Name": "setValue", "Path": "/api/v1/devicemethod/default/random-instance-01/setValue/{propertyName}/{data}", "Parameters": [ { "PropertyName": "random-int", "ValueType": "int" } ] } ] } }从 Response 中可以看出，目标 device 拥有名为 setValue 的 Device Method，可以通过 Path 中显示的字段进行调用。此外，setValue method 可以用来控制 random-int 这一设备属性。➤ 创建设备数据写入请求Url: https://{mapper-pod-ip}:{mapper-api-port}/api/v1/devicemethod/{deviceNamespace}/{deviceName}/{deviceMethodName}/{propertyName}/{data} Response: { "statusCode": 200, "Message": "Write data ** to device ** successfully." }用户通过 Restful API 发起设备数据写入请求有两种方式：1）边缘端调用用户可以直接在边缘节点上，通过 Mapper Pod 暴露的 Restful API 发送请求，直接与设备交互，实现低延迟的本地控制。2）云端调用在云端，用户可以借助 EdgeMesh 等组件，将请求从云端转发至对应的边缘节点，然后由 Mapper 处理并执行设备写入操作。无论采用哪种调用方式，Mapper 在接收到设备数据写入请求后，会执行以下操作：解析请求内容，获取目标设备、目标方法及其参数。调用设备驱动层中的 DeviceDataWrite 功能，按照定义的协议与设备进行通信。完成设备属性的写入，更新设备状态。截至目前，本系列文章已经系统地介绍了 KubeEdge SIG Device-IoT 自1.15版本以来的核心特性，包括：基于物模型的设备管理 API， 能够更全面的描述物理设备。DMI 数据面能力增强Mapper-Framework 开发框架原理，用于简化用户开发自定义 mapper 插件。使用 Mapper 进行视频流数据采集与上报，支持摄像头等设备的数据接入。使用 Mapper 进行设备数据写入，增强边缘设备管理能力。在本系列的最后一篇文章中，我们将向大家展示如何从零开始基于 Mapper-Framework 开发一个 Modbus 协议的 Mapper 插件，并详细讲解如何定义设备模型、构建 Mapper 工程、实现设备驱动、获取并推送设备数据，从而帮助开发者更高效地构建和集成自定义 Mapper 组件。    扫码回复“KubeEdge”进入技术交流群 【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_4KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_5Slack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。  Karmada v1.13 版本[1]现已发布，本版本包含下列新增特性：新增应用优先级调度功能，可用于保证关键作业时效性新增应用调度暂停与恢复功能，可用于构建多集群队列系统Karmada Operator 功能持续演进Karmada 控制器性能优化提升Karmada Dashboard 首个版本发布！开启多云编排可视化新篇章   新特性概览  应用优先级调度当前，Karmada 调度器调度负载时遵循 FIFO 策略，按照负载进入调度队列的次序依次调度。但在某些场景，比如AI训练类作业平台，用户希望工作负载能够按照优先级进行调度。这样当高优先级、紧急任务进入调度队列时，可以实现“插队”的效果，从而确保关键业务的时效性与服务质量。从 v1.13.0 版本起，用户使用 PropagationPolicy 分发负载时可以指定调度优先级(.spec.SchedulePriority 字段)。SchedulePriority 会指向用户事先配置的优先级类，Karmada 解析该优先级类并获取对应的优先级数值，值越大，调度优先级越高。例如，需要在环境中部署 A，B 两种应用，应用A 负责在线交易这类对实时性要求高的业务，而应用B 负责定期日志清理等非紧急且对时间不敏感的业务。为确保在资源紧张时，应用A 能优先被调度，可以给应用A 配置较大的优先级类。应用A 的优先级类和 PropagationPolicy 配置：apiVersion:scheduling.k8s.io/v1 kind:PriorityClass metadata: name:high-priority value:1000000 --- apiVersion:policy.karmada.io/v1alpha1 kind:PropagationPolicy metadata: name:propagation-a spec: schedulePriority: priorityClassSource:KubePriorityClass priorityClassName:high-priority placement: clusterAffinity: clusterNames: -member1 resourceSelectors: -apiVersion:apps/v1 kind:Deployment name:application-a应用B 的优先级类和 PropagationPolicy 配置：apiVersion: scheduling.k8s.io/v1 kind:PriorityClass metadata: name:low-priority value:1 --- apiVersion:policy.karmada.io/v1alpha1 kind:PropagationPolicy metadata: name:propagation-b spec: schedulePriority: priorityClassSource:KubePriorityClass priorityClassName:low-priority placement: clusterAffinity: clusterNames: -member1 resourceSelectors: -apiVersion:apps/v1 kind:Deployment name:application-b 通过上述配置，当调度队列同时存在应用A 和 应用B 的工作负载时，应用A 会被优先调度，即便应用B 先进入队列。更多有关应用优先级调度的资料请参考：应用优先级调度[2]  应用调度暂停与恢复应用从 Karmada 控制面分发到成员集群大致可以分为两个环节：应用调度：Karmada 调度器根据分发策略为应用选择合适的集群。应用分发：Karmada 控制器按照调度结果将应用分发到指定的集群。Karmada 现已支持应用调度及分发过程的启停控制，这一能力为用户提供了灵活的调度管理手段。基于此，用户可根据实际业务需求，构建定制化的高级调度策略。例如，可将其与业务发布流程相结合，实现联邦应用跨集群的滚动升级；也可结合工作负载优先级，达成队列与工作负载的优先级调度。其中应用分发环节的暂停与恢复是在 v1.11.0 版本引入的功能，详细请参考：应用分发暂停与恢复[3]。而在 v1.13.0 版本，Karmada 正式引入了应用调度环节的暂停与恢复。社区在字段 ResourceBinding.Spec.Suspension 中新增了字段 Scheduling，用于控制应用调度的暂停与恢复。当 Suspension.Scheduling 为 true 时，应用调度暂停。当 Suspension.Scheduling 为 false 时，应用调度恢复。此功能可以与第三方系统集成，通过控制 ResourceBinding 的 Suspension.Scheduling 的字段值，实现对应用调度过程的精准控制。例如，在创建 ResourceBinding 时，可通过 webhook 将 Suspension.Scheduling 设置为 true 以暂停调度；随后，可对应用进行优先级排序、容量规划等操作；待相关操作完成后，设置 Suspension.Scheduling 为 false 即可恢复调度，最终实现有序调度/资源配额管理等高级能力。更多有关应用调度暂停与恢复的资料请参考：应用调度暂停与恢复能力[4] Karmada Operator 功能持续演进本版本持续增强 Karmada Operator，新增以下功能：支持配置 API Server 边车容器：用户可通过此功能为 Karmada API Server 配置边车容器，从而集成辅助服务。例如，可集成 KMS 插件[5]，实现静态数据加密。更多有关 API Server 边车容器配置的资料请参考：支持配置 API Server 边车容器[6]支持配置组件优先级类：用户可通过自定义 Karmada CR 为控制平面组件指定优先级类，确保关键组件以适当的优先级进行调度，从而提升 Karmada 系统的可靠性和稳定性。更多有关组件优先级类配置的资料请参考：如何为 Karmada 控制平面组件配置优先级类[7]以上新特性进一步提升了 Karmada Operator 的可配置性，满足用户多样化需求。 Karmada 控制器性能优化提升随着 Karmada 被业界广泛采纳，以及部署的规模不断提升，性能优化也成了 Karmada 关注和发力的重要方向。社区成立了性能优化团队，专门分析和优化 Karmada 关键组件的性能，并已取得了显著的成效。在版本 v1.13.0，Karmada 的性能优化主要集中在控制器，减少大规模数据部署场景下，控制器重启时的性能开销。为了验证性能优化的成效，社区准备了 12C CPU, 28G RAM 的物理机，并部署了 1000 个 Deployments 和 1000个 Configmaps，共生成 2000 个 ResourceBindings。在重启组件 karmada-controller-manager 后，收集 workqueue 的指标，结果如下：对于 Detector 控制器：队列 Reconcile 时间降低了60%。对于 binding-controller 控制器：队列 Reconcile 时间降低了25%。这些指标显示了在版本 v1.13.0，控制器 Detector 和 binding-controller 在重启场景下存量资源重新编排的性能有了显著的提升。 Karmada Dashboard 首个版本发布经过数位热心开发者的持续努力，Karmada Dashboard 终于迎来了具有里程碑意义的第一个版本（v0.1.0）！这一版本标志着 Karmada 在可视化管理领域迈出了重要的一步。Karmada Dashboard 是一款专为 Karmada 用户设计的图形化界面工具，旨在简化多集群管理的操作流程，提升用户体验。通过 Dashboard，用户可以直观地查看集群状态、资源分布以及任务执行情况，同时还能轻松完成配置调整和策略部署。Karmada Dashboard v0.1.0 主要功能包括：集群管理： 提供集群接入和状态概览，包括健康状态、节点数量等关键指标。资源管理：业务资源配置管理，包括命名空间、工作负载、服务等。策略管理：Karmada 策略管理，包括分发策略、差异化策略等。更多有关 Karmada Dashboard 的资料请参考：Karmada Dashboard[8] 致谢贡献者Karmada v1.13 版本包含了来自 41 位贡献者的 205 次代码提交，在此对各位贡献者表示由衷的感谢：贡献者列表：   参考资料[1] Karmada v1.13 版本: https://github.com/karmada-io/karmada/releases/tag/v1.13.0[2] 应用优先级调度: https://github.com/karmada-io/karmada/tree/master/docs/proposals/scheduling/binding-priority-preemption[3] 应用分发暂停与恢复: https://karmada.io/docs/next/userguide/scheduling/resource-propagating/#suspend-and-resume-of-resource-propagation[4] 应用调度暂停与恢复能力: https://github.com/karmada-io/karmada/tree/master/docs/proposals/scheduling-suspension[5] KMS 插件: https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/[6] 支持配置 API Server 边车容器: https://github.com/karmada-io/karmada/tree/master/docs/proposals/karmada-operator/api-server-sidecard-containers[7] 如何为 Karmada 控制平面组件配置优先级类: https://karmada.io/zh/docs/administrator/configuration/priority-class-configuration/#%E5%A6%82%E4%BD%95%E4%B8%BA-karmada-%E6%8E%A7%E5%88%B6%E5%B9%B3%E9%9D%A2%E7%BB%84%E4%BB%B6%E9%85%8D%E7%BD%AE%E4%BC%98%E5%85%88%E7%BA%A7%E7%B1%BB[8] Karmada Dashboard: cid:link_1  添加社区小助手进入Karmada交流群 👉Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：https://github.com/karmada-io/karmadaSlack地址：https://slack.cncf.io/（#karmada）

AI与云原生技术正以前所未有的速度改变着我们的世界，而云原生技术则如同一座坚实的桥梁，连接着传统IT与现代化的数字世界。当AI与云原生相遇，它们相互赋能，相互促进，为开发者们打开了一个全新的技术宇宙。 3 月 15 日，2025年全球首场KCD将于北京举办，本次KCD北京站包含KEYNOTES+AI分论坛，CLOUD NATIVE分论坛，组织团队由多位行业专家和资深技术人士组成，他们致力于为大家打造一场充满活力和包容性的社区技术活动。一场关于AI与云原生的技术盛宴，正等待着大家的加入！来自华为、摩尔线程等Volcano云原生批量计算社区专家，将在KEYNOTES+AI分论坛带来两场分享，邀您畅聊云原生智能调度技术与应用： ▍KCD北京站 Volcano议程预告      3月15日 13:15-13:45    AI 编排能力提升:基于昇腾硬件的智能调度方案    Shuqiao Li (华为，高级工程师) Chen Zicong (Huawei Cloud, Member of Volcano,R&D Engineer of Huawei Cloud)     3月15日 16:35-17:05     基于Volcano的拓扑感知调度方案在大规模AI工作负载与多样化网络集群中的应用    Xiaodong Ye (Moore Threads,SDE) Yu Zhou (Moore Threads,SDE)  查看完整议程Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。Volcano 云原生批量计算项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。社区已吸引5.8万+全球开发者，并获得4.4k Star 和1K+Fork，参与贡献企业包括华为、AWS、百度、腾讯、博云、京东、小红书、第四范式、bilibili等。社区地址：cid:link_1  目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到广泛应用，完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene、Ray 等众多主流计算框架的支持，并构建起完善的上下游生态。 报名参会KCD（北京站）：📅 活动日期：2025年3月15日（周六）📍 活动地点：北京市海淀区魏公村路6号院丽金智地中心💡 活动形式 ：技术分享+开源集市+有奖问答+精美茶歇ℹ️ 温馨提示 ：因场地方管理要求，请通过二维码或链接https://hdxu.cn/y0a9指引填写真实参会信息，确保无障碍入园参会。    【更多Volcano干货推荐】Volcano云原生批量计算公开课Volcano云原生批量计算公开课Volcano云原生批量计算公开课由CNCF首个批量计算社区Volcano核心贡献者开发，通过理论学习+实践操作，帮助学习者由浅入深了解批量计算原理和生产场景应用，晋升批量计算达人！点击免费学习Volcano云原生批量计算公开课社区介绍：Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene、Ray 等众多主流计算框架的支持，并构建起完善的上下游生态。Volcano官网：https://volcano.shGitHub: cid:link_1每周例会：https://zoom.us/j/91804791393

Karmada 社区非常高兴地宣布，社区孵化的 Dashboard 项目，经过数位热心开发者的持续努力，终于迎来了具有里程碑意义的第一个版本（v0.1.0）！这一版本标志着 Karmada 在可视化管理领域迈出了重要的一步。 关于 Dashboard 项目  Karmada Dashboard [1] 是一款专为 Karmada 用户设计的图形化界面工具，旨在简化多集群管理的操作流程，提升用户体验。通过 Dashboard，用户可以直观地查看集群状态、资源分布以及任务执行情况，同时还能轻松完成配置调整和策略部署。    功 能 特 性   Karmada Dashboard v0.1.0 [2] 主要功能包括：集群管理：提供集群接入和状态概览，包括健康状态、节点数量等关键指标。资源管理：业务资源配置管理，包括命名空间、工作负载、服务等。策略管理：Karmada策略管理，包括分发策略、差异化策略等。 集群管理集群管理页面可以查看到所有成员集群的列表，管理集群的接入和删除： 资源管理通过资源管理页面可以查看、管理各类业务配置资源，包括命名空间、工作负载、Service、ConfigMap、Secret等。命名空间管理如下图所示：策略管理通过策略管理页面可以查看并管理分发策略（PropagationPolicy）和差异化策略（OverridePolicy）, 分发策略展示如下： 快 速 体 验  安装和使用 Karmada Dashboard 非常简单，项目仓库提供了完整的安装部署指导，欢迎安装体验！ cid:link_3    未 来 计 划   第一个版本的发布只是一个开始，它还未经历足够的验证，尚不具备生产上使用的条件，未来的 Karmada Dashboard 将继续添加更多功能、增强稳定性并优化使用体验。以下是我们的一些计划：构建成员集群资源视图，提供全局资源管理能力系统稳定性、易用性、交互体验提升构建系统监控视图，提供控制面组件监控能力多平台支持，如增加arm64平台支持如果您有任何建议或需求，欢迎随时通过社区渠道与我们联系。 致 谢 开 发 者 在这里，我们要特别感谢以下几位核心开发者为 Karmada Dashboard 的发布做出的卓越贡献：贡献者（GitHub） 丁文江（@warjiang）主导项目开发，包括前后端设计和开发。船长（@samzong)一个挚爱开源的产品经理，帮助审查前后端设计任洪彩（@RainbowMango）Karmada社区维护者，为Dashboard 的开发提供了全方位支持，包括基础设施构建、版本规划、代码审查等 李恒锐(@Heylosky)Asif (@axif0)一位热爱探索新问题并将想法转化为有影响力的解决方案的开发人员。余浩铭（@chouchongYHMing）本科在读生，支持朝九晚五和上四休三 他们的努力让这个项目从构想变成了现实。我们也欢迎更多开发者加入 Karmada 社区，一起推动 Dashboard 的进一步发展！  欢 迎 加 入 我 们 Karmada Dashboard 开发团队由Karmada 用户以及热心开发者组成，Karmada Dashboard 的开发离不开社区小伙伴的支持与贡献。如果你对云原生技术感兴趣，并希望参与一个充满挑战和创新的开源项目，欢迎加入我们的团队！我们目前特别需要以下角色：前端开发者：负责 Dashboard 的界面设计与交互优化，提升用户体验。后端开发者：负责 API 开发、数据集成以及性能优化，确保系统的稳定性和高效性。无论你是初学者还是资深工程师，我们都欢迎你的加入！你可以通过以下方式参与：参与我们的例会，了解开发进展：cid:link_1提交你的第一个 Pull Request！ 帮助我们修复bug或提供新的功能。我们相信，你的加入将为 Karmada Dashboard 带来更多可能性。期待与你一起打造更好的多集群管理工具！ 更多阅读[1] Karmada Dashboard: cid:link_3[2] Karmada Dashboard v0.1.0: cid:link_2 👉Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：cid:link_4Slack地址：https://slack.cncf.io/（#karmada）  添加社区小助手进入Karmada交流群

Karmada 社区非常高兴地宣布科大讯飞正式加入Karmada 用户组[1]（Karmada Adopter Group），成为该开源社区的重要成员。作为云原生计算基金会（CNCF）旗下的开源项目，Karmada 致力于为用户提供强大的多集群管理和调度能力，帮助企业在复杂的分布式环境中实现高效的应用部署和管理。科大讯飞的加入将进一步丰富 Karmada 社区的生态，并为项目的持续创新注入新的动力。    关于科大讯飞  科大讯飞股份有限公司成立于1999年，是亚太地区知名的智能语音和人工智能上市企业。自成立以来，长期从事语音及语言、自然语言理解、机器学习推理及自主学习等核心技术研究并保持了国际前沿技术水平；积极推动人工智能产品研发和行业应用落地，致力让机器“能听会说，能理解会思考”，用人工智能建设美好世界。作为中国人工智能“国家队”，科大讯飞承建了中国唯一的认知智能全国重点实验室和语音及语言信息处理国家工程研究中心，同时是中国语音产业联盟理事长单位、中科院人工智能产学研创新联盟理事长单位、长三角人工智能产业链联盟理事长单位。[2]   关于Karmada用户组   作为连接社区与用户的核心纽带，Karmada 用户组致力于打造一个深度融合、开放协作的高价值平台，推动成员间的高效联动与经验共享。通过技术支持、活动共创及最佳实践交流，Karmada 用户组将持续赋能用户在多云管理领域的能力提升，助力云原生多云多集群生态系统的蓬勃发展。其主要目标和功能包括：分享知识：促进 Karmada 用户之间的经验、挑战和解决方案交流促进协作：提供一个用户可以协作、分享想法并解决共同问题的平台支持用户：提供资源、教程和指导，帮助用户有效利用 Karmada收集反馈：倾听用户声音，以指导 Karmada 未来的发展方向社区活动组织：通过定期 meetup、网络研讨会和其他活动，增强社区参与度截至目前，Karmada 用户组已吸纳来自全球的30+家机构和组织。更多使用场景及案例研究请查阅：https://karmada.io/adopters  欢迎加入用户组    任何在生产环境中使用 Karmada 的公司，其开发者均可申请加入 Karmada 用户组。无论您是最终用户还是云厂商，我们都欢迎您的加入。最终用户：指在其内部 IT 基础设施中直接部署和使用 Karmada 进行多云或多集群管理的企业或组织。这些公司利用 Karmada 作为关键技术底座来管理和优化算力资源。供应商：指那些将 Karmada 集成到他们的产品或服务中，以提供给其他企业或组织使用的公司。 加入 Karmada 用户组，您可以与面临类似挑战的同行建立联系并分享 Karmada 实践经验，一同探索多云多集群生态，包括但不限于以下内容：社区技术支持：包括且不限于方案评估、日常运维、问题定位、版本升级等社区支持公司知名度提升：您的公司和团队将获得全球范围内更多的曝光机会技术影响力构建：邀请共建技术演讲，包括 KubeCon 等海内外业界大会，Karmada 社区伙伴举办的线上、线下系列会议保持信息同步：及时接收重要信息更新，包括新版本的关键特性、重要 Bug 修复、安全风险等内容，确保您的项目能够第一时间受益于新的改进和增强。顶尖人才招募：利用社区渠道招聘宣传，全球范围内精准招募优秀人才拓展商业机会：与 Karmada 生态系统其他成员建立潜在的商业联系和合作 当前，加入 Karmada 用户组对社区贡献没有硬性要求，我们鼓励成员积极参与社区活动，分享经验与见解。然而，请注意，未来可能会要求成员对 Karmada 社区做出一定的贡献，以维持其用户组成员身份。这种贡献可以包括但不限于代码提交、文档编写、问题修复、使用案例分享等。访问下方 Karmada 用户组申请表单 [3]，提交 issue 申请，即可接收申请进度。手机端可扫描下方二维码快捷填写申请表单。  扫码申请加入用户组更多信息，请访问：[1] Karmada Adopter Group 详细信息，请查阅: cid:link_2[2] 科大讯飞详细介绍: https://www.iflytek.com/about.html[3] Karmada Adopter Group 申请加入表单地址: cid:link_0 Karmada Adopter Group 欢迎您的加入！期待与您共同创建一个友好而活跃的空间，共享知识、最佳实践和经验，为企业与社区发展缔造更多可能。如需了解更多关于Karmada Adopter Group的信息，请联系： Maintainer Mailing Listcncf-karmada-maintainers@lists.cncf.io  👉Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：cid:link_3Slack地址：https://slack.cncf.io/（#karmada） 

作者：王彬丞&杨志佳&刘家伟针对新版本 Device-IoT 领域的更新，我们计划推出一系列的文章对这些特性进行详细的介绍，大致的文章大纲为：1. 基于物模型的设备管理 API 设计与实现2. DMI 数据面能力设计与实现3. Mapper 开发框架 Mapper-Framework 设计与实现4. 如何使用 Mapper 完成视频流数据处理5. 如何使用 Mapper 实现设备数据写入6. 如何从头开发一个 Mapper（以 modbus 为例） 在上一篇文章中，我们介绍了Mapper开发框架Mapper-Framework。Mapper-Framework中集成了DMI管理面和数据面能力，能够自动生成Mapper工程供用户使用，有效降低Mapper的开发门槛。在1.15版本中，针对温湿度监测、酸碱度监测等数据离散的边缘场景，Mapper-Framework数据面能以多种方式定时采集上报单点数值。但在边缘计算中，摄像头之类流数据设备的管理也是不可或缺的部分。因此，在1.17版本中，Mapper-Framework增加了视频流数据处理的功能，完善了KubeEdge边缘设备的管理范围。 ONVIF摄像头设备纳管 在摄像头管理领域，ONVIF（Open Network Video Interface Forum） 是一种广泛应用的通用设备协议，旨在为视频监控及其他物理安全领域的IP设备之间的互联互通建立统一的标准，确保不同厂商的设备能够无缝集成和协作。在 KubeEdge 1.17 版本中，为了支持摄像头设备的云原生接入与管理，我们基于 Mapper-Framework 设计并实现了 ONVIF 协议的内置 Mapper，该插件已存放于 mappers-go 仓库中，用户只需运行该内置 Mapper[1] ，并根据自身摄像头设备的具体信息修改相应的 device 配置文件，即可完成摄像头设备的自动接入与纳管。通过这种方式，能够让 ONVIF 网络摄像头设备具备云原生能力，支持在边缘环境下进行统一管理、远程控制和数据采集。ONVIF 网络摄像头设备的 device-instance 配置文件主要包含以下关键字段：apiVersion: devices.kubeedge.io/v1beta1 kind: Device metadata: name: onvif-device-01 spec: ... protocol: protocolName: onvif configData: url: 192.168.168.64:80 # Replace it with the address of your own onvif camera userName: admin # Replace it with the username of your own onvif camera password: /etc/secret/password # Fill in the fields according to your secret.yaml上述字段指定了设备协议名称以及网络摄像头设备的 url、用户名以及密码，用户需要根据实际设备的详细信息进行修改。为避免密码明文存储，需要通过 Kubernetes secret 的形式完成挂载。完整的配置文件信息可以在配置文件示例[2] 获取。 Mapper-Framework支持视频流数据处理 在大多数应用场景中，摄像头设备通常通过 RTSP（Real-Time Streaming Protocol） 流的形式输出视频数据。根据 ONVIF 协议，Mapper 可以按照用户在device-instance配置文件中定义的参数，自动连接并获取摄像头的 profileToken 鉴权文件和 RTSP 流 URI，最终实现视频流数据的采集。为了简化用户对视频流数据的处理流程，在 KubeEdge 1.17 版本中，我们在  Mapper-Framework 的数据面内置了视频流数据处理功能，主要支持以下能力：➤ 内置视频片段存储功能：能够将设备上报的视频流自动转化为视频片段文件，便于存储和后续分析。➤ 内置视频帧存储功能：能够将视频流数据解析并存储为视频帧文件（图像序列），从而支持后续 AI 计算任务，如目标检测、行为识别等。用户只需在 device-instance 配置文件中进行相关配置，即可使用当前版本的流数据处理能力。此外还支持用户自定义流数据处理逻辑以满足特定的业务需求，例如视频流实时分析、AI 推理等。配置文件相关字段定义及对应结构如下：apiVersion: devices.kubeedge.io/v1beta1 kind: Device metadata: name: onvif-device-01 spec: ... properties: - name: saveFrame visitors: protocolName: onvif configData: format: jpg # Video frame file format outputDir: /tmp/case/ # Output path of video frame file frameCount: 30 # Number of output frame files frameInterval: 1000000 # interval between frames, the unit is nanoseconds dataType: stream - name: saveVideo visitors: protocolName: onvif configData: frameCount: 1000 # The number of frames the video clip contains format: mp4 # Video file format outputDir: /tmp/case/ # Output path of video file videoNum: 2 # Number of output video files dataType: stream在1.17 版本后，Mapper-Framework数据面能力得到了进一步增强。除了将设备数据推送至数据库和用户应用的功能外，还新增了对视频流数据的处理能力，显著提升了设备数据的采集和读取能力，使得边缘 AI 和视频分析等场景的集成更加便捷。然而，在实际的生产环境中，设备数据的写入也是一个至关重要的特性。例如，一些工业和安防应用场景需要将处理后的数据写回设备，以执行特定的控制指令或参数调整。在本系列的下一篇文章中，我们会对 Mapper 实现设备数据写入的功能进行详细的介绍。 ▍相关链接[1]  内置onvif Mapper：cid:link_2[2]  onvif device配置文件示例：cid:link_0 【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_1KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_3Slack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

Karmada 社区非常高兴地宣布挚文集团（NASDAQ : MOMO）正式加入Karmada 用户组（Karmada Adopter Group），成为该开源社区的重要成员。作为云原生计算基金会（CNCF）旗下的开源项目，Karmada 致力于为用户提供强大的多集群管理和调度能力，帮助企业在复杂的分布式环境中实现高效的应用部署和管理。挚文集团的加入将进一步丰富 Karmada 社区的生态，并为项目的持续创新注入新的动力。  关于挚文集团  挚文集团于2011年成立，2014年12月11日在美国纳斯达克交易所挂牌上市（NASDAQ: MOMO），拥有陌陌、探探等多款手机应用，以及电影制作发行、节目制作等多元业务。“挚文”这一中文名称代表了公司的人文理想：营造一种诚挚的企业文化氛围。同时“挚”又包含“执手”之意，意味着人与人的连接，与使命愿景相呼应。   关于Karmada用户组   作为连接社区与用户的核心纽带，Karmada 用户组致力于打造一个深度融合、开放协作的高价值平台，推动成员间的高效联动与经验共享。通过技术支持、活动共创及最佳实践交流，Karmada 用户组将持续赋能用户在多云管理领域的能力提升，助力云原生多云多集群生态系统的蓬勃发展。其主要目标和功能包括：分享知识：促进 Karmada 用户之间的经验、挑战和解决方案交流促进协作：提供一个用户可以协作、分享想法并解决共同问题的平台支持用户：提供资源、教程和指导，帮助用户有效利用 Karmada收集反馈：倾听用户声音，以指导 Karmada 未来的发展方向社区活动组织：通过定期 meetup、网络研讨会和其他活动，增强社区参与度截至目前，Karmada 用户组已吸纳来自全球的30+家机构和组织。更多使用场景及案例研究请查阅：https://karmada.io/adopters    欢迎加入用户组    任何在生产环境中使用 Karmada 的公司，其开发者均可申请加入 Karmada 用户组。无论您是最终用户还是云厂商，我们都欢迎您的加入。最终用户：指在其内部 IT 基础设施中直接部署和使用 Karmada 进行多云或多集群管理的企业或组织。这些公司利用 Karmada 作为关键技术底座来管理和优化算力资源。供应商：指那些将 Karmada 集成到他们的产品或服务中，以提供给其他企业或组织使用的公司。加入 Karmada 用户组，您可以与面临类似挑战的同行建立联系并分享 Karmada 实践经验，一同探索多云多集群生态，包括但不限于以下内容：社区技术支持：包括且不限于方案评估、日常运维、问题定位、版本升级等社区支持公司知名度提升：您的公司和团队将获得全球范围内更多的曝光机会技术影响力构建：邀请共建技术演讲，包括 KubeCon 等海内外业界大会，Karmada 社区伙伴举办的线上、线下系列会议保持信息同步：及时接收重要信息更新，包括新版本的关键特性、重要 Bug 修复、安全风险等内容，确保您的项目能够第一时间受益于新的改进和增强。顶尖人才招募：利用社区渠道招聘宣传，全球范围内精准招募优秀人才拓展商业机会：与 Karmada 生态系统其他成员建立潜在的商业联系和合作当前，加入 Karmada 用户组对社区贡献没有硬性要求，我们鼓励成员积极参与社区活动，分享经验与见解。然而，请注意，未来可能会要求成员对 Karmama 社区做出一定的贡献，以维持其用户组成员身份。这种贡献可以包括但不限于代码提交、文档编写、问题修复、使用案例分享等。访问下方 Karmada 用户组申请表单，提交 issue 申请，即可接收申请进度。手机端可扫描下方二维码快捷填写申请表单。扫码申请加入用户组 用户组申请链接：[1] Karmada Adopter Group 申请加入表单地址：cid:link_0[2] 更多Karmada Adopter Group 详细信息，请查阅：cid:link_2 Karmada Adopter Group 欢迎您的加入！期待与您共同创建一个友好而活跃的空间，共享知识、最佳实践和经验，为企业与社区发展缔造更多可能。如需了解更多关于Karmada Adopter Group的信息，请联系： Maintainer Mailing Listcncf-karmada-maintainers@lists.cncf.io  👉Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：cid:link_3Slack地址：https://slack.cncf.io/（#karmada）

KubeEdge作为业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，自2018年开源以来，吸引了全球来自30+国家的16万+开发者，当前已广泛应用于交通、工业制造、智能CDN、金融、航天、汽车、油气等行业。为了给社区用户和开发者带来更优质的体验，提供更完备的云原生边缘计算能力，社区在此发起2025年需求征集。请您抽时间填写我们的需求征集问卷，提出您宝贵的意见与建议，也欢迎加入社区，共建开放、创新的社区。KubeEdge社区2025年需求征集：https://shimo.im/forms/25q5Xpw5NXfPVr3D/fill  扫码提交需求KubeEdge社区      【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_1Slack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

由Linux Foundation组织的LFX Mentorship计划，从19年开始为CNCF各个开源社区中的开发人员持续提供带薪实习和指导。往年已获16w+申请，发起1200+课题，毕业近1000实习生，发放超过300万美金报酬。2025年春季申请时间为 2月5日-2月18日，远程实习将从 3 月 3 日开始为期三个月。参与到LFX Mentorship计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为$3000美金，约合￥20000人民币）。Volcano社区在LFX Mentorship计划的课题申请正在火热进行中，感兴趣的开发者即日起可前往官方平台申请:cid:link_3   Volcano社区介绍 Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。Volcano 云原生批量计算项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。社区已吸引5.8万+全球开发者，并获得4.4k Star 和1K+Fork，参与贡献企业包括华为、AWS、百度、腾讯、博云、京东、小红书、第四范式、bilibili等。社区地址：cid:link_4目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到广泛应用，完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene、Ray 等众多主流计算框架的支持，并构建起完善的上下游生态。在LFX Mentorship 2025春季计划，Volcano期待与你协作开拓AI大数据等场景调度的更多可能。   面向对象  春季计划申请者需在2025年2月18日前在LFX官网完成Mentee注册及项目申请。若被接收作为Mentee，您将能在开源社区经验丰富、积极贡献的Mentor指导下为开源项目做出贡献。依据官方规定[1]，对Mentee申请者有以下要求:计划开始时至少年满18周岁所在单位和组织不禁止该实习未参加另外的Linux Mentorship计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)并非社区中高于最低限度贡献成员（如Maintainer、Recurring Contributor）满足具体所属项目中提及的其它前置需求  课题参与方式 根据官方安排 [2]，LFX Mentorship 2025年春季活动流程如下：Mentee注册与项目申请 February 5 - 18, 2025 申请者审核期 February 19 - 25申请者入选通知 February 26实习启动 March 3, 2025中期考核 April 15, 2025首次津贴支付 April 16, 2025结项考核、实习生报告提交，最终津贴支付批准 May 27-28活动结束 May 30申请者需要在2月18日前完成Mentee注册和项目申请，流程详见/asup [3]/sup：a href="cid:link_1" target="_blank" rel="noopener"cid:link_1实习申请结果预计将在 2 月 26 日通知到申请人。主线开发日期为2025年3月3日-5月27日，全程线上协作，无需线下参与。结项需要在2025年5月27日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。  Volcano课题   今年，我们向各位申请者推荐CNCF Volcano社区下列课题：▍Volcano supports queue-level scheduling policies课题描述：Volcano支持在线和离线工作负载的统一调度，提供了丰富的调度插件和算法，并可以通过队列来区分不同的租户。Volcano目前的调度策略是全局配置，所有的队列使用相同的调度策略，但在实际场景中，不同的租户由于使用场景的不同，可能需要使用不同的调度策略。因此，volcano需要支持在队列层面设置和使用不同的调度策略，而不是使用全局统一的调度策略。预期结果：1. 修改队列CRD中，新增调度策略字段，用户可以设置队列级别的调度策略。2. Volcano调度器根据作业所在的队列执行相应的调度策略。前置技能：Go, Kubernetes, Volcano课题导师：Xuzheng Chang（@Monokaix ）2536818783@qq.comZicong Chen （@JesseStutler ）jesseincomparable@hotmail.com课题链接：cid:link_3project/a785c059-fb70-41aa-88a2-62692ab2ca98▍Coordinate descheduler and Volcano to support resource defragmentation 课题描述：Volcano社区提供了Volcano descheduler来支持重调度。相比于社区原生descheduler，支持负载感知重调度。同时资源碎片也是用户比较关心的问题，Volcano需要在现有的descheduler的基础上提供资源碎片整理能力，并需要保证被逐出的pod能够成功重新调度，这就需要Volcano descheduler和Volcano scheduler的配合来解决资源碎片问题，最大化资源利用率。预期结果：1. 基于Volcano descheduler实现资源碎片整理能力。2. Volcano scheduler与Volcano descheduler协同配合，确保可以重新成功调度被驱逐的Pod。前置技能：Go, Kubernetes, Volcano课题导师：Xuzheng Chang（@Monokaix ）2536818783@qq.comZicong Chen （@JesseStutler ）jesseincomparable@hotmail.com课题链接：cid:link_3project/607246c3-f48b-446c-a7cc-10c0068c553f▍Volcano dashboard feature enhancements课题描述：Volcano dashboard是Volcano资源的前端展示组件。当前该组件需要支持查看更多资源，并且支持创建、删除等操作。预期结果：1.支持查看除Volcano以外的资源。2.支持队列、Volcano job等资源的添加、删除、修改操作。前置技能：Kubernetes, React, Node, JS课题导师：Xuzheng Chang（@Monokaix ）2536818783@qq.comZicong Chen （@JesseStutler ）jesseincomparable@hotmail.com课题链接：cid:link_3project/438c1fec-d3d3-4ab0-82ce-499993f8b681 如果对课题内容有任何问题，欢迎向课题导师发送邮件或在GitHub仓库提交Issue提问。扫码回复“Volcano” 进入技术群今年春季，Volcano社区期待在 LFX Mentorship 见到您！参考资料[1] LFX Mentorship - Application Requirement: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/am-i-eligible [2] LFX Mentorship - Program Readme: cid:link_0[3] LFX Mentorship - Mentee Application Guideline: cid:link_1  【更多Volcano干货推荐】Volcano云原生批量计算公开课Volcano云原生批量计算公开课Volcano云原生批量计算公开课由CNCF首个批量计算社区Volcano核心贡献者开发，通过理论学习+实践操作，帮助学习者由浅入深了解批量计算原理和生产场景应用，晋升批量计算达人！点击免费学习Volcano云原生批量计算公开课社区介绍：Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene、Ray 等众多主流计算框架的支持，并构建起完善的上下游生态。Volcano官网：https://volcano.shGitHub: cid:link_4每周例会：https://zoom.us/j/91804791393

作为云原生批量计算领域的事实标准，Volcano已经在AI、Big Data及高性能计算 (HPC) 等多种场景中获得广泛应用，吸引了来自30多个国家的800多名贡献者，累计代码提交数万次。Volcano已在国内外60+企业进行了生产落地，经受住了实际生产环境的考验，赢得了用户的广泛赞誉，为业界提供了云原生批量计算的卓越实践标准与解决方案。随着用户使用场景的日益复杂，以及对资源利用率极致追求，特别是在AI大模型场景下，对训练与推理任务的性能、GPU资源利用率、可用性提出了更高的要求，促使Volcano不断拓展其应用场景，深入解决用户的核心诉求。Volcano目前的版本历程里共发布了28个release，针对批量计算的场景做了一系列功能增强和优化，帮助用户更好的将业务迁移到云原生平台，解决了诸多痛点问题，赢得了用户的广泛的喜爱与好评，用户与社区之间也形成了良好的互动，approver和reviewer数量累计发展了30+，达成了双赢互利的局面。值此2025新年之际，Volcano新版本将会是一个新的里程碑，社区将在2025年引入一系列重大特性，继续深耕CNAI(Cloud Native AI 云原生AI)和大数据等领域，主要特性包括：AI场景:网络拓扑感知调度: 降低训练任务间的网络传输开销，优化大模型训练场景下的性能。NPU卡调度和虚拟化能力: 提升NPU资源利用率。GPU卡动态切分能力:  提供MIG与MPS动态切分能力，提升GPU资源利用率。Volcano Global多集群AI作业调度: 支持跨集群的AI任务部署与拆分。断点续训与故障恢复能力优化:  支持更细粒度的作业重启策略。支持DRA：支持动态资源分配，灵活高效的管理异构资源。大数据场景:弹性层级队列能力: 帮助用户将大数据业务丝滑迁移到云原生平台。微服务场景：在离线混部与动态资源超卖: 提升资源利用率，同时保障在线业务QoS。负载感知调度与重调度: 提供资源碎片整理和负载均衡能力。Volcano v1.11的正式发布[1]，标志着云原生批量计算迈入全新阶段！本次更新聚焦AI与大数据的核心需求，推出网络拓扑感知调度、多集群AI作业调度等重磅特性，显著提升AI训练与推理任务的性能。同时，在离线混部与动态资源超卖及负载感知重调度功能进一步优化资源利用率，确保在线业务的高可用性。此外，弹性层级队列为大数据场景提供了更灵活的调度策略。Volcano v1.11不仅是技术的飞跃，更是云原生批量计算领域的全新标杆！    重磅特性详解   本次发布的v1.11版本针对AI、大数据和资源利用率提升场景提供一系列重磅特性更新，主要包含：▍网络拓扑感知调度：优化AI大模型训练性能在AI大模型训练场景中，模型并行（Model Parallelism）将模型分割到多个节点上，训练过程中这些节点需要频繁进行大量数据交互。此时，节点间的网络传输性能往往成为训练的瓶颈，显著影响训练效率。数据中心的网络类型多样，如InfiniBand (IB)、RoCE、NVSwitch等，且网络拓扑复杂，通常包含多层交换机。两个节点间跨的交换机越少，通信延迟越低，吞吐量越高。因此，用户希望将工作负载调度到具有最高吞吐量和最低延迟的最佳性能域，尽可能减少跨交换机的通信，以加速数据交换，提升训练效率。为此，Volcano提出了网络拓扑感知调度（Network Topology Aware Scheduling）策略，通过统一的网络拓扑API和智能调度策略，解决大规模数据中心AI训练任务的网络通信性能问题。 统一的网络拓扑API：精准表达网络结构为了屏蔽数据中心网络类型的差异，Volcano定义了新的CRD HyperNode来表示网络拓扑，提供了标准化的API接口。与传统的通过节点标签（label）表示网络拓扑的方式相比，HyperNode具有以下优势：语义统一：HyperNode提供了标准化的网络拓扑描述方式，避免了标签方式的语义不一致问题。层级结构：HyperNode支持树状层级结构，能够更精确地表达实际的网络拓扑。易于管理：集群管理员可以手动创建HyperNode，或通过网络拓扑自动发现工具维护HyperNode。一个HyperNode表示一个网络拓扑性能域，通常映射到一个交换机。多个HyperNode通过层级连接，形成树状结构。例如，下图展示了由多个HyperNode构成的网络拓扑：叶子HyperNode（s0、s1、s2、s3）：子节点为集群中的真实节点。非叶子HyperNode（s4、s5、s6）：子节点为其他HyperNode。在这种结构中，节点间的通信效率取决于它们之间的HyperNode层级跨度。例如：node0 和 node1 同属于s0，通信效率最高。node1 和 node2 需要跨两层HyperNode（s0→s4→s1），通信效率较低。node0 和 node4 需要跨三层HyperNode（s0→s4→s6），通信效率最差。 HyperNode配置示例以下是一个叶子HyperNode和非叶子HyperNode的配置示例：叶子HyperNode示例：apiVersion: topology.volcano.sh/v1alpha1 kind: HyperNode metadata: name: s0 spec: tier: 1 # HyperNode层级，层级越低通信效率越高 members: # 子节点列表 - type: Node # 子节点类型为Node selector: exactMatch: # 精确匹配 name: node-0 - type: Node selector: regexMatch: # 正则匹配 pattern: node-[01]非叶子HyperNode示例：apiVersion: topology.volcano.sh/v1alpha1 kind: HyperNode metadata: name: s6 spec: tier: 3 # HyperNode层级 members: # 子节点列表 - type: HyperNode # 子节点类型为HyperNode selector: exactMatch: # 精确匹配 name: s4 - type: HyperNode selector: exactMatch: name: s5 基于网络拓扑的感知调度策略Volcano Job和PodGroup可以通过 networkTopology 字段设置作业的拓扑约束，支持以下配置：mode：支持 hard 和 soft 两种模式。hard：硬约束，作业内的任务必须部署在同一个HyperNode内。soft：软约束，尽可能将作业部署在同一个HyperNode下。highestTierAllowed：与 hard 模式配合使用，表示作业允许跨到哪层HyperNode部署。例如，以下配置表示作业只能部署在2层及以下的HyperNode内（如s4或s5），否则作业将处于Pending状态：spec: networkTopology: mode: hard highestTierAllowed: 2通过这种调度策略，用户可以精确控制作业的网络拓扑约束，确保作业在满足条件的最佳性能域运行，从而显著提升训练效率。 未来展望Volcano将持续优化网络拓扑感知调度功能，未来计划：支持从节点标签自动转换为HyperNode CR，帮助用户迁移到Volcano。集成底层网络拓扑自动发现工具，简化HyperNode的管理。提供命令行工具，方便用户查看和管理HyperNode层级结构。关于Network Topology Awre Scheduling的详细设计与使用指导，请参考设计文档：Network Topology Aware Scheduling[2]。使用文档：Network Topology Aware Scheduling | Volcano[3]。由衷感谢社区开发者: @ecosysbin, @weapons97, @Xu-Wentao,@penggu, @JesseStutler, @Monokaix 对该特性的贡献！ ▍弹性层级队列：灵活的多租户资源管理策略在多租户场景中，资源分配的公平性、隔离性以及任务优先级控制是核心需求。不同部门或团队通常需要共享集群资源，同时又要确保各自的任务能够按需获得资源，避免资源争用或浪费。为此，Volcano v1.11 引入了弹性层级队列功能，大幅增强了队列的资源管理能力。通过层级队列，用户可以实现更细粒度的资源配额管理、跨层级资源共享与回收，以及灵活的抢占策略，从而构建高效、公平的统一调度平台。同时对于使用YARN的用户，可以使用Volcano无缝将大数据业务迁移到Kubernetes集群之上。弹性层级队列的核心能力Volcano的弹性层级队列具备以下关键特性，满足多租户场景下的复杂需求：支持配置队列层级关系：用户可以按需创建多级队列，形成树状结构。每个队列可以设置独立的资源配额和优先级，确保资源的合理分配。跨层级资源共享与回收：子队列资源空闲时，可以将资源共享给兄弟队列，当子队列提交任务时，可以从兄弟队列回收资源。细粒度的资源配额管理，每个队列可以设置以下资源参数：capability：队列的资源容量上限。deserved：队列应得的资源量。如果队列已分配的资源超过deserved值，超出的部分可以被回收。guarantee：队列的资源预留量，这部分资源不会被其他队列共享，确保队列的最低资源保障。灵活的抢占策略：支持基于优先级的资源抢占，确保高优先级任务能够及时获得所需资源。 层级队列示意图以下是一个简单的层级队列结构示例：根队列：作为所有队列的父队列，负责全局资源的分配与管理。部门队列：隶属于根队列，代表不同部门或团队的资源池。子队列：隶属于部门队列，代表具体的项目或任务，用户可以将作业提交到叶子队列。 适用场景多部门资源共享：在大型企业中，不同部门共享同一个集群，通过层级队列实现资源的公平分配与隔离。大数据任务调度：从YARN迁移到Kubernetes的用户，可以利用Volcano的层级队列功能，无缝迁移大数据业务。AI训练与推理：在AI场景中，不同训练任务或推理服务可以通过层级队列实现资源的动态分配与回收。关于弹性层级队列详细设计与使用指导，请参考:设计文档: hierarchical-queue-on-capacity-plugin[4]。使用文档: Hierarchica Queue | Volcano[5]。由衷感谢社区开发者: @Rui-Gan 对该特性的贡献！ ▍多集群AI作业调度：跨集群的统一管理与高效调度随着企业业务的快速增长，单个 Kubernetes 集群通常无法满足大规模 AI 训练和推理任务的需求。用户通常需要管理多个 Kubernetes 集群，以实现统一的工作负载分发、部署和管理。目前，已经有许多用户在多个集群中使用 Volcano，并使用 Karmada[6] 进行管理。为了更好地支持多集群环境中的 AI 任务，支持全局队列管理、任务优先级和公平调度等功能，Volcano 社区孵化了 Volcano Global[7]子项目。该项目将 Volcano 在单个集群中的强大调度能力扩展到多集群场景，为多集群 AI 任务提供统一的调度平台，支持跨集群任务分发、资源管理和优先级控制。Volcano Global 在 Karmada 的基础上提供了以下增强功能，以满足多集群 AI 任务调度的复杂需求： 核心能力Volcano Global在Karmada的基础上，提供了以下增强功能，满足多集群AI作业调度的复杂需求：支持Volcano Job的跨集群调度：用户可以在多集群环境中部署和调度Volcano Job，充分利用多个集群的资源，提升任务执行效率。队列优先级调度：支持跨集群的队列优先级管理，确保高优先级队列的任务能够优先获得资源。作业优先级调度与排队：在多集群环境中，支持作业级别的优先级调度和排队机制，确保关键任务能够及时执行。多租户公平调度：提供跨集群的多租户公平调度能力，确保不同租户之间的资源分配公平合理，避免资源争用。 关于Volcano Global的详细部署和使用指导，请参考: Multi-Cluster AI Job Scheduling | Volcano[8]。由衷感谢社区开发者: @Vacant2333, @MondayCha, @lowang-bh, @Monokaix 对该特性的贡献！ ▍在离线混部与动态资源超卖：最大化资源利用率，保障业务稳定性背景：资源利用率的挑战随着云原生技术的快速发展，Kubernetes已成为云原生时代的“操作系统”，越来越多的业务迁移到Kubernetes平台。然而，尽管云原生技术带来了灵活性和可扩展性，数据中心的资源利用率仍然较低。在线业务（如微服务）通常具有明显的波峰波谷特征，在波谷时段，大量资源处于闲置状态，而在波峰时段，资源又可能不足。为了提升资源利用率并保障高优先级业务的SLO（Service Level Objective），Volcano推出了云原生混部解决方案，通过在离线混部与动态资源超卖，最大化集群资源利用率，同时确保在线业务的稳定性。云原生混部的核心思想是将在线业务（如实时服务）和离线业务（如批处理任务）部署在同一个集群中。当在线业务处于波谷时，离线业务可以利用闲置资源；当在线业务达到波峰时，通过优先级控制压制离线业务，确保在线业务的资源需求。这种动态资源分配机制不仅提升了资源利用率，还保障了在线业务的服务质量。 业界实践：Volcano的独特优势业界已有许多公司和用户对在离线混部技术进行了探索与实践，但仍存在一些不足，比如不能做到和Kubernetes完全解耦，超卖资源计算方式粗糙，在离线作业使用方式不一致、用户体验不友好等问题。基于这些问题，Volcano对在离线混部技术进行了深度优化，具备以下独特优势：天然支持离线作业调度：Volcano Scheduler原生支持离线作业的调度与管理，无需额外适配。无侵入式设计：对Kubernetes无侵入式修改，用户无需调整现有集群架构即可使用。动态资源超卖：实时计算节点的可超卖资源，确保资源利用与业务QoS的平衡。OS层面的隔离与保障：通过内核级别的资源隔离机制，确保在线业务的优先级和稳定性。 Volcano云原生混部解决方案：端到端的资源优化Volcano的云原生混部解决方案从应用层到内核提供了端到端的资源隔离与共享机制，主要包括以下核心组件：Volcano Scheduler：负责在离线作业的统一调度，提供队列、组、作业优先级、公平调度、资源预留等多种抽象，满足微服务、大数据、AI等多种业务场景的调度需求。Volcano SLO Agent：每个节点上部署的SLO Agent实时监控节点的资源使用情况，动态计算可超卖的资源，并将这些资源分配给离线作业。同时，SLO Agent会检测节点的CPU/内存压力，在必要时驱逐离线作业，保障在线业务的优先级。Enhanced OS：为了进一步强化资源隔离，Volcano在内核层面实现了精细化的QoS保障。通过cgroup接口，为在线和离线业务设置不同的资源限制，确保在线业务在高负载时仍能获得足够的资源。 核心能力：资源利用与业务保障的双赢Volcano云原生混部解决方案具备以下关键能力，帮助用户实现资源利用与业务稳定性的双赢：统一调度：支持多种工作负载的统一调度，包括微服务、批处理作业和AI任务。基于QoS的资源模型：为在线和离线业务提供基于服务质量（QoS）的资源管理，确保高优先级业务的稳定性。动态资源超卖：根据节点的实时CPU/内存利用率，动态计算可超卖的资源，最大化资源利用率。CPU Burst：允许容器临时超出CPU限制，避免在关键时刻被限流，提升业务响应速度。网络带宽隔离：支持整机网络出口带宽限制，保障在线业务的网络使用需求。关于Volcano云原生混部的详细设计和使用文档，请参考: Cloud Native Colocation | Volcano[9]。由衷感谢社区开发者: @william-wang 对该特性的贡献！ ▍负载感知重调度：智能均衡集群资源，告别资源热点在Kubernetes集群中，随着工作负载的动态变化，节点资源利用率不均衡的问题时常发生，导致部分节点过热，影响整体集群的稳定性与效率。为了解决这一问题，Volcano v1.11 引入了负载感知重调度功能，基于节点的真实负载动态调整Pod分布，确保集群资源的均衡利用，避免资源热点，提升集群的整体性能与可靠性。负载感知重调度通过子项目 cid:link_8 孵化。 核心能力：真实负载感知调度：通过监控节点的CPU、内存等真实负载指标，动态调整Pod分布，避免仅依赖Pod Request的粗糙调度。定时与动态触发：支持按CronTab定时任务或固定时间间隔触发重调度，灵活适应不同场景需求。适用场景：节点资源不均衡：当集群中部分节点资源利用率过高，而其他节点资源闲置时，负载感知重调度可自动平衡节点负载。热点节点治理：当节点因高负载出现性能瓶颈或故障风险时，重调度可及时迁移Pod，保障业务稳定性。技术亮点：基于真实负载的重调度：相比传统的基于Pod Request的调度策略，Volcano的负载感知重调度更加精准，能够真实反映节点的资源使用情况。无缝集成Kubernetes生态：与Kubernetes原生调度器兼容，无需额外配置即可实现负载感知重调度。灵活的策略配置：用户可根据业务需求，自定义重调度的时间间隔或触发条件，确保调度的灵活性与可控性。关于负载感知重调度的使用说明，请参考: Load-aware Descheduling | Volcano[10]由衷感谢社区开发者: @Monokaix 对该特性的贡献！ ▍细粒度的作业故障恢复策略：高效应对任务中断，提升训练效率在AI、大数据和高性能计算（HPC）场景中，作业的稳定性和故障恢复能力至关重要。传统的作业故障恢复策略通常会在某个Pod失败时重启整个Job，这不仅浪费资源，还可能导致训练任务从头开始，严重影响效率。随着AI场景中断点续训和Checkpoint 技术的普及，单个Pod的失败不再需要重启整个Job。为此，Volcano v1.11 引入了细粒度的作业故障恢复策略，支持更灵活的故障处理机制，帮助用户高效应对任务中断，显著提升训练效率。 核心能力：支持Pod粒度的重启策略用户可以根据需求，设置仅重启失败的Pod或所属的Task，避免不必要的Job重启，减少资源浪费。重启单个Pod：当某个Pod失败时，仅重启该Pod，不影响其他正常运行的任务。policies: - event: PodFailed action: RestartPod重启整个Task：当某个Pod失败时，重启该Pod所属的Task（一组Pod），适用于需要保持任务组一致性的场景。policies: - event: PodFailed action: RestartTask 支持为 Action 设置超时时间Pod失败可能是由临时性故障（如网络抖动或硬件问题）引起的，Volcano允许用户为故障恢复动作设置超时时间。如果在超时时间内Pod恢复正常，则不再执行重启操作，避免过度干预。示例配置：若Pod失败后重启，10分钟内仍未恢复，则重启整个Job。policies: - event: PodFailed action: RestartPod - event: PodEvicted action: RestartJob timeout: 10m 新增PodPending事件处理当Pod因资源不足或拓扑约束长期处于Pending状态时，用户可以为Pending事件设置超时时间。若超时后Pod仍未运行，则可以选择终止整个Job，避免资源浪费。示例配置：若Pod处于Pending状态超过10分钟，则终止Job。policies: - event: PodPending action: TerminateJob timeout: 10m 适用场景：AI大模型训练：在分布式训练中，单个Pod的失败不会影响整体训练进度，通过细粒度的故障恢复策略，可以快速恢复任务，避免从头开始训练。大数据处理：在批处理任务中，部分任务的失败可以通过重启单个Pod或Task解决，无需重启整个作业，提升处理效率。高性能计算：在HPC场景中，任务的稳定性和高效恢复至关重要，细粒度的故障恢复策略可以最大限度地减少任务中断时间。 技术亮点：灵活的策略配置：用户可以根据业务需求，自定义故障恢复策略，支持Pod、Task和Job级别的重启操作。超时机制：通过设置超时时间，避免因临时性故障导致的过度重启行为，提升作业的稳定性。无缝兼容断点续训：与AI场景中的断点续训和Checkpoint技术完美结合，确保训练任务的高效恢复。关于Volcano Job的详细设计和说明文档，请参考: How to use job policy[11]。由衷感谢社区开发者: @bibibox 对该特性的贡献！ ▍Volcano Dashboard：资源管理的可视化利器Volcano dashboard是Volcano官方提供的资源展示仪表盘，用户在部署Volcano后，再部署Volcano dashboard，就可以通过图形界面展示集群中Volcano相关的资源，方便用户查询和操作，项目地址: https://github.com/volcano-sh/dashboard。目前支持的功能有：支持查看集群总览，包括Job数量、状态、完成率，Queue数量，Queue的资源利用率等。支持查看Job列表和详情，支持模糊搜索匹配，支持按照Namespace、Queue、Status等条件过滤，支持Job排序展示。支持查看Queue列表和详情，支持模糊搜索匹配，支持按照Status等条件过滤，支持Queue排序展示。支持查看Pod的列表和详情，支持模糊搜索匹配，支持按照Namespace、Status等条件过滤，支持Pod排序展示。由衷感谢社区开发者: @WY-Dev0, @Monokaix 对该特性的贡献！ ▍Volcano支持Kubernetes v1.31Volcano版本紧跟Kubernetes社区版本节奏，对Kubernetes的每个大版本都进行支持，目前最新支持的版本为v1.31，并运行了完整的UT、E2E用例，保证功能和可靠性。如果您想参与Volcano适配Kubernetes新版本的开发工作，请参考：adapt-k8s-todo[12]进行社区贡献。由衷感谢社区开发者: @vie-serendipity, @dongjiang1989 对该特性的贡献！ ▍Volcano Job支持Preemption PolicyPriorityClass可以表示Pod的优先级，包含一个优先级数值和抢占策略，在调度和抢占的过程中，PriorityClass会被用来作为调度和抢占的依据，高优先级的Pod先于低优先级Pod调度，并且可以抢占低优先级的Pod，Volcano在Pod层面完整支持优先级调度和抢占策略，在Volcano Job层面支持基于priorityClass value的优先级调度和抢占。但在某些场景下，用户希望Volcano Job不通过抢占触发资源回收，而是等待集群资源自动释放，从而整体保障业务稳定性，Volcano在新版本支持了Job级别的PreemptionPolicy，配置了PreemptionPolicy为Never的Volcano Job不会抢占其他Pod。Volcano Job和Job内的task同时支持配置PriorityClass，关于两个PriorityClass的配合关系以及配置样例请参考: how to configure priorityclass for job[13]。由衷感谢社区开发者: @JesseStutler 对该特性的贡献！ ▍性能优化：大规模场景下的高效调度在Volcano中，Queue是最基本且最重要的资源之一。Queue的 status 字段记录了其中状态为 Unknown、Pending、Running、Inqueue、Completed的PodGroup。然而，在大规模场景下，当队列中的PodGroup频繁发生变化时（例如，队列中循环提交大量运行时间较短的任务），会导致大量PodGroup状态从 Running 变为 Completed。这种情况下，Volcano Controller需要频繁刷新Queue的 status 字段，给APIServer带来较大压力。此外，Volcano Scheduler在Job调度完成后会更新Queue的 status.allocated 字段，这在大规模场景下可能导致Queue更新冲突，进一步影响系统性能。为了彻底解决大规模场景下Queue频繁刷新和更新冲突的问题，Volcano v1.11 对Queue的管理机制进行了优化，将Queue中PodGroup的统计数据迁移到指标（Metrics）中，不再进行持久化存储。这一优化显著降低了APIServer的压力，同时提升了系统的整体性能和稳定性。 优化后的核心改进PodGroup统计数据迁移到指标Queue中的PodGroup状态数据（如Unknown、Pending、Running等）不再存储在Queue的 status 字段中，而是通过指标系统进行记录和展示。用户可以通过以下命令查看Queue中PodGroup的统计数据：查看指定队列的统计数据：vcctl queue get -n [name]查看所有队列的统计数据：vcctl queue list减少APIServer压力通过将PodGroup统计数据迁移到指标中，避免了频繁更新Queue的status字段，显著降低了APIServer的负载，提升系统吞吐。解决Queue更新冲突在大规模场景下，Queue的更新冲突问题得到了有效缓解，确保了调度器的高效运行。关于Queue中PodGroup的状态统计数据迁移到指标的详细设计以及指标名称，请参考: Queue podgroup statistics[14]。由衷感谢社区开发者: @JesseStutler 对该特性的贡献！ 总结：Volcano v1.11，云原生批量计算的新标杆 Volcano v1.11不仅是技术的飞跃，更是云原生批量计算领域的全新标杆。无论是AI大模型训练、大数据调度，还是资源利用率的提升，Volcano v1.11都提供了强大的功能和灵活的解决方案。我们相信，Volcano v1.11将帮助用户在云原生批量计算领域走得更远、更稳，开启AI与大数据的云原生调度新纪元！立即体验Volcano v1.11.0，开启高效计算新时代！v1.11.0 release: cid:link_5 致谢贡献者Volcano v1.11.0 版本包含了来自39位社区贡献者的上百次代码提交，在此对各位贡献者表示由衷的感谢，贡献者GitHub ID：@QingyaFan@JesseStutler@bogo-y@bibibox@zedongh@archlitchi@dongjiang1989@william-wang@fengruotj@SataQiu@lowang-bh@Rui-Gan@xovoxy@wangyang0616@PigNatovsky@Yanping-io@lishangyuzi@hwdef@bood@kerthcet@WY-Dev0@raravena80@SherlockShemol@zhifanggao@conghuhu@MondayCha@vie-serendipity@Prepmachine4@Monokaix@lengrongfu@jasondrogba@sceneryback@TymonLee@liuyuanchun11@Vacant2333@matbme@lekaf974@kursataktas@lut777 参考资料[1] Volcano v1.11.0 release: cid:link_5[2] Network Topology Aware Scheduling: https://volcano.sh/en/docs/network_topology_aware_scheduling/[3] Network Topology Aware Scheduling | Volcano: https://volcano.sh/en/docs/network_topology_aware_scheduling/[4] hierarchical-queue-on-capacity-plugin: cid:link_1[5] Hierarchica Queue | Volcano: https://volcano.sh/zh/docs/hierarchical_queue/[6] Karmada: https://karmada.io/[7] Volcano Global: cid:link_9-globa[8] Multi-Cluster AI Job Scheduling | Volcano: https://volcano.sh/en/docs/multi_cluster_scheduling/[9] Cloud Native Colocation | Volcano: https://volcano.sh/en/docs/colocation/[10] Load-aware Descheduling | Volcano: https://volcano.sh/en/docs/descheduler/[11] How to use job policy: cid:link_2[12] adapt-k8s-todo: cid:link_4[13] how to configure priorityclass for job: cid:link_0[14] Queue podgroup statistics: cid:link_3  【更多Volcano干货推荐】Volcano云原生批量计算公开课Volcano云原生批量计算公开课Volcano云原生批量计算公开课由CNCF首个批量计算社区Volcano核心贡献者开发，通过理论学习+实践操作，帮助学习者由浅入深了解批量计算原理和生产场景应用，晋升批量计算达人！点击免费学习Volcano云原生批量计算公开课社区介绍：Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene、Ray 等众多主流计算框架的支持，并构建起完善的上下游生态。Volcano官网：https://volcano.shGitHub: cid:link_9每周例会：https://zoom.us/j/91804791393扫码添加社区小助手回复Volcano进交流群