数之联简介成都数之联科技股份有限公司成立于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容器活动专场

中奖结果公示感谢各位小伙伴参与本次活动，欢迎关注华为云DTSE Tech Talk 技术直播更多活动~本次活动获奖名单如下：账号名 奖项名称 奖品名称qingqingjiayuan6 官网抽奖 华为云云宝公仔盲盒hw57269863 官网抽奖  华为云云宝公仔盲盒xj120141121 优质提问 华为云定制T恤linghz666 优质提问 华为云定制T恤 hw57374707 论坛提问奖 华为云定制Polo衫视频号抽奖华为云定制云宝盲盒视频号抽奖华为云定制鼠标垫视频号抽奖华为云定制云宝盲盒

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更多云原生技术动向关注容器魔方

华为云隆重推出云容器Serverless产品CCE Autopilot，引领容器服务进入全面“自动驾驶”的新时代。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的购买和使用详情可查看CCE Autopilot集群用户指南。▍总结华为云CCE Autopilot以其Serverless架构，引领容器服务进入全新时代。它通过免运维、动态资源管理、智能预测和自动化运维，不仅极大简化了IT管理，还显著降低了运营成本，提高了资源的利用效率。同时，CCE Autopilot的兼容性保证了与Kubernetes生态的无缝对接，助您敏捷应对市场，加速创新步伐。邀请您携手华为云CCE Autopilot，开启企业数字化转型的新篇章，共同迎接更加高效、智能的未来！容器活动专场：cid:link_1云容器引擎 CCE

中奖结果公示感谢各位小伙伴参与本次活动，欢迎关注华为云DTSE Tech Talk 技术直播更多活动~本次活动获奖名单如下：请于6月19日前在此问卷中反馈您的中奖邮寄信息~直播简介【直播主题】构筑云原生时代的应用稳定性【直播时间】2024年6月12日 16:30-18:00【直播专家】韫欣 华为云aPaaS DTSE技术布道师【直播简介】在云原生的浪潮中，开发者们面临着前所未有的挑战，你是否曾因技术的复杂度和工具的碎片化而感到困惑？是否在寻找一种方法，既能应对业务的快速迭代，又能确保应用的稳定性和高效运维？本期直播，我们特别邀请到华为云应用平台AppStage的高级专家带来丰富的运维经验分享，揭秘10亿+高并发应用如何实现高效稳定的开发和运维，无论你是云原生技术的新手，还是正在寻求优化方案的资深开发者，都将为你答疑解惑，赶快参与直播，跟我们一起探索吧！直播链接：cid:link_1活动介绍【互动方式】直播前您可以在本帖留下您疑惑的问题，专家会在直播时为您解答。直播后您可以继续在本帖留言，与专家互动交流。我们会在全部活动结束后对参与互动的用户进行评选。【活动时间】即日起—2024年6月13日【奖励说明】评奖规则：活动1：直播期间在直播间提出与直播内容相关的问题，对专家评选为优质问题的开发者进行奖励。奖品：华为云定制T恤活动2：在本帖提出与直播内容相关的问题，由专家在所有互动贴中选出最优问题贴的开发者进行奖励。奖品：华为云定制Polo衫​更多直播活动直播互动有礼：官网直播间发口令“华为云 DTSE”抽华为云云宝公仔盲盒等好礼。​【注意事项】1、所有参与活动的问题，如发现为复用他人内容或直播间中重复内容，则取消获奖资格。2、为保证您顺利领取活动奖品，请您在活动公示奖项后2个工作日内私信提前填写奖品收货信息，如您没有填写，视为自动放弃奖励。3、活动奖项公示时间截止2024年6月15日，如未反馈邮寄信息视为弃奖。本次活动奖品将于奖项公示后30个工作日内统一发出，请您耐心等待。4、活动期间同类子活动每个ID（同一姓名/电话/收货地址）只能获奖一次，若重复则中奖资格顺延至下一位合格开发者，仅一次顺延。5、如活动奖品出现没有库存的情况，华为云工作人员将会替换等价值的奖品，获奖者不同意此规则视为放弃奖品。6、其他事宜请参考【华为云社区常规活动规则】。

北京时间2024年5月16日，Kmesh 正式进入 CNCF 云原生全景图，位于 Service Mesh 类别下。CNCF Landscape 在云原生实践过程中的每个环节帮助用户了解有哪些具体的软件和产品选择，Kmesh 进入 CNCF Landscape，成为了 CNCF构建云原生服务网格最佳实践中的一环。Kmesh：业界首个内核级Sidecarless流量治理引擎▍eBPF和Sidecarless是服务网格的未来近年来服务网格逐步流行，但sidecar架构在资源开销、升级部署、时延等方面仍存在挑战，如何消减代理开销，构建sidecarless的服务网格已成为业界共识。Kmesh从立项之初，就瞄准网格痛点问题，创新性的提出业内首个内核级sidecarless流量治理引擎，通过eBPF + 可编程内核技术将L4~L7治理下沉OS，治理过程无需经过代理组件，实现服务网格内服务通信路径多跳变一跳，彻底消除代理开销，真正实现网格治理sidecarless化。Kmesh架构图▍Kmesh优势高性能内核中原生支持 L4~L7 流量治理功能，网格内微服务转发时延降低60%，微服务启动性能提升40%；低开销微服务中无需部署sidecar，服务网格数据面开销降低70%；高可用内核流量治理不会截断连接，组件升级、重启完全不影响业务已有连接；零信任网络支持基于内核mTLS构建零信任网络；安全隔离基于eBPF的虚机安全，且具备cgroup级治理隔离；灵活治理模式除了全内核治理形态，Kmesh还支持四七层治理分离架构，内核eBPF和waypoint组件分别处理L4和L7流量，允许用户逐步采用Kmesh，从而实现从无网格->安全L4治理->L7治理的平稳过渡；平滑兼容与Istio无缝集成，支持xDS协议标准。目前同时支持Istio API和Gateway API，可以与现有sidecar协同工作。为什么选择KmeshKmesh首先是一种Sidecarless的网格架构模型，目前Sidecarless模式广受欢迎。无论是Istio社区还是Cilium社区都在在采用这种架构模型，另外广大用户非常认可Sidecarless。与Sidecar相比，Sidecarless没有资源占用的开销，同时解耦应用和代理的生命周期，并且打破一一绑定的关系，部署、维护更加简单。Kmesh创新性的采用eBPF技术在内核态进行流量治理，使得流量的治理随流进行。好处是不会截断业务的连接，大大减少了流量路径上的连接数，进而降低应用访问的时延。在用户态进行流量治理的一个比较大的弊端是组件的升级会导致业务的流量受损，Kmesh通过可编程内核技术，完好的避开了这一点。目前Kmesh这方面具有业界压倒性的优势，我们充分看到了eBPF的无限可能，未来基于eBPF可以进行更多的网络创新。Kmesh还提供了另一种高级的模式，通过四七层分离，提供丰富的L7治理功能。四七层分离能够提供更加细粒度的物理隔离，不同租户，不同命名空间或者不同的服务均可以划分，独享七层代理waypoint。waypoint还可以根据业务流量，进行动态扩缩容，方便提供全托管。我们看到waypoint不同于传统的中心式网关，不存在单点故障。由此，我们坚定的认为未来Sidecarless模式的理想架构，一定是eBPF技术和waypoint组合，既要减少资源消耗，又要降低时延。在节点上通过eBPF进行L4和简单的L7流量治理，至于高级的、复杂的七层协议则转发到waypoint治理。加入社区贡献Kmesh由华为发起， openEuler社区孵化，当前作为独立项目在GitHub托管，为用户提供极致性能的流量治理技术方案。华为是中国最早参与服务网格的厂商，早在2018年华为就开始投入Istio社区，常年在Istio社区贡献保持亚洲第一，并且自首届以来持续拥有社区Steering Committee席位。华为在服务网格领域的探索历程我们希望借助在Istio社区长期的积累，始终以开放中立的态度发展Kmesh，打造Sidecarless服务网格业界标杆方案，服务千行百业，促进服务网格健康有序的发展。Kmesh当前正处于高速发展阶段，我们诚邀广大有志之士加入！Kmesh社区地址：cid:link_3CNCF云原生全景图Cloud Native Computing Foundation，云原生计算基金会（以下简称CNCF）是一个开源软件基金会，它致力于云原生（Cloud Native）技术的普及和可持续发展。云原生技术通过一系列的软件、规范和标准帮助企业和组织，在现代的动态环境（如公共云、私有云和混合云）中构建和运行敏捷的、可扩展的应用程序。CNCF 发布了云原生全景图（CNCF Landscape），旨在帮助企业和开发人员快速了解云原生体系的全貌，帮助用户选择云原生实践中的恰当的软件和工具，因此受到广大开发者和使用者的关注和重视。参考链接[1]CNCF Landscape: cid:link_4[2]Ambient Mesh介绍: cid:link_0[3]华为云ASM: cid:link_1[4]Kmesh快速上手: cid:link_2添加小助手k8s2222回复Kmesh进入技术交流群

 企业软件开发困局随着信息化的进程不断加速，带来的各种业务应用、平台应用等软件资产的复杂度也快速上升。随之而来的信息化基础设施能力与软件工程全生命周期的管理也会变得越来越复杂，数字化转型、云原生、持续交付的口号随之升起。千行百业都在响应数字化转型的号召以提升业务效率、企业竞争力或是市场竞争力。但是企业在转型的过程中却举步维艰。往往原因有以下几点：流程固化，牵一发而动全身：原有的流程已经制定多年，相关人员也已经习惯这套流程。突然的规则转变以及带来的相关风险无人愿意主动承担。部门墙明显，无法快速协同：在金融等行业中，每个部门的成员往往都是统一职责的。如业务部门，只负责市场运营、项目需求管理等；研发部门，只负责开发以及测试；运维部门，只负责平台的运维、基础设施的维护等。一个业务软件的版本迭代，需要从多个部门层层流转，但部门与部门之间的沟通又不彻底，出现问题也容易互相牵扯，最终导致软件需求交付效率的大大下降。严谨的网络环境管理却又松散的制品管理：网络部门严格管理着各个环境之间的网络访问逻辑，一般情况下，开发人员只能访问开发环境；而且开发、测试、准生产以及生产环境之间网络都是不互通的。在没有强有力的政策干预下，可能会出现各个环境都独立一套代码、制品仓库，更糟糕的是，可能不同的软件产品线都独立管理各自的代码、制品仓库。因此在阶段流转时，需要通过传统的拷贝方式去做流转传递，带来了额外的管理成本，也更容易引入人为风险。过多的编外人员带来的各种散乱工具链：在软件研发部门可能存在多方外包人员，而每一方外包人员都有各自熟悉的软件开发工具，代码仓库有些使用Gitlab，有些使用Gitea；制品仓库有些使用nexus，有些使用jforg；甚至构建工具都不能统一，有用Jenkins的，也有本地构建的。这也带来了管理上的巨大麻烦。显而易见的困局，企业在数字化转型过程中面临流程固化、部门墙明显、制品管理松散和工具链混乱等问题，导致软件需求交付效率下降。需要打破原有流程和部门墙，建立统一的管理体系，加强制品管理和工具链整合，以提高软件需求交付效率。破局之法：DevOps面对以上重重现状和困难，我们迎来了曙光——DevOps。DevOps最初诞生于互联网企业。DevOps作为一种文化、哲学和实践的集合，自从诞生以来，就一直在不断地进化和扩展。它的定义以及理念大家都耳熟能详：打破部门墙、紧密合作、自动化、小步快跑、敏捷迭代等等。它是一种文化宣言，提及了方法论，每个企业或者行业都能够结合自身实际情况去操作实施。核心理念：变更的快速响应：DevOps支持需求的快速更改和新功能的快速部署。通过自动化构建和部署流程，开发团队可以快速地将代码从开发环境推送到生产环境。持续反馈：通过持续集成和持续部署，可以确保在开发周期的任何阶段捕获问题，以及在生产过程中立即收集用户反馈，然后快速将这些反馈整合到产品迭代中。跨功能协作：DevOps鼓励开发团队、QA团队和运维团队从需求收集的初期就开始紧密合作，以确保全方位理解和满足用户需求，并从整个软件交付流程中消除障碍。原则优化：DevOps的实践着重于自动化和精益原则，包括尽早消除浪费，确保需求的清晰性和简洁性，以及提供最大的价值。从核心理念就能够看出，DevOps文化实践需要有统一的软件工程工具链，所有相关人员都能够在DevOps平台上执行各自的工作，实现部门之间通力协作和重复流程的全面自动化。上图展示了DevOps的相关角色以及整体工作流程。一个较为完整的DevOps全流程工具链便呼之欲出：从基础设施的管理、项目管理，再到代码管理和持续交付，最后是持续运维。除却文化理念，DevOps的核心是自动化流水线工具，实现了自动化持续交付，而持续交付的核心是持续集成（CI）和持续部署（CD）。CI/CD共同构成了现代软件开发的核心实践，旨在促进软件的快速迭代和高质量交付。其中，持续集成主要关注开发阶段的频繁合并和测试，而持续部署则扩展了这一过程，涵盖了代码从集成到被部署到生产环境的整个流程。两者都是自动化的关键实践，有助于实现DevOps的目标。遵循理论引导并结合实际情况，我们归纳了针对金融等行业的破局三板斧。DevOps专业团队指导，打破固有流程在金融等行业并不缺乏优化现有流程的勇气，只是没有明确的目标以及专业指导。当DevOps的呼声以及发展越来越强大时，国内涌现出了很多专业的DevOps专家咨询团队，他们能够结合企业的实际现状给出最优解，在组织架构不调整的情况下保障以尽可能小的变更达到最大的效果，消除企业顾虑。统一的DevOps工具链平台，打破部门墙，规范研发流程我们发现绝大多数企业都无法做到为每一个项目划分全功能团队（从市场、需求到研发、测试最后到运维），往往都是独立的市场部、研发部和运维部。这天然的形成了沟通与阶段流转之间的部门墙，由于更改现状牵扯太大，我们便通过应用DevOps的理念，建立统一的DevOps工具链平台，对当前项目的全生命周期进行管理。针对每一个原始需求，从需求记录、分析、分配到后续的开发、测试、验证及最终上线，都能被相关人员看到。阶段的流转也能够在相关平台上直接操作和通知，杜绝冗长低效的跨部门流程。我们提倡相关人员使用DevOps平台的同时，梳理最佳实践，进行定期培训，潜移默化的让研发流程变得统一和规范。在严谨的网络环境内搭建统一的核心资产库核心资产库的统一有必要性，各个项目组成员，即使在不同的应用环境下，也不能单独建立。如代码仓库，不能在开发环境和测试环境各有一套。我们需要统一的核心资产库去践行DevOps的理念。该库需要打通从开发到生产环境的网络连接，并通过严格的权限控制，来实现安全合规。行业困局的解决方案为了满足理论支撑，我们基于华为云UCS作为容器平台底座，结合软通动力应用交付平台来实现行业云原生数字化转型的最佳解决方案。华为云UCS（Ubiquitous Cloud Native Service）是业界首个分布式云原生产品，为企业构建云原生业务部署、管理、应用生态的全域一致性体验 ，实现客户在使用云原生应用时，感受不到地域、跨云、流量的限制，让云原生的能力进入企业的每一个业务场景，加速千行百业拥抱云原生。而软通动力应用交付平台是一款持续交付产品，帮助企业快速建立稳定软件发布的内部开发者平台与 DevOps 文化，为开发者提供云原生应用运行环境，开发者通过平台的自助服务能力，进行应用的构建、部署、验证、运维等生命周期管理操作，降低应用开发者使用云原生技术的门槛，提升应用的部署和运行质量。平台支持UCS云原生服务中心快速安装，用户只需要通过页面表单的填写即可快速部署平台，实现开箱即用。客户通过UCS对多方集群执行统一纳管，从而达到对多个集群的统一治理，实现配置管理、容器迁移、策略中心、流量治理和容器智能分析。这在网络环境严苛的金融等行业中是非常便利的。云原生服务中心精选了各种成熟可靠的开源工具，为客户提供了统一便捷的安装体验，其中的多种工具能够和应用交付平台实现集成联动效果，如SonarQube和ArgoCD。他们支持配置对接到应用交付平台的持续集成流水线或安全测试编排中，实现多个工具平台的串联，打破数据孤岛。整体解决方案中，实现DevOps的核心便是华为云UCS提供的容器底座以及应用交付平台提供的集成和自动化能力，两者相辅相成。原本的应用交付平台得到升华。通过UCS的特性，我们可以实现多集群的统一联邦管理，让快速搭建双活、主备等高可用应用部署架构变得轻而易举。这种架构极大地提升了运维能力，使构建发布过程实现全面自动化，从而提高交付质量、缩短交付周期、保持技术路线一致性以及规范资源使用。值得一提的是，UCS云原生服务中心的引入使得企业能够快速安装和使用诸如ArgoCD、SornaQube等热门开源工具平台。这不仅丰富了企业的技术选择，还增强了企业的灵活性，使企业在快速变化的市场环境中始终保持竞争力。将UCS与软通动力应用交付平台相结合，企业将获得一套更高效、更可靠的运维解决方案。这套方案可以全面提高企业的运维能力，降低人工干预成本，提高交付质量，并确保技术路线的一致性。在此基础上，通过UCS云原生服务中心的引入，企业还能够快速接入各类热门开源工具平台，进一步提升企业的灵活性。这套解决方案将助力企业在激烈的市场竞争中脱颖而出，实现业务的持续发展。方案落地实践与价值某资产管理公司成立10年期间累积了不少软件资产，过于陈旧的研发体系以及日益膨胀的原始需求，使得他们迫切的想要进行云原生改造，实践DevOps来得到交付效率上的提升。在入场调研的过程中，我们发现其所面临的困境和金融业企业困境如出一辙：各个环境的割裂、没有统一的代码仓库、阶段流转靠U盘拷贝、散乱的依赖管理、缺失自动化构建能力以及没有统一规范的软件研发流程，全靠各个团队自由发挥。云原生DevOps专家团队面对这种实际场景，针对性的给出了架构设计和迁移改造方案。容器化改造客户原先的系统服务都是虚拟机部署，一个微服务需要单独规划一台4U8G的虚拟机，如此配置不易弹性伸缩且有巨大的资源浪费。专家团队顺势提出容器化改造，并且使用业界首个分布式云原生产品华为云UCS作为容器平台底座，同时给出微服务容器化改造的最佳实践，帮助客户快速迁移。统一代码仓库和制品仓库令人惊讶的是，客户没有统一的代码仓库和制品仓库，多个团队之间的代码资产各自管理。有些使用Git，有些使用SVN，更有甚者就未使用代码仓库。因此在代码从开发环境转换到测试环境、准生产环境时，通过U盘拷贝的形式，制品依赖更是如此。所以改造的下一步是统一必备的软件开发工具。综合考量各种因素后，我们为客户提供了Gitlab代码仓库、SWR镜像仓库以及nexus依赖仓库。统一的DevOps平台有了容器平台、代码仓库、镜像仓库等基础设施和软件开发平台，实践DevOps需要将这些平台结合起来，并提供持续交付的能力。软通动力应用交付平台完美匹配，其灵活的集成管理能力串联了多个研发工具链，给客户提供高效便捷的流水线配置体验。研发流程优化当基础配置全部准备完成后，此时需要流程规范和最佳实践进行指导。华为云UCS专家团队结合资产管理公司的组织架构以及业务结构，为客户量身定制了基于新平台的研发流程。从理论出发结合实际为客户实现云原生数字化转型。经过客户及华为云云原生团队的共同努力，客户业务最终完美的迁移到容器环境中。经过一段时间的学习、适应和磨合，客户按照DevOps的文化理念进行迭代、统一代码和制品仓库以及配置自动化流水线。据效能统计：人力管理成本平均减少70%、构建部署的频率提升十余倍、更改失败率降低、平均交付周期以及资源利用率都有了巨大的优化，顺利打破金融等行业的云原生、数字化转型困局。访问链接，体验华为云分布式云原生UCS：cid:link_0更多云原生技术动向关注容器魔方

KubeEdge社区v1.17.0 版本正式发布。新版本为边缘节点和设备带来了更多的新能力，同时持续在易用性上做了提升。KubeEdge v1.17.0 新增特性：支持边缘 Pods 使用 InClusterConfig 访问 Kube-APIServerMapper 支持流数据上报支持边缘子模块自启动引入 keadm ctl 命令，支持在边缘查询和重启 pod易用性提升：基于 Keadm 的部署能力增强Mapper 框架添加 MySQL 数据库升级 K8s 依赖到 v1.28  新特性概览   ▍支持边缘 Pods 使用 InClusterConfig 访问 Kube-APIServerKubernetes 支持 Pods 使用 InClusterConfig 机制直接访问 Kube-APIServer，然而在边缘场景，边缘 Pods 和 Kube-APIServer 通常不在一个网络环境下，无法直接访问。在1.17.0 新版本中，通过开启 MetaServer 和 DynamicController 模块，边缘 Pods 同样可以使用 InClusterConfig 机制直接访问 Kube-APIServer。该特性在本版本中作为 Alpha 特性发布，如果你需要使用，您需要开启边缘 List-Watch 开关并配置 requireAuthorization的featureGates。在使 keadm init 启动 CloudCore 时，指定 cloudCore.featureGates.requireAuthorization=true 以及 cloudCore.modules.dynamicController.enable=true。启动 EdgeCore 后，按如下修改 edgecore.yaml 后重启 EdgeCore。apiVersion: edgecore.config.kubeedge.io/v1alpha2 kind: EdgeCore featureGates: requireAuthorization: true modules: ... metaManager: metaServer: enable: true更多信息可参考：cid:link_3cid:link_4▍Mapper 支持流数据上报 1.17 版本中，针对当前 Mapper 只能处理离散型的设备数据，无法处理流数据的问题，为 Mapper-Framework 提供视频流数据处理的能力。在新版本中，能够支持 KubeEdge 管理边缘摄像头设备，获取摄像头采集的视频流，并将视频流保存为帧文件或者视频文件，增强 KubeEdge 边缘设备管理能力。边缘摄像头设备管理1.17 版本提供基于 Onvif 协议的内置 Mapper，实现 Onvif 设备驱动功能，能够根据用户配置文件中的定义连接摄像头设备，获取设备的鉴权文件与 RTSP 视频流，将 Onvif 摄像头设备纳管进 KubeEdge 集群。Onvif 设备的一个示例 device-instance 配置文件如下：apiVersion: devices.kubeedge.io/v1beta1 kind: Device metadata: name: onvif-device-01 namespace: default spec: deviceModelRef: name: onvif-model # need to be the same as the model name defined in onvif-model.yaml protocol: protocolName: onvif configData: url: 192.168.168.64:80 # Replace it with the address of your own onvif camera userName: admin # Replace it with the username of your own onvif camera password: /etc/secret/password # Fill in the fields according to your secret.yaml nodeName: edge-node # Replace it with your edge node name properties: - name: getURI visitors: protocolName: onvif configData: url: 192.168.168.64:80 userName: admin password: /etc/secret/password dataType: string视频流数据处理新版本增强 Mapper-Framework 数据面能力，内置流数据处理功能。用户能够在 device-instance 文件中进行配置，将边缘摄像头设备上报的视频流截取保存为视频片段文件以及视频帧文件，流数据处理的 device-instance 文件示例如下：apiVersion: devices.kubeedge.io/v1beta1 kind: Device metadata: name: onvif-device-01 ... properties: - name: saveFrame # Convert video stream into frame visitors: protocolName: onvif configData: format: jpg # Frame file format outputDir: /tmp/case/ # Directory for output frame files frameCount: 30 # Number of output frames frameInterval: 1000000 # Time interval between frames (The unit is nanoseconds) dataType: stream - name: saveVideo # Convert video streams into video clips visitors: protocolName: onvif configData: frameCount: 1000 # The number of frames the video clip contains format: mp4 # Video clip format outputDir: /tmp/case/ # Directory for output video clip videoNum: 2 # Number of video clips dataType: stream更多信息可参考：cid:link_5cid:link_6cid:link_2▍支持边缘子模块自启动由于配置或者可恢复的环境问题，例如进程启动顺序等，导致 EdgeCore 启动失败。例如，当 containerd.socket 没有就绪时，Edged 启动 Kubelet 失败会导致 EdgeCore 直接退出。在新版本中，我们改进了 Beehive 框架，支持边缘子模块重启。用户可以通过启动 moduleRestart featureGates，将 EdgeCore 的子模块设置为自动重启，而不是整个 EdgeCore 退出。该特性在本版本中作为 Alpha 特性发布，如果你需要使用，您需要配置 moduleRestart 的 featureGates。apiVersion: edgecore.config.kubeedge.io/v1alpha2 kind: EdgeCore featureGates: moduleRestart: true 更多信息可参考：cid:link_7cid:link_6▍引入 keadm ctl 命令，支持在边缘查询和重启 pod当边缘节点离线时，我们无法通过 kubectl 查看边缘节点上的 pod，在 1.17 中可以在边缘节点上通过 keadm ctl get/restart pod [flag] 对 pod 进行查询或重启。如果需要使用该特性，您需要开启 metaserver 开关。keadm ctl get pod 的可选参数如下：[root@centos-2 bin]# keadm ctl get pod -h Get pods in edge node Usage: keadm ctl get pod [flags] Flags: -A, --all-namespaces If present, list the requested object(s) across all namespaces. Namespace in current context is ignored even if specified with --namespace -h, --help help for pod -n, --namespace string Specify a namespace (default "default") -o, --output string Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file, custom-columns, custom-columns-file, wide) -l, --selector string Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2)keadm ctl restart pod 的可选参数如下：[root@centos-2 bin]# keadm ctl restart pod -h Restart pods in edge node Usage: keadm ctl restart pod [flags] Flags: -h, --help help for pod -n, --namespace string Specify a namespace (default "default")Demo 演示：[root@centos-2 bin]# alias kectl='keadm ctl' [root@centos-2 bin]# kectl get pod -owide -A NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES default nginx-deployment-58b54fbd94-f5q7p 1/1 Running 1 (20m ago) 22m 10.88.0.2 centos-2 kubeedge edge-eclipse-mosquitto-scvrk 1/1 Running 1 (16m ago) 28m 192.168.94.106 centos-2 [root@centos-2 bin]# kectl restart pod -n kubeedge edge-eclipse-mosquitto-scvrk 393cbcac4b484a4a28eee7dd2d63b33137a10a84d5f6eed6402b9a23efc6aef0 af4059137ced56b365da7e1c43d3ea218e3090ab7644a105651ca4661ddf26f0 [root@centos-2 bin]# kectl get pod -owide -A NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES default nginx-deployment-58b54fbd94-f5q7p 1/1 Running 1 (21m ago) 23m 10.88.0.2 centos-2 kubeedge edge-eclipse-mosquitto-scvrk 1/1 Running 2 (10s ago) 29m 192.168.94.106 centos-2 更多信息可参考：cid:link_8cid:link_9▍易用性提升：基于 Keadm 的部署能力增强将命令 keadm generate 更改为 keadm manifest；[root@centos-2 bin]# keadm --help|grep manifest manifest Checks and generate the manifests. example: [root@centos-1 keepalived]# keadm manifest --advertise-address= --profile version=v1.17.0在 keadm join 添加一个镜像仓库参数: image-repository，以支持自定义镜像仓库；[root@centos-2 bin]# keadm join -h|grep image-repository --image-repository string Use this key to decide which image repository to pull images from example: [root@centos-2 bin]# keadm join --cloudcore-ipport :10000 --kubeedge-version=1.17.0 --remote-runtime-endpoint=unix:///run/cri-dockerd.sock --image-repository my.harbor.cn/kubeedge --token xxxx 将 keadm reset 命令进行三级拆分，拆分成 keadm reset cloud 和 keadm reset edge, keadm reset 仍然被保留，使用时 cloudcore 和 edgecore 都会被卸载，新增的三级命令 keadm reset cloud 和 keadm reset edge 分别只卸载 cloudcore 和 edgecore。[root@centos-2 bin]# keadm reset --help ... Available Commands: cloud Teardowns CloudCore component edge Teardowns EdgeCore component Flags: --force Reset the node without prompting for confirmation -h, --help help for reset --kube-config string Use this key to set kube-config path, eg: $HOME/.kube/config (default "/root/.kube/config") [root@centos-2 bin]# keadm reset cloud --help ... Flags: --force Reset the node without prompting for confirmation -h, --help help for cloud --kube-config string Use this key to set kube-config path, eg: $HOME/.kube/config (default "/root/.kube/config") [root@centos-2 bin]# keadm reset edge --help ... Flags: --force Reset the node without prompting for confirmation -h, --help help for edge更多信息可参考：cid:link_1cid:link_10cid:link_11cid:link_12▍Mapper 框架添加 MySQL 数据库在 1.17 的 Mapper-Framework 中，数据推送模块新增了 MySQL 数据库,如果用户想使用 MySQL 作为某个 property 的 PushMethod，可以在 device instance 的对应 property 下， 通过如下配置即可：apiVersion: devices.kubeedge.io/v1beta1 kind: Device ... spec: properties: - name: xxx ... pushMethod: dbMethod: mysql: mysqlClientConfig: addr: 127.0.0.1:3306 #the url to connect to the mysql database. database: kubeedge #database name userName: root #user name更多信息可参考：cid:link_13▍升级 K8s 依赖到 v1.28新版本将依赖的 Kubernetes 版本升级到 v1.28.6，您可以在云和边缘使用新版本的特性。更多信息可参考：cid:link_14  版本升级注意事项  自 v1.17.0 起，我们推荐在使用 keadm 安装 KubeEdge 时使用 --kubeedge-version= 来指定具体版本，--profile version= 会逐渐废弃。▍致谢感谢 KubeEdge 社区技术指导委员会 (TSC)、各 SIG 成员对 v1.17 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_0 添加社区小助手k8s2222回复KubeEdge进入社区交流群