2024年12月18日，由中国科学技术协会科学技术传播中心、中国计算机学会、中国通信学会、中国科学院软件研究所联合主办，CSDN 承办的开源创新榜评选活动圆满落幕。KubeEdge 作为业界首个云原生边缘计算项目以及 CNCF 唯一正式毕业的边缘计算开源项目，以其卓越的创新性、贡献度和影响力，从200多个竞争项目中脱颖而出，荣获2024开源创新榜优秀开源项目之首。2024开源创新榜评选活动由王怀民院士担任评委会主任，带领全国各学会、大学、科研院所、企业、开源基金会、行业联盟等近20位开源专家，面向中国开源行业领域，遴选具有创新性、贡献度和影响力的开源项目、社区、应用场景与开源事件，进一步激励更多企业和开发者参与开源生态建设，推动开源技术繁荣和发展。  KubeEdge 于2018年11月正式开源，2019年作为首个云原生边缘项目被接受为 CNCF Sandbox 项目，在2020年9月晋升为孵化项目，并于2024年10月从 CNCF 正式毕业，是第三个由中国企业开源的毕业项目。KubeEdge 项目致力于将 Kubernetes 的容器化应用编排能力无缝扩展至边缘主机，为边缘计算提供强大的基础设施支持。它基于 Kubernetes 构建，不仅覆盖了云端与边缘端之间的网络连接、应用部署和元数据同步，还通过高效的架构设计，显著提升了边缘计算场景中的可靠性与性能。目前，KubeEdge 将云原生生态扩展到了数据中心之外的更多场景和行业，广泛应用于 CDN、智能交通、智慧能源、智慧零售、智慧园区、智能汽车、航空航天、智能物流、金融、化工、电力、区块链等各领域，完成了业界最大规模云原生边云协同高速公路收费站管理项目、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生智慧零售管理、业界首个云原生金融管理等行业代表项目。基于云原生边缘计算领域的独特优势，KubeEdge 得到了伙伴和用户的高度认可。此次荣获“优秀开源项目”奖项，既是对 KubeEdge 技术实力的高度认可，也彰显了社区在合作精神、开放性和追求卓越方面的努力与成就。这一荣誉离不开每一位社区成员的辛勤付出和无私奉献。未来，KubeEdge 社区将保持开放治理模式和协作理念，进一步改善用户体验，提供更可靠和稳定的服务。我们也诚邀更多的开发者和用户加入 KubeEdge 社区，共同探索边缘计算的未来，共创辉煌。   【更多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/

12月27日，“The Future of KubeEdge” KubeEdge 毕业主题研讨会在上海成功举办。来自上海开源信息技术协会、华为云、DaoCloud、Intel、南京腾优科技、FatCoupon Technology、中碳普惠云、复旦大学、上海对外经贸大学、上海工程技术大学等多家机构、企业、高校代表及贡献者出席，就 KubeEdge 毕业后的社区规划展开深入研讨，持续聚力技术与运营协同创新，助力云原生边缘计算产业升级发展。  回顾 KubeEdge 的发展历程，从 2018 年 11 月正式开源，2019 年作为首个云原生边缘项目被接受为 CNCF Sandbox 项目， 2020 年 9 月晋升为孵化项目，并于2024年成功毕业，成为CNCF首个毕业级云原生边缘计算项目，一路走来，社区持续开源创新，将云原生生态扩展到了数据中心之外的更多场景和行业，为业内带来了多个行业首发应用，广泛覆盖 CDN、智能交通、智慧能源、智慧零售、智慧园区、汽车、航空航天、智能物流、金融、化工、电力、区块链等领域。 ▲ KubeEdge 项目里程碑 会上，KubeEdge 联合创始人，华为云云原生开源负责人王泽锋介绍了全球云原生开源生态与运作模式，并分享了 KubeEdge 发展历程中的核心技术与典型案例。CNCF 毕业项目是国际开源生态的领军者，KubeEdge 从 CNCF 毕业已迈入了成熟新阶段。基于在云原生边缘计算领域的独特优势，KubeEdge 期待在未来为整个云原生生态系统缔造更广阔的可能性。 ▲ KubeEdge联合创始人，华为云云原生开源负责人王泽锋 KubeEdge TSC，DaoCloud 首席运营官张红兵在会上分享了 KubeEdge 长期以来的社区治理及运营策略。通过系统化建立社区治理架构，严格执行高效的开发者协同机制，开展深度的工程化验证，社区有序促进技术持续创新与升级。与此同时，社区也通过开发者实训、公开课、峰会、研讨会等系列形式，为社区开发者们构建多元化的学习、参与和成长路径，打造社区活跃生态。 ▲ KubeEdge TSC，DaoCloud 首席运营官张红兵 毕业是社区的里程碑，同时也对技术创新和运营发展提出了更高的要求。在小组讨论环节，各位代表集思广益，从企业、高校、开发者各个视角，就社区未来发展深入探讨，涵盖 Scalability、Node、Device-IoT、AI、Netwoking、Security、UI、Cluster-Lifecycle、Testing、EdgeSite、Release、Docs、Robotics 等多个 SIG 的技术创新方向，持续升级社区运营治理，促进 KubeEdge 与产业发展生态融合。 未来，KubeEdge 社区将保持开放治理模式和协作理念，进一步升级用户体验，提供更可靠和稳定的服务。社区成功毕业离不开每一位社区伙伴、用户与开发者的协作与贡献，期待与您携手共建，加速社区生态协同发展，共同引领云原生边缘计算迈向产业应用新高度。

作者：王彬丞&杨志佳&刘家伟针对新版本 Device-IoT 领域的更新，我们计划推出一系列的文章对这些特性进行详细的介绍，大致的文章大纲为：基于物模型的设备管理 API 设计与实现DMI 数据面能力设计与实现Mapper 开发框架 Mapper-Framework 设计与实现如何使用 Mapper 完成视频流数据处理如何使用 Mapper 实现设备数据写入如何从头开发一个 Mapper（以 modbus 为例） 在上一篇文章中，我们为适应用户对边缘设备管理的需求，设计实现了基于物模型的设备管理 API。在此基础上，我们完善了 DMI 数据面的能力，提供边缘端处理设备数据的多种方式，让 KubeEdge 能够更灵活、标准化的管理边缘设备。本篇文章是系列文章的第二篇，将详细介绍v1.15.0版本在 DMI 数据面的一些工作。DMI 数据面能力支持 在1.12版本中，KubeEdge 设计了设备管理框架——DMI。DMI 框架提供了统一的设备管理相关接口，设备应用开发者和使用者可以通过实现 DMI 中的标准化接口完成设备管理，让边缘设备以微服务的形式提供服务，更加贴合云原生。➤ DMI 的架构图如下图所示：DMI 框架中一个重要的特性是设备管理面与设备数据面解耦。设备管理面基于 Device CRD 承载设备本身的生命周期管理，如图中黄色线条；设备数据面则让设备数据通过微服务的方式向数据消费者应用提供，拥有多种数据推送方式，如图中蓝色线条。DMI 设备管理面数据主要包括设备的元数据、设备属性、配置、生命周期等，其特点是相对比较稳定，创建后信息更新较少，这类数据会通过云边通道进行传递。设备数据面数据则主要为设备传感器采集到的设备数据，相比于管理面数据来说数据量较大，若通过云边通道传输可能会造成通道阻塞，影响集群正常功能。v1.15.0版本中 DMI 数据面功能得到完善，通过数据面能以多样化的方式推送设备数据，相比通过云边通道传输数据更加合理。  DMI 数据面能力支持 ➤ DMI 数据面系统架构如下图所示：在v1.15.0版本更新后，DMI 数据面支持如图中四种方式处理推送设备数据：1、推送至用户应用。按照 v1beta1 版本的 Device Instance API 定义，用户能够在 Device Instance 配置文件中配置 pushMethod 字段，以 HTTP 或者 MQTT 的方式定时将设备数据推送到用户应用中。2、推送至用户数据库。最新版本的 KubeEdge DMI 内置 InfluxDB、Redis、TDengine、MySQL 数据库的数据推送方式，用户能够在 Device Instance 配置文件中 dbMethod 字段设置相应数据库的参数，将设备数据定时传入数据库。3、推送至云端。用户能够设置 Device Instance 配置文件中 reportToCloud 字段决定是否将设备数据推送至云端。4、用户能够通过 Mapper 提供的 RESTful API 主动拉取设备数据。以下是一个使用 DMI 数据面能力处理设备数据的 Device Instance 配置文件示例：apiVersion: devices.kubeedge.io/v1beta1 kind:Device ... spec: properties: -name:temp collectCycle:10000 # The frequency of reporting data to the cloud. once every 10 seconds reportCycle:10000 # The frequency of data push to user applications or databases. reportToCloud:true # Device data will be reported to cloud desired: value:"100" 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 dbMethod: influxdb2: # define the influx database config to push device data to user database influxdb2ClientConfig: url:http://127.0.0.1:8086 org:test-org bucket:test-bucket influxdb2DataConfig: measurement:stat tag: unit:temperature fieldKey: devicetest在示例文件中，用户可以通过 reportToCloud 字段定义 Mapper 是否将设备数据推送至云端；此外，pushmethod.mqtt 字段定义了 Mapper 向用户应用推送的配置信息，示例中表示 Mapper 会定时以 MQTT 协议的方式向 127.0.0.1:1883 地址的用户应用推送设备数据；pushmethod.dbMethod 字段定义了 Mapper 向用户数据库推送的配置信息，示例中表示 Mapper 会定时向 127.0.0.1:8086 地址的 InfluxDB 数据库推送设备数据。基于 DMI 数据面的能力，用户只需在 Device Instance 配置文件中定义相关字段，即可使用多种方式处理采集到的设备数据，有效降低了云边通道阻塞的风险。DMI 提供的功能接口最终是由设备管理插件 Mapper 来承载的。Mapper 北向需要实现 DMI 管理接口向 KubeEdge 完成自身的注册以及设备管理。对于用户来说，独立对接 DMI 接口实现自定义的 Mapper 使用门槛依然较高，因此我们在v1.15.0版本中推出 Mapper 开发框架 Mapper Framework，能够使用简单的命令自动生成一个 Mapper 工程供用户使用，有效降低用户上手的难度。在本系列的下一篇文章中，我们会对 Mapper Framework 的架构与使用方法进行详细介绍。【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_2Slack地址 : 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/

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。Karmada v1.12版本[1]现已发布，本版本包含下列新增特性：应用级故障迁移功能增强（新增状态中继机制，适用于大数据处理程序高可用场景，如 Flink）单集群应用迁移能力增强（适用于单集群存量应用迁移）Karmada Operator 高可用部署能力支持OverridePolicy 支持局部修改结构化字段值新特性概览▶  应用级故障迁移功能增强在之前的版本中，Karmada 提供了基本的应用级故障迁移能力，能够通过应用的健康状态或自定义的故障等条件触发应用迁移。为了满足有状态应用在故障迁移过程中保留其运行状态的需求，Karmada 在 v1.12 版本新增了应用状态中继机制。对于大数据处理应用（例如 Flink），利用此能力可以从故障前的 checkpoint 重新启动，无缝恢复到重启前的数据处理状态，从而避免数据重复处理。社区在PropagationPolicy/ClusterPropagationPolicy API 中的.spec.failover.application 下引入了一个新的StatePreservation 字段， 用于定义有状态应用在故障迁移期间保留和恢复状态数据的策略。结合此策略，当应用从一个故障集群迁移到另一个集群时，能够从原始资源配置中提取关键数据。状态保留策略StatePreservation 包含了一系列StatePreservationRule 配置，通过 JSONPath 来指定需要保留的状态数据片段，并利用关联的 AliasLabelName 将数据传递到迁移后的集群。以 Flink 应用为例，在 Flink 应用中，jobID 是一个唯一的标识符，用于区分和管理不同的 Flink 作业（jobs）。每个 Flink 作业在提交到 Flink 集群时都会被分配一个jobID。当作业发生故障时，Flink 应用可以利用jobID 来恢复故障前作业的状态，从故障点处继续执行。具体的配置和步骤如下：apiVersion: policy.karmada.io/v1alpha1 kind:PropagationPolicy metadata: name:foo spec: #... failover: application: decisionConditions: tolerationSeconds:60 purgeMode:Immediately statePreservation: rules: -aliasLabelName:application.karmada.io/failover-jobid jsonPath:"{ .jobStatus.jobID }"迁移前，Karmada 控制器将按照用户配置的路径提取 job ID。迁移时，Karmada 控制器将提取的 job ID 以 label 的形式注入到 Flink 应用配置中，比如application.karmada.io/failover-jobid : <jobID>。运行在成员集群的 Kyverno 拦截 Flink 应用创建请求，并根据jobID  获取该 job 的 checkpoint 数据存储路径，比如  /<shared-path>/<job-namespace>/<jobId>/checkpoints/xxx，然后配置initialSavepointPath 指示从save point 启动。Flink 应用根据initialSavepointPath 下的 checkpoint 数据启动，从而继承迁移前保存的最终状态。该能力基于 FlinkDeployment 打造，但广泛适用于能够基于某个 save point 启动的有状态应用程序，这些应用均可参考上述流程实现故障迁移的状态中继。此功能需要启用 StatefulFailoverInjection 特性开关。StatefulFailoverInjection 目前处于 Alpha 阶段，默认情况下是关闭的。功能约束：应用必须限定在单个集群中运行；迁移清理策略（PurgeMode）限定为Immediately，即故障应用需立即删除然后再创建新应用，确保数据一致性。▶  单集群应用迁移能力增强在用户将业务从单集群迁移至多集群的过程中，如果资源已经被迁移到 Karmada 控制面，那么当控制面中的资源模板被删除时，成员集群中的资源也会随之删除。但在某些场景，用户希望能够保留成员集群中的资源。例如，作为管理员，在工作负载迁移过程中可能遇到意外情况（如云平台无法发布应用程序或 Pod 异常）， 需要回滚机制立刻恢复到迁移之前的状态，以便快速止损。在 v1.12 版本，社区在PropagationPolicy/ClusterPropagationPolicy API 中引入了PreserveResourcesOnDeletion 字段，用于定义当控制面中的资源模板被删除时成员集群上资源的保留行为，如果设置为true，则成员集群上的资源将被保留。结合此字段，一旦用户在迁移过程中发现异常，可以快速执行回滚操作并保留成员集群中原有的资源，整个迁移回滚过程更加安全可控。使用该字段请注意以下两点：该配置对所有成员集群统一生效，不会仅针对部分集群进行选择性控制。当 Policy 被删除时，资源模板及已分发的成员集群资源将保持不变，除非被显式删除。以 PropagationPolicy 为例，用户在删除 Karmada 控制面资源模板时，可以配置如下 PropagationPolicy 来保留成员集群的资源：apiVersion: policy.karmada.io/v1alpha1 kind:PropagationPolicy metadata: name:nginx-pp spec: conflictResolution:Overwrite preserveResourcesOnDeletion:true# 资源模板删除后，成员集群资源依然保留 placement: clusterAffinity: clusterNames: -member1 resourceSelectors: -apiVersion:apps/v1 kind:Deployment name:nginx -apiVersion:v1 kind:Service name:nginx-svc更多有关安全回滚迁移的资料请参考：迁移操作如何回滚[2] 。▶  Karmada Operator 高可用部署能力支持作为社区维护的安装工具，Karmada-operator 可以用来部署和管理多个 Karmada 实例。为了更好地支持高可用部署方案，karmada-operator 在本版本实施了一系列针对性的改进和优化措施，包括：引入了对自定义 CA 证书的支持；支持连接外部 etcd；可通过 Secret 指定外部 etcd 客户端的凭据；可为 Karmada 组件指定卷和卷挂载；对外暴露 APISever 服务，用于服务发现。这些增强使得 karmada-operator 能够跨多个管理集群部署一个高度可用的 Karmada 控制平面，这些集群可以跨越不同的数据中心，从而满足故障恢复的诉求。上图是通过 Karmada-operator 构建的生产级高可用架构，在这个架构中，Karmada-operator 跨不同地理位置的数据中心部署多个 Karmada 控制面，并将它们连接到同一个外部 etcd 集群。这种设置不仅确保了跨数据中心的数据一致性，还简化了数据管理和维护工作。此外，借助 Karmada-operator 提供的 APIServer 服务暴露能力，结合 Ingress 对外提供统一的服务访问。同时，利用可配置的CA证书机制，保障了 Karmada 实例与外部服务间通信的安全性。此架构显著增强了系统对单个数据中心故障的抵御能力，最大限度地减少了因数据中心故障导致的服务中断风险，保证了业务连续性和用户体验的稳定性，符合严格的灾难恢复标准。▶  OverridePolicy 支持局部修改结构化字段值OverridePolicy 允许用户针对特定集群自定义资源的覆盖策略，确保资源可以在不同环境中灵活适配和优化。Kubernetes 资源如 Secrets 和 ConfigMaps 常常会用到结构化的字段值，如 ConfigMaps 的.data 利用 YAML 格式的结构化数据承载配置信息。在实际应用中，存在只需要修改其部分字段的情况，而且，当原始的结构化字段值复杂且内容繁多时，使用全覆盖将会大大增大 OverridePolicy 的配置难度。为了解决这一问题，并提高 OverridePolicy 在此类场景中的易用性，Karmada 引入了FieldOverrider 特性。FieldOverrider 支持对 JSON 和 YAML 格式的结构化字段值进行局部修改，即只添加或替换或删除所需的字段。这种方式简化了配置过程，提高了效率，同时减少了出错的可能性，使得资源管理更加直观和便捷。通过FieldOverrider，用户可以对结构化字段值进行更精细化地处理，适应多变的应用环境需求。下面以 ConfigMap 为例，用户可通过FieldOverrider 部分覆盖 ConfigMap 的.data 字段来实现集群间的差异化配置。# example-configmap apiVersion: v1 kind: ConfigMap metadata: name: example-configmap data: config.yaml: | app: database: port: 5432 ip: 127.0.0.1 name: example zone: zone1# example-overridepolicy apiVersion:policy.karmada.io/v1alpha1 kind:OverridePolicy metadata: name:example spec: resourceSelectors: -apiVersion:v1 kind:ConfigMap name:example-configmap overrideRules: -overriders: fieldOverrider: -fieldPath:/data/config.yaml yaml: -subPath:/app/database/port operator:replace# 支持add、remove和replace操作 value:"3306" targetCluster: clusterNames: -member1经过以上配置，集群 member1 中的 ConfigMap 将更新为：# example-configmap in member1 apiVersion: v1 kind: ConfigMap metadata: name: myconfigmap data: config.yaml: | app: database: port: 3306 # 更新了port ip: 127.0.0.1 name: example zone: zone1更多FieldOverrider 的用法请参考：FieldOverrider 使用指南[3]▶ 致谢贡献者Karmada v1.12 版本包含了来自 33 位贡献者的 253 次代码提交，在此对各位贡献者表示由衷的感谢：贡献者列表：@a7i@ahorine@anujagrawal699@B1f030@chaosi-zju@CharlesQQ@chaunceyjiang@husnialhamdani@iawia002@ipsum-0320@jabellard@jklaw90@KhalilSantana@LavredisG@liangyuanpeng@LivingCcj@MAVRICK-1@mohamedawnallah@mszacillo@RainbowMango@SataQiu@seanlaii@sophiefeifeifeiya@tiansuo114@wangxf1987@whitewindmills@wulemao@XiShanYongYe-Chang@xovoxy@yanfeng1992@yelshall@zach593@zhzhuang-zju参考资料[1]Karmada v1.12版本:cid:link_5[2]迁移操作如何回滚:cid:link_0[3]FieldOverrider 使用指南:cid:link_4【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_6 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

作者：唐明&王彬丞   引言   随着边缘计算的发展，人工智能在边缘侧的应用日益增多，对计算资源的需求也越来越高，尤其 GPU 算力的需求增长迅速。KubeEdge 作为基于 Kubernetes 的开源边缘计算平台，除提供高效的边缘设备管理和边缘应用容器化服务外，还提供了边云协同 AI 框架 Sedna，助力边缘 AI 发展。然而由于边缘计算环境复杂，将 GPU 资源纳入 KubeEdge 集群管理并让其与边缘 AI 应用协同工作成为重要问题。本篇文章将介绍如何将 GPU 边缘节点接入 KubeEdge 集群并支持边缘 AI 应用使用 GPU 资源，以应对边缘 AI 应用的计算需求。   GPU 运行环境构建   本文实验环境 💭 注：Node 1、Node 2 均为边缘节点，分别使用 Containerd 和 Docker 作为容器运行时进行演示在边缘节点上使用 GPU 需要先构建 GPU 运行环境，主要包括以下几个步骤：1、安装 GPU 驱动首先需要确定边缘节点机器是否有 GPU，可以使用 lspci | grep NVIDIA 命令来检查。根据具体 GPU 型号下载合适的 GPU 驱动并完成安装，安装完成后可以使用 nvidia-smi 命令检查驱动是否安装成功。安装方法可以参考[1]。2、安装容器运行时将 GPU 节点接入 KubeEdge 集群，需要先安装如 Docker、Containerd 之类的容器运行时，具体的安装指南可以参考 KubeEdge官方文档[2]。需要特别注意的是，自 KubeEdge v1.14 版本起，已经移除了对 Dockershim 的支持，不再支持直接使用 Docker 运行时管理边缘容器。如仍需使用 Docker，在安装 Docker 后还需安装 cri-dockerd[3]。3、安装 Nvidia-Container-ToolkitNVIDIA Container Toolkit 是一个专为构建和运行 GPU 容器设计的工具包。它通过一系列的功能和组件，使得在容器环境中充分利用 NVIDIA GPU 资源变得更加简单和高效。由于边缘节点网络连接情况不同，有两种方式安装 NVIDIA Container Toolkit：▷ 边缘节点能直接访问外部网络若边缘节点能直接访问外部网络，推荐按照官方文档，使用 apt、yum 等工具进行安装[4]。▷ 边缘节点无法直接访问外部网络边缘节点若无法直接访问外部网络，则需要在网络可以联通的机器上下载官方离线安装包[5]，将安装包传入边缘节点完成解压。 解压后目录中应该出现如下的文件：root@user:~/release-v1.16.0-rc.1-experimental/packages/ubuntu18.04/amd64# ls libnvidia-container1_1.16.0~rc.1-1_amd64.deb libnvidia-container-tools_1.16.0~rc.1-1_amd64.deb nvidia-container-toolkit-operator-extensions_1.16.0~rc.1-1_amd64.deb libnvidia-container1-dbg_1.16.0~rc.1-1_amd64.deb nvidia-container-toolkit_1.16.0~rc.1-1_amd64.deb libnvidia-container-dev_1.16.0~rc.1-1_amd64.deb nvidia-container-toolkit-base_1.16.0~rc.1-1_amd64.deb在该目录中执行下方的命令完成安装： root@user:~# sudo apt install ./*这里我们提供的案例是基于 Ubuntu 系统的（如果使用 CentOS，可以在链接[5]下载对应的 rpm 包，使用 rpm 命令进行安装）。4、配置容器运行时支持 GPU成功安装 Nvidia-Container-Toolkit 后，可以使用 nvidia-ctk 来配置各个容器运行时支持 GPU：# containerd (node1) root@user:~# sudo nvidia-ctk runtime configure --runtime=containerd --set-as-default # docker (node2) root@user:~# sudo nvidia-ctk runtime configure --runtime=docker --set-as-default5、重启容器运行时重启容器运行时，并且确认是否已经支持 GPU：# containerd (node1) root@user:~# systemctl daemon-reload && systemctl restart containerd # 检查运行时是否已经修改为 nvidia root@user:~# cat /etc/containerd/config.toml |grep nvidia default_runtime_name = "nvidia" [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia] [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia.options] BinaryName = "/usr/bin/nvidia-container-runtime" # docker (node2) root@user:~# systemctl daemon-reload && systemctl restart docker # 检查运行时是否已经修改为 nvidia root@user:~# docker info |grep Runtime Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux nvidia runc Default Runtime: nvidia经过第一部分 GPU运行环境构建的操作，边缘节点已经拥有 GPU 驱动，容器运行时也具备了 GPU 设备的调用能力，接下来需要将边缘节点正式纳管进 KubeEdge 集群。   边缘 GPU 节点纳管   将边缘 GPU 节点纳管至 KubeEdge 集群主要包括以下几个步骤：1、节点接入推荐使用 keadm 工具将边缘节点接入 KubeEdge 集群，接入方式与普通边缘节点一致，详细信息可参考 KubeEdge 官方文档[6]。下面以 Docker 和 Containerd 容器运行时作为边缘 GPU 节点接入示例：# containerd (node1) root@user:~# keadm join --cgroupdriver=cgroupfs \ --cloudcore-ipport="THE-EXPOSED-IP":10000 \ --kubeedge-version=v1.17.0 \ --token="YOUR TOKEN" --remote-runtime-endpoint=unix:///run/containerd/containerd.sock # docker (node2) root@user:~# keadm join --cgroupdriver=systemd \ --cloudcore-ipport="THE-EXPOSED-IP":10000 \ --kubeedge-version=v1.17.0 \ --token="YOUR TOKEN" --remote-runtime-endpoint=unix:///var/run/cri-dockerd.sock运行 systemctl status edgecore 命令确认边缘节点 EdgeCore 是否运行成功：root@user:~# systemctl status edgecore ● edgecore.service Loaded: loaded (/etc/systemd/system/edgecore.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2022-10-26 11:26:59 CST; 6s ago Main PID: 2745865 (edgecore) Tasks: 13 (limit: 4915) CGroup: /system.slice/edgecore.service └─2745865 /usr/local/bin/edgecore2、部署 k8s-device-plugin可以按照下方的 yaml 文件部署 k8s-device-plugin DaemonSetapiVersion: apps/v1 kind: DaemonSet metadata: name: nvidia-device-plugin-daemonset namespace: kube-system spec: revisionHistoryLimit: 10 selector: matchLabels: name: nvidia-device-plugin-ds template: metadata: labels: name: nvidia-device-plugin-ds spec: containers: - env: - name: FAIL_ON_INIT_ERROR value: "false" image: nvcr.io/nvidia/k8s-device-plugin:v0.14.3 imagePullPolicy: IfNotPresent name: nvidia-device-plugin-ctr resources: {} securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /var/lib/kubelet/device-plugins name: device-plugin dnsPolicy: ClusterFirst priorityClassName: system-node-critical restartPolicy: Always schedulerName: default-scheduler securityContext: {} terminationGracePeriodSeconds: 30 tolerations: - effect: NoSchedule key: nvidia.com/gpu operator: Exists volumes: - hostPath: path: /var/lib/kubelet/device-plugins type: "" name: device-plugin检查 k8s-device-plugin 是否成功部署：root@user:~# kubectl get po -n kube-system -owide|grep nvidia nvidia-device-plugin-daemonset-d5nbc 1/1 Running 0 22m 10.88.0.4 nvidia-edge-node <none> <none> nvidia-device-plugin-daemonset-qbwdd 1/1 Running 0 2d6h 10.88.0.2 nano-1iamih8np <none> <none>使用 kubectl describe node 命令验证节点 GPU 信息是否正确上报。root@user:~# kubectl describe node {YOUR EDGENODE NAME} Name: nvidia-edge-node Roles: agent,edge Labels: beta.kubernetes.io/arch=amd64 ... Capacity: cpu: 12 ephemeral-storage: 143075484Ki hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 40917620Ki nvidia.com/gpu: 1 pods: 110 Allocatable: cpu: 12 ephemeral-storage: 131858365837 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 40815220Ki nvidia.com/gpu: 1 pods: 110如果节点信息中出现了 nvidia.com/gpu 资源，说明 device-plugin 正常运行，可以将 GPU 挂载至边缘 GPU 应用容器中。第三部分提供测试应用的部署方法，能够验证 GPU 调用能力。   测试 GPU 资源调用能力  1、部署 GPU 测试应用可以使用下方所示的示例 yaml，部署一个 pytorch 的边缘应用，该应用使用一个 GPU 资源。kind: Deployment apiVersion: apps/v1 metadata: name: test-gpu namespace: default spec: replicas: 1 selector: matchLabels: app: test-gpu template: metadata: labels: app: test-gpu spec: containers: - name: container-1 image: pytorch/pytorch:2.2.0-cuda12.1-cudnn8-devel command: - tail - '-f' - /dev/null resources: limits: nvidia.com/gpu: '1' requests: nvidia.com/gpu: '1' imagePullPolicy: IfNotPresent nodeName: nvidia-edge-node # replace to your GPU edge node name2、验证 GPU 是否成功挂载进入这个应用创建的容器中，调用 pytorch 中的 torch.cuda.is_available() 命令验证 GPU 是否成功挂载。# containerd (node1) root@user:~# crictl ps CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD de1f1e60abc0a 0dd75116a8ce8 2 minutes ago Running container-1 0 6beffb412af3f test-gpu-6bfbdc9449-jfbrl root@user:~# crictl exec -it de1f1e60abc0a /bin/bash root@test-gpu-6bfbdc9449-jfbrl:/workspace# python3 Python 3.10.13 (main, Sep 11 2023, 13:44:35) [GCC 11.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import torch >>> torch.cuda.is_available() True # docker (node2) root@user:~# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e7e3804626a5 853b58c1dce6 "tail -f /dev/null" 53 seconds ago Up 45 seconds k8s_container-1_test-gpu-arm64-nano-7f8fd7f79f-hzvp5_default_64fb7a90-b0e6-4b46-a34f-8a06b24b9169_0 root@user:~# docker exec -it e7e3804626a5 /bin/bash root@test-gpu-arm64-nano-7f8fd7f79f-hzvp5:/# python3 Python 3.8.10 (default, Nov 14 2022, 12:59:47) [GCC 9.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import torch >>> torch.cuda.is_available() True通过本文的介绍，我们详细探讨了如何将边缘 GPU 节点接入 KubeEdge 集群，并支持边缘应用使用 GPU 资源。将 GPU 资源集成至 KubeEdge 集群中可以大大提升边缘设备的计算能力，推动边缘 AI 技术的发展，助力实现高效的边缘计算解决方案。欢迎大家持续关注 KubeEdge 社区。▍相关链接[1] 安装GPU驱动参考文档：https://www.nvidia.cn/drivers/lookup/[2] KubeEdge容器运行时文档：https://kubeedge.io/docs/setup/prerequisites/runtime[3] cri-dockerd参考文档：https://kubeedge.io/docs/setup/prerequisites/runtime#docker-engine[4] NVIDIA Container Toolkit官方文档：https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html[5] NVIDIA Container Toolkit官方离线安装包：cid:link_1[6] 节点接入参考文档：https://kubeedge.io/docs/setup/install-with-keadm【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_2Slack地址 : 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/

Kmesh是业内首个内核级流量治理引擎，Kmesh创新性地将服务治理卸载到内核eBPF和中心代理。Kmesh目前有两种工作模式：Kernel-Native 和 Dual-Engine模式。Kernel-Native模式，Kmesh将流量治理完全下沉操作系统内核，通过eBPF和可编程内核模块对流量进行治理，在整个服务访问链路上不会增加任何多余的连接跳数，提供极致的性能体验。当然Kernel-Native模式对操作系统内核有一定的要求，比较适合对性能有极致要求的用户。 今天重点谈的是Dual-Engine模式（本文后续均以Kmesh指代），这是一种分层的流量治理架构，它是通过eBPF程序拦截应用流量，并根据用户策略进行路由、负载均衡等四层的治理；七层治理则采用中心式代理，这样既可以保证七层治理需求的多样性和扩展性，又避免了Sidecar架构中，流量两次进出七层代理的复杂性。Kmesh Dual-Engine的架构如下图所示：Kmesh Dual-Engine架构Ambient Mesh是Istio社区2022年推出的一种Sidecarless架构，其目的也是为用户提供资源开销更小的网络基础设施。Ambient也是采用分层的流量治理，其中节点上，用户态组件ztunnel负责拦截进出应用的流量，并进行四层转发；中心侧通过waypoint进行七层流量的治理，同样可以做到灵活、按需部署。Ambient Mesh架构我们可以看到Kmesh和Ambient Mesh在架构上非常相似，两者均采用了四七层分离的流量治理架构。然而不同之处在于，Ambient Mesh流量的拦截和转发依靠节点级用户态ztunnel，而Kmesh则依靠eBPF。ztunnel工作在用户态，因此应用发送的流量首先经过iptables的拦截，进入本机协议栈处理一次，发送到ztunnel，而经过ztunnel处理后，再发起第二次连接。同理在服务端，流量也会先被拦截到ztunnel，再次发起连接，然后经由本机协议栈发送到应用进程。但是Kmesh对应用流量的拦截和转发，则是通过eBPF程序在socket的不同钩子点完成，整个过程没有增加多余的连接，因此每次通信过程比Ambient Mesh少两条连接。说到这里就不得不提一下Kmesh的设计初衷了。 Kmesh设计之道 当前用户在考虑服务网格落地时最担心的几个典型问题是：网格基础设施不够可靠，运维复杂，因为过多的中间点出现在服务的访问链路中，服务访问被不同的连接管道串联， 故障定位变得复杂Sidecar带来的CPU、内存资源开销不可忽视网格无法独立升级，它的生命周期与应用绑定，升级过程伴随着应用重启基础设施代理额外的服务访问时延增加Kmesh重点考虑了以上问题并结合用户对网格的基本诉求，定义了五大设计原则：极简运维，打造足够可靠、轻量、解耦的网络基础设施，尽量的减少用户的维护成本。高性能，微服务架构下，服务的调用拓扑一般都很长，有的请求甚至有10+次调用链，因此必须保证在绝大多数情况下，小于1ms的时延。低开销，底层网络基础设施占用的CPU、Memory相对于业务容器应该足够小，并且不会随着业务容器的规模而大幅增加。扩展性，为应对不同的协议治理，必须从架构层提供足够的扩展能力高安全，构筑零信任安全的能力，为用户提供全链路可信保障Kmesh五大设计原则  Kmesh与Ambient Mesh性能对比  几个月前，我们将Kmesh v0.5.0与Ambient Mesh v1.22.1在测试环境下（kind集群）进行过对比，只比对了两者在处理L7流量治理的场景下的时延，结果显示，Kmesh的端到端时延较Ambient Mesh提升25%左右。Kmesh与Ambient v1.22对比我们把这个结果汇报给了CNCF TAG-Network以及Istio社区，他们希望在真实的Kubernetes集群以及用最新的版本进行全面的测试。所以我们重新做了完整的测试。▍测试环境我们在华为云香港Region创建了一个Kubernetes 1.30标准版集群，并且纳管了三个Worker节点（Ubuntu 22.04, 规格为4U 16G）。集群中安装Istio 1.24.1 Ambient模式，以及Kmesh最新版本集群中部署了Fortio测试工具，无资源限制，其中Fortio-Client与Fortio-Server均为单副本，分别部署在不同的节点七层代理waypoint按需部署，在Kmesh和Ambient测试中，均与Fortio-Server部署在同一个节点，保证两者拓扑一致waypoint 规格2核1GFortio测试采用连接复用，并发连接数（1,2,4,8,16,32,64,128）▍最大吞吐量L4治理吞吐四层服务治理，Kmesh的最大吞吐与基线（没有任何治理）基本一致，Kmesh的吞吐能力是Ambient Mesh的两倍左右。这里主要是因为，Kmesh的采用eBPF随流治理，不会增加访问路径的长度，而Ambient Mesh在客户端和服务端两个节点分别多了一个ztunnel用户态代理，导致流量路径多了两条连接。L7治理吞吐L7治理吞吐放大图七层服务治理，Kmesh与Ambient吞吐量均比基线差，因为两者均多了一层七层Envoy代理。但是Kmesh的吞吐大概是Ambient Mesh的1.3倍，这里还是得益于Kmesh的治理路径上少了两次用户态代理，减少了数据的用户态和内核态拷贝次数以及协议栈处理的次数。▍服务治理时延我们选取了在固定QPS 1024下，分别测试Kmesh和Ambient Mesh的L4和L7治理的时延。L4服务治理时延测试可以看到Kmesh的L4治理相比于基线，基本上没有增加额外的时延开销，而Ambient Mesh在并发连接数比较高的时候，增加了大概1.5ms的时延。可能是由于ztunnel在新版本引入了连接池导致。L7服务治理时延测试我们可以看到在并发连接数低时，Kmesh与Ambient Mesh的七层治理时延增加非常少，在小于8并发的时候，Kmesh的时延小于1ms，Ambient Mesh的时延不可预测性更大，其P99时延甚至增加8ms。随着并发连接数增加，Kmesh和Ambient Mesh的时延均增加。但是在小于32并发时，Kmesh的P99时延比Ambient Mesh好两倍多。在更高128并发时，Ambient Mesh的表现似乎更优一些，但是差距不大。在笔者看来，造成以上结果的原因，主要有两点。1、Waypoint采用Envoy实现，当前测试中Envoy均启动两个worker线程并发处理。Envoy的线程间不共享任何状态和数据以避免锁冲突，但是同时带来了负载不均衡和延迟不稳定的问题。2、ztunnel的实现中增加了连接池的优化，虽然连接复用可以在高并发时节省一些连接资源，但是也可能带来额外的不稳定时延。CPU和内存Kmesh在节点流量治理采用了eBPF，没有用户态进程，所以引入的资源开销非常小，详细请参考：cid:link_5/en/docs/performance/resource_consumption/而在最大吞吐量测试时，ztunnel的CPU占用率与Fortio应用基本一致，大概100%的CPU占用，而通过bpftop工具可以查看Kmesh的bpf程序CPU利用大概在10%左右，从CPU利用率上来说Kmesh优于Ambient 10 倍数据面内存：在测试中，ztunnel占用的内存保持在10M+，相对比较稳定，Kmesh数据面的内存占用主要在BPF Map的内存分配，当前Kmesh使用的BPF Map已经采用按需分配，因此在测试过程占用的内存更少，小于5M。  测试感悟与总结  本次测试，我们主要在时延和吞吐两个维度对Kmesh和Ambient进行了一定比较，总体来说Kmesh的性能略胜一筹。四层流量治理场景下，Kmesh的性能与基线基本保持一致，全面优于Ambient Mesh。但是在七层治理的场景下，我们看到无论是Kmesh还是Ambient Mesh性能衰减还是比较大，而且也具有一些不稳定的延时。七层代理Waypoint是端到端访问的性能瓶颈，受限于其多线程无锁的设计，在高并发场景下，Envoy的资源分配以及参数调教对性能的影响很重要。另外技术的对比不应该只局限在一些性能参数指标，还应该关注可靠性、运维的便捷性。服务访问链路就像是由多条管道连接起来的输水管，每一个接口连接就相当于一个用户态组件。输水管道中，接口连接处最容易漏水，而服务访问中同样如此，由于不同的代理组件接收、处理及发送数据的速度不一样，因此不同的代理设置不同的连接Buffer，不同的超时，不同的连接池等等参数。越多的连接级联，意味着越多的不可靠因素和风险存在。Kmesh在设计之初就重点考虑了极简运维和高可靠性，Kmesh尽可能地将流量治理下沉，尽量减少连接的跳数，从下图可以看出，Kmesh在服务访问链路上连接跳数比Ambient Mesh少2条，这大大降低了用户在故障后问题定位的复杂度。将节点的流量治理下沉OS内核的另一个好处是，Kmesh在控制面升级时或者重启时，即使BPF程序更新，也不会导致业务的连接中断。而节点级用户态代理，天然不具备升级重启不影响业务通信的能力。  如何使用Kmesh/加入社区贡献  社区地址：cid:link_4安装试用：cid:link_3参考链接1. 实验步骤：cid:link_12. cid:link_53. cid:link_24. https://jimmysong.io/blog/introducing-kmesh-kernel-native-service-mesh/更多云原生技术动向关注容器魔方

12月7日，2024华为云开源开发者论坛在上海顺利召开。本届论坛面向用户企业、生态伙伴、个人和高校开发者，开展主论坛、云原生、开源共创、大前端四大论坛，共启云上创新和价值裂变。云原生与AI成为本次论坛中的热门话题，来自CNCF、小红书、B站、华为云、DaoCloud、多比特、京东等技术大咖齐聚上海，共享KubeEdge、Volcano、Karmada、openGemini、Kmesh、Kuasar、openEuler、Sermant等项目技术的生产实践和创新成果，共探云原生社区合作与未来发展无限可能。开放协作，共创云原生 × AI繁荣生态华为云开源业务总经理邓明昆在论坛上发表《开放协作，共创云原生繁荣生态》演讲。他表示，云原生的商业价值和技术价值已经已经获得市场和社区的广泛认同，华为云作为云原生生态的重要参与者，将持续开放协作，和开发者一起共创云原生繁荣生态。会上，Kmesh Orion 子项目重磅亮相，持续构建内存安全、高性能的云原生数据面。引领云原生技术创新，华为云云原生一路生花。今年，KubeEdge成为CNCF首个云原生边缘计算毕业项目，openGemini、Sermant正式成为CNCF官方项目，Karmada、Volcano海内外多行业代表用户大规模生产落地，Kmesh创新引领Sidecarless服务网格发展，Kuasar 1.0 实现LLM高效开发与灵活部署重塑，推动云原生与AI融合发展。▲ 华为云开源业务总经理邓明昆云原生已成为企业数字化转型的重要基石，随着人工智能的高速发展，云原生和 AI 的融合也正在智能应用和行业场景中展现出更大的潜力。主论坛上，CNCF中国区总监、LF亚太区战略总监Keith Chan分享了开源发展趋势及当前热门的Cloud Native AI。他提到，AI开发者正与云原生开发者呈融合之势，Cloud Native AI即在云原生基础设施上部署和应用AI。在对最终用户的调研中发现，超半数企业在 AI 部署中应用云原生技术，涵盖公有云、私有云及混合云。在迈向CNAI的进程中，云原生生态系统为在云中运行AI工作负载拥有更好体验铺平了道路，有力地支持了GPU共享，对加速云原生AI发展提供了有力的技术支持。▲ CNCF中国区总监、LF亚太区战略总监Keith Chan在《打破算力边界，云原生加速AI应用创新》主题分享中，华为云云原生开源负责人、CNCF技术监督委员会（TOC）委员王泽锋指出，AI应用创新高速发展对算力提出了更高要求，云原生统一算力平台，有效整合资源，实现高效的管理与调度，已成为AI的最佳底座，而统一作业编排和算力调度是平台能力的关键。他详细阐述了基于 Karmada 和 Volcano 的统一算力编排调度方案，包括作业抽象、Gang 调度、装箱调度、统一资源管理、故障迁移等功能，这些云原生能力为AI应用提供了稳定、高效的运行环境，推动AI创新发展。▲ 华为云云原生开源负责人、CNCF技术监督委员会（TOC）委员王泽锋融合创新，智能未来，云原生论坛大咖齐聚小红书容器技术专家、云原生资源效能与应用平台负责人熊峰带来《Karmada助力小红书打造混合云多集群架构》演讲分享。随着业务的飞速发展，小红书内部K8s集群的规模和数量都在快速增长，集群和资源管理难度急剧增大，小红书通过引入 Karmada 多集群方案，打造面向应用的统一平台入口，提升应用跨集群分发与弹性能力，做好应用跨集群调度，高效管理多云基础设施。▲ 小红书容器技术专家、云原生资源效能与应用平台负责人熊峰Bilibili云原生资深研发工程师王凯发表《哔哩哔哩在视频转码场景下基于Volcano的落地实践》演讲。他介绍了为什么选型Volcano并细致讲解了基于 Volcano 的联邦化离线平台介绍和转码场景对 Volcano 做的高吞吐改造。当前 B 站转码任务已经 100% 由 Volcano 调度。借助 Volcano ，B站将批任务处理能力下沉到了平台，可供其他类似场景复用，此外也和其他场景拉齐了调度器。当前 B 站内部 AI、大数据、转码已经都统一了调度器。▲ Bilibili云原生资深研发工程师王凯KubeEdge作为今年新晋的CNCF毕业级项目，也在本次云论坛上趁热给与会项目和开发者们带来了社区治理经验分享，KubeEdge TSC两位专家——华为云高级软件工程师徐飞，道客首席运营官张红兵联合发表《CNCF毕业项目KubeEdge经验分享及行业实践》演讲。KubeEdge自2018年开源以来，一直秉持开源开放的治理理念，在社区开发、社区治理、社区用户采纳等方面都取得重大的进展。成功从CNCF毕业，标志着项目的发展进入成熟的新阶段。▲ KubeEdge TSC，华为云高级软件工程师徐飞，道客首席运营官张红兵华为云数据库技术专家 & openGemini社区Maintainer 范祥从社区技术融合创新的角度，带来《openGemini 与 KubeEdge：探索云边协同的高效时序数据治理方案》分享。他指出，当前，物联网和车联网领域的企业普遍将数据直接传输至云端，这导致了数据流转环节增多，数据处理效率问题变得尤为紧迫。为了应对这一挑战，openGemini携手KubeEdge和社区合作伙伴，致力于打造基于KubeEdge平台的云边协同解决方案，旨在为用户提供简单、便捷且高效的数据处理能力。▲ 华为云数据库技术专家 & openGemini社区Maintainer 范祥华为云Grid可靠性首席技术专家刘翔，Istio社区Steering Committee委员、Kmesh Maintainer徐中虎介绍了《服务网格的未来：Kmesh的设计思想与演进方向》。Kmesh采用eBPF将L4治理下沉内核，配合安全、稳定、可靠的中心式L7代理，将高性能、轻量发挥到极致。Kmesh Orion作为内存安全、高性能的云原生数据面，具备丰富的L7流量治理特性，可以对当前Kmesh的L4流量治理能力进行有效补充，与Kmesh组合将在安全、高性能、低开销、极简运维等方面形成独特的竞争优势。▲ 华为云Grid可靠性首席技术专家刘翔，Istio社区Steering Committee委员，Kmesh Maintainer徐中虎华为云容器基础设施架构师冯绍宝，华为高级工程师、openEuler sig-cloudnative Maintainer徐学鹏介绍了Kuasar新型轻量化容器沙箱的探索和实践。单一容器沙箱很难同时满足安全、通用和资源效率这3个特性。Kuasar提出一套Sandbox管理框架，通过简化架构，抽象接口，配合轻量级容器引擎iSulad，提供了丰富的沙箱类型支持，可大幅沙箱容器的启动速度和资源效率。iSulad+Kuasar将在Serverless、AI、机密容器等场景持续演进，在云原生时代发挥更大的作用。▲ 华为云容器基础设施架构师冯绍宝，华为高级工程师，openEuler sig-cloudnative Maintainer冯学鹏多比特基础架构组负责人陈志军发表《小游戏出海场景下基于Sermant的云原生微服务架构演进》演讲。他介绍了在中国小游戏企业出海渐成趋势之际面临的挑战及对微服务架构的选型过程。Sermant具备高性能、资源占用少、代码0侵入等优势，全面的类隔离机制实现0类冲突，且提供更丰富、更灵活的服务治理功能解耦，微服务运行时动态挂载：服务0中断。多比特在基于Sermant的实践中，探索出了一条保证业务稳定和成本可控的道路。▲ 多比特基础架构组负责人陈志军在论坛期间的云原生趋势谈主题圆桌中，CNCF中国区总监、LF亚太区战略总监Keith Chan，华为云云原生开源负责人、CNCF TOC王泽锋，道客首席运营官、KubeEdge TSC张红兵，京东高级算法工程师王龙辉，华为云高级软件工程师任洪彩进行了云原生趋势深度探讨，共研开源跨社区合作、用户社区合作以及云原生与AI未来发展等话题。▲ 圆桌对话：云原生趋势谈让每一位开发者都成为决定性的力量。在大会主论坛上，来自Karmada、Volcano、KubeEdge、openGemini等社区的多位云原生社区核心贡献者，荣获年度杰出开源开发者奖项。该奖项用于致谢开发者们在华为云开源开发者生态中的协作贡献和卓越价值。▲ 年度杰出开源开发者作为全球云原生生态的长期参与者与贡献者，华为云深耕云原生技术创新，是CNCF唯一的中国创始成员，拥有CNCF多个项目技术委员会、治理委员会成员及核心Maintainer席位，并在2024年获得了全球顶级开源组织CNCF中国本土唯一TOC委员席位。坚持开源创新，驱动产业升级，随着企业用云的不断深入，华为云持续创研业界领先的云原生产品方案，连续八次中国容器软件市场份额No.1，分布式云原生UCS、云容器引擎CCE、Serverless容器CCE Autopilot和CCI等代表产品引领全行业智能化发展趋势，为企业数智化转型提供强大动力。融合创新，智领未来。开源社区不仅仅在各自的技术领域中加深探索创新，也在跨社区的应用合作与融合发展中不断拓宽可能性。本次华为云开源开发者论坛云原生分论坛，为用户和开发者们带来了多项目、多领域的行业用户实践经验和技术创新成果分享，而成熟发展的云原生生态系统也正在加速引领各行各业迈向智能未来。更多云原生技术动向关注容器魔方

CCE(华为云容器集群服务)提供云原生监控插件（kube-prometheus-stack），可全面对接开源Prometheus生态，支持类型丰富的组件监控，并提供了多种开箱即用的预置监控大盘。本文就分享了基于Prometheus指标的弹性伸缩实践。准备工作：有华为云账号，且经过实名认证操作步骤：1 创建一个集群1.1 购买集群登录CCE控制台，在“集群管理”页面右上角单击“购买集群”。在“购买集群”页面，按需填写集群配置参数。如果没有虚拟私有云和子网可以参考以下操作：登录控制台，在搜索栏搜VPC，点击进入网络控制台页面点击右上角“创建虚拟私有云”按钮，进行创建。如下图配置VPC和子网信息，名称和网段自定义即可，最后点击右下角“立即创建”按钮创建后如下图显示在集群配置页面选择已创建的子网和私有云即可，单击“下一步：插件选择”，选择创建集群时需要安装的插件。单击“下一步：插件配置”，配置插件。参数填写完成后，单击“下一步：确认配置”，显示集群资源清单，确认无误后，单击“提交”。集群创建预计需要5-10分钟，您可以单击“返回集群管理”进行其他操作或单击“查看集群事件列表”后查看集群详情。2 安装云原生监控插件2.1 安装插件登录CCE控制台，单击集群名称进入集群，单击左侧导航栏的“插件中心”。在“插件中心”页面右侧找到云原生监控插件，单击“安装”。2.2 参数配置本地数据存储：本实践使用本地存储监控数据，监控数据可选择是否上报至AOM或三方监控平台。自定义指标采集：该配置在本实践中必须选择开启，否则将无法采集自定义指标。3 获取Prometheus监控数据3.1 部署测试应用进入节点列表点击节点名称进入ECS控制台，选择远程登录，使用CloudShell登录到云主机。1）创建sample-app.yaml文件，通过yaml文件部署名称为“sample-app”的应用：内容如下：apiVersion: apps/v1kind: Deploymentmetadata:  name: sample-app  labels:    app: sample-appspec:  replicas: 1  selector:    matchLabels:      app: sample-app  template:    metadata:       labels:        app: sample-app    spec:      containers:       - image: swr.cn-east-3.myhuaweicloud.com/container/autoscale-demo:v0.1.2 #示例镜像        name: metrics-provider         resources:          requests:            cpu: 250m            memory: 512Mi          limits:            cpu: 250m            memory: 512Mi        ports:        - name: http          containerPort: 8080   #容器暴露的端口      imagePullSecrets:        - name: default-secret---apiVersion: v1kind: Servicemetadata:  name: sample-app  namespace: default  labels:     app: sample-appspec:  ports:     - port: 80      name: http      protocol: TCP      targetPort: 8080  selector:    app: sample-app   type: ClusterIP2）创建工作负载。登陆容器集群后台，执行命令行创建工作负载：kubectl apply -f sample-app.yaml3.2 创建ServiceMonitor监控自定义指标1）创建servicemonitor.yaml文件，内容如下：apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitormetadata:  name: sample-app  # ServiceMonitor名称  namespace: defaultspec:  endpoints:        # 定义要监控的服务的端点，包括名称、端口、路径、协议等信息  - interval: 30s   # 表示Prometheus Operator将每30秒检查一次服务是否需要添加到监控目标列表中    port: http    path: /metrics  namespaceSelector:    any: true  selector:     matchLabels:      app: sample-app  #需要采集数据的对象标签2）创建ServiceMonitor登陆容器集群后台，执行命令行创建监控服务：kubectl apply -f servicemonitor.yaml4 修改Prometheus配置文件4.1 修改自定义指标采集规则修改Prometheus的adapter-config配置项，通过修改user-adapter-config中rules字段将Prometheus暴露出的指标转换为HPA可关联的指标。（HPA策略即Horizontal Pod Autoscaling，是Kubernetes中实现POD水平自动伸缩的功能。）在rules字段下添加自定义指标采集规则。以收集内存指标示例如下：rules:- seriesQuery: container_memory_working_set_bytes{namespace!="",pod!=""}  resources:    overrides:      namespace:         resource: namespace      pod:         resource: pod  name:    matches: ^(.*)_bytes    as: ${1}_bytes_per_second #此处${1}取值为matches:"^(.*)_bytes"中^(.*)匹配到的值  metricsQuery: sum(<<.Series>>{<<.Label Matchers>>}) by (<<.GroupBy>>)重新部署monitoring命名空间下的custom-metrics-apiserver工作负载。（monitoring命名空间是安装云原生监控插件时自动生成，无需手动创建）在容器集群后台执行命令查看采集指标是否添加成功。kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1/namespaces/default/pods/*/container_memory_working_set_bytes_per_second5 创建HPA策略5.1 使用自定义指标创建HPA策略。创建hpa.yaml文件，内容如下：kind: HorizontalPodAutoscalerapiVersion: autoscaling/v2metadata:  name: sample-app-memory-highspec:# HPA的伸缩对象描述，HPA会动态修改该对象的Pod数量。  scaleTargetRef:    apiVersion: apps/v1    kind: Deployment    name: sample-app# HPA的最小Pod数量和最大Pod数量。  minReplicas: 1  maxReplicas: 10# 监控的指标数组，支持多种类型的指标共存。  metrics:  - type: Pods    pods:      metric:         name: container_memory_working_set_bytes_per_second   # 使用自定义容器指标      target:        type: AverageValue  # AverageValue类型的目标值，Pods指标类型下只支持AverageValue类型的目标值        averageValue: 1024000m   # 此处1024000m代表1KB创建HPA策略。kubectl apply -f hpa.yaml查看HPA策略是否生效。kubectl get hpa sample-app-memory-high6 实验结束弹性伸缩之前：弹性伸缩之后：

Kmesh 是内核原生Sidecarless服务网格数据平面。它借助 "eBPF "和 "可编程内核"，将流量治理下沉到操作系统内核，大大的降低了服务网格的资源开销和网络延迟。通过eBPF，流量数据可以直接在内核中获取，并且能够使用 "bpf map"将数据传递到用户空间。Kmesh使用这些数据构建监控指标和访问日志。▍如何获取原始数据在内核中，可以直接获取socket携带的流量信息。bpf_tcp_sock 中携带的数据如下：struct bpf_tcp_sock { __u32 snd_cwnd; /* Sending congestion window */ __u32 srtt_us; /* smoothed round trip time << 3 in usecs */ __u32 rtt_min; __u32 snd_ssthresh; /* Slow start size threshold */ __u32 rcv_nxt; /* What we want to receive next */ __u32 snd_nxt; /* Next sequence we send */ __u32 snd_una; /* First byte we want an ack for */ __u32 mss_cache; /* Cached effective mss, not including SACKS */ __u32 ecn_flags; /* ECN status bits. */ __u32 rate_delivered; /* saved rate sample: packets delivered */ __u32 rate_interval_us; /* saved rate sample: time elapsed */ __u32 packets_out; /* Packets which are "in flight" */ __u32 retrans_out; /* Retransmitted packets out */ __u32 total_retrans; /* Total retransmits for entire connection */ __u32 segs_in; /* RFC4898 tcpEStatsPerfSegsIn * total number of segments in. */ __u32 data_segs_in; /* RFC4898 tcpEStatsPerfDataSegsIn * total number of data segments in. */ __u32 segs_out; /* RFC4898 tcpEStatsPerfSegsOut * The total number of segments sent. */ __u32 data_segs_out; /* RFC4898 tcpEStatsPerfDataSegsOut * total number of data segments sent. */ __u32 lost_out; /* Lost packets */ __u32 sacked_out; /* SACK'd packets */ __u64 bytes_received; /* RFC4898 tcpEStatsAppHCThruOctetsReceived * sum(delta(rcv_nxt)), or how many bytes * were acked. */ __u64 bytes_acked; /* RFC4898 tcpEStatsAppHCThruOctetsAcked * sum(delta(snd_una)), or how many bytes * were acked. */ __u32 dsack_dups; /* RFC4898 tcpEStatsStackDSACKDups * total number of DSACK blocks received */ __u32 delivered; /* Total data packets delivered incl. rexmits */ __u32 delivered_ce; /* Like the above but only ECE marked packets */ __u32 icsk_retransmits; /* Number of unrecovered [RTO] timeouts */ };注意: 上述数据并没完全用于监控指标和访问日志功能。Kmesh将在后续的开发中逐步补充这些指标。现阶段使用的数据有：struct tcp_probe_info { __u32 type; struct bpf_sock_tuple tuple; __u32 sent_bytes; __u32 received_bytes; __u32 conn_success; __u32 direction; __u64 duration; // ns __u64 close_ns; __u32 state; /* tcp state */ __u32 protocol; __u32 srtt_us; /* smoothed round trip time << 3 in usecs */ __u32 rtt_min; __u32 mss_cache; /* Cached effective mss, not including SACKS */ __u32 total_retrans; /* Total retransmits for entire connection */ __u32 segs_in; /* RFC4898 tcpEStatsPerfSegsIn * total number of segments in. */ __u32 segs_out; /* RFC4898 tcpEStatsPerfSegsOut * The total number of segments sent. */ __u32 lost_out; /* Lost packets */ };除了这些socket携带的数据外，Kmesh通过socket_storage在建立链接时存储临时数据。当链接关闭时，从之前存储的临时数据中获取链接持续时间等数据。▍数据处理Kmesh在内核中获取了来自链接的数据后，会通过ringbuf将数据传递给用户态。Kmesh在用户态将ringbuf的数据解析之后，根据这些数据中携带的源服务和目标服务信息更新metricController中的缓存和构建metricLabels。构建的metricLabels有workload粒度的也有service粒度的。但workload粒度的监控指标最多是集群中pod数量的平方，因此Kmesh提供一个启动开关，使用户能够按需启用监控指标功能和访问日志功能。namespacedhost := "" for k, portList := range dstWorkload.Services { for _, port := range portList.Ports { if port.TargetPort == uint32(dstPort) { namespacedhost = k break } } if namespacedhost != "" { break } }建立工作负载粒度的度量和服务粒度的度量metricLabels后，更新缓存。每5秒钟，监控指标信息都会通过Prometheus API更新到Prometheus中。在处理指标时，会一起生成访问日志。每次链接关闭时，都会将生成的Accesslog打印到Kmesh的日志中。Kmesh监控指标功能和访问日志功能的整体架构图如下所示：指标细节现阶段Kmesh L4层监控的指标如下：工作负载粒度:NameDescribekmesh_tcp_workload_connections_opened_total源工作负载和目标工作负载之间总共建立了多少次链接kmesh_tcp_workload_connections_closed_total源工作负载和目标工作负载之间总共关闭了多少次链接kmesh_tcp_workload_received_bytes_total目标工作负载接收到了多少的数据kmesh_tcp_workload_sent_bytes_total源工作负载发送了多少的数据kmesh_tcp_workload_conntections_failed_total源工作负载和目标工作负载之间建立链接失败了多少次服务粒度:NameDescribekmesh_tcp_connections_opened_total源工作负载和目标服务之间总共建立了多少次链接kmesh_tcp_connections_closed_total源工作负载和目标服务之间总共关闭了多少次链接kmesh_tcp_received_bytes_total目标服务接收到了多少的数据kmesh_tcp_sent_bytes_total源工作负载发送了多少的数据kmesh_tcp_conntections_failed_total源工作负载和目标服务之间建立链接失败了多少次监控指标例子:kmesh_tcp_workload_received_bytes_total{connection_security_policy="mutual_tls",destination_app="httpbin",destination_canonical_revision="v1",destination_canonical_service="httpbin",destination_cluster="Kubernetes",destination_pod_address="10.244.0.11",destination_pod_name="httpbin-5c5944c58c-v9mlk",destination_pod_namespace="default",destination_principal="-",destination_version="v1",destination_workload="httpbin",destination_workload_namespace="default",reporter="destination",request_protocol="tcp",response_flags="-",source_app="sleep",source_canonical_revision="latest",source_canonical_service="sleep",source_cluster="Kubernetes",source_principal="-",source_version="latest",source_workload="sleep",source_workload_namespace="default"} 231也能够通过prometheus dashboard查看监控指标。具体步骤参考Kmesh可观测性文档。现阶段Kmesh访问日志展示的字段如下：NameDescribesrc.addr请求的源地址和端口src.workload源工作负载名称src.namespace源工作负载所在的namespacedst.addr请求的目标地址和端口dst.service目标服务的域名dst.workload目标工作负载的名称dst.namespace目标工作负载的命名空间direction流量流向，OUTBOUND表示从节点流出，INBOUND表示从流入节点sent_bytes本次链接发送的数据量received_bytes本次链接接收的数据量duration本次链接的持续时间Accesslog Result: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▍SummaryKmesh直接从套接字获取流量数据，并将其作为ringbuf传递到用户空间，以生成监控指标和访问日志。避免在用户空间拦截流量并以本地方式获取指标。定期批量更新用户空间中的指标，避免在大流量时增加网络延迟。随后，我们还将开发跟踪功能，以补充 Kmesh 的可观测能力。欢迎感兴趣的同学加入Kmesh开源社区!12月7日，Kmesh技术专家将在2024华为云开源开发者论坛上带来《服务网格的未来：Kmesh的设计思想与演进方向》技术分享及重磅发布！添加小助手k8s2222，报名领票参会！

开放创新，释放云上数字生产力。12月7日，2024华为云开源开发者论坛将于上海举办。本届论坛面向生态合作伙伴、企业、个人和高校开发者，设置主论坛、云原生、开源共创、大前端四大论坛，帮助开发者使用开源链接鲲鹏、昇腾根生态和华为云生态，实现高效创新和价值裂变。2024华为云开源开发者论坛云原生专场汇聚 KubeEdge、Volcano、Karmada、Kmesh、openGemini、Sermant、OpenTiny、Kuasar 等技术大咖，邀您共探前沿技术，共领智能未来！完整议程已揭晓，欢迎报名参会 https://hdxu.cn/mitm

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