▍企业上云现状：上云趋势持续加深，但云上开支存在显著浪费根据Flexer 2024年最新的一项调查显示，当前有超过70%的企业重度使用云服务，而这个数据去年是65%。由此可见，越来越多的企业开始把业务部署在云上。企业在使用云厂商提供的云服务的同时，也在为云服务的花费买单。调查显示，平均大约有30%的云成本支出被认为是无效支出。如何节省云成本支出成为近几年上云企业最关心的Top1问题。▍企业云原生化逐步深入，成本治理依然存在挑战云原生技术当前已经成为很多企业进行数字化转型的主流方式。kubernetes提供的资源共享、资源隔离、弹性调度等能力，本身能够帮助企业提升资源使用率，降低企业IT成本。然而，2021年CNCF《FinOps Kubernetes Report》的调研报告显示，迁移至Kubernetes平台后，68%的受访者表示所在企业计算资源成本有所增加，36%的受访者表示成本飙升超过20%。其背后的原因值得深思。▍云原生时代成本治理面对的挑战云原生时代成本治理有四个矛盾点：业务单元 VS 计费单元：一般云服务（比如ECS）的计费周期比较长，可能是包月或者包年；而云原生容器的生命周期相对比较短暂，容器的弹性伸缩、故障重启等动作，都有可能导致资源的闲置率比较高。容量规划 VS 资源供给：容量规划一般是静态的，一般是按照预算或者规划提前准备容器，而资源供给是业务来驱动。业务的高峰流量冲击，升级扩容等场景，都会对容量规划造成很大的挑战。统一治理 VS 多云部署：现在很多企业使用了不止一朵云，不同的云厂商的账单接口和格式都不一样，不利于企业的多云统一成本治理。成本模型 VS 云原生架构：云厂商的成本模型相对比较简单，一般是按照物理资源来计费，比如ECS服务是以整机的价格来计费。云原生架构以应用为中心，资源的申请细化到CPU/内存等粒度。这就导致云原生场景成本可视化和成本分析比较困难。总结下来，云原生成本治理面临三大挑战：成本洞察：云原生场景如何实现成本可视化，如何快速定位成本问题、识别资源浪费？成本优化：云原生成本优化的手段很多，如何采用合适的成本优化手段来实现收益最大化？成本运营：企业如何构建可持续的成本治理体系与文化？▍华为云云原生FinOps解决方案FinOps 是一门将财务管理原则与云工程和运营相结合的学科，它使组织更好地了解其云支出。 它还能够帮助他们就如何分配和管理云成本做出明智的决策。 FinOps 的目标不是节省资金，而是通过云实现最大化的收入或业务价值。 它有助于组织控制云支出，同时保持支持其业务运营所需的性能、可靠性和安全性级别。FinOps Foundation 将 FinOps 定义为三个阶段：通知、优化和运营。根据每个团队或企业完成 FinOps 的进度，公司可能会同时处于多个阶段。通知（成本洞察）：通知是 FinOps 框架的第一阶段。这一阶段旨在为所有利益相关者提供所需的信息，以便于他们了解情况，从而做出有关云使用的经济高效的明智决策。成本优化：成本优化重点是想方设法节约成本。根据当前使用情况，您的组织可以在哪些方面合理调整资源规模，并从折扣中受益？成本运营：成本运营是 FinOps 框架的最后一个阶段。在这一阶段，组织会根据业务目标持续评估绩效，然后想方设法改进 FinOps 实践。优化工作到位后，组织可以借助自动化来实施策略，在不影响性能的情况下不断调整云资源来控制成本。华为云云原生FinOps解决方案，参照业界FinOps标准与最佳实践，为用户提供云原生成本多维可视化与多种成本优化治理手段，协助客户最大化的收入或业务价值。▍云原生FinOps - 成本洞察华为云云原生FinOps成本洞察，提供如下关键特性：基于标签的资源成本归属支持ECS、EVS等资源关联集群标签，便于集群费用汇总计算基于CBC账单的精准成本计算基于CBC真实账单进行成本分摊计算，精准划分部门成本灵活的成本分摊策略支持集群、命名空间、节点池、应用、自定义等多种维度的成本可视化与成本分摊策略。支持长期的成本数据存储与检索最大支持长达2年的成本分析，支持月度，季度，年度报表及导出。工作负载快速感知，轻松应对快速弹性场景针对应用快速弹性场景，支持分钟级的负载发现与计费能力，让所有成本无一遗漏。云原生成本洞察的实现机制介绍：1、集群物理资源成本 VS 集群逻辑资源成本集群的成本可以从两个角度来计算：集群物理资源成本，包括集群直接或间接关联的资源成本，比如集群管理费、ECS成本、EVS成本等。集群的物理资源成本可以从云成本账单中直观的体现出来。集群逻辑资源成本，从kubernetes资源的角度，集群的成本包括工作负载的成本，再加上集群闲置资源成本和公共开销成本。不难看出，集群物理资源成本=集群逻辑资源成本。2、单位资源（CPU/内存等）成本计算在集群的物理资源成本已知的情况下，如何推导出集群逻辑资源成本（如pod/工作负载），是云原生FinOps成本洞察的关键。这里核心要解决的问题是单位资源成本计算的问题。我们知道，一般的云虚拟机是按照整机的价格去售卖的，不会按照单位CPU或内存售卖。但是容器服务的资源占用是按照单位资源（CPU或内存等）来申请的。所以必须计算出单位资源的成本，才能最终计算出容器服务占用的成本。一般云厂商单位CPU或内存的价格会有一个估算值，我们也可以按照CPU和内存的成本占比来计算单位资源成本。3、云原生资源成本计算从下图我们可以看出，一个Pod的资源使用是随着时间动态波动。有些时刻Pod的资源占用低于资源申请（Request），有些时刻Pod的资源占用大于资源申请（Request）。在计算Pod成本时，我们会定时采样Pod的实际使用值和Request值，并将实际使用值和Request值中的最大值用于Pod的成本计算。这是因为一旦Request值分配给Pod，那么这不是资源会被K8S预留，不会被其他Pod抢占。所有Pod需要为Request部门的资源买单。同理，如果Pod的实际使用量大于Request，那么这个Pod也需要为超出的部分买单。基于以上原理，我们就可以得出Pod的成本计算：将命名空间下所有的Pod成本累加，就可以得出命名空间维度的成本：基于以上计算逻辑，华为云CCE云原生成本治理特性实现了多种维度的集群成本可视化，比如：集群成本可视化命名空间成本可视化节点池成本可视化工作负载成本可视化4、部门成本分摊与成本分析报表很多企业会把一个集群安装命名空间的粒度分配给不同的部门使用。那么如何对各个部门的成本进行可视化分析？从上图可以看出，部门的成本不仅包括部门归属的命名空间的成本，还应该承担一部分公共成本。这部分功能成本包括系统命名空间成本和空闲资源成本。华为云CCE云原生成本治理支持基于部门的成本分摊策略配置，如下图所示：同时，基于部门的成本分摊策略，华为云CCE云原生成本治理提供了月度/季度/年度报表功能，最大支持2年的报表查询与导出。▍云原生FinOps - 成本优化云原生场景如何提升资源利用率？据 Gartner 统计，企业CPU平均使用率不足15%，造成资源利用率低的原因有多种，典型场景有：• 资源配置不合理：部分用户对于自己服务的资源使用情况不了解，申请资源时具有盲目性，通常申请过量资源• 业务波峰波谷：微服务具有明显日级别波峰、波谷特性，用户为保证服务的性能和稳定性按照波峰申请资源• 资源碎片化：不同业务部门资源池独立，无法做到资源共享，容易产生资源碎片。容器化能一定程度上提升资源利用率，但是存在部分问题单纯依赖容器化无法得到有效解决：• 资源过量申请：如果没有有效的资源推荐和监控机制，普遍实践还是是超额申请、积沙成塔造成资源浪费。• 资源池统一：K8s原生调度器缺少组、队列等高阶调度能力；大数据业务存算一体难以利用容器弹性优势。• 应用性能：单纯增加部署密度难以保证服务质量。为了提升集群资源利用率，CCE云原生FinOps解决方案提供了多种优化手段，比如智能应用资源规格推荐、云原生混部、动态超卖等能力。1. 智能应用资源规格推荐为了保障应用性能和可靠性，同时由于缺乏足够的可视化工具，我们总是倾向为应用申请过量的资源。为了解决这一问题，CCE云原生成本治理提供了智能应用资源规格推荐功能。该功能基于应用的历史画像数据，基于机器学习算法，为应用推荐最佳的申请值。2. 华为云云原生混部解决方案华为云CCE云原生混部解决方案基于volcano插件，支持一键部署，为容器业务提供高低优先级混合部署，动态超卖，服务QoS保障等能力。关键能力主要包括：容器业务优先级与资源隔离融合调度应用SLO感知：多类型业务智能混合调度，应用拓扑感知，分时复用，超卖等；资源感知调度：提供CPU NUMA拓扑感知、IO感知、网络感知调度，软硬协同，提升应用性能；集群资源规划：提供队列、公平、优先级、预留、抢占等丰富策略，统一满足高优、低优业务；节点QoS管理：多维度资源隔离、干扰检查、驱逐机制。下面重点介绍动态超卖特性：如何将节点闲置资源再利用，提升资源利用率。动态超卖的核心原理为：将节点Request和实际使用量的差值部分，作为可调度资源，供调度器重新分配，仅供低优任务使用。超卖特性有如下特点：低于作业优先使用超卖资源高优作业预选超卖节点时只能使用其非超卖资源统一调度周期高优作业先于低优作业调度不管是云原生混部还是超卖特性，都可以提升资源利用率。那么如何在提升资源利用率的同时，保障应用性能与服务质量？华为HCE 2.0 OS提供的CPU隔离能力，结合CPU快速抢占、SMT管理控制和离线任务压制指令的负载均衡能力，保障在线业务资源QoS同时，也能让被压制的离线任务指令尽量快速得到响应。根据实验室中模拟在线和离线混部场景(CPU利用率70+%)与单独业务部署在线的场景（CPU利用率30%）进行性能对比，混部场景中在线业务的性能（时延&吞吐）劣化幅度控制在单独部署在线业务性能的5%之内。基本可以认为把混部对性能的影响降低到可以忽略不计。下面我们来看一个客户案例，该客户利用华为云云原生混部解决方案，优化资源配置，最终实现35%的资源利用率提升。该客户的主要痛点包括：应用干扰：大数据与在线语音、推荐等应用争抢资源，e.g. cpu/memory，网络；影响高优任务服务质量。应用资源配置不合理：为了保证调度成功，request设置很小，不能反馈负载资源需求，引发资源冲突应用绑核：部分应用绑核，总体资源利用率低基于客户痛点，我们为客户提供如下解决方案：客户将原来节点OS由CentOS切换至华为云HCE OS；将调度器由原来基于默认调度器切换至Volcano调度器；根据客户业务属性，配置调度优先级、隔离等等策略；通过华为云云原生混部解决方案，最终为客户带来资源利用率提升35%的收益。3. CCE Autopilot：按需付费与灵活规格助力客户节约成本CCE全新推出的Autopilot集群，支持按照应用的实际用量按需付费，相对于CCE集群的优势是Autopilot集群将节点的管理运维完全托管起来，这样您无需提前规划和购买节点资源，从而实现精细化的成本治理。这里我们看两个客户场景：互联网文娱和社交业务，春节假期期间流量是平时的数倍，专项跟踪运维保障，提前预留资源，成本巨大。网约车平台，业务具有典型的早晚高峰特点，传统驾驶模式需要客户手动购买和提前预留资源，资源利用率低。通过Autopilot可以实现成本精细化治理，最终实现整体成本降低与收益最大化。扫码体验华为云CCE获取华为云云原生FinOps方案▼▼▼

随着云计算和微服务的兴起，容器化技术已经成为现代软件开发和部署的核心。本文将详细介绍容器化技术的概念、优势、主流工具以及最佳实践，帮助读者全面理解并应用这一技术。一、什么是容器化技术？容器化技术是一种轻量级的虚拟化技术，它允许开发者将应用程序及其依赖项打包到一个可移植的容器中。这个容器包含了应用程序运行所需的所有环境，使得应用程序可以在任何支持容器技术的平台上无缝运行。与传统的虚拟化技术相比，容器化技术更加轻量级，因为它只包含应用程序及其依赖项，而不包括完整的操作系统。这使得容器在启动和停止时更加快速，同时占用更少的资源。二、容器化技术的优势可移植性：容器化技术使得应用程序可以在不同的操作系统和平台上运行，无需担心环境差异。快速部署：容器化应用程序可以快速启动和停止，非常适合云计算环境和微服务架构。资源利用率高：由于容器共享底层操作系统资源，因此可以提高资源的利用率，降低硬件成本。易于管理和维护：容器化技术提供了标准化的应用程序打包和部署方式，使得应用程序的管理和维护更加简单。三、主流容器化工具Docker：Docker是目前最流行的容器化工具，它提供了丰富的功能和强大的生态系统，使得开发者可以轻松地创建、部署和管理容器。Kubernetes：Kubernetes是一个开源的容器编排系统，它可以帮助开发者自动化部署、扩展和管理容器化应用程序。四、容器化最佳实践保持容器轻量级：尽量将应用程序及其依赖项打包到一个容器中，避免将多个应用程序或服务打包到一个容器中。使用版本控制：对容器镜像进行版本控制，以便跟踪和管理不同版本的容器。安全性考虑：确保容器镜像的安全性，避免引入潜在的安全漏洞。同时，限制容器的权限，防止潜在的安全风险。持续集成和持续部署（CI/CD）：结合CI/CD工具，实现自动化构建、测试和部署容器化应用程序，提高开发效率。监控和日志收集：对容器化应用程序进行监控和日志收集，以便及时发现和解决问题。五、总结容器化技术为现代软件开发和部署带来了诸多优势，它提高了应用程序的可移植性、快速部署能力、资源利用率以及管理和维护的便捷性。掌握并应用容器化技术，将使开发者在构建高效、稳定、安全的软件系统方面更具竞争力。随着技术的不断发展，容器化技术将继续完善和优化，为未来的软件开发和部署提供更多可能性。我们期待看到更多创新性的应用和实践，共同推动容器化技术的发展。

开源之夏介绍开源之夏是由中国科学院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源软件社区的蓬勃发展，助力开源软件供应链建设。Kuasar多沙箱容器运行时项目开源之夏2024课题已上线！这个夏天，期待与同学们一起开启多沙箱容器运行时技术之旅。▍Kuasar社区介绍CNCF Kuasar 多沙箱容器运行时项目（https://github.com/kuasar-io/kuasar）于2023年4月在KubeCon + CloudNativeCon Europe上由华为云、中国农业银行以及openEuler社区、WasmEdge社区和Quark Containers社区联合发起，并于2023年12月成为云原生计算基金会（CNCF）官方项目。Kuasar融入了各企业和社区在容器运行时领域的前沿探索、技术积累和生产实践，开源至今受到业界的广泛关注和支持，数十位来自外部企业、高校的开源爱好者参与开发贡献和积极落地应用，Kuasar正以开源创新的姿态促进云原生产业发展。▍Kuasar社区开源之夏2024课题已上线课题一 vmm类型Pod支持使用youki库创建容器项目编号：240110284项目难度：进阶/Advanced项目社区导师：abel-von（华为云）导师联系邮箱：fshb1988@gmail.com项目简述：Kuasar可以创建轻量级虚拟机（vmm）类型的Pod，并在虚拟机内创建容器示例。当前做法是虚机内的vmm-task进程调用runc命令行进行创建，存在一定的性能开销。Youki（containers/youki: A container runtime written in Rust (github.com)）是一个使用rust语言编写的容器运行时，同样遵循OCI规范。本课题希望可以实现在vmm-task进程里调用youki库（注意，是库不是命令行）的接口进行容器生命周期管理。项目链接：https://summer-ospp.ac.cn/org/prodetail/240110284?lang=zh&list=pro课题二 使用tracing库增强组件可观测性项目编号：240110286项目难度：基础/Basic项目社区导师：burning（华为云）导师联系邮箱：burning9699@gmail.com项目简述：追踪（tracing）技术通常被用于业务逻辑执行情况的分析和问题定位，方便开发测试人员了解框架、找出瓶颈、分析问题，Rust也有类似的库：tokio-rs/tracing: Application level tracing for Rust. (github.com) 。本课题期望通过引入该库，实现对vmm-sandboxer和vmm-task请求调用情况的可视化，提高系统可观测性。项目链接：https://summer-ospp.ac.cn/org/prodetail/240110286?lang=zh&list=pro▍开源之夏面向哪些学生？本活动面向年满 18 周岁的高校在校学生。暑期即将毕业的学生，只要申请时学生证处在有效期内，就可以报名活动。中国籍学生参与活动时需提供身份证、学生证、教育部学籍在线验证报告（学信网）或在读证明。外籍学生参与活动时需提供护照，同时提供录取通知书、学生卡、在读证明等文件用于证明学生身份。▍我可以在开源之夏获得什么？结识开源界小伙伴和技术大牛获得社区导师的专业指导，与开源项目开发者深度交流丰富项目实践经验，提升项目开发技能为学习方向提供参考，为职业发展积累人脉通过结项考核的学生将获得结项奖金和结项证书（基础难度税前8000元RMB，进阶难度税前12000元RMB），更有机会获选优秀学生▍学生参与关键时间点4月30日-6月4日期间，学生可以通过开源之夏官网（https://summer-ospp.ac.cn/）注册、与导师沟通项目并提交项目申请。对Kuasar社区开源之夏课题感兴趣的同学，可以通过本文上方导师邮箱，提前联系导师沟通课题需求，找到最适合自己的课题方向，您也可以添加社区小助手微信k8s2222，回复Kuasar进入社区技术交流群或了解社区课题。添加社区小助手微信k8s2222回复Kuasar了解课题申报或进入社区技术交流群学生在开源之夏课题参与期间，通过线上工作的形式完成课题，相关项目结项需要在9月30日前以 PR 的形式提交到Kuasar社区仓库中并完成合并，结项的同学根据项目难度获得结项成果及奖金，并有机会获选主办方优秀学生。▍进一步了解Kuasar作为多沙箱容器运行时项目，Kuasar在保留传统容器运行时功能的基础上，与Containerd社区一起推动新的沙箱接口统一标准，并通过全面Rust化以及优化管理模型框架等手段，进一步降低管理开销，简化调用链路，灵活扩展对业界主流沙箱技术的支持。此外，通过支持多安全沙箱共节点部署，Kuasar可以充分利用节点资源、降本增效，为用户提供更安全高效的沙箱场景解决方案。Kuasar项目全景图南向沙箱方面，Kuasar已支持基于轻量级虚拟化技术的安全容器沙箱（Cloud Hypervisor、Qemu、StratoVirt），基于新兴的WebAssembly沙箱（WasmEdge、Wasmtime），基于进程级虚拟化的App Kernel沙箱（Quark）以及基于内核的原生普通容器沙箱（runC）；北向引擎方面，Kuasar已与Containerd联合构建最新的沙箱接口标准，并共同推动该标准在Containerd v2.0版本的完整实现。此外，轻量级容器引擎iSulad项目也已经完成与Kuasar项目的深度集成，支持在openEuler 23.09创新版本上一键部署。CNCF Kuasar社区期待与同学们一起开启开源之夏2024，这个夏天，来自华为云的大咖导师将与您携手作战，一起推动云原生领域容器运行时技术的探索、创新和发展。

还在对集群成本评估感到束手无策？还在担心不合理的K8s集群资源浪费？华为云云原生全新上线云原生FinOps成本治理中心，为用户提供多维度集群成本可视化，结合智能规格推荐、混部、超卖等成本优化手段，助力客户降本增效。 4月24日（周三）16:30-18:00，华为云云原生DTSE技术布道师 Roc老师将带来《华为云云原生FinOps解决方案，为您释放云原生最大价值》直播分享。华为云云原生FinOps解决方案通过可视化的成本洞察和成本优化，帮助用户精细用云以提升单位成本的资源利用率，实现降本增效目标，本期直播通过云原生上云现状分析及华为云FinOps方案及实践解析，系统化解析华为云云原生一系列云原生FinOps技术 ，为企业与用户提供企业上云成本管理的最优路径。▍直播精彩看点企业上云现状与云原生FinOps优势华为云云原生FinOps解决方案云原生FinOps成本展示与成本分析云原生FinOps成本优化华为云CCE云原生成本治理功能演示▍直播观看平台华为云官网 华为云开发者联盟视频号、CSDN、B站、虎牙、微博华为云视频号、快手、B站、虎牙、微博▍看直播 赢定制礼品 福利1 | 专家坐堂有奖： 即日起-4月25日，在指定论坛贴提问，评选优质问题送华为云定制POLO衫。 福利2 | 互动有礼： 官网直播间发口令“华为云 DTSE”抽华为云定制雨伞。福利3 | 有奖提问：直播过程中提问，评选优质问题送华为云定制长袖卫衣。扫码体验华为云CCE获取华为云云原生FinOps方案▼▼▼

中奖结果公示感谢各位小伙伴参与本次活动，欢迎关注华为云DTSE Tech Talk 技术直播更多活动~本次活动获奖名单如下：请于4月30日下班前在此问卷中反馈您的中奖邮寄信息~直播简介【直播主题】华为云云原生FinOps解决方案，为您释放云原生最大价值【直播时间】2024年4月24日 16:30-18:00【直播专家】Roc 华为云云原生DTSE技术布道师【直播简介】还在对CCE集群成本评估感到束手无策？还在担心不合理的K8s集群资源申请和过度浪费？华为云容器服务CCE全新上线云原生FinOps中心，为用户提供多维度集群成本可视化，结合智能规格推荐、混部、超卖等成本优化手段，助力客户降本增效，释放云原生最大价值。观看直播：cid:link_1活动介绍【互动方式】直播前您可以在本帖留下您疑惑的问题，专家会在直播时为您解答。直播后您可以继续在本帖留言，与专家互动交流。我们会在全部活动结束后对参与互动的用户进行评选。【活动时间】即日起—2024年4月25日【奖励说明】评奖规则：活动1：直播期间在直播间提出与直播内容相关的问题，对专家评选为优质问题的开发者进行奖励。奖品：华为云定制长袖卫衣活动2：在本帖提出与直播内容相关的问题，由专家在所有互动贴中选出最优问题贴的开发者进行奖励。奖品：华为云定制POLO衫更多直播活动直播互动有礼：官网直播间发口令“华为云 DTSE”抽华为云定制雨伞等好礼。【注意事项】1、所有参与活动的问题，如发现为复用他人内容或直播间中重复内容，则取消获奖资格。2、为保证您顺利领取活动奖品，请您在活动公示奖项后2个工作日内私信提前填写奖品收货信息，如您没有填写，视为自动放弃奖励。3、活动奖项公示时间截止2024年4月30日，如未反馈邮寄信息视为弃奖。本次活动奖品将于奖项公示后30个工作日内统一发出，请您耐心等待。4、活动期间同类子活动每个ID（同一姓名/电话/收货地址）只能获奖一次，若重复则中奖资格顺延至下一位合格开发者，仅一次顺延。5、如活动奖品出现没有库存的情况，华为云工作人员将会替换等价值的奖品，获奖者不同意此规则视为放弃奖品。6、其他事宜请参考【华为云社区常规活动规则】。

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进入技术群