dge 1.18.0 版本现已正式发布。新版本在稳定性、安全性等方面有了显著的提升，同时持续在易用性等方面做了增强。KubeEdge v1.18.0 新增特性：RouterManager 支持高可用CloudCore 云边通道鉴权增强支持设备状态上报keadm 能力增强封装 Token，CA 和证书操作，提高扩展性升级 K8s 依赖到 v1.29  新特性概览  ▍RouterManager支持高可用针对 CloudCore 采用高可用部署时，RouterManager 无法准确路由的问题，在新版本中，对 RouterManager 在高可用部署时做了优化与增强，云端发往边缘的自定义消息将会被路由到对应 EdgeNode 所连接的 CloudCore中，并正确下发到对应的 EdgeNode。同时考虑了边界情况，在转发过程中，如果 EdgeNode重连到其他 CloudCore 时，消息将会被重新转发到正确的 CloudCore 中。更多信息可参考：cid:link_1cid:link_2▍CloudCore云边通道鉴权增强 CloudCore 作为连接边缘节点和 Kube-APIServer 的桥梁，需要限制边缘节点对集群资源的访问权限。在新版本中，我们对云边通道的安全性进行了增强，CloudHub 会识别消息发送方并校验其是否有足够的权限，从而限制边缘节点操作其他节点的资源。v1.18.0 目前已支持 node authorization 模式。该特性引入了如下配置参数，在新版本中默认关闭，开启如下开关即可启用该特性。apiVersion: v1 data: cloudcore.yaml: ... modules： cloudhub: authorization: // optional, default false, toggle authoration enable: true // optional, default to false, do authorization but always allow all the requests debug: false // required, an authorizer chain authorizers: // node authorization mode - node: ebable：true ... 为了安全启用此特性，可以先开启 debug。当鉴权失败时，CloudCore 只记录日志，但请求仍会正常处理。更多信息可参考：cid:link_3cid:link_4▍支持设备状态上报 设备有其自身的状态，比如在线、离线、异常等。1.18.0版本支持了设备状态上报的能力。该特性在 Mapper-Framework 已经默认实现，用户基于 Mapper-Framework 生成自己需要的 mapper，即可使用。状态上报成功后，可通过 device 的资源查看结果：apiVersion: devices.kubeedge.io/v1beta1 kind: Device ... spec: status: lastOnlineTime: "2024-07-30T17:55:49Z" state: ok twins: - observedDesired: ....更多信息可参考：cid:link_5cid:link_6cid:link_7▍Keadm能力增强 在旧版本中，使用 keadm join 安装 EdgeCore 只能指定部分参数的配置。在最新版本中，我们对 EdgeCore 的配置流程进行了显著优化。现在，您无需等待节点接入完成,手动编辑 edgecore.yaml 配置文件，再重启 EdgeCore。通过在 keadm join 命令中使用新增的 --set 参数，您可以在节点加入时直接设置配置，就像使用 Helm 配置 values.yaml 一样便捷。这一改进大大简化了配置管理过程，提高了效率。下列指令是一个开启 MetaServer 的样例：keadm join --set modules.metaManager.enable=true,modules.metaManager.metaServer.enable=true,modules.metaManager.remoteQueryTimeout=32更多信息可参考：cid:link_8https://github.com/kubeedge/kubeedge/pull/5564 ▍封装Token，CA和证书操作，提高扩展性在本版本中，我们对 Token 和 Certificate 的处理进行了彻底的整理和优化。原先分散在代码各处的处理逻辑现在已被集中管理，显著降低了维护成本。Token 处理已被集成到一个统一的工具包中，而 Certificate 的处理则通过接口抽象化，不仅支持自建 CA 流程，还适配了通过 Kubernetes CSR 申请 Certificate 的流程。此外，我们的设计允许未来轻松扩展以支持更多类型的私钥和客户自定义的 Certificate。此次重构不仅提升了 Token 和 Certificate 业务代码的可读性和可维护性，而且保持了对外接口的完全向下兼容性，确保了现有系统的无缝升级。更多信息可参考：cid:link_9cid:link_10▍升级K8s依赖到v1.29新版本将依赖的 Kubernetes 版本升级到 v1.29.6，您可以在云和边缘使用新版本的特性。更多信息可参考：cid:link_11▍致谢感谢 KubeEdge 社区技术指导委员会(TSC)、各 SIG 成员对 v1.18.0 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_0扫码回复“Mentorship”进入技术交流群

LFX Mentorship计划，由Linux Foundation组织，从19年开始为CNCF各个开源社区中的开发人员持续提供带薪实习和指导。往年已获10w+申请，发起800+课题，毕业600+实习生，发放超过230万美金报酬。2024年秋季申请时间为7月31日-8月13日，远程实习将从 9 月 3 日开始为期三个月。参与到LFX Mentorship计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为$3000美金，约合￥20000人民币）。今年KubeEdge社区在LFX Mentorship计划中准备了多个课题，感兴趣的读者可于8月13日前到官方平台申请:https://mentorship.lfx.linuxfoundation.org/  KubeEdge社区介绍  KubeEdge社区已经连续4年参与LFX Mentorship计划，过去已为学员提供20+个项目。KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目。在GitHub获得7.6k+Stars和2.1k+Fork，吸引了全球来自30+国家的100+贡献组织及16万+开发者。近年来，KubeEdge社区持续开拓创新，完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式、开源业界首个分布式协同AI基准测试Ianvs。在LFX Mentorship 2024秋季计划，KubeEdge期待再次和计算机领域新生力量一起，开拓数字未来。  面向对象  秋季计划申请者需在2024年8月13日前在LFX官网完成Mentee注册及项目申请。若被接收作为Mentee，您将能在开源社区经验丰富、积极贡献的Mentor指导下为开源项目做出贡献。依据官方规定[1]，对Mentee的申请者有以下要求:计划开始时至少年满18周岁所在单位和组织不禁止该实习未参加另外的Linux Mentorship计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)并非社区中高于最低限度贡献成员（如Maintainer、Recurring Contributor）满足具体所属项目中提及的其它前置需求  课题参与方式  根据官方安排 [2]，LFX Mentorship 2024年秋季活动流程如下：Mentee注册与项目申请 July 31 - Aug 13, 5:00 PM PDT申请者评审及人事工作 Aug 14 - 27, 5:00 PM PDT实习启动及任务发放 Sept 9 (Week 1)中期考核及首次津贴支付 Oct 15 (Week 6)结项考核、实习生报告提交，最终津贴支付批准 Nov 26, 5:00 PM PST (Week 12)活动结束 Nov 29申请者需要在8月13日前完成Mentee注册和项目申请，流程详见[3]：https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply实习申请结果预计将在 9 月 3 日通知到申请人。主线开发日期为2024年9月9日 – 11月26日，全程线上协作，无需线下参与。结项需要在2024年11月26日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。  KubeEdge课题  最后，向各位申请者推荐CNCF KubeEdge社区下列课题：▍KubeEdge: Decouple the node cooperation ability and batch management ability of the edgeapplication课题描述：EdgeApplication可以通过节点组来override应用的配置(如副本数、镜像、命令和环境)，同时节点组内的 pod 流量是闭环的(由 EdgeApplication 管理的Deployment共享一个 Service)。但是在实际场景中，需要批量操作的节点范围与需要相互协作的节点范围并不一致。因此我们需要有一种解决方案来解耦 EdgeApplication 的节点协作能力和批量管理能力。预计输出件：需求方案实现EdgeApplication可以被节点组或者指定lable的节点override解决流量闭环 前置技能：Golang, Kubernetes, KubeEdge课题导师：WillardHu | wei.hu@daocloud.ioElias Wang | wangbincheng4@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/89fe7f6c-052b-4597-9ba3-c016858b1835Github Issue：cid:link_1▍KubeEdge: Elastic Inference for Deep Learning Models Using KubeEdge课题描述：人工智能的快速发展使得深度学习模型在各个领域得到广泛应用。然而，模型推理任务所需资源可能会显著波动，尤其是在高峰期，可能会给系统的计算能力带来挑战。为了应对这种不同的负载需求，我们提出了一种利用 KubeEdge 和 Pod 水平自动扩缩(HPA) 实现推理任务动态扩缩的弹性推理解决方案。通过利用 KubeEdge，我们可以在不同的边缘设备和云资源之间分配推理任务，实现资源利用和任务处理的效率。预计输出件：基于 KubeEdge 实现弹性扩缩 AI 推理示例基于 KubeEdge 和 Sedna 实现联合推理任务的弹性扩缩的开发和输出示例输出Blog前置技能：KubeEdge，Sedna部署及管理Kubernetes的经验，包括配置及调优HPA机制开发与调优深度学习模型的知识Go与Python的编程经验课题导师：ming tang  | ming.tang@daocloud.ioShelley Bao | baoyue2@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/1f58cbe5-fe3a-4d0f-9875-b1725ecac223Github Issue：cid:link_2▍KubeEdge: Multimodal Large Model Joint Learning Algorithm: Reproduction Based on KubeEdge-Ianvs课题描述：KubeEdge-Ianvs目前主要专注于单数据模态的云边协同学习(训练和推理)。然而，诸如自动驾驶汽车等边缘设备通常会捕捉包括GPS、LIDAR和摄像头数据在内的多模态数据。单一模态的学习已经无法满足边缘设备的精确推理需求。因此，该项目旨在将主流的多模态大模型联合学习算法整合到KubeEdge-Ianvs的云边协同学习中，提供多模态学习能力。预计输出件：使用 KubeEdge-Ianvs 在边缘部署多模态大语言模型的基准测试套件修改和调整现有的边-云数据收集接口，以满足多模态数据收集的需求基于 Ianvs 实现一个多模态大语言模型 (MLLM) 基准测试套件复制主流的多模态联合学习(训练和推理)算法，并将其集成到 Ianvs 单任务学习中(可选) 在 Ianvs 的至少一种高级范式(终身学习、增量学习、联邦学习等)中测试多模态联合学习的有效性。前置技能：TensorFlow/Pytorch, LLMs, KubeEdge-Ianvs课题导师：Chuang Hu | hchuchuang@gmail.com)Zimu Zheng | zimu.zheng@huawei.com)课题链接：https://mentorship.lfx.linuxfoundation.org/project/d5d315c7-aaee-46ee-895e-a0f9e6ffed4bGithub Issue：cid:link_4▍KubeEdge: Cloud-edge collaborative speculative decoding for LLM based on KubeEdge-Ianvs课题描述：大语言模型(LLM)的自回归解码模式决定了它只能串行解码，这限制了其推理速度。可以使用推测式解码技术结合草稿模型并行解码LLM，从而在不损失准确性的情况下提高LLM的推理速度。然而，LLM的推测式解码技术并没有考虑在云边协同环境中的应用。本项目旨在基于开源的云边协同分布式机器学习平台KubeEdge-Ianvs实现云边协作推测式解码，进一步提高云边环境下LLM的推理速度。预计输出件：基于 KubeEdge-Ianvs 实现一个云边协同推测解码的示例。(可选) 提出一种更加高效的云边协同推测解码算法。前置技能：KubeEdge-Ianvs, LLM, Pytorch, Python课题导师：Shijing Hu | sjhu21@m.fudan.edu.cnZimu Zheng | zimu.zheng@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/bfa8251f-a975-4e07-8e7a-915df3518551Github Issue：cid:link_5▍KubeEdge: Integrate KubeEdge, Sedna, and Volcano for Efficient Task Scheduling课题描述：KubeEdge 和 Sedna 已经实现了云边协同训练和协同推理的能力。我们旨在与更多社区进行探索和合作，提供更强的 AI 能力。本项目旨在通过在KubeEdge与Sedna的云边协同框架内集成 Volcano实现高性能调度，从而推动分布式 AI 和边缘计算的发展。预计输出件：使用 KubeEdge 和 Sedna 成功部署训练任务，并提供example。在 Sedna 中集成 Volcano 实现高性能的训练任务调度。（可选）在 KubeEdge 中成功部署 Kubeflow，并完成训练任务的部署，输出一篇Blog前置技能：KubeEdge, KubeEdge-Sedna, Volcano课题导师：Shelley Bao | baoyue2@huawei.comFisher Xu | fisherxu1@gmail.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/49fa6dab-9cb5-4889-bbeb-66c4a5545f8fGithub Issue：cid:link_3如果对课题内容有任何问题，欢迎在GitHub仓库提交Issue或者添加社区小助手微信向社区提问。今年秋季，KubeEdge社区期待在 LFX Mentorship 见到您！Reference[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: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply扫码回复“Mentorship”进入技术交流群

华为云云原生团队欢迎你的加入！

物联网与边缘算力飞速发展，如何实现边云协同AI，让AI赋能边侧各行各业？今天16:30，华为云专家直播交流云原生边缘计算核心技术与创新布局，为你轻松匹配多行业、多场景智能化升级的云边端协同解决方案！▍直播主题边云协同新场景，KubeEdge架构设计与边缘AI实践探索▍直播时间2024.07.24（周三） 16:30-18:00▍直播简介本期直播我们将解读业界首个云原生边缘计算框架KubeEdge的架构设计，如何实现边云协同AI，将AI能力无缝下沉至边缘，让AI赋能边侧各行各业，构建智能、高效、自治的边缘计算新时代，共同探索智能边缘的无限可能！▍讲师介绍 - EliasCNCF KubeEdge社区核心成员，华为云云原生团队研发工程师，在云原生边缘计算、云原生调度、物联网等领域有深入的研究和实践经验，目前负责KubeEdge社区设计开发及生态构建，主导基于KubeEdge的云原生边缘设备管理等开发工作，保持KubeEdge技术创新和竞争力。▍直播福利：福利1：互动有礼官网直播间发口令“华为云 DTSE”抽华为云定制T恤。福利2：有奖提问直播过程中提问，评选优质问题送华为云定制双肩包。更多福利：加入微信交流群直播期间扫码入群，解锁更多隐藏福利哦~扫码观看直播

近日我们很高兴的宣布 Kmesh 发布了 v0.4.0 版本。感谢社区的贡献者在两个多月的时间里做出了巨大的努力，使得 Kmesh 取得功能完整度、稳定性、可靠性的多重提升。当前 Kmesh 相较业界其他方案已经具备显著的资源开销小和低延时等优势，后续我们会继续在核心功能和大规模稳定性等方面重点投入，争取尽快达到 GA（生产可用）。▍Kmesh 背景回顾尽管服务网格已经在过去几年持续曝光，获得了很大的知名度，但是 Sidecar 模式在资源开销、数据链路时延等方面对工作负载产生了很大的影响。所以用户在落地选型时，还是比较谨慎。除此之外，Sidecar 模式还有一个比较大的缺点是 Sidecar 与业务容器生命周期完全绑定，无法做到独立升级。因此 Kmesh 创新性的提出基于内核的 Sidecarless 的流量治理方案，将流量治理下沉到内核以解决 Sidecar 模式用户关心的一些问题。eBPF 技术非常适合四层的流量治理，加上可编程内核模块可以进行七层的流量编排。Kmesh 最早完全通过 eBPF 和内核模块进行 L4-L7 的治理。Kmesh 采用随流治理的策略，不会额外增加服务通信过程中的连接跳数，相比 Sidecar 模式，服务之间的通信连接数从三条减少到一条。为了丰富七层协议的治理能力，今年 Kmesh 增加了一种新的治理模式 Workload：远端流量治理，利用 ebpf 将流量转发到 kmesh-waypoint，进行高级的七层协议治理，这是一种更加灵活的分层治理模型，能够按需满足不同用户的需求。目前 Kmesh 基于 Istio 控制面，提供了新的服务网格数据面引擎，详细的架构如下：▍Kmesh v0.4版本关键特性解析IPv6支持以前 Kmesh 只支持采用 IPv4 通信的服务治理，但是当前 Kubernetes 集群已经默认支持双栈集群，我们不能假设服务只采用 IPv4 协议通信，因此在 0.4 版本中我们适配了 IPv6 的协议特征，支持了 IPv6 的服务治理。值得注意的是：即使在 IPv4 集群中，Java 应用在通信时，默认采用 IPv6 地址族进行通信，所以如果需要采用 Kmesh 对 Java 服务进行治理，请一定要升级 Kmesh 0.4 版本。IPv6 目前只在 Workload 模式下完整支持。请期待下一个版本中，Kmesh 本地模式（流量治理完全下沉内核）也将完全支持 IPv6 协议族。细粒度的流量治理v0.4 版本，除了按照 Namespace 进行服务的纳管以外，我们还支持了按照 pod 粒度进行流量的纳管治理。一定程度上增加了灵活性，满足了客户只针对一个命名空间下的特定工作负载进行治理的需求。特定 Pod 纳管kubectl label pod istio.io/dataplane-mode=kmesh -n {namespace}整个 Namespace 纳管kubectl label ns istio.io/dataplane-mode=kmeshKmesh 通过检查 Pod 及 Namespace 上面标签，在不同的组件中进行 Pod 的纳管。场景一：Pod 创建时已经打上了标签，那么 kmesh 通过 Kmesh-cni 在容器网络初始化的时候通知 kmesh eBPF 程序进行纳管，保证工作负载启动之前完成纳管，不会遗漏任何数据包的治理。场景二：在 pod 启动之后，再为 Pod 打上 istio.io/dataplane-mode：kmesh标签，那么 Kmesh-daemon 会监听 Pod 事件，检查到标签更新后，通知 kmesh ebpf 程序进行纳管。场景三：去掉 istio.io/dataplane-mode：kmesh 标签，允许 Pod 不被 Kmesh 纳管。这种纳管方式更加灵活，也方便了用户在发现服务访问故障之后，快速进行故障隔离，定位定界。支持集群外部服务治理在服务网格中，我们可以通过 ServiceEntry 定义网格外部服务，一般为 DNS 类型。apiVersion: networking.istio.io/v1kind: ServiceEntrymetadata: name: external-svc spec: hosts: - news.google.com location: MESH_EXTERNAL ports: - number: 80 name: http protocol: HTTP resolution: DNS对于这种服务，控制面为其生成 STRICT_DNS 类型的 Cluster, endpoint 地址为域名。eBPF 程序不能进行 DNS 解析，因此不能根据域名进行 DNAT。在 Kmesh 0.4 版本中，我们新增了 DNS 解析模块，在用户态首先进行 DNS 解析，然后重写 Cluster 将域名替换成IP地址，再刷新给 eBPF 程序进行 DNAT。典型工作原理如图所示：DNS 类型服务的治理，大大拓展了 Kmesh 服务治理的范畴，由 Kubernets 集群，扩展到外部服务。基于 eBPF 的轻量化可观测可观测性是服务网格中很重要的基础能力，对于了解数据面通信的状态具有重大意义，可以基于监控进行告警。Kmesh 采用了分层观测架构，在治理数据面，内核中存在大量可用于观测的指标数据，Kmesh 通过 eBPF 以极低的代价将这些微观、细粒度指标收集起来，并支持链路级、Pod 级等多维度信息采集；并通过 ringbuf map 上报给 kmesh-daemon 组件，daemon 中根据实时订阅的观测数据，再组织加工成用户可理解的可观测信息。当前 Kmesh 已支持以下四种监控指标，每一种指标都通过标签标识源和目的应用，用户还可以配置 Prometheus 进行采集。kmesh_tcp_connections_opened_totalkmesh_tcp_connections_closed_totalkmesh_tcp_received_bytes_totalkmesh_tcp_sent_bytes_total接下来，社区将继续丰富metrics、access log等观测的采集，并完善与Prometheus、Grafana 等观测平台的对接。在线日志级别调整动态日志级别调整对于故障诊断具有很大的帮助，早期的版本，如果要分析 bpf 数据面的问题，获取更详细的定位日志，你需要修改代码并重新构建镜像，整个过程非常低效；新版本中被彻底改善，我们支持了在线日志级别调整，用户通过 Kmesh 运维命令，可实时调整用户态 Kmesh-daemon 和 bpf 程序的日志级别。使用样例如下：#Adjust kmesh-daemon log level (e.g., debug | error | info)kubectl exec -ti -n kmesh-system kmesh-6ct4h -- kmesh-daemon log --set default:debug#Adjust kmesh eBPF data plane log levelkubectl exec -ti -n kmesh-system kmesh-6ct4h -- kmesh-daemon log --set bpf:debug除了新特性的加入，v0.4 版本在可维护性、大规模性能、可测试性等方面也做出了诸多改进。▍大规模集群支持生产环境中，根据部署业务的不同，集群规模可大可小，对于 Kmesh 来说，大规模集群更能展现 Kmesh 架构的优势，经过评估，Kmesh 需要支持 5000 服务，10万 pod 级的集群管理，以满足绝大多数生产使用诉求。对于远端模式，Kmesh 修改了 bpf map 的创建模式，支持按需申请 bpf map 中的记录，这样我们可以很容易的支持大规模集群，且不引入冗余的内存开销；对于本地模式， bpf map 更新慢的问题一直困扰着我们，原本刷新一条规则需要几十甚至上百毫秒，0.4 版本，我们优化了 map-in-map 的初始化逻辑，通过空间换时间的策略，消除了 map-in-map 的刷新耗时，将规则的刷新降低到 ms 以内，这为后续支持大规模奠定了坚实的基础。▍E2E测试Kmesh 当前正处于快速膨胀的成长期，新特性正源源不断的加入到 Kmesh 中，如何保障社区的整体质量，确保 Kmesh 平稳有序的向前发展是社区面临的重要挑战；虽然社区已经有 UT test 做功能防护，但我们还缺少黑盒视角、集群级的功能防护；为此社区引入了 E2E 测试框架，并将其部署在 PR 门禁中，这样，每个新 PR 提交时，就可以及时检查新提交对于已有功能的影响，这对于 Kmesh 非常有用，当前 E2E 测试框架已经部署上线，并增加了部分测试用例，后续将不断丰富测试集，也欢迎社区的小伙伴们共同完善Kmesh测试防护网。详细的运行E2E测试请参考cid:link_2en/docs/developer/e2e-guide/▍加入社区贡献我们希望借助在 Istio 社区长期的积累，始终以开放中立的态度发展 Kmesh，打造 Sidecarless 服务网格业界标杆方案，服务千行百业，促进服务网格健康有序的发展。Kmesh 当前正处于高速发展阶段，我们诚邀广大有志之士加入！参考链接[1] Kmesh Website：cid:link_2[2] Kmesh Release v0.4.0：cid:link_1[3] 可观测性设计：cid:link_0添加小助手k8s2222回复Kmesh进入技术交流群

▍背景通常情况下，K8s集群的容器网络平面和外部网络是隔离的，外部网络无法直接访问到集群内部的容器业务，如何为容器提供并管理统一的外部流量入口?社区提供的常见方式是使用Nodeport Service，Loadbalancer Service，Ingress等K8s资源对象来暴露集群内部的容器原生应用。Service对象提供了四层负载均衡能力，Ingress对象则提供了面向应用层访问（HTTP/HTTPS等）的七层负载均衡能力。而随着云原生架构在企业内的普遍落地，容器作为云原生微服务应用的载体，需要面对更多挑战，如面对微服务的复杂组网，业务请求在云服务之间转发往往需要做源地址转换而导致流量分发损耗；游戏类、电商抢购类等业务在短时间内会进行频繁扩缩容，必须应对高并发的网络流量；网关入口流量应对互联网的安全攻击，如灰产、异常流量，需提供流量安全防护能力；此外，支持更加复杂的路由规则配置、多种应用层协议（HTTP、HTTPS、GRPC等）、应用蓝绿发布、流量可观测性等七层高级转发能力也逐渐成为了云原生应用的普遍诉求。Ingress Nginx，Ingress Kong，Traefik等开源社区方案虽然提供了丰富的七层流量治理功能， 但对于关键生产业务上云，企业在选择Ingress方案时,除了考虑功能性,还需要充分权衡安全性、可维护性和可靠性等方面的需求，以找到最佳平衡点。专业的云服务提供商提供托管的Ingress解决方案，能够较好的应对这些挑战。华为云CCE服务提供了基于应用型负载均衡ELB（Elastic Load Balance）的全托管免运维的企业级 Ingress 流量治理，让用户轻松应对云原生应用流量管理。▍ELB Ingress 介绍在K8s集群中，容器网络平面通常是独立于集群主机网络的一个隔离的网络平面，工作负载在滚动升级或者重新调度后容器的地址会有变化，这就带来一个问题：如何实现某组Pod的服务发现，并提供固定的外部访问入口？Service和Ingress对象就是K8s中实现集群内外应用统一访问入口的一种机制。K8s社区对集群外部的流量暴露提供了三种方式：Nodeport Service、Loadbalancer Service、Ingress，前两者Service对象主要提供集群四层流量入口，Ingres对象提供七层流量治理能力。两者相互配合，共同实现K8s集群应用的对外访问机制。如下图一所示，客户端通过Ingress管理的负载均衡器，访问Ingress申明的路由，由负载均衡器将流量经过后端Service导入至后端容器。ELB Ingress是华为云CCE服务提供的七层流量治理功能，基于社区标准Ingress API实现，提供高可用、高性能、高安全、多协议的全托管免运维负载均衡能力。同时具备弹性能力，在流量突发时支持快速扩展计算资源，支持千万级并发连接，百万级新建连接，是云原生应用流量治理的理想选择。▍ELB Ingress工作原理ELB Ingress部署于CCE集群的master节点上，与ELB实例对接，可将Ingress申明的容器后端地址、转发策略、路由等信息配置至ELB实例，并且支持动态更新。图二是基于Nodeport中转的ELB Ingress工作流图，CCE Standard集群使用该方案的原理如下：用户为集群创建Ingress资源，在Ingress中配置流量访问规则，如负载均衡器实例、URL路由、SSL证书等监听信息，以及访问的后端Service等，控制器通过标签选择器选中工作负载，将工作负载所在节点和Nodeport端口挂载至负载均衡器实例的后端；Ingress Controller监听到Ingress资源发生变化时，会根据其中定义的流量访问规则，在ELB侧重新配置监听器以及后端服务器路由;用户通过ELB访问应用程序，流量根据ELB中配置的转发策略转发到对应的Node节点，再经过Nodeport二次转发访问到关联的工作负载(Nodeport转发机制参见k8s官方文档说明)。该方案中流量经过节点、IPTables/IPVS规则多次转发，网络性能存在损耗。在大流量场景下，网络转发效率、网络连通速度的挑战尤为突出。为此，我们推出了基于CCE Turbo集群的网络加速方案：容器直接使用VPC网络实现直通容器的ELB Ingress，将原有的“容器网络 + 虚拟机网络“两层模型简化为一层。如图三所示，集群中的Pod IP直接从VPC中分配，支持北向ELB直通容器，外部流量可以不经过节点端口转发直接访问集群中的Pod，达到流量分发零损耗的效果。▍ELB Ingress流量治理核心优势ELB Ingress基于原生Kubernetes Ingress，通过声明式API指定Ingress的路由、对接的后端服务，或者通过Annotation配置监听侧的高级选项，由系统保证最终一致性。ELB Ingress为开发者和运维人员提供了极大的开发灵活性和维护便利性，其核心优势包括：高吞吐、高可用、高弹性ELB Ingress搭配独享型ELB实例，最高支持2千万并发连接；通过完善的健康检查机制，保障业务实时在线，支持多可用区的同城双活容灾，无缝实时切换；弹性规格ELB实例支持根据流量负载自动弹性扩缩实例规格，适用于业务用量波动较大的场景，例如游戏、视频等行业，能满足瞬时流量同时成本最小化。高安全性ELB Ingress提供了端到端的全链路安全策略，如下图四是外部流量经过ELB访问CCE Turbo集群的简单示例：在访问端可配置接入WAF引擎检测并拦截恶意攻击流量，而正常流量转发至后端云服务器。通过Ingress的Annotation配置可轻松为ELB实例配置自定义安全策略，例如设置黑白名单，双向认证等。从ELB转发至后端也支持HTTPS加密信道，进一步增强整体安全性。可移植性完全兼容社区Ingress语义，从开源Nginx Ingress等方案迁移过来仅需改造annotation即可轻松适配。可观测性云监控可以按时间轴查看ELB的网络流量和访问日志，动态分析并告警潜在风险；云审计可以实时监控ELB资源更新日志，针对风险动作实时告警，动态监控云上资源安全；Ingress Controller也支持丰富的普罗监控指标，如接口调用时延，reload次数等。免维护性ELB Ingress组件运行在集群的Master节点，用户无需关注运维问题，组件在集群升级时会自动更新，且对业务无感。▍ELB Ingress流量治理核心功能在社区基础功能之上，华为云ELB Ingress在负载均衡、路由规则、流量控制、安全性和可观测性等方面都有较大增强，满足了更复杂的生产环境需求。下面介绍ELB Ingress流量治理核心功能：灰度发布灰度发布是业界常用的版本升级平滑过渡的一种方式。在版本升级时，先让部分用户使用新版本，其他用户继续使用老版本。待新版本稳定后，再逐步扩大新版本的使用范围，直到所有用户流量都迁移到新版本上。这样可以最大限度地控制新版本发布带来的业务风险，降低故障影响范围，同时支持快速回滚。我们提供了基于Header/Cookie/Weight的灰度发布策略，前两种策略通过将用户分成若干组，在不同的时间段内逐步引入新版本，最终扩大新版本的影响范围；基于Weight的策略则是通过控制新版本的权重，在不同时间段内逐步增加新版本的流量比例，直到完全替代旧版本。高级转发策略随着云原生应用组网的日益复杂，传统的基于路由转发的七层流量治理已经难以满足需求。我们提供的高级转发策略可以很好地解决传统方案面临的局限性：基于请求头的负载均衡：根据客户端请求头的不同值，将请求分配到不同的后端服务器。HTTP重定向到HTTPS：系统自动将HTTP监听器流量转发至HTTPS监听，提升网站安全性，防止内容篡改等。URL重定向和重写：支持将URL永久或临时映射到另一个URL。同时，支持正则表达式匹配和实现不同路径的重写规则。慢启动在应用滚动升级时，ELB Ingress会自动更新负载均衡器后端，并且根据后端容器实例副本数自动设置后端权重。但是，在后端健康检查通过后的上线过程中，可能面临流量突增，导致后端容器的CPU或内存资源瞬间高负荷，从而影响业务稳定性。在开启慢启动模式后，系统可以在指定时间内，逐步将流量导入到目标容器后端。这样可以缓解业务容器突增的流量压力，保护系统免受过度负载的影响，实现优雅过渡。▍小结华为云CCE服务的ELB Ingress基于华为云应用型负载均衡ELB（Elastic Load Balance）提供强大的Ingress流量管理能力，兼容Nginx Ingress，具备处理复杂业务路由和证书自动发现的能力，支持HTTP、HTTPS和GRPC等协议，满足在云原生应用场景下对超强弹性和大规模七层流量处理能力的需求。后续我们还将发布系列文章，详细介绍基于ELB Ingress的流量管理最佳实践，欢迎各位读者继续关注。相关链接：华为云云容器引擎CCE服务路由概述：cid:link_3Ingress官方文档：cid:link_24步快速使用云容器引擎01注册账号，并登录CCE控制台点击注册帐号，并授予IAM用户相应的权限。登录CCE控制台帐号无需授权即可拥有所有权限，由帐号创建的IAM子用户需要授予相应的权限才能使用CCE，具体请参见权限管理。02 创建集群如果您需要创建普通Kubernetes集群，请参见快速创建Kubernetes集群。03 部署工作负载通过镜像或编排模板创建工作负载（应用）。· 创建无状态工作负载（Nginx）· 部署有依赖关系的WordPress和MySQL04 生命周期管理查看部署后工作负载的状态和日志信息，对工作负载进行相应的升级、伸缩和监控等。具体请参见管理工作负载和任务

数之联简介成都数之联科技股份有限公司成立于2012年，由985&211高校教授领衔，专注于大数据与人工智能技术的研发和应用。公司面向“智能化改造”和“数字化转型”这两大当前企业发展的重要战略方向，提供自主安全可控的人工智能基础设施与软硬一体的高端装备，助力客户提升管理和服务的智慧化水平，实现降本提质增效。▍行业背景在液晶面板生产领域，由于多种因素，产品常出现不良品。为此，关键工艺节点后引入了自动光学检测（AOI）设备，通过光学原理检测常见缺陷。然而，现有 AOI 设备仅识别缺陷有无，需要人工分类和识 别假缺陷，这一过程耗时且影响生产效率。数之联的客户企业，某面板龙头企业，引入自动缺陷分类系统（ADC）以提高判定准确性并减轻劳动强度，使用深度学习技术自动分类 AOI 输出的缺陷图片，并筛除误判，从而提高生产效率。客户企业率先在一个工厂引入 ADC，后续在其他工厂推广，节省人力资源，提高判定效率。尽管如此，由于工艺复杂和供应商差异，现场建设呈现出割裂和分散管理的趋势，给数据共享和运维带来困难。为解决这些问题，客户企业启动了工业智能检测平台的建设，该平台利用人工智能技术，标准化智能检测并提高生产效率和良率。工业智能检测平台工业智能检测平台 将 ADC 作为核心，扩展至模型训练和检测复判，实现“云”（管理+训练）+“边”（推理）+“端”（业务）的一体化方案，旨在通过标准化平台提高生产质量和数据价值。建设范围包括资源共享中心、现地 训练和边侧推理等子平台，将在若干工厂实施。工业智能检测平台架构图项目目标是实现现地 ADC 上线、资源共享和云边端标准化，以减轻运维负荷、提升标准。工业智能检测平台旨在通过规范化和标准化 客户企业 全集团的 ADC 系统，为后续 ADC 建设提供样本和模板，降低成本和周期，提高生 产和质检效率以及产品良率。包含系统管理员、资源配置员等用户角色，并涉及 ADC 推理、模型训练、数据共享等信息流，以及云端协同功能，确保 ADC 的自动缺陷分类生产过程，并提高模型和缺陷图片的 利用率。▍产品与技术实现一、集群管理不同现地可将对应的 K8s 集群注册至中心云系统，中心云系统对多个现地的集群进行管理。集群管理我们选择了 PULL 模式。为了降低 OP 的操作成本，我们在中心云提供了 step-by-step 的注册流程。引导安装 karmada-agent。使用 karmadactl token create 控制面生成 token。引导注册 karmadactl register 。在成员集群中编辑由 karmadactl register 创建的 deploy/karmada-agent 以确保其可以访问该成员集群的 kube-apiserver。二、使用聚合层 API通过 karmada-aggregator 组件提供的集群统一访问能力，我们可以在中心云实现可视化大屏等需要聚合成员集群的数据的功能。通常我们用 Service 来暴露 Java 实现的功能，并用 Java Fabric8 等客户端调用 kubectl get --raw 来实现调用：/apis/cluster.karmada.io/v1alpha1/clusters/%s/proxy/api/v1/namespaces/%s/services/%s/proxy/%s1、集群监控针对在线的集群，中心云系统可对内存、CPU、磁盘、网络流入流出速率、GPU、日志等指标进行监控数据展示，并可切换集群进行数据查看。资源监控中心云可以看到和训练云相同的监控，通过 Karmada 聚合层 API 由集群的 Java 程序对 PromQL 封装后提供给前端页面，以下是一个 Java 查询节点 CPU 利用率的示例：/apis/cluster.karmada.io/v1alpha1/clusters/%s/proxy/api/v1/namespaces/%s/services/%s/proxy/api/v1/query_range?query=node:node_cpu_utilization:avg1m{node='%s'}&start=%s&end=%s&step=%s2、中心云数据下发用户在中心云上传的数据，可自由选择下发至指定现地，包括数据集、标注、算子工程、算子镜像以及模型等。数据发布数据集、算子工程、模型，通常是文件，在完成传输后，会保存到本地或NAS等存储中。标注，通常是结构化数据，在完成传输后，会保存到 DB 中。算子镜像，一般导出为 tar 包，在完成传输后，会推送到当前集群的 harbor 中。中心云除了 Karmada 的控制面以外，也带有自己的业务 K8s 集群，也包括存储，因此可以作为一个中转器。以上均通过 Karmada 的聚合层 API 来调用我们提供的文件上传等 svc。实现了集群和集群之间的调用。3、跨现地训练针对某现地训练资源不足的情况下，可通过申请其他现地资源的方式，进行跨现地训练。该功能实现方式为将 A 现地训练所需要的数据集、标注、算子工程、算子镜像等数据发送至 B 现地，通过 B 现地的资源进行训练。再将训练好的模型返回给 A 现地。跨现地训练原理和中心云数据下发类似，任务所需的数据会直接发送到对应集群，体现了成员集群和成员集群之间的调用关系。4、可视化大屏根据中心云注册的现地，统计不同现地的各类指标数据进行大屏展示。可视化大屏通过 Karmada 聚合层 API，我们在这类大屏中展示实时数据的时候，可以方便地直接调用成员集群的 svc。而无需让所有的数据显示都走大数据的离线分析、实时分析。提供更高的时效性。▍项目管理本项目的团队由我司经验丰富的训练平台产品经理，以及专业的研发工程师和测试工程师 14 名组成。团队从 2023 年 4 月开始工作，直至 2023 年 12 月完成了开发和部署工作。尽管项目在进程中经历了三个大的里程碑，每个阶段都充满了挑战，但团队的每一个成员都坚持不懈，积极应对，展现了我们团队的战斗力、凝聚力和专业能力。考虑到训练平台的用户主要是算法工程师和产线业务人员，他们的使用习惯和知识背景存在显著差异，因此产品经理进行了深入的市场研究和讨论，最终设计出一款既能满足算法工程师的灵活性需求，又能满足产线业务人员追求高效、简洁的系统。为了确保项目的范围、进度、质量和成本可控，我们在关键阶段举行了包括产品设计、开发、测试和部署评审等会议，并定期召开项目会议以及客户沟通会议。系统部署后，我们积极获取用户反馈，解决问题并持续优化系统以满足客户需求。添加社区小助手进入Karmada交流群

2024年6月22日，华为开发者大会2024期间，在“全域Serverless时代：技术创新引领，赋能行业实践”专题论坛上，华为云云原生服务产品专家带来主题演讲——Serverless容器的成本效益与敏捷开发之道（The Cost-Effective and Agile Path of Serverless Containers）。他表示，Serverless已成为云原生算力的主流形态，华为云提供CCE Autopilot（Serverless容器集群）和CCI（Serverless容器实例）两款容器产品，并面向垂直场景（如AI、HPC以及Web等）提供Serverless Workloads，简化用户体验。华为云CCE Autopilot以其创新的免运维特性，为容器服务提供全面优化的Kubernetes兼容性，让用户专注于核心业务的创新与实现。▍华为云持续投入Serverless基础设施，简化运维管理，释放创新潜力在云计算的浪潮中，容器技术以其轻量级和高效性，成为企业IT架构转型的强劲动力。然而，随着业务的快速发展，传统的容器服务（Serverful）逐渐暴露出一系列问题：运维管理复杂、弹性速度慢、成本控制困难，这些都严重制约了企业的创新步伐。运维管理复杂：用户需要手动管理底层服务器的资源分配和扩展，不仅涉及到复杂的容量规划和资源调度，还涉及到持续的节点运维故障排查、系统升级等运维活动。运维成本高，需投入大量人力和物力资源。弹性速度慢：用户需制定节点和负载的弹性联合策略，容器弹性扩容通常需要提前对工作节点进行扩容，过程通常需要分钟级别的等待，影响效率和响应速度。成本控制困难：容器节点需要预先分配资源，当资源未被充分利用时，会造成资源浪费，且高负载情况时可能资源不足，难以实现成本效益最大化。华为云容器引擎服务深刻洞察行业痛点，致力于Serverless基础设施的研发与创新，为用户提供全面优化的负载支持。面对独立资源池的管理和运营挑战，华为云容器服务采用Serverless融合底座，实现CPU、内存、GPU等资源的池化管理，提升资源灵活性和可扩展性。基于该融合资源底座，华为云推出CCE Autopilot产品，用户只需管理容器生命周期，享受由融合资源池统一管控的高效率服务，无需过度关注节点负载或资源池承载能力，为用户提供一个灵活且易于管理的计算环境，简化运维管理，释放创新潜力。▍CCE Autopilot: 实现k8s集群托管免运维，加速应用现代化CCE Autopilot是云容器引擎服务推出的Serverless版集群，为用户提供免运维的容器服务，并提供经过优化的Kubernetes兼容能力。在传统的CCE集群模式中， Kubernetes的master节点由华为云托管，用户需要对节点和应用进行统一管理。这要求用户具备一定的Kubernetes管理知识，以便有效地维护和扩展其容器化应用。在CCE Autopilot模式下，华为云不仅托管了k8s的控制节点，还托管了工作节点，用户无需购买节点即可部署应用，这意味着用户只需要关注应用业务逻辑的实现，可以大幅降低运维成本，提高应用程序的可靠性和可扩展性。对比CCE/CCE turbo集群，CCE Autopilot集群核心演进如下：产品Serverless化：增 加集群工作节点托管，实现集群全托管，用户无需对节点的部署、管理和安全性进行维护，集群规格自动弹性伸缩。资源池 化：采用华为云Serverless融合资源池，实现CPU、内存、GPU等资源的池化管理，减少资源碎片，容器资源按需使用。性能全面优化：通过动态预热技术进行资源池预热，资源供给加速，容器秒级弹性，根据负载规模自动扩缩。▍CCE Autopilot关键能力CCE Autopilot通过以下关键能力，重新定义了容器服务的管理和运维，助力企业轻松应对业务挑战，加速创新步伐。智能可靠的集群免运维体验CCE Autopilot通过智能化版本升级、漏洞自动修复和智能调参等技术，给用户提供更稳定、更安全、更智能的集群使用体验。作为全托管的Serverless解决方案，它简化了容量规划和节点购买流程，用户无需管理和维护底层资源设施，大幅减少了运维工作量。这种开箱即用的产品形态，让用户能够专注于核心业务逻辑的开发和部署。持续迭代的极致弹性性能CCE Autopilot以极致性能为核心，联合底层服务构建统一Serverless容器资源底座，通过多级资源池预热技术，精准满足客户多元异构的资源需求，并持续迭代优化性能。无论是面对突发流量、季节性波动还是长期增长，用户无需提前规划和预留资源，实现容器秒级弹性，根据负载规模自动进行扩缩，确保业务的连续性和性能的最优化。用户可以在短时间内快速上线新应用或服务，快速响应市场变化。全面兼容的云原生开源生态CCE Autopilot将Serverless架构优势与云原生开源生态相结合，提供全面兼容Kubernetes生态的Serverless集群，使用户能够根据需求灵活扩展功能。它支持Kubernetes社区版本的全跟随和自动更新，确保用户及时获得最新技术更新和安全补丁，保持技术前沿。未来将持续集成包括安全、应用管理、弹性、CI/CD、AI在内的主流开源软件如OPA Gatekeeper、Knative等，提供开箱即用的应用框架，让客户更加轻松的管理自己的Kubernetes应用。灵活规格与按秒计费CCE Autopilot旨在提供一种灵活、高效且具有成本效益的云服务体验。利用自动化技术，产品能够实现集群规格的动态调整，并且取消了传统的档位限制，用户可以享受从0.25vCPU起步的灵活规格档位，根据自己的具体需求优化资源配比。采用按量计费模式，用户按照实际使用的资源量（以秒为单位）支付费用，实现真正的按需付费，减少不必要的成本支出。安全隔离与自动预警CCE Autopilot基于QingTian架构，实现虚拟机级别的安全隔离能力，并通过专属的container OS提供精简且安全的运行环境。其底层统一资源池设计支持快速故障隔离和修复，确保应用的持续安全稳定运行。系统内置的自动预警机制能够及时识别并预防管控面过载风险，管控组件具备自动弹性能力，在负载增加时能够自动扩展，进一步保障服务的稳定性和可靠性。▍CCE Autopilot典型应用场景华为云CCE Autopilot以其Serverless特性，为多样化的业务场景提供了强大的支持和便利。以下是CCE Autopilot的典型应用场景：SaaS/企业平台的运维与迭代升级CCE Autopilot适合作为SaaS平台和企业平台的坚实底座，尤其适用于需要频繁进行升级和迭代的大型企业资源池。传统模式客户需自运维自升级，运维人力成本巨大。CCE Autopilot的自动化运维减少了对人力资源的依赖，显著降低了运维成本。且对互联网金融等对安全合规性有严格要求的行业，传统驾驶模式客户自运维，OS等保能力建设困难，CCE Autopilot的托管服务不仅简化了节点管理，还提升了系统的安全性和合规性，使企业能够更专注于核心业务的创新与发展。业务高效弹性伸缩针对互联网文娱、社交和网约车等具有明显流量波动的业务，如春节期间流量激增的情况，CCE Autopilot提供的智能资源弹性解决方案，能够根据业务特征和流量预测，动态调整资源配置。这种基于业务感知的弹性策略，避免了传统定时弹性策略中的资源浪费，实现了资源供给与业务需求的高效匹配，帮助企业在保持业务连续性的同时，优化了成本结构。成本优化配置CCE Autopilot为有成本优化诉求的企业用户提供了灵活的资源配置方案。它满足了用户对低成本学习、资源灵活配置的需求，同时支持业务量的自动扩缩，以适应业务的快速增长。CCE Autopilot确保了即使在资源需求较小的初期阶段，用户也能获得高可靠性和性能的服务，随着业务的扩展，资源可以无缝扩展，满足企业对成本效益和业务连续性的需求。▍如何使用CCE Autopilot集群进入华为云控制台，选择云容器引擎CCE产品。在控制台界面，选择购买集群，选择CCE Autopilot集群类型，再进行基础的网络插件等配置，便可进行CCE Autopilot集群创建。集群创建完成后，用户将进入集群的管理界面，在这里可以直接访问Kubernetes资源管理等功能。CCE Autopilot相较于CCE集群，其显著的特点在于省略了节点、节点池管理内容，这得益于产品侧提供了基础设施全托管服务。尽管如此，用户仍然可看到完整的Kubernetes控制面信息。▍总 结华为云CCE Autopilot以其Serverless架构，引领容器服务进入全新时代。它通过免运维、动态资源管理、智能预测和自动化运维，不仅极大简化了IT管理，还显著降低了运营成本，提高了资源的利用效率。同时，CCE Autopilot的兼容性保证了与Kubernetes生态的无缝对接，助用户敏捷应对市场，加速创新步伐。期待更多客户、伙伴与华为云一起开启企业数字化转型的新篇章，共同迎接更加高效、智能的未来！华为云CCE Autopilot限时免费体验，登录华为云官网-活动-云容器 活动专场，了解更多详情：cid:link_0容器活动专场

6月21日-23日，华为开发者大会2024在东莞松山湖成功举办。大会期间，华为云开源立足开源视角，联动云原生、应用前端、微服务、中间件、数据库、基础设施、端云协同等多个技术领域，邀请内外部专家通过专题论坛进行深度技术解读和实践案例分享，结合生动有趣的社区实操、1v1产品体验与交流等活动，共同探讨技术开源的持续创新与生态发展。全栈开源，加速开发者应用创新近年来，随着云原生技术的迅速发展和社区生态的不断完善，开源已经成为企业和开发者实现应用和业务创新的基石。本次HDC 2024期间，华为云开源专题论坛从开源策略、技术与生态、客户实践以及基础设施四大维度向参会者进行了解读。 ▲ 华为云开源业务总经理邓明昆     华为云开源业务总经理邓明昆在论坛中提出了应用全面现代化的重要性，同时也向外界传递了华为云开源全栈开源的长期策略：华为云将坚持开源开放、协同创新，基于华为云多年的技术积累和软件工程经验，逐步覆盖应用框架、中间件、数据库、云原生基础设施、研发工具等，最终实现云原生全栈技术开源和整合能力，使能云原生应用的全生命周期，助力开发者快速实现应用和业务的创新，加速企业数字化转型。 华为云全栈开源，包含以下几个核心组成部分：云原生应用开源套件：整合前端以及低码平台、微服务框架、业界主流中间件、以及主流开源数据库项目，面向应用开发者提供一站式云原生应用开发平台，帮助开发者快速构建高可靠，高性能、强韧性，极致体验的云原生应用；分布式云原生基础设施开源套件：提供多云、多集群统一编排，统一调度，统一流量治理，边云协同，统一监控运维等核心能力，帮助广大开发者快速搭建分布式云原生平台；开源基础设施：提供基础工具平台， 建立 代码、镜像、文档等技术资料，持续维护更新机制。参与开源，共创开源新价值华为云坚持长期投入开源贡献，共同推进开源社区生态的成长。在算力网络基础设施构建领域，华为云与中国移动研究院等伙伴共筹项目蓝图，共建算力网络开源生态。中国移动研究院开源专家，LF Edge Akraino社区技术委员会委员陈燕军在《开源赋能中国移动算力网络基础设施构建》演讲中指出，中国移动推动算力网络基础设施建设，加快发展智能算力，布局算力网络智能跃迁，在技术攻关领域积极参与开源。中国移动研究院携手华为、北京邮电大学等产学研伙伴主导发起“算力网络泛在算力调度”蓝图项目，联合Kurator, Karmada, Volcano等项目实现泛在通用及智能算力调度参考架构验证。同时，中国移动与华为等主流云厂商、设备商成立OIF算力网络开源社区，致力于提供算力网络端到端开源参考架构，并在算力原生、泛算调度等技术方向推进开源探索，共建算力网络开源生态。华为云基于IoT场景的真实业务实践，结合CNCF/Apache/开放原子等开源组织的价值开源项目，通过对OpenHarmony，Pulsar，BookKeeper， ServiceComb，openGemini等项目的应用和端云协同场景的持续技术优化，不仅贡献了安全、可靠、特性增强，同时加强生态对接，开源了端云协同套件、多个华为云对接connector，打造亿级IoT联接平台，加速行业数智化。开源基础设施，打造新一代开源开发者平台GitCode研发总监崔志康在论坛中分享了新一代开源开发者平台—GitCode，该平台依托CSDN开发者社区和华为云CodeArts，帮助开发者实现项目托管、协同研发、项目运营和生态扩展，共同打造新一代的开源开发者平台。GitCode特色功能包括针对开源贡献者和运营者的G-Star摘星计划针对开源项目成长全流程孵化计划；针对开源使用者提供最全最快最新的全球精选代码仓获取和下载；针对AI开发者的模型托管服务与推理部署服务。多领域实操互动，深入体验开源技术专题论坛外，华为云开源CodeLabs训练营、极客挑战赛、产品体验官、扫地僧等系列开发者活动和展台也进一步展示了云原生能力和技术创新成果，与现场开发者们进行深度交流与互动。未来，华为云开源将继续践行开源开放、协同创新的理念，持续推进开源技术创新与生态发展。 更多云原生技术动向关注容器魔方

云原生基础设施已经成为企业数字化转型的关键驱动力，随着企业用云不断推进，用云的广度和深度不断拓展，云原生在Serverless池化算力、算力全网互联、云原生应用生态等方面呈现出新的深度用云范式，进一步释放云原生价值。6月22日，华为开发者大会2024-“智启未来，云原生基础设施深度用云新范式”专题论坛成功举办，论坛分享了云原生基础设施深度用云新范式和发展趋势，以及云原生在精益用云、企业IDC现代化以及云原生多云治理等方面的成功实践。中国信息通信研究院云计算与大数据研究所云计算部主任马飞发表《云原生AI打造企业创新生产力》的主题演讲。马飞指出，在政策、产业、市场的多重驱动下，人工智能正迎来新一轮的创新浪潮。但是，算力需求的迅速迸发、模型的不断发展使得AI也面临着算力管理复杂、训练推理成本高、任务调度难等发展瓶颈。在此背景下，云原生AI应运而生，以其高可用性、弹性和可扩展性等优势，为AI产业提供了突破困境的关键。云原生AI不仅是一种技术架构，更是一种全新的生产力，基于智算资源管理、训推效能优化，以及海量AI任务调度三个方面技术手段，通过整合异构算力、提升训练推理效能、支持企业智能化降本增效，为现代企业和组织的智能化转型提供了核心动力。此外，云原生AI在跨地域多集群协同、训推效能优化、大模型云原生化等场景下的应用实践，展示了云原生AI技术如何帮助企业应对挑战，提升创新能力。了解更多详情，可扫描文末的二维码下载由华为云中国信息通信研究院云计算与大数据研究所、行吟信息科技（上海）有限公司、第四范式（北京）技术有限公司、远盟康健科技有限公司以及复旦大学联合撰写的《云原生AI技术架构白皮书》。▲ 中国信息通信研究院云大所云计算部主任马飞华为云云原生技术专家黄毽指出，云原生已经成为企业数字化转型共识，正在加速进入深水区，呈现出新的深度用云新范式和发展趋势，将企业的数字化建设、业务智能升级带入新阶段。面向未来，云原生基础设施将会往算力Serverless全池化、云原生算力全网互联以及应用使能算力等三个方向发展。针对这三大方向将衍生出八大关键发展趋势，具体是：趋势一：Serverless是云原生算力的主流形态，通过Serverless极致弹性和面向工作负载深度优化构建基础设施，进一步简化用户体验；趋势二：柔性计算改变云算力分配机制，呈现出从固定规格及配比“粗放式算力供给”到动态多样化“精细化算力需求”以及从感知“算力类型和算力代次”到感知“价值算力”新特征；趋势三：CloudMatrix矩阵计算将进一步激发云原生算力，基于“一切可池化”、“一切可组合”以及“一切皆对等”的矩阵算力将是云原生Serverless算力的最佳承载；趋势四：云原生是多云调度和治理的第一选择，基于分布式云原生架构，将实现算力、数据、流量全域调配，实现真正的云原生多云架构；趋势五：云原生赋能企业IDC往现代化IDC演进，企业IDC从“以资源为中心的基础设施”到“以应用为中心”转型、从“分散式管理”到“集约式管理”转型以及从“孤立的企业IDC”到“企业IDC+公有云混合架构”转型；趋势六：云原生是全域算力协同的最佳技术底座，云原生将赋能IDC数据中心全面云原生化，实现全域算力调度和协同；趋势七：云原生AI是云原生生态最强音，通过Serverless AI新范式、云原生训推一体新范式以及泛在AI计算新范式，支持大模型创新；趋势八：云原生促进应用百花齐放云原生孕育磅礴算力生态，支持千行百业。▲ 华为云云原生技术专家黄毽上海行吟信息科技有限公司（小红书）云原生资源调度负责人宋泽辉分享了小红书面向混合云场景下的计算资源效能提升实践。小红书基于融合资源池对容器应用使用的资源统一调度，通过精细化CPU核编排、GPU共享调度、拓扑感知调度、离线资源调度方法灵活应对资源需求潮汐。混部集群利用率均值维持在45%，最高可达60%，整体利用率提升效果明显，日均贡献核数数百万核*时，为离线节省大量的计算资源成本。▲ 小红书云原生资源调度负责人宋泽辉广发证券有限公司执行董事苏兆聪介绍了广发证券的新一代容器云平台。该平台以华为云云容器引擎CCE为底座，承载微服务、中间件、任务调度、API网关等组件；基于先进的服务网格技术，对异构系统的进行服务治理，实现多架构系统的统一管控，降低技术治理难度。苏兆聪表示，在未来还将与华为云深入合作，构建云边协同平台对服务器资源进行统一管控和调度，以及多云容灾能力，简化运维人员操作，进一步节约硬件资源。▲ 广发证券执行董事苏兆聪本次专题论坛，华为云与产业专家、行业伙伴齐聚一堂，共同探索云原生技术趋势以及行业最佳实践，帮助更多的行业用户享受到云原生带来的优质体验，进一步释放云原生价值。《云原生AI技术架构白皮书》下载：cid:link_0扫码下载云原生AI技术架构白皮书

1. 引言随着物联网（IoT）和边缘计算技术的飞速发展，企业和开发者面临着如何管理大规模分布式设备的挑战。KubeEdge作为一个开源平台，可以帮助扩展Kubernetes的能力，将容器编排从云延伸到边缘节点。本文将在Ubuntu 22.04上详尽介绍如何使用KubeEdge，并通过实际案例演示其应用。2. 什么是kubeEdge2.1 KubeEdge简介KubeEdge是由CNCF（云原生计算基金会）孵化的开源平台，其设计目的是扩展Kubernetes的能力至边缘计算设备。它提供了统一的边云协同管理能力，使得边缘设备和云端能够无缝对接，构建一个灵活高效的边缘计算架构。2.2 架构介绍KubeEdge 由以下组件组成：Edged: 在边缘节点上运行并管理容器化应用程序的代理。EdgeHub: Web 套接字客户端，负责与 Cloud Service 进行交互以进行边缘计算（例如 KubeEdge 体系结构中的 Edge Controller）。这包括将云侧资源更新同步到边缘，并将边缘侧主机和设备状态变更报告给云。CloudHub: Web 套接字服务器，负责在云端缓存信息、监视变更，并向 EdgeHub 端发送消息。EdgeController: kubernetes 的扩展控制器，用于管理边缘节点和 pod 的元数据，以便可以将数据定位到对应的边缘节点。EventBus: 一个与 MQTT 服务器（mosquitto）进行交互的 MQTT 客户端，为其他组件提供发布和订阅功能。DeviceTwin: 负责存储设备状态并将设备状态同步到云端。它还为应用程序提供查询接口。MetaManager: Edged 端和 Edgehub 端之间的消息处理器。它还负责将元数据存储到轻量级数据库（SQLite）或从轻量级数据库（SQLite）检索元数据。3. 网络组网图3.1 网络拓扑在具体的安装步骤之前，我们先了解一下KubeEdge的组网拓扑。这有助于更好地理解后续的安装和配置过程。以下是KubeEdge的组网拓扑图：3.2 组网原理介绍：网络环境的要求：KubeEdge要求边端能够访问云端的cloudcore暴露的端口（10000-10004）注意：单方面要求边端能够访问云端。不要求云端可以访问边端。云端：在公有云上搭建k8s集群并部署KubeEdge的cloudcore。边缘节点：在自己的笔记本电脑上安装edgecore,连接到家庭交换机，最后通过宽带拨号连接到Internet，访问到云端。在企业私有云中创建vm充当边缘节点部署edgecore，通过虚拟交换机连接到数据中的交换设备（交换机，路由器），通过企业防火墙设备，访问到云端。通信：KubeEdge使用WebSocket协议来实现云和边缘之间的高效通信，特别是在其核心组件之间。以下是KubeEdge如何使用WebSocket的详细说明，WebSocket在KubeEdge中主要用于以下几个方面：心跳检测：为了确保连接的稳定性，EdgeCore和CloudCore之间会定期发送心跳消息，通过WebSocket连接检测对方的在线状态。如果在一定时间内没有收到心跳响应，则认为连接断开。自动重连：如果检测到WebSocket连接断开，EdgeCore会自动尝试重新连接CloudCore，确保云边之间的通信恢复。Kubernetes事件：KubeEdge需要将Kubernetes事件从云端传输到边缘节点。例如，当用户在云端通过Kubernetes API部署新的应用时，CloudCore会捕获这些事件，并通过WebSocket连接将事件发送到相应的EdgeCore，从而在边缘节点上进行相应的处理。设备管理事件：KubeEdge支持IoT设备管理，设备状态和事件信息也通过WebSocket连接在云和边缘之间传输。例如，设备的状态变化、数据采集等事件都会通过WebSocket进行实时同步。连接建立：EdgeCore启动时，会与CloudCore建立WebSocket连接。CloudCore充当WebSocket服务器，EdgeCore充当客户端。这种连接是持久化的，确保云和边缘之间的实时通信。数据传输：通过WebSocket连接，EdgeCore和CloudCore可以传输各种类型的数据，包括控制命令、应用部署信息、设备状态更新等。由于WebSocket支持全双工通信，数据可以在任意一端实时传输，而无需轮询。云边通信：事件传输：心跳检测和重连机制：4 环境安装在开始安装KubeEdge之前，需要先准备好基础环境。以下是需要安装的基本工具和依赖。4.1 安装依赖在云端方面，我们需要：Kubernetes 集群，集群安装请参考我的另外一篇文章：Kubernetes v1.27.1（kubeadm）部署在边缘，我们需要：容器运行时，现在我们支持：DockerContainerdCri-oVirtletMQTT 服务器（可选）4.2  安装cloudcore（云端）下面将详细介绍如何在Ubuntu 22.04上安装最新版本的KubeEdge。4.2.1  下载并安装KubeEdge软件包首先需要下载KubeEdge的二进制文件，并将其解压到指定目录。最新版本为v1.17.0：root@cloudcore:~# mkdir kubeEdge root@cloudcore:~# cd kubeEdge/ root@cloudcore:~/kubeEdge# curl -LO  https://github.com/kubeedge/kubeedge/releases/download/v1.17.0/keadm-v1.17.0-linux-amd64.tar.gz root@cloudcore:~/kubeEdge# tar -xvzf keadm-v1.17.0-linux-amd64.tar.gz root@cloudcore:~/kubeEdge# cd keadm-v1.17.0-linux-amd64 root@cloudcore:~/kubeEdge/keadm-v1.17.0-linux-amd64# sudo cp keadm/keadm /usr/local/bin/ root@cloudcore:~/kubeEdge/keadm-v1.17.0-linux-amd64# keadm -h     +----------------------------------------------------------+     | KEADM                                                    |     | Easily bootstrap a KubeEdge cluster                      |     |                                                          |     | Please give us feedback at:                              |     | https://github.com/kubeedge/kubeedge/issues              |     +----------------------------------------------------------+     Create a cluster with cloud node     (which controls the edge node cluster), and edge nodes     (where native containerized application, in the form of     pods and deployments run), connects to devices. Usage:   keadm [command] Examples:     +----------------------------------------------------------+     | On the cloud machine:                                    |     +----------------------------------------------------------+     | master node (on the cloud)# sudo keadm init              |     +----------------------------------------------------------+     +----------------------------------------------------------+     | On the edge machine:                                     |     +----------------------------------------------------------+     | worker node (at the edge)# sudo keadm join <flags>       |     +----------------------------------------------------------+     You can then repeat the second step on, as many other machines as you like. Available Commands:   completion  Generate the autocompletion script for the specified shell   config      Use this command to configure keadm   ctl         Commands operating on the data plane at edge   debug       debug function to help diagnose the cluster   deprecated  keadm deprecated command   gettoken    To get the token for edge nodes to join the cluster   help        Help about any command   init        Bootstraps cloud component. Checks and install (if required) the pre-requisites.   join        Bootstraps edge component. Checks and install (if required) the pre-requisites. Execute it on any edge node machine you wish to join   manifest    Checks and generate the manifests.   reset       Teardowns KubeEdge (cloud(helm installed) & edge) component   rollback    rollback edge component. Rollback the edge node to the desired version.   upgrade     Upgrade components of the cloud or the edge   version     Print the version of keadm Flags:   -h, --help   help for keadm Additional help topics:   keadm beta       keadm beta command Use "keadm [command] --help" for more information about a command.4.2.2 初始化CloudCore1、去除k8s controlplane节点的污点root@cloudcore:~# kubectl taint nodes cloudcore  node-role.kubernetes.io/control-plane:NoSchedule- node/cloudcore untainted root@cloudcore:~# root@cloudcore:~# kubectl describe node cloudcore | grep Taints Taints:             <none> root@cloudcore:~# 2、CloudCore负责云端与边缘节点的交互和管理。安装和初始化CloudCore如下：root@cloudcore:~# keadm init --advertise-address="182.92.163.65" --kubeedge-version=1.17.0 --kube-config=/root/.kube/config --set iptablesHanager.mode="external" Kubernetes version verification passed, KubeEdge installation will start... CLOUDCORE started =========CHART DETAILS======= Name: cloudcore LAST DEPLOYED: Sat Jun  1 21:18:03 2024 NAMESPACE: kubeedge STATUS: deployed REVISION: 1 注意：请指定kueedge的版本，默认安装的是v1.15.1root@cloudcore:~# kubectl get all -n kubeedge NAME                             READY   STATUS    RESTARTS   AGE pod/cloudcore-69d64c8b78-wrpq7   1/1     Running   0          11m NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                                             AGE service/cloudcore   ClusterIP   10.105.194.25   <none>        10000/TCP,10001/TCP,10002/TCP,10003/TCP,10004/TCP   11m NAME                                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE daemonset.apps/edge-eclipse-mosquitto   0         0         0       0            0           <none>          11m NAME                        READY   UP-TO-DATE   AVAILABLE   AGE deployment.apps/cloudcore   1/1     1            1           11m NAME                                   DESIRED   CURRENT   READY   AGE replicaset.apps/cloudcore-69d64c8b78   1         1         1       11m 4.2.3 关闭云端防火墙root@cloudcore:~# systemctl status ufw.service ○ ufw.service - Uncomplicated firewall      Loaded: loaded (/usr/lib/systemd/system/ufw.service; enabled; preset: enabled)      Active: inactive (dead) since Thu 2024-05-30 10:29:18 CST; 4 days ago    Duration: 11h 56min 27.372s        Docs: man:ufw(8)    Main PID: 552 (code=exited, status=0/SUCCESS) May 29 22:32:51 cloudcore systemd[1]: Starting ufw.service - Uncomplicated firewall... May 29 22:32:51 cloudcore systemd[1]: Finished ufw.service - Uncomplicated firewall. May 30 10:29:18 cloudcore systemd[1]: Stopping ufw.service - Uncomplicated firewall... May 30 10:29:18 cloudcore ufw-init[180267]: Skip stopping firewall: ufw (not enabled) May 30 10:29:18 cloudcore systemd[1]: ufw.service: Deactivated successfully. May 30 10:29:18 cloudcore systemd[1]: Stopped ufw.service - Uncomplicated firewall. root@cloudcore:~# systemctl stop ufw.service root@cloudcore:~# systemctl disable ufw.service Synchronizing state of ufw.service with SysV service script with /usr/lib/systemd/systemd-sysv-install. Executing: /usr/lib/systemd/systemd-sysv-install disable ufw Removed "/etc/systemd/system/multi-user.target.wants/ufw.service". root@cloudcore:~# 4.2.4 打标签防止云端的一些damonset pod调度到边缘端root@cloudcore:~# kubectl get daemonset -n kube-system |grep -v NAME |awk '{print $1}' | xargs -n 1 kubectl patch daemonset -n kube-system --type='json' -p='[{"op": "replace","path": "/spec/template/spec/affinity","value":{"nodeAffinity":{"requiredDuringSchedulingIgnoredDuringExecution":{"nodeSelectorTerms":[{"matchExpressions":[{"key":"node-role.kubernetes.io/edge","operator":"DoesNotExist"}]}]}}}}]'注意：因为通常边缘计算的硬件条件都不好，这里我们需要打上标签，让一些云端damonset pod不扩展到edge节点上去。4.2.5 在云端设置安全组规则由于cloudcore 会暴露10000-10004端口。边缘端会通过此端口和云端交互.公有云的安全组一般不会开放这些端口，因此需要手动开启。root@cloudcore:~# kubectl get svc -n kubeedge NAME        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                                             AGE cloudcore   ClusterIP   10.110.56.18   <none>        10000/TCP,10001/TCP,10002/TCP,10003/TCP,10004/TCP   3d17h root@cloudcore:~# 4.3 安装EdgeCore（边缘侧）EdgeCore安装在边缘节点，用于运行实际的应用和处理数据。4.3.1 安装基础软件kevin@edgecore:~$ sudo apt-get update kevin@edgecore:~$ sudo apt-get install -y curl wget apt-transport-https4.3.2 安装与配置containerdStep 1: 更新包索引并安装必要的包kevin@edgecore:~$ sudo apt-get update kevin@edgecore:~$ sudo apt-get install -y apt-transport-https ca-certificates curl gnupg lsb-releaseStep 2: 添加阿里云的 Docker GPG 密钥kevin@edgecore:~$ curl -fsSL https://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg Step 3: 设置稳定版仓库kevin@edgecore:~$ echo \   "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://mirrors.aliyun.com/docker-ce/linux/ubuntu \   $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null Step 4: 更新包索引并安装 containerdkevin@edgecore:~$ sudo apt-get update kevin@edgecore:~$ sudo apt-get install -y containerd.ioStep 5: 配置 containerd创建或编辑 config.toml 配置文件：kevin@edgecore:~$ sudo containerd config default | sudo tee /etc/containerd/config.tomlStep 6: 要确保 cri 没有出现在 /etc/containerd/config.toml 文件中 disabled_plugins 列表内kevin@edgecore:~$ cat /etc/containerd/config.toml | grep -A 5 -B 5 "disabled_plugins" #cri 没有出现在 /etc/containerd/config.toml 文件中 disabled_plugins 列表内 disabled_plugins = [] imports = [] oom_score = 0 plugin_dir = "" required_plugins = [] root = "/var/lib/containerd"注意：如果你从软件包（例如RPM或者.deb）中安装 containerd，你可能会发现其中默认禁止了 CRI 集成插件。你需要启用 CRI 支持在KubeEdge场景下使用 containerd。要确保 cri 没有出现在 /etc/containerd/config.toml 文件中 disabled_plugins 列表内。如果你更改了这个文件，也请记得要重启 containerd。Step 7:  确保安装v1.6.0或更高版本的containerdkevin@edgecore:~$ sudo containerd --version containerd containerd.io 1.6.32 8b3b7ca2e5ce38e8f31a34f35b2b68ceb8470d89Step 8: 更新沙箱(pause)镜像，可以通过在containerd的配置文件中修改如下设置来实现：[plugins."io.containerd.grpc.v1.cri"]   sandbox_image = "kubeedge/pause:3.6"Step 9: 更新containerd的cgroup驱动[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]   ...   [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]     SystemdCgroup = trueStep 10: 启动并启用 containerd 服务kevin@edgecore:~$ sudo systemctl restart containerd kevin@edgecore:~$ sudo systemctl enable containerdStep 11:  查看containerd的状态kevin@edgecore:~$ sudo systemctl status containerd ● containerd.service - containerd container runtime      Loaded: loaded (/lib/systemd/system/containerd.service; enabled; vendor preset: enabled)      Active: active (running) since Mon 2024-06-03 01:37:00 UTC; 43s ago        Docs: https://containerd.io    Main PID: 62879 (containerd)       Tasks: 8      Memory: 13.0M         CPU: 374ms      CGroup: /system.slice/containerd.service              └─62879 /usr/bin/containerd4.3.3 配置 CNI 插件下载和安装 CNI 插件：kevin@edgecore:~$  sudo mkdir -p /opt/cni/bin kevin@edgecore:~$  curl -L https://github.com/containernetworking/plugins/releases/download/v1.5.0/cni-plugins-linux-amd64-v1.5.0.tgz | sudo tar -C /opt/cni/bin -xz kevin@edgecore:~$ ls -al /opt/cni/bin total 81544 drwxr-xr-x 2 1001  127     4096 May 20 07:23 . drwxr-xr-x 3 root root     4096 Jun  4 04:48 .. -rwxr-xr-x 1 1001  127  4272394 May 20 07:23 bandwidth -rwxr-xr-x 1 1001  127  4787319 May 20 07:23 bridge -rwxr-xr-x 1 1001  127 11430474 May 20 07:23 dhcp -rwxr-xr-x 1 1001  127  4422354 May 20 07:23 dummy -rwxr-xr-x 1 1001  127  4943785 May 20 07:23 firewall -rwxr-xr-x 1 1001  127  4344044 May 20 07:23 host-device -rwxr-xr-x 1 1001  127  3679567 May 20 07:23 host-local -rwxr-xr-x 1 1001  127  4440601 May 20 07:23 ipvlan -rw-r--r-- 1 1001  127    11357 May 20 07:23 LICENSE -rwxr-xr-x 1 1001  127  3750042 May 20 07:23 loopback -rwxr-xr-x 1 1001  127  4478854 May 20 07:23 macvlan -rwxr-xr-x 1 1001  127  4228716 May 20 07:23 portmap -rwxr-xr-x 1 1001  127  4600833 May 20 07:23 ptp -rw-r--r-- 1 1001  127     2343 May 20 07:23 README.md -rwxr-xr-x 1 1001  127  3956598 May 20 07:23 sbr -rwxr-xr-x 1 1001  127  3223795 May 20 07:23 static -rwxr-xr-x 1 1001  127  4503238 May 20 07:23 tap -rwxr-xr-x 1 1001  127  3837627 May 20 07:23 tuning -rwxr-xr-x 1 1001  127  4439832 May 20 07:23 vlan -rwxr-xr-x 1 1001  127  4102988 May 20 07:23 vrf配置 CNI 网络：创建 CNI 网络配置文件：kevin@edgecore:~$ sudo mkdir -p /etc/cni/net.d kevin@edgecore:~$ cat <<EOF | sudo tee /etc/cni/net.d/10-containerd-net.conflist {   "cniVersion": "0.4.0",   "name": "containerd-net",   "plugins": [     {       "type": "bridge",       "bridge": "cni0",       "isGateway": true,       "ipMasq": true,       "ipam": {         "type": "host-local",         "ranges": [           [{"subnet": "192.168.0.0/16"}]         ],         "routes": [           {"dst": "0.0.0.0/0"}         ]       }     },     {       "type": "portmap",       "capabilities": {"portMappings": true}     }   ] } EOFkevin@edgecore:~$ curl -LO https://github.com/containerd/nerdctl/releases/download/v1.7.6/nerdctl-1.7.6-linux-amd64.tar.gz kevin@edgecore:~$ sudo tar -C  /usr/local/bin -xzvf nerdctl-1.7.6-linux-amd64.tar.gz nerdctl containerd-rootless-setuptool.sh containerd-rootless.sh kevin@edgecore:~$ nerdctl --version nerdctl version 1.7.64.3.4  下载并安装KubeEdge软件包首先需要下载KubeEdge的二进制文件，并将其解压到指定目录。最新版本为v1.17.0：kevin@edgecore:~$ mkdir kubeEdge kevin@edgecore:~$ cd kubeEdge/ kevin@edgecore:~/kubeEdge$  curl -LO  https://github.com/kubeedge/kubeedge/releases/download/v1.17.0/keadm-v1.17.0-linux-amd64.tar.gz kevin@edgecore:~/kubeEdge$ tar -xvzf keadm-v1.17.0-linux-amd64.tar.gz kevin@edgecore:~/kubeEdge$ cd keadm-v1.17.0-linux-amd64 kevin@edgecore:~/kubeEdge/keadm-v1.17.0-linux-amd64# sudo cp keadm/keadm /usr/local/bin/4.3.5 测试网络的联通性1、从边端ping云端root@edgecore:/etc/kubeedge/config# ping 182.92.163.65 PING 47.109.202.113 (47.109.202.113) 56(84) bytes of data. 64 bytes from 47.109.202.113: icmp_seq=1 ttl=51 time=49.6 ms 64 bytes from 47.109.202.113: icmp_seq=2 ttl=51 time=49.1 ms ^C --- 47.109.202.113 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 49.135/49.345/49.556/0.210 ms 2、测试端口是否可以访问#cloudcore 监听的端口在10000-10004 root@edgecore:~# telnet 182.92.163.65 10000 Trying 47.109.202.113... Connected to 47.109.202.113. Escape character is '^]'. ^CConnection closed by foreign host. root@edgecore:~# telnet 182.92.163.65 10002 Trying 47.109.202.113... Connected to 47.109.202.113. Escape character is '^]'. ^CConnection closed by foreign host. root@edgecore:~# telnet 182.92.163.65 10003 Trying 47.109.202.113... Connected to 47.109.202.113. Escape character is '^]'. ^CConnection closed by foreign host. root@edgecore:~# telnet 182.92.163.653 10004 Trying 47.109.202.113... Connected to 47.109.202.113. Escape character is '^]'. ^CConnection closed by foreign host. root@edgecore:~# 4.3.6 获取云端tokenroot@cloudcore:~# keadm gettoken afc0ccb97b1f68c8607aa31584e8bd8f115cbca66d2bfbe21a782c866f589db9.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3MTc5NDU3NDB9.OJeQ1ewmQ_C3xFYrPmUJ7kOrqz1M5oTfKp4_fDCEMfM root@cloudcore:~#4.3.7 边缘节点加入云端1、运行keadm join命令加入云端root@edgecore:~/kubeEdge# sudo keadm join --cloudcore-ipport=182.92.163.65:10000 \ --token afc0ccb97b1f68c8607aa31584e8bd8f115cbca66d2bfbe21a782c866f589db9.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3MTc5NDU3NDB9.OJeQ1ewmQ_C3xFYrPmUJ7kOrqz1M5oTfKp4_fDCEMfM \ --edgenode-name=edgenode01 \ --kubeedge-version v1.17.0 \ --remote-runtime-endpoint=unix:///run/containerd/containerd.sock \ --cgroupdriver=systemd I0609 01:02:07.306277    3442 command.go:925] 1. Check KubeEdge edgecore process status I0609 01:02:07.308827    3442 command.go:925] 2. Check if the management directory is clean I0609 01:02:07.308940    3442 join.go:94] 3. Create the necessary directories I0609 01:02:07.327151    3442 join_others.go:183] 4. Pull Images Pulling kubeedge/installation-package:v1.17.0 ... Successfully pulled kubeedge/installation-package:v1.17.0 I0609 01:03:07.418751    3442 join_others.go:183] 5. Copy resources from the image to the management directory I0609 01:03:23.211034    3442 join.go:94] 6. Generate systemd service file I0609 01:03:23.211142    3442 join.go:94] 7. Generate EdgeCore default configuration I0609 01:03:23.211151    3442 join_others.go:111] The configuration does not exist or the parsing fails, and the default configuration is generated W0609 01:03:23.212571    3442 validation.go:71] NodeIP is empty , use default ip which can connect to cloud. I0609 01:03:23.214148    3442 join.go:94] 8. Run EdgeCore daemon I0609 01:03:23.816884    3442 join_others.go:264] I0609 01:03:23.816894    3442 join_others.go:265] KubeEdge edgecore is running, For logs visit: journalctl -u edgecore.service -xe I0609 01:03:33.825262    3442 join.go:94] 9. Install Complete!注意：Keadm安装EdgeCore时，你需要设置--remote-runtime-endpoint=unix:///run/containerd/containerd.sock2、云端查看边缘节点是否加入云端root@cloudcore:~# kubectl get nodes NAME         STATUS   ROLES           AGE   VERSION cloudcore    Ready    control-plane   39h   v1.28.2 edgenode01   Ready    agent,edge      96s   v1.28.6-kubeedge-v1.17.05. 部署nginx到edge端1、编写ngnix deployment yaml#nginx-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata:  name: nginx-demo spec:  replicas: 1   selector:    matchLabels:      app: nginx  template:    metadata:      labels:        app: nginx    spec:      nodeName: edgenode01  # 边缘端的名字 kubectl get node里面的      hostNetwork: true          containers:        - name: nginx          image: nginx:latest          ports:            - containerPort: 80 --- apiVersion: v1 kind: Service metadata:  name: nginx-service spec:  selector:    app: nginx  ports:    - name: http       port: 80      targetPort: 80 注意：在云端执行2、在科学上网的机器下载nginx镜像，进行打包kevin@jumphost:~/kubeedge/images$ sudo docker pull nginx Using default tag: latest latest: Pulling from library/nginx 2cc3ae149d28: Pull complete a97f9034bc9b: Pull complete 9571e65a55a3: Pull complete 0b432cb2d95e: Pull complete 24436676f2de: Pull complete 928cc9acedf0: Pull complete ca6fb48c6db4: Pull complete Digest: sha256:56b388b0d79c738f4cf51bbaf184a14fab19337f4819ceb2cae7d94100262de8 Status: Downloaded newer image for nginx:latest docker.io/library/nginx:latest kevin@jumphost:~/kubeedge/images$ sudo docker save -o nginx.tar nginx kevin@jumphost:~/kubeedge/images$ pwd /home/kevin/kubeedge/images在科学上网的机器上执行。3、拷贝镜像到边缘节点kevin@edgecore:~$ scp 100.98.97.43:/home/kevin/kubeedge/images/nginx.tar ./在边缘节点上执行。4、在边缘节点上load镜像kevin@edgecore:~$ sudo nerdctl load -i nginx.tar --namespace k8s.io unpacking docker.io/library/nginx:latest (sha256:dfc74c87d8108a046662ee785732b1d7b5f54f362da12b171f222b9b0e3a76a2)... Loaded image: nginx:latest kevin@edgecore:~$在边缘节点上执行5、创建Nginx应用，查看是否在边缘节点创建成功。root@cloudcore:~/ke_install# kubectl apply -f ngnix.yaml deployment.apps/nginx-metallb created service/nginx-service created root@cloudcore:~/ke_install# root@cloudcore:~/ke_install# kubectl get pod NAME                                   READY   STATUS    RESTARTS   AGE nginx-demo-5488d4cccd-p2fkf            1/1     Running   0          9s6、边缘节点上测试能否访问ngnix的80端口kevin@edgecore:~$ sudo ss -ntlp | grep 80 LISTEN 0      511          0.0.0.0:80         0.0.0.0:*    users:(("nginx",pid=1733,fd=6),("nginx",pid=1697,fd=6)) LISTEN 0      511             [::]:80            [::]:*    users:(("nginx",pid=1733,fd=7),("nginx",pid=1697,fd=7)) kevin@edgecore:~$ curl http://172.17.48.6 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> 6. 总结本文详细介绍了如何在Ubuntu 22.04系统上使用keadm安装和配置最新版本的KubeEdge（v1.17.0）。通过KubeEdge，可以将Kubernetes的强大功能扩展到边缘节点，提升边缘计算的能力和效率。希望这些内容能帮助读者快速上手并掌握KubeEdge的核心技术与应用。KubeEdge的边缘计算架构在未来将会有更广泛的应用前景，随着物联网，边缘计算技术和AI技术发展，KubeEdge将在更多的场景中发挥其独特优势，尤其是云+AI模式的云边协调场景。参考链接:[1]  https://release-1-17.docs.kubeedge.io/zh/docs/welcome/getting-started[2] https://kubeedge.io/zh/docs/setup/prerequisites/runtime/#containerd[3] 树莓派上部署KubeEdge_execute keadm command failed: edge node join faile-CSDN博客[4] https://blog.csdn.net/Leventcoco/article/details/128516720?utm_medium=distribute.pc_relevant.none-task-blog-2~default~baidujs_baidulandingword~default-1-128516720-blog-125448199.235^v43^pc_blog_bottom_relevance_base2&spm=1001.2101.3001.4242.2&utm_relevant_index=4[5] https://kubeedge-docs.readthedocs.io/en/latest/index.html[6] https://blog.csdn.net/xc979906570/article/details/139481230[7] https://github.com/kubeedge/examples/tree/master/kubeedge-counter-demo[8] https://mp.weixin.qq.com/s/QlI1RxOXGBY2IzNqHNaX6g[9] https://github.com/haicgu/training/blob/main/Cloud-Edge/KubeEdge/kubeedge-counter-demo.md[10] KubeEdge CounterDemo 源码分析

华为开发者大会2024将于6月21日至23日在东莞松山湖举行，大会将分享HarmonyOS、盘古大模型、昇腾AI云服务、GaussDB数据库等最新创新成果。这里有丰富多样的主题演讲、峰会、专题论坛和互动体验，有数百场面向开发者的特色活动，与您共赢新商机，共创新技术。华为云开源诚挚邀您参会华为开发者大会2024。华为云开源在本次大会中将通过专题论坛、展区展览、Codelabs、极客马拉松、扫地僧见面会、产品体验官等形式，与广大开发者们深入讨论业内热点，高频互动，共话开源，探索开源技术的无限可能。专题论坛大咖级嘉宾基于云原生及应用的技术开源、OpenHarmony应用开发等进行技术解读和实操演示，帮助用户与开发者通过开源技术实现业务创新。 HDC  开源专题论坛       云原生开源+OpenHarmony，加速开发者应用创新 HDC  云原生开源登陆展“岛”        丰富开发者活动等你来挑战华为云开源专属展岛位于云生态园区会场（华为云溪流背坡村），将全面展示华为云开源的云原生能力和创新技术成果。📍 展位号：H1-2-11 分布式云原生开源套件📍 展位号：H1-2-10 云原生应用开源社区开发者们也可以在园区参加丰富的华为云开源主题活动，技术领域涵盖前端开发、微服务、数据库等热门方向，收获大咖经验，激发创新潜能。更多大会信息可文末原文链接访问华为开发者大会2024官网或者点击下方小程序预约行程。欢迎预约报名“云原生开源+OpenHarmony，加速开发者应用创新”论坛、开发者活动，一起触达前沿科技，激发创新灵感，共享多元文化，探索无限可能。

加入议程  Schedule智启未来，云原生基础设施深度用云新范式【识别二维码，加入您的议程】▼

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。在最新发布的v1.10版本中，Karmada新增了工作负载重平衡功能：在某些场景下，资源副本的当前分布状态可能不是最优，但调度器为了减少对系统的冲击会尽可能保持调度结果的惰性，不会轻易改变调度结果；此时，用户可以通过新引入的 WorkloadRebalancer API 针对指定的资源手动触发全新的重调度，以在集群间建立最优的副本状态分布。本版本其他新增特性：解除资源模板名称长度不能超过 63 个字符的限制生产环境中的可用性和可靠性增强   新特性概览  Workload Rebalance一般情况下，工作负载类资源一旦被调度，其调度结果通常会保持惰性，不会轻易改变副本分布状态。即使通过修改资源模板中的副本数或 PropagationPolicy 的 Placement 来触发重新调度，系统也只会在必要时进行最小化的调整，以最大程度地减少对系统的影响。然而，在某些情况下，用户可能希望能够主动触发全新的重调度，完全忽略过去的分配结果，并在集群之间建立全新的副本分布状态，例如：在主备集群模式下，由于主集群故障，应用被迁移至备集群，主集群恢复后，应用希望重新迁移至主集群。在应用级别故障迁移场景下，由于集群资源不足，应用从多个集群缩减到单个集群，相应集群资源充足后，应用希望重新分发到多集群以确保高可用性。对于聚合调度策略，由于资源限制，副本最初分布在多个集群中，当单个集群足以容纳所有副本后，应用希望重新聚合到单集群。因此，本版本引入了工作负载重平衡功能，如果当前副本分布状态不是最优，用户可以按需触发全新的重调度。例如，用户想触发 Deployment/foo 的重调度，只需声明下述 WorkloadRebalancer 资源：apiVersion: apps.karmada.io/v1alpha1 kind: WorkloadRebalancer metadata: name: foo-rebalancer spec: workloads: - apiVersion: apps/v1 kind: Deployment name: foo namespace: default然后，调度器将对该 Deployment 进行重调度。1）如果成功，您将看到以下结果:apiVersion: apps.karmada.io/v1alpha1 kind: WorkloadRebalancer metadata: name: foo-rebalancer generation: 1 creationTimestamp: "2024-05-22T11:16:10Z" spec: ... status: finishTime: "2024-05-22T11:16:10Z" observedGeneration: 1 observedWorkloads: - result: Successful workload: apiVersion: apps/v1 kind: Deployment name: foo namespace: default2）如果失败，例如 Deployment/foo 的 ResourceBinding 不存在，您将得到以下结果：apiVersion: apps.karmada.io/v1alpha1 kind: WorkloadRebalancer metadata: name: foo-rebalancer generation: 1 creationTimestamp: "2024-05-22T11:16:10Z" spec: ... status: finishTime: "2024-05-22T11:16:10Z" observedGeneration: 1 observedWorkloads: - reason: ReferencedBindingNotFound result: Failed workload: apiVersion: apps/v1 kind: Deployment name: foo namespace: default有关此功能的详细描述，请参见用户指南：https://karmada.io/zh/docs/next/userguide/scheduling/workload-rebalancer解除资源模板命名长度的限制由于历史设计原因，资源模板的名称被用作 label 的值，从而加速资源的检索。由于 Kubernetes 限制标签 value 值不能超过 63 个字符，导致用户无法将名称长度超过 63 个字符的资源分发至成员集群中去，间接限制了资源模板名称的长度，严重阻碍了用户将工作负载从旧集群迁移到Karmada。Karmada社区从 v1.8 版本起着手消除这一限制，并在 v1.8 和 v1.9 版本中做了充足的准备工作，以确保使用旧版本 Karmada 的用户可以平滑升级到当前新版本，而不用感知这一变化。更多详情请参见 [Umbrella] 在资源中使用 permanent-id 替换 namespace/name标签：cid:link_4生产环境中的可用性和可靠性增强本版本融合了大量生产级用户的反馈，进行了大量功能性增强以及安全性提升，包括：1）功能增强：支持分发 kubernetes.io/service-account-token type的 Secret 资源优化 PropagationPolicy 降低优先级时的优先级抢占逻辑显著减少 karmada-metrics-adapter 组件的内存使用优化了 karmada-webhook 的启动逻辑，消除了偶现的异常报错2）安全增强：将 google.golang.org/protobuf 从 1.31.0 升级到 1.33.0，以解决 CVE-2024-24786 漏洞问题将 Karmada 证书的 RSA 密钥长度从 2048 升级到 3072，提高秘钥安全性将 text/template 库替换为 html/template，增加 HTML 编码等安全保护功能创建文件时由默认授予 0666 权限改为指定授予 0640 权限，提高文件安全性采取必要措施以消除安全扫描工具的误报，如在使用 karmadactl 删除 token 时调整日志打印内容和消除 gosec 警告 G107 等3）生态集成：为 OpenKruise 中的 CloneSet 资源展示 status.labelSelector，以支持该资源的HPA扩缩容特性在 karmadactl 添加成员集群时，新增支持 OIDC 认证模式相信这些努力将使 Karmada 为用户带来更好的体验！致谢贡献者Karmada v1.10 版本包含了来自32位贡献者的356次代码提交，在此对各位贡献者表示由衷的感谢：贡献者GitHub ID:@a7i@Jay179-sudo@veophi@Affan-7@jwcesign@wangxf1987@B1F030@khanhtc1202@warjiang@calvin0327@laihezhao@whitewindmills@chaosi-zju@liangyuanpeng@wzshiming@chaunceyjiang@my-git9@XiShanYongYe-Chang@dzcvxe@RainbowMango@yanfeng1992@Fish-pro@Ray-D-Song@yike21@grosser@rohit-satya@yizhang-zen@guozheng-shen@seanlaii@zhzhuang-zju@hulizhe@stulzq参考链接[1]Release Notes: cid:link_1[2]WorkloadRebalancer 指南: cid:link_0[3]WorkloadRebalancer 示例教程: cid:link_3[4]Karmada 1.10升级文档: cid:link_2更多云原生技术动向关注容器魔方

近年来快速发展的视觉大模型(例如 SAM )在促进高精度的智能感知方面具有很大的潜力。然而，边缘环境中的资源限制往往会限制这种视觉大模型在本地部署，从而产生相当大的推理延迟，导致难以支持自动驾驶和机器人等实时物联网智能感知应用。KubeEdge SIG AI 复旦大学吕智慧团队胡时京在 KubeEdge-Ianvs 上发布了基于大小模型协同推理的云边协同物联网感知方法，通过难例样本挖掘算法将少量难例样本上传云端由视觉大模型处理，大部分简单样本在边缘端由小模型处理，在保证推理时延的情况下提高了应对难例样本的处理效果。代码请见：cid:link_1一、背景智慧城市、物联网( IoT )技术的发展已经在国内外社会中根深蒂固，它们改变了人们日常生活和工作的方式，如自动驾驶、机器人、数字孪生、可穿戴设备和增强现实等。其中大量数据从物理世界生成和收集并由各种人工智能（AI）应用程序处理成用户需要的信息越来越成为了一种发展趋势。据 Gartner 统计，到2025年，物联网等终端设备产生的数据量将达到 79.4 zettabytes（ZB），到2030年，物联网设备数量将达到1250 亿。不断激增的终端设备（如移动设备，物联网设备）产生了海量的数据，由于物联网数据的特点（即容量大、多样性、产生速度快），传统的基于云的物联网模型已经无法满足物联网中智能应用的要求，数据源的高度分散性和广泛分布的人工智能应用要求物联网中的边缘设备具有智能感知的能力，即基于海量物联网数据训练边缘模型并进行高效推理。图1：物联网感知失败案例然而真实世界中的物联网边缘设备往往处在一个动态变化的环境中，例如自动驾驶汽车、机器人等移动边缘设备采集的数据会受其位置变化影响，监控摄像头采集的数据会受时间变化影响。物联网边缘设备采集的数据的分布和特征并非一成不变，在真实物联网边缘环境中普遍存在数据漂移和数据异构的现象。数据漂移和数据异构现象会对物联网边缘设备的智能感知能力造成极大影响，严重者甚至会导致出现人员伤亡以及业务受损。如图1所示，2017年，波士顿动力公司的人形机器人 Atlas 因为演示台所处环境与其训练所处环境相差较大未能正确识别演示台边缘，抱箱摔下演示台，该事件导致其股价大跌。2020年12月，福州中防万宝城导购机器人无法识别扶梯，跌落并撞翻两位客人，造成两人轻伤。2021年3月，特斯拉视觉识别应用误把白色卡车识别为天空，导致撞车造成至少两人丧生，特斯拉市值蒸发约440亿美金。2021年10月，美团无人配送车在送货过程中与一辆私家车相撞，美团被判全责。以上案例充分说明了数据漂移问题和数据异构问题是目前物联网智能感知技术的两大挑战。针对数据漂移问题，现有的解决思路致力于发生数据漂移后对模型在新的数据集上进行重训练使其能适应新的环境变化。然而重训练模型也会导致模型忘记之前学习到的信息，出现灾难性遗忘现象。这导致当物联网边缘设备又回到之前的环境时还需要再重新训练模型，造成了对算力的极大浪费。因此在训练过程中需要让模型具备终身学习的能力，使模型一方面可以不断学习新的数据集中的内容以适应新的环境，另一方面模型也不会大幅度遗忘在旧的数据集上学习到的信息，从而减少再重训练的开销。针对数据异构问题，目前快速发展的视觉大模型，如 Meta 公司发布的 Segment Anything Model（SAM），具有较强的泛化能力，在处理分布外的异构数据时相比传统计算机视觉模型效果较好。因此在物联网感知推理过程中引入视觉大模型是应对数据异构问题的关键解决方案之一。但是以 SAM 为首的大模型由于其参数量较大，难以部署在资源受限的边缘端，只能部署在云端使用。而很多边缘物联网设备，例如机器人、自动驾驶汽车，对推理的实时性要求较高，如果将所有推理样本都上传云端处理，会造成较大的通讯开销，并极大增加推理时延。因此只单独使用在云端部署的 SAM 大模型无法满足实时物联网感知的需求，需要通过云端大模型和边缘小模型的云边协同来解决实时物联网感知的挑战。二、基于大模型的边云协同物联网感知系统实现针对上述物联网边缘环境普遍存在的数据漂移和数据异构问题，我们采用终身学习训练方法动态更新边缘小模型从而使模型适应新的环境，我们在云端部署视觉大模型 SAM 用于处理分布外异构数据从而应对边缘小模型难以处理的难例推理样本。同时考虑到云端部署的 SAM 视觉大模型推理时延较大，难以满足物联网实时感知任务的需求，我们采用基于难例样本挖掘的云边协同策略，将大部分简单推理样本在边缘端由边缘小模型处理，少部分难例推理样本上传云端由云端 SAM 大模型处理，从而在保证推理时延的情况下提高推理准确率。▍2.1 总体架构设计基于大模型的边云协同物联网感知系统总体架构设计如图2所示，边云协同物联网感知系统包括云边协同推理和终身学习训练两部分。云边协同推理模块用于解决物联网感知的数据异构和实时性问题。以 SAM 为首的大模型具有较强的泛化能力，因此在处理分布外异构数据时准确率更高。我们通过基于难例样本挖掘的云边协同策略，将大部分简单样本在边缘处理，只有少部分难例样本才需要上传云端由 SAM 大模型处理，从而提高推理实时性。在云边协同推理部分，我们在边缘节点部署 RFNet 模型和难例样本挖掘算法用于实现在边缘端对简单样本的推理和判断推理样本是否需要上传云端。难例样本挖掘算法根据 RFNet 模型推理的结果将样本分为难例样本和简单样本，简单样本直接输出 RFNet 推理结果，难例样本上传云端处理，从而降低推理时延，提高推理实时性。我们在云端部署 SAM 模型用于对难例样本的推理结果进行优化，从而应对数据异构的问题。优化后的云端推理结果会下载到边缘节点作为难例样本的推理结果输出。SAM 模型可以通过 prompt 的方式以交互的形式对图像进行分割，在本项目中我们参考复旦大学提出的 SSA（Semantic Segment Anything）[1] 方法，用 SAM 模型将图像中所有物体都分割出来从而直接应用 SAM 模型于语义分割任务中。图2：基于大模型的边云协同物联网感知系统架构终身学习训练模块用于解决数据漂移问题。当环境变化导致数据分布发生变化时，原来训练的 RFNet 模型在面对数据分布变化后的样本时推理准确率会出现大幅度下降。终身学习算法通过在新分布的数据上持续训练 RFNet 模型从而提高 RFNet 模型的推理准确率，使之适应数据漂移现象。在终身学习训练部分，我们将上传到云端的难例样本及其云端推理结果存储在 replay buffer 中。当 replay buffer 中样本超过一定数量时，我们基于 replay buffer 中的难例样本对 RFNet 模型进行再训练，从而提高边缘模型应对数据漂移问题的能力。训练后的 RFNet 模型会被下载到边缘节点更新边缘端的 RFNet 模型。基于大模型的边云协同物联网感知系统总体架构设计如图2所示，边云协同物联网感知系统包括云边协同推理和终身学习训练两部分。上述系统架构的优势在于：通过难例样本挖掘，大部分简单样本在边缘节点由 RFNet 模型直接得到推理结果，保证系统可以满足实时性要求。少部分 corner case、难例样本上传云端由大模型 SAM 推理得到更完善的推理结果，提高系统推理平均准确率。通过终身学习训练，边缘端 RFNet 模型可以在大模型 SAM 的监督下从难例样本中学习到一定经验，从而适应边缘端复杂多变的环境。KubeEdge 是目前主流的开源边缘计算平台，其子项目 KubeEdge-Ianvs，作为业界首个分布式协同 AI 基准测试平台，基于 KubeEdge-Sedna 为算法及服务开发者提供全场景可扩展的分布式协同 AI 基准测试，以研发、衡量和优化分布式协同 AI 系统。我们基于 Kubeedge-Ianvs 实现了该系统架构，具体在 Ianvs 中实现的模块如图3所示。图3：在KubeEdge-Ianvs中实现模块我们将难例样本挖掘算法填补在 Ianvs 的未知样本识别模块，其将样本分为难例样本（未知样本）和简单样本（已知样本）。在云端节点基于大模型 SAM 对难例样本的推理在未知样本推理模块中实现，在边缘端基于 RFNet 对简单样本的推理在已知样本推理模块中实现。对于终身学习训练的部分，我们在已知和未知任务处理模块实现，这部分我们延用了 Ianvs 默认的终身学习训练配置。▍2.2 案例分析我们采用在华为深圳工业园区由智能机械狗采集的语义分割机器人数据集 Cloud-Robotics 作为本项目的测试 benchmark。Cloud-Robotics 是首个在真实世界场景中由机械狗实地收集的数据集，因此数据集中的图片都是以机械狗的视角拍摄的，拍摄角度相比 Cityscapes 等自动驾驶语义分割数据集更低，也更贴近实际机器人应用（递送、巡检）。数据集官网链接：cid:link_6。图4展示了在 Cloud-Robotics 数据集中RFNet模型和SAM模型部分的推理结果，不难看出 RFNet 在处理部分 corner case 比如反光（第三排图片）时效果较差，将建筑物识别为天空。然而通过大模型 SAM 推理得到分割完善的 mask 后基于像素级的投票成果将错误识别为天空的部分正确识别为了建筑物。图4：部分实验结果展示我们在[Cloud-Robotics][2] 数据集上进行了实验，为了进一步对比 SAM+RFNet 效果，我们额外选取了 Huggingface 发布的在cityscapes数据集上预训练的[Segformer][3] 模型作为基模型进行测试，测试结果如下表：上表展示了不同算法在 Cloud-Robotics 数据集上对不同类别物体的识别准确率（IoU）。我们将识别物体根据其在数据集中出现的频率分为常见类别和稀有类别两种。从结果中可以看出对于常见类别的 Road、Sidewalk 和 builiding 类物体的识别上，SAM+RFNet 云边协同和 RFNet 效果提升仅有1%左右，这是因为对于识别常见类别的简单任务来说，RFNet 模型的准确率已经很高了，再额外加入 SAM 大模型也没有太多提升空间。而对于园区中出现较少稀有类别的 Car、Terrain 类物体， SAM+RFNet 相比 RFNet 提升平均超过20%以上，这是因为对于识别稀有类别的难例任务来说，RFNet 模型处理效果不好，而 SAM 模型更擅长处理。总体来说， SAM+RFNet 云边协同相比只用RFNet准确率提升了8%以上，证明了我们提出的基于大模型的边云协同物联网感知系统的有效性。同时可以看出使用 Segformer 作为基模型的结果则相差很多，这主要是因为 Segformer 是在 cityscapes 数据集上预训练的，而 Cloud-Robotics 数据集中存在 cityscapes 数据集中没有的标签，同时数据集的分布差别较大（Cloud-Robotics 面向半封闭工业园区，cityscapes 面向开放世界）导致了 Segformer 推理结果较差。在Cityscapes 数据集上预训练的 Segformer 模型在 Car 类物体识别上准确率较高，这主要是因为 Cityscapes 数据集是面向开放世界的语义分割数据集，其中 car 类物体出现频率更高。下图展示了 RFNet 和 Segformer 的部分推理结果对比。图5：不同模型效果展示如图5所示，可以看出因为 Segformer 在分类时就将整个天空都识别为了建筑，因此即便 SAM 推理的结果中将天空正确切割出来了，最后 SAM+Segformer 的推理结果中天空仍然是分类错误的。这告诉我们 SAM 大模型不能解决一切问题，最终推理结果还是依赖于使用的小模型推理标签准确。因此即便在使用大模型进行云边协同推理时，对边缘端小模型进行终身学习更新仍然是必要的。三、基于KubeEdge-lanvs的使用教程在这章中我们通过运行 Ianvs 终身学习的 cloud-robotics 样例向大家讲解基于 KubeEdge-Ianvs 实现大模型边云协同物联网感知的基本流程。Ianvs 安装流程以及终身学习更详细的介绍可以参考：Ianvs-lifelong-learning-tutorial[4]。首先我们需要配置好 Cloud-Robotics 的数据集，先创建数据集的文件夹，注意如果你把数据集放到别的位置，本教程中的部分路径配置也要一并修改。mkdir /data cd /data mkdir datasets cd datasets download datasets in cid:link_6download.html配置好数据集后，我们可以准备运行示例代码了。Cloud-Robotics 示例运行的代码放在/ianvs/project/ianvs/examples/robot/lifelong_learning_bench/semantic-segmentation下，我们首先要配置 python 路径（这里如果 Ianvs 安装位置不一样的话需要更改路径）：export PYTHONPATH=$PYTHONPATH:/ianvs/project/ianvs/examples/robot/lifelong_learning_bench/semantic-segmentation/testalgorithms/rfnet/RFNet然后我们需要去安装 SAM 大模型：cd /ianvs/project git clone https://github.com/facebookresearch/segment-anything.git cd segment-anything python -m pip install -e .下载模型参数：wget https://dl.fbaipublicfiles.com/segment_anything/sam_vit_h_4b8939.pth为了保存模型推理结果，我们需要按照以下指令安装 mmcv 和 mmdetection:python -m pip install https://download.openmmlab.com/mmcv/dist/cu118/torch2.0.0/mmcv-2.0.0-cp39-cp39-manylinux1_x86_64.whl cd /ianvs/project git clone https://github.com/hsj576/mmdetection.git cd mmdetection python -m pip install -v -e .在机器配置性能不足以运行 SAM 模型的情况下，我们为 Cloud-Robotics 数据集中的所有 SAM 推理结果准备了一个缓存。你可以从这个链接 [5]下载缓存，并把缓存文件放在“/ianvs/project/”中:cp cache.pickle /ianvs/project通过使用缓存，可以在不安装 SAM 模型的情况下模拟基于大模型的边云协同推理。除此之外，我们还在这个链接  [6]中提供了一个预训练的 RFNet 模型，如果你不想从零开始训练 RFNet 模型，可以使用我们预训练的 RFNet 模型：cd /ianvs/project mkdir pretrain cp pretrain_model.pth /ianvs/project/pretrain in /ianvs/project/ianvs/examples/robot/lifelong_learning_bench/semantic-segmentation/testalgorithms/rfnet/RFNet/utils/args.py set self.resume = '/ianvs/project/pretrain/pretrain_model.pth'上述所有配置完成后，执行下面指令即可进行基于 SAM 大模型的边云协同推理：cd /ianvs/project/ianvs ianvs -f examples/robot/lifelong_learning_bench/semantic-segmentation/benchmarkingjob-sam.yaml相关资料：[1] SSA（Semantic Segment Anything）: cid:link_0[2] Cloud-Robotics: cid:link_6[3] Segformer: cid:link_2[4] Ianvs-lifelong-learning-tutorial: cid:link_5[5] cid:link_3[6] cid:link_4更多云原生技术动向关注容器魔方