沙箱隔离技术是一种将进程有效隔离到独立环境中运行的技术。随着容器技术的兴起，沙箱隔离技术也在云原生领域中得到了广泛的应用。iSulad率先通过 Sandbox API 支持 Kuasar，提供高效和稳定的沙箱管理能力。然而，由于容器技术的历史原因，沙箱的概念在容器引擎和容器运行时中没有得到足够的支持。OCI 标准[1]未定义沙箱管理，导致容器引擎和容器运行时只能采用容器管理的方式管理沙箱，引发性能和稳定性问题，具体可参见Kuasar 系列文章[2]。事实上，容器领域一直在深入研究和探索引入沙箱管理接口的问题。举例来说，Containerd 社区于 2022 年 4 月将 Sandbox API 相关功能整合到主线[3]，这一举措对 Containerd 内部沙箱管理逻辑进行了优化。然而，令人遗憾的是，它依然使用 OCI 标准接口来调用容器运行时以管理沙箱。2023 年 4 月 21 日，华为在 Kubecon+CloudNativeCon Europe 2023 云原生峰会上发布了多沙箱运行时 Kuasar[4]，将沙箱管理逻辑引入了容器运行时。至此，Kuasar 成为第一个支持 Sandbox API 的容器运行时。容器引擎使用 Sandbox API 直接管理沙箱成为了可能。iSulad[5]也率先通过 Sandbox API 支持 Kuasar，提供高效和稳定的沙箱管理能力。openEuler 23.09 完成对 iSulad+Kuasar+StratoVirt 的集成，为用户提供了一个极速轻量的安全容器解决方案，具体可参见第二篇 Kuasar 系列文章[6]。Sandbox API 简介service Controller { rpc Create(ControllerCreateRequest) returns (ControllerCreateResponse); rpc Start(ControllerStartRequest) returns (ControllerStartResponse); rpc Platform(ControllerPlatformRequest) returns (ControllerPlatformResponse); rpc Prepare(PrepareRequest) returns (PrepareResponse); rpc Purge(PurgeRequest) returns (PurgeResponse); rpc UpdateResources(UpdateResourcesRequest) returns (UpdateResourcesResponse); rpc Stop(ControllerStopRequest) returns (ControllerStopResponse); rpc Wait(ControllerWaitRequest) returns (ControllerWaitResponse); rpc Status(ControllerStatusRequest) returns (ControllerStatusResponse); rpc Shutdown(ControllerShutdownRequest) returns (ControllerShutdownResponse); }Sandbox API 的引入解决了容器引擎和容器运行时之间由来已久的痛点问题[2]：引入 Sandbox 语义，增强了云原生架构上的连贯性削减 shim 进程的冗余，减小资源开销，加快启动速度缩短调用链，可靠性倍增消除 Pause 容器冗余统一沙箱接口使容器运行时支持多沙箱生命周期与管理 Sandbox API[7] 定义了容器引擎如何与容器运行时交互，其中 Controller Service 定义了沙箱的生命周期管理接口，包括创建 (Create) 、启动 (Start) 、停止 (Stop) 、等待退出 (Wait) 、状态查询 (Status) 、销毁 (Shutdown) 、平台信息查询 (Platform) 等。通过 Sandbox API，容器引擎能够直接对沙箱进行管理，无需通过 OCI 标准接口间接管理沙箱，提高了容器引擎的性能和稳定性。资源管理 Sandbox API 还定义了沙箱的资源管理接口，包括资源准备 (Prepare) 、资源清理 (Purge) 、资源更新 (UpdateResources) 等。容器引擎可以通过这些接口管理容器资源，例如在创建容器前准备资源，运行过程中更新资源，容器退出后清理资源。iSulad 新架构图1. iSulad 架构对比图在 Kuasar 发布以后，iSulad 第一时间采用了新的架构以支持 Sandbox API ，使得它能够通过 Kuasar 来直接管理沙箱。为保持已有版本的兼容性与稳定性，iSulad 只对 CRI V1 版本进行了重构升级，支持用户使用 Sandbox API 管理沙箱。CRI V1alpha 版本继续沿用 OCI 标准来处理沙箱管理请求。沙箱与容器的解耦 在新的架构中，iSulad 引入了 Sandbox 的语义，新增核心模块 Sandbox ，使其成为容器引擎的一等公民，实现了容器管理与沙箱管理的解耦。从云原生整体架构的角度看，容器编排组件、容器引擎和容器运行时之间的沙箱管理变得更加流畅和高效，形成了一个完整的沙箱管理链路。以 iSulad+Kuasar+StratoVirt 极速轻量的安全容器解决方案为例，iSulad 在北向接收来自 Kubernetes 的 CRI 请求，并创建 Sandbox 对象来处理 PodSandbox 相关调用，同时使用 Executor 模块来处理 CRI 的 Container 请求。在南向，使用 Controller 模块通过 Sandbox API 调用 Kuasar 的 Sandboxer 进程来管理沙箱，同时使用 Runtime 中的 Shim V2 模块来调用 Kuasar 的 Task 进程，实现了对 StratoVirt 虚拟机中容器的管理。沙箱控制器 图2. 沙箱控制器类图Sandbox API 的实现使 iSulad 能够直接通过 Controller 来管理沙箱，因此 Kuasar 容器运行时也无需创建 Pause 容器以兼容 OCI 标准，避免了 Pause 容器的冗余。在新架构中，Controller 模块的设计充分考虑了对原有沙箱管理功能的兼容性，即支持用户通过Sandbox 和 Controller 模块创建普通容器(Pause 容器)作为沙箱。如上图所示，Controller 模块对 Sandbox 提供了统一 Controller 接口，以及两种不同的实现：Sandboxer Controller 和 Shim Controller 。Sandboxer Controller 是对 Sandbox API 的封装，将用户对沙箱的管理请求通过 gRPC 接口转发给 Kuasar 的 Sandboxer 进程，从而使 Sandboxer 执行底层的沙箱管理逻辑。Shim Controller 兼容原有的基于容器管理的接口，将对 Sandbox 的管理请求转发给 Executor 模块，以便创建和管理基于 Pause 容器的沙箱。Shim Controller 的实现使用户能够在新的架构下继续使用 OCI 标准接口来管理沙箱，以兼容原有已部署的业务，确保功能的连续性。Sandbox 和 Controller 的详细设计可以参见 iSulad 社区的设计文档[8]。简化容器调用链 图3. 容器启动流程图在支持了 Sandbox API 以后，iSulad 的容器管理流程也发生了一些变化。上图以 iSulad+Kuasar+StratoVirt 解决方案为例，展示了 iSulad 从启动沙箱到启动容器的简化流程。在图中，Kuasar Task 充当虚拟机中的 init 进程，同时也是虚拟机沙箱内容器的管理进程。它向 iSulad 提供容器管理接口 Task API ，当前解决方案中的 Task API 接口的实现与 Shim V2 类似但又不完全相同。根据 Shim V2 规范，容器引擎会调用一个 Shim V2 的二进制，创建 Shim 进程并返回 Shim 地址，用于管理沙箱、容器和资源。然而，通过调用 Sandbox API，iSulad 不再需要通过 Shim 进程来管理沙箱。相反，Sandbox API 的 Start 接口会在启动沙箱后返回一个 Task 地址，使 iSulad 能够与虚拟机中的 Kuasar Task 进程直接通信，以管理容器的生命周期。这种设计消除 Shim 进程以减少了管理面的内存开销并缩短调用链，从而提高了整个解决方案的性能和稳定性。总结 Sandbox API 是 iSulad、Kuasar 和 StratoVirt 这三个组件构成的极速轻量的安全容器解决方案的核心纽带。通过 Sandbox API，容器引擎能够直接对沙箱进行管理，无需通过 OCI 标准接口间接管理沙箱，从而显著提高了容器引擎的性能和稳定性。Sandbox API 的引入，也为容器引擎和容器运行时之间的沙箱管理提供了一个标准化的接口，为容器领域的发展提供了新的可能性。当前 Sandbox API 的实现已经合入了 iSulad 社区的主线，用户可以通过 openEuler 23.09 体验这一全栈自研的极速轻量安全容器解决方案，具体可参见 Kuasar 系列文章[6]。openEuler 社区一直秉承开放、协作、共赢的理念，欢迎更多的开发者参与到 iSulad、Kuasar 和 StratoVirt 的建设中来，共同推动容器领域的繁荣发展。参考[1] OCI Runtime Spec: cid:link_3[2] iSulad+Kuasar：管理面资源消耗锐减 99% 的新一代统一容器运行时解决方案 ：cid:link_5[3] Sandbox API : cid:link_4[4] 多沙箱容器运行时 Kuasar 技术揭晓！100% 启动速度提升，99% 内存开销优化 ：cid:link_6[5] iSulad: cid:link_9[6] openEuler 23.09 一键部署基于 Kuasar 的极速轻量安全容器：cid:link_7[7] sandbox.proto: cid:link_1[8] iSulad Sandbox 设计文档：cid:link_2本文转载自openEuler，原文链接Kuasar社区技术交流地址Kuasar官网：https://kuasar.io项目地址：cid:link_8Twitter: https://twitter.com/Kuasar_io添加社区小助手回复“Kuasar”进入技术交流群

Kurator 是由华为云推出的开源分布式云原生套件。面向分布式云原生场景，Kurator 旨在为用户提供一站式的解决方案，帮助用户快速构建自己的分布式云原生平台。在最新发布的 v0.5.0 版本中，Kurator 强化了其在多集群环境中的应用备份与恢复，以及存储管理的功能，以满足用户对于复杂部署的需求。本次更新主要包括以下两项新特性：统一集群备份恢复与迁移：Kurator 现在支持一键定制化的备份与恢复多个集群中的应用和资源，并通过统一视图实时监控各集群的进度；同时，还支持跨集群资源的一键迁移功能。统一分布式存储：Kurator 实现了一致性的分布式存储解决方案，其一站式部署让用户在多集群环境下轻松实现块存储、文件存储和对象存储的应用。 统一集群备份恢复与迁移在多云和分布式环境的持续演变中，数据的安全性与可恢复性已经成为用户高度关注的问题。对于企业来说，数据丢失往往是一个难以承受的打击，可能导致严重的业务中断和信誉损失。在以 Kubernetes 为行业标准的环境中，伴随着服务数量和集群规模的增长，数据管理的复杂度也随之增加，这使得实施高效而灵活的备份策略变得尤为重要。面对这种需求的不断扩大和挑战的增加，传统的备份工具往往在多环境下展现出局限性，难以提供一个无缝的统一解决方案。因此，Kurator 的统一备份方案应运而生，旨在提供这一领域的备份解决方案。基于 Velero (https://velero.io/) ，Kurator 为用户提供了一键式的操作体验，可以自定义备份并恢复横跨多个集群的应用与资源。通过 Kurator 提供的统一视图功能，用户能够实时监控各个集群备份的状态和进度。其覆盖范围涵盖了从 Pod、Deployment、Service 等 Kubernetes 原生资源，到 PersistentVolumes（PVs）等持久化存储的备份和恢复，以满足现代企业多元化的数据保护需求。统一备份Kurator 在备份解决方案上提供了多样化的选择，以适应不同场景下的数据保护需求。其灵活性确保了不同业务场景下都能找到合适的备份策略。即时备份: 面对数据频繁变动的情形，“即时备份”能够迅速地提供保护，确保关键数据在关键时间点的完整性得以保持。定期备份:对于那些不太频繁变动，但同样需要确保持久性的数据，“定期备份”可以根据预设的时间周期性的自动执行备份，以满足合规性要求和保障数据安全。此外，Kurator 还提供了一系列高度定制化的备份选项。例如，“特定集群备份”允许运维团队基于策略或特定需求有选择性地备份特定集群。“资源过滤”功能则提供了细粒度的控制，使管理员能够根据资源的名称、命名空间或标签等属性来精确定义备份的范围。这些备份策略的多样性和自动化能力为用户在不断变化的业务需求中，提供了稳定和可靠的数据保护。接下来是一个统一备份的实际操作示例：apiVersion: backup.kurator.dev/v1alpha1 kind: Backup metadata:   ...   name: select-labels   namespace: default spec:   destination:     fleet: quickstart   policy:     resourceFilter:       labelSelector:         matchLabels:           app: busybox     ttl: 720h status:   backupDetails:   - backupNameInCluster: kurator-member1-backup-default-select-labels     backupStatusInCluster:       completionTimestamp: "2023-10-28T03:37:13Z"       expiration: "2023-11-27T03:37:07Z"       formatVersion: 1.1.0       phase: Completed       progress:         itemsBackedUp: 1         totalItems: 1       startTimestamp: "2023-10-28T03:37:07Z"       version: 1     clusterKind: AttachedCluster     clusterName: kurator-member1   - backupNameInCluster: kurator-member2-backup-default-select-labels     backupStatusInCluster:       completionTimestamp: "2023-10-28T03:37:13Z"       expiration: "2023-11-27T03:37:07Z"       formatVersion: 1.1.0       phase: Completed       progress: {}       startTimestamp: "2023-10-28T03:37:07Z"       version: 1     clusterKind: AttachedCluster     clusterName: kurator-member2   ...观察 spec 配置，可以看到备份的目标是位于 Fleet 中各集群内所有标有 app:busybox 标签的资源。通过在 spec 中配置策略的方式，可以确保相关的资源得到备份。在 status 中，可以实时追踪到备份任务在每个集群，如 kurator-member1 和 kurator-member2，的执行状况，保持了操作的透明度。🔗 更多的示例和细节，请参考: cid:link_5统一恢复基于统一备份产生的备份数据，Kurator 通过统一恢复功能支持跨集群的应用和资源恢复。针对即时备份恢复:依据“即时备份”创建的备份数据，可以快速恢复至指定关键时刻的状态。针对定期备份恢复: 针对“定期备份”，Kurator 支持将备份数据恢复到最近一次成功执行备份的时间点。类似备份功能，Kurator 在恢复方面也提供了多样化和定制化的选项。例如，“特定集群恢复”使得用户能够只将数据恢复到指定集群，而不必覆盖所有备份中包含的集群。“资源过滤”功能则允许用户对备份数据进行进一步筛选，只选择性地恢复需要的数据项。用户可以根据备份名称、命名空间或标签等属性来定义恢复的范围，这不仅提升了恢复过程的灵活性，也确保了高度的精确性。参阅以下操作示例，了解如何使用 Kurator 进行统一恢复：apiVersion: backup.kurator.dev/v1alpha1 kind: Restore metadata:   ...   name: minimal   namespace: default spec:   backupName: select-labels status:   restoreDetails:   - clusterKind: AttachedCluster     clusterName: kurator-member1     restoreNameInCluster: kurator-member1-restore-default-minimal     restoreStatusInCluster:       completionTimestamp: "2023-10-28T09:24:07Z"       phase: Completed       progress:         itemsRestored: 2         totalItems: 2       startTimestamp: "2023-10-28T09:24:05Z"   - clusterKind: AttachedCluster     clusterName: kurator-member2     restoreNameInCluster: kurator-member2-restore-default-minimal     restoreStatusInCluster:       completionTimestamp: "2023-10-28T09:24:07Z"       phase: Completed       progress:         itemsRestored: 2         totalItems: 2       startTimestamp: "2023-10-28T09:24:05Z"   ...通过检查恢复任务的 spec 配置，我们可以确定本次恢复操作是针对前文提到的、标记为 select-labels 的备份数据。这里使用了最低配置，不进行恢复的筛选，直接根据备份的配置进行恢复。在 status 中，同样可以实时追踪到恢复任务在每个集群的执行状况。🔗 更多的示例和细节，请参考: cid:link_3统一迁移统一迁移旨在简化将应用程序及其资源从一个集群迁移到其他多个集群的过程。用户需要定义一种 migrate 类型的资源配置，并指定源集群、目标集群及相关策略。此外，类似于 Kurator 的统一备份和恢复功能，用户同样可以进行丰富的定制化配置。配置完成之后，Kurator 相应的控制器便会自动启动迁移任务。这一系列任务包括将资源从源集群上传到对象存储，以及最终迁移到指定的目标集群。具体的迁移过程可参考以下示意图：Kurator 统一迁移流程图相较于使用 Velero，Kurator 提供了一个更为集成和清晰的迁移流程描述。所有必要的配置细节都集中在单一的 migrate 对象中，从而减少了随着目标集群数量增加而产生的配置负担。同时，Kurator自动管理从创建备份到完成迁移的全过程，简化了操作流程，降低了手动操作错误的风险。此外，用户还可以通过这一个对象来实时监控多个集群中的迁移进度，随时了解迁移的最新状态，确保整个流程按预期执行。接下来是一个统一迁移的实际操作示例：apiVersion: backup.kurator.dev/v1alpha1 kind: Migrate metadata:   ...   name: select-labels   namespace: default spec:   policy:     resourceFilter:       labelSelector:         matchLabels:           app: busybox   sourceCluster:     clusters:     - kind: AttachedCluster       name: kurator-member1     fleet: quickstart   targetCluster:     clusters:     - kind: AttachedCluster       name: kurator-member2     fleet: quickstart status:   conditions:   - lastTransitionTime: "2023-10-28T15:55:23Z"     status: "True"     type: sourceReady   phase: Completed   sourceClusterStatus:     backupNameInCluster: kurator-member1-migrate-default-select-labels     backupStatusInCluster:       completionTimestamp: "2023-10-28T15:55:18Z"       expiration: "2023-11-27T15:55:13Z"       formatVersion: 1.1.0       phase: Completed       progress: {}       startTimestamp: "2023-10-28T15:55:13Z"       version: 1     clusterKind: AttachedCluster     clusterName: kurator-member1   targetClusterStatus:   - clusterKind: AttachedCluster     clusterName: kurator-member2     restoreNameInCluster: kurator-member2-migrate-default-select-labels     restoreStatusInCluster:       completionTimestamp: "2023-10-28T15:56:00Z"       phase: Completed       startTimestamp: "2023-10-28T15:55:58Z"   ...在 spec 配置中，源集群设置为 kurator-member1，目标集群为 kurator-member2，迁移过程仅针对包含标签 app:busybox 的资源。在 status 中，迁移阶段 Phase 显示为 Completed，表明迁移操作已完成。sourceClusterStatus 和 targetClusterStatus 分别提供源集群资源的备份细节和目标集群资源的恢复情况。🔗 更多的细节，请参考: cid:link_4统一分布式存储分布式存储作为现代云原生架构中不可或缺的一部分，提供了数据的可扩展性和可靠性。然而，在不同集群间实现一个一致的分布式存储解决方案，往往涉及到复杂的配置和管理工作。Kurator 致力于简化分布式存储的部署与管理。基于领先的开源项目 Rook（cid:link_9），Kurator 支持在多集群环境中轻松自动化管理分布式存储。这包括块存储、文件系统存储和对象存储等多种存储类型，以适应各种应用场景的需求。利用 Fleet 插件，Kurator 提供了一种一键跨集群部署分布式存储的解决方案，既简化了配置步骤也显著降低了配置错误的可能性。架构如下图所示：Kurator统一分布式存储架构图接下来是一个通过 Fleet 插件部署多集群分布式存储的例子：apiVersion: fleet.kurator.dev/v1alpha1 kind: Fleet metadata:   name: quickstart   namespace: default spec:   clusters:     - name: kurator-member1       kind: AttachedCluster     - name: kurator-member2       kind: AttachedCluster   plugin:     distributedStorage:       storage:         dataDirHostPath: /var/lib/rook         monitor:           count: 3           labels:             role: MonitorNodeLabel         manager:           count: 2           labels:             role: ManagerNodeLabel在 spec 中，clusters 指明了存储将部署在哪些集群上。在 status 中，plugin 配置下的 distributedStorage 标识此为一个分布式存储插件的安装。此外，dataDirHostPath 定义了存储的路径，而 monitor 和 manager 配置项则指定了 Ceph 组件的参数。🔗 更多的示例和细节，请参考: cid:link_1参考链接统一备份恢复迁移特性介绍: cid:link_6Fleet备份插件安装: cid:link_2统一备份操作指南: cid:link_5统一恢复操作指南: cid:link_3统一迁移操作指南: cid:link_4统一分布式存储操作指南: cid:link_1附：Kurator社区交流地址GitHub地址：cid:link_7Kurator主页：cid:link_8Slack地址: cid:link_0添加社区小助手k8s2222回复Kurator进入技术交流群

在云原生时代浪潮的推动下，Kubernetes的发展日新月异，更新的集群版本可以带来更新的功能，助力用户打造更强大的云原生应用环境。然而，一直以来，如何让用户积极地升级集群版本，是业界公认的一个难题。“我们想用K8s推出的新能力，也想保持整体集群的最新状态。但是我们那么多重要的应用跑在容器上，如何确保我的业务在集群升级过程不受任何影响呢？一旦出现问题，能快速修复吗？”，“我的集群版本比较老，想要升级到最新版本，升级过程可能会很长，担心可能对上层业务会有影响，且影响时长不可控”——这是CCE集群升级团队与用户交流过程中最常听到的几个问题。为此，CCE集群升级团队深入分析并总结了集群升级的痛点问题，主要有以下三个方面：在业务影响方面，传统升级中的替换升级或迁移升级均会导致业务Pod重建，从而影响到业务。在升级稳定性和效率方面，Kubernetes集群系统复杂，影响升级稳定性因素众多；集群版本跨度较大时需要执行多次升级操作，升级时间较久，尤其在大规模集群升级场景，用户感知更为明显。在交互体验方面，用户对升级流程缺乏全局掌控，尤其是升级流程中步骤较多，用户理解成本高。图1 集群升级痛点如何无损、快速、丝滑地升级集群是业界共同的难题。基于上述几个痛点，CCE产品团队从“过程业务无感”、“稳定高效升级”、“丝滑交互体验”等方面入手，打造焕然一新的集群升级体验。过程业务无感传统升级方式主要有节点替换升级和集群迁移升级，两种方式均会导致业务Pod重建，进而影响用户业务。华为云率先推出原地升级能力，只需更新CCE组件版本，节点无需任何变动，对集群中运行的Pod业务无任何影响，从而实现无损升级。同时，原地升级在速度上相比传统升级有大幅提升。图2 传统升级和原地升级对比同时，用户无需关注集群与插件版本的依赖关系，一键式升级将为您自动进行升级适配，省心省力。 此外，如果在升级过程中出现不可预期的情况，可以基于备份为用户实现快速恢复，使用户更容易掌控集群升级。稳定高效升级在升级稳定性提升方面，我们基于华为云上万次的升级经验沉淀，为用户提供了全方位的升级前检查项，检查项涵盖集群、节点、插件和应用、关键组件状态和配置、资源使用等方面，极大程度上为用户规避升级风险，实现稳定升级。同时，备份是业务连续性的重要保证，业界通用的Etcd备份方案存在无法备份集群组件和配置的问题，我们通过采用硬盘快照备份方案不仅为用户提供了完整的集群数据备份能力，且平均备份速度提升近10倍。在升级效率方面，一方面由于Kubernetes社区只兼容相邻小版本，当版本跨度较大时，需要通过多次升级至最新版。我们为用户提供跨版本升级能力，最多支持跨4个大版本进行升级，如v1.23升级至v1.27，有效缩短用户升级路径，节约升级成本；另一方面，升级时间随着在集群规模正增长，我们在保证集群升级安全的前提下，最多支持100节点并发升级，让用户在更短的时间内完成集群节点升级，提高升级效率。图3 简化集群升级路径图4 集群节点并发升级丝滑交互体验在升级引导方面，我们通过引导页面，给用户清晰直观呈现待升级集群的提示消息，让用户不会错过重要的升级通知。图5 集群管理页面集群升级通知为了降低用户理解成本，我们设计了升级小动画为用户阐述原地升级的概念和原理，帮助用户生动直观地了解集群升级流程和注意事项。图6 集群升级动画同时，我们推出了升级路径推荐功能，自动选择最佳的升级路径，并根据升级路径展示本次升级带来的特性更新和优化增强等。图7 升级路径在升级流程中，我们通过可视化的手段为用户详细呈现了升级的进度和异常情况，升级过程一目了然，使用户能掌控升级进度，降低焦虑。图8 升级进度可视化在升级检查异常时，我们基于不同资源汇聚了检查项信息，帮助用户快速查看异常项并提供修复建议，引导用户快速处理问题。图9 升级异常诊断分析在升级完成后，我们会帮助用户进行升级后自动验证，确保升级后的集群正常运行，节省用户时间和精力。图10 自动健康诊断未来愿景欢迎您使用CCE集群升级功能，我们会持续在“过程业务无感”、“稳定高效升级”、“丝滑交互体验”等方面进行持续优化，让集群升级过程更简单、高效和可靠。期待您宝贵的使用意见。服务体验请访问cid:link_4相关链接cid:link_3cid:link_5云容器引擎 CCE

在边缘计算的浪潮中，AI是边缘云乃至分布式云中最重要的应用。随着边缘设备的广泛使用和性能提升，将人工智能相关的部分任务部署到边缘设备已经成为必然趋势。KubeEdge-Ianvs 子项目，作为业界首个分布式协同AI基准测试平台，基于 KubeEdge-Sedna 为算法及服务开发者提供全场景可扩展的分布式协同AI基准测试，以研发、衡量和优化分布式协同AI系统。然而在边缘设备中部署静态的AI模型往往不足以应对复杂多变的真实世界环境，因此终身学习能力对于边缘AI模型来说变得越来越重要。为了方便边缘AI算法研究者开发及测试终身学习算法在真实世界环境中的效果，KubeEdge-Ianvs 在新版本的更新中发布了支持终身学习范式的相关算法的研发与测试功能。本篇文章为大家阐释相关背景和Ianvs终身学习架构，并以 Ianvs 云机器人终身学习测试为例对 Ianvs 终身学习的特性进行介绍。欢迎关注 Ianvs 项目，持续获得第一手独家公开数据集与完善基准测试配套。开源项目GitHub地址：cid:link_4  一、背景  ▍1.1 终身学习能力对边缘模型越来越重要边缘设备所处的环境通常是不稳定的，环境变化会导致数据分布的大幅变化，即数据漂移。数据漂移会显著降低模型准确性。为了解决数据漂移问题，边缘设备需要具备动态更新模型的能力，以适应环境变化。下图展示了一个典型的终身学习算法流程框架。在该框架中，终身学习任务被定义为：已处理 N 个任务，将陆续处理 M 个任务。如何维护知识库并利用其中的模型处理这些任务是关键。终身学习的流程分为四步，首先根据之前已处理的 N 个任务初始化云端的知识库中的已知任务处理模型；然后在遇到新的任务时，从云端知识库中选取合适的模型部署到边缘端处理任务，如果新任务是已知的任务则更新原来的模型，如果遇到了未知任务则重新训练新的模型用于处理该任务；在边缘端处理好该任务后，对云端知识库进行更新；最后遇到新任务时重复前两步操作。通过以上流程可以确保边缘部署的模型具备终身学习的能力，从而可以应对数据漂移等问题带来的影响。▍1.2 业界缺少合适的终身学习测试工具目前终身学习算法相关测试工具发展较慢，目前比较成熟的测试工具只有 ContinualAI 推出的 Avalanche。Avalanche 支持的特性如下：Avalanche 支持的特性非常丰富，但是对于终身学习算法开发者来说 Avalanche 还存在一些局限性：未能覆盖终身学习全生命周期算法：支持的场景主要局限于增量学习等场景，而终身学习中任务定义、分配以及未知任务识别等流程无法体现在该 benchmark中。缺乏配套真实世界数据集：配套的数据集主要包括 Split-MNIST、Cifar10 等学术界常用的玩具测试集，缺乏适用的真实世界数据集及配套算法。研发算法难以落地：Avalanche更多面向终身学习算法的测试实验，并没有考虑未来将算法落地部署的需求。因此目前业界亟需一个更好的终身学习测试 benchmarking 工具，Ianvs 发布的非结构化终身学习新特性可以很好的解决上述问题。  二、lanvs 终身学习架构  ▍2.1 Ianvs 终身学习优势终身学习近年来得到了越来越多的关注，越来越多的边缘智能从业者认识到了终身学习的重要性。但是终身学习相比其他 AI 算法来说有着更高的研究门槛，经过我们的调研发现终身学习研发存在模型训练流程复杂、算法效果难以衡量和算法落地应用困难三大挑战。第一个挑战是终身学习模型训练流程较为复杂，比如对于一个刚入门终身学习的同学来说，可能对终身学习算法流程中的未知任务识别模块比较感兴趣，但是要想完整实现终身学习还需要填补任务定义、任务分配等模块，而这对于刚入门的同学不太友好，想复现别人的工作还需要去额外完成其他终身学习模块。针对这一挑战，KubeEdge-Ianvs 中对终身学习全生命周期的各个模块都进行了设计，包括并不限于任务定义、任务分配、未知任务识别和未知任务处理等多个终身学习核心算法模块，各个模块之间是解耦合的，用户可以只研究自己感兴趣的模块，其他模块采用默认配置即可跑通终身学习实验。第二个挑战是终身学习算法效果衡量困难，不同论文中的终身学习算法由于其测试流程不一样难以比较其工作的优劣。同时大部分论文的工作都是在 MNIST、CIFAR10 这些非真实数据集上进行的实验，由于缺乏在真实世界数据集上的测试，算法在现实世界中的实际应用效果往往要大打折扣。针对这一挑战，KubeEdge-Ianvs 中对终身学习的测试流程进行了统一，提供 BWT、FWT 等公认的终身学习系统指标，方便衡量算法效果。同时 KubeEdge-Ianvs 开源了 Cloud-Robotics 等真实世界终身学习数据集，并配套了对应的运行样例，用户可以直接开箱使用该真实世界数据集测试自己提出的算法的效果。第三个挑战是终身学习算法落地较为困难，算法研发与实际部署之间存在一定鸿沟。用户训练好的模型需要进一步封装才能实际在生产环境上使用。针对这一挑战，KubeEdge-Ianvs 在开发时就考虑到了和其姊妹项目 KubeEdge-Sedna 开源服务平台是配套兼容关系，因此在 KubeEdge-Ianvs上研发的终身学习算法可以直接迁移到 KubeEdge-Sedna平台上实现落地部署，解决了从研发到落地最后一公里的问题。总而言之，Ianvs 终身学习优势包括：覆盖终身学习全生命周期，包括任务定义、任务分配、未知任务识别和未知任务处理等多个模块，各个模块是解耦合的；统一化的测试流程，系统内置权威的终身学习测试指标，并且支持测试结果的可视化；并提供真实世界数据集用于终身学习测试，能更好测试终身学习算法在真实环境的效果；和 KubeEdge-Sedna 终身学习相兼容，研发算法可以快捷迁移到 Sedna 上实现落地部署。▍ 2.2 Ianvs 终身学习新特性Ianvs 在去年发布的 0.1.0 版本中已具备支持单任务学习范式和增量学习范式的算法研发与测试，在新版的 Ianvs 中增加了支持对终身学习范式的相关算法的研发与测试的功能，同时也为终身学习算法测试提供了新的开源数据集。主要新特性如下：特性一：覆盖终身学习全生命周期Ianvs 终身学习具体架构如下图所示，主要包括任务定义、任务分配、未知任务识别和未知任务处理等模块，覆盖终身学习全生命周期。对于已处理任务，Ianvs 通过任务定义模块，将已知任务抽象成若干个模型存储进云端知识库中。在遇到新任务时，Ianvs 首先通过未知任务识别模块判断推理样本属于未知任务还是已知任务。若是已知任务，则从云端知识库中调度对应模型部署在边侧处理该任务，同时基于已知任务样本对模型进行增量更新。若是未知任务，则 Ianvs 通过未知任务处理模块处理该任务，利用外部系统标注并重新训练新的模型用于处理该任务。处理完成后，新的任务模型或是更新后的已知任务模型再重新整合至云端知识库中。为了方便初学者使用 Ianvs，在 Ianvs 仓库中的 examples/robot/ 文件夹下提供了一个可以直接运行的样例cid:link_1 ， 详细的教程在第三节。特性二：统一化的测试流程和真实世界数据集Ianvs 对终身学习测试流程进行了统一，主要参考了 NIPS2017 的论文 “Gradient Episodic Memory for Continual Learning”，复现了其中提出的 BWT 和 FWT 指标，用于评价终身学习算法的抗遗忘能力和未知任务泛化能力。Ianvs 还开源了 Cloud-Robotics 等真实世界数据集，并提供了配套的可以开箱即用的实验代码，帮助用户快速上手 Ianvs 终身学习。数据集官网链接：cid:link_5特性三：支持快捷落地部署如下图所示，Ianvs 中终身学习算法实现的组件与 Sedna 上终身学习算法实现的组件是相兼容的，因此在 Ianvs 上研发测试的算法可以无障碍迁移部署到 Sedna 上，方便相关从业人员实地部署算法。  三、lanvs 终身学习快速教程  在这章中我们通过运行 Ianvs 终身学习的 cloud-robotics 样例向大家讲解 Ianvs 终身学习的基本流程。Ianvs 安装流程以及终身学习更详细的介绍可以参考：Ianvs-lifelong-learning-tutorial相关链接：cid:link_31）首先我们需要配置好 Cloud-Robotics 的数据集，先创建数据集的文件夹，注意如果你把数据集放到别的位置，本教程中的部分路径配置也要一并修改。mkdir /datacd /datamkdir datasetscd datasetsCloud-Robotics 数据集可以根据该数据集专属网站的指示操作获得，链接：cid:link_22）下载完成后解压数据集：unzip cloud-robotics.zip3)配置好数据集后，我们可以准备运行示例代码了。Cloud-Robotics 示例运行的代码放在 /ianvs/project/ianvs/examples/robot/lifelong_learning_bench/ 下，我们首先要配置 python 路径（这里如果 Ianvs 安装位置不一样的话需要更改路径）：export PYTHONPATH=$PYTHONPATH:/ianvs/project/ianvs/examples/robot/lifelong_learning_bench/testalgorithms/rfnet/RFNet4）然后我们检查一下 yaml 文件的信息：5）上图 benchmarkjob.yaml 中 workplace 是存放模型训练输出的路径，可以改成你需要的路径。6）上图 testenv-robot.yaml 中 train_url 和 test_url 是数据集索引的路径，如果你的数据集存放位置和教程不一样，则需要修改 train_url 和 test_url 的路径。7）在上图 rfnet_algorithm.yaml 中可以根据你的需求添加测试的终身学习算法，比如任务定义、任务分配等算法。本样例中提供了一个简单的示例。8）其他的配置文件暂时没有需要调整的。接下来我们就可以运行示例代码了：cd /ianvs/project/ianvs ianvs -f examples/robot/lifelong_learning_bench/benchmarkingjob.yaml 在模型终身学习任务结束后你可以看到以下内容，包括 BWT、FWT 等终身学习系统衡量指标：9）出现以上显示结果，则成功跑通了一个 Ianvs 终身学习样例！如果读者对于本次版本发布的更多细节感兴趣，欢迎查阅 Ianvs v0.2 Release Note：cid:link_0后续 KubeEdge SIG AI 将发布系列文章，陆续具体介绍终身学习全面升级的特性，欢迎各位读者继续关注社区动态。▍相关链接[1] 开源项目GitHub地址：cid:link_4[2] 数据集官网链接：cid:link_5[3] Ianvs 安装流程以及终身学习更详细的介绍链接：cid:link_3[4] Cloud-Robotics 数据集：cid:link_2[5] Ianvs v0.2 Release Note：cid:link_0

中奖结果公示感谢各位小伙伴参与本次活动，欢迎关注华为云DTSE Tech Talk 技术直播更多活动~本次活动获奖名单如下：账号名 奖项名称 奖品名称xj120141121 优质提问 华为云定制保温杯hw081993541 优质提问 华为云定制保温杯hid_oadhx28f7dx7mds 微信抽奖 华为云定制周边好礼hid_5mwsprsnmnfz10k 微信抽奖 华为云定制周边好礼hid_155uke5xwymvo2d 微信抽奖 华为云定制周边好礼hid_nt7cax4_p9ecsrw 微信抽奖 华为云定制周边好礼hw020230876 微信抽奖 华为云定制周边好礼hw081993541 官网抽奖 华为云定制飞盘yizhangl 官网抽奖 华为云定制飞盘

云原生产品技术栈庞大，需要用户对容器、Kubernetes等核心技术都有扎实的理解和掌握；同时问题定位和排查也较为困难，需要用户对不同系统模块原理非常熟悉。这些因素导致云原生产品上手门槛高、配置和运维复杂。为此，华为云云容器引擎CCE产品团队在CCE文档方面进行了重点优化，以降低用户的使用难度：优化文档结构，以便用户更系统地获取所需信息。新增大量实操内容，提供了配置参考，丰富了最佳实践。对已有文档内容进行重构与升级，更新了关键操作指导，确保内容更加易用。新增高质量问答对，实现智能化问答。通过文档服务的全面提升，用户可以更轻松地上手和使用云原生产品，大幅降低难度。结构优化：知识体系完善,学习路径清晰为了帮助用户更直观地获取所需信息，在内容结构上，我们针对用户学习和检索行为对文档目录进行了优化，使用户能够更加清晰了解CCE的学习使用路径。用户可以轻松地跟随这条路径，从入门级别的基础操作指导开始，逐步深入到更高级的管理和运维实践。这种渐进式学习路径帮助用户建立坚实的基础，从而更好地理解和掌握云原生技术。图1 文档目录优化其次，我们加强了文档之间的关联性。每篇文档都与其他相关文档形成了链接，帮助用户在需要的时候能够轻松地跳转到相关主题。 确保用户可以更全面地了解整个云原生技术生态系统。图2 文档关联性增强内容上新：实操案例丰富,满足用户需求CCE文档的内容优化是为了让用户能够在使用CCE时轻松获取所需信息，配置系统并应对各种关键场景。首先，我们引入了一份详尽的CCE配置参考手册，其中列出了各类参数的详细说明，包括集群、节点等各项配置。用户可以在配置手册中找到所需的参数信息，从而更好地理解和掌握系统配置。图3 配置手册此外，我们还新增多篇CCE最佳实践，覆盖了一系列关键场景，如基于容器的CI/CD、应用上云、日志监控等，旨在帮助用户在实际应用中成功地配置和管理云原生环境。用户可以依照这些最佳实践，快速了解如何部署容器应用、将服务迁移到云端以及如何设置有效的日志监控系统。这些实际场景的指导有助于用户将理论知识转化为实际操作，提高技能水平，同时减少配置和部署的复杂性。图4 最佳实践内容重构升级：核心知识更可靠,操作更明确对文档内容进行了重构与升级，更新了关键操作指导，确保内容更加易用。例如我们对容器存储相关文档进行了全面的重构，容器存储是云原生环境中不可或缺的一部分，因为它涉及到应用程序数据的持久性和可靠性。我们重新审视并更新了存储文档，确保其内容涵盖了各种存储解决方案和最佳实践，并将内容从以K8s对象角度更新为存储类型角度组织，使得用户能够更加直观的从使用存储的角度查找并使用文档。图5 存储内容重构升级智能问答增强：用户体验更友好,问题快速解答在CCE文档的智能问答部分，我们新增了超过800条高质量问答对，旨在全面覆盖CCE的常见问题和疑虑。这意味着用户现在可以像与客服交互一样，通过智能问答系统获得即时反馈，无需漫长的搜索或等待。这项改进的好处不仅仅在于提供更快速的解答，还在于增强了文档的互动性和友好度。用户不再需要翻阅大量文档或手动搜索答案，而是可以直接向智能问答系统提问。这种自然语言查询的方式使文档更加与用户互动，打破了传统文档的单向性质。用户可以随时提出问题，获得立即的、个性化的答案，从而提高了文档的实用性和用户体验。图6 智能问答未来愿景华为云CCE致力于为用户提供配置更简单、管理更便捷、流程更透明的容器服务。未来我们将持续打磨CCE的文档使用体验，力争为用户带来更多价值。如果您有任何的建议或意见，可以通过页面下方的反馈意见告知我们，您的任何意见对我们来说都很重要。服务体验请访问https://www.huaweicloud.com/product/cce.html云容器引擎 CCE

Proxyless Service Mesh如何处理服务间的通信和交互？

在云原生容器化浪潮的当下，监控是确保业务稳定性最受关注的问题之一。那么，华为云CCE容器服务又是如何帮助用户提高运维效率呢？半年来，CCE容器服务的运维团队持续拜访用户，并总结用户在云原生运维场景下的痛点问题，主要有以下三大痛点问题：搭建云原生集群监控系统涉及的配置项多，包括集群自身的组件、资源的监控、业务组件的监控等，技术门槛较高。云原生场景下的监控指标涵盖五大类，近数十万项，同时不同类型指标之间相互关联，传统监控难以将这些信息可视化。Promtheus已成为业界云原生监控的事实标准。但开源方案在商用场景下仍存在一些非功能性问题，尤其是海量监控指标带来的高资源消耗，导致成本显著增加。图1 云原生运维的痛点问题基于上述几个痛点，CCE联合AOM服务团队从开箱即用：一键启用容器监控能力、全景观测：多维度全场景监控视图、开源增强：兼容开源Promtheus，全方位能力提升等维度共同打造新一代云原生监控平台，为用户提供更加方便快捷的运维手段。开箱即用：一键启用容器监控能力为了方便用户快速触达监控中心，我们对开启监控中心的步骤进行了极致的简化，并将AOM服务上的监控信息整合到CCE的监控中心。现在，只需前往监控中心一键开启，即可在集群监控中心中查看容器基础资源、Kubernetes资源对象和Kubernetes服务组件的监控指标。图2 创建集群时开通监控中心图3 监控中心一键开通全景观测：多维度全场景监控视图CCE监控中心提供集群内涵盖基础资源、K8s资源对象、K8s服务组件、K8s集群Node、云原生上层业务等五大类，总计近数十万项指标的全景可观测能力，致力打造一站式运维的极致体验。集群健康总览：监控中心首页会呈现整个集群中关键的控制面组件信息、资源占用最高的组件等，能让您对集群的健康情况一目了然。图4 集群健康总览资源健康总览：监控中心提供了节点、工作负载、POD等Kubernetes资源的独立监控页面。资源监控页面中提供资源的基本监控信息，并且能够纵览对应的资源概况，快速发现异常对象。图5 资源健康总览关联资源一屏可见：在监控中心中，在资源监控详情页中能看到关联资源的监控详情，并且可以方便的进行跳转查看（如在看节点监控时可以下钻至节点上的Pod，查看Pod的监控）。图6 资源监控详情页监控大盘：监控中心中提供了丰富的监控大盘，从集群、Node、控制组件等不同的视角呈现集群的健康状态。图7 监控中心仪表盘开源增强：兼容开源Promtheus，全方位能力提升Prometheus是CNCF社区推荐的云原生监控方案，也是业界云原生监控的事实标准，它的服务发现、时序数据等能力能够很好地解决云原生场景下多变、海量数据的问题。同时，Prometheus也是用户使用最多的监控工具。为了更好地符合用户的使用习惯，降低学习成本，CCE提供基于Prometheus开源生态能力的监控组件，兼容Prometheus的开源配置，同时在开源能力基础上对安全、性能、安装部署等方面做了商用增强。在安全上，使用防护能力更强的华为自研的加密算法，对Prometheus使用的敏感信息进行加密；在性能上，一方面对监控指标进行分层管理，满足不同类型用户的监控诉求，另一方面，降低本地存储数据的时效，有效地降低了用户的资源消耗；在安装部署上，需要用户配置的参数由30+优化至0配置一键安装。除此之外，针对Prometheus在海量数据下资源消耗巨大的问题，我们还提供了托管Prometheus+轻量化采集Agent的解决方案，用户侧仅需要负担轻量化采集Agent的资源即可支持海量指标监控，同时大大降低了用户的运维复杂度。我们非常期待本期带来的监控中心能力能够有效地提升您的运维体验，同时我们也会对监控中心进行持续的优化。期待您的使用以及宝贵的改进意见。后续我们还会有其他运维特性的介绍，如告警中心，健康诊断、日志中心等，敬请期待。服务体验请访问cid:link_4相关链接cid:link_3cid:link_5云容器引擎 CCE

云原生已经成为企业应用现代化数字转型的潮流。云原生架构让企业的应用具备了更快的迭代速度、更低的开发复杂度和更好的可扩展性，但是应用应用部署位置不可控 、数量等不断变化的场景让运维复杂度和运维人员的工作量大大增加。相较于传统运维，云原生架构下的运维更加关注监控、日志、事件、告警等数据的自动化采集、可视化呈现和智能化决策。为了提升云原生场景下的运维体验，华为云CCE容器服务带来了新一代的云原生可观测平台，聚焦以下四大能力：监控中心为了解决云原生用户使用监控系统困难的问题，CCE针对多服务组合的复杂场景进行优化，支持一键启用监控中心能力，并提供从容器视角的一站式可视化监控新体验，支持集群、节点、工作负载、Pod等多种维度的监控视图。图1 监控中心告警中心为了解决Prometheus告警语句复杂、不同类别告警源存在多配置入口、基础告警项多导致配置效率低等问题，CCE集群中增加告警中心能力，提供容器告警基于模板的一键配置能力。默认告警规则可有效覆盖集群和容器常见故障场景。图2 告警中心日志中心传统的日志管理系统在云原生场景下存在使用体验割裂、采集配置复杂、日志检索及查看不契合云原生概念模型等问题，为解决上述问题，CCE服务深度集成LTS日志服务能力，推出云原生日志中心，简化了日志采集配置，并提供基于云原生视角的日志管理视图。图3 日志中心健康中心云原生场景下丰富的监控指标、事件、日志能够让用户更加方便定位问题，但是同样也无形中提高了运维人员的技术门槛。为了能够让更多的运维人员能够快速的定位问题，CCE服务提供了健康中心能力，基于华为云容器运维专家经验对集群健康状况进行全面检查，发现集群故障与潜在风险并给出修复建议。图4 健康中心以上就是新一代CCE云原生可观测平台所带来的四大能力。下一篇我们将深入探讨客户在云原生监控上面临的挑战，并着重介绍CCE监控中心如何应对此类挑战，敬请期待。服务体验请访问cid:link_1相关链接cid:link_0cid:link_2云容器引擎CCE

北京时间2023年10月13日，KubeEdge 发布 v1.15.0 版本。新版本新增多个增强功能，在边缘节点管理、边缘应用管理、边缘设备管理等方面均有大幅提升。KubeEdge v1.15.0 新增特性：支持 Windows 边缘节点基于物模型的新版本设备管理 API v1beta1发布承载 DMI 数据面的 Mapper 自定义开发框架 Mapper-Framework 发布支持边缘节点运行静态 Pod支持更多的 Kubernetes 原生插件运行在边缘节点 新特性概览 ▍支持 Windows 边缘节点随着边缘计算应用场景的不断拓展，涉及到的设备类型也越来越多，其中包括很多基于Windows 操作系统的传感器、摄像头和工控设备等，因此新版本的KubeEdge 支持在 Windows 上运行边缘节点，覆盖更多的使用场景。在 v1.15.0 版本中，KubeEdge 支持边缘节点运行在 Windows Server 2019，并且支持 Windows 容器运行在边缘节点上，将 KubeEdge 的使用场景成功拓展到 Windows 生态。Windows 版本的 EdgeCore 配置新增了 windowsPriorityClass 字段，默认为NORMAL_PRIORITY_CLASS。用户可以在 Windows 边缘主机上下载 Windows 版本的 EdgeCore 安装包[1]，解压后执行如下命令即可完成 Windows 边缘节点的注册与接入，用户可以通过在云端执行 kubectl get nodes 确认边缘节点的状态，并管理边缘 Windows 应用。edgecore.exe --defaultconfig > edgecore.yaml edgecore.exe --config edgecore.yaml更多信息可参考：cid:link_3cid:link_4▍基于物模型的新版本设备管理 API v1beta1 发布v1.15.0 版本中，基于物模型的设备管理 API，包括 Device Model 与 Device Instance，从 v1alpha2 升级到了 v1beta1，新增了边缘设备数据处理相关等的配置，北向设备 API 结合南向的 DMI 接口，实现设备数据处理，API 的主要更新包括：Device Model 中按物模型标准新增了设备属性描述、设备属性类型、设备属性取值范围、设备属性单位等字段。// ModelProperty describes an individual device property / attribute like temperature / humidity etc. type ModelProperty struct { // Required: The device property name. 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 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 Instance 中内置的协议配置全部移除，包括 Modbus、Opc-UA、Bluetooth 等。用户可以通过可扩展的 Protocol 配置来设置自己的协议，以实现任何协议的设备接入。Modbus、Opc-UA、Bluetooth 等内置协议的 Mapper 不会从 mappers-go 仓库移除，并且会更新到对应的最新版本，且一直维护。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:"-"` } 在 Device Instance 的设备属性中增加了数据处理的相关配置，包括设备上报频率、收集数据频率、属性是否上报云端、推送到边缘数据库等字段，数据的处理将在 Mapper 中进行。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"` }更多信息可参考：cid:link_5cid:link_6▍承载 DMI 数据面的 Mapper 自定义开发框架 Mapper-Framework 发布v1.15.0 版本中，对 DMI 数据面部分提供了支持，主要承载在南向的 Mapper 开发框架 Mapper-Framework中。Mapper-Framework 提供了全新的 Mapper 自动生成框架，框架中集成了 DMI 设备数据管理（数据面）能力，允许设备在边缘端或云端处理数据，提升了设备数据管理的灵活性。Mapper-Framework 能够自动生成用户的 Mapper 工程，简化用户设计实现 Mapper 的复杂度，提升 Mapper 的开发效率。DMI 设备数据面管理能力支持v1.15.0 版本 DMI 提供了数据面能力的支持，增强边缘端处理设备数据的能力。设备数据在边缘端可以按配置直接被推送至用户数据库或者用户应用，也可以通过云边通道上报至云端，用户也可以通过 API 主动拉取设备数据。设备数据管理方式更加多样化，解决了 Mapper 频繁向云端上报设备数据，易造成云边通信阻塞的问题，能够减轻云边通信的数据量，降低云边通信阻塞的风险。DMI 数据面系统架构如下图所示：Mapper 自动生成框架 Mapper-Frameworkv1.15.0 版本提出全新的 Mapper 自动生成框架 Mapper-Framework。框架中已经集成 Mapper 向云端注册、云端向 Mapper 下发 Device Model 与 Device Instance 配置信息、设备数据传输上报等功能，大大简化用户设计实现 Mapper 的开发工作，便于用户体验 KubeEdge 边缘计算平台带来的云原生设备管理体验。更多信息可参考：cid:link_7▍支持边缘节点运行 Kubernetes 静态 Pod新版本的 KubeEdge 支持了 Kubernetes 原生静态 Pod 能力，与 Kubernetes 中操作方式一致，用户可以在边缘主机的指定目录中，以 JSON 或者 YAML 的形式写入 Pod 的 Manifests 文件，Edged 会监控这个目录下的文件来创建/删除边缘静态 Pod，并在集群中创建镜像 Pod。静态 Pod 默认目录是 /etc/kubeedge/manifests，您也可以通过修改 EdgeCore 配置的 staticPodPath 字段来指定目录。更多信息可参考：cid:link_8▍支持更多的 Kubernetes 原生插件运行在边缘节点v1.15.0 版本的 KubeEdge 支持更多原生插件在边缘节点上运行。KubeEdge 提供了高扩展性的 Kubernetes 原生非资源类 API 透传框架，满足了原生插件对此类 API 的依赖。插件可以从边缘节点的 MetaServer 中获取集群 version 等信息，MetaServer 将对请求进行数据缓存，保证边缘节点网络中断时仍能正常服务。当前框架下，社区开发者将更容易的开放更多非资源类 API。开发者只需关注插件依赖的 API，而不需要考虑请求如何传递至边缘节点。更多信息可参考：cid:link_9▍升级 Kubernetes 依赖到 v1.26新版本将依赖的 Kubernetes 版本升级到 v1.26.7，您可以在云和边缘使用新版本的特性。更多信息可参考：cid:link_10 升级注意事项 新版本 v1beta1 的 Device API不兼容 v1alpha1 版本，如果您需要在 KubeEdge v1.15.0 中使用设备管理特性，您需要更新 Device API 的 yaml 配置。如果您使用 containerd 作为边缘容器运行时，您需要将 containerd 版本升级到 v1.6.0 或者更高版本，KubeEdge v1.15.0 不再支持 containerd 1.5 以及更早的版本。参考：https://kubernetes.io/blog/2022/11/18/upcoming-changes-in-kubernetes-1-26/#cri-api-removal在 KubeEdge v1.14 中，EdgeCore 已经移除了对 dockershim 的支持，边缘运行时仅支持 remote 类型，并且使用 containerd 作为默认运行时。如果您想要继续使用 docker 作为边缘运行时，您需要安装 cri-dockerd，并且在启动 EdgeCore 过程中，设置 runtimeType=remote 以及 remote-runtime-endpoint=unix:///var/run/cri-dockerd.sock。参考：cid:link_2▍致谢感谢 KubeEdge 社区技术指导委员会( TSC )、各 SIG 成员对 v1.15.0 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接[1] Windows 版本 EdgeCore 安装包:cid:link_0[2] Release Notes：cid:link_11/blob/master/CHANGELOG/CHANGELOG-1.15.md  加入KubeEdge社区 KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 : https://kubeedge.ioGitHub地址 : cid:link_11Slack地址 : 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”进入技术交流群

中奖结果公示感谢各位小伙伴参与本次活动，本次活动因问题均与直播间中问题重复，无符合要求内容，故本期无中奖人员。直播简介【直播主题】云原生微服务的下一站：Proxyless Service Mesh【直播时间】2023年10月25日 16:30-18:00【直播专家】杨奕 华为云云原生DTSE技术布道师 李来 华为云云原生DTSE技术布道师【直播简介】云原生微服务治理技术的下一代演进方向是什么？Proxyless Service Mesh! 本期直播讲聚焦于云原生微服务治理技术，介绍了从SOA、微服务SDK到Service Mesh、Proxyless Service Mesh的演进历程，并演示如何基于开源的云原生无代理服务网格Sermant，帮助用户以零代码修改的方式来将SOA架构应用向Proxyless Service Mesh架构进行改造，实现微服务架构的平滑演进和升级。直播链接：cid:link_0活动介绍【互动方式】直播前您可以在本帖留下您疑惑的问题，专家会在直播时为您解答。直播后您可以继续在本帖留言，与专家互动交流。我们会在全部活动结束后对参与互动的用户进行评选。【活动时间】即日起—2023年10月26日【奖励说明】评奖规则：活动1：直播期间在直播间提出与直播内容相关的问题，对专家评选为优质问题的开发者进行奖励。奖品：华为云定制保温杯活动2：在本帖提出与直播内容相关的问题，由专家在所有互动贴中选出最优问题贴的开发者进行奖励。奖品：华为云定制POLO衫更多直播活动直播互动有礼：官网直播间发口令“华为云 DTSE”抽华为云定制飞盘、填写问卷抽华为云定制长袖卫衣等好礼分享问卷有礼 ：邀请5位朋友以上完成问卷即可获得华为云定制帆布袋。老观众专属福利：连续报名并观看DTT直播3期以上抽送华为云DTT定制T恤。【注意事项】1、所有参与活动的问题，如发现为复用他人内容或直播间中重复内容，则取消获奖资格。2、为保证您顺利领取活动奖品，请您在活动公示奖项后2个工作日内私信提前填写奖品收货信息，如您没有填写，视为自动放弃奖励。3、活动奖项公示时间截止2023年10月27日，如未反馈邮寄信息视为弃奖。本次活动奖品将于奖项公示后30个工作日内统一发出，请您耐心等待。4、活动期间同类子活动每个ID（同一姓名/电话/收货地址）只能获奖一次，若重复则中奖资格顺延至下一位合格开发者，仅一次顺延。5、如活动奖品出现没有库存的情况，华为云工作人员将会替换等价值的奖品，获奖者不同意此规则视为放弃奖品。6、其他事宜请参考【华为云社区常规活动规则】。

1、全球化布局：华为云在全球范围内覆盖了200多个国家和地区的数据中心，为全球用户提供服务。这意味着无论你在哪个国家或地区，华为云都能满足你的云计算需求。华为云还建成了全球最大规模的鲲鹏云服务器生态系统，为用户提供了更加可靠、高效的服务。 2、多样化的云服务：华为云提供了数十项云服务，包括计算、存储、网络、数据库、安全、人工智能等。这使得华为云能够满足各类客户的需求，从个人用户到企业客户，从初创企业到大型企业，都可以在华为云找到适合自己的解决方案。 3、全面的安全保障：华为云具有全面的安全体系和多层次的安全保障措施，包括网络安全、数据安全、身份认证、合规管理等，可以为客户提供全方位的安全保障。此外，华为云还获得了41项全球合规认证，这也是用户选择华为云的重要原因之一。

在容器化日益成为中大型企业上云主流选择的情况下，容器服务如何能帮助用户更简单快捷的上云、高效可信赖的运维？为了更好的解决这个问题，CCE用户体验团队在今年进行了大量的用户现场调研，聆听用户的声音。围绕行业普遍存在的配置复杂门槛高、运维信息分散效率低、升级难度大等问题打造全新CCE体验，提出“易用：一站式集群配置，开箱即用”、“场景化：聚焦用户场景，无跳出运维管理”和“透明化：所见即所得，将复杂的过程透明化”的设计理念，同时融合了华为云全新设计语言，为用户打造集群开箱即用、异常快速高效定位、任务透明可信赖的容器化上云体验。图1 容器化体验改进为了持续提供更好的产品体验，我们非常期待您对CCE产品的评价，如果您有任何的建议，欢迎通过页面底部的“意见反馈”向我们反馈，我们会认真听取您的宝贵建议。设计语言焕新升级CCE服务控制台应用了华为云全新的设计语言，这套设计语言的核心特点是更加贴近用户使用感知、着力提升用户使用友好性、降低使用难度，围绕用户关注点构建信息展现结构，构建更加友好、便捷的使用体验。直观、聚焦：关键信息抽取，同时减少页面复杂色，清晰直观，希望可以帮助用户更聚焦重点。图2 集群列表优化场景化：基于用户实际场景的有效信息汇聚，无需跨服务跳页面。图3 云原生观测优化易用：一站式集群配置，开箱即用不少用户反馈容器技术门槛相对较高，很多繁杂的配置用户自行摸索起来，效率低。日志等一些服务的开通和使用，需要到不同的服务里多次跳转等。针对这些复杂的配置问题，我们推出配置中心。在配置中心里，将配置项进行分类，方便用户统一管理同一类型配置。针对具体的配置项，我们提供配置解释、配置建议、给出配置风险，帮助用户“自己搞定”配置。图4 配置中心优化在运维管理上，我们推出云原生观测中心，实现运维管理的开箱即用。云原生观测中心将监控、日志服务集成进CCE服务，用户可以在CCE的页面内完成监控、日志的一键开通，并且在使用过程也不需要跳出CCE服务。图5 日志管理优化场景化：聚焦用户场景，无跳出运维管理在实地拜访中，我们发现工程师近80%的工作场景都在进行运维相关的工作。而之前CCE提供的是基础的监控能力，用户需要跳转去应用运维管理服务，查看详细监控和告警。围绕查看监控、告警的场景，我们希望用户能更聚焦对应的资源对象，我们提出“以应用为中心，构筑端到端的一站式运维体验”的设计理念。围绕集群、节点、负载和Pod，我们提供融合了资源健康度和监控的独立运维页面，方便用户聚焦关注的资源。用户在一个页面即可快速评估资源健康度和异常项，同时查看各层级完成监控。图6 监控中心优化围绕告警，CCE集成了应用运维管理的告警通知和告警规则、消息通知服务的联系人管理，用户无需跳转，即可在CCE快速查看处理告警和进行配置。图7 告警中心优化透明化：所见即所得、将复杂的过程透明化像集群升级等关键操作，具体变更点及影响相对模糊，容易引起用户顾虑。对于此类操作，我们通过信息预先告知、过程可视可回退等设计理念，让用户有充分的知情权和掌控感，降低用户顾虑。以集群升级为例，由于用户未清晰感知相关原理和可能存在的影响，升级过程不感知进度细节，不敢轻易升级。本次优化中，我们通过可视化等手段预先为用户呈现讲解原地升级的概念和原理，告知用户升级对插件等功能的影响，降低用户顾虑。图8 集群升级流程展示图9 集群升级插件影响同时对于升级过程，如升级检查，拓扑图形式呈现检查过程，用户可感知资源视角的进度和异常情况。图10 集群升级过程可视化对于升级过程，用户如果遇到异常，可以随时调出伴随式监控，辅助定位问题，无需跳转查看监控。图11 集群升级过程监控未来愿景华为云CCE致力于为用户提供配置更简单、管理更便捷、流程更透明的容器服务。未来我们将持续打磨CCE的使用体验，力争为用户带来更多价值。如果您有任何的建议或意见，可以通过页面下方的反馈意见告知我们，您的任何意见对我们来说都很重要。

如图所示，您好，关于MDC300摄像头适配相关，我还有一些问题想请教一下：                                                                                         1.请问支持的摄像头里是用的MAX96717F作为相机的解串器2.我们是2022年购买的该产品，请问现在有没有适配新的摄像头厂商列表，新的列表里是否支持豪威 OX03C10 CMOS传感器3.根据上图这款相机参数表，能不能提供适配或者给出适配方法期待您的解答，万分感谢！

华为云云容器引擎（Cloud Container Engine，简称CCE）服务Kubernetes版本支持策略将进行优化，从Kubernetes 1.27版本开始，CCE将对每个社区版本均提供商用支持。CCE集群1.27版本计划于2023年10月正式商用，CCE集群1.28版本计划于2023年12月支持。图1 版本支持策略升级CCE 提供高度可扩展的、高性能的企业级Kubernetes集群。借助云容器引擎，您可以在华为云上轻松部署、管理和扩展容器化应用程序。服务体验请访问：cid:link_0云容器引擎CCE