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/

LFX Mentorship 计划，由 Linux Foundation 组织，从19年开始为 CNCF 各个开源社区中的开发人员持续提供带薪实习和指导。往年已获16w+申请，发起1200+课题，毕业近千名实习生，发放超过300万美金报酬。2025年春季申请时间为 2月5日-2月18日，远程实习将从3月3日开始为期三个月。参与到 LFX Mentorship 计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为$3000美金，约合￥20000人民币）。今年 KubeEdge 社区在 LFX Mentorship 计划中准备了多个课题，感兴趣的读者可于2月18日前点击阅读全文，或到官方平台申请：strongcid:link_14/strong  KubeEdge社区介绍 KubeEdge 社区已经连续5年参与 LFX Mentorship 计划，过去已为学员提供25+个项目。KubeEdge 是业界首个云原生边缘计算框架、云原生计算基金会内部唯一毕业级边缘计算开源项目。在 GitHub 获得 8k+Stars和2.2k+Fork，吸引了全球来自35+国家的100+贡献组织及16万+开发者。近年来，KubeEdge 社区持续开拓创新，完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同 AI 框架 Sedna 及业界首个边云协同终身学习范式、开源业界首个分布式协同 AI 基准测试 Ianvs。在 LFX Mentorship 2025春季计划，KubeEdge 期待再次和计算机领域新生力量一起，开拓数字未来。   面向对象 春季计划申请者需在2025年2月18日前在 LFX 官网完成 Mentee 注册及项目申请。若被接收作为 Mentee，您将能在开源社区经验丰富、积极贡献的 Mentor 指导下为开源项目做出贡献。依据官方规定[1]，对 Mentee 的申请者有以下要求:计划开始时至少年满18周岁所在单位和组织不禁止该实习未参加另外的 Linux Mentorship 计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)并非社区中高于最低限度贡献成员（如Maintainer、Recurring Contributor）满足具体所属项目中提及的其它前置需求   课题参与方式  根据官方安排 [2]，LFX Mentorship 2025年春季活动流程如下：Mentee 注册与项目申请 2月5日-2月18日申请者评审及人事工作 2月19日-2月25日实习启动及任务发放 3月3日中期考核及首次津贴支付 4月16日结项考核、实习生报告提交，最终津贴支付批准 5月28日 活动结束 5月30日申请者需要在2月18日前完成 Mentee 注册和项目申请，流程详见 [3]：cid:link_8实习申请结果预计将在 2 月 26 日通知到申请人。主线开发日期为2025年3月3日 – 5月28日，全程线上协作，无需线下参与。结项需要在2025年5月28日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。   KubeEdge课题    最后，向各位申请者推荐 CNCF KubeEdge 社区下列课题：▍KubeEdge: Enhance KubeEdge testing coverage (2025 Term 1)课题描述：为更好地维护代码质量并减少缺陷的引入，本课题希望将单元测试覆盖率提高到60%到70%（目前单元测试覆盖率为38.69%）。需要注意的是，除了要求 KubeEdge 整体的单元测试覆盖率满足要求外，每个核心代码目录（cloud/、edge/、keadm/和pkg/）的单元测试覆盖率也需要超过60%。预计输出件：UT 覆盖率提升至60%-70%前置技能：KubeEdge, Go, Testing课题导师：Elias Wang (@wbc6080)wangbincheng4@huawei.comFisher Xu (@fisherxu)fisherxu1@gmail.com课题链接：cid:link_2Github Issue：cid:link_9 ▍KubeEdge: KubeEdge Dashboard Enhancement - BFF (2025 Term 1)课题描述：为 KubeEdge Dashboard 设计的 BFF（Backend for Frontend） 中间层，旨在连接前端 UI 层与 KubeEdge 后端 API，作为数据的中转和处理中心，为前端提供一个专门设计的后端服务，简化前端的数据获取逻辑并提升性能与安全性。此外，为了让开发者更快速地体验并部署Dashboard，我们需要与 kubeedge/keink 项目进行深度集成，仅需一条命令即可启动 Dashboard 环境，实现对功能的完整演示和验证。预计输出件：一键运行与持续集成一键部署： 借助 keink 项目，仅需一条命令即可快速拉取并运行 Daily 发布的容器镜像，让开发者或体验者无需额外环境配置。持续发布机制： Daily 镜像能够持续整合最新的功能更新和修复，开发者可以及时获取最新版本，快速验证和测试功能，从而优化研发流程。数据处理: 对从后端获取的数据进行统一的格式化、过滤和处理，以满足前端的展示需求，避免在前端编写重复或复杂的逻辑。错误处理与重试（可选）前置技能：KubeEdge, JavaScript, React课题导师：Chen Su (@ghosind)ghosind@gmail.comElias Wang (@wbc6080)wangbincheng4@huawei.com课题链接：cid:link_3Github Issue：cid:link_10 ▍KubeEdge: Domain-specific large model benchmarks: the edge perspective (2025 Term 1)课题描述：业界通用大模型基准测试往往聚焦于云。随着大模型进入规模化应用时代，云端为大模型提供了基础设施和服务。客户进一步提出了边缘侧的针对性应用需求，包括个性化、数据合规性和实时性，使得不同边侧单位往往构建自有行业大模型或知识库。但目前针对边侧数据开展的大模型基准测试并未成型。由于数据在不同边缘的分布，预计通用大模型在多样边侧行业场景将产生大幅性能波动。本课题旨在为边缘AI服务和应用定位行业大模型性能波动，以便用于匹配特定大模型、定位问题乃至选择适用边侧场景。预计输出件：行业大模型边侧测试数据集、测试套件、使用说明（进阶) 测试指标设计与开发（进阶）测试方法研究，测试调研与研究报告前置技能：KubeEdge-Ianvs, Python, LLMs课题导师：Zimu Zheng (@MooreZheng)zimu.zheng@hotmail.comShijing Hu (@hsj576)sjhu21@m.fudan.edu.cn课题链接：cid:link_4Github Issue：cid:link_12 ▍KubeEdge: Enhance Dependency Management and Documentation for KubeEdge-Ianvs (2025 Term 1)课题描述：Ianvs目前正面临着较为紧迫的依赖管理问题。随着 Python 版本、依赖库以及 Ianvs 特性的持续演进，许多先前的 examples 已无法运行，导致大量相关的 Issue 被提出；现有的项目文档中也存在不少过时内容，这对新用户来说较为困扰。Ianvs 需要对已有 examples 的依赖进行梳理，并构建一套更加完善的依赖管理机制，降低新用户上手Ianvs的门槛。预计输出件：更加完善的 Contributing Guide基于大语言模型云边协同推理示例打造的全新 Quick Start Example其他 Paradigm 依赖修复和文档完善前置技能：KubeEdge, Python课题导师：Yu Fan (@FuryMartin)furymartin9910@outlook.comShijing Hu (@hsj576)sjhu21@m.fudan.edu.cn课题链接：cid:link_5Github Issue：cid:link_13 ▍KubeEdge: Community Website Comprehensive Upgrade Project: Homepage Renewal… (2025 Term 1)课题描述：为提高 KubeEdge 官网的用户体验和访问效率，官网优化项目将聚焦于首页设计优化、新页面的增加以及社区资源的改进。该项目的目标是提升网站的易用性、增加用户粘性，并通过增强培训内容和硬件兼容性支持，吸引更多用户使用 KubeEdge。预计输出件：官网首页的设计与优化，包含设计和代码更新新增页面：课程培训视频的展示，包含设计和代码更新新增页面：”硬件兼容”展示页，包含设计和代码更新partner 页面设计与优化，包含设计和代码更新优化社区资源，改善文档和入门体验，确保用户能够轻松上手并有效使用  KubeEdge。前置技能：KubeEdge, JavaScript, Docusaurus课题导师：Hongbing Zhang (@HongbingZhang)hongbing.zhang@daocloud.ioShelley Bao (@Shelley-BaoYue)baoyue2@huawei.com课题链接：cid:link_6Github Issue：cid:link_11如果对课题内容有任何问题，欢迎在 GitHub 仓库提交 Issue 或者添加社区小助手微信向社区提问。扫码回复“KubeEdge” 进入技术群今年春季，KubeEdge 社区期待在 LFX Mentorship 见到您！ 参考资料：[1] LFX Mentorship - Application Requirement：cid:link_7 [2] LFX Mentorship - Program Readme：cid:link_0[3] LFX Mentorship - Mentee Application Guideline：cid:link_8  【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_1KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。 KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_15Slack地址 : 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/

这个进入容器执行命令 的api目前无法支持websocet，但是官网文档上已经列出来了，请问什么时候能支持这个功能？

2024年12月18日，由中国科学技术协会科学技术传播中心、中国计算机学会、中国通信学会、中国科学院软件研究所联合主办，CSDN 承办的开源创新榜评选活动圆满落幕。KubeEdge 作为业界首个云原生边缘计算项目以及 CNCF 唯一正式毕业的边缘计算开源项目，以其卓越的创新性、贡献度和影响力，从200多个竞争项目中脱颖而出，荣获2024开源创新榜优秀开源项目之首。2024开源创新榜评选活动由王怀民院士担任评委会主任，带领全国各学会、大学、科研院所、企业、开源基金会、行业联盟等近20位开源专家，面向中国开源行业领域，遴选具有创新性、贡献度和影响力的开源项目、社区、应用场景与开源事件，进一步激励更多企业和开发者参与开源生态建设，推动开源技术繁荣和发展。  KubeEdge 于2018年11月正式开源，2019年作为首个云原生边缘项目被接受为 CNCF Sandbox 项目，在2020年9月晋升为孵化项目，并于2024年10月从 CNCF 正式毕业，是第三个由中国企业开源的毕业项目。KubeEdge 项目致力于将 Kubernetes 的容器化应用编排能力无缝扩展至边缘主机，为边缘计算提供强大的基础设施支持。它基于 Kubernetes 构建，不仅覆盖了云端与边缘端之间的网络连接、应用部署和元数据同步，还通过高效的架构设计，显著提升了边缘计算场景中的可靠性与性能。目前，KubeEdge 将云原生生态扩展到了数据中心之外的更多场景和行业，广泛应用于 CDN、智能交通、智慧能源、智慧零售、智慧园区、智能汽车、航空航天、智能物流、金融、化工、电力、区块链等各领域，完成了业界最大规模云原生边云协同高速公路收费站管理项目、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生智慧零售管理、业界首个云原生金融管理等行业代表项目。基于云原生边缘计算领域的独特优势，KubeEdge 得到了伙伴和用户的高度认可。此次荣获“优秀开源项目”奖项，既是对 KubeEdge 技术实力的高度认可，也彰显了社区在合作精神、开放性和追求卓越方面的努力与成就。这一荣誉离不开每一位社区成员的辛勤付出和无私奉献。未来，KubeEdge 社区将保持开放治理模式和协作理念，进一步改善用户体验，提供更可靠和稳定的服务。我们也诚邀更多的开发者和用户加入 KubeEdge 社区，共同探索边缘计算的未来，共创辉煌。   【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : https://github.com/kubeedge/kubeedgeSlack地址 : 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/

12月27日，“The Future of KubeEdge” KubeEdge 毕业主题研讨会在上海成功举办。来自上海开源信息技术协会、华为云、DaoCloud、Intel、南京腾优科技、FatCoupon Technology、中碳普惠云、复旦大学、上海对外经贸大学、上海工程技术大学等多家机构、企业、高校代表及贡献者出席，就 KubeEdge 毕业后的社区规划展开深入研讨，持续聚力技术与运营协同创新，助力云原生边缘计算产业升级发展。  回顾 KubeEdge 的发展历程，从 2018 年 11 月正式开源，2019 年作为首个云原生边缘项目被接受为 CNCF Sandbox 项目， 2020 年 9 月晋升为孵化项目，并于2024年成功毕业，成为CNCF首个毕业级云原生边缘计算项目，一路走来，社区持续开源创新，将云原生生态扩展到了数据中心之外的更多场景和行业，为业内带来了多个行业首发应用，广泛覆盖 CDN、智能交通、智慧能源、智慧零售、智慧园区、汽车、航空航天、智能物流、金融、化工、电力、区块链等领域。 ▲ KubeEdge 项目里程碑 会上，KubeEdge 联合创始人，华为云云原生开源负责人王泽锋介绍了全球云原生开源生态与运作模式，并分享了 KubeEdge 发展历程中的核心技术与典型案例。CNCF 毕业项目是国际开源生态的领军者，KubeEdge 从 CNCF 毕业已迈入了成熟新阶段。基于在云原生边缘计算领域的独特优势，KubeEdge 期待在未来为整个云原生生态系统缔造更广阔的可能性。 ▲ KubeEdge联合创始人，华为云云原生开源负责人王泽锋 KubeEdge TSC，DaoCloud 首席运营官张红兵在会上分享了 KubeEdge 长期以来的社区治理及运营策略。通过系统化建立社区治理架构，严格执行高效的开发者协同机制，开展深度的工程化验证，社区有序促进技术持续创新与升级。与此同时，社区也通过开发者实训、公开课、峰会、研讨会等系列形式，为社区开发者们构建多元化的学习、参与和成长路径，打造社区活跃生态。 ▲ KubeEdge TSC，DaoCloud 首席运营官张红兵 毕业是社区的里程碑，同时也对技术创新和运营发展提出了更高的要求。在小组讨论环节，各位代表集思广益，从企业、高校、开发者各个视角，就社区未来发展深入探讨，涵盖 Scalability、Node、Device-IoT、AI、Netwoking、Security、UI、Cluster-Lifecycle、Testing、EdgeSite、Release、Docs、Robotics 等多个 SIG 的技术创新方向，持续升级社区运营治理，促进 KubeEdge 与产业发展生态融合。 未来，KubeEdge 社区将保持开放治理模式和协作理念，进一步升级用户体验，提供更可靠和稳定的服务。社区成功毕业离不开每一位社区伙伴、用户与开发者的协作与贡献，期待与您携手共建，加速社区生态协同发展，共同引领云原生边缘计算迈向产业应用新高度。

容器的介绍容器化技术，它是一种虚拟化技术，用于在计算机系统中隔离和运行应用程序。容器将应用程序及其所有依赖项打包到一个独立的、可移植的环境中，使其能够在不同的计算机或操作系统上运行。容器的特点：隔离性、轻量级、可移植性、弹性伸缩、生态系统。目前最流行的容器化技术是Docker，它提供了一个开放的平台，用于构建、分发和运行容器。除了Docker，还有其他容器化技术，如Kubernetes、Podman、Containerd等。容器的精髓在于镜像，而docker是容器镜像标准的制定者，因此，学习容器是绕不开docker的。Docker是一个开源的引擎，可以轻松的为任何应用创建一个轻量级的、可移植的、自给自足的容器Docker的技术架构Docker 客户端（Client）： Docker 客户端是用户与 Docker 交互的命令行工具或图形界面工具。用户可以使用 Docker 客户端发送命令和指令，例如构建镜像、创建容器、启动容器等。Docker 客户端与 Docker 主机进行通信，通过 API 接口或者 Docker 配置文件进行交互。常见的 Docker 客户端包括 Docker CLI（命令行界面）和 Docker Dashboard（图形用户界面）。Docker 主机（Docker Host）： Docker 主机是安装和运行 Docker 引擎的物理或虚拟机器。它负责管理容器的创建、启动、停止和销毁等生命周期操作。Docker 主机上运行着 Docker 引擎，它接收来自 Docker 客户端的指令，并执行相应的操作。Docker 主机上可以同时运行多个容器，并提供了资源隔离、网络管理和存储管理等功能。镜像仓库（Registry）： 镜像仓库是用于存储和分发 Docker 镜像的中央仓库。镜像仓库允许用户上传、下载和共享镜像。当用户在 Docker 主机上创建镜像时，可以选择将镜像推送到镜像仓库中，以便其他人可以使用这个镜像。Docker Hub 是官方提供的公共镜像仓库，用户可以从中获取各种常用的镜像。除了 Docker Hub，还有一些私有和第三方的镜像仓库可供选择，例如 Harbor、Azure Container Registry 等。在整个架构中，Docker 客户端与 Docker 主机通过 API 接口进行通信，Docker 主机负责管理容器的运行和资源隔离。镜像仓库则是存储和分享镜像的中央仓库，用户可以从中拉取镜像或将自己创建的镜像推送至其中。这样，Docker 技术架构实现了应用程序的打包、分发和部署，提供了一种便捷、可移植和可扩展的容器化环境。容器的工作机制（Docker）Docker 客户端（Docker Client）：Docker 客户端是用户与 Docker 交互的命令行工具或 GUI 工具。它向 Docker 引擎发送指令，如拉取镜像、创建容器、启动容器等。Docker 引擎（Docker Engine）：Docker 引擎是 Docker 的核心组件，负责管理容器的生命周期，包括创建、启动、停止、删除等操作。它还提供了一组 API 接口和命令行工具，供用户与 Docker 进行交互。容器（Container）：容器是从容器镜像创建的运行实例。它是一个独立的、隔离的执行环境，其中应用程序可以在其中运行。容器具有自己的文件系统、网络和进程空间，但与主机系统是隔离的。Docker 客户端和 Docker 引擎是分离的两个组件，Docker 客户端发送指令给 Docker 引擎，Docker 引擎执行指令并管理容器的生命周期。容器则是从容器镜像创建的运行实例，它具有隔离性、资源管理和网络管理等特性，使得应用程序可以在一个独立且可移植的环境中运行。容器的关键技术 - NamespaceNamespace是Linux内核对系统资源进行隔离和虚拟化的特性，这些系统资源包括：PID ：PID 命名空间提供了进程 ID 的隔离。User：User 命名空间提供了用户和用户组的隔离。UTS：UTS 命名空间提供了主机名和域名的隔离。IPC：IPC 命名空间提供了进程间通信（IPC）资源的隔离，如共享内存、信号量和消息队列等。Net：Net 命名空间提供了网络资源的隔离，包括网络接口、IP 地址、路由表和网络命名空间等。Mnt：Mnt 命名空间提供了文件系统挂载点的隔离。Namespace隔离说明以交互模式启动一个centos容器，并在其中运行/bin/bash程序。执行ps命令查看到“/bin/bash”是PID=1的进程，即docker将其隔离于宿主机中的其他进程[root@localhost ~]# docker run -it centos /bin/bash [root@24b87937f13d /]# ps axf PID TTY STAT TIME COMMAND 1 pts/0 Ss 0:00 /bin/bash 14 pts/0 R+ 0:00 ps axf打开另一个终端，使用docker inspect查看容器进程在宿主机上的真实PID。实际上，该容器上运行的”/bin/bash”在宿主机上是PID=96745的进程[root@localhost ~]# docker inspect 24b87937f13d | grep Pid "Pid": 96745, "PidMode": "", "PidsLimit": 0,容器的关键技术 - CgroupCgroups：Linux Control Group作用：限制一个进程组对系统资源的使用上限，包括CPU、内存、Block I/O等Cgroups还能设置进程优先级，对进程进行挂起和恢复等操作原理：将一组进程放在一个Cgroup中，通过给这个Cgroup分配指定的可用资源，达到控制这一组进程可用资源的目的实现：在Linux中，Cgroups以文件和目录的方式组织在操作系统的/sys/fs/Cgroup路径下。该路径中所有的资源种类均可被Cgroup限制Docker环境搭建操作系统内存处理器硬盘网络Centos 8 Stream4 GB150GBNAT1）安装基础软件包[root@docker ~]# yum install -y vim net-tools bash-completion yum-utils # 或者退出重新登录，为了自动补全 [root@docker ~]# bash 2）下载docker-ce repo文件[root@docker ~]# yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo [root@docker ~]# cd /etc/yum.repos.d/ [root@docker yum.repos.d]# ls CentOS-Stream-AppStream.repo CentOS-Stream-BaseOS.repo CentOS-Stream-Debuginfo.repo CentOS-Stream-Extras-common.repo CentOS-Stream-Extras.repo CentOS-Stream-HighAvailability.repo CentOS-Stream-Media.repo CentOS-Stream-NFV.repo CentOS-Stream-PowerTools.repo CentOS-Stream-RealTime.repo CentOS-Stream-ResilientStorage.repo CentOS-Stream-Sources.repo docker-ce.repo3）安装# 查看docker版本 [root@docker ~]# yum list docker-ce --showduplicates | sort -r # 默认安装最新版 [root@docker ~]# yum install -y docker-ce # 安装指定版本 [root@docker ~]# yum install -y docker-ce-20.10.22 docker-ce-cli-20.10.224）启动# 查看docker版本 [root@docker ~]# docker -v Docker version 24.0.6, build ed223bc #开启docker服务、开机自启、查看状态 [root@docker ~]# systemctl enable docker.service Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /usr/lib/systemd/system/docker.service. [root@docker ~]# systemctl start docker.service [root@docker ~]# systemctl status docker.service ● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; > Active: active (running) since Sun 2023-09-17 17:20:23 CST; 5s ago Docs: https://docs.docker.com Main PID: 12240 (dockerd) Tasks: 7 Memory: 28.4M CGroup: /system.slice/docker.service └─12240 /usr/bin/dockerd -H fd:// --containerd=/run/conta> Sep 17 17:20:22 docker systemd[1]: Starting Docker Application Conta> Sep 17 17:20:22 docker dockerd[12240]: time="2023-09-17T17:20:22.760> Sep 17 17:20:22 docker dockerd[12240]: time="2023-09-17T17:20:22.770> Sep 17 17:20:23 docker dockerd[12240]: time="2023-09-17T17:20:23.159> Sep 17 17:20:23 docker dockerd[12240]: time="2023-09-17T17:20:23.241> Sep 17 17:20:23 docker dockerd[12240]: time="2023-09-17T17:20:23.250> Sep 17 17:20:23 docker dockerd[12240]: time="2023-09-17T17:20:23.250> Sep 17 17:20:23 docker dockerd[12240]: time="2023-09-17T17:20:23.263> Sep 17 17:20:23 docker systemd[1]: Started Docker Application Contai>5）配置镜像加速器以阿里云镜像加速器为例[root@docker ~]# mkdir -p /etc/docker [root@docker ~]# tee /etc/docker/daemon.json <<-'EOF' { "registry-mirrors": ["https://as5wzlk8.mirror.aliyuncs.com"] } EOF { "registry-mirrors": ["https://as5wzlk8.mirror.aliyuncs.com"] } [root@docker ~]# cat /etc/docker/daemon.json { "registry-mirrors": ["https://as5wzlk8.mirror.aliyuncs.com"] } # 重新加载配置文件 [root@docker ~]# systemctl daemon-reload # 重新启动docker服务 [root@docker ~]# systemctl restart docker.service # 标准的完整名称 服务器 仓库/分类 镜像 版本 registry.cn-hangzhou.aliyuncs.com/cloudcs/centos:latest # 版本默认情况下，如果不指定，那么默认为 latestDocker基本操作# 镜像的下载 [root@docker ~]# docker pull mysql # 镜像重命名 [root@docker ~]# docker tag mysql:latest mysql:666 # 镜像的删除 [root@docker ~]# docker rmi mysql:latest # 镜像历史信息 [root@docker ~]# docker history mysql:latest # 镜像保存 [root@docker ~]# docker save mysql alpine > /tmp/all.tar # 镜像导入 [root@docker ~]# docker load -i /tmp/all.tar尝试运行一个容器[root@docker ~]# docker run -tid --name d1 --restart always alpine 44936d56248d3c9657e502168ea91098b2caa69a065a7d712dd4d3048b3f508d # 查看正在运行容器 [root@docker ~]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 44936d56248d alpine "/bin/sh" 26 seconds ago Up 25 seconds d1 # 进入容器 [root@docker ~]# docker exec -ti d1 /bin/sh / # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 8: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0 valid_lft forever preferred_lft forever / # exit感谢您阅读本文。我希望它能给您带来新的思考和启发，并为您的未来带来积极的影响。如果小伙伴们有任何问题或想法，请在下方留言，我会很乐意与您交流。谢谢各位小伙伴的支持。

作者：王彬丞&杨志佳&刘家伟针对新版本 Device-IoT 领域的更新，我们计划推出一系列的文章对这些特性进行详细的介绍，大致的文章大纲为：基于物模型的设备管理 API 设计与实现DMI 数据面能力设计与实现Mapper 开发框架 Mapper-Framework 设计与实现如何使用 Mapper 完成视频流数据处理如何使用 Mapper 实现设备数据写入如何从头开发一个 Mapper（以 modbus 为例） 在上一篇文章中，我们为适应用户对边缘设备管理的需求，设计实现了基于物模型的设备管理 API。在此基础上，我们完善了 DMI 数据面的能力，提供边缘端处理设备数据的多种方式，让 KubeEdge 能够更灵活、标准化的管理边缘设备。本篇文章是系列文章的第二篇，将详细介绍v1.15.0版本在 DMI 数据面的一些工作。DMI 数据面能力支持 在1.12版本中，KubeEdge 设计了设备管理框架——DMI。DMI 框架提供了统一的设备管理相关接口，设备应用开发者和使用者可以通过实现 DMI 中的标准化接口完成设备管理，让边缘设备以微服务的形式提供服务，更加贴合云原生。➤ DMI 的架构图如下图所示：DMI 框架中一个重要的特性是设备管理面与设备数据面解耦。设备管理面基于 Device CRD 承载设备本身的生命周期管理，如图中黄色线条；设备数据面则让设备数据通过微服务的方式向数据消费者应用提供，拥有多种数据推送方式，如图中蓝色线条。DMI 设备管理面数据主要包括设备的元数据、设备属性、配置、生命周期等，其特点是相对比较稳定，创建后信息更新较少，这类数据会通过云边通道进行传递。设备数据面数据则主要为设备传感器采集到的设备数据，相比于管理面数据来说数据量较大，若通过云边通道传输可能会造成通道阻塞，影响集群正常功能。v1.15.0版本中 DMI 数据面功能得到完善，通过数据面能以多样化的方式推送设备数据，相比通过云边通道传输数据更加合理。  DMI 数据面能力支持 ➤ DMI 数据面系统架构如下图所示：在v1.15.0版本更新后，DMI 数据面支持如图中四种方式处理推送设备数据：1、推送至用户应用。按照 v1beta1 版本的 Device Instance API 定义，用户能够在 Device Instance 配置文件中配置 pushMethod 字段，以 HTTP 或者 MQTT 的方式定时将设备数据推送到用户应用中。2、推送至用户数据库。最新版本的 KubeEdge DMI 内置 InfluxDB、Redis、TDengine、MySQL 数据库的数据推送方式，用户能够在 Device Instance 配置文件中 dbMethod 字段设置相应数据库的参数，将设备数据定时传入数据库。3、推送至云端。用户能够设置 Device Instance 配置文件中 reportToCloud 字段决定是否将设备数据推送至云端。4、用户能够通过 Mapper 提供的 RESTful API 主动拉取设备数据。以下是一个使用 DMI 数据面能力处理设备数据的 Device Instance 配置文件示例：apiVersion: devices.kubeedge.io/v1beta1 kind:Device ... spec: properties: -name:temp collectCycle:10000 # The frequency of reporting data to the cloud. once every 10 seconds reportCycle:10000 # The frequency of data push to user applications or databases. reportToCloud:true # Device data will be reported to cloud desired: value:"100" pushMethod: mqtt: # define the MQTT config to push device data to user app address:tcp://127.0.0.1:1883 topic:temp qos:0 retained:false dbMethod: influxdb2: # define the influx database config to push device data to user database influxdb2ClientConfig: url:http://127.0.0.1:8086 org:test-org bucket:test-bucket influxdb2DataConfig: measurement:stat tag: unit:temperature fieldKey: devicetest在示例文件中，用户可以通过 reportToCloud 字段定义 Mapper 是否将设备数据推送至云端；此外，pushmethod.mqtt 字段定义了 Mapper 向用户应用推送的配置信息，示例中表示 Mapper 会定时以 MQTT 协议的方式向 127.0.0.1:1883 地址的用户应用推送设备数据；pushmethod.dbMethod 字段定义了 Mapper 向用户数据库推送的配置信息，示例中表示 Mapper 会定时向 127.0.0.1:8086 地址的 InfluxDB 数据库推送设备数据。基于 DMI 数据面的能力，用户只需在 Device Instance 配置文件中定义相关字段，即可使用多种方式处理采集到的设备数据，有效降低了云边通道阻塞的风险。DMI 提供的功能接口最终是由设备管理插件 Mapper 来承载的。Mapper 北向需要实现 DMI 管理接口向 KubeEdge 完成自身的注册以及设备管理。对于用户来说，独立对接 DMI 接口实现自定义的 Mapper 使用门槛依然较高，因此我们在v1.15.0版本中推出 Mapper 开发框架 Mapper Framework，能够使用简单的命令自动生成一个 Mapper 工程供用户使用，有效降低用户上手的难度。在本系列的下一篇文章中，我们会对 Mapper Framework 的架构与使用方法进行详细介绍。【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_2Slack地址 : 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/