作者：王彬丞、杨志佳、刘家伟随着万物互联时代快速到来，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/

MindSpore2.3.0+Ascend910A，镜像为swr.cn-north-4.myhuaweicloud.com/atelier/mindspore_2_3_ascend:mindspore_2.3.0-cann_8.0.rc2-py_3.9-euler_2.10.7-aarch64-snt9b-20240727152329-0f2c29a，运行测试样例报错RuntimeError: Call aclnnSub failed, detail:EZ9999: Inner Error!kernel没装全导致二进制算子操作报错。/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/numpy/core/getlimits.py:499: UserWarning: The value of the smallest subnormal for <class 'numpy.float64'> type is zero. setattr(self, word, getattr(machar, word).flat[0])/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/numpy/core/getlimits.py:89: UserWarning: The value of the smallest subnormal for <class 'numpy.float64'> type is zero. return self._float_to_str(self.smallest_subnormal)/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/numpy/core/getlimits.py:499: UserWarning: The value of the smallest subnormal for <class 'numpy.float32'> type is zero. setattr(self, word, getattr(machar, word).flat[0])/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/numpy/core/getlimits.py:89: UserWarning: The value of the smallest subnormal for <class 'numpy.float32'> type is zero. return self._float_to_str(self.smallest_subnormal)[ERROR] RUNTIME_FRAMEWORK(3361,ffff93dd11e0,python):2024-10-31-20:00:24.542.957 [mindspore/ccsrc/runtime/graph_scheduler/actor/actor_common.cc:327] WaitRuntimePipelineFinish] Wait runtime pipeline finish and an error occurred: Call aclnnSub failed, detail:EZ9999: Inner Error!EZ9999: 2024-10-31-20:00:24.531.850 Parse dynamic kernel config fail.[THREAD:3973] TraceBack (most recent call last): AclOpKernelInit failed opType[THREAD:3973] Op Sub does not has any binary.[THREAD:3973] Kernel Run failed. opType: 3, Sub[THREAD:3973] launch failed for Sub, errno:561000.[THREAD:3973]----------------------------------------------------- C++ Call Stack: (For framework developers)----------------------------------------------------mindspore/ccsrc/plugin/device/ascend/kernel/opapi/aclnn/sub_aclnn_kernel.h:36 RunOpTraceback (most recent call last): File "/home/ma-user/work/Test/test.py", line 36, in <module> out = net(x, y) File "/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/mindspore/nn/cell.py", line 703, in __call__ out = self.compile_and_run(*args, **kwargs) File "/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/mindspore/nn/cell.py", line 1074, in compile_and_run return _cell_graph_executor(self, *new_args, phase=self.phase) File "/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/mindspore/common/api.py", line 1860, in __call__ return self.run(obj, *args, phase=phase) File "/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/mindspore/common/api.py", line 1911, in run return self._exec_pip(obj, *args, phase=phase_real) File "/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/mindspore/common/api.py", line 185, in wrapper results = fn(*arg, **kwargs) File "/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/mindspore/common/api.py", line 1891, in _exec_pip return self._graph_executor(args, phase)RuntimeError: Call aclnnSub failed, detail:EZ9999: Inner Error!EZ9999: 2024-10-31-20:00:24.531.850 Parse dynamic kernel config fail.[THREAD:3973] TraceBack (most recent call last): AclOpKernelInit failed opType[THREAD:3973] Op Sub does not has any binary.[THREAD:3973] Kernel Run failed. opType: 3, Sub[THREAD:3973] launch failed for Sub, errno:561000.[THREAD:3973]----------------------------------------------------- C++ Call Stack: (For framework developers)----------------------------------------------------mindspore/ccsrc/plugin/device/ascend/kernel/opapi/aclnn/sub_aclnn_kernel.h:36 RunOp

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

展望未来科技前沿，探索云原生边缘计算与边缘AI的无限可能！本期直播我们将解读业界首个云原生边缘计算框架KubeEdge的架构设计，如何实现边云协同AI，将AI能力无缝下沉至边缘，让AI赋能边侧各行各业，构建智能、高效、自治的边缘计算新时代，共同探索智能边缘的新篇章！直播链接：cid:link_0Q：云边协同推理是在云和边各一个模型吗？是通过什么指标将任务卸载到云端呢？A:sedna案例中云边协同推理是将一个大模型部署在云端，并将一个小模型部署在边缘端，对于简单的推理任务可以直接在边端推理，针对较难的任务可以由云端大模型推理。我们可以设置一个置信度阈值指标判断推理任务是否是难例，将难例使用云端大模型推理。Q：k8s 调用 kubeEdge 服务兼容性不匹配，如何解决？A:可能是因为版本的原因，一个kubeedge的版本能够兼容3个k8s的版本，需要安装合适版本的k8s。Q：边缘节点的故障恢复，KubeEdge是如何处理的？A:KubeEdge利用边缘侧轻量级数据库实现了云边消息元数据的持久化，这是其故障恢复能力的重要基础。通过将Pod、ConfigMap等基础元数据持久化在边缘节点上，确保即使在边缘节点离线或重启后，这些元数据也能被保留下来。这样，当边缘节点重新上线时，它可以直接从本地获取这些元数据，快速恢复应用的状态。Q：现在安装KubeEdge最简单的方式有推荐吗？A:社区推荐大家使用官方安装组件keadm进行安装，使用keadm安装时在云端节点只需执行keadm init命令进行初始化，获取秘钥后在边缘节点上执行keadm join命令即可。详细的安装教程可以参考官方文档https://kubeedge.io/docs/setup/install-with-keadm。此外，对于想试用KubeEdge功能的初学者，还可以使用keink工具自动创建一个KubeEdge集群，可以参考https://github.com/kubeedge/keinkQ：KubeEdge在边缘AI场景下如何提升模型的推理效率？A:kubeedge一方面借助Kubernetes的容器编排能力，实现了边缘AI应用的自动化部署和管理。另一方面还提出边缘AI智能框架sedna，其边云协同的理念能借助云端充足的资源提升边缘模型的性能，也可以使用边云协同推理提升系统推理效率。Q：kubeedge是否在边缘异常断电文件系统损坏做了相关优化， 边缘侧电力稳定性有可能较差，会存在异常断电场景A:kubeedge主要是对云边消息传递的可靠性做了增强，使用一个轻量级数据库存储云边控制命令的元数据，对于边缘节点的文件系统没有做相关的功能增强。Q：介绍一下边缘节点和kubeEdge的部署A:我们目前有三种方式部署kubeedge，分别是采用keadm、二进制部署以及keink自动部署，相关文档可以参考https://kubeedge.io/docs/category/setupQ：边缘AI在哪些行业有应用前景？A:边缘AI在智慧城市、智能家居、智慧医疗、AR/VR技术等方面有着广阔的应用前景。Q：边缘计算环境中，KubeEdge如何保障数据的安全性和隐私性？A:KubeEdge在节点安全方面，采用了容器隔离、CNI网络安全、节点入侵检测和容器自愈等技术。在访问控制方面，利用Kubernetes的RBAC（基于角色的访问控制）权限管理功能，能够对集群资源进行细粒度的访问控制。Q：云边之间的数据传输是否支持视频格式的传输？A:这里我们主要考虑到视频一般的传输数据量是很大的，如果使用云边通道进行传递会导致严重的通信负荷，使用目前在kubeedge 1.17版本的特性中我们只实现将摄像头采集到的视频流转化成帧文件或者视频片段存在边缘节点上，暂时不支持向云端传输。Q：CDN部署过程中，怎么保证节点容器有序和可控的升级？ 是否支持版本的A/B 测试？ 怎么对升级过程进行校验？A:可以通过分批升级与组内升级并发控制、细粒度版本设置、升级校验等方式解决以上问题，可以参考https://kubeedge.io/zh/case-studies/ctyun/Q：对于数据孤岛问题。对于需要对设备调节参数的场景，同一租户在不同楼宇中的控制系统，甚至电力系统部互通。那么对于这种需要预测的参数怎么去调整？同样的情况下，基于安全原因，不支持打洞，那edgemesh是不是就不能用了？A:可以采用sedna中提供的联邦学习能力，在边缘侧直接进行模型训练，只把训练得到的模型参数上传云端。Edgemesh核心的特点就是使用中继和P2P打洞技术联通边缘节点。Q：云边协同推理是根据哪些指标将任务卸载到云端呢？A:在sedna有关云边协同推理的案例中，是通过设置一个阈值指标用于衡量推理任务是否是难例，可以将难例放置在云端进行推理。Q：Sedna的推算准确率高吗？达到了什么样的程度？A:sedna的定位主要是为了将用户已有的AI应用下沉至边缘侧，能够让用户部署更便捷，推算的准确度一般是和用户的训练得到的模型相关。Q：云端训练后的结果如何通过局域网推送到边缘端设备？A:可以通过云边通道、edgemesh来进行通信。Q：对比其他边缘计算框架，KubeEdge有哪些独到之处？A:KubeEdge的核心理念是基于Kubernetes提供的云原生能力，在边缘计算场景下进行了增强，所以一方面有云原生的基础能力支持，比如利用容器化技术屏蔽边缘复杂的底层硬件环境、利用云原生管理技术能够让故障的用户应用迅速回滚；另一方面做了组件轻量化、云边消息可靠性增强以及边缘设备管理能力增强，更加适合云原生边缘计算场景。Q：因docker的问题边端安装时基础环境镜像无法下载的问题怎么处理，官方是否有备用镜像库A:可以在能够下载镜像的节点上下载镜像，再打包至边缘节点。Q：分集群部署K8s的控制面和集群太多，怎么构建统一的CDN调度平台又不会过度占用机器资源？A:案例中CDN管理平台是在大区的区域中心、数据中心上部署k8s集群，通过kubeedge纳管边缘节点，具体的技术实现可以参考kubeedge官网的案例解读https://kubeedge.io/zh/case-studies/ctyun/Q：如何评估一个应用场景是否适合采用KubeEdge进行边缘AI部署？A:可以看具体的应用场景是否有云边协同的需求Q：Sendna的模型管理中，模型文件量化是如何处理的？模型work是独立运行在容器里面的还是需要和业务相结合的，例如视频的解码、推理、编码不放在一个容器里面的话延时是否会有问题？A:需要根据实际的使用场景判断，比如解码、推理、编码容器是部署在一个节点上、或者部署在多个节点上的时延是不同的。Q：脸检测模型最多同时检测到多少张脸啊？A:需要针对模型的性能、节点资源等角度具体分析。Q：karmada和KubeEdge有哪些区别？A:karmada是面向多云原生集群编排的，kubeedge主要面向云原生边缘计算场景。Q：如何解决边缘节点样本数量少的问题？A:kubeedge sedna支持多种训练和推理模式，其中终身学习主要用于解决小样本与边缘数据异构问题。Sedna会在云节点上部署一个知识库，能够辅助边缘端完成推理，并不断学习未知任务更新知识库。Q：KubeEdge最大支持管理多少规模边缘节点？A:目前有案例表明kubeedge接入的边缘节点规模突破10万，可以参考https://kubeedge.io/zh/blog/scalability-test-reportQ：KubeEdge如何处理多租户环境下的资源隔离？A:kubeedge依然保留了k8s的原生能力，因此可以通过创建命名空间、创建资源配额等的方式完成多租户环境下的资源隔离。Q：KubeEdge如何与云服务集成？A:KubeEdge核心理念是在原有Kubernetes云原生能力的基础上，面向边缘场景做了功能的增强，例如云边传递消息可靠性的增强、组件的轻量化，能够依托目前成为事实标准的Kubernetes api完成边缘与云上一致的使用体验，因此云服务依然可以参考传统Kubernetes中的部署方式进行部署。Q：云端可以批量升级边缘吗？A:在KubeEdge 1.16版本中，我们对边缘节点的批量升级这一特性做了功能增强，NodeUpgradeJob 的 Kubernetes API 进行边缘节点的一键化、批量升级。API 支持边缘节点的升级预检查、并发升级、失败阈值、超时处理等功能。对此，KubeEdge 支持了云边任务框架。社区开发者将无需关注任务控制、状态上报等逻辑实现，只需聚焦云边任务功能本身。 具体信息可参考https://kubeedge.io/blog/release-v1.16#support-cloud-and-edge-components-upgradeQ：EdgeMesh对边缘站点有哪些要求？A:运行EdgeMesh的边缘节点需要满足正常kubeedge对于边缘节点的要求，例如需要部署容器运行时、还需要满足硬件资源的一些限制。Q：KubeEdge如何处理边缘计算中的网络不稳定问题？A:KubeEdge针对边云连接不稳定、时常断连的情况，做了消息可靠性的增强，也是KubeEdge的核心特性之一。云上向边缘端下发控制命令时会检查边缘是否回传了ack应答，以此验证消息是否下发成功，并且云端会将消息进行编号，记录消息的下发。当边缘端长期断链后再次连接时，就不需要将消息全部重新发送，避免造成带宽冲击。另一方面，我们还实现了边缘自治的能力，在边缘节点上部署了一个轻量级的数据库，云上发送到边缘的元数据会保存在这个数据库中进行持久化，在边云连接长时断开或者边缘节点宕机重启后，能从边缘数据库中恢复用户应用。Q：EdgeMesh Agent之间打洞失败时怎么判断流量是否中转成功？A:当EdgeMesh打洞失败时可以使用EdgeMesh-server来中继流量，确保流量中转成功。Q：如果对安全要求很高的情况，那edgemesh的打洞不被允许，那这个特性是不是也用不了了。A:Edgemesh需要在边缘节点跨局域网时通过P2P打洞和中转技术才能完成边缘节点间的通信。Q：怎么降低两个边缘节点上的流量经过 EdgeMesh中转的网络时延？A:可以将EdgeMesh中继节点部署在地理位置适中的位置，以缩短数据传输的物理距离；也可以使用负载均衡技术将流量均匀分配到多个中继节点上，避免单个节点过载，从而提高整体的网络性能和降低时延。Q：1.12.7版本边端启动一段时间后云端可正常获取到边端的cpu，内存等状态信息，但运行一段时间后（一天或两天不固定）会出现边端状态信息上报失败连接超时，但除状态信息外其他都正常。边端重启后即恢复正常，这种情况可能有哪些原因造成的A:可以查看日志中是否有其他报错，例如channel已满，也可以使用go pprof等工具查看是否有内存泄露或者goroutine泄露的情况。Q：边缘设备开发有无官方开发板？A:目前我们已经内置了一些典型边缘设备协议的mapper插件，例如modbus、onvif等，用户可以直接使用我们提供的mapper对边缘设备进行管理，也可以仿照内置的mapper，自行通过mapper-framework开发框架实现其他协议mapper。内置的mapper地址为https://github.com/kubeedge/mappers-goQ：kubeEdge连入k8s如何防止抖动（经常断了又连接上）呢，毕竟数量太多的话会对集群造成影响A:kubeedge针对边云连接不稳定、时常断连的情况，做了消息可靠性的增强，也是kubeedge的核心特性之一。云上向边缘端下发控制命令时会检查边缘是否回传了ack应答，以此验证消息是否下发成功，并且云端会将消息进行编号，记录消息的下发。当边缘端长期断链后再次连接时，就不需要将消息全部重新发送，避免造成带宽冲击。另一方面，我们还实现了边缘自治的能力，在边缘节点上部署了一个轻量级的数据库，云上发送到边缘的元数据会保存在这个数据库中进行持久化，在边云连接长时断开或者边缘节点宕机重启后，能从边缘数据库中恢复用户应用。Q：KubeEdge对于跨地域的边缘计算部署有哪些支持？A:KubeEdge 1.11版本引入了“边缘节点分组管理”新特性，该特性允许将边缘节点按地区划分为节点组，使得应用所需资源可以打包成一个整体在节点组上进行部署。这种分组方式有效降低了边缘应用生命周期管理的复杂度，并减少了运维成本。Q：边缘设备的数量有限制吗？A:目前已经有案例表明kubeedge能够支持上万边缘设备的管理Q：KubeEdge支持哪些类型的工作负载？A:由于kubeedge的核心理念是基于k8s云原生能力，在边缘场景下做了一些功能的增强，因此传统k8s中工作负载的类型在kubeedge中都能够支持，例如deployment、job等。Q：云原生边缘计算与传统云计算相比有哪些优势？A:第一，云原生边缘计算拥有低延迟与高实时性，能够更快地响应用户请求，提供更高的实时性服务。第二，云原生边缘计算能够保障数据隐私与安全，能够在本地或靠近数据产生的地方处理数据，减少了数据传输的中间环节，从而提高了数据的安全性。第三，云原生边缘计算能带来带宽与成本优化。数据在边缘端处理能够减少数据传输的距离，降低了对带宽的需求，从而有助于降低网络成本。Q：KubeEdge对于边缘设备的异构性是如何处理的？A:kubeedge通过mapper插件对边缘设备进行管理，mapper中集成了设备驱动，可以按照对应的协议访问物理设备、获取边缘设备的数据或者状态。Mapper通过实现edgecore中DMI这个设备管理统一接口完成自身向集群的注册，最终完成设备的纳管。DMI采用grpc+uds的机制，定义了通用的接口，能够屏蔽设备之间的差异。Q：在KubeEdge的sedna中，实现边云协同AI的具体步骤是怎么样的A:由于sedna定位并不是tensorflow pytorch这类的深度学习框架，而是提供把用户已有的AI应用能力下沉至边缘端，减少用户构建部署的成本。因此第一，用户需要根据典型的框架实现自己的AI应用，并根据sedna中的要求对代码做一些修改，主要是导入sedna边云协同推理库，设置推理阈值等，修改完成后可以打包为一个镜像；第二，需要实现sedna中定义的部分crd文件，例如model crd定义的用户模型参数；第三，提交AI任务。用户可以定义sedna中JointInferenceService之类的任务crd，提交至集群，由sedna完成部署。Q：KubeEdge中边缘端和云端是如何高效同步状态和配置信息A:kubeedge中需要用到多个组件共同协作，完成云边同步状态和配置信息。在云端主要是依靠cloudhub和synccontroller，synccontroller中一方面会对云端下发的消息进行记录并编号，保证消息下发的连续性，另一方面也会定期同步云边状态，cloudhub则是实际执行消息传递的。在边缘端有edgehub，metamanager等组件来辅助云边通信，edghehub和cloudhub对应，接收cloudhub下发的消息并转发，metamanager一方面实现边缘自治，把核心元数据保存在边缘数据库中，一方面会把edgehub中的消息转发到边缘其他模块。Q：在边云协同过程中，如何处理数据的实时性与一致性？A:可以依赖kubeedge提供的云边消息同步机制。云端下发消息时会监测边端是否回传ACK应答，确保消息下发成功，另一方面云端使用synccontroller对云端下发的消息进行记录并编号，保证消息下发的连续性，也能定期同步云边状态。Q：KubeEdge在管理边缘设备必须通过mapper吗A:kubeedge是需要mapper来管理边缘设备的，mapper是kubeedge中的设备管理插件，其中集成了对应协议设备的驱动程序，能够实际连接到物理设备，并且获取设备状态与数据。Mapper实现了edgecore中DMI的相关接口，能将自身注册入kubeedge集群，并且将管理的设备状态数据通过DMI接口上报到edgecore，edgecore会对这些消息进行处理封装，通过云边通道上传到云端cloudcore，cloudcore中的devicecontroller就是edgecore中上报的设备信息与k8s apiserver通信的桥梁，完成对边缘设备的管理。Q：基于KubeEdge云原生边缘计算如何保障数据处理的实时性呢？A:kubeedge整合了云计算的优势和边缘计算的优势，能在靠近物或数据源头的网络边缘侧就近处理海量数据，具有毫秒级的实时响应。Q：KubeEdge安装部署有什么要求A:KubeEdge是依赖Kubernetes的，在部署前需要先拥有一个Kubernetes集群，同时KubeEdge也是以容器化的形式管理用户边缘应用的，所以也需要下载相应的容器运行时，比如containerd。Docker等，当然因为目前Kubernetes已经不在使用docker作为默认的容器运行时，所以使用高于1.14版本的KubeEdge时需要使用cri-dockerd，相关容器运行时的安装以及注意事项在我们的官网文档中也有介绍https://kubeedge.io/docs/setup/prerequisites/runtime/，大家可以参考。Q：KubeEdge如何将AI能力下沉至边缘？有哪些具体的技术实现和优化措施？A:kubeedge提出了边缘智能框架sedna，基于KubeEdge提供的边云协同能力，支持用户现有AI类应用无缝下沉到边缘，降低用户构建与部署成本、提升模型性能、保护数据隐私。Sedna能够提供基础的边云协同数据集管理、模型管理功能，具有协同推理、增量学习、联邦学习和终身学习的能力，能够更好的实现边云协同AI。Q：是否依赖边缘节点算力大小？A:kubeedge从部署的角度来说实现了组件的轻量化，目前已经能将内存占用降低至70M左右，减少了边缘节点的资源要求。除安装需求外，边缘节点算力的需求主要与用户部署的边缘应用相关，需要根据用户应用的大小评测具体的算力消耗。Q：KubeEdge的架构设计主要关注哪些关键组件？A:kubeedge云端和边端都运行了众多组件，其中云端组件包括EdgeController、deviceController、Synccontroller、cloudhub等，边端组件包括edgehub、MetaManager、edged、devicetwin、EventBus、ServiceBus等，每个组件都有重要的功能，具体的介绍可以访问我们的官方文档 https://kubeedge.io/docs/category/architectureQ：对于KubeEdge的边缘节点应该怎么配置？A:目前官方推荐大家使用keadm这个安装管理工具来部署kubeedge集群，可以在获得云端kubeedge集群的token后，使用keadm join命令加入kubeedge集群，并且自动部署edgecore组件。Q：KubeEdge与K8s有什么关系，与k8s的兼容性如何，是否支持最新版本的k8s？A:Kubeedge核心理念是基于k8s原生能力，在边缘计算场景下做了一些增强，因此与k8s的兼容性是kubeedge的核心特点之一。一般来说一个Kubeedge版本可以兼容3个版本的k8s，在每三个月kubeedge发布版本时，都会升级k8s的依赖，我们近期刚发布的1.18版本已经能够兼容1.29 1.28 1.27三个版本的k8s，欢迎大家使用。Q：边缘计算\边缘AI\云计算有什么区别？A:云是中心化、按需获取的大规模计算资源共享池，服务于广大的区域，能够提供几乎无限的算力；边缘计算是靠近数据产生源头的计算能力，服务于广小的区域，提供受限的算力。边缘AI是指在边缘计算环境中实现的人工智能。Q：KubeEdge在边云协同中如何处理数据安全与隐私保护？A:KubeEdge在数据传输过程中采用了全链路加密技术，确保数据在云端和边缘端之间的传输过程中不被窃取或篡改。这种加密方式涵盖了数据的整个传输路径，从源头到目的地都保持数据的安全性。Q：KubeEdge如何应对边缘设备的动态性和不确定性？A:kubeedge采用mapper设备管理插件来实际管理物理设备。在mapper中承载了DMI数据面能力，能够按照用户设置的周期定时采集设备状态与数据，并进行数据推送。Q：KubeEdge是否支持边缘设备的本地自治？网络中断时，边缘节点能否独立运行和做出决策？可以中断多久？A:kubeedge针对边云经常断连的情况，在边缘节点上部署了轻量级的数据库，可以存储云端命令的核心元数据，在边缘节点断开连接时能够依靠数据库维持边缘应用和设备稳定运行。在证书未过期的情况下理论上可以保持断连状态，随时重新连接。Q：KubeEdge是否对边缘侧异常断电场景有优化？边缘侧电力稳定性比较弱 经常断电A:kubeedge主要是对云边消息传递的可靠性做了增强，在边缘节点上部署一个轻量级数据库存储云边控制命令的元数据，在边缘节点断电重启时可以依据数据库的数据进行恢复想要了解更多云原生相关知识，欢迎观看DTSE Tech Talk 系列技术直播

在数字化转型的浪潮中，云原生技术以其独特的优势成为了企业创新发展的强大引擎。为了助力开发者们更深入地理解云原生，掌握其实践精髓，华为云DTSE将通过一个实践案例，介绍云原生技术改造方案。融合运用华为云高阶服务，助力企业应用云原生改造，提升系统弹性能力，探索云原生实践新路径。直播链接：cid:link_5Q：云原生技术架构的未来主流发展趋势是怎么样的？A:1.应用驱动的云原生发展: 未来的云原生平台将更加注重支持高度移动化、在线化、数据化、 SaaS化的新一代应用，推动企业从“IT资源云化”演进至“全栈云化”，强调自动化能力支撑的“全栈技术融合”和“敏捷交付”。2.单元化思想与一体化统筹: 云原生应用将更加注重标准化、单元化、可插拔和高度解耦的特性，同时也会关注服务拆分导致的开销，追求“自上而下”的一体化统筹优化。3.AI、大数据与云原生相互提升: 云原生的发展将越来越需要以大数据和 AI为基础的自动化、智能化工具平台，不断为开发、交付和资源管理活动提质增效。4.服务网格和服务治理: 服务治理与业务逻辑逐步解耦，服务网格以基础设施的方式提供无侵入的连接控制、安全、可监测性、灰度发布等治理能力。5.有状态应用的发展: 有状态应用逐步成为云原生市场中新的增长点，Operator的出现为有状态应用在云原生基础设施上运行提供了一套行之有效的标准规范。6.多云统一管理和调度: 客户开始关注跨区域和跨平台甚至跨服务商的大规模可复制能力，实现多云统一管理和业务流量统一调度。7.云原生北向 API的稳定性: 云原生北向 API区域稳定，支持跨区域和跨平台的大规模可复制能力2。这些趋势反映了云原生技术架构在未来发展中将更加注重应用的驱动、服务治理、应用的复杂性管理以及多云环境下的统一管理和调度能力。Q：云原生架构与传统云计算架构有何区别？A:云原生和传统云计算的差异主要在于它们各自在构建、部署和管理应用方面的方法和架构。云原生是指一套利用云计算的优势以实现更灵活、更可靠的软件开发和运维的技术与方法。相较于传统云计算，主要特征包括：1、微服务架构；2、容器化技术；3、动态管理；4、持续交付。传统云计算通常涉及虚拟机等技术以利用云资源，但在架构和操作层面保持较多传统数据中心的特性。云原生的方法重点在于微服务架构的采用，容器化以实现应用和服务的快速部署及扩缩容，动态管理确保资源的高效利用，持续交付支持快速迭代和市场响应。Q：CCE是否支持多租户资源共享？A:暂不支持。可以选择对应的命名空间，实现资源或租户的隔离。https://support.huaweicloud.com/usermanual-cce/cce_10_0285.htmlQ：如何评估企业应用云原生改造的必要性？A:企业云原生改造评估标准通常包括对企业现有架构的现代化程度、云原生技术栈的应用情况、以及改造后预期效果的综合评估。根据您提供的文档，具体的评估标准可以从以下几个方面进行:1.云原生架构设计能力:是否具备云原生的架构设计技术和服务能力，能够根据企业需求进行云原生架构的设计。2.落地实施技术服务支持能力:评估企业在云原生技术落地实施方面的能力，包括容器化改造、镜像仓库管理、 DevOps、运维监控等。3.微服务架构设计与实施能力:是否能够使用服务网格技术(如 Istio)、微服务框架(如 SpringCloud、 Dubbo)或华为云服务治理/微服务引擎相关服务进行微服务架构的设计与实施。4.业务流量监控与服务治理能力:是否能够设计并实施容器化业务流量监控、负载均衡策略、限流、熔断、服务调用安全、灰度发布、调用链追踪等服务治理相关内容。5.成本效益分析:改造后是否能提高资源利用率，降低计算成本和运维成本。6.安全性与合规性:改造过程中是否遵循安全最佳实践，确保符合相关合规性要求。7.服务等级协议(SLA)满足度:改造后的系统是否能够满足在线作业服务(如广告电商等)高 SLA要求和高峰时段的资源需求。8.弹性能力与容错性:是否能够提高系统的弹性能力，如自动弹性扩缩容，以及提高容错性，特别是对于大数据/转码等离线作业。企业在进行云原生改造评估时，应该结合自身业务特点和技术栈现状，参考上述标准，通过全面的技术评估和成本效益分析，制定出适合自己的云原生改造计划。同时，也需要考虑改造过程中的风险等级和策略，确保改造工作的顺利进行Q：华为云有什么产品可以替代apollo吗A:微服务引擎 CSE。一站式微服务平台，提供微服务应用必备的服务注册发现、配置管理、服务路由（应用网关）、服务治理能力。https://www.huaweicloud.com/product/cse.htmlQ：华为云云原生改造方案如何保证数据的安全和隐私性？A:华为云云原生改造方案保证安全性的措施主要包括以下几点:1.安全理念: 华为云强调“三分建设、七分运营”的安全理念，其中建设包括合规建设方案(等保、密评)、数据安全方案、大模型安全方案，而运营则重在全域安全运营加专业服务(MDR)。2.云原生安全优势: 华为云提出了“能力螺旋式上升的安全体系化能力”，这表明其安全能力不断进化和提升，与外挂式安全方案相比，华为云的安全方案有绝对优势。3.智能安全运营: 华为云原生安全运营实践分享中提到，通过智能安全分析/编排/响应(Intelligent Security Analysis/Orchestration/Response),结合全面的情报源、专家知识和 AI技术，使得威胁无处藏身。具体来说，威胁检测模型结合了安全日志、服务日志、云原生 AI和统一云安全架构，使得 SecMaster能够以超过95%的准确率快速同步华为云的已知威胁检测模型。4.快速响应: 使用安全编排技术(SOAR),SecMaster能够在单点风险发生时实现分钟级的全球响应2。5.安全信息智能分析: 通过 SecMaster进行智能分析、编排与响应，包括模型生成、事件响应团队(CSIRT)的事件警报、资产及信息的关联等，以及内部和外部情报的整合，实现快速的自动化处理。6.第三方情报: 结合第三方情报，增强安全分析的深度和广度2。通过上述措施，华为云云原生改造方案能够在设计之初就将安全性作为核心要素，通过不断的技术创新和实践经验积累，为用户提供一个更加安全、可靠的云原生环境。Q：云原生应用怎么无缝迁移到华为云上?A:华为云有自己的云原生迁移方案，迁移工具。可以给客户实施 https://support.huaweicloud.com/productdesc-professionalservices/migrationservices.htmlQ：云原生改造过程中，如何进行成本控制？A:在云原生改造过程中，控制成本是一个重要的环节。我们可以采取以下方法来实现成本控制:1.成本洞察:利用真实账单和集群资源用量统计数据，通过自研的成本画像算法进行成本拆分。提供部门、集群、命名空间、应用等维度的成本画像。帮助成本管理人员分析集群成本开销、资源使用状况，识别资源浪费。2.云原生成本治理:基于 FinOps理念的容器成本治理解决方案。提供部门维度、集群维度、命名空间维度的成本和资源画像。通过工作负载资源推荐等优化手段协助企业 IT成本管理人员实现容器集群的提效降本。3.云原生架构优化:应用容器化和微服务化的改造，以发挥云原生的优势，如自动弹性扩缩容等。容器技术可以提高资源利用率，避免闲置资源，从而降低计算成本。应用微服务化可以降低运维复杂度，从而降低运维成本。将在线离线业务混合部署，以提升整体利用率。通过上述方法，企业可以在云原生改造过程中有效控制成本，实现资源的高效利用，同时降低运维成本。cid:link_3Q：codearts的灰度切换的时候服务可用吗A:可用。灰度发布是在生产环境中创建与当前线上服务完全一致的工作负载（灰度负载），仅对其中的包版本（业务代码和配置）进行更新，但是新创建的工作负载不承接任何现网流量，对线上用户没有任何影响，就可以在没有风险的情况下，在生产环境进行测试了。在灰度环境验证无问题之后，就可以逐渐将线上用户的真实访问引流到灰度负载，直至完全引流后，新创建的灰度负载承接所有现网流量，原先的线上负载不承接任何流量，此时就可以安全地删除旧负载，保留新负载，完成一次发布。https://support.huaweicloud.com/bestpractice-pipeline/pipeline_practice_0002.htmlQ：请问华为云的云原生技术如何加速企业应用的开发和部署？A:华为云云原生技术通过提供一系列工具和服务来加速企业应用的开发和部署。以下是华为云云原生技术如何帮助企业加速这一过程的几个关键点:1.容器化与微服务架构:云原生技术基于容器化技术，支持微服务架构，使得应用可以被拆分为独立的服务，每个服务都可以独立开发、测试、部署和扩展。这种架构有助于提高应用的可维护性和可扩展性。2.DevOps工具链:华为云提供了完整的 DevOps工具链，包括代码管理、持续集成/持续部署(CI/CD)、测试和监控等，这些工具支持自动化流程，从而加快应用的开发和部署速度。3.云原生应用平台:华为云推出的云原生应用平台，如 ROMA,为企业提供全托管的、企业级的云原生应用开发和管理服务，支持微服务、容器、无服务器等多种云原生技术。Q：云原生改造后，如何评估其带来的性能提升和业务价值增长？A:云原生改造后的性能提升和业务价值增长的评估可以从以下几个方面进行:1.性能提升: 可以通过对改造前后的系统性能进行对比，包括但不限于响应时间、处理能力、资源利用率等指标。具体可以使用一些性能测试工具(如 JMeter、 LoadRunner等)进行压力测试和性能测试，通过测试结果来评估性能是否有所提升。2.业务价值增长: 可以从业务层面进行评估，例如，云原生改造后，是否降低了开发和运维的成本，是否提高了开发效率，是否加快了产品上线的速度，是否提高了系统的可用性和可扩展性，是否带来了新的业务机会等。具体可以通过业务指标(如销售额、用户数量、市场份额等)和业务调研来评估。3.技术风险: 云原生改造可能带来一些技术风险，例如，系统的复杂性可能会增加，新的技术可能需要相应的技术人才，改造过程可能会对现有系统产生影响等。这些风险需要在改造前进行评估，并在改造过程中进行管理。4.投资回报: 通过对比云原生改造的成本和改造后带来的业务价值，可以计算出投资回报率，以此评估云原生改造的经济效益。以上四个方面都需要综合考虑，才能全面评估云原生改造后的性能提升和业务价值增长。Q：面对多云策略，华为云如何帮助企业在不同云平台间实现云原生应用的灵活部署和管理？A:华为云通过提供一系列的云原生产品和服务，帮助企业在多云策略下部署和管理云原生应用。以下是华为云如何助力企业实现这一目标的几个关键方面:1.云原生技术创新: 华为云提出“云原生2.0”理念，将云原生技术与人工智能、大数据、物联网等前沿技术深度融合，提供业界领先的云原生解决方案。这包括云原生应用平台、微服务治理平台、 CCE Turbo等产品，帮助企业构建和部署云原生应用。2.多云资源管理: 华为云提供多云管理平台 CMP,支持跨多个云平台的资源管理、应用部署和监控，帮助企业实现多云环境下的统一管理和运维。3.业务连续性支持: 华为云的多云架构下天然具备支持各类业务连续性场景的能力，满足应用多活与多云容灾的要求。4.安全与合规性: 华为云通过策略管理、审计能力统一了各底层平台的安全合规性要求，并通过多云安全态势感知能力掌握整个分布式云平台和业务的安全情况。5.人才培养与认证: 华为云与高校合作开设云原生相关课程，为云原生产业输送专业人才，并推出云原生认证体系，帮助技术人才提升技能水平。6.参与云原生标准制定: 华为云积极参与云原生国际标准的制定，其云原生技术和解决方案得到了国际社会的认可，并被广泛应用于全球的云原生项目中。7.技术突破与案例分享: 华为云在云原生领域的技术突破，如云原生一站式安全解决方案、智能运维解决方案、微服务治理解决方案等，为企业提供了更加强大、可靠、智能的云原生解决方案，帮助企业加速数字化转型和业务创新。通过这些综合性的服务和解决方案，华为云能够帮助企业在多云策略下有效地部署和管理云原生应用，加速企业的数字化转型过程。Q：跨项目、跨团队、多地域的大规模场景，怎么做好需求追溯?A:需求管理 CodeArts Req https://support.huaweicloud.com/projectman/index.htmlQ：华为云提供了哪些工具或平台来支持持续集成/持续部署（CI/CD）实践？A:华为云支持 CI/CD的工具或平台包括:1.CodeArts:代码托管:CodeArts Repo提供千亿级代码行存储和十万并发下载，支持不同产品形态开发协同，以及百万人在线协同。代码检查:CodeArts Check基于主流业界标准和华为规范，守护软件质量与安全。编译构建:CodeArts Build支持亿级代码1小时构建，助于软件开发效率提升10倍。制品仓库:CodeArts Artifact实现公司级制品中心仓，支持百亿级软件包管理，支持日均20亿上传下载请求。发布管理:CodeArts Release提供调测与发布编排、自动化上线的发布管理服务。部署:CodeArts Deploy内置丰富部署模板，多套环境一站式分发部署。流水线:CodeArts Pipeline为企业级应用交付平台，助力企业 DevSecOps转型。2.DevSecOps解决方案:安全可信工具链: 组合 DevSecOps,打造自主可控安全服务，助力客户安全可信。3.专业服务:团队级教练辅导: 基于华为云 DevSecOps理念，提供敏捷辅导等落地实施服务，以提升企业软件交付能力，助力研发效能提升，使能企业数字化转型。Q：请问apollo数据是定期获取还是获取一次呢？另外我们本地已经搭建了jenkins的流水线要如何跟codearts对接A:apollo定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。https://github.com/apolloconfig/apollo/wiki/Apollo%E9%85%8D%E7%BD%AE%E4%B8%AD%E5%BF%83%E4%BB%8B%E7%BB%8D 服务扩展点是CodeArts的一种扩展插件，为CodeArts提供连接第三方服务的能力。 用户典型使用场景：在项目的流水线配置中，如果用户需要远程连接第三方服务，如：连接第三方GitHub、码云的Git仓库获取项目源码，连接第三方Jenkins服务执行Jenkins任务，连接Kubernetes集群进行部署，连接nexus repository用于添加用户的私有Maven仓库信息，Docker repository用于连接Docker镜像仓库，IAM账户扩展点用于委托自己账号的AK/SK给需要执行任务的账号等，均可以使用服务扩展点实现。 https://support.huaweicloud.com/usermanual-pipeline/pipeline_01_0011.htmlQ：请问华为云的云容器引擎 CCE 如何支持高可靠的企业级容器应用管理？它与其他容器服务有什么区别？A:华为云 CCE实现高可靠的企业级容器应用管理主要通过以下几个步骤: 1.集群选择: 选择具有3个控制节点的高可用模式，这样即使一个控制节点发生故障，集群仍然可以继续使用，不影响业务功能。 2.节点部署: 创建节点时选择在不同的可用区，这样即使一个可用区的节点发生故障，其他可用区的节点仍然可以提供服务。 3.节点池管理: 创建多个节点池，不同节点池部署在不同可用区，通过节点池扩展节点，以实现资源分配的最大化。 4.工作负载设置: 创建工作负载时，设置实例数需大于2个，以保证高可用。 5.亲和性规则: 设置工作负载亲和性规则，尽量让 Pod分布在不同可用区、不同节点上，以提高容器集群环境的高可用性。 6.一键部署: 提供一键式部署能力，可以快速帮助用户使用华为云容器服务能力，简化了部署过程，降低了出错率。 7.兼容 Kubernetes: 基于业界主流的 Kubernetes实现，完全兼容 Kubernetes/Docker社区原生版本，与社区最新版本保持紧密同步，完全兼容 Kubernetes API和 Kubectl,这为企业级应用管理提供了强大的支持。 通过这些步骤，华为云 CCE能够提供高可靠、高性能的企业级容器应用管理服务，支持 Kubernetes社区原生应用和工具，帮助企业快速实现业务系统的容器化改造。 华为云的云容器引擎(CCE)与其他容器服务的主要区别在于其提供的全栈容器能力和 Serverless容器服务。 CCE提供了高度可扩展和高性能的企业级 Kubernetes集群，支持运行 Docker容器，并提供了从集群管理到应用全生命周期管理的全栈容器能力，包括应用服务网格、 Helm应用模板、插件管理、应用调度、监控与运维等。用户可以轻松在华为云上部署、管理和扩展容器化应用程序。Q：请问在云原生架构中使用CCE和ECS各有什么优缺点？A:CCE(云容器引擎)优点:1.开箱即用的监控能力:CCE提供一键启用容器监控能力，简化了监控系统的搭建，降低了技术门槛。2.全景观测: 多维度全场景监控视图，提供近数十万项指标的全景可观测能力。3.开源增强: 兼容开源 Promtheus,提升了全方位的监控能力。4.智能可靠: 支持智能化版本升级、漏洞自动修复和智能调参，提供稳定、安全的集群使用体验。5.极致弹性性能: 支持容器秒级弹性，自动进行扩缩容，确保业务连续性和性能优化。6.全面兼容: 兼容 Kubernetes生态，灵活扩展功能。7.灵活规格与按秒计费: 提供灵活规格档位，按实际使用的资源量支付，减少成本支出。缺点:1.监控指标繁多: 云原生场景下的监控指标涵盖五大类，近数十万项，可能导致监控系统资源消耗高1。2.成本增加: 由于监控指标多，可能导致监控系统的成本显著增加。ECS(弹性计算服务)优点:1.灵活性: 提供高度可定制的虚拟机，用户可以根据需求自由配置硬件资源。2.广泛的操作系统支持: 支持多种操作系统，包括一些云原生架构不支持的系统。3.直接控制: 用户对虚拟机有完全的控制权，可以安装任何所需的软件。缺点:1.管理复杂性: 用户需要自己管理和维护底层资源设施，运维工作量大。2.成本不透明: 计费可能包括固定费用和按小时或按月计费的组合，使得成本预测更加复杂。3.弹性有限: 与 CCE的秒级弹性相比，ECS的弹性扩展通常需要手动操作或较长时间来响应资源需求变化。总结来说，CCE在云原生架构中提供了更加智能、便捷的监控和管理能力，适合需要快速部署和运维简化的场景。而 ECS提供了更高的灵活性和控制权，适合对底层资源管理有特殊需求或使用非云原生架构的场景。cid:link_1Q：CodeArts release联调环境支持二次开发吗？A:支持编排发布 https://support.huaweicloud.com/usermanual-pipeline/pipeline_01_0065.htmlQ：X Resource Service 层是什么样的原理？就是说集群节点资源都不用关心吗？工作节点的扩缩容和预热要运维吗？容器的网络模型是用的哪种？网络还是走的VPC融合容器吗？A:X Resource Service 层是什么样的原理？ 不清楚问题的意思 就是说集群节点资源都不用关心吗？ 需要检查 工作节点的扩缩容和预热要运维吗？ 不需要 容器的网络模型是用的哪种？ 1.云原生网络2.0 2.VPC网络 3.容器隧道网络 网络还是走的VPC融合容器吗？ 都有的Q：在云原生架构中，如何确保服务的高可用性和容错性？能否分享一些实际案例和应对策略？A:在云原生架构中，服务的高可用性和容错性是通过一系列的设计原则和技术手段来实现的。以下是一些常见的解决方案:1.容灾容错: 通过在不同的地理位置部署应用的副本，确保当一个地区发生故障时，其他地区的副本可以接管工作，保证服务的连续性。2.过载控制: 使用负载均衡器和自动扩展机制来避免单点过载，当流量增加时，可以自动扩展资源以应对负载，保证服务不因资源不足而降级。3.灰度发布: 逐步推出新版本的服务，可以先在小范围内部署，逐步扩大范围，如果在某个阶段发现问题，可以快速回滚，减少影响。4.监控和日志: 实时监控服务状态和性能指标，一旦发现异常，可以立即采取措施，如自动重启服务、通知运维人员等。5.故障演练: 定期进行故障演练，模拟各种可能的故障情况，检验服务的容错能力，同时作为改进服务可靠性的机会。6.数据备份和恢复: 定期备份数据，并确保可以快速恢复，以防数据丢失导致服务不可用。7.服务治理: 通过服务网格(如 Istio)等技术，实现服务之间的流量管理、故障注入、流量调度等功能，提高服务的弹性。8.持续规划和反馈: 持续地对服务的可靠性进行规划和改进，根据监控数据、故障报告等反馈信息，不断优化服务架构。以上解决方案可以单独使用，也可以结合使用，以提高服务的高可用性和容错性。在实际应用中，需要根据具体的业务需求和技术环境，选择合适的解决方案。Q：如果我们使用的是gitlab的仓库，如何实现配合code arts进行全自动发布呢A:要实现 GitLab仓库与 CodeArts的全自动发布，你需要使用一些 CI/CD工具，如 GitLab CI/CD或 Jenkins等。 以下是一种实现方法:1.在 GitLab中设置 CI/CD: 首先，你需要在你的 GitLab仓库中设置 CI/CD。这可以通过创建一个.gitlab-ci.yml文件来完成。在这个文件中，你可以定义你的构建、测试和部署流程。2.安装必要的依赖: 在.gitlab-ci.yml文件中，你需要安装你的项目所需的所有依赖。你可以使用apt，yum或brew等工具来安装这些依赖。3.编写脚本来部署到 CodeArts: 你需要编写一个脚本来部署你的项目到 CodeArts。这个脚本应该会将你的项目部署到 CodeArts的相应环境。cid:link_2Q：可以用IDE改项目，然后用CCE的CI/CD编译后，打成新的docker再用流水线自动放入CCE平台，等待审核后，自动替换旧的docker？A:是的。通过流水线参数串联编译构建服务和部署服务 https://support.huaweicloud.com/bestpractice-pipeline/pipeline_practice_0013.htmlQ：请问当数据量呈指数级增长时，DTSE 如何在华为云上进行弹性扩展以避免性能瓶颈？A:华为云的弹性扩展可以通过水平扩展和垂直扩展两种方式来解决性能瓶颈问题。1.水平扩展: 就是增加更多的资源来处理更多的请求。例如，如果您的应用程序需要处理大量并发请求，您可以添加更多的 ECS实例(Elastic Compute Service,弹性计算服务)或者云服务器来分担负载。弹性伸缩服务(Auto Scaling,自动伸缩)可以根据业务需求自动进行水平扩展。2.垂直扩展: 就是提升现有资源的性能。例如，您可以通过升级 ECS实例的配置(如 CPU、内存)来提升单个实例的处理能力。另外，华为云还提供了数据库服务(如 RDS,Relational Database Service,关系型数据库服务)等服务，这些服务内建了数据分片、读写分离、自动扩展等功能，可以更好地帮助用户解决大规模数据和高并发的挑战。总的来说，华为云的弹性扩展服务可以根据业务需求，动态地调整资源配置，从而有效地解决性能瓶颈问题。Q：codearts可以和本地jenkins打通吗？A:可以的。 新建CodeArts服务扩展点 服务扩展点是CodeArts的一种扩展插件，为CodeArts提供连接第三方服务的能力。 用户典型使用场景：在项目的流水线配置中，如果用户需要远程连接第三方服务，如：连接第三方GitHub、码云的Git仓库获取项目源码，连接第三方Jenkins服务执行Jenkins任务，连接Kubernetes集群进行部署，连接nexus repository用于添加用户的私有Maven仓库信息，Docker repository用于连接Docker镜像仓库，IAM账户扩展点用于委托自己账号的AK/SK给需要执行任务的账号等，均可以使用服务扩展点实现。 https://support.huaweicloud.com/usermanual-pipeline/pipeline_01_0011.htmlQ：有没有文档呀，在线的文档或者不是在线的都可以A:https://support.huaweicloud.com/index.html 华为云的支持文档，如果是CodeArts相关的，看开发与运维模块Q：如何在华为云上配置和管理云爆发？A:Cloud Bursting解决方案，Serverless容器降本增效极致体验 https://developer.huawei.com/consumer/cn/forum/topic/0207132258291104197Q：CodeArts req和CodeArts Release有哪些区别？A:CodeArts Req是华为云提供的一款需求管理与团队协作服务。它旨在为研发团队提供一个简单高效的平台，以支持需求管理、项目管理、敏捷 Scrum、缺陷跟踪、文档托管、统计分析和工时管理等功能。 https://support.huaweicloud.com/projectman/index.html CodeArts Release是华为云提供的一种发布管理服务，它是与 CodeArts流水线(CodeArts Pipeline)相结合的 E2E解决方案，专门用于支持产品版本的持续交付。通过 CodeArts Release,发布团队可以在保持现有生产环境完整性的同时，高效地交付业务所需的应用程序和升级。 https://support.huaweicloud.com/usermanual-pipeline/pipeline_01_0065.htmlQ：请问code arts可以进行自动触发吗A:可以的。https://support.huaweicloud.com/usermanual-pipeline/pipeline_01_0017.htmlQ：请问有没有实际操作的的视频，从刚把华为云到应用到华为云上A:华为云提供一些基础的迁移工具比如SMS，DRS等等，如果需要大型应用的迁移建议求助代表处华为云迁移团队Q：怎么减少容器测试阶段的重复性构建又能兼顾质量?A:在容器测试阶段，重复性构建可能会消耗大量的计算资源，同时也可能增加测试的时间和成本。但是，为了保证软件质量，我们又必须进行充分的测试。下面有一些策略可以在尽量减少重复性构建的同时保证质量:1.使用 CI/CD工具: 持续集成/持续部署(CI/CD)工具(如 Jenkins, GitLab CI/CD, CircleCI等)可以自动化构建和测试的过程，这样就可以避免手动进行重复的构建操作。这些工具通常都支持并行测试，这样可以大大减少测试的总时间。2.并行测试: 并行测试可以大大提高测试的效率。现代 CI/CD工具通常都支持并行测试，这样可以同时运行多个测试用例，大大减少测试的总时间。3.代码覆盖率工具: 使用代码覆盖率工具(如 JaCoCo, Cobertura等)可以帮助你确定哪些代码已经被测试，哪些代码还没有被测试。这样可以帮助你更有效地分配测试资源。4.使用 Docker层缓存: 如果你的 Docker镜像包含了一些经常变动的文件，那么在构建过程中可能会进行多次不必要的完整构建。你可以使用 Docker的层缓存(layer caching)功能来避免这种情况。当你构建一个 Docker镜像时，Docker会检查是否有可重用的层，如果有，就不会再重新构建这些层。5.避免长时间运行的测试: 长时间运行的测试可能会占用大量的计算资源，而且可能会使得测试结果不稳定。你应该尽量避免使用长时间运行的测试，或者将它们与其他测试并行运行。6.优化测试策略: 不同的测试策略可能会有不同的效率和质量。你应该根据你的具体需求和资源情况来选择合适的测试策略。例如，单元测试通常比集成测试更快，但是集成测试通常能发现更多的问题。以上这些策略可以帮助你在尽量减少重复性构建的同时保证软件质量。Q：华为云 GaussDB(DWS) 的高可用性是如何实现的？A:华为云 GaussDB(DWS)的高可用性主要通过以下机制实现:1.硬件级高可靠:磁盘 Raid: 确保数据的冗余备份。交换机堆叠及网卡 bond: 提高网络的可靠性和可用性。不间断电源(UPS): 防止电力故障影响数据中心的运作。2.软件级高可靠:集群事务管理: 保证集群所有节点间事务的 ACID特性，以及故障可恢复性。全方位 HA(高可用性)设计: 包括集群 CN(控制节点)、 GTM(全局事务管理器)、 DN(数据节点)等，确保在部分节点故障时，集群仍然能够正常运作。分布式事务管理: 支持全局事务信息管理和分布式事务状态管理，保证分布式事务的 ACID特性。分布式死锁预防: 保证在出现死锁时能够自动解锁或者预防死锁。3.基于 K-Safety的高可用性:K-Safety是 Vertica数据库的一项技术，保证了在集群内，每一个数据库中每一张表的每一列被存储在至少 K+1台机器上，这样保证了任意 K个节点发生故障时，集群中仍然存在至少一份完整的数据来响应数据处理和查询请求。GaussDB(DWS)采用类似的主、备、从备的技术，分布在安全环单元内部的节点上，每个安全环内节点数=单物理服务器上的 DN数+1,最小为3,类似于 K-Safety的效果。通过上述多层次、多维度的高可用性设计，华为云 GaussDB(DWS)能够在集群出现故障时尽可能地不中断服务，降低硬件、软件和人为造成的故障对业务的影响，以保证业务的持续性。cid:link_4Q：请问获取apollo数据是定期获取还是获取一次呢A:apollo定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。https://github.com/apolloconfig/apollo/wiki/Apollo%E9%85%8D%E7%BD%AE%E4%B8%AD%E5%BF%83%E4%BB%8B%E7%BB%8DQ：CCE支持哪些类型的持久化存储？A:云硬盘EVS. 对象存储OBS. 弹性文件存储SFS. https://doc.hcs.huawei.com/zh-cn/usermanual/cce/cce_10_0307.htmlQ：怎么保证CCE的高可用性?A:CCE的高可用性可以通过以下几种方式来保证:1.高可用部署方案:增加实例数量: 采用多实例部署方式可以有效避免单点故障造成的服务不可用。独占节点部署: 将核心插件如 CoreDNS独占 Node节点部署，进行节点级别的资源限制和隔离，避免业务应用与核心插件资源抢占。多可用区部署: 采用多可用区部署可以有效避免单可用区故障造成的整个服务的不可用。2.数据保护技术:服务发现支持证书配置: 集群中的应用服务支持使用 HTTPS传输协议，保证数据传输的安全性。高可用部署: 集群支持3个控制节点的高可用模式，Node节点支持分布在不同 AZ,以实现高可用性。磁盘加密: 支持多种存储类型，满足高可用以及部分存储加密场景，为数据提供安全防护。3.节点管理:创建不同可用区的节点: 创建多个节点池，不同节点池部署在不同可用区，通过节点池扩展节点。工作负载亲和性规则: 创建工作负载时设置实例数需大于2个，并设置工作负载亲和性规则，尽量让 Pod分布在不同可用区、不同节点上。通过上述措施，CCE能够提供高可用的部署和运行环境，确保服务的稳定和可靠性。cid:link_0Q：DTSE 如何帮助开发者快速解决遇到的技术问题？A:DTSE(Developer Technology Service Engineer)作为华为云的一种服务，主要致力于帮助开发者解决技术问题，提升开发效率和产品质量。以下是 DTSE如何帮助开发者的几个方面:1.技术问题支持:DTSE提供专业的技术支持，帮助开发者分析、定位并解决技术问题，确保问题能够快速得到解决，保证开发进程的顺利进行3。2.项目成果优化: 通过与客户技术侧负责人对齐，DTSE能够聚焦于开发者的技术架构优化，降低 BUG数量和系统故障时长，提升开发者对 DTSE的信任1。3.效率提升:DTSE协助开发者建立标准的开发流程，提高开发效率，并通过监控和优化代码质量，减少后期维护工作12。4.技术赋能:DTSE支持开发者熟悉华为云技术栈，提供持续的技术跟踪和赋能，帮助开发者提升技术能力和使用体验2。5.产品改进与优化: 根据客户反馈和实际使用情况，DTSE协助推动产品特性需求的实现，优化产品功能，提升开发者的工作效率和产品质量12。6.经验沉淀与分享:DTSE通过沉淀项目经验，提炼关键价值点，与开发者进行交流，建立信任，并促进知识共享12。通过上述方式，DTSE不仅解决了开发者在实际工作中遇到的技术问题，还提升了开发效率和产品质量，增强了开发者对华为云产品的信任和依赖。Q：云原生改造的故障演练有哪些实现方法？A:多活高可用服务 MAS。多活高可用服务（Multi-Site High Availability Service，简称MAS）源自华为消费者多活应用高可用方案，提供从流量入口、数据到应用层的端到端的业务故障切换及容灾演练能力，保障故障场景下的业务快速恢复，提升业务连续性。 https://support.huaweicloud.com/usermanual-mas/mas_03_0102.htmlQ：使用虚拟机架构还是容器架构应该怎么考量？A:虚拟机架构和容器架构是两种常见的云计算和应用部署方式，各自有其优缺点。选择哪一种架构，通常取决于以下一些考量因素:1.资源隔离与共享: 虚拟机提供了完全的硬件隔离，而容器则共享主机的操作系统和资源。虚拟机的隔离性更好，但也会带来更高的资源消耗。容器则能更高效地利用硬件资源，但隔离性较差。2.启动时间: 虚拟机需要加载整个操作系统，所以启动时间较长。而容器只需要加载应用及其依赖，启动时间通常更短。3.操作系统与硬件的兼容性: 虚拟机可以运行任何操作系统，具有很高的灵活性。而容器只能运行与主机操作系统兼容的应用，这也决定了其应用的限制。4.安全性: 虚拟机在安全性上有一定优势，因为每个虚拟机都运行在自己的操作系统中，而容器共享主机的操作系统，可能存在安全隐患。5.应用隔离: 虚拟机可以在同一台物理机上运行多个隔离的操作系统，从而运行多个应用。而容器在同一台物理机上运行多个容器，但这些容器共享主机的操作系统，因此应用之间可能存在干扰。6.管理与维护: 虚拟机的管理和维护通常更复杂，需要管理多个操作系统。而容器的管理和维护相对简单，只需要管理应用程序及其依赖。7.网络配置: 虚拟机可以配置虚拟网络，而容器则需要在主机的网络中进行配置，这也是容器的一个限制。8.成本: 虚拟机通常需要更多的硬件资源和管理资源，因此成本较高。而容器则能更高效地利用硬件资源，成本较低。总的来说，虚拟机和容器各有优缺点，选择哪种架构需要根据具体的应用需求和资源状况来决定。Q：如何优化云原生基础设施，提升业务的弹性能力？A:云原生基础设施优化方法主要包括以下几个方面:1.云原生持续融合 IaaS基础设施，构建下一代 Serverless底座:面向应用的无感算力: 虚机算力向 Serverless容器算力持续演进，实现算力无感、弹性无感、运维无感。面向应用的网络: 从面向网络的 VPC走向面向应用的 ANC,实现网络、容器、应用的扁平化。面向应用的存储: 实现传统存储多应用接口应用模式向与云原生文件/应用语义模型的转化，支撑数据无感流动。2.云原生算力无处不在，构建分布式云原生基础设施:面向应用全域分发: 通过云原生将华为云多种数据中心、边缘、客户站点全域链接，实现 regionless,多算力、流量、数据统一治理。基于声明式 API: 根据计算资源、成本优化、 SLA、时延等维度实现工作负载全局最优位置部署1。3.构建面向 Workloads优化的基础设施:围绕垂直应用场景，面向 AI、 HPC、 Web、 DB等全场景提供负载优化的云原生基础设施。4.基于 FinOps理念，构建低碳、绿色的基础设施:实现应用级别、节点级别的弹性伸缩，采用智能弹性、智能调度等技术构建绿色、高效的云原生基础设施。5.云原生 AI基础设施:围绕 Clould for AI战略，重构为 AI原生的云基础设施底座平台。6.分布式擎天架构创新:实现基于高速总线下的对等池化架构，突破算力、网络、存储的壁垒。此外，还有如低成本、高性能、灵活弹性的适配场景，通过全硬件卸载节省成本、提升性能，以及秒级弹性等技术，来优化云原生基础设施3。在安全性方面，通过networkpolicy+安全组、安全容器、RBAC等措施来应对挑战。以上方法结合起来能够帮助企业在大规模应用场景下实现高效的资源管理和成本优化。Q：华为云云原生技术有哪些优势？A: 1.出身：源自开源，高于开源。 不同于微软，AWS，阿里云，华为云从2015年就选择K8S容器技术，是CNCF创始成员。在社区上代码贡献累计亚洲第一。并贡献KubeEdge，Karmada，Volcano 等多个开源项目。 2.能力：软硬结合，极致性能，极低时延 云计算的原罪就是复杂。在一个云计算数据中心，有着数十万台服务器，每台服务器上又是几十个虚机，虚机之上又是几十个容器，而数以亿计的应用，有的是需要最高性能，有的是最大的存储，有的是最大的带宽等，这一切反映的是在这种复杂网络的调度能力，华为与所有其他云厂商不同的是，我们有着交换机，路由器，存储，服务器的硬件整机产品创新能力，又拥有华为云独有的擎天架构。通过软硬结合，我们能将虚机网络和容器网络两层变一层，网络时延降低40%，实现性能绝对领先于其他厂商。 3.业务案例。新浪微博三阶段的故事 新浪微博曾经容易瘫。用了华为云的容器服务，就不再瘫了，华为云容器服务支持30秒8000核的扩容。想要了解更多云原生相关知识，欢迎观看DTSE Tech Talk 系列技术直播

我们非常高兴地宣布 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 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

          很荣幸能够参加这次的E级云架构学习的机会，在这个培训过程中，我感受到了前所未有的学习热情和专业的教学氛围。老师的授课方式生动有趣，不仅深入浅出地讲解了知识点，还注重培养我们的实践能力和项目思维。课程内容丰富多样，涵盖了多个领域的前沿知识，让我受益匪浅。 从自己零零散散的了解顶层架构设计的边角料，再到老师的专业知识学习与设计思路，再到自己懵懵懂懂的APIG、FunctionGraph、大数据的数据治理等知识领域的深入补充与教学，学习到了之前不懂的知识。总的来说，这个培训班不仅提升了我的专业技能和知识水平，还让我结识了一群志同道合的朋友。我相信，这段宝贵的学习经历将对我的未来产生积极的影响。我衷心感谢培训班的所有老师和同学，也期待未来能有更多这样的学习机会。 

这次培训E级培训的感觉：1.讲师能力：非常专业，不论是从整体感觉还是细节讲解，都受益匪浅，无可挑剔。2.课件内容：从顶层架构到底层技术细节，都图文并茂，易于理解，并且配有专门的案例，学员们理论中不理解的问题，通过案例讲解后茅塞顿开。3.推进方式：时间观念非常强，进度准确到分钟级别；讨论环节，学员们扩散的问题，讲师都能精准找到问题的根因并且解答。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

8月23日，“连接未来，智慧无限”HCDG城市行深圳站——人工智能&鸿蒙生态创新论坛活动在深圳市南山区华侨城创意文化园成功举办。活动以"人工智能&鸿蒙生态创新"为主题，吸引了众多行业专家和业务领袖齐聚一堂，共同探讨云原生、Devops、鸿蒙技术生态构建、AI原生应用引擎等前沿话题。论坛伊始，华为深圳云生态云原生DTSE技术专家朱红磊先生带来的主题为“云原生和Devops助力企业数字化转型”的精彩分享，深入浅出地阐述了云原生技术如何通过提供可扩展的、灵活的、高效的解决方案来支持企业快速实现数字化转型。朱专家强调，Devops作为一种自动化和持续交付的方法，与云原生技术相结合，能够帮助企业更快地响应市场变化，提高业务的灵活性和竞争力。随后，华为深圳云生态鸿蒙DTSE技术专家刘文明先生就“鸿蒙技术的生态构建与发展趋势”进行了深度解读。刘先生指出，鸿蒙操作系统作为一个全场景智能生态系统，正通过其独特的微内核设计和分布式架构，不断强化与各行各业的融合，推动智能生态的广泛构建。他预测，随着鸿蒙生态的不断壮大，未来将有更多设备和服务采用鸿蒙系统，实现跨平台的无缝协同。论坛第三个环节由华为云AI原生应用引擎产品总监李明先生主讲，主题为“华为云AI原生应用引擎0代码智能构建专属个性化应用”。李先生介绍了华为云AI原生应用引擎如何利用0代码平台，帮助开发者和企业快速构建和部署AI应用，从而降低技术门槛，加速AI应用的普及和应用。他强调，这一平台为企业提供了个性化、定制化的AI解决方案，使得非专业人士也能轻松享受到人工智能技术带来的便利。最后，活动进入互动交流与实验体验环节。与会嘉宾和参与者通过深入交流，不仅加深了对云原生、Devops、鸿蒙技术和AI原生应用引擎的理解，还就如何将这些技术应用于实际业务中进行了充分探讨。现场的实验体验环节更是让参与者亲身体验了华为技术的强大性能和灵活性。华为云将继续携手各城市HCDG核心组成员，与广大企业及开发者，共建产业新生态，为企业及开发者提供“新技术、新体验、新机会”全方位支撑，赋能更多的企业数字化转型。HCDG（Huawei Cloud Developer Group 华为云开发者社区组织），是基于城市圈和技术圈，由开发者核心组自发开展的开放、创新、多元的社区技术交流组织，致力于帮助开发者学习提升、互动交流、挖掘合作，推动技术应用与本地产业结合、数智化转型和开发者文化发展。

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 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

扫码进入容器活动专场

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