由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/

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 社区将保持开放治理模式和协作理念，进一步升级用户体验，提供更可靠和稳定的服务。社区成功毕业离不开每一位社区伙伴、用户与开发者的协作与贡献，期待与您携手共建，加速社区生态协同发展，共同引领云原生边缘计算迈向产业应用新高度。

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

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。Karmada v1.12版本[1]现已发布，本版本包含下列新增特性：应用级故障迁移功能增强（新增状态中继机制，适用于大数据处理程序高可用场景，如 Flink）单集群应用迁移能力增强（适用于单集群存量应用迁移）Karmada Operator 高可用部署能力支持OverridePolicy 支持局部修改结构化字段值新特性概览▶  应用级故障迁移功能增强在之前的版本中，Karmada 提供了基本的应用级故障迁移能力，能够通过应用的健康状态或自定义的故障等条件触发应用迁移。为了满足有状态应用在故障迁移过程中保留其运行状态的需求，Karmada 在 v1.12 版本新增了应用状态中继机制。对于大数据处理应用（例如 Flink），利用此能力可以从故障前的 checkpoint 重新启动，无缝恢复到重启前的数据处理状态，从而避免数据重复处理。社区在PropagationPolicy/ClusterPropagationPolicy API 中的.spec.failover.application 下引入了一个新的StatePreservation 字段， 用于定义有状态应用在故障迁移期间保留和恢复状态数据的策略。结合此策略，当应用从一个故障集群迁移到另一个集群时，能够从原始资源配置中提取关键数据。状态保留策略StatePreservation 包含了一系列StatePreservationRule 配置，通过 JSONPath 来指定需要保留的状态数据片段，并利用关联的 AliasLabelName 将数据传递到迁移后的集群。以 Flink 应用为例，在 Flink 应用中，jobID 是一个唯一的标识符，用于区分和管理不同的 Flink 作业（jobs）。每个 Flink 作业在提交到 Flink 集群时都会被分配一个jobID。当作业发生故障时，Flink 应用可以利用jobID 来恢复故障前作业的状态，从故障点处继续执行。具体的配置和步骤如下：apiVersion: policy.karmada.io/v1alpha1 kind:PropagationPolicy metadata: name:foo spec: #... failover: application: decisionConditions: tolerationSeconds:60 purgeMode:Immediately statePreservation: rules: -aliasLabelName:application.karmada.io/failover-jobid jsonPath:"{ .jobStatus.jobID }"迁移前，Karmada 控制器将按照用户配置的路径提取 job ID。迁移时，Karmada 控制器将提取的 job ID 以 label 的形式注入到 Flink 应用配置中，比如application.karmada.io/failover-jobid : <jobID>。运行在成员集群的 Kyverno 拦截 Flink 应用创建请求，并根据jobID  获取该 job 的 checkpoint 数据存储路径，比如  /<shared-path>/<job-namespace>/<jobId>/checkpoints/xxx，然后配置initialSavepointPath 指示从save point 启动。Flink 应用根据initialSavepointPath 下的 checkpoint 数据启动，从而继承迁移前保存的最终状态。该能力基于 FlinkDeployment 打造，但广泛适用于能够基于某个 save point 启动的有状态应用程序，这些应用均可参考上述流程实现故障迁移的状态中继。此功能需要启用 StatefulFailoverInjection 特性开关。StatefulFailoverInjection 目前处于 Alpha 阶段，默认情况下是关闭的。功能约束：应用必须限定在单个集群中运行；迁移清理策略（PurgeMode）限定为Immediately，即故障应用需立即删除然后再创建新应用，确保数据一致性。▶  单集群应用迁移能力增强在用户将业务从单集群迁移至多集群的过程中，如果资源已经被迁移到 Karmada 控制面，那么当控制面中的资源模板被删除时，成员集群中的资源也会随之删除。但在某些场景，用户希望能够保留成员集群中的资源。例如，作为管理员，在工作负载迁移过程中可能遇到意外情况（如云平台无法发布应用程序或 Pod 异常）， 需要回滚机制立刻恢复到迁移之前的状态，以便快速止损。在 v1.12 版本，社区在PropagationPolicy/ClusterPropagationPolicy API 中引入了PreserveResourcesOnDeletion 字段，用于定义当控制面中的资源模板被删除时成员集群上资源的保留行为，如果设置为true，则成员集群上的资源将被保留。结合此字段，一旦用户在迁移过程中发现异常，可以快速执行回滚操作并保留成员集群中原有的资源，整个迁移回滚过程更加安全可控。使用该字段请注意以下两点：该配置对所有成员集群统一生效，不会仅针对部分集群进行选择性控制。当 Policy 被删除时，资源模板及已分发的成员集群资源将保持不变，除非被显式删除。以 PropagationPolicy 为例，用户在删除 Karmada 控制面资源模板时，可以配置如下 PropagationPolicy 来保留成员集群的资源：apiVersion: policy.karmada.io/v1alpha1 kind:PropagationPolicy metadata: name:nginx-pp spec: conflictResolution:Overwrite preserveResourcesOnDeletion:true# 资源模板删除后，成员集群资源依然保留 placement: clusterAffinity: clusterNames: -member1 resourceSelectors: -apiVersion:apps/v1 kind:Deployment name:nginx -apiVersion:v1 kind:Service name:nginx-svc更多有关安全回滚迁移的资料请参考：迁移操作如何回滚[2] 。▶  Karmada Operator 高可用部署能力支持作为社区维护的安装工具，Karmada-operator 可以用来部署和管理多个 Karmada 实例。为了更好地支持高可用部署方案，karmada-operator 在本版本实施了一系列针对性的改进和优化措施，包括：引入了对自定义 CA 证书的支持；支持连接外部 etcd；可通过 Secret 指定外部 etcd 客户端的凭据；可为 Karmada 组件指定卷和卷挂载；对外暴露 APISever 服务，用于服务发现。这些增强使得 karmada-operator 能够跨多个管理集群部署一个高度可用的 Karmada 控制平面，这些集群可以跨越不同的数据中心，从而满足故障恢复的诉求。上图是通过 Karmada-operator 构建的生产级高可用架构，在这个架构中，Karmada-operator 跨不同地理位置的数据中心部署多个 Karmada 控制面，并将它们连接到同一个外部 etcd 集群。这种设置不仅确保了跨数据中心的数据一致性，还简化了数据管理和维护工作。此外，借助 Karmada-operator 提供的 APIServer 服务暴露能力，结合 Ingress 对外提供统一的服务访问。同时，利用可配置的CA证书机制，保障了 Karmada 实例与外部服务间通信的安全性。此架构显著增强了系统对单个数据中心故障的抵御能力，最大限度地减少了因数据中心故障导致的服务中断风险，保证了业务连续性和用户体验的稳定性，符合严格的灾难恢复标准。▶  OverridePolicy 支持局部修改结构化字段值OverridePolicy 允许用户针对特定集群自定义资源的覆盖策略，确保资源可以在不同环境中灵活适配和优化。Kubernetes 资源如 Secrets 和 ConfigMaps 常常会用到结构化的字段值，如 ConfigMaps 的.data 利用 YAML 格式的结构化数据承载配置信息。在实际应用中，存在只需要修改其部分字段的情况，而且，当原始的结构化字段值复杂且内容繁多时，使用全覆盖将会大大增大 OverridePolicy 的配置难度。为了解决这一问题，并提高 OverridePolicy 在此类场景中的易用性，Karmada 引入了FieldOverrider 特性。FieldOverrider 支持对 JSON 和 YAML 格式的结构化字段值进行局部修改，即只添加或替换或删除所需的字段。这种方式简化了配置过程，提高了效率，同时减少了出错的可能性，使得资源管理更加直观和便捷。通过FieldOverrider，用户可以对结构化字段值进行更精细化地处理，适应多变的应用环境需求。下面以 ConfigMap 为例，用户可通过FieldOverrider 部分覆盖 ConfigMap 的.data 字段来实现集群间的差异化配置。# example-configmap apiVersion: v1 kind: ConfigMap metadata: name: example-configmap data: config.yaml: | app: database: port: 5432 ip: 127.0.0.1 name: example zone: zone1# example-overridepolicy apiVersion:policy.karmada.io/v1alpha1 kind:OverridePolicy metadata: name:example spec: resourceSelectors: -apiVersion:v1 kind:ConfigMap name:example-configmap overrideRules: -overriders: fieldOverrider: -fieldPath:/data/config.yaml yaml: -subPath:/app/database/port operator:replace# 支持add、remove和replace操作 value:"3306" targetCluster: clusterNames: -member1经过以上配置，集群 member1 中的 ConfigMap 将更新为：# example-configmap in member1 apiVersion: v1 kind: ConfigMap metadata: name: myconfigmap data: config.yaml: | app: database: port: 3306 # 更新了port ip: 127.0.0.1 name: example zone: zone1更多FieldOverrider 的用法请参考：FieldOverrider 使用指南[3]▶ 致谢贡献者Karmada v1.12 版本包含了来自 33 位贡献者的 253 次代码提交，在此对各位贡献者表示由衷的感谢：贡献者列表：@a7i@ahorine@anujagrawal699@B1f030@chaosi-zju@CharlesQQ@chaunceyjiang@husnialhamdani@iawia002@ipsum-0320@jabellard@jklaw90@KhalilSantana@LavredisG@liangyuanpeng@LivingCcj@MAVRICK-1@mohamedawnallah@mszacillo@RainbowMango@SataQiu@seanlaii@sophiefeifeifeiya@tiansuo114@wangxf1987@whitewindmills@wulemao@XiShanYongYe-Chang@xovoxy@yanfeng1992@yelshall@zach593@zhzhuang-zju参考资料[1]Karmada v1.12版本:cid:link_5[2]迁移操作如何回滚:cid:link_0[3]FieldOverrider 使用指南:cid:link_4【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_6 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

作者：唐明&王彬丞   引言   随着边缘计算的发展，人工智能在边缘侧的应用日益增多，对计算资源的需求也越来越高，尤其 GPU 算力的需求增长迅速。KubeEdge 作为基于 Kubernetes 的开源边缘计算平台，除提供高效的边缘设备管理和边缘应用容器化服务外，还提供了边云协同 AI 框架 Sedna，助力边缘 AI 发展。然而由于边缘计算环境复杂，将 GPU 资源纳入 KubeEdge 集群管理并让其与边缘 AI 应用协同工作成为重要问题。本篇文章将介绍如何将 GPU 边缘节点接入 KubeEdge 集群并支持边缘 AI 应用使用 GPU 资源，以应对边缘 AI 应用的计算需求。   GPU 运行环境构建   本文实验环境 💭 注：Node 1、Node 2 均为边缘节点，分别使用 Containerd 和 Docker 作为容器运行时进行演示在边缘节点上使用 GPU 需要先构建 GPU 运行环境，主要包括以下几个步骤：1、安装 GPU 驱动首先需要确定边缘节点机器是否有 GPU，可以使用 lspci | grep NVIDIA 命令来检查。根据具体 GPU 型号下载合适的 GPU 驱动并完成安装，安装完成后可以使用 nvidia-smi 命令检查驱动是否安装成功。安装方法可以参考[1]。2、安装容器运行时将 GPU 节点接入 KubeEdge 集群，需要先安装如 Docker、Containerd 之类的容器运行时，具体的安装指南可以参考 KubeEdge官方文档[2]。需要特别注意的是，自 KubeEdge v1.14 版本起，已经移除了对 Dockershim 的支持，不再支持直接使用 Docker 运行时管理边缘容器。如仍需使用 Docker，在安装 Docker 后还需安装 cri-dockerd[3]。3、安装 Nvidia-Container-ToolkitNVIDIA Container Toolkit 是一个专为构建和运行 GPU 容器设计的工具包。它通过一系列的功能和组件，使得在容器环境中充分利用 NVIDIA GPU 资源变得更加简单和高效。由于边缘节点网络连接情况不同，有两种方式安装 NVIDIA Container Toolkit：▷ 边缘节点能直接访问外部网络若边缘节点能直接访问外部网络，推荐按照官方文档，使用 apt、yum 等工具进行安装[4]。▷ 边缘节点无法直接访问外部网络边缘节点若无法直接访问外部网络，则需要在网络可以联通的机器上下载官方离线安装包[5]，将安装包传入边缘节点完成解压。 解压后目录中应该出现如下的文件：root@user:~/release-v1.16.0-rc.1-experimental/packages/ubuntu18.04/amd64# ls libnvidia-container1_1.16.0~rc.1-1_amd64.deb libnvidia-container-tools_1.16.0~rc.1-1_amd64.deb nvidia-container-toolkit-operator-extensions_1.16.0~rc.1-1_amd64.deb libnvidia-container1-dbg_1.16.0~rc.1-1_amd64.deb nvidia-container-toolkit_1.16.0~rc.1-1_amd64.deb libnvidia-container-dev_1.16.0~rc.1-1_amd64.deb nvidia-container-toolkit-base_1.16.0~rc.1-1_amd64.deb在该目录中执行下方的命令完成安装： root@user:~# sudo apt install ./*这里我们提供的案例是基于 Ubuntu 系统的（如果使用 CentOS，可以在链接[5]下载对应的 rpm 包，使用 rpm 命令进行安装）。4、配置容器运行时支持 GPU成功安装 Nvidia-Container-Toolkit 后，可以使用 nvidia-ctk 来配置各个容器运行时支持 GPU：# containerd (node1) root@user:~# sudo nvidia-ctk runtime configure --runtime=containerd --set-as-default # docker (node2) root@user:~# sudo nvidia-ctk runtime configure --runtime=docker --set-as-default5、重启容器运行时重启容器运行时，并且确认是否已经支持 GPU：# containerd (node1) root@user:~# systemctl daemon-reload && systemctl restart containerd # 检查运行时是否已经修改为 nvidia root@user:~# cat /etc/containerd/config.toml |grep nvidia default_runtime_name = "nvidia" [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia] [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia.options] BinaryName = "/usr/bin/nvidia-container-runtime" # docker (node2) root@user:~# systemctl daemon-reload && systemctl restart docker # 检查运行时是否已经修改为 nvidia root@user:~# docker info |grep Runtime Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux nvidia runc Default Runtime: nvidia经过第一部分 GPU运行环境构建的操作，边缘节点已经拥有 GPU 驱动，容器运行时也具备了 GPU 设备的调用能力，接下来需要将边缘节点正式纳管进 KubeEdge 集群。   边缘 GPU 节点纳管   将边缘 GPU 节点纳管至 KubeEdge 集群主要包括以下几个步骤：1、节点接入推荐使用 keadm 工具将边缘节点接入 KubeEdge 集群，接入方式与普通边缘节点一致，详细信息可参考 KubeEdge 官方文档[6]。下面以 Docker 和 Containerd 容器运行时作为边缘 GPU 节点接入示例：# containerd (node1) root@user:~# keadm join --cgroupdriver=cgroupfs \ --cloudcore-ipport="THE-EXPOSED-IP":10000 \ --kubeedge-version=v1.17.0 \ --token="YOUR TOKEN" --remote-runtime-endpoint=unix:///run/containerd/containerd.sock # docker (node2) root@user:~# keadm join --cgroupdriver=systemd \ --cloudcore-ipport="THE-EXPOSED-IP":10000 \ --kubeedge-version=v1.17.0 \ --token="YOUR TOKEN" --remote-runtime-endpoint=unix:///var/run/cri-dockerd.sock运行 systemctl status edgecore 命令确认边缘节点 EdgeCore 是否运行成功：root@user:~# systemctl status edgecore ● edgecore.service Loaded: loaded (/etc/systemd/system/edgecore.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2022-10-26 11:26:59 CST; 6s ago Main PID: 2745865 (edgecore) Tasks: 13 (limit: 4915) CGroup: /system.slice/edgecore.service └─2745865 /usr/local/bin/edgecore2、部署 k8s-device-plugin可以按照下方的 yaml 文件部署 k8s-device-plugin DaemonSetapiVersion: apps/v1 kind: DaemonSet metadata: name: nvidia-device-plugin-daemonset namespace: kube-system spec: revisionHistoryLimit: 10 selector: matchLabels: name: nvidia-device-plugin-ds template: metadata: labels: name: nvidia-device-plugin-ds spec: containers: - env: - name: FAIL_ON_INIT_ERROR value: "false" image: nvcr.io/nvidia/k8s-device-plugin:v0.14.3 imagePullPolicy: IfNotPresent name: nvidia-device-plugin-ctr resources: {} securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /var/lib/kubelet/device-plugins name: device-plugin dnsPolicy: ClusterFirst priorityClassName: system-node-critical restartPolicy: Always schedulerName: default-scheduler securityContext: {} terminationGracePeriodSeconds: 30 tolerations: - effect: NoSchedule key: nvidia.com/gpu operator: Exists volumes: - hostPath: path: /var/lib/kubelet/device-plugins type: "" name: device-plugin检查 k8s-device-plugin 是否成功部署：root@user:~# kubectl get po -n kube-system -owide|grep nvidia nvidia-device-plugin-daemonset-d5nbc 1/1 Running 0 22m 10.88.0.4 nvidia-edge-node <none> <none> nvidia-device-plugin-daemonset-qbwdd 1/1 Running 0 2d6h 10.88.0.2 nano-1iamih8np <none> <none>使用 kubectl describe node 命令验证节点 GPU 信息是否正确上报。root@user:~# kubectl describe node {YOUR EDGENODE NAME} Name: nvidia-edge-node Roles: agent,edge Labels: beta.kubernetes.io/arch=amd64 ... Capacity: cpu: 12 ephemeral-storage: 143075484Ki hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 40917620Ki nvidia.com/gpu: 1 pods: 110 Allocatable: cpu: 12 ephemeral-storage: 131858365837 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 40815220Ki nvidia.com/gpu: 1 pods: 110如果节点信息中出现了 nvidia.com/gpu 资源，说明 device-plugin 正常运行，可以将 GPU 挂载至边缘 GPU 应用容器中。第三部分提供测试应用的部署方法，能够验证 GPU 调用能力。   测试 GPU 资源调用能力  1、部署 GPU 测试应用可以使用下方所示的示例 yaml，部署一个 pytorch 的边缘应用，该应用使用一个 GPU 资源。kind: Deployment apiVersion: apps/v1 metadata: name: test-gpu namespace: default spec: replicas: 1 selector: matchLabels: app: test-gpu template: metadata: labels: app: test-gpu spec: containers: - name: container-1 image: pytorch/pytorch:2.2.0-cuda12.1-cudnn8-devel command: - tail - '-f' - /dev/null resources: limits: nvidia.com/gpu: '1' requests: nvidia.com/gpu: '1' imagePullPolicy: IfNotPresent nodeName: nvidia-edge-node # replace to your GPU edge node name2、验证 GPU 是否成功挂载进入这个应用创建的容器中，调用 pytorch 中的 torch.cuda.is_available() 命令验证 GPU 是否成功挂载。# containerd (node1) root@user:~# crictl ps CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD de1f1e60abc0a 0dd75116a8ce8 2 minutes ago Running container-1 0 6beffb412af3f test-gpu-6bfbdc9449-jfbrl root@user:~# crictl exec -it de1f1e60abc0a /bin/bash root@test-gpu-6bfbdc9449-jfbrl:/workspace# python3 Python 3.10.13 (main, Sep 11 2023, 13:44:35) [GCC 11.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import torch >>> torch.cuda.is_available() True # docker (node2) root@user:~# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e7e3804626a5 853b58c1dce6 "tail -f /dev/null" 53 seconds ago Up 45 seconds k8s_container-1_test-gpu-arm64-nano-7f8fd7f79f-hzvp5_default_64fb7a90-b0e6-4b46-a34f-8a06b24b9169_0 root@user:~# docker exec -it e7e3804626a5 /bin/bash root@test-gpu-arm64-nano-7f8fd7f79f-hzvp5:/# python3 Python 3.8.10 (default, Nov 14 2022, 12:59:47) [GCC 9.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import torch >>> torch.cuda.is_available() True通过本文的介绍，我们详细探讨了如何将边缘 GPU 节点接入 KubeEdge 集群，并支持边缘应用使用 GPU 资源。将 GPU 资源集成至 KubeEdge 集群中可以大大提升边缘设备的计算能力，推动边缘 AI 技术的发展，助力实现高效的边缘计算解决方案。欢迎大家持续关注 KubeEdge 社区。▍相关链接[1] 安装GPU驱动参考文档：https://www.nvidia.cn/drivers/lookup/[2] KubeEdge容器运行时文档：https://kubeedge.io/docs/setup/prerequisites/runtime[3] cri-dockerd参考文档：https://kubeedge.io/docs/setup/prerequisites/runtime#docker-engine[4] NVIDIA Container Toolkit官方文档：https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html[5] NVIDIA Container Toolkit官方离线安装包：cid:link_1[6] 节点接入参考文档：https://kubeedge.io/docs/setup/install-with-keadm【更多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/

Kmesh是业内首个内核级流量治理引擎，Kmesh创新性地将服务治理卸载到内核eBPF和中心代理。Kmesh目前有两种工作模式：Kernel-Native 和 Dual-Engine模式。Kernel-Native模式，Kmesh将流量治理完全下沉操作系统内核，通过eBPF和可编程内核模块对流量进行治理，在整个服务访问链路上不会增加任何多余的连接跳数，提供极致的性能体验。当然Kernel-Native模式对操作系统内核有一定的要求，比较适合对性能有极致要求的用户。 今天重点谈的是Dual-Engine模式（本文后续均以Kmesh指代），这是一种分层的流量治理架构，它是通过eBPF程序拦截应用流量，并根据用户策略进行路由、负载均衡等四层的治理；七层治理则采用中心式代理，这样既可以保证七层治理需求的多样性和扩展性，又避免了Sidecar架构中，流量两次进出七层代理的复杂性。Kmesh Dual-Engine的架构如下图所示：Kmesh Dual-Engine架构Ambient Mesh是Istio社区2022年推出的一种Sidecarless架构，其目的也是为用户提供资源开销更小的网络基础设施。Ambient也是采用分层的流量治理，其中节点上，用户态组件ztunnel负责拦截进出应用的流量，并进行四层转发；中心侧通过waypoint进行七层流量的治理，同样可以做到灵活、按需部署。Ambient Mesh架构我们可以看到Kmesh和Ambient Mesh在架构上非常相似，两者均采用了四七层分离的流量治理架构。然而不同之处在于，Ambient Mesh流量的拦截和转发依靠节点级用户态ztunnel，而Kmesh则依靠eBPF。ztunnel工作在用户态，因此应用发送的流量首先经过iptables的拦截，进入本机协议栈处理一次，发送到ztunnel，而经过ztunnel处理后，再发起第二次连接。同理在服务端，流量也会先被拦截到ztunnel，再次发起连接，然后经由本机协议栈发送到应用进程。但是Kmesh对应用流量的拦截和转发，则是通过eBPF程序在socket的不同钩子点完成，整个过程没有增加多余的连接，因此每次通信过程比Ambient Mesh少两条连接。说到这里就不得不提一下Kmesh的设计初衷了。 Kmesh设计之道 当前用户在考虑服务网格落地时最担心的几个典型问题是：网格基础设施不够可靠，运维复杂，因为过多的中间点出现在服务的访问链路中，服务访问被不同的连接管道串联， 故障定位变得复杂Sidecar带来的CPU、内存资源开销不可忽视网格无法独立升级，它的生命周期与应用绑定，升级过程伴随着应用重启基础设施代理额外的服务访问时延增加Kmesh重点考虑了以上问题并结合用户对网格的基本诉求，定义了五大设计原则：极简运维，打造足够可靠、轻量、解耦的网络基础设施，尽量的减少用户的维护成本。高性能，微服务架构下，服务的调用拓扑一般都很长，有的请求甚至有10+次调用链，因此必须保证在绝大多数情况下，小于1ms的时延。低开销，底层网络基础设施占用的CPU、Memory相对于业务容器应该足够小，并且不会随着业务容器的规模而大幅增加。扩展性，为应对不同的协议治理，必须从架构层提供足够的扩展能力高安全，构筑零信任安全的能力，为用户提供全链路可信保障Kmesh五大设计原则  Kmesh与Ambient Mesh性能对比  几个月前，我们将Kmesh v0.5.0与Ambient Mesh v1.22.1在测试环境下（kind集群）进行过对比，只比对了两者在处理L7流量治理的场景下的时延，结果显示，Kmesh的端到端时延较Ambient Mesh提升25%左右。Kmesh与Ambient v1.22对比我们把这个结果汇报给了CNCF TAG-Network以及Istio社区，他们希望在真实的Kubernetes集群以及用最新的版本进行全面的测试。所以我们重新做了完整的测试。▍测试环境我们在华为云香港Region创建了一个Kubernetes 1.30标准版集群，并且纳管了三个Worker节点（Ubuntu 22.04, 规格为4U 16G）。集群中安装Istio 1.24.1 Ambient模式，以及Kmesh最新版本集群中部署了Fortio测试工具，无资源限制，其中Fortio-Client与Fortio-Server均为单副本，分别部署在不同的节点七层代理waypoint按需部署，在Kmesh和Ambient测试中，均与Fortio-Server部署在同一个节点，保证两者拓扑一致waypoint 规格2核1GFortio测试采用连接复用，并发连接数（1,2,4,8,16,32,64,128）▍最大吞吐量L4治理吞吐四层服务治理，Kmesh的最大吞吐与基线（没有任何治理）基本一致，Kmesh的吞吐能力是Ambient Mesh的两倍左右。这里主要是因为，Kmesh的采用eBPF随流治理，不会增加访问路径的长度，而Ambient Mesh在客户端和服务端两个节点分别多了一个ztunnel用户态代理，导致流量路径多了两条连接。L7治理吞吐L7治理吞吐放大图七层服务治理，Kmesh与Ambient吞吐量均比基线差，因为两者均多了一层七层Envoy代理。但是Kmesh的吞吐大概是Ambient Mesh的1.3倍，这里还是得益于Kmesh的治理路径上少了两次用户态代理，减少了数据的用户态和内核态拷贝次数以及协议栈处理的次数。▍服务治理时延我们选取了在固定QPS 1024下，分别测试Kmesh和Ambient Mesh的L4和L7治理的时延。L4服务治理时延测试可以看到Kmesh的L4治理相比于基线，基本上没有增加额外的时延开销，而Ambient Mesh在并发连接数比较高的时候，增加了大概1.5ms的时延。可能是由于ztunnel在新版本引入了连接池导致。L7服务治理时延测试我们可以看到在并发连接数低时，Kmesh与Ambient Mesh的七层治理时延增加非常少，在小于8并发的时候，Kmesh的时延小于1ms，Ambient Mesh的时延不可预测性更大，其P99时延甚至增加8ms。随着并发连接数增加，Kmesh和Ambient Mesh的时延均增加。但是在小于32并发时，Kmesh的P99时延比Ambient Mesh好两倍多。在更高128并发时，Ambient Mesh的表现似乎更优一些，但是差距不大。在笔者看来，造成以上结果的原因，主要有两点。1、Waypoint采用Envoy实现，当前测试中Envoy均启动两个worker线程并发处理。Envoy的线程间不共享任何状态和数据以避免锁冲突，但是同时带来了负载不均衡和延迟不稳定的问题。2、ztunnel的实现中增加了连接池的优化，虽然连接复用可以在高并发时节省一些连接资源，但是也可能带来额外的不稳定时延。CPU和内存Kmesh在节点流量治理采用了eBPF，没有用户态进程，所以引入的资源开销非常小，详细请参考：cid:link_5/en/docs/performance/resource_consumption/而在最大吞吐量测试时，ztunnel的CPU占用率与Fortio应用基本一致，大概100%的CPU占用，而通过bpftop工具可以查看Kmesh的bpf程序CPU利用大概在10%左右，从CPU利用率上来说Kmesh优于Ambient 10 倍数据面内存：在测试中，ztunnel占用的内存保持在10M+，相对比较稳定，Kmesh数据面的内存占用主要在BPF Map的内存分配，当前Kmesh使用的BPF Map已经采用按需分配，因此在测试过程占用的内存更少，小于5M。  测试感悟与总结  本次测试，我们主要在时延和吞吐两个维度对Kmesh和Ambient进行了一定比较，总体来说Kmesh的性能略胜一筹。四层流量治理场景下，Kmesh的性能与基线基本保持一致，全面优于Ambient Mesh。但是在七层治理的场景下，我们看到无论是Kmesh还是Ambient Mesh性能衰减还是比较大，而且也具有一些不稳定的延时。七层代理Waypoint是端到端访问的性能瓶颈，受限于其多线程无锁的设计，在高并发场景下，Envoy的资源分配以及参数调教对性能的影响很重要。另外技术的对比不应该只局限在一些性能参数指标，还应该关注可靠性、运维的便捷性。服务访问链路就像是由多条管道连接起来的输水管，每一个接口连接就相当于一个用户态组件。输水管道中，接口连接处最容易漏水，而服务访问中同样如此，由于不同的代理组件接收、处理及发送数据的速度不一样，因此不同的代理设置不同的连接Buffer，不同的超时，不同的连接池等等参数。越多的连接级联，意味着越多的不可靠因素和风险存在。Kmesh在设计之初就重点考虑了极简运维和高可靠性，Kmesh尽可能地将流量治理下沉，尽量减少连接的跳数，从下图可以看出，Kmesh在服务访问链路上连接跳数比Ambient Mesh少2条，这大大降低了用户在故障后问题定位的复杂度。将节点的流量治理下沉OS内核的另一个好处是，Kmesh在控制面升级时或者重启时，即使BPF程序更新，也不会导致业务的连接中断。而节点级用户态代理，天然不具备升级重启不影响业务通信的能力。  如何使用Kmesh/加入社区贡献  社区地址：cid:link_4安装试用：cid:link_3参考链接1. 实验步骤：cid:link_12. cid:link_53. cid:link_24. https://jimmysong.io/blog/introducing-kmesh-kernel-native-service-mesh/更多云原生技术动向关注容器魔方

12月7日，2024华为云开源开发者论坛在上海顺利召开。本届论坛面向用户企业、生态伙伴、个人和高校开发者，开展主论坛、云原生、开源共创、大前端四大论坛，共启云上创新和价值裂变。云原生与AI成为本次论坛中的热门话题，来自CNCF、小红书、B站、华为云、DaoCloud、多比特、京东等技术大咖齐聚上海，共享KubeEdge、Volcano、Karmada、openGemini、Kmesh、Kuasar、openEuler、Sermant等项目技术的生产实践和创新成果，共探云原生社区合作与未来发展无限可能。开放协作，共创云原生 × AI繁荣生态华为云开源业务总经理邓明昆在论坛上发表《开放协作，共创云原生繁荣生态》演讲。他表示，云原生的商业价值和技术价值已经已经获得市场和社区的广泛认同，华为云作为云原生生态的重要参与者，将持续开放协作，和开发者一起共创云原生繁荣生态。会上，Kmesh Orion 子项目重磅亮相，持续构建内存安全、高性能的云原生数据面。引领云原生技术创新，华为云云原生一路生花。今年，KubeEdge成为CNCF首个云原生边缘计算毕业项目，openGemini、Sermant正式成为CNCF官方项目，Karmada、Volcano海内外多行业代表用户大规模生产落地，Kmesh创新引领Sidecarless服务网格发展，Kuasar 1.0 实现LLM高效开发与灵活部署重塑，推动云原生与AI融合发展。▲ 华为云开源业务总经理邓明昆云原生已成为企业数字化转型的重要基石，随着人工智能的高速发展，云原生和 AI 的融合也正在智能应用和行业场景中展现出更大的潜力。主论坛上，CNCF中国区总监、LF亚太区战略总监Keith Chan分享了开源发展趋势及当前热门的Cloud Native AI。他提到，AI开发者正与云原生开发者呈融合之势，Cloud Native AI即在云原生基础设施上部署和应用AI。在对最终用户的调研中发现，超半数企业在 AI 部署中应用云原生技术，涵盖公有云、私有云及混合云。在迈向CNAI的进程中，云原生生态系统为在云中运行AI工作负载拥有更好体验铺平了道路，有力地支持了GPU共享，对加速云原生AI发展提供了有力的技术支持。▲ CNCF中国区总监、LF亚太区战略总监Keith Chan在《打破算力边界，云原生加速AI应用创新》主题分享中，华为云云原生开源负责人、CNCF技术监督委员会（TOC）委员王泽锋指出，AI应用创新高速发展对算力提出了更高要求，云原生统一算力平台，有效整合资源，实现高效的管理与调度，已成为AI的最佳底座，而统一作业编排和算力调度是平台能力的关键。他详细阐述了基于 Karmada 和 Volcano 的统一算力编排调度方案，包括作业抽象、Gang 调度、装箱调度、统一资源管理、故障迁移等功能，这些云原生能力为AI应用提供了稳定、高效的运行环境，推动AI创新发展。▲ 华为云云原生开源负责人、CNCF技术监督委员会（TOC）委员王泽锋融合创新，智能未来，云原生论坛大咖齐聚小红书容器技术专家、云原生资源效能与应用平台负责人熊峰带来《Karmada助力小红书打造混合云多集群架构》演讲分享。随着业务的飞速发展，小红书内部K8s集群的规模和数量都在快速增长，集群和资源管理难度急剧增大，小红书通过引入 Karmada 多集群方案，打造面向应用的统一平台入口，提升应用跨集群分发与弹性能力，做好应用跨集群调度，高效管理多云基础设施。▲ 小红书容器技术专家、云原生资源效能与应用平台负责人熊峰Bilibili云原生资深研发工程师王凯发表《哔哩哔哩在视频转码场景下基于Volcano的落地实践》演讲。他介绍了为什么选型Volcano并细致讲解了基于 Volcano 的联邦化离线平台介绍和转码场景对 Volcano 做的高吞吐改造。当前 B 站转码任务已经 100% 由 Volcano 调度。借助 Volcano ，B站将批任务处理能力下沉到了平台，可供其他类似场景复用，此外也和其他场景拉齐了调度器。当前 B 站内部 AI、大数据、转码已经都统一了调度器。▲ Bilibili云原生资深研发工程师王凯KubeEdge作为今年新晋的CNCF毕业级项目，也在本次云论坛上趁热给与会项目和开发者们带来了社区治理经验分享，KubeEdge TSC两位专家——华为云高级软件工程师徐飞，道客首席运营官张红兵联合发表《CNCF毕业项目KubeEdge经验分享及行业实践》演讲。KubeEdge自2018年开源以来，一直秉持开源开放的治理理念，在社区开发、社区治理、社区用户采纳等方面都取得重大的进展。成功从CNCF毕业，标志着项目的发展进入成熟的新阶段。▲ KubeEdge TSC，华为云高级软件工程师徐飞，道客首席运营官张红兵华为云数据库技术专家 & openGemini社区Maintainer 范祥从社区技术融合创新的角度，带来《openGemini 与 KubeEdge：探索云边协同的高效时序数据治理方案》分享。他指出，当前，物联网和车联网领域的企业普遍将数据直接传输至云端，这导致了数据流转环节增多，数据处理效率问题变得尤为紧迫。为了应对这一挑战，openGemini携手KubeEdge和社区合作伙伴，致力于打造基于KubeEdge平台的云边协同解决方案，旨在为用户提供简单、便捷且高效的数据处理能力。▲ 华为云数据库技术专家 & openGemini社区Maintainer 范祥华为云Grid可靠性首席技术专家刘翔，Istio社区Steering Committee委员、Kmesh Maintainer徐中虎介绍了《服务网格的未来：Kmesh的设计思想与演进方向》。Kmesh采用eBPF将L4治理下沉内核，配合安全、稳定、可靠的中心式L7代理，将高性能、轻量发挥到极致。Kmesh Orion作为内存安全、高性能的云原生数据面，具备丰富的L7流量治理特性，可以对当前Kmesh的L4流量治理能力进行有效补充，与Kmesh组合将在安全、高性能、低开销、极简运维等方面形成独特的竞争优势。▲ 华为云Grid可靠性首席技术专家刘翔，Istio社区Steering Committee委员，Kmesh Maintainer徐中虎华为云容器基础设施架构师冯绍宝，华为高级工程师、openEuler sig-cloudnative Maintainer徐学鹏介绍了Kuasar新型轻量化容器沙箱的探索和实践。单一容器沙箱很难同时满足安全、通用和资源效率这3个特性。Kuasar提出一套Sandbox管理框架，通过简化架构，抽象接口，配合轻量级容器引擎iSulad，提供了丰富的沙箱类型支持，可大幅沙箱容器的启动速度和资源效率。iSulad+Kuasar将在Serverless、AI、机密容器等场景持续演进，在云原生时代发挥更大的作用。▲ 华为云容器基础设施架构师冯绍宝，华为高级工程师，openEuler sig-cloudnative Maintainer冯学鹏多比特基础架构组负责人陈志军发表《小游戏出海场景下基于Sermant的云原生微服务架构演进》演讲。他介绍了在中国小游戏企业出海渐成趋势之际面临的挑战及对微服务架构的选型过程。Sermant具备高性能、资源占用少、代码0侵入等优势，全面的类隔离机制实现0类冲突，且提供更丰富、更灵活的服务治理功能解耦，微服务运行时动态挂载：服务0中断。多比特在基于Sermant的实践中，探索出了一条保证业务稳定和成本可控的道路。▲ 多比特基础架构组负责人陈志军在论坛期间的云原生趋势谈主题圆桌中，CNCF中国区总监、LF亚太区战略总监Keith Chan，华为云云原生开源负责人、CNCF TOC王泽锋，道客首席运营官、KubeEdge TSC张红兵，京东高级算法工程师王龙辉，华为云高级软件工程师任洪彩进行了云原生趋势深度探讨，共研开源跨社区合作、用户社区合作以及云原生与AI未来发展等话题。▲ 圆桌对话：云原生趋势谈让每一位开发者都成为决定性的力量。在大会主论坛上，来自Karmada、Volcano、KubeEdge、openGemini等社区的多位云原生社区核心贡献者，荣获年度杰出开源开发者奖项。该奖项用于致谢开发者们在华为云开源开发者生态中的协作贡献和卓越价值。▲ 年度杰出开源开发者作为全球云原生生态的长期参与者与贡献者，华为云深耕云原生技术创新，是CNCF唯一的中国创始成员，拥有CNCF多个项目技术委员会、治理委员会成员及核心Maintainer席位，并在2024年获得了全球顶级开源组织CNCF中国本土唯一TOC委员席位。坚持开源创新，驱动产业升级，随着企业用云的不断深入，华为云持续创研业界领先的云原生产品方案，连续八次中国容器软件市场份额No.1，分布式云原生UCS、云容器引擎CCE、Serverless容器CCE Autopilot和CCI等代表产品引领全行业智能化发展趋势，为企业数智化转型提供强大动力。融合创新，智领未来。开源社区不仅仅在各自的技术领域中加深探索创新，也在跨社区的应用合作与融合发展中不断拓宽可能性。本次华为云开源开发者论坛云原生分论坛，为用户和开发者们带来了多项目、多领域的行业用户实践经验和技术创新成果分享，而成熟发展的云原生生态系统也正在加速引领各行各业迈向智能未来。更多云原生技术动向关注容器魔方

Kmesh 是内核原生Sidecarless服务网格数据平面。它借助 "eBPF "和 "可编程内核"，将流量治理下沉到操作系统内核，大大的降低了服务网格的资源开销和网络延迟。通过eBPF，流量数据可以直接在内核中获取，并且能够使用 "bpf map"将数据传递到用户空间。Kmesh使用这些数据构建监控指标和访问日志。▍如何获取原始数据在内核中，可以直接获取socket携带的流量信息。bpf_tcp_sock 中携带的数据如下：struct bpf_tcp_sock { __u32 snd_cwnd; /* Sending congestion window */ __u32 srtt_us; /* smoothed round trip time << 3 in usecs */ __u32 rtt_min; __u32 snd_ssthresh; /* Slow start size threshold */ __u32 rcv_nxt; /* What we want to receive next */ __u32 snd_nxt; /* Next sequence we send */ __u32 snd_una; /* First byte we want an ack for */ __u32 mss_cache; /* Cached effective mss, not including SACKS */ __u32 ecn_flags; /* ECN status bits. */ __u32 rate_delivered; /* saved rate sample: packets delivered */ __u32 rate_interval_us; /* saved rate sample: time elapsed */ __u32 packets_out; /* Packets which are "in flight" */ __u32 retrans_out; /* Retransmitted packets out */ __u32 total_retrans; /* Total retransmits for entire connection */ __u32 segs_in; /* RFC4898 tcpEStatsPerfSegsIn * total number of segments in. */ __u32 data_segs_in; /* RFC4898 tcpEStatsPerfDataSegsIn * total number of data segments in. */ __u32 segs_out; /* RFC4898 tcpEStatsPerfSegsOut * The total number of segments sent. */ __u32 data_segs_out; /* RFC4898 tcpEStatsPerfDataSegsOut * total number of data segments sent. */ __u32 lost_out; /* Lost packets */ __u32 sacked_out; /* SACK'd packets */ __u64 bytes_received; /* RFC4898 tcpEStatsAppHCThruOctetsReceived * sum(delta(rcv_nxt)), or how many bytes * were acked. */ __u64 bytes_acked; /* RFC4898 tcpEStatsAppHCThruOctetsAcked * sum(delta(snd_una)), or how many bytes * were acked. */ __u32 dsack_dups; /* RFC4898 tcpEStatsStackDSACKDups * total number of DSACK blocks received */ __u32 delivered; /* Total data packets delivered incl. rexmits */ __u32 delivered_ce; /* Like the above but only ECE marked packets */ __u32 icsk_retransmits; /* Number of unrecovered [RTO] timeouts */ };注意: 上述数据并没完全用于监控指标和访问日志功能。Kmesh将在后续的开发中逐步补充这些指标。现阶段使用的数据有：struct tcp_probe_info { __u32 type; struct bpf_sock_tuple tuple; __u32 sent_bytes; __u32 received_bytes; __u32 conn_success; __u32 direction; __u64 duration; // ns __u64 close_ns; __u32 state; /* tcp state */ __u32 protocol; __u32 srtt_us; /* smoothed round trip time << 3 in usecs */ __u32 rtt_min; __u32 mss_cache; /* Cached effective mss, not including SACKS */ __u32 total_retrans; /* Total retransmits for entire connection */ __u32 segs_in; /* RFC4898 tcpEStatsPerfSegsIn * total number of segments in. */ __u32 segs_out; /* RFC4898 tcpEStatsPerfSegsOut * The total number of segments sent. */ __u32 lost_out; /* Lost packets */ };除了这些socket携带的数据外，Kmesh通过socket_storage在建立链接时存储临时数据。当链接关闭时，从之前存储的临时数据中获取链接持续时间等数据。▍数据处理Kmesh在内核中获取了来自链接的数据后，会通过ringbuf将数据传递给用户态。Kmesh在用户态将ringbuf的数据解析之后，根据这些数据中携带的源服务和目标服务信息更新metricController中的缓存和构建metricLabels。构建的metricLabels有workload粒度的也有service粒度的。但workload粒度的监控指标最多是集群中pod数量的平方，因此Kmesh提供一个启动开关，使用户能够按需启用监控指标功能和访问日志功能。namespacedhost := "" for k, portList := range dstWorkload.Services { for _, port := range portList.Ports { if port.TargetPort == uint32(dstPort) { namespacedhost = k break } } if namespacedhost != "" { break } }建立工作负载粒度的度量和服务粒度的度量metricLabels后，更新缓存。每5秒钟，监控指标信息都会通过Prometheus API更新到Prometheus中。在处理指标时，会一起生成访问日志。每次链接关闭时，都会将生成的Accesslog打印到Kmesh的日志中。Kmesh监控指标功能和访问日志功能的整体架构图如下所示：指标细节现阶段Kmesh L4层监控的指标如下：工作负载粒度:NameDescribekmesh_tcp_workload_connections_opened_total源工作负载和目标工作负载之间总共建立了多少次链接kmesh_tcp_workload_connections_closed_total源工作负载和目标工作负载之间总共关闭了多少次链接kmesh_tcp_workload_received_bytes_total目标工作负载接收到了多少的数据kmesh_tcp_workload_sent_bytes_total源工作负载发送了多少的数据kmesh_tcp_workload_conntections_failed_total源工作负载和目标工作负载之间建立链接失败了多少次服务粒度:NameDescribekmesh_tcp_connections_opened_total源工作负载和目标服务之间总共建立了多少次链接kmesh_tcp_connections_closed_total源工作负载和目标服务之间总共关闭了多少次链接kmesh_tcp_received_bytes_total目标服务接收到了多少的数据kmesh_tcp_sent_bytes_total源工作负载发送了多少的数据kmesh_tcp_conntections_failed_total源工作负载和目标服务之间建立链接失败了多少次监控指标例子:kmesh_tcp_workload_received_bytes_total{connection_security_policy="mutual_tls",destination_app="httpbin",destination_canonical_revision="v1",destination_canonical_service="httpbin",destination_cluster="Kubernetes",destination_pod_address="10.244.0.11",destination_pod_name="httpbin-5c5944c58c-v9mlk",destination_pod_namespace="default",destination_principal="-",destination_version="v1",destination_workload="httpbin",destination_workload_namespace="default",reporter="destination",request_protocol="tcp",response_flags="-",source_app="sleep",source_canonical_revision="latest",source_canonical_service="sleep",source_cluster="Kubernetes",source_principal="-",source_version="latest",source_workload="sleep",source_workload_namespace="default"} 231也能够通过prometheus dashboard查看监控指标。具体步骤参考Kmesh可观测性文档。现阶段Kmesh访问日志展示的字段如下：NameDescribesrc.addr请求的源地址和端口src.workload源工作负载名称src.namespace源工作负载所在的namespacedst.addr请求的目标地址和端口dst.service目标服务的域名dst.workload目标工作负载的名称dst.namespace目标工作负载的命名空间direction流量流向，OUTBOUND表示从节点流出，INBOUND表示从流入节点sent_bytes本次链接发送的数据量received_bytes本次链接接收的数据量duration本次链接的持续时间Accesslog Result:accesslog: 2024-09-14 08:19:26.552709932 +0000 UTC src.addr=10.244.0.17:51842, src.workload=prometheus-5fb7f6f8d8-h9cts, src.namespace=istio-system, dst.addr=10.244.0.13:9080, dst.service=productpage.echo-1-27855.svc.cluster.local, dst.workload=productpage-v1-8499c849b9-bz9t9, dst.namespace=echo-1-27855, direction=INBOUND, sent_bytes=5, received_bytes=292, duration=2.733902ms▍SummaryKmesh直接从套接字获取流量数据，并将其作为ringbuf传递到用户空间，以生成监控指标和访问日志。避免在用户空间拦截流量并以本地方式获取指标。定期批量更新用户空间中的指标，避免在大流量时增加网络延迟。随后，我们还将开发跟踪功能，以补充 Kmesh 的可观测能力。欢迎感兴趣的同学加入Kmesh开源社区!12月7日，Kmesh技术专家将在2024华为云开源开发者论坛上带来《服务网格的未来：Kmesh的设计思想与演进方向》技术分享及重磅发布！添加小助手k8s2222，报名领票参会！

开放创新，释放云上数字生产力。12月7日，2024华为云开源开发者论坛将于上海举办。本届论坛面向生态合作伙伴、企业、个人和高校开发者，设置主论坛、云原生、开源共创、大前端四大论坛，帮助开发者使用开源链接鲲鹏、昇腾根生态和华为云生态，实现高效创新和价值裂变。2024华为云开源开发者论坛云原生专场汇聚 KubeEdge、Volcano、Karmada、Kmesh、openGemini、Sermant、OpenTiny、Kuasar 等技术大咖，邀您共探前沿技术，共领智能未来！完整议程已揭晓，欢迎报名参会 https://hdxu.cn/mitm

作者：王彬丞、杨志佳、刘家伟随着万物互联时代快速到来，5G网络普及导致边缘设备产生的数据量快速增长。普通的边缘设备计算能力不足，因此传统方法会将边缘侧数据集中汇聚到云端数据中心进行处理，容易对响应实时性、网络稳定性以及数据安全性产生挑战。为满足用户在大规模设备场景中更高的可用性需求，KubeEdge Device-IoT在1.12版本推出设备管理框架（Device Management Interface，DMI）。DMI整合设备管理接口，将管理面和业务面数据解耦，优化边缘计算场景下的设备管理能力，打造基于云原生技术的设备数字孪生管理平台。在 1.15 版本中，我们根据边缘设备管理的用户需求迭代更新 v1beta1 版本的设备管理  API，并以此为基础完善 DMI 数据面功能，承载于南向的 Mapper 开发框架 Mapper-Framework 中。Mapper-Framework 提供了全新的 Mapper 自动生成框架，框架中集成了 DMI 设备管理面与数据面能力，能够自动生成 Mapper 工程，用户只需实现其中的设备驱动的功能即可使用 Mapper 管理边缘设备，简化用户设计开发 Mapper 的复杂度，提升开发效率。针对新版本 Device-IoT 领域的更新，我们计划推出一系列的文章对这些特性进行详细的介绍，大致的文章大纲为：基于物模型的设备管理 API 设计与实现DMI 数据面能力设计与实现Mapper 开发框架 Mapper-Framework 设计与实现如何使用 Mapper 完成视频流数据处理如何使用 Mapper 实现设备数据写入如何从头开发一个 Mapper（以 modbus 为例） 本篇文章是系列文章的第一篇，主要介绍基于物模型的设备管理 API。    基于物模型的设备管理 API  为适应用户需求，在 v1.15.0 版本中，KubeEdge SIG Device-IoT 提出基于物模型的设备管理 API，将 Device Model 与 Device Instance从 v1alpha2 版本升级为 v1beta1 版本。新版本的设备管理 API 能够更全面的描述物理设备，新增了边缘设备数据处理的相关字段，能够适配 DMI 数据面能力增强功能。北向设备  API 结合南向的 DMI 接口，实现设备管理与设备数据处理，API 的主要更新包括：▍1. Device ModelDevice Model 用以描述一类边缘设备共同的设备属性。按照物模型的定义，Device Model 中新增了设备属性描述、设备属性类型、设备属性取值范围、设备属性单位等字段，如下图所示：// ModelProperty describes an individual device property / attribute like temperature / humidity etc. type ModelProperty struct { // Required: The device property name. // Note: If you need to use the built-in stream data processing function, you need to define Name as saveFrame or saveVideo Name string `json:"name,omitempty"` // The device property description. // +optional Description string `json:"description,omitempty"` // Required: Type of device property, ENUM: INT,FLOAT,DOUBLE,STRING,BOOLEAN,BYTES,STREAM Type PropertyType `json:"type,omitempty"` // Required: Access mode of property, ReadWrite or ReadOnly. AccessMode PropertyAccessMode `json:"accessMode,omitempty"` // +optional Minimum string `json:"minimum,omitempty"` // +optional Maximum string `json:"maximum,omitempty"` // The unit of the property // +optional Unit string `json:"unit,omitempty"` }上图展示了 Device Model 的核心 ModelProperty 字段，其中 Type 字段定义该属性的数据类型，AccessMode 定义该属性的访问方式，包括读写和只读两种。当访问方式设置为只读时，Mapper 会直接返回采集到的设备数据，反之当设置为读写后，Mapper 会对采集到的设备数据进行归一化等处理后再返回。Minimum 与 Maximum 则定义了设备属性的最大最小值，Unit 字段定义了设备属性的单位。下图展示了一个 Device Model 配置文件的示例：apiVersion: devices.kubeedge.io/v1beta1 kind: DeviceModel metadata: name: beta1-model spec: properties: - name: temp # define device property description: beta1-model type: INT # date type of device property accessMode: ReadWrite maximum: "100" # range of device property (optional) minimum: "1" unit: "Celsius" # unit of device property protocol: modbus # protocol for device, need to be same with device instance▍2. Device Instance一个 Device Instance 代表一个实际的设备对象。v1beta1 版本中，Device Instance 中内置的协议配置全部移除，包括 Modbus、OPC-UA、Bluetooth 等。用户可以通过可扩展的 Protocol 配置来设置设备协议，能够实现任何协议的设备接入。Modbus、OPC-UA、Bluetooth 等内置协议的 Mapper 仍会保留在 Mappers-go 仓库中，同时也会不断增加其他协议的内置 Mapper。type ProtocolConfig struct { // Unique protocol name // Required. ProtocolName string `json:"protocolName,omitempty"` // Any config data // +optional // +kubebuilder:validation:XPreserveUnknownFields ConfigData *CustomizedValue `json:"configData,omitempty"` } type CustomizedValue struct { Data map[string]interface{} `json:"-"` }此外，为增强 DMI 数据面功能，本次更新在 Device Instance 的设备属性中增加了设备数据处理的相关配置，例如设备上报频率、数据推送频率、属性是否上报云端、设备数据推送方式，如下图所示。type DeviceProperty struct { ... // Define how frequent mapper will report the value. // +optional ReportCycle int64 `json:"reportCycle,omitempty"` // Define how frequent mapper will collect from device. // +optional CollectCycle int64 `json:"collectCycle,omitempty"` // whether be reported to the cloud ReportToCloud bool `json:"reportToCloud,omitempty"` // PushMethod represents the protocol used to push data, // please ensure that the mapper can access the destination address. // +optional PushMethod *PushMethod `json:"pushMethod,omitempty"` }ReportCycle 字段定义了 Mapper 向用户数据库、用户应用推送数据的频率；CollectCycle 字段定义了 Mapper 向云端上报数据的频率；ReportToCloud 字段定义了 Mapper 采集到的设备数据是否需要上报云端；PushMethod 字段定义了 Mapper 推送设备数据的方式。目前提供 HTTP、MQTT 以及 OpenTelemetry 等方式向用户应用推送数据，并内置集成 InfluxDB、MySQL、Redis、TDengine 数据库。用户能够通过配置文件控制Mapper 向用户应用、用户数据库中定时推送设备数据，也能够通过 API 主动拉取设备数据，实现设备数据处理方式的多样化，相比于将所有数据推送至云端再行处理的传统方法，能够有效减少云边通信阻塞的风险。下图展示了一个 Device Instance 配置文件的示例：apiVersion: devices.kubeedge.io/v1beta1 kind: Device ... spec: properties: - name: temp collectCycle: 2000 # The frequency of reporting data to cloud, 2 seconds reportCycle: 2000 # The frequency of data push to user applications or databases, 2 seconds reportToCloud: true # Decide whether device data needs to be pushed to the cloud 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 visitors: # Define the configuration required by the mapper to access device properties (e.g. register address) protocolName: modbus configData: register: "HoldingRegister" offset: 2 limit: 1 protocol: # Device protocol. The relevant configuration of the modbus protocol is defined in the example. protocolName: modbus configData: serialPort: '/dev/ttyS0' baudRate: 9600基于 v1beta1版本的设备管理 API，我们以 Kubernetes CRD 的形式将 Device Model 与 Device Instance 引入 KubeEdge 集群。如需要更多详细的信息，可以参考设备管 API 的 proposal 文件[1] 以及相关 PR[2]。在本系列的下一篇文章中，我们会对 DMI 数据面能力的支持进行详细的介绍。▍相关链接[1]  docs/proposals/device-crd-v1beta1.md：cid:link_1[2]  相关PR：device crd v1beta1 and API definition：cid:link_2【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：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/

KubeEdge 1.19.0版本现已正式发布。新版本在节点和设备方面引入了多个新特性，同时带来了全新版本的 Dashboard。 KubeEdge v1.19 新增特性：支持边缘节点上报 Event支持边缘节点 OTA 升级Mapper 支持设备数据写入Mapper 框架新增支持 OpenTelemetry全新版本 Dashboard  新特性概览  ▍支持边缘节点上报 EventKubernetes Event 作为集群中事件的报告，可以反馈节点、Pods 等集群资源的状态变化。在1.19版本中，EdgeCore 支持了边缘 Event 的上报，用户可以直接在云端通过kubectl get events 或者kubectl describe {resource_type} {resource_name} 获取边缘节点或者 pods 等状态。该特性在1.19版本中默认关闭，使用EdgeCore时执行--set modules.edged.reportEvent=true 或者如下修改 EdgeCore 配置参数并重启 EdgeCore。apiVersion: edgecore.config.kubeedge.io/v1alpha2 kind: EdgeCore featureGates:   requireAuthorization: true modules:   ...   edged:     reportEvent: true ...更多信息可参考：cid:link_3cid:link_4▍支持边缘节点 OTA 升级新版本在节点升级 NodeUpgradeJob 基础上新增了边端节点卡点确认和对镜像摘要的验证。卡点确认可以使节点升级下发到边缘节点后，在用户得到确认后才进行升级。镜像摘要验证可以确保在边缘节点待升级的 kubeedge/installation-pacakge 镜像是安全可靠的。在1.19版本中，我们可以通过 YAML 配置 NodeUpgradeJob 的 imageDigestGatter 来定义镜像摘要，value 用于直接定义摘要的值，registryAPI 用于通过 registry v2 接口获取镜像摘要，两者互斥，如果都没有配置则在升级时不进行镜像摘要的校验，样例：spec:   ...   imageDigestGatter:     value: ""     registryAPI:       host: ""       token: ""我们还可以通过 YAML 配置 NodeUpgradeJob 的 requireConfirmation 来定义是否要在边端进行确认操作，样例：spec:   ...   requireConfirmation: true当 requireConfirmation 设置为 true 时，在边端节点升级任务下发到边端后，任务状态会更新为 confirmation 状态等待边端发起确认命令后再继续进行升级。我们可以通过执行 keadm ctl 指令进行确认，以继续升级任务：keadm ctl confirm或者调用 Metaserver 接口进行确认，以继续升级任务：POST http(s)://localhost:<metaserver_port>/confirm更多信息可参考：cid:link_2cid:link_5cid:link_6▍Mapper 支持设备数据写入 Mapper 当前能够采集设备数据并上报，但在设备数据写入方面仍不完善。1.19版本在 Mapper-Framework 中增加了设备数据写入的能力，允许用户通过 Mapper 提供的 API 调用 device method，对 device property 完成数据写入。Device method API目前基于物模型的 v1beta1 版本的设备管理 API 包含 device property 的定义，在1.19版本中，新增 device method 的定义。Device method 指设备能够被外部调用的能力或方法，一个 device method 能够控制多个 device property 值。用户能在 device-instance 文件中定义 device method，通过 device method 完成 device property 的控制、写入。spec:   ...   methods:     - name: ""       description: ""       propertyNames:       - ""设备数据写入在1.19中改进 Mapper API 能力，新增 device method 调用接口。用户能够调用相关的接口获取某个设备包含的所有 device method，以及 device method 的调用命令，通过返回的调用命令发起设备写入请求。device method 的具体功能实现需要用户自行在 Mapper 的设备驱动层中完成。更多信息可参考：cid:link_7cid:link_8▍Mapper 框架新增支持 OpenTelemetry 当前 Mapper 向用户应用推送设备数据默认内置 HTTP 与 MQTT 两种方式，但仍存在部分应用无法直接以这两种方式进行推送。在1.19版本中我们在数据面引入 OpenTelemetry 观测框架，能够封装设备数据并向多类应用或数据库推送数据，例如 GreptimeDB、 Prometheus 等，增强 Mapper 数据面推送设备数据的能力。spec:   ...   properties:     - name: ""       pushMethod:          otel：           endpointURL: ""更多信息可参考：cid:link_9▍全新版本 Dashboard之前发布的 KubeEdge Dashboard，新版本使用主流的 Next.js 框架以及 MUI 样式库对其进行了重构。在新版本中我们重构并优化了近60个页面与组件，基于 KubeEdge 最新版本的后端 API，我们完善并增加了 Device 等相关功能页面，并在不影响原有功能的基础上将代码量减少至原先的四分之一。在这个过程中，我们整理完善了 Kubernetes 以及 KubeEdge 后端接口的 Typescript 类型定义，并将依赖的后端接口更新至最新版本，确保其与最新的 KubeEdge 兼容。更多信息可参考：cid:link_10 版本升级注意事项 下个版本（v1.20），EdgeCore的配置项edged.rootDirectory的默认值将会由/var/lib/edged切换至/var/lib/kubelet，如果您需要继续使用原有路径，可以在使用keadm 安装EdgeCore时设置 --set edged.rootDirectory=/var/lib/edged。从1.19版本开始，请在使用 keadm 安装 KubeEdge 时，使用--kubeedge-version 指定版本，--profile version 已废弃。▍致谢感谢 KubeEdge 社区技术指导委员会 (TSC)、各 SIG 成员对v1.19版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_1【更多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/

10月15日，云原生计算基金会（CNCF）宣布，KubeEdge正式成为CNCF毕业项目。KubeEdge由华为云开源并捐赠CNCF，是业界首个云原生边缘计算项目。正式从CNCF毕业，标志了KubeEdge的技术生态受到全球业界广泛认可，云原生边缘计算技术迈入了成熟新阶段。华为云CTO张宇昕表示：“KubeEdge自开源以来，获得了业界伙伴、用户的关注支持，在智慧交通、金融、能源、网联汽车、机器人、物流等行业领域都取得了突破性的创新实践，KubeEdge的毕业也将进一步推动企业的云原生数字化转型，释放更大的产业价值。华为云作为云原生技术的先行者与普及者，未来将继续与CNCF和社区合作，共同推动云原生产业的发展。”华为首席开源联络官、CNCF基金会董事任旭东表示：“华为多年来砥砺ICT产业创新和方案，深耕基础软件，并积极参与和发起开源项目，与伙伴、客户和开发者共创共建社区，致力于产业健康和商业成功。KubeEdge项目是华为在基础软件开源领域的又一重要贡献，推动了云原生技术在边缘计算场景中的创新实践，为多个行业的数字化转型提供了关键支撑。未来，华为将持续开源创新，与全球伙伴共同构建繁荣的产业生态。”​华为云坚持开源开放引领云原生新兴领域KubeEdge云原生边缘计算项目于2018年11月由华为云宣布开源，它完整地打通了边缘计算中云、边、设备协同的场景，为用户提供一体化的云边端协同解决方案。KubeEdge将Kubernetes原生的容器编排和调度能力扩展到边缘，提供边缘应用管理、云边元数据同步、边缘设备管理等能力，同时也在边缘网络、边云协同AI、边云协同机器人管理等创新方向持续创新实践。秉承开源开放的治理模式和协作理念，KubeEdge社区迅速发展，目前拥有来自贡献者覆盖全球超过35个国家地区，110家组织。华为云是全球云原生开源技术的推动者和领导者。华为云长期拥有CNCF项目技术委员会、治理委员会成员及核心Maintainer等多个席位，还是CNCF唯一的中国创始成员，并在2024年获得了全球顶级开源组织CNCF中国本土唯一TOC委员席位（全球共11席）。多行业、多场景商业落地使能产业升级华为云以KubeEdge为核心，构建了智能边缘平台IEF（Intelligent EdgeFabric），当前已广泛应用于智能交通、智慧能源、智慧零售、智慧园区、汽车、航空航天、智能物流、金融、化工、区块链等各领域。华为云以其云原生边缘的独特优势，得到众多客户伙伴的高度认可。边缘计算是中国铁塔将“通信塔”升级为“数字塔”关键，能让全国210万+的铁塔快速实现升级。中国铁塔视联平台从提出到成熟经历多个阶段，在发展阶段IEF以其异构兼容、云边协同能力支撑了铁塔更经济性地发挥边缘计算、调度云边协同，为铁塔更好地服务于广大民生夯实了基础。蔚来汽车战略新业务数字系统架构师蒋旭辉：“KubeEdge作为专为云边协同开发的平台，可以有效解决汽车领域应用云原生技术栈面临的算力稀缺、海量边缘节点、运行环境差异等挑战。我们经过大量调研和选型工作后，以KubeEdge为核心构建蔚来整套车云协同平台，并首次用于量产车型，带来开发交付效率、团队协作等方面的显著提升，并将实现超大规模的边缘汽车管理。”顺丰科技边缘云容器负责人程庞钢：“顺丰科技在物流领域深耕多年，KubeEdge如同我们迈向智能化的得力助手。从物流分拣的高效运作到运输环节的全生命周期处理，KubeEdge所提供的边缘计算能力助力我们打造更智慧、更高效的物流体系。”随着企业用云广度和深度的不断拓展，华为云也不断拓展和升级云原生服务应用，在云原生Al基础设施、Serverless架构、多云和混合云战略、云边端协同等领域持续投入，以技术革新为驱动，打造业界领先的云原生解决方案。华为云连续八次中国容器软件市场份额No.1，分布式云原生UCS、云容器引擎CCE、Serverless容器CCE Autopilot和CCI等代表产品持续引领全行业智能化发展趋势，为企业数智化转型提供强大动力。【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 : https://kubeedge.ioGitHub地址 : cid:link_2Slack地址 : https://kubeedge.slack.com邮件列表 : cid:link_1每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/