3月21日，在巴黎举办的云原生顶级峰会KubeCon+CloudNativeCon Europe 2024上 ，华为云首席架构师顾炯炯在 “Cloud Native x AI：以持续开源创新开启智能时代” 的主题演讲中指出，云原生和AI技术的融合，是推动产业深刻变革的关键所在。华为云将持续进行开源创新，与开发者共启智能时代。  ▲华为云首席架构师顾炯炯发表演讲AI对于云原生范式提出关键挑战在过去的几年里，云原生彻底改变了传统的IT系统，催化了互联网和政府服务等领域的数字飞跃。云原生范式带来的新的可能性，例如闪电般的快速销售和基于微服务治理的敏捷应用DevOps，已经深入人心。同时，人工智能的快速发展和广泛采用，包括大规模模型，已经成为行业智能的跳动心脏。根据Epoch 2023年的调研数据，基础模型所需的计算能力每18个月就会增长10倍，是摩尔定理揭示的通用计算能力增长率的5倍。AI带来的新摩尔定律和大规模AI模型的主导地位对云原生范式提出了挑战，顾炯炯总结了其中关键的4点：首先，低GPU/NPU平均利用率导致AI训练和推理的高成本；其次，大模型训练集群频繁的失败率限制了训练效率；第三，大规模模型的复杂配置导致AI开发门槛高；第四，大规模的AI推理部署面临着不可预测的最终用户访问延迟和数据隐私问题的风险。华为云AI创新为开发者迎接挑战提供思路随着AI模型变得越来越大，对计算能力的需求也呈指数级增长。这种需求不仅给云原生技术带来了挑战，也为业界提供了创新机遇。顾炯炯分享了一些华为云在AI创新方面的故事，为开发者解决这些挑战提供了参考。在云原生边缘计算平台KubeEdge的基础上，华为云实现了一个云原生多机器人调度管理平台。用户可以通过自然语言命令在云端输入任务指令，由系统协调边缘的多个机器人共同协作完成复杂任务。为了克服自然语言命令理解、大量机器人高效调度管理以及跨类型机器人访问管理的三个挑战，该系统采用了云端、边缘节点和机器人三个部分的架构，通过大模型执行自然语言命令，并进行流量预测、任务分配和路由规划。这一架构显著提高了机器人平台的灵活性，管理效率提升25%，系统部署周期缩短30%，新机器人的部署时间从月级缩短到天级。中国某顶级内容分享社区，每月活跃用户超过1亿。它的核心服务之一是主页上的推荐功能。推荐模型有近1000亿个参数。训练集群有数千个计算节点。一个训练作业需要数百个参数服务器和worker。因此，该社区对最优拓扑调度、高性能、高吞吐量有着强烈的需求。开源项目Volcano可以更好地支持在Kubernetes上运行的AI/ML工作负载，并提供了一系列作业管理和高级调度策略。Volcano项目引入了拓扑感知调度、装箱、SLA感知调度等算法，帮助社区将整体训练性能提升了20%，运维复杂度也大大降低。Serverless AI引领云原生发展趋势如何高效、稳定地运行AI应用，同时降低运营成本，成为摆在众多企业和开发者面前的一大挑战。为此，华为云总结了云原生AI平台的关键要求，提出了一种全新的云原生AI平台理念——Serverless AI。顾炯炯提到，从开发者的视角来看，Serverless AI致力于智能地推荐并行策略，让复杂的训练和推理任务变得轻而易举。它提供自适应的GPU/NPU自动扩展功能，能够根据工作负载的实时变化动态调整资源分配，确保任务的高效执行。同时，Serverless AI还维护着一个无故障的GPU/NPU集群，让开发者无需担心硬件故障带来的中断风险。更值得一提的是，该平台保持与主流AI框架的兼容性，让开发者能够无缝集成现有的AI工具和模型。对于云服务提供商而言，Serverless AI同样具有深远的意义。它不仅能够提高GPU/NPU的利用率，使训练、推理和开发混合工作负载得以高效运行，还能通过优化能效实现绿色计算，降低能耗成本。此外，Serverless AI平台还能实现跨多个租户的空间和时间GPU/NPU共享，提高资源的复用率。最重要的是，它为训练和推理任务提供了有保证的QoS和SLA，确保了服务质量和稳定性。Serverless AI平台采用了构建在操作系统和虚拟化之上的灵活的资源调度层，将应用程序框架的关键功能封装于应用资源中介层中。顾炯炯现场展示了Serverless AI平台的参考架构。他认为，这种架构设计，使得Serverless AI平台具有了大规模AI资源自动驱动引擎的特点，包括精确了解应用资源利用模式的资源分析，实现异构硬件资源池化的资源共享，基于GPU/NPU虚拟化和负载热迁移的AI训练任务容错能力，以及提高资源利用率的多维度调度和自适应弹性伸缩等优点。分论坛上，华为云技术专家提到，Kubernetes上运行AI/ML工作负载的使用量不断增加，许多公司在分布于数据中心和各种GPU类型的多个 Kubernetes 集群上构建云原生AI平台。使用Karmada和Volcano，可轻松实现多集群的GPU工作负载智能调度、集群故障转移支持，在保障集群内和跨集群的两级调度一致性和效率，并平衡系统整体资源的利用率和不同优先级工作负载的QoS，以应对大规模、异构的GPU环境管理中面临的挑战。Karmada为多云和混合云场景中的多集群应用管理提供即时可用的自动化管理，越来越多的用户在生产环境中使用Karmada构建灵活高效的解决方案。Karmada已于2023年正式升级为CNCF孵化项目，期待与更多伙伴与开发者们共建繁荣社区。Volcano与主流AI/大数据框架实现了无缝集成，有效解决了AI/大数据任务的作业管理，资源分配，资源调度等问题与挑战，为业界提供了分布式作业训练的最佳实践。在大模型日新月异的今天，Volcano将持续发力，解决多集群AI任务调度等难题，助推大模型训练与推理快速发展。“云原生技术的敏捷性和异构AI计算平台的创新性，将是提升AI生产力的关键。” 顾炯炯谈到，未来，华为云将持续致力于开源创新，与业界同仁、伙伴共同开启智能时代的新篇章。更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

还在为K8s集群繁琐的资源管理投入大量的运维时间和人力？还在担心K8s集群节点伸缩不够及时或者不合理导致成本浪费？华为云Serverless K8s服务 CCE Autopilot通过资源全托管的方式让基础设施免运维，为用户节省运维成本，通过高效精准的弹性灵活应对业务的平峰和洪峰，为用户节省资源成本。3月13日16:30 -18:00，华为云云原生DTSE技术布道师颜栎将带来《CCE Autopilot：华为云容器全面进入“自动驾驶”时代 》直播分享。本期直播将聚焦企业集群运维痛点提供Serverless最新方案，系统化介绍华为云CCE Autopilot带来的全新集群服务体验。使用华为云CCE Autopilot进行集群节点全托管，无需配置和运维基础设施，帮你自动部署、扩展和管理容器化应用程序，高效构建业务，运维效率提升90%。华为云CCE Autopilot，应运而生的Serverless K8s服务资源设施全托管，节点免运维，降低运维成本，让用户聚焦业务创新；资源精益管理，通过FinOps提供成本治理能力，提升资源利用率，降低资源成本；业界领先弹性速度，4,000Pod/30s，高效弹，精准弹，灵活应对业务洪峰和平峰，实现稳敏双修；面向不同场景提供通用负载、SMB（中长尾）负载、AI负载、Batch负载的场景化调优能力；直播观看平台华为云官网 华为云开发者联盟视频号、CSDN、B站、虎牙、微博华为云视频号、快手、B站、虎牙、微博▍本期直播精彩看点CCE Autopilot，提供业务运行最优的云原生基础设施：1. 集群节点全面托管，基础设施自动升级。2.故障实时监测与自愈，漏洞自动修复。集群管理“无极变速”：1. 集群规格自动调整，取消规格档位限制。2. 资源使用“无级变速”，算力资源灵活规格档位，去Flavor化。智能弹性，动态感知业务特征，自动预测触发弹性华为云CCE Autopilot提供Serverless服务体验的同时，保留了用户对资源的可见性满足了部分客户对资源灵活管理的需求。此外，CCE Autopilot完全兼容K8s接口，及时跟随K8s社区动态，用户可以从普通的K8s集群平滑迁移到CCE Autopilot，立即省去节点运维投入。扫描下方二维码体验华为云CCE Autopilot▼▼▼

中奖结果公示感谢各位小伙伴参与本次活动，欢迎关注华为云DTSE Tech Talk 技术直播更多活动~本次活动获奖名单如下：请于3月20日下班前在此问卷中反馈您的中奖邮寄信息~直播简介【直播主题】CCE Autopilot：华为云容器全面进入“自动驾驶”时代【直播时间】2024年3月13日 16:30-18:00【直播专家】颜栎 华为云云原生DTSE技术布道师【直播简介】华为云容器已全面进入“自动驾驶”时代！ CCE Autopilot为你带来基于Serverless基础设施的企业级Kubernetes集群服务，集群节点全托管，无需配置和运维基础设施，运维效率提升90%。提供应用智能调度，极致弹性等管理编排能力，帮你自动部署、扩展和管理容器化应用程序，高效构建业务。观看直播：cid:link_1活动介绍【互动方式】直播前您可以在本帖留下您疑惑的问题，专家会在直播时为您解答。直播后您可以继续在本帖留言，与专家互动交流。我们会在全部活动结束后对参与互动的用户进行评选。【活动时间】即日起—2024年3月14日【奖励说明】评奖规则：活动1：直播期间在直播间提出与直播内容相关的问题，对专家评选为优质问题的开发者进行奖励。奖品：华为云定制键盘活动2：在本帖提出与直播内容相关的问题，由专家在所有互动贴中选出最优问题贴的开发者进行奖励。奖品：华为云定制U型按摩枕更多直播活动直播互动有礼：官网直播间发口令“华为云 DTSE”抽华为云定制雨伞、填写问卷抽华为云定制Polo衫等好礼。【注意事项】1、所有参与活动的问题，如发现为复用他人内容或直播间中重复内容，则取消获奖资格。2、为保证您顺利领取活动奖品，请您在活动公示奖项后2个工作日内私信提前填写奖品收货信息，如您没有填写，视为自动放弃奖励。3、活动奖项公示时间截止2024年3月15日，如未反馈邮寄信息视为弃奖。本次活动奖品将于奖项公示后30个工作日内统一发出，请您耐心等待。4、活动期间同类子活动每个ID（同一姓名/电话/收货地址）只能获奖一次，若重复则中奖资格顺延至下一位合格开发者，仅一次顺延。5、如活动奖品出现没有库存的情况，华为云工作人员将会替换等价值的奖品，获奖者不同意此规则视为放弃奖品。6、其他事宜请参考【华为云社区常规活动规则】。

全球顶级开源组织云原生计算基金会(Cloud Native Computing Foundation，简称 CNCF)正式宣布其2024年技术监督委员会(Technical Oversight Committee，简称CNCF TOC)席位，华为云云原生开源负责人王泽锋，凭借其在CNCF领域长期卓越的贡献成功当选，成为本届 CNCF TOC 11位技术领军人物之一。CNCF致力于云原生技术的普及和可持续发展，汇集世界顶级厂商，发展至今会员单位已超过750+。CNCF技术监督委员会是CNCF的核心决策团队，为云原生社区提供技术领导，决定CNCF社区的技术走向，由董事会、Maintainer以及End User等多个选区投票产生。一直以来，CNCF TOC主要以欧美专家为主，本届选举中，华为云开源专家王泽锋获得CNCF Maintainer广泛支持，凭借Maintainer选区最高票当选新一届CNCF TOC委员（2024-2026任期）。这也标志着其个人及华为在云原生领域的持续贡献获得产业界的高度认可，代表了整个中国本土贡献者在国际舞台上开源影响力的新高度。云原生产业规模和前景巨大，不少技术领域仍然处于窗口期，可谓机遇与挑战并存。王泽锋表示：“中国在全球云原生产业发展中拥有非常明显的优势：巨大的数字经济规模、丰富的应用场景，不断推动技术层面的创新；不少本土科技公司凭借技术实力已在云原生的核心赛道中占据了重要位置。作为CNCF TOC的新任成员，我将致力于更好地联接国内以及国际开源社区，借助CNCF、华为等平台及资源，携手更多企业、开源组织、学术机构及广大开发者一起，共同推动云原生技术发展与产业标准化，赋能千行万业的数字化转型。”王泽锋：协作创新，共建更有生命力的开源社区作为最早来自中国的Kubernetes维护者之一，王泽锋早在2014年基于 Upstream first 的理念，参与 Kubernetes 上游社区贡献，并于2015年成为了国内最早的 Kubernetes maintainer 之一，其主导的 Kubernetes 社区的多个关键特性和子项目的设计研发工作在社区完成开发后被大量企业用户在生产环境中广泛使用；与此同时，他指导了超过30名开发人员成为Kubernetes和其他CNCF项目的业务骨干、核心开发者。2018 年，王泽锋与同事联合创立了业界首个云原生边缘计算项目KubeEdge 开源项目，并捐赠到 CNCF 基金会，通过开放社区的治理模式与业界开发者协作共享。KubeEdge 也因此成为 CNCF 第一个将云原生技术应用到边缘计算的开源项目。时至今日，KubeEdge 在交通、能源、通信、金融、工业制造、CDN、智慧园区等各行各业已经有了更加深广的应用和普惠价值。此外，他还发起了 Volcano云原生批量计算 、Karmada云原生多集群管理 等多个云原生开源项目，填补了云原生技术在相关领域的技术空白。作为CNCF中国大使，王泽锋在KubeCon + CloudNativeCon 程序委员会任职多年，并于 2023 年担任 KubeCon + CloudNativeCon China 联合主席。作为公认的演讲者，王泽锋多次在 KubeCon Europe 和 KubeCon China 上发表Keynote和分论坛议题演讲。此外，王泽锋一直是Kubernetes贡献者峰会的长期支持者，联合规划和组织多场KCS China、KCD，并从2018年开始，联合策划了 “Cloud Native Days China”系列 Meetup、“Cloud Native Lives”等一系列业内活动；与此同时，由他发起的系列云原生技术公共课程，帮助超过百万的中国开发者构筑云原生技术交流平台，学习和采用云原生技术。技术先驱，引领全球云原生生态圈作为CNCF亚洲唯一创始成员、白金成员，华为对 Kubernetes、Istio 等社区核心项目的贡献一直位居全球前列，社区影响力持续多年亚洲第一，加速了云原生技术从起步到成熟的过程；华为拥有10余位CNCF项目核心Maintainer，出版多部云原生领域技术书籍，是全球云原生开源技术的领导者之一。近年来，华为持续开源创新，先后向CNCF捐献业界首个云原生边缘计算项目KubeEdge、首个云原生算力调度引擎Volcano、首个多云容器编排引擎Karmada等重量级云原生项目，在网络、边缘、调度、多云等技术领域形成了相对成熟生态圈，并开源了Kurator、Kappital、Kuasar、Kmesh等创新项目，加速了云原生与边缘计算、AI、大数据等产业的融合。共享开源价值，为行业发展注入源生动力在数字经济快速演进的大背景下，开源作为数智化转型的创新驱动力，不断催生技术突破和业务创新，发挥出愈加凸显的价值。华为与业界分享生产实践经验及创新成果，与国际云原生社区共发展。未来，面向全球的云原生社区工作有何创新？王泽锋提出了他对CNCF TOC的愿景和其独特的价值：促进跨区域新贡献者和现有贡献者之间的经验分享和沟通。建立公共的维护者地图，帮助新加入的贡献者找到周围的维护者以获得支持和帮助，以新一代的维护者增进社区活力，促进项目的可持续性。建立项目导师和项目冠军机制，帮助加快新开源项目向CNCF的申请/引导过程，以及项目在CNCF沙盒和孵化器中的成长。更清晰的项目推进过程和相应的自动化工具，以减少项目维护者和TOC/TAG成员在观察和评估项目健康和项目成熟度方面所花费的时间。云原生+AI，开源加速构建AI基础设施面对AI时代迎面而来的挑战，华为云在云原生领域持续引领，打造多云场景下的AI云原生基础设施，加速构建AI时代最佳云底座。作为全球最早参与CNCF重点项目产品化的企业之一，华为云早在2015年基于Kubernetes、Istio等上游社区，推出了国内最早的商用容器产品，并于2016年发布国内首个公有云容器服务CCE（云容器引擎）。伴随华为云近年来的高速发展，目前华为云已经陆续发布Serverless容器CCI、应用服务网格ASM、智能边缘平台IEF、分布式云原生UCS等多个创新产品，连续七次登顶IDC发布的中国容器市场份额报告，这也是业界对华为云在容器领域一路领先给与的充分肯定。智能浪潮新形势下，华为云结合在云原生领域的领先优势，打造云原生多云融合基础设施，云原生AI基础设施，云原生Serverless基础设施等系列解决方案，陆续升级发布华为云CCE Turbo，华为云CCE Autopilot，Serverless云耀云容器等创新产品。由华为云开源并捐赠至CNCF的孵化级开源项目也在AI云边协同、AI混部调度、多集群算力分配等技术领域加速行业产品应用升级，为行业智能升级攻坚克难，注入源生动力。未来，华为云云原生将持续与全球开发者紧密合作，共同推进云原生技术的创新与发展，积极推动云原生技术在产业领域的深度融合应用，为促进全球数智化经济的繁荣发展贡献力量。更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

二月问题总结如下：【1】在ECS windows部署Llama2 尝试使用MLC运行，但出现以下报错，求助cid:link_0【2】atlas300P3 在容器中访问rtsp流地址报错No route to host cid:link_1【3】ECS上面，我看机器学习推荐的只有N卡，想问下华为自己的显卡在ModelArts那边不是能用，为啥还没上ECS cid:link_2【4】昇腾310（Ascend 310）能不能用来搭建stable diffusecid:link_3【5】 acl init failed, errorCode = 100039cid:link_4

作者：本文由华为云客户迷你玩投稿背景迷你玩旗下《迷你世界》是一款国产沙盒创意平台，拥有全球数千万创作者进行去中心化内容创作，通过方块组合自由创造等方式，引导用户在平台上创作虚拟作品。2021《迷你世界》的每月活跃玩家人数已超过一亿。《迷你世界》此前面临的突出问题在于服务端的弹性：迷你世界服务器的规格较大，每个服务器上承载了很多游戏服进程，不同玩家的游戏时间上差异也比较大，为了保障深度玩家的游戏体验，即使只有一个玩家还在进行游戏，对应的游戏服务器也是不会缩容的，这必然会影响服务端整体的资源利用率和运营成本。我们期望通过容器灵活规格来解决《迷你世界》服务端的缩容问题，同时提升整个游戏系统的扩缩容、部署升级效率。挑战云原生技术以其灵活性、可扩展性和可维护性等优势，正在迅速改变企业的 IT 架构。第三方报告显示，2022年已经有超过75%的互联网公司在基于K8s部署生产业务，预期2025年这个数字将超过90%。然而在游戏场景中，k8s的还面临一些局限性。首先，游戏业务天然是有状态的，K8S原生的有状态资源StatefulSet并不擅长处理大量的、复杂的状态管理任务。其次，时延敏感性也是一个问题。在游戏中，时延直接影响到游戏的流畅度和玩家的体验，这就对K8s的容器网络实现提出了更高的要求。同时，安全性也是一个挑战。游戏服中可能包含大量的敏感信息，普通容器的隔离程度与虚拟化相比仍有一定差距。解决方案华为云CCE在网络、容器运行时上进行了增强，再配合社区workload，使能《迷你世界》后端全栈容器化，资源使用量较虚拟化部署环境减少了50+%。整体架构如下：网络方面，华为云CCE Turbo提供了一种更接近虚拟机的容器网络，这种模式下，容器成为和虚拟机等同的“一等公民”。容器网卡集成了虚拟网络的能力，比如通过CRD关联到安全组进行安全加固，更细粒度的IP地址管理等。更重要的是，这种容器网络支持Pod直接关联EIP，用户可以直接通过EIP访问应用。EIP的成本管理上，华为云提供了95计费的共享带宽，以多个EIP共享的带宽为计费单元。我们开发了专门的K8s webhook为不同的pod分配不同的共享带宽，来做到最优的成本控制。有状态应用管理方面：我们使用了OpenKruise社区的CloneSet来管理游戏服pod。CloneSet提供了pod的原地升级能力，可以在不重建pod的情况下对运行中的容器进行更新。我们还深度使用了它的定向缩容能力，通过自定义Hooks判断指定游戏服pod是否有活跃玩家，实现对游戏服缩容的精细化控制。OpenKurise的CRD配合控制器的模式在不同的K8s环境中具有良好的扩展性，只要厂商提供社区一致的API，均可正常部署运行。安全方面，当前我们的使用方式是服务端Pod与节点1:1部署，游戏服pod配置关联指定安全组，通过安全组和虚拟化对游戏服进行双重安全加固。效果《迷你世界》完成全量容器化后，在运维效率、资源成本都有了显著优化资源占用节省50%计算资源根据游戏的实施访问量自动管理，定时弹性伸缩配合指标触发的自动弹性伸缩，再加上定向缩容，资源总是能伸缩至合理水平，保障玩家的游戏体验。迭代效率提升容器化缩短了应用的迭代周期，通过灰度发布，流量治理等保证了业务平滑稳定升级，应用升级从小时级提升至分钟级。迷你玩和华为云在未来将Serverless领域加深合作：华为云容器实例服务CCI具有秒级弹性、按量计费的特性，非常贴合我们的应用场景。此外，华为云CCE提供弹性突发引擎，可以将CCI资源池以虚拟节点的方式接入CCE。基于这项能力，我们仅需将与节点强绑定的部分资源稍作调整即可将应用部署到Serverless容器服务中，进一步提升后端的弹性能力。同时CCI基于安全容器构建，独享内核，具有虚拟机级别的安全保障。下一阶段，我们考虑将部分负载逐步迁移到Serverless容器上。

北京时间2024年1月23日，KubeEdge 发布 1.16.0 版本。新版本新增多个增强功能，在集群升级、集群易用性、边缘设备管理等方面均有大幅提升。KubeEdge v1.16.0 新增特性：集群升级：支持云边组件自动化升级支持边缘节点的镜像预下载支持使用 Keadm 安装 Windows 边缘节点增加多种容器运行时的兼容性测试EdgeApplication 中支持更多 Deployment 对象字段的 Override支持基于 Mapper-Framework 的 Mapper 升级DMI 数据面内置集成 Redis 与 TDEngine 数据库基于 Mapper-Framework 的 USB-Camera Mapper 实现易用性提升：基于 Keadm 的部署能力增强升级 K8s 依赖到 v1.27  新特性概览 ▍集群升级：支持云边组件自动化升级随着 KubeEdge 社区的持续发展，社区版本不断迭代；用户环境版本升级的诉求亟需解决。针对升级步骤难度大，边缘节点重复工作多的问题，v1.16.0 版本的 KubeEdge 支持了云边组件的自动化升级。用户可以通过 Keadm 工具一键化升级云端，并且可以通过创建相应的 Kubernetes API，批量升级边缘节点。云端升级云端升级指令使用了三级命令与边端升级进行了区分，指令提供了让用户使用更便捷的方式来对云端的 KubeEdge 组件进行升级。当前版本升级完成后会打印 ConfigMap 历史配置，如果用户手动修改过 ConfigMap，用户可以选择通过历史配置信息来还原配置文件。我们可以通过 help 参数查看指令的指导信息：keadm upgrade cloud --help Upgrade the cloud components to the desired version, it uses helm to upgrade the installed release of cloudcore chart, which includes all the cloud components Usage: keadm upgrade cloud [flags] Flags: --advertise-address string Please set the same value as when you installed it, this value is only used to generate the configuration and does not regenerate the certificate. eg: 10.10.102.78,10.10.102.79 -d, --dry-run Print the generated k8s resources on the stdout, not actual execute. Always use in debug mode --external-helm-root string Add external helm root path to keadm --force Forced upgrading the cloud components without waiting -h, --help help for cloud --kube-config string Use this key to update kube-config path, eg: $HOME/.kube/config (default "/root/.kube/config") --kubeedge-version string Use this key to set the upgrade image tag --print-final-values Print the final values configuration for debuging --profile string Sets profile on the command line. If '--values' is specified, this is ignored --reuse-values reuse the last release's values and merge in any overrides from the command line via --set and -f. --set stringArray Sets values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --values stringArray specify values in a YAML file (can specify multiple)升级指令样例：keadm upgrade cloud --advertise-address= --kubeedge-version=v1.16.0边端升级v1.16.0版本的KubeEdge支持通过 NodeUpgradeJob 的 Kubernetes API 进行边缘节点的一键化、批量升级。API 支持边缘节点的升级预检查、并发升级、失败阈值、超时处理等功能。对此，KubeEdge 支持了云边任务框架。社区开发者将无需关注任务控制、状态上报等逻辑实现，只需聚焦云边任务功能本身。升级 API 样例：apiVersion: operations.kubeedge.io/v1alpha1 kind: NodeUpgradeJob metadata: name: upgrade-example labels: description: upgrade-label spec: version: "v1.16.0" checkItems: - "cpu" - "mem" - "disk" failureTolerate: "0.3" concurrency: 2 timeoutSeconds: 180 labelSelector: matchLabels: "node-role.kubernetes.io/edge": "" node-role.kubernetes.io/agent: ""兼容测试KubeEdge 社区提供了完备的版本兼容性测试，用户在升级时仅需要保证云边版本差异不超过 2 个版本，就可以避免升级期间云边版本不一致带来的问题。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5330https://github.com/kubeedge/kubeedge/pull/5229https://github.com/kubeedge/kubeedge/pull/5289▍支持边缘节点的镜像预下载新版本引入了镜像预下载新特性，用户可以通过 ImagePrePullJob的 Kubernetes API 提前在边缘节点上加载镜像，该特性支持在批量边缘节点或节点组中预下载多个镜像，帮助减少加载镜像在应用部署或更新过程，尤其是大规模场景中，带来的失败率高、效率低下等问题。镜像预下载API示例：apiVersion: operations.kubeedge.io/v1alpha1 kind: ImagePrePullJob metadata: name: imageprepull-example labels: description:ImagePrePullLabel spec: imagePrePullTemplate： images: - image1 - image2 nodes： - edgenode1 - edgenode2 checkItems: - "disk" failureTolerate: "0.3" concurrency: 2 timeoutSeconds: 180 retryTimes: 1 更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5310https://github.com/kubeedge/kubeedge/pull/5331▍支持使用 Keadm 安装 Windows 边缘节点KubeEdge 1.15.0 版本实现了在 Windows 上运行边缘节点，在新版本中，我们支持使用安装工具 Keadm 直接安装 Windows 边缘节点，操作命令与 Linux 边缘节点相同，简化了边缘节点的安装步骤。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/4968▍增加多种容器运行时的兼容性测试新版本中新增了多种容器运行时的兼容性测试，目前已集成了containerd，docker，isulad 和 cri-o 4种主流容器运行时，保障 KubeEdge 版本发布质量，用户在安装容器运行时过程中也可以参考该PR中的适配安装脚本。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5321▍EdgeApplication 中支持更多 Deployment 对象字段的 Override在新版本中，我们扩展了 EdgeApplication 中的差异化配置项（overriders），主要的扩展有环境变量、命令参数和资源。当您不同区域的节点组环境需要链接不同的中间件时，就可以使用环境变量（env）或者命令参数（command, args）去重写中间件的链接信息。或者当您不同区域的节点资源不一致时，也可以使用资源配置（resources）去重写cpu和内存的配置。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5262https://github.com/kubeedge/kubeedge/pull/5370▍支持基于Mapper-Framework的 Mapper 升级1.16.0 版本中，基于 Mapper 开发框架 Mapper-Framework 构建了 Mapper 组件的升级能力。新框架生成的 Mapper 工程以依赖引用的方式导入原有 Mapper-Framework 的部分功能，在需要升级时，用户能够以升级依赖版本的方式完成，简化 Mapper 升级流程。Mapper-Framework 代码解耦:1.16.0 版本中将 Mapper-Framework 中的代码解耦为用户层和业务层。用户层功能包括设备驱动及与之强相关的部分管理面数据面能力，仍会随 Mapper-Framework 生成在用户 Mapper 工程中，用户可根据实际情况修改。业务层功能包括 Mapper向云端注册、云端下发Device列表等能力，会存放在kubeedge/mapper-framework 子库中。Mapper 升级框架:1.16.0 版本 Mapper-Framework 生成的用户 Mapper 工程通过依赖引用的方式使用 kubeedge/mapper-framework 子库中业务层功能，实现完整的设备管理功能。后续用户能够通过升级依赖版本的方式达到升级 Mapper 的目的，不再需要手动修改大范围代码。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5308https://github.com/kubeedge/kubeedge/pull/5326▍DMI 数据面内置集成 Redis 与TDEngine数据库1.16.0 版本中进一步增强 DMI 数据面中向用户数据库推送数据的能力，增加 Redis 与 TDengine 数据库作为内置数据库。用户能够直接在 device-instance 配置文件中定义相关字段，实现 Mapper 自动向 Redis 与 TDengine 数据库推送设备数据的功能，相关数据库字段定义为：type DBMethodRedis struct { // RedisClientConfig of redis database // +optional RedisClientConfig *RedisClientConfig `json:"redisClientConfig,omitempty"` } type RedisClientConfig struct { // Addr of Redis database // +optional Addr string `json:"addr,omitempty"` // Db of Redis database // +optional DB int `json:"db,omitempty"` // Poolsize of Redis database // +optional Poolsize int `json:"poo lsize,omitempty"` // MinIdleConns of Redis database // +optional MinIdleConns int `json:"minIdleConns,omitempty"` }type DBMethodTDEngine struct { // tdengineClientConfig of tdengine database // +optional TDEngineClientConfig *TDEngineClientConfig `json:"TDEngineClientConfig,omitempty"` } type TDEngineClientConfig struct { // addr of tdEngine database // +optional Addr string `json:"addr,omitempty"` // dbname of tdEngine database // +optional DBName string `json:"dbName,omitempty"` }更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5064▍基于Mapper-Framework的USB-Camera Mapper实现基于KubeEdge 的 Mapper-Framework，新版本提供了 USB-Camera 的 Mapper 样例，该 Mapper 根据 USB 协议的 Camera 开发，用户可根据该样例和 Mapper-Framework 更轻松地开发具体业务相关的 Mapper。在样例中提供了 helm chart 包，用户可以通过修改 usbmapper-chart/values.yaml 部署 UBS-Camera Mapper，主要添加 USB-Camera 的设备文件, nodeName, USB-Camera 的副本数，其余配置修改可根据具体情况而定，通过样例目录中的 Dockerfile 制作 Mapper 镜像。global: replicaCounts: ...... cameraUsbMapper: replicaCount: 2 #USB-Camera的副本数 namespace: default ...... nodeSelectorAndDevPath: mapper: - edgeNode: "edgenode02" #USB-Camera连接的缘节点nodeName devPath: "/dev/video0" #USB-Camera的设备文件 - edgeNode: "edgenode1" devPath: "/dev/video17" ...... USB-Camera Mapper 的部署命令如下：helm install usbmapper-chart ./usbmapper-chart更多信息可参考：https://github.com/kubeedge/mappers-go/pull/122▍易用性提升：基于 Keadm 的部署能力增强添加云边通信协议配置参数在 KubeEdge v1.16.0 中，使用keadm join边缘节点时，支持使用--hub-protocol 配置云边通信协议。目前 KubeEdge 支持 websocket 和 quic 两种通信协议，默认为 websocket 协议。命令示例：keadm join --cloudcore-ipport <云节点ip>:10001 --hub-protocol=quic --kubeedge-version=v1.16.0 --token=xxxxxxxx说明：当--hub-protocol设置为 quic 时，需要将--cloudcore-ipport的端口设置为10001，并需在CloudCore的ConfigMap中打开quic开关，即设置modules.quic.enable为true。操作示例：使用 kubectl edit cm -n kubeedge cloudcore，将 quic 的 enable 属性设置成 true，保存修改后重启 CloudCore的pod。modules： ...... quic: address: 0.0.0.0 enable: true #quic协议开关 maxIncomingStreams: 10000 port: 10001 ......更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5156keadm join 与 CNI 插件解耦在新版本中，keadm join边缘节点时，不需要再提前安装 CNI 插件，已将边缘节点的部署与 CNI 插件解耦。同时该功能已同步到 v1.12 及更高版本，欢迎用户使用新版本或升级老版本。说明：如果部署在边缘节点上的应用程序需要使用容器网络，则在部署完 EdgeCore 后仍然需要安装 CNI 插件。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5196▍升级 K8s 依赖到 v1.27新版本将依赖的 Kubernetes 版本升级到 v1.27.7，您可以在云和边缘使用新版本的特性。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5121  版本升级注意事项  新版本我们使用 DaemonSet 来管理边端的 MQTT 服务 Eclipse Mosquitto 了，我们能够通过云端 Helm Values 配置来设置是否要开启 MQTT 服务。使用 DaemonSet 管理 MQTT 后，我们可以方便的对边端 MQTT 进行统一管理，比如我们可以通过修改 DaemonSet 的配置将边端 MQTT 替换成 EMQX。但是如果您是从老版本升级到最新版本，则需要考虑版本兼容问题，同时使用原本由静态 Pod 管理的 MQTT 和使用新的 DaemonSet 管理的 MQTT 会产生端口冲突。兼容操作步骤参考：1、您可以在云端执行命令，将旧的边缘节点都打上自定义标签kubectl label nodes --selector=node-role.kubernetes.io/edge without-mqtt-daemonset=""2、您可以修改 MQTT DaemonSet 的节点亲和性nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - ... - key: without-mqtt-daemonset operator: Exists3、将节点 MQTT 改为由 DaemonSet 管理# ------ 边端 ------ # 修改/lib/systemd/system/edgecore.service，将环境变量DEPLOY_MQTT_CONTAINER设置成false # 这步可以放在更新EdgeCore前修改，这样就不用重启EdgeCore了 sed -i '/DEPLOY_MQTT_CONTAINER=/s/true/false/' /etc/systemd/system/edgecore.service # 停止EdgeCore systemctl daemon-reload && systemctl stop edgecore # 删除MQTT容器，Containerd可以使用nerdctl替换docker docker ps -a | grep mqtt-kubeedge | awk '{print $1}' | xargs docker rm -f # 启动EdgeCore systemctl start edgecore # ------ 云端 ------ # 删除节点标签 kubectl label nodes without-mqtt-daemonset新版本的 keadm join 命令会隐藏 with-mqtt 参数，并且将默认值设置成 false，如果您还想使用静态 Pod 管理 MQTT，您仍然可以设置参数--with-mqtt来使其生效。with-mqtt 参数在 v1.18 版本中将会被移除。  致谢  感谢 KubeEdge 社区技术指导委员会(TSC)、各 SIG 成员对 v1.16.0 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_0更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

Kurator 是华为云开源的面向分布式云原生环境的一站式解决方案。它利用 Karmada 作为多集群编排基础，内置集成了Istio、Prometheus、Thanos、Volcano、KubeEdge、Argo 等主流云原生技术。基于此，Kurator 构建了包括集群舰队管理、集群生命周期管理、统一应用分发、流量治理、监控和策略管理在内的分布式云平台管理能力。在最新 0.6.0 版本中，Kurator 为云原生应用增加了 CI/CD 流水线设置与管理功能，简化流水线创建。此外，强化了 0.4.0 版本发布的统一应用分发功能，可以在部署新应用时设置金丝雀（灰度）发布、A/B 测试、蓝绿发布三种渐进式发布策略。新增的流水线特性和渐进式发布功能与统一分发能力结合，实现基于代码仓库的 GitOps 工作流。这有助于快速构建分布式云原生平台，简化应用开发与发布流程。Kurator CI/CD 的结构图如下所示：用户更新代码仓库后，触发 Kurator 流水线，完成代码拉取、检查、编译并构建镜像。其后，用户更新应用部署模板，例如更改应用配置中的镜像信息。Kurator Application Controller 侦测到配置更新，将自动触发已应用的渐进式发布策略，实现应用的自动发布。如此一来，整个软件研发生命周期以代码为中心，实现开发至发布完整流程的自动化，简化运维、部署工作。  流水线  CI/CD 流水线实现源码到发布的自动化过程，包括源码管理、检查、测试等阶段。但由于每个阶段技术需求不同，导致流水线配置和管理难度大。Kurator 参考开源项目 Tekton，通过预定义常用任务模版的方式简化流水线创建操作。用户只需指定任务名称和代码仓库访问凭证即可创建流水线，使用门槛低。对熟悉流水线的高级用户，Kurator 也支持自定义任务。用户可以根据自己需求定制任务内容，满足个性化场景。通过预置任务模板和自定义任务的能力，Kurator 大幅简化了流水线配置和管理的难度。从图中可以看出，在使用流水线时，Kurator 完成了大部分工作。用户只需配置运行环境，选择任务模板即可完成流水线创建，大大减少学习成本。特别是与传统Tekton 相比，Kurator 提供了预定义任务模板，用户只关注任务内容而不再处理具体实现，实现了流水线使用的极致简化。除了简化流水线的创建操作外，Kurator 还考虑到了软件供应链安全，可以在流水线构建镜像时自动为其添加数字签名和源头证明，以防范假冒镜像，保证镜像源头可靠，保证在镜像制作方面的安全性。软件供应链安全指的是保护软件从开发到部署的整个生命周期过程中的安全性。软件供应链安全可以提高软件安全性能和用户信任度，预防恶意代码渗透。签名和证明添加后，镜像将自动上传至仓库。在镜像仓库中可以直接查看镜像签名和证明的详细情况，如图所示。用户可以用签名过程生成的公钥验证镜像签名和源头。这样在生产中,生产者仅需公布签名公钥，就能让用户验证数字签名和来源证明。接下来将展示一个在 Kurator 中创建一个流水线的示例：在流水线定义 spec.tasks 中指定任务名称，即可选择 Kurator 内置的常用任务模板。目前内置的常用任务模板包括:名称任务目标git-clone拉取源码go-test运行go代码单元测试go-lintgo源码静态检查build-and-push-image编译，构建镜像并上传此外，通过 customTask 定义可以发布自定义任务。通过指定 image、command 和 args,实现定制任务需求，如上述示例中自定义任务完成的工作就是打印README.md。更多的示例和细节，请参考: https://kurator.dev/docs/pipeline/  渐进式发布  金丝雀发布、A/B 测试和蓝绿发布都是主流的应用发布策略，可有效减少上线风险。Kurator 0.6.0 在原统一应用分发基础上，增加渐进式发布功能。现在应用可以指定三种渐进式发布策略中的一种策略。同时，可以将具备发布能力的统一分发，与 CI/CD 流水线结合起来，实现基于代码仓库的 GitOps 工作流。▍金丝雀发布金丝雀部署是一种渐进式发布策略。先向少数用户发布新的软件版本进行测试，根据测试结果，决定是否向更多用户推出新版本。旨在最大限度地减少新版本上线后对用户的影响，是一种更安全、更可靠的软件发布策略。参阅以下的操作示例，了解如何使用 Kurator 配置金丝雀发布。通过配置 rollout 中的 workload 字段，可以将金丝雀发布的目标设置为 webapp 命名空间下名为 backend 的应用。发布目标除了支持 deployment 应用之外，还支持 daemonSet应用。流量分析使用 Kurator 内置的请求成功率（request-sueccess-rate）和平均访问时延（request-duration）两个指标作为衡量新版本是否健康的标准。其中通过 thresholdRange 指定阈值。示例中要求请求成功率大99%，平均访问时延小于 500ms，新版本的服务才会被认定为健康。rolloutPolicy.canaryStrategy 配置了每次测试成功后，下次流量递增的比例和最终允许测试版本流量占比的最大值，从而实现渐进式发布新版本。示例中每次递增 10% 的流量流向新版本，最多为 50%。也可以设置 maxWeight 为 55，这样在最后一次测试的时候，只会新增 5% 的流量流向新版本。除了这些配置之外，Kurator 还可以设定完成验证之后，流量以什么样的比例逐步流向新版本。更多细节请参考: https://kurator.dev/docs/fleet-manager/rollout/canary/▍A/B测试A/B 测试为效果测试，是验证应用两版本表现的测试方法。它通过将用户分到不同组，每个组体验不同版本，然后分析每个组用户在使用过程中的各项指标，选择效果较好的版本。A/B 测试也可以先让部分用户试用新版本，收集真实环境下的用户反馈，再决定是否上线新版本。了解如何在 Kurator 配置应用的 A/B 测试，请参考下方操作示例。和金丝雀发布类似，由 workload 指定 A/B 测试的目标。通过 metric 指定测试的指标。A/B 测试和金丝雀发布不同的点在于需要配置 match 中的匹配规则，实现流量分组。上述 match 配置是只有 http 请求头满足使用 FireFox 浏览器或请求的 cookie 中包含 “type=insider” 的情况下，请求才会被转发到新版本。通过对不同请求头的处理达到对用户分组的效果，对不同的版本进行效果测试。除了匹配请求头之外，还能匹配 URI、端口号等。更多细节请参考: https://kurator.dev/docs/fleet-manager/rollout/abtest/▍蓝绿发布蓝绿发布是一种渐进零停机发布方法。它将生产环境分为两个独立运行的蓝绿环境,蓝环境承载当前实际流量，绿环境预部署新版本。新版本通过测试后,只需切换流量到绿环境，就能实现零停机升级。蓝环境备用支持回滚。通过实时扩容，可近乎零停机完成迭代交付，提高发布效率和用户体验。了解如何在 Kurator 配置蓝绿发布的操作示例，请参考下方。蓝绿发布需要配置目标应用、测试指标、迭代次数和容许测试失败的次数，其中测试的迭代次数由 analysisTimes 指定，容许测试失败的次数由 checkFailedTimes指定，除此之外无需配置别的规则。因为蓝绿发布在测试新版本的时候是将全局流量转发到绿环境中进行测试，没有金丝雀发布的渐进式流量递增和 A/B 测试的对用户分组的需求。更多细节请参: https://kurator.dev/docs/fleet-manager/rollout/blue-green/  未来展望  综上所述，通过 CI/CD 流水线和渐进式发布功能，Kurator 实现了从源码到发布的完整流水线自动化，真正提升了开发效率和运维能力，实现开发、配置和发布的应用全流程生命周期管理。此外还大幅简化了采用 CI/CD 流水线和渐进式发布的门槛。随着 Kurator 的不断迭代升级，我们还将继续为流水线添加更多的预定义任务模板，为渐进式发布提供更多的测试指标。欢迎大家试用 Kurator 并提出宝贵的意见与需求。Kurator的门户为：cid:link_0随着功能的逐渐完善，Kurator 将成为用户快速立体掌握云原生技术体系、高效运行分布式应用的强大工具。参考链接Kurator项目地址：cid:link_0CI/CD流水线：https://kurator.dev/docs/pipeline/软件供应链安全：https://kurator.dev/docs/pipeline/chain-security/渐进式发布：https://kurator.dev/docs/fleet-manager/rollout/金丝雀发布：https://kurator.dev/docs/fleet-manager/rollout/canary/A/B测试：https://kurator.dev/docs/fleet-manager/rollout/abtest/蓝绿发布：https://kurator.dev/docs/fleet-manager/rollout/blue-green/更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

Kmesh是业内首个内核级云原生流量治理引擎，通过基础软件创新帮助用户构筑云原生场景下高性能的通信基础设施。Kmesh第一个版本v0.1.0 [1]现已正式发布，用户可以在服务网格环境中使用yaml一键部署，无缝对接Istiod，通过流量治理下沉OS，实现相比 Istio Sidecar 方案转发时延降低50%+，为应用提供极致的转发性能体验。▍Kmesh 介绍Kmesh 基于 eBPF + 可编程内核技术，将流量治理下沉 OS，数据路径上无需经过代理层，实现了一个内核级 sidecarless 网格数据面。Kmesh 关键能力：高性能：内核中原生支持 L4~L7 流量治理功能，治理过程无需经过实体代理组件，网格内服务通信路径从代理架构下的三跳变为一跳，大幅提升网格数据面的转发性能；低开销：Pod 中无需部署 Sidecar 程序，大幅降低网格基础设施的资源开销；安全隔离：基于 eBPF 的运行时安全，并支持 cgroup 级治理隔离；平滑兼容：支持与 Istiod 等支持 XDS 协议的服务网格管控面对接，同时可以与现有 Sidecar 网格协同工作；Kmesh 的主要部件包括：kmesh-controller：负责生命周期管理、XDS 协议对接、观测运维等功能；kmesh-api：接口层，主要包括XDS 转换后的编排 API、观测运维通道等；kmesh-runtime：kernel 中实现的支持 L4~L7 流量编排的运行时；其中7层编排运行时能力依赖对内核的增强；kmesh-orchestration：基于 eBPF 实现 L4~L7 流量编排，如路由、灰度、负载均衡等；kmesh-probe：观测运维探针，提供端到端观测能力；▍Kmesh v0.1.0关键特性一键部署Kmesh社区发布了 Kmesh 的部署镜像[2]，并支持通过 yaml 一键部署 Kmesh[3]；基于namespace使能Kmesh类似Istio，Kmesh支持按namespace使能流量接管范围，如：kubectl label namespace default label istio.io/dataplane-mode=Kmesh无缝连通Istio Sidecar支持在已有sidecar形态的网格环境启用Kmesh，启用后namespace 下新创建的 Pod 流量会自动被 Kmesh 接管，而不再经过 sidecar 代理；自动对接服务网格控制面Kmesh支持与Istiod自动对接，且理论上遵循XDS协议的网格控制面都可以与Kmesh对接，可通过修改yaml中的  MESH_CONTROLLER 环境量指定；TCP/HTTP1.1基础流量治理支持TCP流量转发，支持HTTP1.1头域匹配、路由、灰度等，支持随机、轮询负载均衡算法；兼容运行模式支持根据运行环境的OS内核能力，自适应使能Kmesh特性，在无增强补丁的内核版本上，也能够以兼容模式运行Kmesh；详情参考Release Notes[1]。▍性能测试我们使用 fortio 测试了 Istio（Envoy）、Kmesh 在同等流量治理场景下的表现，同时测试了 K8s 下基于 kubeProxy 的服务通信时延作为基线参考；不同链接数下的时延对比：相同QPS下的CPU开销对比：从测试结果可以看到：Kmesh 的转发时延基本接近K8s原生转发时延，相比 Istio sidecar 模式的转发时延有明显降低；相同 qps 下，Kmesh 的 CPU 开销基本与 k8s 原生 CPU 开销一致，相比 Istio sidecar 模式有明显降低；想要了解详细的 demo 测试细节，可以观看我们的演示视频：videovideovideovideovideo  ▍Kmesh关键技术剖析内核级流量编排运行时微服务通信一般先建立链接，再发送业务报文，如果想要无感的对业务报文做编排处理，通常需要对流量进行劫持，编排完成后再基于调整后的报文继续转发，这也是现在 Proxy 代理的实现；Kmesh 考虑随流完成治理工作，将链路建立时机推迟到业务报文发送阶段，以实现更高的编排处理性能。伪建链pre_connect 流程挂载 bpf prog，若当前访问的目标地址在 xds 的 listener 范围，则调用 bpf_setsockopt 通过 TCP_ULP 将当前 socket 的 tcp proto hook重载到 kmesh_defer 的内核模块实现；延迟建链kmesh_defer 内核模块重写了 connect/send hook（在原生 hook 上做了增强）：服务第一次走到 connect hook 时，会设置 bpf_defer_connect 标记，并不真正触发握手流程；send hook 中，若 sock 上设置了 bpf_defer_connect 标记，则触发connect，此时，会基于扩展的BPF_SOCK_OPS_TCP_DEFER_CONNECT_CB 调用 bpf prog，并在 bpf prog 中完成流量治理，然后基于调整后的通信五元组、报文进行建链和发送；整个治理过程大致如下图所示：XDS规则管理xds 模型是一颗层次化的树型规则表达，且不同版本模型定义可能会有调整，Kmesh 需要将模型信息转换成 eBPF map 存储，同时保持模型规则之间的层次关系；将 xds 模型转换成 eBPF map 数据具体过程：Kmesh 订阅 Istiod 的 xds 模型，并基于 protobuf-c 将 pb 模型转换成 c 数据结构风格；对于顶层模型（ listener 等），Kmesh 定义了知名 map 表与之对应，且value 的数据结构复用 protobuf-c 导出的 c struct；map 更新从顶层的知名 map 表开始，对于记录中的指针成员，xds-adapter 中会创建 inner-map 表来存储指针指向的真实数据区域，并将 inner-map的map fd添加进 map-in-map表中，最后将其在map-in-map表的key（index）作为该指针成员的 value；map-in-map 解决 xds 模型层次化对于 map 记录的 value 成员，如果是指针变量（涉及引用其他数据结构），通过 inner-map 存储指向的数据区域：如果 vaule 成员是基础数据类型（int 等），则直接访问；如果 value 成员是指针类型，则指针存储的 value 是存放真实数据的 inner-map 在 map-in-map 表中的 index（注意：index 是在 kmesh-daemon 的xds-adapter 模块中更新 bpf map 时配合写入）；访问时，先基于 index 找到 inner-map的map fd，再去 inner-map 表中查找真正数据，对于多级指针成员，则重复该过程，直到指针信息全部被剥离。流量治理编排实现xds 的治理规则复杂，层层匹配，超过了单个 eBPF 程序的复杂度限制；Kmesh 基于 eBPF Tail Calls 特性，将治理过程拆分成多个独立的 eBPF progs，具备较好的扩展性；▍展望Kmesh 是一种基于eBPF+可编程内核实现的高性能流量治理引擎，与业界方案相比，具有更高的转发性能和更低的资源开销；在无增强补丁的内核版本上，可以以兼容模式运行Kmesh，如果想要使用Kmesh完整的治理能力，当前 openEuler 23.03[4]版本已经原生支持，除此之外的其他操作系统需要基于增强的 patch 构建[5]。Kmesh 正在逐步完善，成为一个更受欢迎的流量治理引擎还有很多工作要做，欢迎大家试用 Kmesh v0.1.0 版本，并持续关注 Kmesh 社区，也期待您的共同参与。参考链接[1] Kmesh v0.1.0：cid:link_2[2] Kmesh的部署镜像：cid:link_3[3] 一键部署Kmesh：cid:link_1[4] openEuler 23.03版本：https://repo.openeuler.org/openEuler-23.03/[5] 基于增强的patch构建：cid:link_0[6] Kmesh社区地址：cid:link_4更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

  背景介绍  当今社会正处在一个技术飞速发展、机器人与人工智能深入应用于工业领域的时代。在物流、制造和零售等领域，自动导引车（AGV）已经成为高效生产的关键工具，正在全球范围内迅速发展并得到广泛应用。2022年，我国 AGV 销量为93000台，同比增长29.2%；销售规模为185亿元，同比增长46.8%；海外销售规模为36亿，同比增长44%。AGV 系统中的无人驾驶技术，不仅可以提高生产效率，减少人工操作失误的概率，还可以在复杂和危险的环境下保障操作人员的安全。图 1 定制化接口与统一接口下，工厂调度系统架构图尽管 AGV 技术被广泛应用，却缺乏调度系统与 AGV 之间的统一接入协议。图1(a)展示了单个工厂部署不用厂家 AGV 的软件架构图，其中 MES/WMS/ERP 代表上层业务系统，RCS 代表 AGV 调度系统或云端控制平台。由于 AGV 与 RCS 之间的接口是定制化且封闭的，因此 AGV 与 RCS 的厂家属于强耦合关系，即厂家1的 RCS 无法调度厂家2的 AGV。因此对于工厂用户来讲，为了保证不同厂家的机器人安全工作，必须划定交管区域。在同一个交管区内，同一时刻只允许同一厂家的机器人进入，显著降低了任务的执行效率和 AGV 的利用效率。因此，制定一套全面、深入、适用各种环境和物流领域的调度系统与 AGV 的协议，对于统一调度系统与设备之间对接，提升 AGV 的效率、稳定性和安全性至关重要。统一的协议标准不仅明确 AGV 供应方的责任，同时也为 AGV 需求方提供保障。图 1(b)展示了统一接口下的软件架构图，可以看到，RCS 与 AGV 之间不再存在耦合关系。总结来讲，统一接口相比于定制化的接口存在以下优势：安全性高：所有厂商的 AGV 被 RCS 当作白盒集中处理，从源头杜绝碰撞，保障安全；调度效率高：同一场地无需划定交管区，AGV 也无需在“红绿灯”前长时间等待；业务连续性强：终端用户的采购方案更加灵活，无需被单个 AGV 供应商绑定；部署运维成本低：单 RCS 部署的模式，显著降低计算资源和运维人员的成本；扩展性强：支持不同厂家的新旧设备共存，用户可以按需引入新的 AGV；为此，华为联合中外运、顺丰、龙岩烟草、海康、海柔、蓝芯、斯坦德、镭神、边缘计算产业联盟、中国物流与采购联合会等30+伙伴共同起草了《云端控制平台与物流自动导引车通用接口指南》，旨在将相关的经验贡献给行业，促进我国机器人行业的蓬勃发展。  协议内容  ▍内容简介该文件规定了 AGV 与云端控制平台的接口模型、客户端通信安全认证、通信协议结构，以及控制、传输流程接口的技术要求和检验规则。适用于物流、仓储、制造业等领域的物流自动导引车实现云端控制的系统接口设计、开发、检验等。图 2 云端控制平台与AGV报文交互示意图图 2 展示了云端控制平台与 AGV 的交互流程图，整体分成以下几步：AGV 在初始化完成后，向云端控制平台发起接入申请，可选普通模式接入和安全模式接入。在普通模式中，后续报文将直接发送至对端。在安全模式中， AGV 与云端控制平台将协商会话密钥，且后续报文以密文的形式发送。AGV 向云端控制平台发起注册请求。注册成功后，将会周期性的上报自身状态；云端控制平台配置 AGV 的全局信息，如状态上报周期、告警参数等；AGV 周期性地向云端控制平台上报自身状态，并与云端控制平台保持心跳；云端控制平台根据上层业务系统输入，下发每个 AGV 的控制报文，驱动 AGV 运动；AGV 可以根据需求向云端控制平台申请安全空间，以完成自主运动，如动态绕障。▍协议亮点图 3 协议亮点信息安全：在普通接入模式的基础上，新增了安全加密模式。AGV 与云端控制平台通过 SM2 密钥交换协议协商会话密钥，然后使用该密钥对传输的报文进行 SM4 分组密码算法进行加密后，利用 SM2 数字签名算法生成签名，再对密文和签名进行传输，从而保证整个通信过程的安全；多地图管理：为满足 AGV 跨楼层和跨楼栋搬运的需求，协议规定了 RCS 和 AGV 的地图切换流程。同时指明了 AGV 在同一场地下，在 SLAM 和二维码导航之间的切换流程；双向路径规划：协议不仅规定了 RCS 规划的路径下发给 AGV 的流程，同时支持车体在极端环境下自主规划且平台授权的轨迹形式方法，如临时性避障；通信数据：采用二进制报文，显著降低通讯的数据量，减轻了对网络的依赖。同时保留多个预留字段，便于扩展和定制化实现。▍行业推广 协议的蓬勃发展离不开行业的应用和推广。KubeEdge 是边缘计算领域的开源平台，构建在 Kubernetes 之上，为网络、应用部署和云端与边缘之间的数据同步提供基础设施的支持，其目标和应用范围与当前协议的宗旨十分契合。因此 KubeEdge 将作为协议推广的重要阵地，其功能包括但不限于文档展示、协议内容详细解读、协议代码参考实现和端到端调度系统实现等，为了广大厂商和终端用户提供了良好的交流平台。▍相关链接仓库地址：cid:link_0更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

作者：达益鑫 |南开大学，刘家伟、吴锟 |DaoCloud，王杰章 |华为云▍特性研发背景以及原理KubeEdge EdgeMesh 边缘 CNI 特性针对于边缘容器网络复杂异构环境提供与云上一致的容器网络体验，包括：1. 云边统一的容器网络资源管理分配2.基于分布式中继及穿透能力的 PodIP 级别跨子网流量转发服务特性开发背景EdgeMesh 致力于研究和解决边缘计算场景下网络连通、服务协同、流量治理等相关的一系列问题，其中在异构复杂的边缘网络环境内，不同物理区域的容器在面对动态变迁的网络环境以及短生命周期且跳跃变迁的服务位置，一部分服务可能需要使用 PodIP 进行跨网段通信，而主流的 CNI 方案主要针对于云上稳定且集成式的网络环境，并不支持跨子网流量的转发，致使这些 CNI 方案并不能够很好地适应边缘复杂异构的环境，最终导致容器即便在同一个集群内却没有享用一个平面的网络通信服务。针对这个需求，EdgeMesh 进行逐步的优化。首先实现的是网络底层的中继以及穿透服务功能开发，即 EdgeMesh 高可用特性。在分布式网络场景当中，该特性能够为节点提供基于 Service 的中继流量以及网络穿透服务，但还没有完全支持对 PodIP 层次流量的转发和穿透能力。换句话说在云边混合的场景当中 ，EdgeMesh 能够为跨网段的 Service 流量提供穿透服务，但并没有涉足到容器网络的资源管理和 IP 层的连通性功能，仍旧依赖于集群原本的 CNI 方案。这个局限性导致 EdgeMesh 无法为更加底层的网络 IP 流量提供服务，意味着 EdgeMesh 并不能够完全覆盖混合云边的场景需求，对于那些需要穿透和中继服务的 PodIP 流量，老版本的 EdgeMesh 爱莫能助。那么为什么主流的 CNI 方案无法兼容边缘环境，EdgeMesh 又是如何理解这个需求的呢？关键问题在于主流的 CNI 方案大多建立于至少三层可通的环境要求之下，具体来说 CNI 自身管理创建网络资源的时候，并不能够感知底层网络的状态，其管理能力高度依赖于 Kubernetes 系统提供的 Node IP 地址，而这个地址的连通性是由底层的网络设备来维持的，如果宿主机不能通过该 Node IP 访问到目标，那么容器网络的虚拟 IP 就更没有办法联通了，原理也将在下文详述。这也意味着 Kubernetes 系统所给的 Node IP 在边缘这样底层网络并不稳定的环境下无法保障稳定的底层通信服务。EdgeMesh 基于上述理解，对这个需求进行细化的分析：边缘网络拓扑结构变动性强，且物理隔离场景较多，致使容器网络环境难以呈现出云上那样稳定的底层设施特征，比如边缘环境中自动驾驶场景或者是快递运输场景等。在这样的环境中，物理节点本身并不是绑定固定地址，甚至涉及到 5G 信号核心网注册切换等通信上的流程问题，使得 IP 地址和网络拓扑并不具备完全意义上的寻址能力，通俗说某个节点可能在上一时刻在 A 区域但是过了一会他就行驶到 B 区域了，这样动态变化切换的场景是以往 CNI 架构不曾考虑的。CNI 的连通性是基于 Kubernetes 的 Node IP 维持的，更加深入理解这个结论：主流的 CNI 相信 Kubernetes 系统设置的 IP 地址是可以联通的，所以这些主流的 CNI 方案管理虚拟网络往往都使用这样的方法：宿主机操作系统中的一个切换装置，通过让自己作为虚拟网络资源和实际物理网络环境的中继；正如下图所示， CNI 只是通过 k8s 系统，在各个节点上创建了虚假的地址，通过信息协同的方式让拥有这些虚假地址的数据包可以正常在单机节点上传送给目标，但根本还是依赖于 Node IP 可以访问联通，毕竟如果数据包不能够正常到达目标节点，CNI 利用操作系统所作的虚假行为也就没有了意义。反过来说也无法超过于单机操作系统能够管理的网络连通性，多机分布式场景下完全只能够依靠 Kubernetes 系统。当然，也并非所有的主流 CNI 都只在本机的操作系统内做文章，更加深入解决连通性的 Calico 组件有提供基于 BGP 协议的跨机连接方案，但也围绕着云上数据中心架构展开的。与此相对应的边缘环境中， 节点的 IP 地址是存在着局域性、变动性、不确定性的，可以风趣地说 Kubernetes 系统被节点欺骗了。容器生命周期短暂且不确定，这个特性更像是此类问题的催化剂，使得边缘割裂场景下的网络连接更加难以使用固定的拓扑结构来进行规划管理。系统设计思路在本特性初阶段我们确定了此次项目实现的目标：是结合 EdgeMesh 已有的 P2P 功能来提供 CNI 特性， CNI 特性在目前阶段并不意味着开发出完全替代Flannel、Calico、Cilium 等已有架构的完全独立 CNI，而是作为多阶段逐步迭代实现的特性。一方面从用户角度来说，如果直接替代云上已有的 CNI 架构，会带来额外的部署成本，也无法向用户保证新的架构有足够的价值可以完全覆盖老体系的场景和功能，以项目迭代开发的方式，优先实现一些能力，再慢慢优化、敏捷开发更能符合用户的利益。因而对于云上环境，我们倾向于直接兼容已有的 CNI 架构，使用它们提供的服务，但是补足他们不能够提供的 P2P 功能。与此同时，现有的 CNI 方案并不能够为边缘复杂异构的环境提供统一的容器网络服务，所以相较于 Docker 或者是其他 CRI 提供的简单网络功能，我们更倾向于直接开发出自己的 CNI 来实现对边缘容器网络资源的管理。而在上述的 CNI 需求之外，最重要的是如何与 EdgeMesh 的 P2P 服务结合起来；目前的开源社区中实现隧道的技术有：如 VPN，包含 IPSec、Wireguard等；如 P2P，包含 LibP2P 等，结合 EdgeMesh 应对的复杂异构多变边缘环境，我们选用了 LibP2P 技术进行开发。在此之上需要判断哪些PodIP流量需要 P2P ,哪些流量仍旧使用原本的 CNI 网络服务；再来是将这两部分的功能解耦，以便后期的功能逐步迭代优化，主要的系统架构如下图所示：上述系统设计将集群内的流量分为两类：同一网段流量： 指的是底层网络 NodeIP 可通信，Pod 容器流量通过 CNI 转换即可进行通讯。跨网段流量: 指的是底层网络不可直接访问， Pod 容器流量通过 CNI 转换封装也无法到达目标节点。针对于不同的流量我们提供不同的流量传输方式：对于同一网段的流量：依旧使用主流 CNI 的方案，通过 CNI 转换地址的形式切换虚拟网络和真实网络，连通性依赖 Kubernetes 系统获取的 NodeIP。对于跨网段的流量： 将这部分流量拦截到 EdgeMesh 当中，通过中继或者是穿透的形式转发到目标的节点，此时 EdgeMesh 充当具有 P2P 功能的 CNI 插件，来完成虚拟网络的切换。这样的设计需要解决亮点重要的问题：云边集群容器网络资源统一控制管理边缘节点以及云上节点 CNI 共同管理容器网络资源，使得容器可以分配到集群唯一的 IP地址，且不论云边都可以通过这个 IP 地址进行通信。云边以及边边跨网段容器网络通信能力兼容原本 CNI 的通信方式让需要 P2P 的流量跨网段传输。系统设计的关键抉择在于，是否需要将 P2P 的功能放置到 CNI 执行的关键路径当中，或者是将 P2P 的功能与 CNI 架构解耦。针对于第一个问题，核心关键是 IPAM 插件的设计和兼容，这方面我们倾向于集成开源社区成熟的方案 Siderpool ：📌 ：https://github.com/spidernet-io/spiderpool Spiderpool 是一个kubernetes 的 underlay 和 RDMA 网络解决方案， 同时也是一款 CNCF Sanbox级别项目这一方案也更加契合容器网络插件化设计的理念，用户可以依据业务的需求来更改系统组件的组合，在现阶段完全满足多 CNI 统一管理集群资源的设计。针对第二个问题，核心在于为 CNI 创建的容器网络资源添加跨子网的连通性。方案设计上，如果将中继和穿透的功能放置到 CNI 执行的关键路径中，那就意味着需要在内核中实现中继和穿透的流程，否则将带来巨大的性能消耗。实际上目前 Calico 、 Flannel 、Cilium 等架构在云上使用隧道技术时候就是采用这个方法：在容器资源创建修改的时候，同步修改内核中的网络设备参数，然后对数据包进行封装或者是修改，比如 Vxlan 服务中将目标是其他节点容器的流量拦截，然后添加对协议参数。这个方式在云上运用较为普遍，但是明显无法适应边缘的环境，原因在于：CNI 执行是无状态且一次性的，只有当容器网络资源创建、修改、删除的时候， CNI 调用链会被触发并执行对应的功能；这个方式的实质是通过静态配置的方式来提供通信服务，对于云上较为稳定的网络环境以及通信条件来说，确实是合适的选择，但对于边缘环境来说，网络资源并非一成不变；如果将隧道信息配置为静态形式，再通过 CNI 调用链触发管理，就无法应对部分容器动态变化之后隧道信息变迁的情况。在上述考量的基础上，本特性将 分开 CNI 和 P2P 的功能，解耦彼此在系统运作上的依赖关系，这样也更加方便用户可以选择是否开启其中的一项功能。边缘 CNI 功能这部分设计为实现基础的 CNI 调用链功能，在边缘节点管理容器网络资源，同时通过 IPAM 组件 spiderpool 兼容云上其他的 CNI 架构，统一分配集群的容器网络资源，包括基础的 CNI 功能，其次是通过 SpiderPool 实现全局的容器 IP 地址唯一。基于以上各组件设计,当集群内每一个容器都拥有了唯一的 IP 地址，我们接下来需要做的是为需要中继穿透的流量提供服务，设计方式为： 用户配置全局容器网段文件，分为云上 CIDR 和 边缘 CIDR ，每一段 CIDR 对应一个区域网络即 三层不可通的网络， EdgeMesh 通过配置文件插入路由表规则，将目标地址于本节点 CIDR 不相同的流量都拦截到本机的Tun 设备，再传输到 EdgeMesh 的 libP2P host 通过中继或者穿透的方式传输到目标地址。▍特性启用以及功能启用 EdgeMesh 边缘 CNI 特性您可以通过以下配置的方式，在启动 EdgeMesh 时候启用 CNI 边缘 P2P 特性，配置过程中您可以依据对云边网段资源的划分需求来配置云边容器网络所处的区域：# 启用 CNI 边缘特性 helm install edgemesh --namespace kubeedge \ --set agent.relayNodes[0].nodeName=k8s-master,agent.relayNodes[0].advertiseAddress="{1.1.1.1}" \ --set agent.cloudCIDR="{10.244.1.0/24,10.244.1.0/24}",agent.edgeCIDR="{10.244.5.0/24,10.244.6.0/24}" https://raw.githubusercontent.com/kubeedge/edgemesh/main/build/helm/edgemesh.tgz上述配置的参数中 cloudCIDR 是云上容器集群分配的地址， edgeCIDR 是边缘容器集群分配的地址；EdgeMesh 会对比部署节点分配到的容器网段 CIDR 与配置文件中是否属于不同网段，属于不同网段的地址会添加对应的 ip route 规则拦截到 Tun 设备。cloudCIDR 参数是云上分配的容器网段，类型为 []string ，形式为容器 IP 地址以及其子网掩码，表示一段虚拟网络区域，在区域内的容器应当网络二层可通，如果容器不能够通过二层设备访问，请划分为不同的容器网段。edgeCIDR 参数是边缘分配的容器网段，类型为 []string ，形式为容器IP地址以及其子网掩码，表示一段虚拟网络区域，在区域内的容器应当网络二层可通，如果容器不能够通过二层设备访问，请划分为不同的容器网段。名称参数类型使用实例agent.meshCIDRConfig.cloudCIDR[]string--setagent.meshCIDRConfig.cloudCIDR="{10.244.1.0/24,10.244.1.0/24}"agent.meshCIDRConfig.edgeCIDR[]string--setagent.meshCIDRConfig.edgeCIDR="{10.244.1.0/24,10.244.1.0/24}"需要注意的是设置的地址必须为 CIDR 形式 ，同时需要您依据云边网络情况划分出对应的网段；另一方面本特性需要同时启动高可用特性，为跨网段的流量提供中继和穿透服务。更多的安装配置信息请详见：helm安装 : https://edgemesh.netlify.app/zh/guide/#helm手动安装：https://edgemesh.netlify.app/zh/guide/项目功能特性介绍依据系统的设计，边缘 CNI 特性提供以下具体的功能：云边集群容器网络资源控制管理📌 ：现版本推荐集群云上节点使用 calico/flannel/cilium 等 CNI 插件，同时边缘集群节点使用 EdgeMesh CNI 插件，整个集群配置 SpiderPool 作为统一的地址管理插件来提供服务。针对于边缘网络复杂异构的情况，EdgeMesh 提供了边缘 CNI 插件来创建和管理边缘节点容器的地址资源，同时通过配合 IPAM 插件 spiderpool 协调云上节点的其他 CNI 插件来实现 整个集群的容器地址唯一，云边节点都可以通过唯一的地址进行通讯。如下图所示，该项功能的主要特性在于屏蔽了云边复杂的网络集群拓扑，实现了云边集群统一的容器资源管理，使得云边的容器可以体验如同在一个局域网内的通信服务，而不必考虑边缘集群节点容器地址重复或者是云边集群底层地址不通的问题。云边以及边边容器网络通信能力针对于边缘环境中云边和边缘通信问题，EdgeMesh CNI 特性集成了 P2P 的功能，为跨网络集群的容器流量提供中继和穿透服务。该 P2P 特性现版本主要通过 TUN 设备在 IP 层拦截需要中继和穿透服务的流量实现，能够为应用网络通信提供底层连接的服务，而不受到 IP 层以上网络协议的影响。系统功能运行如下图所示，在每个节点上的 EdgeMesh 会通过修改 IP Route 的形式拦截流量到 TUN 设备，再传输到 EdgeMesh 的 libP2P host 通过中继或者穿透的方式传输到目标地址。这个过程中 EdgeMesh 并不会拦截所有的流量而是通过用户在启动时候设置的网络区域参数来区别哪些流量是跨网段，哪些流量是同局域网访问的，并不会干扰到正常同网段流量的通信。后续计划以及未来设想在项目开发的初期阶段，系统设计基础实现了最初的需求，但是在边缘容器网络环境当中，由于网路部署和设备架构的使用情况多样复杂，对于容器网络提出了三方面重点的需求：可观测具体指的是对于云边以及边边流量的去向，包含在节点内操作系统处理的过程以及节点外多节点之间转发传输的流程可观测性。这类需求对于运维人员以及应用开发人员有着非常重要的价值和意义，可以快速定位网络流量问题出现的位置和导致的原因，并快速得出性能优化的方案和解决问题的办法。高性能与纯云部署的容器集群相似，云边混杂集群同样也面临着性能堪忧的问题，在网络层面主要指的是节点内对网络数据包在操作系统处理路径上的优化，减少其处理的逻辑和相关资源的消耗。强稳定相较于纯云上集群的部署，云边混杂集群的状态往往难以稳定，需要服务能够应对环境变化同时在出现问题时候较快地将流量卸载到正常的服务当中。针对于这些需求， 容器网络 CNI 功能是重点开发和创新的系统组件， EdgeMesh 将在接下来的系统开发中结合 eBPF 等内核优化技术，同时以实现一款泛用的边缘 CNI 插件为目标，推出应对这三点需求的特性和功能，期待能够为用户带来更加丰富和稳定的网络服务体验。附：KubeEdge社区贡献和技术交流地址[1] 网站: https://kubeedge.io[2] Github地址: cid:link_0[3] Slack地址: https://kubeedge.slack.com[4] 每周社区例会: https://zoom.us/j/4167237304[5] Twitter: https://twitter.com/KubeEdge[6] 文档地址: https://docs.kubeedge.io/en/latest/更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

12月16日-17日，以“一切为了开发者”为主题的开放原子开发者大会在无锡举办。会上，由开放原子开源基金会主导，华为、浪潮、DaoCloud、谐云、青云、飓风引擎以及OpenSDV开源联盟、openEuler社区、OpenCloudOS社区等成员单位共同发起建设的AtomHub可信镜像中心正式开放公测。AtomHub秉承共建、共治、共享的理念，旨在为开源组织和开发者提供中立、开放共建的可信开源容器镜像中心。AtomHub可信镜像中心正式公测平台地址：https://atomhub.openatom.cn/▍背景容器技术是云原生生态的基石，随着云原生技术在千行百业大规模落地和快速发展，容器镜像已经成为云原生应用分发的关键形态。开源容器镜像安全可靠的传播和分享，对云原生技术生态的繁荣有巨大促进作用。由于Docker Hub等镜像仓库的不稳定性和不可控性，以及一些政策和法规的限制，开发者们使用这些镜像仓库时也面临着种种问题和困难。网络不稳定：包括Docker Hub在内的多数容器镜像托管平台，服务器都位于海外，国内用户在访问时经常会遇到网络延迟和丢包的问题，导致镜像的上传和拉取频繁超时或请求失败。镜像拉取被限流：以Docker Hub为例，匿名用户6小时内只能拉取镜像100次，而注册登录的免费用户每6小时也只能拉取镜像200次，严重影响了镜像构建和应用部署的效率。缺失中立平台：国内用户缺失中立的镜像分享平台，构建镜像上传到Docker Hub再从国内下载受限制，影响容器镜像在中国的分享和传播。▍AtomHub定位鉴于上述原因，打造一个中立、开放共建的可信开源容器镜像中心，成为了当前亟待解决的问题。AtomHub项目——开源容器镜像中心由此发起，旨在为开发者提供来源真实、生态开放、平台中立、安全可信的新一代开源容器镜像中心。▍AtomHub架构AtomHub将采用镜像评级机制，确保镜像质量和安全性。官方镜像是由AtomHub官方发布的镜像，具有最高度可靠性和安全性，涵盖各种流行的操作系统、编程语言、数据库、中间件和应用程序；认证社区镜像由经过认证的开源社区发布，符合社区的质量标准和安全规范；认证厂商镜像则由经过认证的软件厂商发布，具有较高可靠性和专业性。与此同时，AtomHub还支持开发者自行构建和发布镜像，以满足个性化的需求。AtomHub将基于国产操作系统和软件打造自主可信根镜像、可信全链路构建系统，支持安全漏洞扫描和内容合规检测，及时发现和修复镜像漏洞和安全风险，确保镜像层层安全可信，重建可持续容器镜像供应链。AtomHub计划采用高性能镜像存储后端、多云CDN同步、冷热数据自动转储分流等关键技术，打造百万级并发规模容器镜像分发平台，为用户提供稳定可靠的镜像下载服务。▍AtomHub五大战略规划安全性：AtomHub将提供一套完善的安全机制，包括镜像签名、漏洞扫描和内容合规检测等功能，确保镜像安全可靠。高性能：AtomHub将采用高性能存储引擎和多云CDN加速，为您提供高速的镜像拉取和推送体验。易用性：AtomHub将会提供用户友好的Web界面，支持关键词搜索、分类浏览和镜像智能推荐，方便用户快速找到和下载所需镜像。兼容性：AtomHub采用OCI标准，兼容Docker Hub生态，可以无缝对接您现有的容器编排和持续集成/持续部署（CI/CD）工具。开放性：AtomHub将完全开源，打造一个开放、中立、透明的容器镜像共享平台，允许所有爱好者共同参与项目的开发、维护和使用。AtomHub作为一个新兴的开源容器镜像中心项目，对中国本土云原生技术和开源生态良性循环有巨大促进作用，我们欢迎所有对开源和容器技术感兴趣的开发者们加入我们的社区，一起打造安全可靠、高效便捷的容器镜像中心！AtomHub可信镜像中心平台地址https://atomhub.openatom.cn/首批提供160+款基础软件容器镜像，包含操作系统，编程语言，主流中间件等，欢迎体验！更多镜像陆续增加中

12月16日-17日，以“一切为了开发者”为主题的开放原子开发者大会在江苏无锡举办。秉持“共建、共治、共享”原则，聚焦大模型、云原生、前端、自动驾驶、物联网、开源治理与开发者运营等多领域内容，大会汇聚百万开发者生态，集聚政、产、学、研、用、金、创、投等各方力量，云集全球技术专家和行业大咖，持续推动软件生态蓬勃发展。华为云重磅参会开幕式、云原生分论坛、展区等多个环节，共同推进开源与云原生产业发展。▍开放原子云社区正式成立开幕式上，开放原子开源基金会理事长孙文龙与北京航空航天大学、华为技术有限公司、阿里巴巴集团控股有限公司、深圳市腾讯计算机系统有限公司、招商银行股份有限公司、京东科技信息技术有限公司代表共同启动成立开放原子云社区。▲开放原子云社区成立仪式北京航空航天大学的胡春明教授当选担任开放原子云社区主席，华为技术有限公司王泽锋，阿里巴巴集团控股有限公司丁宇，深圳市腾讯计算机系统有限公司邹辉，招商银行股份有限公司罗文江分别当选开放原子云社区副主席。开放原子云社区的成立，将通过凝聚云原生产学研用各方力量，共同推动我国云产业高质量发展。未来，该社区将围绕云原生技术路线图及生态全景规划、发掘孵化优质项目形成完整技术栈、培育壮大国内云原生开源生态、积极开展人才培养和国际合作等方面，推动云计算行业迈入“云上价值挖掘”的新阶段，重塑云计算产业价值链。▍AtomHub可信镜像中心正式公测由开放原子开源基金会牵头，开放原子云社区多家成员单位共同建设的AtomHub可信镜像中心在本次大会上正式开放公测。▲ AtomHub可信镜像中心正式公测AtomHub可信镜像中心由开放原子开源基金会牵头，华为、浪潮、DaoCloud、谐云、青云、飓风引擎以及OpenSDV开源联盟、openEuler社区、OpenCloudOS社区等成员单位共同发起，秉承共建、共治、共享的理念，旨在为开源组织和开发者提供中立、开放共建的可信开源容器镜像中心。▲ AtomHub可信镜像中心首批共建单位&社区▍云原生技术前沿落地实践论坛大会的“云原生技术前沿落地实践论坛”由CNCF基金会大使、技术监督委员会贡献者及多个项目创始人王泽锋担任出品，复旦大学计算机科学技术学院副院长、教授、博士生导师彭鑫，网易资深云原生专家侯诗军，腾讯云容器技术专家孟凡杰，蚂蚁集团高级研发工程师王思远，蚂蚁集团算法专家徐剑，华为云云原生团队开源技术专家徐中虎，开源项目 Serverless Devs 联合发起人、项目负责人袁坤，通明智云产品总监单雷，DaoCloud大容器团队技术负责人张潇，DaoCloud大容器团队开发工程师涂立海分别带来议题分享。云原生论坛议题聚焦云原生架构的创新与演进、云原生中间件的稳定性与可靠性、云原生的智能化运维与告警、云原生的FinOps实践、云原生Serverless架构与研发体验等多领域，为参会者提供全面视角和实践分享。▲云原生技术前沿落地实践论坛嘉宾合影在《融入未来：分布式云原生架构演进》的主题演讲中，华为云云原生团队核心成员、开源技术专家徐中虎分享了分布式云原生的发展历史与挑战，分布式云原生架构的演进，华为云Kurator项目在分布式云原生领域的创新。Kurator源于华为云在分布式云原生架构演进过程中多年探索，借助Kurator快速构建分布式云原生平台，可以帮助用户快速构建、部署、监控分布式云原生应用。▲华为云云原生团队核心成员、开源技术专家徐中虎▍Kurator分布式云原生开源社区展区Kurator是一款打造统一分布式云原生基础设施的开源套件。项目整合Karmada、KubeEdge、Volcano、Kubernetes、Istio、Promethus等业界主流开源技术栈，提供多云、多集群统一编排，统一调度，统一流量治理，边云协同，统一监控运维等核心能力，助力企业业务跨云跨边，分布式化升级。社区地址：cid:link_0▲Kurator分布式云原生开源社区随着云原生产业的不断发展，如何从战略全局去规划软件产业高质量发展，充分发挥开源生产方式的作用，是加快推进新型工业化发展的一大命题。社会各界都在整个过程中发挥着环环相扣的力量，而各行各业的开发者和使用者是数字时代创造知识、沉淀知识的主力军，开发者活力是软件产业繁荣发展最直接、最生动的体现。大会倡议，深化交流互鉴，聚焦产业亟需，增添发展动力，加强国际合作，做好服务保障。希望社会各界关注开源、拥抱开源、支持开源，深刻认识开源价值，为开发者提供服务，特别是在资产评估、价值认定、集成创新方面予以重点支持。也希望广大开发者和使用者能积极贡献智慧与力量，以时代责任应对共同挑战，以实干担当开创美好未来。更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

"Kubernetes运维确实复杂，这不仅需要深入理解各种概念、原理和最佳实践，还需要对集群的健康状态、资源利用率、容器的稳定性等多个方面进行风险评估。当集群出现故障时，我们通常需要花费大量时间来分析各种日志和监控信息，以找出问题的根本原因。"一位IT公司运维总监如此说道。近年来，越来越多的公司转向了基于Kubernetes的云原生架构。随着微服务和云原生架构的变得越来越复杂，我们也收到不少客户反馈在生产中进行监控和故障排除变得越来越困难。虽然CCE云原生可观测平台提供了监控、告警、日志等功能，能够让用户更加方便的定位问题，但是同样也无形中提高了运维人员的技术门槛。为了让运维和开发人员能够从繁重的故障定位排查中解脱出来，CCE服务提供了集群健康诊断能力。CCE集群健康诊断集合了容器运维专家的经验，为您提供了集群级别的健康诊断最佳实践。可对集群健康状况进行全面检查，帮助您及时发现集群故障与潜在风险，并给出对应的修复建议供您参考。▎开箱即用：免开通零依赖，一键健康诊断集群健康诊断功能作为CCE内置健康专家系统，可以在不依赖任何插件和其他服务的情况下独立运行。用户无需繁琐的开通与配置流程，就可以一键触发集群健康诊断。图1 一键健康诊断▎定时巡检：无人值守，持续守护集群健康在主动运维场景，比如集群升级前后或业务重保期间，用户可随时主动触发健康诊断来保障业务的顺利运行。另一方面，在日常运维中，我们无法一直盯屏保障，为了将客户从这种低级的劳动中解放出来，健康诊断支持定时巡检功能，只需要简单的配置定时任务，健康诊断任务就可以在后台守护您的集群健康，并将检查结果定时存档，方便随时回溯复盘。图2 健康检查结果▎多维诊断：丰富的诊断项，集群全方位体检CCE集群健康诊断提炼了运维专家提供的高频故障案例，覆盖了集群/核心插件/节点/工作负载/外部依赖等多种维度的健康检查，并且所有的诊断项都给出了风险评级、影响风险、以及修复建议。集群维度：包括集群运维能力检查，安全组配置检查，集群资源规划检查等诊断项。图3 集群维度诊断项核心插件维度：覆盖监控、日志、coredns、存储等核心插件的健康检查。图4 核心插件维度诊断项节点维度：包括节点资源负载情况和节点状态诊断。图5 节点维度诊断项工作负载维度：包括工作负载配置检查，Pod资源负载检查，Pod状态诊断等。图6 工作负载维度诊断项外部依赖维度：主要包括ECS和云硬盘等资源配额检查。图7 外部依赖维度诊断项▎智能分析：智能健康评级，专业修复建议CCE集群健康诊断会针对故障和潜在风险，给出风险等级并提供修复建议。风险等级按照紧急程度分为高风险和低风险两种：高风险：说明该诊断项会危及到集群或应用稳定性，可能造成业务损失，需要尽快修复。低风险：说明该诊断项不符合云原生最佳实践，存在潜在的风险，但是不会马上对业务造成重大影响，建议修复。在每一次健康诊断完成之后，所有的诊断结果会被汇总分析，并给出最终的集群健康评分，该评分反映了集群的整体健康状况。健康评分较低的集群往往存在较大的故障风险，需要引起集群管理员的高度重视。图8 健康风险等级评估▎案例分析：一次安全组误操作导致的业务故障CCE作为通用的容器平台，安全组规则的设置适用于通用场景。集群在创建时将会自动为Master节点和Node节点分别创建一个安全组。如果用户不小心误操作了默认安全组中的规则，可能会导致节点网络不通等问题，而且这种问题往往比较难以排除，需要花费较多的时间才能定位到安全组的原因，影响业务恢复速度。这种情况我们可以通过健康中心的巡检功能来进行故障诊断。例如修改一个集群的默认安全组规则，将Master与Node通信规则，从允许改为拒绝。图9 修改安全组规则以上操作会导致集群部分功能异常，如网络不通出现无法执行kubectl命令的问题。这种问题往往难以排查，会消耗用户大量的时间来寻找根因。此时如果用户在CCE健康中心执行一次健康巡检，会发现安全组高风险巡检项提示：图10 安全组异常提示通过诊断详情可以直接定位异常安全组，便于进行针对性修复：图11 定位异常安全组整个故障诊断流程方便快捷，可以大幅减低故障排查时间，帮助客户业务更稳定的运行在CCE集群上。▎结语CCE集群健康诊断功能，集成沉淀了大量的专家运维经验，目标是为客户提供更加智能、快捷的运维能力。当前该能力依然在快速迭代，后续我们会增加巡检结果通知、风险评估阈值调整以及更丰富的诊断项等能力，为大家带来更智能、更可靠稳定的云原生系统。服务体验请访问cid:link_0云容器引擎 CCE

规格/指标项具体规格/指标描述基础功能规格操作系统的进程管理、内存管理和文件系统管理应满足台区操作系统规范要求。支持运行容器个数 不少于6个 性能规格在最小系统运行、系统空载条件下满足如下性能指标：进程创建平均时长应小于1ms；进程删除平均时长应小于1ms；上电正常运行平均时长应小于90s；管道本地通信平均延时应小于80ms；信号量平均延时应小于300us；内存连续读写平均延时应小于300ns；内存随机访问平均延时应小于500ns；安装容器平均时长应小于30s；卸载容器平均时长应小于10s；安装微应用平均时长应小于30s；卸载微应用平均时长应小于10s；驱动支持满足《台区智能融合终端操作系统技术规范 第2部分：硬件抽象层》规范要求的设备节点，和对外接口定义安全规格操作系统提供日志审计功能；关闭不使用或不在访问控制范围内的端口及服务；可信启动机制满足规范要求。对终端启动过程中操作系统引导程序、操作系统内核、关键系统文件做完整性校验并形成审计记录；操作系统版本安全升级。支持校验升级包的来源和完整性。