如何选择正确的存储类型？

华为云如何实现容灾备份？

虚拟网络与子网的作用是什么？

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

基础设施即服务 (IaaS)： 如何设置自动扩展（Auto Scaling）？

如何配置负载均衡器？

什么是块存储与对象存储？

怎样管理虚拟机实例？

如何选择适合的 IaaS 提供商？

 aws 已创建 alb ingress 域名 无法访问，如何查看 ingress controller 情况 

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/

mv node-v12.16.1-linux-x64 /usr/local/Node.js

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