沙箱隔离技术是一种将进程有效隔离到独立环境中运行的技术。随着容器技术的兴起，沙箱隔离技术也在云原生领域中得到了广泛的应用。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

云原生产品技术栈庞大，需要用户对容器、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

在云原生容器化浪潮的当下，监控是确保业务稳定性最受关注的问题之一。那么，华为云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”进入技术交流群

在容器化日益成为中大型企业上云主流选择的情况下，容器服务如何能帮助用户更简单快捷的上云、高效可信赖的运维？为了更好的解决这个问题，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的使用体验，力争为用户带来更多价值。如果您有任何的建议或意见，可以通过页面下方的反馈意见告知我们，您的任何意见对我们来说都很重要。

华为云云容器引擎（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

作者：华为云云原生团队随着业务的全球化发展和应用多元化部署的趋势，越来越多的客户选择通过混合云、多云模式来进行业务部署。选择多云进行部署可以提高部署业务的基础设施稳定性，在单个供应商基础设施出现故障或者访问流量激增时，可以通过配置跨云弹性来提高业务的高可用性，同时，多云还可以避免企业的技术架构被厂商锁定。尽管使用多云的优点很多，但管理多云集群和在多云的场景下发布应用却面临诸多问题和挑战。多云场景下集群管理和应用交付的挑战1、多集群基础设施的管理及一致性发布面临的挑战。例如，在多集群场景下的网络策略的配置，TLS证书的发布及更新管理。在现代应用程序的部署步骤中，SSL/TLS证书是很重要的一环。但在部署应用程序时，管理证书的续订通常是事后才想到的。证书的生命周期从90天到13个月不等，为了保持安全访问，这些证书需要在到期前更新/重新颁发。鉴于大多数 Ops 团队工作繁杂，证书更新有时会被遗漏，这会导致应用间不能正常访问和工作。在多集群场景下，运维团队会每个供应商集群重复上述过程进行证书更新；而通过 GitOps 结合 Cert-manager[1]、Nginx Ingress Controller 可以一致的、统一的管理证书的自动化更新[2]，大大提升 Ops 团队的运维管理效率 。2、由业务场景侧需求和集群基础设施差异性带来的差异化配置挑战。根据应用程序的业务场景诉求不同，不同集群部署的业务版本，更新频率会存在不同。例如同一餐厅在不同地域的点餐系统可供给的菜单种类，菜单上新会有差异；或由于跨国公司在不同国家推广策略不同，新的业务软件仅需要部署至部分城市所在集群等。同时，由于业务部署的基础设施不同，应用程序部署到集群的底层架构、网络连接性、计算存储性能表现可能多种多样。例如同一份应用配置在被差异化渲染后可以被交付和托管在云上的CCE、EKS集群、客户本地数据中心中的集群（存在断连情况）、边缘端无人机的集群上（半连接集群）以及太空中卫星链所组成的集群（短时连接集群）。因此根据每个集群的性能指标（CPU、Memory）不同，部署业务应用的实例副本数可能会不同；根据每个集群的网络连接情况不同，设置部署业务的版本更新周期，高可用设置（访问某个服务的超时重试次数等）会产生差异；根据每个集群的使用目的不同（早期生命周期阶段的集群通常由开发人员管理，而实际的预发及生产集群的可能由客户的运维团队管理），部署业务的版本和数据库连接池等变量也会存在差异。因此当有M个应用需要交付至N个集群环境中时，差异化配置的复杂度会呈M×N维度爆炸增长。3、使用 UI 控制台方式交付应用与各厂商控制台风格各异、难以编排大规模微服务交付之间的挑战。随着微服务规模变大，依赖UI控制台进行应用交付的方式变得复杂臃肿，其交付的顺序编排依赖人工，无法做到自动化；且无法进行审计和版本控制。4、缺乏统一的应用观测视角的挑战。在多云集群场景下，当前缺乏统一的视图帮助客户查看应用在多集群的部署情况、应用的健康状态及异常状态定位。   使用UCS GitOps配置管理来交付您的多云应用     为了应对上述多云集群管理和多云应用交付的挑战，UCS 推出了基于 GitOps 理念的跨集群配置管理和应用分发的功能。通过它你可以屏蔽底层环境差异和多个管理入口，将多个集群环境的配置和治理集中于一处，以自动化的体验完成多集群基础设施的管理以及多云应用的发布及更新。GitOps 的概念最早由 Weaveworks 公司于2017年提出，指具备版本控制、拉取和合入请求能力、具备CI/CD流水线发布能力的基础设施即代码（Infrastructure as Code, IaC），是一种云原生的持续交付模型。如图1所示，它的核心是使用 Git 仓库来管理基础设施和应用的配置，并且以 Git 仓库作为更改基础设施和应用的单一事实来源，用户从其他地方（例如集群控制台或者命令行）修改的配置均会被修正。Git 仓库中的声明式配置描述了目标环境当前所需基础设施的期望状态，借助 GitOps 能力，当集群中的实际运行的配置或应用状态与 Git 仓库中定义的期望状态不匹配时，Kubernetes Reconcilers 会根据期望状态来调整当前的状态，最终使实际状态与期望状态保持一致[3]。图1：GitOps Operator 运行方式基于上述的思想和技术路线，CNCF 开源社区从17年开始至今，涌现出很多火热的持续交付项目，他们以Flux、ArgoCD等CNCF毕业项目为代表，可以将用户配置在代码仓库中的Kubernetes Manifast（Deployment、Service等Yaml文件）、Helm Chart、Kustomize、Ksonnet、Jsonnet 定义和组织的应用以自动化的方式部署、将配置变化更改到应用程序的运行时环境。UCS 的配置管理功能当前采用 Flux2 作为技术内核，并将其与 UCS 的容器舰队、集群模型进行适配。它通过简单易用的 UI 提供对华为云集群、多云集群、本地集群、附着集群和伙伴云集群进行跨命名空间、跨集群的应用分发与配置管理的能力，并在观测面板中对配置的实时状态的进行收集和展示。用户还可以将它对接到CI流水线后面，实现多云应用的 CI/CD 流水线的集成和发布。当前UCS提供如下关键能力，帮助用户实现便捷的多云交付。2.1 开箱即用的GitOps引擎，兼容主流的开源生态和体验图2：Flux2 主要组件的运行原理UCS 会为每个开启 GitOps 引擎的集群安装一个稳定开源版本的 Flux2 组件，且用户无须运维 GitOps 引擎。每个集群中的 GitOps 引擎会以Pull模式、定周期监听和拉取最新的仓库源配置信息并把最新的配置信息及时同步至集群中。如图2所示：Source-Controller 主要负责监视 Git 仓库源、Bucket 对象存储桶以及 Helm 仓库的存储配置变化，然后把最新 Commit 记录的制品包拉取至集群本地。而 Kustomize-Controller 和 Helm-Controller 则会负责监听集群本地拉取制品变化情况，其中以 Helm Chart/Helm Release 类型定义的制品会交由 Helm-Controller 进行渲染和同步至集群中；同理，按照 Kustomize 方式进行组织的制品交由 Kustomize-Controller 进行渲染和同步至集群中。2.2 丰富的多集群差异化配置能力随着部署应用的规模越来越大，部署集群的底层差异性越来越大，我们发现单一的一份配置对应一个集群的模式会变的越来繁琐和难以维护，因此面向多个集群的差异化配置策略随之出现。UCS 配置管理功能提供了两种多集群差异化配置的策略: Kustomize 和 Helm Release。Kustomize 是一个 Kubernetes 应用程序配置管理工具，它提供一种简单灵活的方式来生成 Kubernetes 资源，并可以使得这些资源在不同的环境中用不同的方式进行配置[4]。如图3所示，Kustomize 策略在 Base 目录下定义所有集群公共部署资源，然后在 Overlay 目录下描述每个集群产生差异化覆盖参数。然后在部署阶段，通过动态渲染参数将最终版本的制品交付至目标集群中。图3：Kustomize 制品组织目录示意图同理，HelmRelease 也是参考上述思路。将公共定义的资源放置在 templates 目录下，然后结合 valuesFrom/valuesFiles 等方式从 value.yaml 读取每个环境的差异化参数，满足客户差异化的配置诉求。其配置的重点在于做好定义公共部分抽象和少数变量的差异化配置，对应用本身参数属性和运维参数进行分离，减少重复编辑和维护的成本。2.3 基于Git的可审计、可持续的部署能力UCS 配置管理将 Git 仓库中最新合入的制品配置信息同步部署至纳管的多个集群中，同时对应用发布行为进行版本化管理和权限控制，提供发布回滚和版本迭代控制，并进行审计跟踪。 基于UCS GitOps+Pipeline流水线构建多云DevOps解决方案 随着 DevOps 价值观和文化的流行，越来越多的公司选择帮助开发团队分担应用程序交付的责任，他们将多云环境下的交付交给专门的运维团队来完成，让开发团队可以更加专注于应用程序的开发和构建本身[5,6]。基于 UCS GitOps+Pipeline 流水线可构建多云DevOps 的解决方案，实现多云环境下多云应用构建和发布。开发团队和运维团队可以基于 Git 工作流，将现有流程对接到华为云 CodeArts Pipeline 流水线或者企业自建的 CI/CD 流水线之上，从而拥有多云应用的业务开发、集成、测试再到多云应用的部署—全流程 DevOps 体验。具体来讲将分为以下两个阶段：1、定义和构建多云应用：开发团队进行业务的开发、测试、验证、打包软件和生成镜像。这里可以是采用华为云官方的 CodeArts Pipeline 流水线或者用户自建的 CI 流水线。然后定义每个集群交付资源的原始制品文件。2、交付多云应用：运维团队首先会根据开发团队提供的原始制品文件对部署在多个集群环境中的差异化内容进行配置。此环节需要做好定义公共部分抽象和少数变量的差异化配置，对应用本身参数属性和运维参数进行分离，减少重复编辑和维护参数的成本。然后使用 UCS GitOps 统一初始化集群所需的环境和资源，对发布步骤进行编排，通过更新配置仓库来一致的对多个集群进行自动化应用发布；同时运维团队还对应用发布行为进行版本化管理、权限控制和审计，提供发布回滚和版本迭代控制，保证业务应用的成功部署。图4：结合UCS GitOps的多云DevOps流水线下面将以一个详细的例子来解释：华为云某亚太跨国公司客户需要统一管理横跨多国的 Kubernetes 集群和进行业务发布，他们的线上商城业务应用同时运行在Hong Kong 的华为云 CCE 集群中，新加坡的亚马逊云 EKS 集群中；并且他们在马来西亚还拥有一部分自建数据中心集群供开发团队进行业务开发和测试验证。由于每个国家消费者的商品喜好差异以及当地的供应链供给不同，商城中发布的商品类别会存在差异。在原有的交付流程中，运维团队会根据每个地域的供应商集群控制面板风格、部署业务版本，业务更新频率等因素，为每个环境单独构建一条流水线独立交付；并在每次发布版本前，运维团队会与开发团队就新版本特点和每条流水线的部署细节进行详细磋商。而使用 UCS GitOps 可以大大降低交付上述流程的复杂度，如图4的解决方案中所示，客户采用多套环境共享一套 CI 流水线，并将构建的产物统一推送至华为云Hong Kong 的SWR 镜像仓库。然后通过差异化配置不同环境的部署参数，将多个环境的发布对接到华为云 CodeArts 配置仓库，实现了从本地集群测试和验证到多个生产集群的发布的无缝切换，也极大的提升了他们多云交付的效率。总结综上所述，UCS GitOps 是以 Flux2 为技术内核，将其与 UCS 的容器舰队/集群模型进行适配的多云交付平台。它通过简单易用的 UI 提供对华为云集群、多云集群、本地集群、附着集群和伙伴云集群进行跨命名空间、跨集群的应用分发与配置管理的能力，并在观测面板中对配置的实时状态进行收集和展示。它可以帮助您将多个集群环境的配置和治理集中于一处，以自动化的体验完成多集群基础设施的管理以及多云应用的发布及更新。同时 UCS 会持续关注开源社区侧多集群 GitOps 的发展趋势，并将优质特性采纳为产品的内核。在后续的版本迭代中，下列特性将会逐步支持：1、容器舰队级别的配置分发：通过对舰队内部集群进行标签化管理，完成舰队视角下应用的一键分发和统一管理。2、全面对接华为云 CodeArts Pipeline：提供全流程、更好融合体验的多云 DevOps 流水线。3、在界面中提供对接三方消息系统的应用发布状态感知能力：一方面处理来自外部系统（GitHub、Bitbucket、Harbor、Jenkins）的事件，然后通知 GitOps Toolkit 控制器有关源更改的信息；另一方面处理由 GitOps Toolkit 控制器发出的事件，然后根据事件的严重性和涉及的对象将它们转发至外部系统（Slack、Microsoft Teams、Discord、Rocker）。参考资料在 Kubernetes 环境中自动化证书管理 https://www.nginx.com/blog/automating-certificate-management-in-a-kubernetes-environment 使用 Flux 管理多集群基础设施 cid:link_0Codefresh Continuous Delivery for Kubernetes使用 Kustomize 对 Kubernetes 对象进行声明式管理  https://kubernetes.io/zh-cn/docs/tasks/manage-kubernetes-objects/kustomization/Enterprise CI CD Best PracticesGitOps-2.0 The Future of DevOps Ebook v4 

由 Istio 社区指导委员会成员和华为云云原生团队联合编著的云原生服务网格书籍《 Istio 权威指南》重磅上市！《 Istio 权威指南》包含云原生服务网格原理、实践、架构、源码四大技术篇章，内容权威、系统、详实， 凝聚华为云云原生团队在 Istio 社区及产品领域耕耘多年的长期实践和宝贵经验。华为云 CTO、CNCF CTO 联合作序，Istio 社区技术委员会（ TOC ）资深成员强力推荐。Istio服务网格是 CNCF（ Cloud-Native Computing Foundation，云原生计算基金会）定义的云原生技术的典型代表之一，向下与提供资源、运行环境结合，构建了一个懂应用、对应用更友好的基础设施，帮助下层基础设施感知上层应用，更有效地发挥资源的效能；向上以非侵入的方式提供面向应用的韧性、安全、动态路由、调用链、拓扑等应用管理和运维能力。作为服务网格技术中最具影响力的项目，Istio 从诞生之初就获得了技术圈和产业界的极大关注。CNCF 这几年的调查报告显示，Istio 一直是生产环境下最受欢迎和使用最多的服务网格。2022 年 9 月，CNCF正式接受 Istio 成为孵化项目，推动 Istio 与 Envoy 项目的紧密协作，一起构建云原生应用流量管理的技术栈，也将进一步促进 Istio 成为应用流量治理领域的事实标准。根据 Istio 官方的统计，Istio 项目已有 8800 名个人贡献者，超过 260 个版本，并有来自 15 家公司的 85 名维护者，可见Istio在技术圈和产业圈都获得了极大的关注和认可。两次年度 IstioCon活动每次都吸引了超过 4000 人参加。华为云云原生团队成员入选了每届Istio社区指导委员会，当前有 2 名指导委员会成员（全球仅 8 家公司 13 人），参与Istio社区的重大技术决策，持续引领了Istio项目和服务网格技术的发展。另外Maintainer 2 名，Member 10+ 名，Pull Request 位于全球TOP 3，中国第一，Contributions TOP 3（2.3w+）。《 Istio 权威指南》简介《 Istio 权威指南》由华为云云原生团队出品,旨在打造业界最系统权威的 Istio  图书。书籍分为上、下两册，上册包括原理篇、实践篇；下册包括架构篇和源码篇，总计 26 章。▍原理篇 1～7 章介绍 Istio 的相关概念、原理，并详解 Istio 丰富的流量治理、可观测性、安全等方面的原理、机制和用法细节。▍实践篇 8～14 章基于一个统一用例实践 Istio 的流量治理、灰度、韧性、安全、可观测性、多基础设施、网关等典型应用。▍架构篇 15～20 章从架构的视角详解 Istio 各控制面组件和数据面组件的设计思想、数据模型和核心工作流程。▍源码篇 21～26 章从代码的视角详解 Istio 各控制组件面和数据面组件的代码结构、代码流程和关键代码片段。书籍特色1. 权威详实内容获 Istio 社区和 Istio TOC Lin Sun 和 John Howard 代表 Istio 社区强力推荐《 Istio 权威指南》基于 Istio 最新版本和架构，通过 4 篇、26 章、近 1000 页的篇幅，全面、系统、详细、深入地解析 Istio 原理、用法、实践、架构和源码。能帮助读者从多个维度理解云原生、服务网格、Istio 等相关技术，掌握基于 Istio 实现应用流量管理、零信任安全、应用可观测性等能力的相关原理与实践。Istio 社区最资深权威的两位 TOC 委员 Lin Sun 和 John Howard 代表Istio 社区推荐书籍的权威、系统的内容，建议初学者、云原生技术专家或 Istio 社区的贡献者均可阅读、参考。2.450+ 详实原创图表解析关键原理、架构、模型和代码流程，归纳易错技术点全书运用 450+ 原创图表多维度洞察、归纳、总结Istio原理、架构、流程和易错技术要点。践行了作者著书的理念不是搬运知识，而是将自己的实际的经验总结和提炼出来，由浅入深地帮助广大从业者学习服务网格的机制，掌握Istio的用法，特别是帮助从业者理解其中容易出错，最难理解的技术细节。如图书第4章可观测性中详细介绍了Istio访问日志的内容，特别剖析了 6 个重要的可以帮助运维人员识别一个请求通过服务网格数据面的每个阶段的耗时细节、定位耗时的瓶颈时间段。考虑到大多数从业者很容易混淆这几个个时间段的细微的差别，特提供了图4-26展示了代理观测记录每个时间段的起始时间点和终止时间点。并通过表4-4对每个时间字段进行了解析。这种通过原创的细致入微的图、表和文字结合的立体表达详解易错核心技术点的方式，获得了Istio TOC成员， Director of Open Source at Solo.io Lin Sun的赞誉和强烈推荐。▲ 图4-26  访问日志中的重要时间字段解析▼ 表4-4  访问日志中的重要时间字段解析3.国内首本系统详细解析 Istio 和 Envoy 架构和源码的技术书籍，Istio 和Envoy 社区核心维护者周礼赞强力推荐此外当前服务网格的使用越来越普及，国内甚至业界介绍服务网格控制面的资料书籍已经慢慢丰富起来，但是详细介绍架构和源码实现的书籍，特别是网格数据面的资料一直较少。很多从业朋友反映业务进入深水区后网格数据面知识的欠缺阻碍了其日常的工作的开展和生产中问题定位定界。《 Istio 权威指南》下册着重介绍 Istio 的架构与源码，特别规划了4章系统详细地解析 Istio-proxy 和 Envoy 架构和源码。书籍的详实内容获得 Istio 和 Envoy 社区核心维护者周礼赞强力推荐。4. 大量原创实践内容覆盖典型应用和常见疑难问题，指导客户解决生产问题《 Istio 权威指南》内容源于华为云云原生团队在 Istio 社区及产品领域耕耘多年的长期工程实践、客户实际案例的宝贵经验积累。在全面系统、深入介绍 Istio 原理、架构的同时，更注重内容对读者具体工作的实用价值。本书规划了独立的实践篇涵盖 Istio 的典型的流量、安全和可观测性实践案例。另外，近些年用户深入使用 Istio 的过程中，访问日志的应答标记的含义对大部分资深使用者造成困扰，但是国内外的资料包括社区官方都很简单，只是一般性的简单描述。上册附录规划了原创的访问日志实践，涵盖了大部分 Istio 访问日志中典型应答标记的实际案例，帮助读者理解其用法。此外下册附录规划了多个华为云云原生团队生产中积累的有借鉴意义的疑难案例，帮助读者参照解决实际工作中碰到的类似问题。5. 华为云 CTO、CNCF CTO、信通院、IEEE/CCF Fellow 等顶级领域专家推荐《 Istio 权威指南》目标成为 Istio 技术的权威、系统的技术书籍，持续帮助读者朋友学习了解 Istio ，解答大家使用 Istio 中的具体问题，推动云原生技术的发展。该目标和成果得到了华为云 CTO 张宇昕、CNCF CTO Chris Aniszczyk 的大力支持，二位 CTO 为《 Istio 权威指南》联合作序，倾力推荐。中国信通院云计算与大数据研究所何宝宏所长、上海交通大学致远讲席教授IEEE/CCF Fellow 过敏意老师、CNCF 中国区总监  Keith Chan、华为云首席产品官方国伟分别结合研究所、学术界、CNCF和产业界的背景和技术趋势表达了对Istio和其所属的服务网格技术的观点，也给出了读者使用本书的建议 。6. Istio 社区和华为云产品专家联合出品《 Istio 权威指南》由 Istio 社区亚洲唯一的从首届至今的指导委员会成员、国内最早的 Istio 商用网格服务开发团队成员联合出品，内容涵盖 Istio 的原理、实践、架构与源码。内容来源于作者在 Istio 社区设计开发大颗粒功能的经验总结，结合华为云云原生团队在云服务开发、客户解决方案构建、生产环境运维等日常工作中的实践、思考和总结，打造国内最权威、系统、详实、实用的Istio书籍。图书是《云原生服务网格 Istio 原理、实践、架构与源码解析》核心作者张超盟、徐中虎又一力作 。作者简介张超盟华为云应用服务网格架构师，先后负责过华为云容器应用运维、微服务平台、云服务目录、云服务可靠性、服务网格等云原生产品的架构设计与开发工作，主导过多个重大项目的云原生和微服务化生产落地。在服务网格、Kubernetes容器服务、微服务架构、应用性能管理、大数据、DevOps工具等方面有深入的研究与实践。Istio社区成员，KubeCon、IstioCon及ServiceMeshCon等会议的演讲者，技术图书作者。早期曾在中铁一局从事路桥建设工作。徐中虎华为云云原生团队核心成员，开源技术专家，服务网格Istio核心维护者，Istio社区指导委员会成员，Kubernetes项目核心贡献者，批量计算项目Volcano的核心维护者，拥有丰富的开源工作经验。主要研究方向有微服务架构、服务网格、容器编排平台Kubernetes和未来的分布式云原生架构等。在分布式系统的性能优化、高可靠和可扩展方面研究深入、经验丰富。张伟华为云服务网格数据面资深专家，拥有18年架构设计与开发经验，先后就职于亿阳信通、加拿大北电网络（中国）、甲骨文、Polycom、阿里巴巴及华为等公司。作为核心开发人员开发过传输网管系统、Tuxedo交易中间件、ts-server多媒体转码服务、GTS高性能事务云服务、sc高性能注册中心、ASM数据面等多个产品，现主要负责华为云ASM服务网格数据面代理产品的设计与开发工作。冷雪西安电子科技大学杭州研究院菁英副教授，浙江大学工学博士。主要研究方向有云原生安全、性能优化和智能运维等，致力于解决云网环境下的关键问题。曾参与并主持多项科研项目，在国际顶级会议和期刊上发表多篇论文并获得多项授权专利。我们衷心地希望书中的内容能对您和您日常工作带来帮助，也很期待有机会就其中的内容和您进行技术交流。假如你需要更深入地学习服务网格及云原生相关技术，欢迎关注我们的容器魔方公众号（参见本书封面），一起学习并讨论服务网格及云原生领域最新的技术进展。行业权威著作，云原生服务网格从业白皮书华为云、CNCF CTO联合作序——华为云CTO  张宇昕《 Istio 权威指南》来源于华为云云原生团队在云服务开发、客户解决方案构建、Istio社区特性开发、生产环境运维等日常工作中的实践、思考和总结，旨在帮助技术圈的更多朋友由浅入深且系统地理解 Istio 的原理、实践、架构与源码。书中内容在描述 Istio 的功能和机制的同时，运用了大量的图表总结，并深入解析其中的概念和技术点，可以帮助读者从多个维度理解云原生、服务网格等相关技术，掌握基于 Istio 实现应用流量管理、零信任安全、应用可观测性等能力的相关实践。无论是初学者，还是对服务网格有一定了解的用户，都可以通过本书获取自己需要的信息。——CNCF CTO  Chris Aniszczyk本书提供了全面且实用的 Istio 指南，涵盖了 Istio 的核心概念、特性和对 xDS 协议等主题的深入探讨，还包括对 Envoy 和 Istio 项目源码的深入解析，这对潜在贡献者非常有用。无论您是软件工程师、SRE 还是云原生开发人员，本书都将为您提供利用 Envoy 和 Istio 构建可扩展和安全的云原生应用所需的知识和技能。行业大咖倾力推荐——中国信通院云计算与大数据研究所所长 何宝宏服务网格作为一种管理服务间通信的核心技术，为服务间的调用带来了便捷且可靠的流量、安全和可观测性等能力。中国信通院作为ICT领域的国家智库，率先牵头制定了服务网格相关标准。华为作为云原生领域的中坚力量，在该标准的编写过程中发挥了重要作用。《Istio权威指南》作为关于服务网格的专业技术书籍，对国内云原生技术的普及和发展将起到极大的促进作用。——上海交通大学致远讲席教授、国家杰青、IEEE/CCF Fellow 过敏意云原生技术已经成为产业界和学术界共同关注的热点之一。Istio作为一种集成了流量、安全和可观测性等能力的透明服务治理平台，有效推动了服务网格在云生产环境下的应用和普及。《Istio权威指南》作为服务网格领域的权威书籍，凝聚了华为云云原生团队长期积累的丰富经验，深入浅出地对Istio相关技术进行了详尽解读，值得相关从业者、技术爱好者和学术研究者阅读、参考。——CNCF中国区总监、Linux Foundation亚太区战略总监Keith ChanIstio一直是云原生领域非常流行的开源项目，是CNCF组织的各类会议上的热门话题。华为一直是云原生开源活动的积极参与者，在Kubernetes和Istio等项目中都有着突出的贡献。《Istio权威指南》由华为云云原生团队倾力打造而成，其理论结合实践，深度剖析了Istio的原理、实践、架构与源码，对于企业面向云原生架构转型及践行服务网格落地都有很大的参考意义。——华为云首席产品官 方国伟云原生极大地提高了企业应用生产力，缩短了应用的上市时间，降低了应用上云的门槛。服务网格作为云原生技术栈中的关键技术之一，可以帮助用户打造“以应用为中心”的云原生基础设施。《Istio权威指南》作为系统介绍服务网格技术Istio的权威书籍，来源于在Istio社区及产品领域耕耘多年的华为云云原生团队的长期工程实践和宝贵经验积累，值得广大云原生技术爱好者阅读、参考。——Istio TOC Member、Director of Open Source at Solo.io Lin SunIstio是当今生产环境下非常流行、部署非常广泛的服务网格技术。如果您已经了解Istio并想从基本概念、API、架构、各组件的源码等方面深入研究Istio，那么《Istio权威指南》适合您阅读。本书是非常实用且有深度的Istio书籍，其涵盖的Istio组件工作流和图表的深度给我留下了特别深刻的印象。希望您喜欢本书，我代表Istio社区祝您学习Istio愉快！——Istio TOC Member、Istio SC Member、Google Staff Engineer John Howard加入CNCF，标志着Istio向服务网格的事实标准迈出了关键的一步。《Istio权威指南》由来自Istio指导委员会、Istio社区等的Istio资深开发人员编写而成，是非常全面、深入地讲解Istio技术的权威书籍，内容涵盖Istio的原理、实践、架构与源码。无论您是初学者、云原生技术专家，还是Istio社区的贡献者，都可以从中获益。——Envoy与Istio核心维护者、Tetrate.io前创始工程师 周礼赞《Istio权威指南（上）》讲解了Istio的原理、各种使用场景和优秀实践，《Istio权威指南（下）》讲解了Istio控制面和数据面Envoy的内部架构及源码实现。这两本书深入剖析了Istio的内部架构，可以帮助您更充分地理解Istio的工作原理和实现，从而更好地应用Istio并进行Istio调优。凝聚深厚实践 行业问鼎力作华为云应用服务网格华为云在2018年率先发布全球首个Istio商用服务：应用服务网格 ASM （Application Service Mesh，）。ASM 是一个拥有高性能、高可靠性和易用性的全托管服务网格。作为分布式云场景中面向应用的网络基础，ASM 对多云、混合云环境下的容器、虚拟机、Serverless、传统微服务、Proxyless 服务提供了应用健康、韧性、弹性、安全性等的全方位管理。华为云应用服务网格（ASM）也已服务于互联网、汽车、制造、物流、政府等多个行业的近千家客户，满足不同行业客户的业务诉求。华为云将在此过程中积累的丰富经验，转化为代码贡献给Istio社区，极大地推动了 Istio 技术的成熟和社区的快速发展。华为云 Istio 社区贡献作为最早一批投身云原生技术的厂商，华为云是 CNCF 在亚洲唯一的初创成员。华为云云原生团队从 2018 年开始积极参与 Istio 社区的活动，参与 Istio 社区的版本特性设计与开发，基于用户的共性需求开发了大量大颗粒特性。团队成员入选了每届 Istio 社区指导委员会，当前有2名指导委员会成员（全球仅 8 家公司 13 人），参与 Istio 社区的重大技术决策，持续引领了 Istio 项目和服务网格技术的发展。另外 Maintainer 2 名，Member 10+名，Pull Request 位于全球TOP 3，中国第一，Contributions TOP 3（2.3w+）。华为云云原生团队华为云云原生团队创建于2013年，是国内较早从事云原生研究的团队之一，也是CNCF的初创成员和白金会员。华为云在容器、服务网格、微服务等云原生技术领域都有着深厚的沉淀，拥有10多名CNCF项目维护者，对 Kubernetes、Istio 等核心项目的贡献一直位居全球前列，并向CNCF捐献了 KubeEdge、Volcano、Karmada 等知名项目。基于 CNCF 的开源生态，华为云还打造了云容器引擎、云容器实例、应用服务网格等一系列优质的商业化云原生服务。为进一步推广云原生技术，加速云原生在行业中落地，华为云联合CNCF、中国信通院及业界云原生技术精英们成立了全球云原生交流平台——创原会。创原会创原会是 CNCF、中国信通院、华为云及业界云原生技术精英们联合成立的全球云原生交流平台，旨在通过研究前沿云原生技术及共享产业落地实践，探索云原生与业务融合的无限可能。自 2020 年成立至今，创原会已在中国、东南亚、拉美、欧洲陆续成立分会并举办活动 50 余场，为全球技术精英们提供了一个优质、高端、开放的交流平台，并吸纳近 300 位 CTO、技术总监成为会员，极大地促进了云原生在全球各行业中的普及和落地。对本书感兴趣，可链接直达− 《Istio权威指南（上）：云原生服务网格Istio原理与实践》(张超盟，徐中虎，张伟，冷雪) https://item.jd.com/13938046.html− 《Istio权威指南（上）：云原生服务网格Istio架构与源码》(张超盟，徐中虎，张伟，冷雪)https://item.jd.com/13938046.html添加小助手k8s2222进入华为云云原生团队Istio技术交流群

在openEuler 22.03-lts aarch64版本的容器中安装rsyslogd，根据centos的类似方法，将以下注释 #### MODULES ####  #module(load="imuxsock"           # provides support for local system logging (e.g. via logger command) #       SysSock.Use="off") # Turn off message reception via local log socket;                           # local messages are retrieved through imjournal now. #module(load="imjournal"            # provides access to the systemd journal #       StateFile="/run/log/imjournal.state") # File to store the position in the journal #module(load="imklog") # reads kernel messages (the same are read from journald) #module(load="immark") # provides --MARK-- message capability  #$imjournalRatelimitInterval 0 启动rsyslog报错 [root@fb4bbc75f4e5 ~]# rsyslogd  rsyslog startup failure, child did not respond within startup timeout (60 seconds) 求助解决

一、容器化改造方案租户对应一个企业。租户中内置多级VDC对企业不同部门。每个部门可以设置配额，对应部门对资源的预算。支持VDC多级管理，最大5级。 部门内的项目，对应project，一个用户可以在不同项目内。一个项目也可以有不同用户。用户可以跨部门关联项目 部门的资源归属到项目中 VDC内用户有不同角色，分别为VDC管理员，负责本级及下级的产品、角色、用户、Project管理、资源管理； VDC业务员：负责资源使用二、高可用规划结合华为云，给出高可用规划的简单说明：1 、分别在2个AZ中部署两套CCE集群，K8S Master采用本地3节点高可用部署；2、应用AZ内高可用部署，通过ClusterIP服务调用不跨AZ。3、应用发布LoadBalancer类型的Service对接到集群所在AZ的融合ELB服务实例；4、应用通过VIP访问数据库，数据库自动切换应用不感知。5、支持多AZ动态容器存储，根据pod所在AZ创建数据卷。三、 网络规划1、集群内部应用默认可通过ClusterIP类型服务相互通信。k8s集群内置DNS服务，服务间访问可以通过IP或域名访问，请画出K8S集群内部应用网络互通示意图：2、Step1：kube-proxy、core-dns从Master中kube-apiserver订阅service，POD2的Service创建时，kube-proxy刷新本节点iptables，core-DNS更新路由数据。3、Step2：Pod2通过域名访问Pod4的service4，发起到core-dns查询请求，并获取对应的ClusterIP（如果使用ClusterIP直接访问则忽略这一步骤）4、Step3：Pod2发送业务报文，目的地址为获取到的ClusterIP。容器网络根据目的地址匹配策略后进行VxLAN封装，封装源地址为容器所在的VM IP地址，目的地址为目的容器所在VM IP，并将报文发给I层vSwitch，然后转发至目的容器所在VM，容器网络解VxLAN封装后，根据ClusterIP将业务报文发送目的service及POD。四、 云原生概念五、 微服务微服务目的是有效的拆分应用，实现敏捷开发和部署 。1、按照业务来划分服务，单个服务代码量小，业务单一，易于维护2、每个微服务都有自己独立的基础组件，例如数据库、缓存等，且运行在独立的进程中3、微服务之间的通信是通过HTTP 协议或者消息组件，且具有容错能力4、微服务有一套服务治理的解决方案，服务之间不相合，可以随时加入和剔除服务5、单个微服务能够集群化部署，并且有负载均衡的能力6、整个微服务系统应该有一个完整的安全机制，包括用户验证、权限验证、资源保护等7、整个微服务系统有链路追踪的能力8、有一套完整的实时日志系统微服务具备功能：1、服务的注册和发现2、服务的负载均衡3、服务的容错4、服务网关5、服务配置的统一管理6、链路追踪7、实时日志六、 CI/CDCICD实现了从代码开发、代码编译、部署、测试、发布上线自动化的一套自动化构建的流程；CI即持续集成(Continuous Integration)，它实现代码合并、构建、部署、测试都在一起，不断地执行这个过程，并对结果进行反馈。CD包含两个含义：持续交付(Continuous Delivery)，它实现部署到生产环境，给用户进行使用；持续部署(Continuous Deployment)，它实现部署到生产环境七、 DevopsDevOps就是让开发人员和运维人员更好地沟通合作，通过自动化流程来使得软件整体过程更加快捷和可靠八、 容器化容器是通过一种虚拟化技术来隔离运行在主机上不同进程，从而达到进程之间、进程和宿主操作系统相互隔离、互不影响的技术。这种相互孤立进程就叫容器，它有自己的一套文件系统资源和从属进程。九、 使用容器引擎客户端上传镜像顺序开始——安装容器引擎——构建镜像——创建组织——连接容器镜像服务——上传镜像——结束十、 CCE引擎优势

一.存储容器化存储作为基础组件，直接和本地盘打交道，所以我们一个要解决的事情就是如果Kubernetes 管理本地盘。kubernetes管理本地盘通过官方提供的local-static-provisioner自动生成LocalPersistentVolume管理磁盘。LocalPersistentVolume是Kubernetes提供的一种管理本地盘的资源。5.1 使用Statefulset管理存储容器通过statefulset 管理有状态的存储服务， 为每个pod分配一个单独的磁盘可以使用volumeClaimTemplates给每个pod生成唯一的pvc，具体规则{podName}，事先准备好PVC 和 PV，通过Statefulset 我们就可以把我们的存储托管到云上了。另外借助daemonset，可以把我们gateway模块部署到每一个node上面。处理云存储的请求。5.2 存储容器化的收益1）降低运维成本基于Kubernetes和statfulset获得了滚动更新，灰度更新，健康检查，快速扩容等功能，只需要一组yaml文件就可以快速搭建一个集群，相比于传统写ansible脚本部署的方式复杂度大大降低。2）降低开发运维成本由于Kubernetes把存储抽象成StorageClass PersistentVolume PersistentVolumeClaim。我们可以通过他们管理我们的存储资源，基于Kubernetes lable的过滤功能，可以实现简单的关系查询，通过PVC与PV管理存储资源，减少管理端的开发。定位问题也能通过POD信息快速定位到问题机器和问题云盘。而且接入Kubernetes生态上的prometheus后，监控告警也能快速开发。3）隔离性增强docker限制cpu memory使用，减少进程之间资源互相干扰，进一步提升资源利用率。在做流媒体容器化过程中，各个系统 Portal 平台、中间件、ops 基础设施、监控等都做了相应的适配改造，改造后的架构矩阵如下图所示。Portal：流媒体 的 PaaS 平台入口，提供 CI/CD 能力、资源管理、自助运维、应用画像、应用授权(db 授权、支付授权、应用间授权)等功能。2.运维工具：提供应用的可观测性工具, 包括 watcher（监控和报警）、bistoury （Java 应用在线 Debug）、qtrace（tracing 系统）、loki/elk（提供实时日志/离线日志查看）。中间件：应用用到的所有中间件，mq、配置中心、分布式调度系统 qschedule、dubbo 、mysql sdk 等。3.虚拟化集群：底层的 K8s 和 OpenStack 集群。4.Noah：测试环境管理平台，支持应用 KVM/容器混合部署。一．CI/CD 流程改造主要改造点:应用画像: 把应用相关的运行时配置、白名单配置、发布参数等收敛到一起，为容器发布提供统一的声明式配置。授权系统: 应用所有的授权操作都通过一个入口进行，并实现自动化的授权。K8s 多集群方案: 通过调研对比，KubeSphere 对运维优化、压测评估后也满足我们对性能的要求，最终我们选取了 KubeSphere 作为多集群方案。二.中间件适配改造改造关注点：由于容器化后，IP 经常变化是常态，所以各个公共组件和中间件要适配和接受这种变化。Qmq组件改造点：Broker端加快过期数据的处理速度。原因:由于IP变化频繁，对于一个主题有几百个甚至上千个的IP订阅，会产生很多文件Qconfig/Qschedule组件改造点：按实例级别的推送、任务执行在容器场景下不建议使用 。原因:因为IP经常变化，在容器化场景下发布、pod驱逐等都会导致IP变化，按实例维度推送没有意义Dubbo组件改造点：更改上线下线逻辑，下线记录由永久节点改为临时节点。 原因:上下线机制加上频繁的IP变更会导致zookeeper上产生大量的过期数据Openresty改造点：监听多K8s集群的endpoint变更，并更新到upstream; KVM、容器server地址共存，支持KVM和容器混合部署;三、应用平滑迁移方案设计为了帮助业务快速平滑地迁移到容器，制定了一些规范和自动化测试验证等操作来实现这个目标。1.容器化的前置条件: 应用无状态、不存在 post_offline hook（服务下线后执行的脚本）、check_url 中不存在预热操作。2.测试环境验证: 自动升级 SDK、自动迁移。我们会在编译阶段帮助业务自动升级和更改 pom 文件来完成 SDK 的升级，并在测试环境部署和验证，如果升级失败会通知用户并提示。3.线上验证: 第一步线上发布，但不接线上流量，然后通过自动化测试验证，验证通过后接入线上流量。4.线上 KVM 与容器混部署：保险起见，线上的容器和 KVM 会同时在线一段时间，等验证期过后再逐步下线 KVM。5.线上全量发布: 确认服务没问题后，下线 KVM。6.观察: 观察一段时间，如果没有问题则回收 KVM。