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

作者：王彬丞&杨志佳&刘家伟针对新版本 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

1.Manus是什么？Manus的官网地址：cid:link_0Manus是一个通用AI智能体，它连接思维与行动：它不仅思考，还能交付成果。2. Manus能做什么？最近几天，Manus都刷屏了，但是Manus到底能做什么事呢？筛选简历、研究房产、分析股票等等一系列复杂任务都可以由Manus完成官网演示视频中的第一个Demo是简历筛选，视频是YouTube源，需要点科学上网的能力才能看。演示开始，官方给Manus发送一个包含10份简历的压缩包，并给它指令：我需要招聘算法工程师，评估这10份简历。Manus随后就和专业招聘人员一样，解压文件，逐个分析简历，评估排名等等操作该任务都是在Manus后台完成，提问者可以提交任务后，随时关闭电脑，等任务完成后，Manus会发送通知3. Manus为什么这么火？Manus的独特在于它不仅能理解用户需求，还能主动采取行动完成具体的任务，也就是知行合一，有条不紊地完成各项任务，并直接交付完整成果目前Manus仍然处于内测阶段，想要试用Manus需要邀请码，而官方未大规模放出邀请码，导致在某鱼上邀请码卖出了999元到100万元的天价4.如何申请Manus第一步：注册登录打开官方网站：cid:link_0打开右上角的Get Started按钮第二步：激活账户登录因为还没邀请码，我们点击Apply For Access进入申请页面第三步：申请快速通过技巧到这一步，需要填写申请邀请码的基本信息，其中Email是你要注册的邮箱号，尽量用gmailHow can Manus help you：主要告诉官方，我们拿到Manus后，怎么使用，需要提供需求细节综合来看，官方需要评估我们的身份，尽可能给需要的人群使用。这里给大家提供申请模板的范文，提高申请通过的概率尊敬的Manus团队， 我是[您的姓名]，目前担任[公司/机构名称]的[职位，如XR技术负责人/智能硬件开发工程师]，同时也是[相关领域社区/开源项目名称]的核心贡献者，在关注到anus的创新方向后，我坚信这项技术将重新定义[具体领域，如人机交互/元字宙入口/康复医疗等]，迫切希望以开发者身份参与内测并提供深度反馈。我的相关经验可能对贵司有价值: 1.技术背景:拥有[X]年[AR/VR/智能硬件开发]经验，主导开发过[简述项目名称与成果，如「基于柔性传感器的可穿戴手势识别系统」或「某品牌VR手套SDK优化」]，对[传感器数据融合/低延迟交互/生物力学分析]等技术难点有实战经验。 场景洞察:目前正在推进[具体项目或研究方向，如「工业场景下的远程协作XR解决方案」或「神经康2复中的手势追踪应用」1，Manus的[某项具体技术特性]恰好能解决我们当前遇到的[具体问题或瓶颈]。 传播能力:我在[技术社区平台/社交媒体名称]拥有[X]万关注者，曾为[某知名硬件产品]撰写过传播量3.超[X]的测评报告，愿在内测期间通过图文/视频形式记录体验过程。我希望在测试中重点关注: ·硬件在[高精度手势识别/长时间佩戴舒适性/多环境适应性]等维度的表现·SDK与[Unity/Unreal/自研引擎]的兼容性及API设计合理性·为贵方提供[中英双语测试报告/竞品对比分析/开发者社区答疑]等额外支持附件中附上我的[个人技术博客链接/Github主页/代表性项日案例]，如需进一步沟通，可随时通过[电话/邮箱]联系。期待能与Manus共同推动行业边界! 顺颂商祺， [您的全名] [联系方式] [个人网站/领英主页] 另外考虑到官方发布会的喜爱，建议优先使用英文的申请Dear Manus Team, I am [Your Name], currently serving as [Your Position, e.g., XR Technology Lead/Smart Hardware Development Engineer] at [Company/Institution Name], and I am also a core contributor to [Relevant Community/Open-Source Project Name]. After learning about Manus's innovative direction, I am convinced that this technology will redefine [Specific Field, e.g., Human-Computer Interaction/Metaverse Access/Rehabilitation Medicine, etc.]. I am eager to participate in the beta testing as a developer and provide in-depth feedback. My relevant experience may be valuable to your team: 1. **Technical Background**: With [X] years of experience in [AR/VR/Smart Hardware Development], I have led the development of [Brief Project Name and Achievements, e.g., "Wearable Gesture Recognition System Based on Flexible Sensors" or "SDK Optimization for a Brand's VR Gloves"]. I have hands-on experience tackling technical challenges such as [Sensor Data Fusion/Low-Latency Interaction/Biomechanical Analysis]. 2. **Scenario Insights**: I am currently advancing [Specific Project or Research Direction, e.g., "XR Remote Collaboration Solution for Industrial Scenarios" or "Gesture Tracking Applications in Neurorehabilitation"]. Manus's [Specific Technical Feature] could precisely address the [Specific Problem or Bottleneck] we are facing. 3. **Communication Capabilities**: I have [X] thousand followers on [Technical Community Platform/Social Media Name] and have authored a review report for [A Well-Known Hardware Product] with over [X] views. I am willing to document my testing experience through articles/videos during the beta period. I hope to focus on the following during the testing: - Hardware performance in areas such as [High-Precision Gesture Recognition/Long-Term Wear Comfort/Multi-Environment Adaptability]. - SDK compatibility with [Unity/Unreal/Proprietary Engine] and the rationality of API design. - Providing additional support such as [Bilingual Test Reports (Chinese/English)/Competitive Analysis/Developer Community Q&A]. Attached are my [Personal Tech Blog Link/Github Profile/Representative Project Cases]. If further discussion is needed, feel free to contact me via [Phone/Email]. I look forward to working with Manus to push the boundaries of the industry! Best regards, [Your Full Name] [Contact Information] [Personal Website/LinkedIn Profile] 账号申请完，就能登录开启Manus之旅了

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进交流群

Karmada 社区非常高兴地宣布正式成立 Karmada Adopter Group（中文名称：Karmada 用户组）。这一举措旨在创建一个充满活力的平台，让用户能够互相连接、合作及高效的信息分享。通过营造共享经验和相互支持的环境，Karmada Adopter Group 将成为用户与 Karmada 社区之间的关键纽带。 作为开放的多云多集群容器编排引擎，Karmada 社区（https://karmada.io/）自2021年开源以来迅速发展，并于2023年12月成为 CNCF 孵化级项目，贡献者遍布全球20+国家和地区。Karmada现已成功部署于数十家大型企业的生产环境中，被广泛应用于公司级关键技术底座，全面管理企业的通用及异构算力资源。 Karmada 不仅获得了大量用户的积极支持，还通过用户的宝贵反馈不断优化和完善。这些支持包括但不限于详细的使用反馈、问题修复以及丰富的实战经验分享，极大地促进了项目的成熟与稳定。社区成员之间的紧密合作，使得Karmada能够快速响应并解决实际应用中的挑战，持续提升用户体验。为了进一步促进用户的交流和合作，Karmada用户现在可以通过加入用户组，连接全球开发者，共同探讨和构建多集群技术。这不仅促进了技术交流和最佳实践分享，也为用户的持续创新和发展提供了坚实的基础。无论是新手还是资深用户，都能在这里找到所需的知识和帮助，共同推动Karmada及其生态系统的繁荣发展。 Karmada 用户组介绍 Karmada Adopter Group 拥有一个专属的 Google 邮件组以及 GitHub Org 组，用于重要公告、更新和信息共享，其主要目标与功能包括：分享知识：促进 Karmada 用户之间经验、挑战和解决方案的交流促进协作：提供一个用户可以共同工作、分享想法并解决共同问题的平台支持用户：提供资源、教程和指导，帮助用户有效利用 Karmada收集反馈：倾听用户声音，以指导 Karmada 未来的发展方向社区活动组织：通过定期 meetup、网络研讨会和其他活动，增强社区参与度 加入用户组，您可以解锁的权益 加入Karmada Adopter Group，您可以与面临类似挑战的同行建立联系并分享Karmada实践经验，一同探索多云多集群生态，包括但不限于以下内容：社区技术支持：包括且不限于方案评估、日常运维、问题定位、版本升级等社区支持公司知名度提升：您的公司和团队将获得全球范围内更多的曝光机会技术影响力构建：邀请共建技术演讲，包括KubeCon等海内外业界大会，Karmada社区伙伴举办的线上、线下系列会议保持信息同步：及时接收重要信息更新，包括新版本的关键特性、重要Bug修复、安全风险等内容，确保您的项目能够第一时间受益于新的改进和增强。顶尖人才招募：利用社区渠道招聘宣传，全球范围内精准招募优秀人才拓展商业机会：与 Karmada 生态系统其他成员建立潜在的商业联系和合作 如何加入用户组 任何在生产环境中使用Karmada的公司，其开发者均可申请加入Karmada Adopter Group。无论您是最终用户还是供应商，我们都欢迎您的参与。最终用户：指在其内部IT基础设施中直接部署和使用Karmada进行多云或多集群管理的企业或组织。这些公司利用Karmada作为关键技术底座来管理和优化其全部算力资源。供应商：指那些将Karmada集成到他们的产品或服务中，以提供给其他企业或组织使用的公司。当前，加入Karmada Adopter Group对社区贡献没有硬性要求，我们鼓励成员积极参与社区活动，分享经验与见解。然而，请注意，未来可能会要求成员对Karmama社区做出一定的贡献，以维持其用户组成员身份。这种贡献可以包括但不限于代码提交、文档编写、问题修复、使用案例分享等。访问下方Karmada用户组申请表单，提交issue申请，即可接收申请进度。手机端可扫描下方二维码快捷填写申请表单。 扫码申请加入用户组用户组申请链接：[1] Karmada Adopter Group 申请加入表单地址：cid:link_0[2] 更多Karmada Adopter Group 详细信息，请查阅：cid:link_2 Karmada Adopter Group 欢迎您的加入！期待与您共同创建一个友好而活跃的空间，共享知识、最佳实践和经验，为企业与社区发展缔造更多可能。如需了解更多关于Karmada Adopter Group的信息，请联系:Hongcai Ren (@RainbowMango) qdurenhongcai@gmail.comMaintainer Mailing Listcncf-karmada-maintainers@lists.cncf.io  添加社区小助手进入Karmada交流群 👉Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：cid:link_3Slack地址：https://slack.cncf.io/（#karmada）

由Linux Foundation组织的LFX Mentorship计划，从19年开始为CNCF各个开源社区中的开发人员持续提供带薪实习和指导。往年已获16w+申请，发起1200+课题，毕业近1000实习生，发放超过300万美金报酬。 2025年春季申请时间  2月18日截止 ，远程实习将从 3 月 3 日开始为期三个月。参与到LFX Mentorship计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为 $3000美金，约合￥20000人民币）。   Karmada社区在LFX Mentorship计划的课题申请正在火热进行中，感兴趣的开发者请于截止日期前在官方入口申请 cid:link_5 Karmada社区介绍Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。Karmada社区贡献者遍布全球20+国家和地区，现已成功部署于数十家大型企业的生产环境中，被广泛应用于公司级关键技术底座，全面管理企业的通用及异构算力资源。在LFX Mentorship 2025春季计划，Karmada期待与你协作开拓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中期考核April 15首次津贴支付April 16结项考核、实习生报告提交 May 27最终薪酬支付批准 May 28活动结束 May 30申请者需要在2月18日前完成Mentee注册和项目申请，流程详见 [3]：cid:link_4实习申请结果预计将在 2 月 26 日通知到申请人。主线开发日期为2025年3月3日-5月27日，全程线上协作，无需线下参与。结项需要在2025年5月27日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。 Karmada社区课题  今年，我们向各位申请者推荐CNCF Karmada 社区下列课题：   ▍Karmada Self-Signed Certificate Content Standardization课题描述：在现有的 Karmada 架构中，每个组件都应该有自己独特的证书，以确保明确的身份和安全性。最佳实践要求每个组件的名称在其证书中用作通用名称（CN），以便于身份区分。然而，目前，所有的 Karmada 组件共享相同的证书内容，这导致了混乱和潜在的安全风险。这个项目的目标是通过确保每个组件拥有反映其身份的不同证书来提高 Karmada 证书系统的合规性。这将提高系统安全性，降低管理复杂性，并与行业标准保持一致。这个项目旨在实现以下标准：- 为整个 Karmada 系统使用单个 CA 证书。- 为每个服务器组件颁发单独的服务器证书，使用组件名称作为 CN。- 为每个客户端组件颁发单独的客户端证书，使用组件名称作为 CN，同一客户端可以为不同的服务器使用一致的证书。 预期结果：- 为 8 个服务器组件完成不同证书的颁发，并将证书内容导入到相应的证书 Secrets 中。- 为 11 个客户端组件完成不同证书的颁发，并将证书内容导入到相应的证书 Secrets 或 Config Secrets 中。 前置技能：Go，Kubernetes，Karmada 课题导师：Chaosi Pan（@chaosi-zju ）chaosi@zju.edu.cnZhen Chang （@XiShanYongYe-Chang ）changzhen5@huawei.com 课题链接：cid:link_1▍Implement multi-cluster management in the Karmada dashboard课题描述：Karmada dashboard 已经实现了控制平面中资源的管理。除此之外，我们希望实现成员集群中资源的管理：一旦用户在控制平面上添加 Kubernetes 资源和相应的策略资源，他们就可以无缝切换到相应的成员集群，检查特定成员集群中 Kubernetes 资源的状态。Kubernetes dashboard 是最受欢迎的单集群管理工具之一，它使用 client-go sdk 与 apiserver 通信以管理集群中的资源。由于 karmada-aggregated-apiserver 组件以及 Kubernetes 资源和 Karmada 资源之间的兼容性设计，大量与 client-go 相关的逻辑可以很容易地扩展到多集群。因此，我们希望将 Kubernetes dashboard 与 karmada-aggregated-apiserver 组件结合起来，在 Karmada dashboard 中实现多集群管理。 预期结果：- 根据 karmada-aggregated-apiserver 提出多集群管理方案。- 将具有特定版本的 Kubernetes dashboard 同步到 Karmada dashboard 仓库，并基于 karmada-aggregated-apiserver 在成员集群中实施资源管理。- 成员集群管理的典型用户界面：- 为 deployment 资源增加 list/detail/delete/update 操作。- pod 资源的日志查看器。- pod 资源的网络终端，用户可以附加正在运行的 pod，并执行临时命令。 前置技能：Kubernetes, Go, gin, react, webgl 课题导师：Wenjiang Ding（@warjiang ）1096409085@qq.comZhen Chang （@XiShanYongYe-Chang ）changzhen5@huawei.com 课题链接：cid:link_2 如果对课题实习有任何问题，欢迎向课题导师发送邮件或在GitHub仓库提交Issue提问。 扫码回复“Karmada” 进入技术群  今年春季，Karmada社区期待在 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_4   👉Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：cid:link_6Slack地址：https://slack.cncf.io/（#karmada）

北京时间2025年1月21日，KubeEdge 发布1.20.0版本。新版本针对大规模、离线等边缘场景对边缘节点和应用的管理、运维等能力进行了增强，同时新增了多语言 Mapper-Framework 的支持。   KubeEdge v1.20.0 新增特性：支持批量节点操作 多语言 Mapper-Framework 支持 边缘 keadm ctl 新增 pods logs/exec/describe 和 Devices get/edit/describe 能力解耦边缘应用与节点组，支持使用 Node LabelSelector边云通道支持 IPv6升级 k8s 依赖到1.30   新特性概览   ▍支持批量节点操作在之前的版本中，keadm 工具仅支持单个节点的安装与管理，然而在边缘场景中，节点数量通常比较庞大，单个节点的管理难以满足大规模场景的需求。在1.20.0版本中，我们提供了批量节点操作和运维的能力。基于这个能力，用户仅需要使用一个配置文件，即可通过一个控制节点（控制节点可以登录所有边缘节点）对所有边缘节点进行批量操作和维护。keadm 当前版本支持的批量能力包括 join, reset 和 upgrade。# 配置文件配置要求参考如下 keadm: download: enable: true # <Optional> Whether to download the keadm package, which can be left unconfigured, default is true. if it is false, the 'offlinePackageDir' will be used. url: "" # <Optional> The download address of the keadm package, which can be left unconfigured. If this parameter is not configured, the official github repository will be used by default. keadmVersion: "" # <Required> The version of keadm to be installed. for example: v1.19.0 archGroup: # <Required> This parameter can configure one or more of amd64/arm64/arm. - amd64 offlinePackageDir: "" # <Optional> The path of the offline package. When download.enable is true, this parameter can be left unconfigured. cmdTplArgs: # <Optional> This parameter is the execution command template, which can be optionally configured and used in conjunction with nodes[x].keadmCmd. cmd: "" # This is an example parameter, which can be used in conjunction with nodes[x].keadmCmd. token: "" # This is an example parameter, which can be used in conjunction with nodes[x].keadmCmd. nodes: - nodeName: edge-node # <Required> Unique name, used to identify the node arch: amd64 # <Required> The architecture of the node, which can be configured as amd64/arm64/arm keadmCmd: "" # <Required> The command to be executed on the node, can used in conjunction with keadm.cmdTplArgs. for example: "{{.cmd}} --edgenode-name=containerd-node1 --token={{.token}}" copyFrom: "" # <Optional> The path of the file to be copied from the local machine to the node, which can be left unconfigured. ssh: ip: "" # <Required> The IP address of the node. username: root # <Required> The username of the node, need administrator permissions. port: 22 # <Optional> The port number of the node, the default is 22. auth: # Log in to the node with a private key or password, only one of them can be configured. type: password # <Required> The value can be configured as 'password' or 'privateKey'. passwordAuth: # It can be configured as 'passwordAuth' or 'privateKeyAuth'. password: "" # <Required> The key can be configured as 'password' or 'privateKeyPath'. maxRunNum: 5 # <Optional> The maximum number of concurrent executions, which can be left unconfigured. The default is 5.` # 配置文件参考用例 (各字段具体值请根据实际环境进行配置) keadm: download: enable: true url: cid:link_11/releases/download/v1.20.0 # If this parameter is not configured, the official github repository will be used by default keadmVersion: v1.20.0 archGroup: # This parameter can configure one or more of amd64\arm64\arm - amd64 offlinePackageDir: /tmp/kubeedge/keadm/package/amd64 # When download.enable is true, this parameter can be left unconfigured cmdTplArgs: # This parameter is the execution command template, which can be optionally configured and used in conjunction with nodes[x].keadmCmd cmd: join--cgroupdriver=cgroupfs--cloudcore-ipport=192.168.1.102:10000--hub-protocol=websocket--certport=10002--image-repository=docker.m.daocloud.io/kubeedge--kubeedge-version=v1.20.0--remote-runtime-endpoint=unix:///run/containerd/containerd.sock token: xxx nodes: - nodeName: ubuntu1 # Unique name arch: amd64 keadmCmd: '{{.cmd}} --edgenode-name=containerd-node1 --token={{.token}}' # Used in conjunction with keadm.cmdTplArgs copyFrom: /root/test-keadm-batchjoin # The file directory that needs to be remotely accessed to the joining node ssh: ip: 192.168.1.103 username: root auth: type: privateKey # Log in to the node using a private key privateKeyAuth: privateKeyPath: /root/ssh/id_rsa - nodeName: ubuntu2 arch: amd64 keadmCmd: join--edgenode-name=containerd-node2--cgroupdriver=cgroupfs--cloudcore-ipport=192.168.1.102:10000--hub-protocol=websocket--certport=10002--image-repository=docker.m.daocloud.io/kubeedge--kubeedge-version=v1.20.0--remote-runtime-endpoint=unix:///run/containerd/containerd.sock # Used alone copyFrom: /root/test-keadm-batchjoin ssh: ip:192.168.1.104 username: root auth: type: password passwordAuth: password: ***** maxRunNum: 5 # 用法 (保存以上文件，例如保存为 config.yaml) # 在控制节点下载最新版本 keadm, 执行以下命令进行使用 keadmbatch-c config.yaml更多信息可参考：cid:link_3cid:link_4cid:link_10 ▍多语言 Mapper-Framework 支持由于边缘 IoT 设备通信协议的多样性，用户可能需要使用 Mapper-Framework 生成自定义 Mapper 插件来纳管边缘设备。当前 Mapper-Framework 只能生成 go 语言版本的 Mapper 工程，对于部分不熟悉 go 语言的开发者来说使用门槛仍然较高。因此在新版本中，KubeEdge 提供了 Java 版本的 Mapper-Framework，用户可以访问 KubeEdge 主仓库的feature-multilingual-mapper分支，利用 Mapper-Framework 生成 Java 版的自定义 Mapper 工程。更多信息可参考：cid:link_11/pull/5773cid:link_5 ▍边缘 keadm ctl 新增 pods logs/exec/describe 和 Devices get/edit/describe 能力在v1.17.0版本中，我们新增了 keadm ctl 子命令，支持在离线场景下对边缘 pod 进行查询和重启。在v1.20中我们对该命令做了进一步增强，支持 pod 的logs/exec/describe等功能，用户在边缘可对 pod 进行日志查询、pod 资源详细信息查询、进入容器内部等操作。同时还新增了对 device 的操作，支持 device 的get/edit/describe的功能，可以在边缘获取 device 列表、device 的详细信息查询、在边缘离线场景下对 device 进行编辑操作。如下所示，新增的 keadm ctl 子命令功能均在 MetaServer 中开放了 Restful 接口，并与 K8s ApiServer 对应的接口完全兼容。[root@edgenode1 ~] # keadm ctl -h Commands operating on the data plane at edge Usage: keadm ctl [command] Available Commands: ... describe Show details of a specific resource edit Edit a specific resource exec Execute command in edge pod get Get resources in edge node logs Get pod logs in edge node ...更多信息可参考：cid:link_6cid:link_7 ▍解耦边缘应用与节点组，支持使用 Node LabelSelectorEdgeApplication 可以通过节点组覆盖部署定义（如副本、镜像、命令和环境），Pod 流量在节点组内闭环（EdgeApplication 管理的 Deployment 共用一个 Service）。但在实际场景中，需要批量操作的节点范围与需要相互协作的节点范围并不相同。例如在智慧园区的场景中，每个城市都有很多个智慧园区，我们需要应用的流量在一个智慧园区内闭环，但应用批量管理的范围可能是城市级，也可能是省级。我们在EdgeApplication CRD中为节点标签选择器添加了一个新的targetNodeLabels字段，该字段将允许应用程序根据节点标签进行部署，并且覆盖特定的字段，YAML 定义如下：apiVersion: apps.kubeedge.io/v1alpha1 kind: EdgeApplication metadata: name: edge-app namespace: default spec: workloadTemplate: {...} workloadScope: # New field: targetNodeLabels targetNodeLabels: - labelselector: - matchExpressions: - key: "region" operator: In values: - "HangZhou" overriders: {...}更多信息可参考：Issue: cid:link_2Pull Request: cid:link_8 ▍边云通道支持 IPv6我们在官网的文档中提供了一份配置指南，介绍了 KubeEdge 如何在 Kubernetes 集群中让云边 hub 隧道支持 IPv6。文档地址：https://kubeedge.io/docs/advanced/support_ipv6 ▍升级 K8s 依赖到 v1.30 新版本将依赖的 Kubernetes 版本升级到v1.30.7，您可以在云和边缘使用新版本的特性。更多信息可参考：cid:link_9  本升级注意事项  从v1.20开始，EdgeCore的配置项edged.rootDirectory的默认值将会由/var/lib/edged切换至/var/lib/kubelet。如果您需要继续使用原有路径，可以在使用 keadm 安装 EdgeCore 时设置--set edged.rootDirectory=/var/lib/edged。 ▍致谢感谢 KubeEdge 社区技术指导委员会 (TSC)、各 SIG 成员对v1.20版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！ ▍相关链接Release Notes：cid:link_1  扫码回复“KubeEdge” 进入技术群    【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。 课程免费学习链接：cid:link_0 KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。 KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_11Slack地址 : 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/