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

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

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

自Serverless概念问世以来，它就被赋予了诸多标签，如全托管、免运维、极速弹性以及极致成本，CCE Autopilot作为华为云容器Serverless家族的新成员，自从发布以来受到了广泛的关注。CCE Autopilot以更低的集群管理费用和数据面资源的按需秒级计费模式，被视为企业降本的利器。然而，一些细心的客户在细致计算后发现，CCE Autopilot的资源单价似乎比ECS虚拟机的同等规格价格更高。CCE Autopilot是否真的能做到有效降本？为了解答这一疑惑，本文将深入探讨CCE Autopilot如何帮助客户实现最佳成本优化。基于Serverless架构，CCE Autopilot提供了以下成本优化方面的优势：• 运维成本： 通过自动化管理，显著减少基础设施的运维人力投入。• 时间成本： 实现快速的应用发布和高效的产品迭代。• 资源成本：采用按需计费模式，有效减少资源浪费。运维和时间成本因缺乏统一标准而难以量化，这使得它们无法被立即感知， 相比之下，资源成本则可以通过每月流水直观呈现，这也是大多数客户最关心的部分，Autopilot如何为客户节省成本？我们通过一个客户案例来了解。X 客户公司的核心业务是数字化娱乐平台。每日 21 点至凌晨 2 点是其业务高峰期，在此期间的流量约为低峰期流量的 10 倍，而周末的峰值流量更是低峰期流量的 15 倍以上。为了有效应对每日的流量高峰，客户按照业务的最大峰值预留资源，购入了 100 台 16u 的服务器，共计 1600vCPU 的资源。然而，每天约有16个小时，该客户的资源使用量都不足 10%。在切换至 CCE Autopilot 集群之后，在每日约 16 个小时的低峰期，客户仅需之前资源总量的 20% 就可以保障业务在低峰期稳定运行；而在高峰期，则通过弹性方式自动进行扩容。通过优化容器资源规格设置、弹性策略使资源利用更高效、购买套餐包等一系列Serverless 改造，实现整体资源成本消耗降低了 60%。通过此案例可以看出CCE Autopilot 集群相较于传统模式能够显著降低资源成本。接下来我们具体介绍客户案例中CCE Autopilot降低成本的三个最佳实践。▍一、优化容器资源规格设置传统的节点模式下，通常我们会先依据流量峰值规划业务资源，再购买节点 。在此过程中，我们常常会设置一个较小的 request 值以确保 POD 能够顺利调度，同时设置一个较大的 limit 值以便共享节点资源，特别是在新增 POD 的场景下，为了尽可能减少资源用量，往往会选择一个稍显空闲的节点“挤一挤”。然而，这种模式也带来了一些问题：节点资源实际使用率低：据 Gartner 统计，企业集群节点CPU 平均使用率不足 15%。由于需要预留高峰时期的资源以及申请资源时存在不确定性，节点实际利用率较低。高峰时节点存在过载风险：为了更多地利用资源，每个节点配置的 limit 总和往往远大于节点规格。一旦出现业务波峰，很有可能超过节点资源上限，从而出现过载情况。Serverless 模式下计费是按照实际资源规格，即 limit 的规格来收费的。然而许多客户在从传统的节点模式向 Serverless 模式迁移过程中仍然采用了节点模式下的资源配置方式，导致很多客户在计算成本时觉得 Serverless 模式成本变高。CCE Autopilot场景下，充分利用Serverless的按量计费的特性，合理设置POD的规格可以有效降低使用成本。CCE Autopilot 支持最小0.25u的起步规格以及1:1~1:8的宽CPU:内存配置范围，能够满足不同场景下的业务容器规格需求。相较于节点模式，Serverless场景下资源可以做到按需秒级弹性，不再需要提前预留资源，可以根据实际业务需求定义容器资源大小，通过设置合理的容器规格可以有效降低业务低峰时的资源量。在上述的客户案例中，客户其中四个核心应用部署在20个16u节点上，节点容器limit规格总和约30u，超过ECS虚机规格的87.5%。但是每个节点的实际资源利用率用在业务低峰的16个小时内不足10%，切换到CCE Autopilot集群后，客户重新规划了pod规格，按照实际资源使用量调整了每个pod的limit值，每个应用仅保留最小实例数。进行改造后，低峰时的资源消耗降低了80%以上。▍二、通过弹性策略使资源利用更高效在节点模式下，由于整体的资源量基本已经固定，应用副本数量的弹性伸缩不会带来太多的成本收益，然而在Serverless模式下每减少一个POD都会减少对应的成本支出。因此让资源更加贴合我们的实际业务时，能达到成本的极致优化。CCE Autopilot 支持的秒级弹性伸缩能力，可以在扩缩容过程中实现应用无感，配合HPA、CronHPA等丰富的自动弹性策略，能够极大的优化使用成本。基于HPA有效提高资源利用率：HPA旨在通过对一系列指标(如：CPU、内存、网络、磁盘等)的监控实现自动的资源扩缩，可以根据业务的敏感类型关联合适的指标， 做到资源随业务同步波动。HPA弹性的POD数量范围可以根据日常监控指标逐步优化，最小值接近业务低谷时最小规格可以有效降低资源成本投入。HPA+CronHPA 轻松面对各种周期性弹性场景：CronHPA提供了周期性的弹性方案，可以基于日、周、月、年灵活的配置弹性周期。大多数客户场景都存在一定周期性稳定的波动，但是随着业务的变化，周期性弹性的资源也需要不断的调整，频繁的更改参数也会增加运维负担，将CronHPA的策略作用于HPA，通过CronHPA实现整体的范围控制，HPA进一步在基础上细化资源的雕刻，能够实现更加精益的资源管理。在上述的客户案例中，客户也同样采取了HPA+CronHPA弹性的方案，每天业务高峰提前扩容，再根据CPU使用量动态进行扩容，核心业务弹性阈值为60%，在业务高峰场景下能做到分钟级弹性100+POD，相较于原来的场景业务高峰时段资源消耗降低了20%。客户通过重新规划容器低峰时资源规格+动态扩容的方式做到了整体资源使用量降低60%。▍三、套餐包模式提供包周期的价格按需的使用体验Serverless 场景下按需资源使用是其最大的亮点，但是如果用按需的单价跑一些长稳的业务就不够划算。传统的包周期模式能够让客户享受更低的折扣，但是灵活性较差，对于Serverless这种资源需要灵活扩缩的场景并不友好。为此，CCE Autopilot 推出了套餐包，让用户可以一次购买一定量的CPU核时和内存GB时，套餐包中的资源被使用完以后，用户可以继续购买套餐包，始终可以按照包周期的价格享受Serverless的灵活模式。目前CCE Autopilot的套餐包分为包月和包年两种模式，提供了1000，10000, 100000（CPU单位 核时，内存单位 GB/时）三个不同档位满足不同用量的客户述求，包年套餐折算后最低最约为按需价格的6折，可以有效为客户节省成本投入。更多优惠活动详见华为云容器专场官网cid:link_0▍总 结CCE Autopilot能够从架构上极大地解决资源率低的问题，从而带来整体成本支出上的减少。Serverless模式同时也带来了我们对成本全新的理解：从以固定资源到以动态应用为中心：传统的资源管理往往依赖于固定的资源配置，而Serverless架构的资源则是跟随业务自动调整。从固定成本到按需付费：Serverless架构能够根据业务需求自动扩缩资源，用户只需为实际使用的资源付费，而不是预先购买固定数量的资源。当我们从Serverless视角重新审视资源成本构成以后，就可以充分利用Serverless架构的优势，实现成本效益最大化。云容器引擎 CCE

我们非常高兴地宣布 Kmesh v0.5.0 的发布。首先，感谢我们的贡献者在过去两个月中的辛勤工作。在 v0.5.0 版本中，我们进行了许多重要的增强，包括命令行工具 kmeshctl、更全面的端到端测试覆盖、底层 eBPF 信息的可视化改进、可观测性增强、完整的重启支持、CNI 安装程序的改进以及 XDP 程序中的 RBAC 支持。此外，在本次发布周期中，我们修复了许多关键的 Bugs，重构了部分关键代码，并增加了更多测试覆盖，使 Kmesh 更加稳定和健壮。  Kmesh背景回顾  尽管以 Istio 为代表的服务网格在过去几年得到了广泛的关注并取得了显著的知名度，但 Istio 社区曾经重点推广的 Sidecar 模式在资源开销和数据链路延迟等方面会对工作负载产生显著影响，因此用户在选择落地方案时仍然相对谨慎。此外，Sidecar 模式的一个主要缺点是其与业务容器的生命周期强绑定，无法独立进行升级。为了解决这些问题，Kmesh 创新性地提出了基于内核的无 Sidecar 流量治理方案，将流量治理下沉至内核层面。当前Kmesh支持“Kernel-Native”和“Dual-Engine”两种模式。对于“Kernel-Native”模式，由于 eBPF 技术非常适合四层流量治理，并且结合可编程内核模块，可以实现七层流量编排。Kmesh 最初完全依赖 eBPF 和内核模块来实现 L4-L7 的治理。Kmesh 采用随流治理策略，不会在服务通信过程中增加额外的连接跳数，与 Sidecar 模式相比，服务之间的通信连接数从三条减少至一条。“Kernel-Native”模式的架构图如下：同时，为了增强七层协议的治理能力，今年 Kmesh 引入了一种新的治理模式——“Dual-Engine”模式，利用 eBPF 将流量转发到 kmesh-waypoint 进行高级的七层协议治理。这是一种更灵活的分层治理模型，能够按需满足不同用户的多样化需求。  Kmesh 0.5版本关键特性解析  Kmesh重启时的零停机时间现在，Kmesh 可以在重启后优雅地重新加载 eBPF Map 和程序，且不需要在重启后重新注册命名空间或特定 Pod。这意味着在重启期间，流量不会中断，这对用户来说是一个巨大的好处。在 kmesh-daemon 重启后，eBPF Map 配置将自动更新为最新状态。如上图所示通过将 eBPF程序 pin 在内核目录上，kmesh 关闭后 eBPF 依然可以正常对流量进行治理，保证 kmesh 重启过程中服务不中断。在 kmesh 重启后，将 bpf_map 中存放的 config 与最新获取的 config 作对比，将 bpf_map 中的 config 更新至最新。在 v0.4.0 版本中，Kmesh 重启后需要重新启动所有由 Kmesh 管理的 Pod，以便重新管理，因为该管理是由 CNI 插件触发的。现在这一过程已在 kmesh-daemon 中完成，因此 Pod 不需要重新启动即可重新管理。可观测性增强现在，Kmesh 支持 L4 访问日志，使用户能够清晰地可视化 Kmesh 管理的流量。请注意，访问日志默认未启用。您可以通过修改 Kmesh 中  spec.containers.args 的 --enable-accesslog 参数来启用访问日志功能。我们还将支持使用 kmeshctl 动态启用访问日志。访问日志的示例如下：accesslog: 2024-09-14 08:19:26.552709932 +0000 UTC src.addr=10.244.0.17:51842, src.workload=prometheus-5fb7f6f8d8-h9cts, src.namespace=istio-system, dst.addr=10.244.0.13:9080, dst.service=productpage.echo-1-27855.svc.cluster.local, dst.workload=productpage-v1-8499c849b9-bz9t9, dst.namespace=echo-1-27855, direction=INBOUND, sent_bytes=5, received_bytes=292, duration=2.733902ms其中各个字段的含义为：同时，为 Kmesh 适配的 Grafana 插件也已添加，以便更好地可视化各维度的监控指标。此外，可观测性方面的一些关键问题已得到修复，有效提高了其准确性和稳定性。将授权执行下沉到XDP程序中在 v0.3.0 版本中，Kmesh 已支持 L4 RBAC，但之前的解决方案是在用户空间中进行 RBAC，这在性能和功能上存在一些问题。现在我们已将其下沉到 XDP eBPF 中，这项功能将真正可用。目前，鉴权规则已转移到 eBPF Map中，这使得能够完全在 eBPF 程序中执行授权。当授权结果为拒绝时，XDP 程序会直接丢弃请求数据包，从而使客户端能够检测到连接失败。下沉到 XDP 程序的关键是使用了 eBPF 的 tail-call 机制，将不同的匹配规则通过 tail-call 串联起来，遵循了原先在用户空间进行鉴权的逻辑。如上图所示，集群内配置的鉴权规则通过消息订阅机制，被写入 eBPF Map。Pod 上入方向的流量在建链时，会在 XDP 程序中进行鉴权规则匹配，如果鉴权结果为拒绝，则包被丢弃；如果鉴权结果为允许，则流量将通过协议栈发送到对应的 App 进程。更好的调试能力我们新增了命令行工具 kmeshctl！现在，您无需进入相应的 Kmesh 守护进程 Pod 来调整 Kmesh 守护进程的日志级别或转储配置。您可以直接使用 kmeshctl：# 调整 kmesh-daemon 日志级别（例如，debug | error | info） kmeshctl log kmesh-6ct4h --set default:debug # 转储配置 kmeshctl dump kmesh-6ct4h workload未来将为 kmeshctl 添加更多功能，以便用户更好地管理和调试 Kmesh。更好的底层BPF Map可视化之前我们有接口 /debug/config_dump/ads 和 /debug/config_dump/workload 来输出 Kmesh 守护进程中缓存的配置内容。由于各种原因，Kmesh 守护进程缓存中的配置与实际的 eBPF 可能并不完全一致。如果我们能获取阅读友好的 eBPF 信息，将更有助于我们进行故障排查。现在，我们可以通过接口 /debug/bpf/* 获取这些信息。这些信息也将被集成到 kmeshctl 中，方便查看，并且可以进一步扩展，以判断底层 eBPF 是否与 Kmesh 守护进程中的配置同步。# Get eBPF info in dual-engine mode kubectl exec -ti -n kmesh-system kmesh-6ct4h -- curl 127.0.0.1:15200/debug/config_dump/bpf/workload # Get eBPF info in kernel-native mode kubectl exec -ti -n kmesh-system kmesh-6ct4h -- curl 127.0.0.1:15200/debug/config_dump/bpf/ads改进CNI安装程序由于 CNI 安装程序是 Kmesh 守护进程，如果 kmesh-daemon 意外崩溃或机器突然断电，CNI 将无法卸载 CNI 配置。如果 kubeconfig 的 token 过期，则 kmesh-daemon 异常退出后，任何 Pod 都无法成功启动。因此，我们采取了以下两种方法来解决此问题：在 start_kmesh.sh 的末尾清理 CNI 配置。在CNI安装程序中添加一个单独的Go协程，一旦token文件被修改，更新 kubeconfig 文件。这可以确保 kubeconfig 文件不容易过期。支持HostNetwork工作负载现在，对于 Kmesh 双引擎模式，我们支持通过 HostNetwork Pods 访问服务。性能提升在双引擎模式中，我们通过使用本地缓存来优化工作负载和服务响应处理期间的 BPF Map更新，避免了对 BPF Map的循环遍历。关键Bug修复我们还修复了一些重大 Bug：通过不删除前端Map，防止在工作负载资源更新期间失去流量控制。来自命名空间 waypoint 的流量将再次重定向到 waypoint，避免了死循环。现在我们跳过了来自 waypoint 的流量管理。修复了当 waypoint 处理非 HTTP TCP流量时，会意外返回HTTP/1.1 400 Bad Request 的问题。#681  致谢贡献者  Kmesh v0.5.0 版本包含了来自14 位贡献者的 567 次代码提交，在此对各位贡献者表示由衷的感谢： @hzxuzhonghu @LiZhenCheng9527 @nlgwcy @YaoZengzeng@supercharge-xsy@Okabe-Rintarou-0@lec-bit@weli-l@noobwei@kwb0523@tacslon@zirain@yuanqijing@SpongeBob0318我们始终以开放中立的态度发展 Kmesh，持续打造 Sidecarless 服务网格业界标杆方案，服务千行百业，促进服务网格健康有序的发展。Kmesh 当前正处于高速发展阶段，我们诚邀广大有志之士加入！参考链接Kmesh Release v0.5.0: cid:link_3Kmesh GitHub: cid:link_5Kmesh Website: https://kmesh.net/【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_4 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

北京时间2024年9月19日，Volcano社区v1.10.0版本[1]正式发布（Branch：release-1.10[2]），此次版本增加了以下新特性：新增队列优先级设置策略支持细粒度的GPU资源共享与回收支持Pod Scheduling Readiness调度支持Sidecar container调度增强vcctl命令行工具功能Volcano支持Kubernetes v1.30增强Volcano安全性优化Volcano性能提升GPU监控功能优化helm chart包安装升级流程▶ 新增队列优先级设置策略  在传统的大数据处理场景下，用户可以直接设置队列优先级来控制作业的调度顺序，为了更好的帮助用户从Hadoop/Yarn迁移到云原生平台，Volcano也支持了在队列层面直接设置优先级，降低大数据用户的迁移成本，提升用户体验和资源利用效率。队列是Volcano中的一种基本资源，不同队列有着优先级区分，在默认情况下，队列的优先级是由队列的share值决定的，share值是由队列中已分配的资源量除以队列的总容量计算得到的，不需要用户手动配置，share值越小，则代表队列中已分配的资源比例越小，即队列越不饱和，需要优先分配资源，因此队列的share越小，队列的优先级越高，在分配资源时会优先分配给share较小的队列，以保证资源分配的公平性。但是在生产环境尤其是大数据处理场景下，用户更希望可以直接设置队列的优先级，从而能更直观的知道不同队列的优先级顺序，由于share值是实时计算得到的，因此会根据队列分配资源的饱和程度而实时变化，为了更加直观的表示队列优先级同时支持用户自行配置，Volcano在share值的基础上为队列新增了priority字段，支持用户配置队列优先级，priority越高则表示队列优先级越高，会优先分配资源给高优先级的队列，并且在回收队列资源时会优先回收低优先级队列内的作业。队列优先级定义：type QueueSpec struct { ... // Priority define the priority of queue. Higher values are prioritized for scheduling and considered later during reclamation. // +optional Priority int32 `json:"priority,omitempty" protobuf:"bytes,10,opt,name=priority"` }同时为了兼容share值的使用方式，Volcano在计算队列优先级时也会考虑share值，默认情况下用户不设置队列优先级或者队列的优先级相等时，Volcano会再比较队列的share值，此时share越小队列优先级越高。用户可以根据实际场景选择设置不同的优先级策略，即priority和share两种方式。关于队列优先级设计文档，请参考：Queue Priority[3]▶ 支持细粒度的GPU资源共享与回收Volcano在v1.9版本发布了弹性队列容量capacity调度功能，用户可以直接为队列设置每一维度资源的容量，同时支持基于deserved的队列弹性容量调度，实现了更加细粒度的队列资源共享和回收机制。弹性队列容量capacity调度的设计文档请参考：Capacity scheduling Design[4]使用指导请参考：Capacity Plugin User Guide[5]为队列配置每一维度deserved使用样例：apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: demo-queue spec: reclaimable: true deserved: # set the deserved field. cpu: 64 memeory: 128Gi nvidia.com/a100: 40 nvidia.com/v100: 80在v1.10版本中，Volcano在弹性队列容量capacity的基础上，支持了上报不同型号的GPU资源，NVIDIA默认的Device Plugin在上报GPU资源时无法区分GPU型号，统一上报为nvidia.com/gpu，AI训推任务无法根据业务特点选择不同型号的GPU，比如A100、T4等型号的GPU，为了解决这一问题，以满足不同类型的AI任务需求，Volcano在Device Plugin层面支持上报不同型号的GPU资源到节点，配合capacity插件实现更加细粒度的GPU资源共享和回收。关于Device Plugin上报不同型号GPU的实现和使用指导，请参考：GPU Resource Naming[6]注意：capacity在v1.10.0版本中作为了默认的队列管理插件，capacity与proportion插件互相冲突，当升级到v1.10.0后，你需要再设置队列的deserved字段，以保证队列功能正常工作，具体的使用说明请参考：Capacity Plugin User Guide[7]capacity插件根据用户指定的队列deserved值来划分集群资源，而proportion插件则根据队列权重动态划分集群资源，用户可以根据实际场景选择使用capacity或者proportion插件进行队列管理。proportion插件的介绍请参考：proportion plugin[8]▶ 支持Pod Scheduling Readiness调度Pod 一旦创建就被认为已准备好进行调度，在 Kube-scheduler 中，它会尽力寻找合适的节点来放置所有Pending的 Pod。然而，在现实情况下，某些 Pod 可能会长时间处于“缺少必要资源”状态，这些 Pod 实际上以不必要的方式干扰调度程序（以及 Cluster AutoScaler 等下游组件）的决策和运行，造成资源浪费等问题。Pod Scheduling Readiness是 Kube-sheduler 的一项新增功能，在Kubernetes v.1.30版本GA，成为了一个稳定特性，它通过设置Pod的schedulingGates字段来控制Pod的调度时机。pod-scheduling-gates-diagram在前面的版本中，Volcano已集成了K8s默认调度器的所有算法，全面涵盖了Kube-scheduler的原生调度功能。因此，Volcano能够无缝替代Kube-scheduler，作为云原生平台下的统一调度器，支持微服务和AI/大数据工作负载的统一调度。在最新发布的v1.10版本中，Volcano更是引入了Pod Scheduling Readiness调度能力，进一步满足了用户在多样化场景下的调度需求。关于Pod Scheduling Readiness特性的文档，请参考：Pod Scheduling Readiness | Kubernetes[9]Volcano支持Pod Scheduling Readiness调度的设计文档，请参考：Proposal for Support of Pod Scheduling Readiness by ykcai-daniel · Pull Request #3581 · volcano-sh/volcano (github.com)[10]▶ 支持Sidecar container调度Sidecar container是一种相对于业务容器而言的辅助容器，通常用来辅助业务容器的运行，比如收集业务容器日志、监控、初始化网络等。在Kubernetes v1.28之前，Sidecar container只是一种概念，并没有单独的API来标识一个容器是否是Sidecar container，Sidecar容器和业务容器处于同等地位，有着相同的生命周期，Kubelet会并发启动所有Sidecar容器和业务容器，这样带来的问题是Sidecar容器可能会在业务容器启动之后才启动，并且在业务容器结束之前先结束，而我们期望的是Sidecar容器先于业务容器启动，并在业务容器结束之后再结束，这样就能保证Sidecar容器收集的日志，监控等信息是完整的。Kubernetes v1.28在API层面支持了Sidecar container，并对init container、Sidecar container、业务container做了统一的生命周期管理，同时调整了Pod的request/limit资源计算方式，该特性在v1.29成为Beta特性。该特性在设计阶段经历了漫长的讨论时间，特性本身并不复杂，主要的考虑点在于兼容旧的使用方式，如果定义一个除了init container、业务容器之外的新的容器类型，会对API有较大的破坏性，同时周边组件适配该特性的话会有较多的侵入式修改，带来很多额外开销，因此Kubernetes社区并没有引入新的容器类型来支持Sidecar container，而是直接复用了init container，通过设置init container的restartPolicy为Always来标识Sidecar container，完美的解决了API兼容性问题和Sidecar容器的生命周期问题。在调度层面，该特性的影响在于Pod申请的request资源计算方式有所变化，因为Sidecar container作为一种特殊的init container是持久运行的，需要将Sidecar container的request值累加到业务容器的request值上，因此需要重新计算init container、Sidecar container和业务容器的资源request值。Volcano调度器在新版本更改了Sidecar container的资源计算方式，支持了Sidecar container的调度，用户可以使用Volcano调度Sidecar container。关于Sidecar container的详细信息，请参考：Sidecar Containers | Kubernetes[11]▶ 增强vcctl命令行工具功能vcctl是操作Volcano内置CRD资源的一个命令行工具，可以方便的用来查看/删除/暂停/恢复vcjob资源，并支持查看/删除/开启/关闭/更新queue资源。Volcano在新版本对vcctl做了功能增强，新增以下功能：支持创建/删除/查看/描述jobflow和jobtemplate资源支持查询指定队列里的vcjob支持通过queue和vcjob过滤查询Podvcctl的详细指导文档，请参考：vcctl Command Line Enhancement[12]▶ Volcano支持Kubernetes v1.30Volcano版本紧跟Kubernetes社区版本节奏，对Kubernetes的每个大版本都进行支持，目前最新支持的版本为v1.30，并运行了完整的UT、E2E用例，保证功能和可靠性。如果您想参与Volcano适配Kubernetes新版本的开发工作，请参考：adapt-k8s-todo[13] 进行社区贡献。▶ 增强Volcano安全性Volcano一直都很重视开源软件供应链的安全，在license合规、安全漏洞披露和修复、仓库分支保护、CI检查等方面遵循OpenSSF定义的规范，Volcano近期在Github Action加入了新的workflow，它会在代码合入时运行OpenSSF安全性检查，并实时更新软件安全评分，持续提升软件安全性。同时Volcano对各个组件的RBAC权限进行了收缩，只保留必要的权限，避免了潜在的越权风险，提升了系统的安全性。相关PR参见：Added the scorecard github action and its badge by harshitasao · Pull Request #3655 · volcano-sh/volcano[14]Shrink permissions of vc scheduler & controller by Monokaix · Pull Request #3545 · volcano-sh/volcano (github.com)[15]Add pre-install&pre-upgrade hook for admission-init job by Monokaix · Pull Request #3504 · volcano-sh/volcano (github.com)[16]▶ 优化Volcano性能在大规模场景下，Volcano做了很多性能优化的工作，主要包括：优化vcjob更新策略，降低vcjob的更新和同步频次，降低API Server压力，提升提交任务的QPSvc controller新增controller gate开关，用户可以选择关闭不需要的controller，减低内存占用和CPU负载所有的controller使用共享的informer，减少内存占用▶ 提升GPU监控功能新版本的Volcano针对GPU监控指标做了优化和增强，修复了GPU监控不精确的问题，并在GPU的算力和显存监控指标上新增了节点信息，方便用户更加直观的查看每个节点上每一张GPU的算力、显存的总量和已分配量。详细PR参见：Update volcano-vgpu monitoring system by archlitchi · Pull Request #3620 · volcano-sh/volcano (github.com)[17]▶ 优化helm chart包安装升级流程Volcano针对helm chart的安装、升级流程进行了优化，并支持安装helm chart包设置更多自定义参数，主要包括：利用helm的hook机制，在安装成功Volcano之后，自动删除volcano-admission-init这一job，避免后续使用helm upgrade升级失败的问题，相关PR参见：Add pre-install&pre-upgrade hook for admission-init job by Monokaix · Pull Request #3504 · volcano-sh/volcano (github.com)[18]每次安装成功后更新Volcano admission需要的secret文件，避免在不指定helm包名情况下，重复安装卸载volcano导致volcano admission处理失败的问题，详细PR参见：Update volcano-admission secret when it already exists by Monokaix · Pull Request #3653 · volcano-sh/volcano (github.com)[19]支持为helm包中的资源对象设置通用label，相关PR参见：Add common labels for chart objects by Aakcht · Pull Request #3511 · volcano-sh/volcano (github.com)[20]支持通过helm为Volcano组件设置日志等级，相关PR参见：Expose volcano components (controller, scheduler, etc.) log level control to the helm chat values by chenshiwei-io · Pull Request #3656 · volcano-sh/volcano (github.com)[21]支持通过helm设置Volcano组件的镜像代理仓库，相关PR参见：add image registry for helm by calvin0327 · Pull Request #3436 · volcano-sh/volcano (github.com)[22]支持通过helm设置容器级别的securityContext，相关PR参加：feat: Add securityContext support at container level in helm chart templates by lekaf974 · Pull Request #3704 · volcano-sh/volcano (github.com)[23]致谢贡献者Volcano 1.10.0 版本包含了来自36位社区贡献者的上百次代码提交，在此对各位贡献者表示由衷的感谢：贡献者GitHub ID@googs1025@WulixuanS@SataQiu@guoqinwill@lowang-bh@shruti2522@lukasboettcher@wangyysde@bibibox@Wang-Kai@y-ykcir@lekaf974@yeahdongcn@Monokaix@Aakcht@yxxhero@babugeet@liuyuanchun11@MichaelXcc@william-wang@lengrongfu@xieyanker@lx1036@archlitchi@hwdef@wangyang0616@microyahoo@snappyyouth@harshitasao@chenshiwei-io@TaiPark@Aakcht@ykcai-daniel@lekaf974@JesseStutler@belo4ya参考资料[1] v1.10.0版本: cid:link_6[2] Branch：release-1.10: cid:link_7[3] Queue Priority: cid:link_3[4] Capacity scheduling Design: cid:link_2[5] Capacity Plugin User Guide: cid:link_1[6] GPU Resource Naming: cid:link_5[7] Capacity Plugin User Guide: cid:link_1[8] proportion plugin: https://volcano.sh/en/docs/plugins/#proportion[9] Pod Scheduling Readiness | Kubernetes: https://kubernetes.io/docs/concepts/scheduling-eviction/pod-scheduling-readiness/[10] Proposal for Support of Pod Scheduling Readiness by ykcai-daniel · Pull Request #3581 · volcano-sh/volcano (github.com): cid:link_10[11] Sidecar Containers | Kubernetes: https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/[12] vcctl Command Line Enhancement: cid:link_0[13] adapt-k8s-todo: cid:link_4[14] Added the scorecard github action and its badge by harshitasao · Pull Request #3655 · volcano-sh/volcano: cid:link_11[15] Shrink permissions of vc scheduler & controller by Monokaix · Pull Request #3545 · volcano-sh/volcano (github.com): cid:link_12[16] Add pre-install&pre-upgrade hook for admission-init job by Monokaix · Pull Request #3504 · volcano-sh/volcano (github.com): cid:link_13[17] Update volcano-vgpu monitoring system by archlitchi · Pull Request #3620 · volcano-sh/volcano (github.com): cid:link_9[18] Add pre-install&pre-upgrade hook for admission-init job by Monokaix · Pull Request #3504 · volcano-sh/volcano (github.com): cid:link_13[19] Update volcano-admission secret when it already exists by Monokaix · Pull Request #3653 · volcano-sh/volcano (github.com): cid:link_14[20] Add common labels for chart objects by Aakcht · Pull Request #3511 · volcano-sh/volcano (github.com): cid:link_15[21] Expose volcano components (controller, scheduler, etc.) log level control to the helm chat values by chenshiwei-io · Pull Request #3656 · volcano-sh/volcano (github.com): cid:link_16[22] add image registry for helm by calvin0327 · Pull Request #3436 · volcano-sh/volcano (github.com): cid:link_17[23] feat: Add securityContext support at container level in helm chart templates by lekaf974 · Pull Request #3704 · volcano-sh/volcano (github.com): cid:link_18【更多Volcano干货推荐】Volcano云原生批量计算公开课Volcano云原生批量计算公开课Volcano云原生批量计算公开课由CNCF首个批量计算社区Volcano核心贡献者开发，通过理论学习+实践操作，帮助学习者由浅入深了解批量计算原理和生产场景应用，晋升批量计算达人！点击免费学习Volcano云原生批量计算公开课社区介绍：Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene、Ray 等众多主流计算框架的支持，并构建起完善的上下游生态。Volcano官网：https://volcano.shGitHub: cid:link_19每周例会： https://zoom.us/j/91804791393

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。本版本包含下列新增特性：支持联邦应用跨集群滚动升级，使用户版本发布流程更加灵活可控karmadactl 新增了多项运维能力，提供独特的多集群运维体验为联邦工作负载提供标准化 generation 语义，使 CD 执行一步到位Karmada Operator 支持自定义 CRD 下载策略，使离线部署更灵活新特性概览▍联邦应用跨集群滚动升级在最新发布的 v1.11 版本[1] 中，Karmada 新增了联邦应用跨集群滚动升级特性。这一特性特别适用于那些部署在多个集群上的应用，使得用户在发布应用新版本时能够采用更加灵活和可控的滚动升级策略。用户可以精细地控制升级流程，确保每个集群在升级过程中都能够平滑过渡，减少对生产环境的影响。这一特性不仅提升了用户体验，也为复杂的多集群管理提供了更多的灵活性和可靠性。下面通过一个示例来演示如何对联邦应用进行滚动升级：假定用户已经通过 PropagationPolicy 将 Deployment 应用分发到三个成员集群中：ClusterA、ClusterB、ClusterC：apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx-propagation spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinity: clusterNames: - ClusterA - ClusterB - ClusterC此时 Deployment 版本为 v1，为了将 Deployment 资源版本升级至 v2，用户可以依次执行下列步骤。首先，用户通过配置 PropagationPolicy 策略，暂时停止向 ClusterA 和 ClusterB 分发资源，从而应用的变更将只发生在 ClusterC：apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx-propagation spec: #... suspension: dispatchingOnClusters: clusterNames: - ClusterA - ClusterB然后更新 PropagationPolicy 资源，允许系统向 ClusterB 集群同步新版本资源：suspension: dispatchingOnClusters: clusterNames: - ClusterA最后删除 PropagationPolicy 资源中的 suspension 字段，允许系统向 ClusterA 集群同步新版本资源：从上述示例中我们可以看到，利用联邦应用跨集群滚动发布能力，新版本应用可以做到按集群粒度滚动升级，并且可以做到精准控制。此外，该特性还能应用于其他场景：作为开发者，当 Karmada 控制平面与成员集群争夺资源控制权时，会出现资源被频繁更新的情况。暂停将资源同步到成员集群的过程将有助于快速定位问题。▍karmadactl 能力增强和运维体验提升在本版本中，Karmada 社区致力于增强 Karmadactl 的能力，以便提供更好的多集群运维体验，进而摆脱用户对 kubectl 的依赖。更丰富的命令集Karmadactl 支持更丰富的命令集，如 create、patch、delete、label、annotate、edit、attach、top node、api-resources 以及 explain，这些命令允许用户对 Karmada 控制面或成员集群上的资源执行更多操作。更丰富的功能Karmadactl 引入了 --operation-scope 参数来控制命令的操作范围。有了这个新参数，get、describe、exec 和 explain 等命令可以灵活切换集群视角对 Karmada 控制面或成员集群的资源进行操作。更详细的命令输出信息karmadactl get cluster 命令的输出现在增加了 cluster 对象的 Zones、Region、Provider、API-Endpoint 和 Proxy-URL 信息。通过这些能力增强，karmadactl 的操作和运维体验得到了提升。karmadactl 的新功能和更多详细信息可以通过使用 karmadactl --help 获得。▍联邦工作负载标准化 generation 语义在本版本中，Karmada 将联邦层面的工作负载 generation 语义进行了标准化。这一更新为发布系统提供了可靠的参考，增强了跨集群部署的精确度。通过标准化 generation 语义，Karmada 简化了发布流程，并确保一致性地跟踪工作负载状态，使得跨多个集群管理和监控应用程序变得更加容易。标准化细节为，当且仅当工作负载分发至所有成员集群中的资源状态满足 status.observedGeneration >= metadata.generation 时，联邦层面的工作负载状态中的 observedGeneration 值才会被设置为其本身 .metadata.generation 值，这确保了每个成员集群中相应的控制器均已完成了对该工作负载的处理。此举将联邦层面的 generation 语义同kubernetes 集群的 generation 语义进行了统一，使用户能够更便捷的将单集群业务迁移至多集群业务。本版本已完成下列资源适配：GroupVersion: apps/v1 Kind: Deployment, DaemonSet, StatefulSetGroupVersion: apps.kruise.io/v1alpha1 Kind: CloneSet, DaemonSetGroupVersion: apps.kruise.io/v1beta1 Kind: StatefulSetGroupVersion: helm.toolkit.fluxcd.io/v2beta1 Kind: HelmReleaseGroupVersion: kustomize.toolkit.fluxcd.io/v1 Kind: KustomizationGroupVersion: source.toolkit.fluxcd.io/v1 Kind: GitRepositoryGroupVersion: source.toolkit.fluxcd.io/v1beta2 Kind: Bucket, HelmChart, HelmRepository, OCIRepository如有您有更多资源（包括CRD）需要适配，可以向 Karmada 社区进行反馈，也可以使用 Resource Interpreter进行扩展。▍Karmada Operator 支持自定义 CRD 下载策略CRD（Custom Resource Definition，自定义资源定义）资源是 Karmada Operator 用于配置新的 Karmada 实例的关键前提资源。这些 CRD 资源包含了 Karmada 系统的关键 API 定义，例如，PropagationPolicy，ResourceBinding，Work 等。在 v 1.11 版本中，Karmada Operator 支持用户自定义 CRD 下载策略。利用这个功能，用户可以指定 CRD 资源的下载路径，并定义更多的下载策略，为用户提供了更灵活的离线部署方式。有关该特性的详细描述，可以参考提案：Custom CRD Download Strategy Support for Karmada Operator[2] 。致谢贡献者Karmada v1.11 版本包含了来自 36 位贡献者的 223 次代码提交，在此对各位贡献者表示由衷的感谢：贡献者列表：@08AHAD@a7i@aditya7302@Affan-7@Akash-Singh04@anujagrawal699@B1F030@chaosi-zju@dzcvxe@grosser@guozheng-shen@hulizhe@iawia002@mohamedawnallah@mszacillo@NishantBansal2003@jabellard@khanhtc1202@liangyuanpeng@qinguoyi@RainbowMango@rxy0210@seanlaii@spiritNO1@tiansuo114@varshith257@veophi@wangxf1987@whitewindmills@xiaoloongfang@XiShanYongYe-Chang@xovoxy@yash@yike21@zhy76@zhzhuang-zju参考资料[1] Karmada v1.11: cid:link_4[2] 提案：Custom CRD Download Strategy Support for Karmada Operator: cid:link_0【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_5 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

扫码进入容器活动专场

案例简介：XX成立于1984年，是土耳其本土最大的企业软件公司，也是最大的公共软件公司之一，为各类企业提供应用软件解决方案。迄今为止，XX在X个不同国家的X个地区拥有X多名员工和X多个业务伙伴。与AAG均有合作。迁移方案描述：Ø信息调研：客户PostgreSQL数据库，其中SAAS实例单库最大对象数超过90W+，PAAS实例逻辑库超过600+。Ø方案设计：SAAS实例共25个逻辑库，使用DRS全量迁移，总共分6批迁移完成，割接窗口是每天6小时。因为DRS只支持单库迁移，所以PAAS实例使用shell脚本迁移。输出Runbook初版。Ø测试验证：使用DRS迁移客户备份的真实数据，验证准备时间、迁移时间、数据对比时间、系统切换时间、遗留问题、实施顺序等项，并完善Runbook。Ø迁移实施：按照Runbook一步步标准化实施迁移，数据比对一致。Ø系统割接：正式割接后，业务验证正常。迁移成功。Ø保障移交：监控与巡检，并进行一周的业务重点保障，配合客户完成项目验收，培训与赋能。异地容灾方案描述：          华为云伊斯坦布尔Region两个AZ组成主备高可用，在距伊斯坦布尔400KM的安卡拉与VDF共建HCSO，采用Postgres数据库原生的流复制技术，组成公 有云伊斯坦布尔的异地灾备中心。流复制技术原理：流复制是基于 wal 日志传送技术实现同步，主节点（master）启用 walsender 进程持续发送 wal 日志流，备节点（standby）通过 walreceiver 进程实时接受从主传过的 wal 日志流，并且通过 walreceiver 进程调用内部函数write() 和 fsync() 将 wal 数据全部写入wal segment 和刷新到 wal segment，并通知 starup 进程回放已经写入wal segment 的 wal 数据。

案例简介：       XX目前数据库采用自建的MySQL、MongoDB。客户希望业务全面上云替换，现将采购少量部署在测试区进行业务验证。目前客户现网云平台采用全栈华为硬件以及华为云，预计涉及数据库软件服务订货价格XXw+。本次试验局验证主要验证DDS云服务基础功能与数据迁移功能。方案描述：    源端环境：自建MongoDB；数据大小100G；    数据迁移：使用DRS全量+增量的方法迁移数据    数据核对：使用DRS自带数据核对工具，对迁移数据条数进行数据核对，数据条数核对上就默认迁移完成    问 题解决：通过查询技术手册解决客户问题，如果有不能解决的问题就通过向开发需求提单，通过开发来解决客户问题。    DDS技术手册：文档数据库服务(DDS) 2.22.07.210 使用指南(for 华为云Stack 8.2.0) 01 - 华为 (huawei.com)

案例简介：XX集团，全球领先的智能物流平台，是国内首家基于云计算、大数据、移动互联网和人工智能技术开发的XX公司，是公路物流领域高新技术综合应用的典型代表XX平台服务的认证司机用户超XX万人，认证货主用户超XX万人，集团业务覆盖全国XX个主要城市。年度撮合成交规模达到XX元，覆盖线路数量超过XX条，此案例主要介绍Kylin组件搬迁。迁移方案：Økylin依赖的所有hive表数据使用CDM工具迁移  Økylin元数据hbase表kylin_metadata数据使用阿里LTS迁移，其中存放了kylin系统级、project级、cube级、job级等各个级别元数据  Ø根据腾讯云环境信息构建历史segment  Ø华为云调度系统定时触发华为云Cube构建  Ø查询华为侧结果集数据，数据一致性校验割接关键步骤：Økylin依赖所有hive表数据迁移Økylin构建历史segment预计算数据 Ø调度任务所有kylin相关任务正常执行 Ø双云预计算数据一致性校验Ø业务正常查询华为云侧kylin预计算数据Ø业务切换查询地址为华为侧地址回滚步骤：Ø切换到华为云地址后，如出现短时间无法解决问题，业务切换查询地址为腾讯侧地址XXkylin迁移&割接方案：cid:link_0使用LTS/BDS迁移Hbase指导：cid:link_1

案例简介：       XX成立于2015年，是目前全球UGC赛道最大的中国游戏公司,在全球拥有XX万注册用户，覆盖美国、新加坡、港澳台、法国、阿联酋、巴西等XX个国家。目前客户现网以AWS+GCP部署为主，目前在AWS一年消耗XXWUSD，主要为业务大厅服源站以及数据收集和分析功能，包含大数据、数据库等业务，GCP一年消耗XXWUSD，主要为业务战斗服，包含服务器和流量业务，本次迁移客户有待迁移Redis实例XX个。数据迁移：1、确认客户业务停止，无应用访问Elastic Cache；2、在AWS源端控制台Elastic Cache导出全量备份文件；3、通过公网传输至华为云，检查备份文件MD5码前后是否一致，使用Redis-Shake工具将数据恢复到GeminiDB Redis中。4、进行数据校验，对GeminiDB Redis进行key值校验；5、数据校验通过后，应用链接GeminiDB Redis实例开始对外提供业务。数据校验：1、查询迁移后源端和目的端内存占用量是否一致；2、使用info keyspace语句查询并对比源端和目的端的key数量是否一致；3、使用脚本随机多次进行抽样内容校验。（客户数据部分具有时效性，可能存在因源端数据过期后源端和目的端前后数据不一致的问题，需要手动查询不一致的数据是否因数据过期引起）。回退方案（A-B-A）：1、AWS侧创建Elastic Cache备用实例，承接回退实例数据2、配置GeminiDB Redis到AWS EC2的DRS全量链路，EC2与Elastic Cache配置SSH隧道；3、启动DRS任务，全量完成后，进行数据校验；4、数据校验通过后，应用修改数据库链接为AWS Elastic Cache备用实例。

案例简介：    XX公司成立于2016年，短短六年间，XX依托于自身在人工智能、大数据领域的技术优势，和丰富的教学资源，已占领法考在线教育领域XX以上的市场份额，用户数量全国第一。近年业务也在向CPA和英语在线培训领域快速发展。       目前XX业务全量部署在A3云上，云空间XX万左右。       此次迁移是XX A3部署的法考、CPA、官网等业务系统。    方案描述：平台部署：网络打通；华为各云服务开通；自建服务的搭建和对接业务表的创建：在DWS里面进行业务模型表的重建（分布列、分区列、冷热策略、行列存储，业务逻辑主键）数据迁移：离线Hive数仓各层数据迁移（客户自己通过回退的方式把数据会退到PoloDB中，再通过gaussdb同步到DWS）；实时听课数据通过DMS接进，然后通过flink消费，最后落进DWS。由于kudu数据不大客户自己写进DWS； PoloDB全量+增量数据通过gaussdb同步到DWS。历史数据的处理：数据的打宽，清洗作业迁移：设计所有业务的数据打宽，清洗逻辑重构，DGC作业的配置及调度数据以及性能的校验：1.历史数据的验证.2.实时增量数据的验，验证范围（所有表）3.实时流程性能验证，4.主要业务场景验证。5.Polo到gaussdb后记录数据量验证。割接：停止往Polo写数据，切换到gaussdb ，埋点数据写进DMS，停止阿里的离线作业，DWS同步正常，flink作业验证正常，观察业务运行状态，核对数据正确性，完成业务割接。

8月21日-23日，由云原生计算基金会（CNCF）和 Linux 基金会联合主办的KubeCon + CloudNativeCon + Open Source Summit + Al_dev China 2024 大会在中国香港盛大召开。会上，多位Kuasar社区Maintainer分享了关于云原生容器运行时与大模型等领域前沿技术的案例实践与经验思考。KubeCon China 2024 主题演讲Kuasar[1]于2023年4月在KubeCon Europe上由华为云联合多家企业和社区发起，12月正式成为CNCF首个多沙箱容器运行时项目。Kuasar基于 Rust 语言实现，提供基于 MicroVM/App Kernel/WebAssembly / runC类型的沙箱容器，融入了各企业和社区在容器运行时领域的前沿探索、技术积累和生产实践，开源至今受到业界的广泛关注和支持，已收获1200多个GitHub Star和85个Fork，数十位来自外部企业、高校的开源爱好者参与开发贡献和积极落地应用。▍使用Kuasar和WasmEdge在Kubernetes上部署大语言模型Kuasar 社区 Maintainer Burning Zhang（华为云），携手WasmEdge社区创始成员Vivian Hu（Second State）带来了主论坛演讲《使用Kuasar和WasmEdge在Kubernetes上部署大语言模型》。《使用Kuasar和WasmEdge在Kubernetes上部署大语言模型》大语言模型（LLM）是强大的人工智能工具，能够理解并生成自然语言。然而，传统运行LLM的方法面临着诸多挑战，包括复杂的软件包安装、GPU设备兼容性问题、不灵活的扩展性、有限的资源监控和统计，以及存在安全漏洞。云原生人工智能（CLOUD NATIVE ARTIFICIAL INTELLIGENCE）白皮书[2]指出：“WASM is a platform-independent, efficient CN approach to inference.”“WASM 是一种高效、平台无关的云原生推理方法。” 云原生人工智能（CLOUD NATIVE ARTIFICIAL INTELLIGENCE）白皮书WasmEdge 提供了一种基于 WebAssembly 运行时的解决方案，使得开发快速、灵活、资源高效且安全的 LLM 应用程序成为可能。Kuasar 作为容器运行时，无缝集成了 WebAssembly 运行时，使应用程序能够在 Kubernetes 集群上顺利运行。在Kubernetes中集成LLM借助 Kuasar 和 WasmEdge 在 Kubernetes 集群中运行大模型负载的实践，成功解决了大模型应用开发和部署的两个关键痛点问题。首先，通过 WebAssembly 技术，解决了传统技术在跨平台兼容性和复杂依赖性方面的挑战。开发者不再需要为不同 CPU 架构之间的编译与运行问题头疼，也无需为不同 GPU 驱动版本的兼容性以及 Python/PyTorch 复杂的依赖包问题而烦恼。WebAssembly 提供了一个统一的运行环境，使得跨平台的应用开发和部署变得更加简洁和高效。另一方面，Kubernetes 集群本身为 LLM 负载程序提供了强大的容器编排能力，极大地简化了大模型的开发和部署过程。打包与部署：通过将大模型打包成容器镜像，能够轻松实现应用在集群任意节点上的批量部署，显著提高了部署效率。资源管理：Kubernetes 提供了精细的资源申请和管理机制，可以为每个应用合理规划异构资源的申请和限制，确保在划定的 QoS 范围内进行高效调度。弹性伸缩：Kubernetes 可以快速实现弹性伸缩，既能保证服务质量，又能最大化资源利用率。可观测性：借助 Kubernetes 的可观测性能力，能够更好地监控负载，收集性能数据，并记录日志，为优化和故障排除提供数据支持。服务发现与负载均衡：Kubernetes 提供了服务发现和负载均衡功能，使得应用程序间的交互和联网更加顺畅。灰度发布：支持灰度发布，使大模型的版本迭代和更新过程更加平滑，降低了新版本上线的风险。通过这些能力，Kubernetes 不仅简化了大模型应用的部署和管理，还大幅提升了其运行效率和稳定性，加速云原生技术与 AI 生态的深度融合与发展。▍基于Containerd的Sandbox API构建容器运行时华为云云原生团队，Kuasar社区Maintainer Abel Feng和来自DaoCloud的Containerd  Committer 蔡威共同分享了《如何基于Containerd的Sandbox API构建容器运行时》。《如何基于Containerd的Sandbox API构建容器运行时》随着不同类型的隔离技术（如沙箱）的引入，容器现在更多地是一组API规范，而不是单一技术。目前Containerd社区已经社区围绕Sandbox概念衍生出一套新的数据结构和管理接口Sandbox API, 以便轻松集成不同类型的沙箱技术，使其成为容器运行时。Containerd中的Sandbox 和Container基于Sandbox API接口实现，Kuasar 结合了华为云多年生产业务实践以及对沙箱技术发展的思考，在保留传统容器运行时功能的基础上，通过全面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创新版本上一键部署。Kuasar各 sandbox架构图应用场景方面，Kuasar 在轻量级安全容器、公有云远程沙箱以及基于 WebAssembly的 LLM 推理场景下展现了其巨大的架构优势。通过 Kuasar，用户能够在轻量级虚拟机中实现高效、安全的资源隔离与管理，甚至可以将远程的IaaS的虚拟机作为沙箱进行灵活管理。此外，在运行 LLM 推理任务时，Kuasar 的架构能够充分利用 WebAssembly技术，实现高效的资源利用和跨平台兼容性，为 AI 应用提供了基础架构支持。目前，Kuasar社区已经发布v1.0.0版本[3]，这是该项目的一个重要里程碑。此次发布的版本标志着 Kuasar 的 Cloud Hypervisor 沙箱容器已经达到了稳定和成熟的阶段，可为开发者和企业用户提供了更为安全的云原生容器化部署，以提升容器的安全性和隔离性。用户可通过小规模测试，验证其在实际场景中的表现。▍总 结在本届 KubeCon 大会上，Kuasar社区联合WasmEdge社区分享了对大模型应用在云原生场景的部署，加速AI在云原生领域的落地，和Containerd社区展示了应用最新的Sandbox API构建多沙箱容器运行时的可能，以及Kuasar 社区在这方面的应用案例和探索，旨在帮助开发者和企业用户更好地容器化上云。大会期间带来的新版本v1.0.0性能更加成熟，欢迎大家体验。展望未来，Kuasar 将继续致力于云原生多沙箱容器领域的深入研发，深入挖掘和满足更多用户场景的需求，不断优化和扩展技术栈，为用户提供更加全面、成熟和高效的解决方案。相关链接：[1]Kuasar多沙箱容器运行时: cid:link_1[2]云原生人工智能白皮书: https://www.cncf.io/wp-content/uploads/2024/03/cloud_native_ai24_031424a-2.pdf[3]Kuasar v1.0.0 版本: cid:link_0更多云原生技术动向关注容器魔方

华为云云原生容器团队致力于成为技术创新先锋，通过云原生容器化技术，为企业数字化转型提供强大动力，让云无处不在，让智能无所不及，共建智能世界云底座。云原生产业方面，我们连续4年位居云容器软件市场份额国内TOP 1，深入理解不同行业需求，先后在云容器引擎、Serverless、边缘计算、分布式云等多个场景推出成熟的云服务，在互联网、金融、政企等多个领域打下良好口碑。云原生技术方面，我们是CNCF国内唯一初始成员，拥有本土唯一CNCF TOC席位和多个CNCF项目技术委员会/治理委员会成员及核心Maintainer，先后主导开源了KubeEdge、Volcano、Karmada、Kuasar等多个CNCF项目，是全球云原生开源技术的领导者之一。 岗位描述 云原生产品架构师 / 研发工程师负责华为云云原生产品及服务的系统设计、代码研发、技术攻关及关键技术预研等，保障云容器服务的持续稳定运行，构建产品技术竞争力，提升产品的市场竞争力和客户价值。云原生开源架构师 / 研发工程师参与云原生开源项目需求分析，洞察业界趋势，用户场景挖掘，构筑高可靠、高性能的开源项目竞争力参与云原生开源项目的代码开发、维护，构建最活跃的开源社区参与云原生开源项目的社区治理与生态建设，打造社区生态参加业界会议，布道宣传开源生态，打造云原生项目的技术品牌和影响力任职要求 本科及以上学历，计算机或相关专业，5年以上软件或行业相关工作经验。了解云计算常用技术，如云原生、容器化、虚拟化、AI、容器引擎、服务治理等技术和架构，熟悉云服务的部署、监控和维护，能够处理常见的故障和问题。具备较强的技术架构设计和方案设计能力，良好的沟通和团队协作能力，能够与客户和合作伙伴进行有效的交流和合作。具备良好的自我学习和创新意识，能够跟踪最新的技术发展趋势，不断提高自己的技术水平和创新能力拥有CNCF社区贡献，熟悉CNCF项目（如Volcano、Kubeflow、KubeEdge、confidential-containers、kepler、OpenTelemetry等项目）优先简历投递 华为云云容器团队社招HC，北京、杭州、深圳、上海均有岗位，欢迎感兴趣的朋友联系。联系方式：手机/微信：15191581137邮箱：chengtenglang@huawei.com