3月21日，在巴黎举办的云原生顶级峰会KubeCon+CloudNativeCon Europe 2024上 ，华为云首席架构师顾炯炯在 “Cloud Native x AI：以持续开源创新开启智能时代” 的主题演讲中指出，云原生和AI技术的融合，是推动产业深刻变革的关键所在。华为云将持续进行开源创新，与开发者共启智能时代。  ▲华为云首席架构师顾炯炯发表演讲AI对于云原生范式提出关键挑战在过去的几年里，云原生彻底改变了传统的IT系统，催化了互联网和政府服务等领域的数字飞跃。云原生范式带来的新的可能性，例如闪电般的快速销售和基于微服务治理的敏捷应用DevOps，已经深入人心。同时，人工智能的快速发展和广泛采用，包括大规模模型，已经成为行业智能的跳动心脏。根据Epoch 2023年的调研数据，基础模型所需的计算能力每18个月就会增长10倍，是摩尔定理揭示的通用计算能力增长率的5倍。AI带来的新摩尔定律和大规模AI模型的主导地位对云原生范式提出了挑战，顾炯炯总结了其中关键的4点：首先，低GPU/NPU平均利用率导致AI训练和推理的高成本；其次，大模型训练集群频繁的失败率限制了训练效率；第三，大规模模型的复杂配置导致AI开发门槛高；第四，大规模的AI推理部署面临着不可预测的最终用户访问延迟和数据隐私问题的风险。华为云AI创新为开发者迎接挑战提供思路随着AI模型变得越来越大，对计算能力的需求也呈指数级增长。这种需求不仅给云原生技术带来了挑战，也为业界提供了创新机遇。顾炯炯分享了一些华为云在AI创新方面的故事，为开发者解决这些挑战提供了参考。在云原生边缘计算平台KubeEdge的基础上，华为云实现了一个云原生多机器人调度管理平台。用户可以通过自然语言命令在云端输入任务指令，由系统协调边缘的多个机器人共同协作完成复杂任务。为了克服自然语言命令理解、大量机器人高效调度管理以及跨类型机器人访问管理的三个挑战，该系统采用了云端、边缘节点和机器人三个部分的架构，通过大模型执行自然语言命令，并进行流量预测、任务分配和路由规划。这一架构显著提高了机器人平台的灵活性，管理效率提升25%，系统部署周期缩短30%，新机器人的部署时间从月级缩短到天级。中国某顶级内容分享社区，每月活跃用户超过1亿。它的核心服务之一是主页上的推荐功能。推荐模型有近1000亿个参数。训练集群有数千个计算节点。一个训练作业需要数百个参数服务器和worker。因此，该社区对最优拓扑调度、高性能、高吞吐量有着强烈的需求。开源项目Volcano可以更好地支持在Kubernetes上运行的AI/ML工作负载，并提供了一系列作业管理和高级调度策略。Volcano项目引入了拓扑感知调度、装箱、SLA感知调度等算法，帮助社区将整体训练性能提升了20%，运维复杂度也大大降低。Serverless AI引领云原生发展趋势如何高效、稳定地运行AI应用，同时降低运营成本，成为摆在众多企业和开发者面前的一大挑战。为此，华为云总结了云原生AI平台的关键要求，提出了一种全新的云原生AI平台理念——Serverless AI。顾炯炯提到，从开发者的视角来看，Serverless AI致力于智能地推荐并行策略，让复杂的训练和推理任务变得轻而易举。它提供自适应的GPU/NPU自动扩展功能，能够根据工作负载的实时变化动态调整资源分配，确保任务的高效执行。同时，Serverless AI还维护着一个无故障的GPU/NPU集群，让开发者无需担心硬件故障带来的中断风险。更值得一提的是，该平台保持与主流AI框架的兼容性，让开发者能够无缝集成现有的AI工具和模型。对于云服务提供商而言，Serverless AI同样具有深远的意义。它不仅能够提高GPU/NPU的利用率，使训练、推理和开发混合工作负载得以高效运行，还能通过优化能效实现绿色计算，降低能耗成本。此外，Serverless AI平台还能实现跨多个租户的空间和时间GPU/NPU共享，提高资源的复用率。最重要的是，它为训练和推理任务提供了有保证的QoS和SLA，确保了服务质量和稳定性。Serverless AI平台采用了构建在操作系统和虚拟化之上的灵活的资源调度层，将应用程序框架的关键功能封装于应用资源中介层中。顾炯炯现场展示了Serverless AI平台的参考架构。他认为，这种架构设计，使得Serverless AI平台具有了大规模AI资源自动驱动引擎的特点，包括精确了解应用资源利用模式的资源分析，实现异构硬件资源池化的资源共享，基于GPU/NPU虚拟化和负载热迁移的AI训练任务容错能力，以及提高资源利用率的多维度调度和自适应弹性伸缩等优点。分论坛上，华为云技术专家提到，Kubernetes上运行AI/ML工作负载的使用量不断增加，许多公司在分布于数据中心和各种GPU类型的多个 Kubernetes 集群上构建云原生AI平台。使用Karmada和Volcano，可轻松实现多集群的GPU工作负载智能调度、集群故障转移支持，在保障集群内和跨集群的两级调度一致性和效率，并平衡系统整体资源的利用率和不同优先级工作负载的QoS，以应对大规模、异构的GPU环境管理中面临的挑战。Karmada为多云和混合云场景中的多集群应用管理提供即时可用的自动化管理，越来越多的用户在生产环境中使用Karmada构建灵活高效的解决方案。Karmada已于2023年正式升级为CNCF孵化项目，期待与更多伙伴与开发者们共建繁荣社区。Volcano与主流AI/大数据框架实现了无缝集成，有效解决了AI/大数据任务的作业管理，资源分配，资源调度等问题与挑战，为业界提供了分布式作业训练的最佳实践。在大模型日新月异的今天，Volcano将持续发力，解决多集群AI任务调度等难题，助推大模型训练与推理快速发展。“云原生技术的敏捷性和异构AI计算平台的创新性，将是提升AI生产力的关键。” 顾炯炯谈到，未来，华为云将持续致力于开源创新，与业界同仁、伙伴共同开启智能时代的新篇章。更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

北京时间2024年1月23日，KubeEdge 发布 1.16.0 版本。新版本新增多个增强功能，在集群升级、集群易用性、边缘设备管理等方面均有大幅提升。KubeEdge v1.16.0 新增特性：集群升级：支持云边组件自动化升级支持边缘节点的镜像预下载支持使用 Keadm 安装 Windows 边缘节点增加多种容器运行时的兼容性测试EdgeApplication 中支持更多 Deployment 对象字段的 Override支持基于 Mapper-Framework 的 Mapper 升级DMI 数据面内置集成 Redis 与 TDEngine 数据库基于 Mapper-Framework 的 USB-Camera Mapper 实现易用性提升：基于 Keadm 的部署能力增强升级 K8s 依赖到 v1.27  新特性概览 ▍集群升级：支持云边组件自动化升级随着 KubeEdge 社区的持续发展，社区版本不断迭代；用户环境版本升级的诉求亟需解决。针对升级步骤难度大，边缘节点重复工作多的问题，v1.16.0 版本的 KubeEdge 支持了云边组件的自动化升级。用户可以通过 Keadm 工具一键化升级云端，并且可以通过创建相应的 Kubernetes API，批量升级边缘节点。云端升级云端升级指令使用了三级命令与边端升级进行了区分，指令提供了让用户使用更便捷的方式来对云端的 KubeEdge 组件进行升级。当前版本升级完成后会打印 ConfigMap 历史配置，如果用户手动修改过 ConfigMap，用户可以选择通过历史配置信息来还原配置文件。我们可以通过 help 参数查看指令的指导信息：keadm upgrade cloud --help Upgrade the cloud components to the desired version, it uses helm to upgrade the installed release of cloudcore chart, which includes all the cloud components Usage: keadm upgrade cloud [flags] Flags: --advertise-address string Please set the same value as when you installed it, this value is only used to generate the configuration and does not regenerate the certificate. eg: 10.10.102.78,10.10.102.79 -d, --dry-run Print the generated k8s resources on the stdout, not actual execute. Always use in debug mode --external-helm-root string Add external helm root path to keadm --force Forced upgrading the cloud components without waiting -h, --help help for cloud --kube-config string Use this key to update kube-config path, eg: $HOME/.kube/config (default "/root/.kube/config") --kubeedge-version string Use this key to set the upgrade image tag --print-final-values Print the final values configuration for debuging --profile string Sets profile on the command line. If '--values' is specified, this is ignored --reuse-values reuse the last release's values and merge in any overrides from the command line via --set and -f. --set stringArray Sets values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --values stringArray specify values in a YAML file (can specify multiple)升级指令样例：keadm upgrade cloud --advertise-address= --kubeedge-version=v1.16.0边端升级v1.16.0版本的KubeEdge支持通过 NodeUpgradeJob 的 Kubernetes API 进行边缘节点的一键化、批量升级。API 支持边缘节点的升级预检查、并发升级、失败阈值、超时处理等功能。对此，KubeEdge 支持了云边任务框架。社区开发者将无需关注任务控制、状态上报等逻辑实现，只需聚焦云边任务功能本身。升级 API 样例：apiVersion: operations.kubeedge.io/v1alpha1 kind: NodeUpgradeJob metadata: name: upgrade-example labels: description: upgrade-label spec: version: "v1.16.0" checkItems: - "cpu" - "mem" - "disk" failureTolerate: "0.3" concurrency: 2 timeoutSeconds: 180 labelSelector: matchLabels: "node-role.kubernetes.io/edge": "" node-role.kubernetes.io/agent: ""兼容测试KubeEdge 社区提供了完备的版本兼容性测试，用户在升级时仅需要保证云边版本差异不超过 2 个版本，就可以避免升级期间云边版本不一致带来的问题。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5330https://github.com/kubeedge/kubeedge/pull/5229https://github.com/kubeedge/kubeedge/pull/5289▍支持边缘节点的镜像预下载新版本引入了镜像预下载新特性，用户可以通过 ImagePrePullJob的 Kubernetes API 提前在边缘节点上加载镜像，该特性支持在批量边缘节点或节点组中预下载多个镜像，帮助减少加载镜像在应用部署或更新过程，尤其是大规模场景中，带来的失败率高、效率低下等问题。镜像预下载API示例：apiVersion: operations.kubeedge.io/v1alpha1 kind: ImagePrePullJob metadata: name: imageprepull-example labels: description:ImagePrePullLabel spec: imagePrePullTemplate： images: - image1 - image2 nodes： - edgenode1 - edgenode2 checkItems: - "disk" failureTolerate: "0.3" concurrency: 2 timeoutSeconds: 180 retryTimes: 1 更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5310https://github.com/kubeedge/kubeedge/pull/5331▍支持使用 Keadm 安装 Windows 边缘节点KubeEdge 1.15.0 版本实现了在 Windows 上运行边缘节点，在新版本中，我们支持使用安装工具 Keadm 直接安装 Windows 边缘节点，操作命令与 Linux 边缘节点相同，简化了边缘节点的安装步骤。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/4968▍增加多种容器运行时的兼容性测试新版本中新增了多种容器运行时的兼容性测试，目前已集成了containerd，docker，isulad 和 cri-o 4种主流容器运行时，保障 KubeEdge 版本发布质量，用户在安装容器运行时过程中也可以参考该PR中的适配安装脚本。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5321▍EdgeApplication 中支持更多 Deployment 对象字段的 Override在新版本中，我们扩展了 EdgeApplication 中的差异化配置项（overriders），主要的扩展有环境变量、命令参数和资源。当您不同区域的节点组环境需要链接不同的中间件时，就可以使用环境变量（env）或者命令参数（command, args）去重写中间件的链接信息。或者当您不同区域的节点资源不一致时，也可以使用资源配置（resources）去重写cpu和内存的配置。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5262https://github.com/kubeedge/kubeedge/pull/5370▍支持基于Mapper-Framework的 Mapper 升级1.16.0 版本中，基于 Mapper 开发框架 Mapper-Framework 构建了 Mapper 组件的升级能力。新框架生成的 Mapper 工程以依赖引用的方式导入原有 Mapper-Framework 的部分功能，在需要升级时，用户能够以升级依赖版本的方式完成，简化 Mapper 升级流程。Mapper-Framework 代码解耦:1.16.0 版本中将 Mapper-Framework 中的代码解耦为用户层和业务层。用户层功能包括设备驱动及与之强相关的部分管理面数据面能力，仍会随 Mapper-Framework 生成在用户 Mapper 工程中，用户可根据实际情况修改。业务层功能包括 Mapper向云端注册、云端下发Device列表等能力，会存放在kubeedge/mapper-framework 子库中。Mapper 升级框架:1.16.0 版本 Mapper-Framework 生成的用户 Mapper 工程通过依赖引用的方式使用 kubeedge/mapper-framework 子库中业务层功能，实现完整的设备管理功能。后续用户能够通过升级依赖版本的方式达到升级 Mapper 的目的，不再需要手动修改大范围代码。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5308https://github.com/kubeedge/kubeedge/pull/5326▍DMI 数据面内置集成 Redis 与TDEngine数据库1.16.0 版本中进一步增强 DMI 数据面中向用户数据库推送数据的能力，增加 Redis 与 TDengine 数据库作为内置数据库。用户能够直接在 device-instance 配置文件中定义相关字段，实现 Mapper 自动向 Redis 与 TDengine 数据库推送设备数据的功能，相关数据库字段定义为：type DBMethodRedis struct { // RedisClientConfig of redis database // +optional RedisClientConfig *RedisClientConfig `json:"redisClientConfig,omitempty"` } type RedisClientConfig struct { // Addr of Redis database // +optional Addr string `json:"addr,omitempty"` // Db of Redis database // +optional DB int `json:"db,omitempty"` // Poolsize of Redis database // +optional Poolsize int `json:"poo lsize,omitempty"` // MinIdleConns of Redis database // +optional MinIdleConns int `json:"minIdleConns,omitempty"` }type DBMethodTDEngine struct { // tdengineClientConfig of tdengine database // +optional TDEngineClientConfig *TDEngineClientConfig `json:"TDEngineClientConfig,omitempty"` } type TDEngineClientConfig struct { // addr of tdEngine database // +optional Addr string `json:"addr,omitempty"` // dbname of tdEngine database // +optional DBName string `json:"dbName,omitempty"` }更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5064▍基于Mapper-Framework的USB-Camera Mapper实现基于KubeEdge 的 Mapper-Framework，新版本提供了 USB-Camera 的 Mapper 样例，该 Mapper 根据 USB 协议的 Camera 开发，用户可根据该样例和 Mapper-Framework 更轻松地开发具体业务相关的 Mapper。在样例中提供了 helm chart 包，用户可以通过修改 usbmapper-chart/values.yaml 部署 UBS-Camera Mapper，主要添加 USB-Camera 的设备文件, nodeName, USB-Camera 的副本数，其余配置修改可根据具体情况而定，通过样例目录中的 Dockerfile 制作 Mapper 镜像。global: replicaCounts: ...... cameraUsbMapper: replicaCount: 2 #USB-Camera的副本数 namespace: default ...... nodeSelectorAndDevPath: mapper: - edgeNode: "edgenode02" #USB-Camera连接的缘节点nodeName devPath: "/dev/video0" #USB-Camera的设备文件 - edgeNode: "edgenode1" devPath: "/dev/video17" ...... USB-Camera Mapper 的部署命令如下：helm install usbmapper-chart ./usbmapper-chart更多信息可参考：https://github.com/kubeedge/mappers-go/pull/122▍易用性提升：基于 Keadm 的部署能力增强添加云边通信协议配置参数在 KubeEdge v1.16.0 中，使用keadm join边缘节点时，支持使用--hub-protocol 配置云边通信协议。目前 KubeEdge 支持 websocket 和 quic 两种通信协议，默认为 websocket 协议。命令示例：keadm join --cloudcore-ipport <云节点ip>:10001 --hub-protocol=quic --kubeedge-version=v1.16.0 --token=xxxxxxxx说明：当--hub-protocol设置为 quic 时，需要将--cloudcore-ipport的端口设置为10001，并需在CloudCore的ConfigMap中打开quic开关，即设置modules.quic.enable为true。操作示例：使用 kubectl edit cm -n kubeedge cloudcore，将 quic 的 enable 属性设置成 true，保存修改后重启 CloudCore的pod。modules： ...... quic: address: 0.0.0.0 enable: true #quic协议开关 maxIncomingStreams: 10000 port: 10001 ......更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5156keadm join 与 CNI 插件解耦在新版本中，keadm join边缘节点时，不需要再提前安装 CNI 插件，已将边缘节点的部署与 CNI 插件解耦。同时该功能已同步到 v1.12 及更高版本，欢迎用户使用新版本或升级老版本。说明：如果部署在边缘节点上的应用程序需要使用容器网络，则在部署完 EdgeCore 后仍然需要安装 CNI 插件。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5196▍升级 K8s 依赖到 v1.27新版本将依赖的 Kubernetes 版本升级到 v1.27.7，您可以在云和边缘使用新版本的特性。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5121  版本升级注意事项  新版本我们使用 DaemonSet 来管理边端的 MQTT 服务 Eclipse Mosquitto 了，我们能够通过云端 Helm Values 配置来设置是否要开启 MQTT 服务。使用 DaemonSet 管理 MQTT 后，我们可以方便的对边端 MQTT 进行统一管理，比如我们可以通过修改 DaemonSet 的配置将边端 MQTT 替换成 EMQX。但是如果您是从老版本升级到最新版本，则需要考虑版本兼容问题，同时使用原本由静态 Pod 管理的 MQTT 和使用新的 DaemonSet 管理的 MQTT 会产生端口冲突。兼容操作步骤参考：1、您可以在云端执行命令，将旧的边缘节点都打上自定义标签kubectl label nodes --selector=node-role.kubernetes.io/edge without-mqtt-daemonset=""2、您可以修改 MQTT DaemonSet 的节点亲和性nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - ... - key: without-mqtt-daemonset operator: Exists3、将节点 MQTT 改为由 DaemonSet 管理# ------ 边端 ------ # 修改/lib/systemd/system/edgecore.service，将环境变量DEPLOY_MQTT_CONTAINER设置成false # 这步可以放在更新EdgeCore前修改，这样就不用重启EdgeCore了 sed -i '/DEPLOY_MQTT_CONTAINER=/s/true/false/' /etc/systemd/system/edgecore.service # 停止EdgeCore systemctl daemon-reload && systemctl stop edgecore # 删除MQTT容器，Containerd可以使用nerdctl替换docker docker ps -a | grep mqtt-kubeedge | awk '{print $1}' | xargs docker rm -f # 启动EdgeCore systemctl start edgecore # ------ 云端 ------ # 删除节点标签 kubectl label nodes without-mqtt-daemonset新版本的 keadm join 命令会隐藏 with-mqtt 参数，并且将默认值设置成 false，如果您还想使用静态 Pod 管理 MQTT，您仍然可以设置参数--with-mqtt来使其生效。with-mqtt 参数在 v1.18 版本中将会被移除。  致谢  感谢 KubeEdge 社区技术指导委员会(TSC)、各 SIG 成员对 v1.16.0 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_0更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

  背景介绍  当今社会正处在一个技术飞速发展、机器人与人工智能深入应用于工业领域的时代。在物流、制造和零售等领域，自动导引车（AGV）已经成为高效生产的关键工具，正在全球范围内迅速发展并得到广泛应用。2022年，我国 AGV 销量为93000台，同比增长29.2%；销售规模为185亿元，同比增长46.8%；海外销售规模为36亿，同比增长44%。AGV 系统中的无人驾驶技术，不仅可以提高生产效率，减少人工操作失误的概率，还可以在复杂和危险的环境下保障操作人员的安全。图 1 定制化接口与统一接口下，工厂调度系统架构图尽管 AGV 技术被广泛应用，却缺乏调度系统与 AGV 之间的统一接入协议。图1(a)展示了单个工厂部署不用厂家 AGV 的软件架构图，其中 MES/WMS/ERP 代表上层业务系统，RCS 代表 AGV 调度系统或云端控制平台。由于 AGV 与 RCS 之间的接口是定制化且封闭的，因此 AGV 与 RCS 的厂家属于强耦合关系，即厂家1的 RCS 无法调度厂家2的 AGV。因此对于工厂用户来讲，为了保证不同厂家的机器人安全工作，必须划定交管区域。在同一个交管区内，同一时刻只允许同一厂家的机器人进入，显著降低了任务的执行效率和 AGV 的利用效率。因此，制定一套全面、深入、适用各种环境和物流领域的调度系统与 AGV 的协议，对于统一调度系统与设备之间对接，提升 AGV 的效率、稳定性和安全性至关重要。统一的协议标准不仅明确 AGV 供应方的责任，同时也为 AGV 需求方提供保障。图 1(b)展示了统一接口下的软件架构图，可以看到，RCS 与 AGV 之间不再存在耦合关系。总结来讲，统一接口相比于定制化的接口存在以下优势：安全性高：所有厂商的 AGV 被 RCS 当作白盒集中处理，从源头杜绝碰撞，保障安全；调度效率高：同一场地无需划定交管区，AGV 也无需在“红绿灯”前长时间等待；业务连续性强：终端用户的采购方案更加灵活，无需被单个 AGV 供应商绑定；部署运维成本低：单 RCS 部署的模式，显著降低计算资源和运维人员的成本；扩展性强：支持不同厂家的新旧设备共存，用户可以按需引入新的 AGV；为此，华为联合中外运、顺丰、龙岩烟草、海康、海柔、蓝芯、斯坦德、镭神、边缘计算产业联盟、中国物流与采购联合会等30+伙伴共同起草了《云端控制平台与物流自动导引车通用接口指南》，旨在将相关的经验贡献给行业，促进我国机器人行业的蓬勃发展。  协议内容  ▍内容简介该文件规定了 AGV 与云端控制平台的接口模型、客户端通信安全认证、通信协议结构，以及控制、传输流程接口的技术要求和检验规则。适用于物流、仓储、制造业等领域的物流自动导引车实现云端控制的系统接口设计、开发、检验等。图 2 云端控制平台与AGV报文交互示意图图 2 展示了云端控制平台与 AGV 的交互流程图，整体分成以下几步：AGV 在初始化完成后，向云端控制平台发起接入申请，可选普通模式接入和安全模式接入。在普通模式中，后续报文将直接发送至对端。在安全模式中， AGV 与云端控制平台将协商会话密钥，且后续报文以密文的形式发送。AGV 向云端控制平台发起注册请求。注册成功后，将会周期性的上报自身状态；云端控制平台配置 AGV 的全局信息，如状态上报周期、告警参数等；AGV 周期性地向云端控制平台上报自身状态，并与云端控制平台保持心跳；云端控制平台根据上层业务系统输入，下发每个 AGV 的控制报文，驱动 AGV 运动；AGV 可以根据需求向云端控制平台申请安全空间，以完成自主运动，如动态绕障。▍协议亮点图 3 协议亮点信息安全：在普通接入模式的基础上，新增了安全加密模式。AGV 与云端控制平台通过 SM2 密钥交换协议协商会话密钥，然后使用该密钥对传输的报文进行 SM4 分组密码算法进行加密后，利用 SM2 数字签名算法生成签名，再对密文和签名进行传输，从而保证整个通信过程的安全；多地图管理：为满足 AGV 跨楼层和跨楼栋搬运的需求，协议规定了 RCS 和 AGV 的地图切换流程。同时指明了 AGV 在同一场地下，在 SLAM 和二维码导航之间的切换流程；双向路径规划：协议不仅规定了 RCS 规划的路径下发给 AGV 的流程，同时支持车体在极端环境下自主规划且平台授权的轨迹形式方法，如临时性避障；通信数据：采用二进制报文，显著降低通讯的数据量，减轻了对网络的依赖。同时保留多个预留字段，便于扩展和定制化实现。▍行业推广 协议的蓬勃发展离不开行业的应用和推广。KubeEdge 是边缘计算领域的开源平台，构建在 Kubernetes 之上，为网络、应用部署和云端与边缘之间的数据同步提供基础设施的支持，其目标和应用范围与当前协议的宗旨十分契合。因此 KubeEdge 将作为协议推广的重要阵地，其功能包括但不限于文档展示、协议内容详细解读、协议代码参考实现和端到端调度系统实现等，为了广大厂商和终端用户提供了良好的交流平台。▍相关链接仓库地址：cid:link_0更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

作者：达益鑫 |南开大学，刘家伟、吴锟 |DaoCloud，王杰章 |华为云▍特性研发背景以及原理KubeEdge EdgeMesh 边缘 CNI 特性针对于边缘容器网络复杂异构环境提供与云上一致的容器网络体验，包括：1. 云边统一的容器网络资源管理分配2.基于分布式中继及穿透能力的 PodIP 级别跨子网流量转发服务特性开发背景EdgeMesh 致力于研究和解决边缘计算场景下网络连通、服务协同、流量治理等相关的一系列问题，其中在异构复杂的边缘网络环境内，不同物理区域的容器在面对动态变迁的网络环境以及短生命周期且跳跃变迁的服务位置，一部分服务可能需要使用 PodIP 进行跨网段通信，而主流的 CNI 方案主要针对于云上稳定且集成式的网络环境，并不支持跨子网流量的转发，致使这些 CNI 方案并不能够很好地适应边缘复杂异构的环境，最终导致容器即便在同一个集群内却没有享用一个平面的网络通信服务。针对这个需求，EdgeMesh 进行逐步的优化。首先实现的是网络底层的中继以及穿透服务功能开发，即 EdgeMesh 高可用特性。在分布式网络场景当中，该特性能够为节点提供基于 Service 的中继流量以及网络穿透服务，但还没有完全支持对 PodIP 层次流量的转发和穿透能力。换句话说在云边混合的场景当中 ，EdgeMesh 能够为跨网段的 Service 流量提供穿透服务，但并没有涉足到容器网络的资源管理和 IP 层的连通性功能，仍旧依赖于集群原本的 CNI 方案。这个局限性导致 EdgeMesh 无法为更加底层的网络 IP 流量提供服务，意味着 EdgeMesh 并不能够完全覆盖混合云边的场景需求，对于那些需要穿透和中继服务的 PodIP 流量，老版本的 EdgeMesh 爱莫能助。那么为什么主流的 CNI 方案无法兼容边缘环境，EdgeMesh 又是如何理解这个需求的呢？关键问题在于主流的 CNI 方案大多建立于至少三层可通的环境要求之下，具体来说 CNI 自身管理创建网络资源的时候，并不能够感知底层网络的状态，其管理能力高度依赖于 Kubernetes 系统提供的 Node IP 地址，而这个地址的连通性是由底层的网络设备来维持的，如果宿主机不能通过该 Node IP 访问到目标，那么容器网络的虚拟 IP 就更没有办法联通了，原理也将在下文详述。这也意味着 Kubernetes 系统所给的 Node IP 在边缘这样底层网络并不稳定的环境下无法保障稳定的底层通信服务。EdgeMesh 基于上述理解，对这个需求进行细化的分析：边缘网络拓扑结构变动性强，且物理隔离场景较多，致使容器网络环境难以呈现出云上那样稳定的底层设施特征，比如边缘环境中自动驾驶场景或者是快递运输场景等。在这样的环境中，物理节点本身并不是绑定固定地址，甚至涉及到 5G 信号核心网注册切换等通信上的流程问题，使得 IP 地址和网络拓扑并不具备完全意义上的寻址能力，通俗说某个节点可能在上一时刻在 A 区域但是过了一会他就行驶到 B 区域了，这样动态变化切换的场景是以往 CNI 架构不曾考虑的。CNI 的连通性是基于 Kubernetes 的 Node IP 维持的，更加深入理解这个结论：主流的 CNI 相信 Kubernetes 系统设置的 IP 地址是可以联通的，所以这些主流的 CNI 方案管理虚拟网络往往都使用这样的方法：宿主机操作系统中的一个切换装置，通过让自己作为虚拟网络资源和实际物理网络环境的中继；正如下图所示， CNI 只是通过 k8s 系统，在各个节点上创建了虚假的地址，通过信息协同的方式让拥有这些虚假地址的数据包可以正常在单机节点上传送给目标，但根本还是依赖于 Node IP 可以访问联通，毕竟如果数据包不能够正常到达目标节点，CNI 利用操作系统所作的虚假行为也就没有了意义。反过来说也无法超过于单机操作系统能够管理的网络连通性，多机分布式场景下完全只能够依靠 Kubernetes 系统。当然，也并非所有的主流 CNI 都只在本机的操作系统内做文章，更加深入解决连通性的 Calico 组件有提供基于 BGP 协议的跨机连接方案，但也围绕着云上数据中心架构展开的。与此相对应的边缘环境中， 节点的 IP 地址是存在着局域性、变动性、不确定性的，可以风趣地说 Kubernetes 系统被节点欺骗了。容器生命周期短暂且不确定，这个特性更像是此类问题的催化剂，使得边缘割裂场景下的网络连接更加难以使用固定的拓扑结构来进行规划管理。系统设计思路在本特性初阶段我们确定了此次项目实现的目标：是结合 EdgeMesh 已有的 P2P 功能来提供 CNI 特性， CNI 特性在目前阶段并不意味着开发出完全替代Flannel、Calico、Cilium 等已有架构的完全独立 CNI，而是作为多阶段逐步迭代实现的特性。一方面从用户角度来说，如果直接替代云上已有的 CNI 架构，会带来额外的部署成本，也无法向用户保证新的架构有足够的价值可以完全覆盖老体系的场景和功能，以项目迭代开发的方式，优先实现一些能力，再慢慢优化、敏捷开发更能符合用户的利益。因而对于云上环境，我们倾向于直接兼容已有的 CNI 架构，使用它们提供的服务，但是补足他们不能够提供的 P2P 功能。与此同时，现有的 CNI 方案并不能够为边缘复杂异构的环境提供统一的容器网络服务，所以相较于 Docker 或者是其他 CRI 提供的简单网络功能，我们更倾向于直接开发出自己的 CNI 来实现对边缘容器网络资源的管理。而在上述的 CNI 需求之外，最重要的是如何与 EdgeMesh 的 P2P 服务结合起来；目前的开源社区中实现隧道的技术有：如 VPN，包含 IPSec、Wireguard等；如 P2P，包含 LibP2P 等，结合 EdgeMesh 应对的复杂异构多变边缘环境，我们选用了 LibP2P 技术进行开发。在此之上需要判断哪些PodIP流量需要 P2P ,哪些流量仍旧使用原本的 CNI 网络服务；再来是将这两部分的功能解耦，以便后期的功能逐步迭代优化，主要的系统架构如下图所示：上述系统设计将集群内的流量分为两类：同一网段流量： 指的是底层网络 NodeIP 可通信，Pod 容器流量通过 CNI 转换即可进行通讯。跨网段流量: 指的是底层网络不可直接访问， Pod 容器流量通过 CNI 转换封装也无法到达目标节点。针对于不同的流量我们提供不同的流量传输方式：对于同一网段的流量：依旧使用主流 CNI 的方案，通过 CNI 转换地址的形式切换虚拟网络和真实网络，连通性依赖 Kubernetes 系统获取的 NodeIP。对于跨网段的流量： 将这部分流量拦截到 EdgeMesh 当中，通过中继或者是穿透的形式转发到目标的节点，此时 EdgeMesh 充当具有 P2P 功能的 CNI 插件，来完成虚拟网络的切换。这样的设计需要解决亮点重要的问题：云边集群容器网络资源统一控制管理边缘节点以及云上节点 CNI 共同管理容器网络资源，使得容器可以分配到集群唯一的 IP地址，且不论云边都可以通过这个 IP 地址进行通信。云边以及边边跨网段容器网络通信能力兼容原本 CNI 的通信方式让需要 P2P 的流量跨网段传输。系统设计的关键抉择在于，是否需要将 P2P 的功能放置到 CNI 执行的关键路径当中，或者是将 P2P 的功能与 CNI 架构解耦。针对于第一个问题，核心关键是 IPAM 插件的设计和兼容，这方面我们倾向于集成开源社区成熟的方案 Siderpool ：📌 ：https://github.com/spidernet-io/spiderpool Spiderpool 是一个kubernetes 的 underlay 和 RDMA 网络解决方案， 同时也是一款 CNCF Sanbox级别项目这一方案也更加契合容器网络插件化设计的理念，用户可以依据业务的需求来更改系统组件的组合，在现阶段完全满足多 CNI 统一管理集群资源的设计。针对第二个问题，核心在于为 CNI 创建的容器网络资源添加跨子网的连通性。方案设计上，如果将中继和穿透的功能放置到 CNI 执行的关键路径中，那就意味着需要在内核中实现中继和穿透的流程，否则将带来巨大的性能消耗。实际上目前 Calico 、 Flannel 、Cilium 等架构在云上使用隧道技术时候就是采用这个方法：在容器资源创建修改的时候，同步修改内核中的网络设备参数，然后对数据包进行封装或者是修改，比如 Vxlan 服务中将目标是其他节点容器的流量拦截，然后添加对协议参数。这个方式在云上运用较为普遍，但是明显无法适应边缘的环境，原因在于：CNI 执行是无状态且一次性的，只有当容器网络资源创建、修改、删除的时候， CNI 调用链会被触发并执行对应的功能；这个方式的实质是通过静态配置的方式来提供通信服务，对于云上较为稳定的网络环境以及通信条件来说，确实是合适的选择，但对于边缘环境来说，网络资源并非一成不变；如果将隧道信息配置为静态形式，再通过 CNI 调用链触发管理，就无法应对部分容器动态变化之后隧道信息变迁的情况。在上述考量的基础上，本特性将 分开 CNI 和 P2P 的功能，解耦彼此在系统运作上的依赖关系，这样也更加方便用户可以选择是否开启其中的一项功能。边缘 CNI 功能这部分设计为实现基础的 CNI 调用链功能，在边缘节点管理容器网络资源，同时通过 IPAM 组件 spiderpool 兼容云上其他的 CNI 架构，统一分配集群的容器网络资源，包括基础的 CNI 功能，其次是通过 SpiderPool 实现全局的容器 IP 地址唯一。基于以上各组件设计,当集群内每一个容器都拥有了唯一的 IP 地址，我们接下来需要做的是为需要中继穿透的流量提供服务，设计方式为： 用户配置全局容器网段文件，分为云上 CIDR 和 边缘 CIDR ，每一段 CIDR 对应一个区域网络即 三层不可通的网络， EdgeMesh 通过配置文件插入路由表规则，将目标地址于本节点 CIDR 不相同的流量都拦截到本机的Tun 设备，再传输到 EdgeMesh 的 libP2P host 通过中继或者穿透的方式传输到目标地址。▍特性启用以及功能启用 EdgeMesh 边缘 CNI 特性您可以通过以下配置的方式，在启动 EdgeMesh 时候启用 CNI 边缘 P2P 特性，配置过程中您可以依据对云边网段资源的划分需求来配置云边容器网络所处的区域：# 启用 CNI 边缘特性 helm install edgemesh --namespace kubeedge \ --set agent.relayNodes[0].nodeName=k8s-master,agent.relayNodes[0].advertiseAddress="{1.1.1.1}" \ --set agent.cloudCIDR="{10.244.1.0/24,10.244.1.0/24}",agent.edgeCIDR="{10.244.5.0/24,10.244.6.0/24}" https://raw.githubusercontent.com/kubeedge/edgemesh/main/build/helm/edgemesh.tgz上述配置的参数中 cloudCIDR 是云上容器集群分配的地址， edgeCIDR 是边缘容器集群分配的地址；EdgeMesh 会对比部署节点分配到的容器网段 CIDR 与配置文件中是否属于不同网段，属于不同网段的地址会添加对应的 ip route 规则拦截到 Tun 设备。cloudCIDR 参数是云上分配的容器网段，类型为 []string ，形式为容器 IP 地址以及其子网掩码，表示一段虚拟网络区域，在区域内的容器应当网络二层可通，如果容器不能够通过二层设备访问，请划分为不同的容器网段。edgeCIDR 参数是边缘分配的容器网段，类型为 []string ，形式为容器IP地址以及其子网掩码，表示一段虚拟网络区域，在区域内的容器应当网络二层可通，如果容器不能够通过二层设备访问，请划分为不同的容器网段。名称参数类型使用实例agent.meshCIDRConfig.cloudCIDR[]string--setagent.meshCIDRConfig.cloudCIDR="{10.244.1.0/24,10.244.1.0/24}"agent.meshCIDRConfig.edgeCIDR[]string--setagent.meshCIDRConfig.edgeCIDR="{10.244.1.0/24,10.244.1.0/24}"需要注意的是设置的地址必须为 CIDR 形式 ，同时需要您依据云边网络情况划分出对应的网段；另一方面本特性需要同时启动高可用特性，为跨网段的流量提供中继和穿透服务。更多的安装配置信息请详见：helm安装 : https://edgemesh.netlify.app/zh/guide/#helm手动安装：https://edgemesh.netlify.app/zh/guide/项目功能特性介绍依据系统的设计，边缘 CNI 特性提供以下具体的功能：云边集群容器网络资源控制管理📌 ：现版本推荐集群云上节点使用 calico/flannel/cilium 等 CNI 插件，同时边缘集群节点使用 EdgeMesh CNI 插件，整个集群配置 SpiderPool 作为统一的地址管理插件来提供服务。针对于边缘网络复杂异构的情况，EdgeMesh 提供了边缘 CNI 插件来创建和管理边缘节点容器的地址资源，同时通过配合 IPAM 插件 spiderpool 协调云上节点的其他 CNI 插件来实现 整个集群的容器地址唯一，云边节点都可以通过唯一的地址进行通讯。如下图所示，该项功能的主要特性在于屏蔽了云边复杂的网络集群拓扑，实现了云边集群统一的容器资源管理，使得云边的容器可以体验如同在一个局域网内的通信服务，而不必考虑边缘集群节点容器地址重复或者是云边集群底层地址不通的问题。云边以及边边容器网络通信能力针对于边缘环境中云边和边缘通信问题，EdgeMesh CNI 特性集成了 P2P 的功能，为跨网络集群的容器流量提供中继和穿透服务。该 P2P 特性现版本主要通过 TUN 设备在 IP 层拦截需要中继和穿透服务的流量实现，能够为应用网络通信提供底层连接的服务，而不受到 IP 层以上网络协议的影响。系统功能运行如下图所示，在每个节点上的 EdgeMesh 会通过修改 IP Route 的形式拦截流量到 TUN 设备，再传输到 EdgeMesh 的 libP2P host 通过中继或者穿透的方式传输到目标地址。这个过程中 EdgeMesh 并不会拦截所有的流量而是通过用户在启动时候设置的网络区域参数来区别哪些流量是跨网段，哪些流量是同局域网访问的，并不会干扰到正常同网段流量的通信。后续计划以及未来设想在项目开发的初期阶段，系统设计基础实现了最初的需求，但是在边缘容器网络环境当中，由于网路部署和设备架构的使用情况多样复杂，对于容器网络提出了三方面重点的需求：可观测具体指的是对于云边以及边边流量的去向，包含在节点内操作系统处理的过程以及节点外多节点之间转发传输的流程可观测性。这类需求对于运维人员以及应用开发人员有着非常重要的价值和意义，可以快速定位网络流量问题出现的位置和导致的原因，并快速得出性能优化的方案和解决问题的办法。高性能与纯云部署的容器集群相似，云边混杂集群同样也面临着性能堪忧的问题，在网络层面主要指的是节点内对网络数据包在操作系统处理路径上的优化，减少其处理的逻辑和相关资源的消耗。强稳定相较于纯云上集群的部署，云边混杂集群的状态往往难以稳定，需要服务能够应对环境变化同时在出现问题时候较快地将流量卸载到正常的服务当中。针对于这些需求， 容器网络 CNI 功能是重点开发和创新的系统组件， EdgeMesh 将在接下来的系统开发中结合 eBPF 等内核优化技术，同时以实现一款泛用的边缘 CNI 插件为目标，推出应对这三点需求的特性和功能，期待能够为用户带来更加丰富和稳定的网络服务体验。附：KubeEdge社区贡献和技术交流地址[1] 网站: https://kubeedge.io[2] Github地址: cid:link_0[3] Slack地址: https://kubeedge.slack.com[4] 每周社区例会: https://zoom.us/j/4167237304[5] Twitter: https://twitter.com/KubeEdge[6] 文档地址: https://docs.kubeedge.io/en/latest/更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

作者：华为云云原生团队▎边缘计算安全防护的实践与洞察随着开源软件安全漏洞持续引起世界各地政府和企业的关注，越来越多的组织、开发人员、研究人员和安全专家投入到开源安全工作中，在各方力量的推动下，开源安全目前已初步形成体系化的生态大网，覆盖了国际化的软件工程行业标准、安全评估体系、安全工具链与整体解决方案等，并逐步撬动整个业界开源软件安全行业的生态产业链。在2020年Linux基金会与多家硬件和软件厂商合作创立了开源软件安全基金会OpenSSF（Open Source Security Foundation），这是一个跨行业的合作组织，汇集了行业领军企业与机构，涵盖世界上最重要的软件供应链安全计划、开源开放的工具链、安全指南、培训等，旨在提高开源软件（OSS）的安全性。作为业界首个云原生边缘计算项目，KubeEdge社区致力于提升KubeEdge在云原生边缘计算场景下的安全性，将安全视为社区发展的重要指导原则。社区充分结合了业界的开源安全经验，于2022年7月完成了对KubeEdge项目的安全威胁模型分析。尽管云原生边缘计算的安全问题备受用户关注，但业界目前缺乏相关的安全威胁模型分析，这使得用户难以有效地加固其边缘系统。因此，KubeEdge社区发布了安全威胁模型及分析白皮书，为用户和厂商提供了重要的安全实践指导。下文将着重介绍Kubeedge在安全防护方面的实践，并介绍OpenSSF在开源软件安全方面的计划与目标。▎KubeEdge安全防护安全防护背景KubeEdge在边端云协同领域正在加速布局，已在智慧交通、智慧城市、智慧园区、智慧能源、智慧工厂、智慧银行、智慧工地、CDN等行业提供一体化的边端云协同解决方案。随着越来越多的用户将KubeEdge项目用于生产环境中， KubeEdge社区把安全问题放在优先地位，并成立Sig- Security 和安全团队 ，负责KubeEdge的系统安全设计，并快速响应和处理安全漏洞。为了对KubeEdge项目进行更加全面的安全评估，KubeEdge社区联合ADA LOGICS公司、OSTIF及云原生计算基金会（CNCF）对KubeEdge项目进行安全评估并输出安全评估报告，分析和总结KubeEdge项目的安全威胁模型及相关安全问题。该评估对KubeEdge项目的安全防护有重要的指导意义，感谢ADA LOGICS公司的专家Adam Korczynski和David Korczynski在该项工作中的巨大贡献，同时，感谢OSTIF的Amir Montazery和Derek Zimmer以及CNCF基金会，他们对这次评估提供了很大帮助。对于安全报告中发现的安全问题，KubeEdge社区已根据社区的漏洞处理策略第一时间完成修复，并针对v1.11、v1.10、v1.9三个版本发布了安全补丁，版本号分别为v1.11.1、v1.10.2和v1.9.4，漏洞公告已发布在cid:link_4。接下来将通过解读KubeEdge威胁模型，为边缘计算领域提供更多的安全防护经验，并在开源软件供应链安全加固工作上为更多的开源社区提供参考。威胁模型分析KubeEdge的安全审计报告指出，该系统可能受到外部攻击、内部操作人员的不当操作和供应链攻击等三种潜在攻击类型的影响。本章节使用STRIDE威胁建模方法，结合安全审计报告对KubeEdge进行了系统的安全分析，包括上述三个方面。目的是帮助开发者和用户了解系统中的潜在安全威胁、明确风险并列举出目前KubeEdge社区已有的消减机制和安全加固建议。以下人群使用KubeEdge过程中，了解KubeEdge的威胁模型分析和可能的缓解措施将对他们的工作有所帮助：• KubeEdge的贡献者：一个通用的威胁模型对KubeEdge贡献者很有用，他们可以从整体角度考虑并加固他们的系统。• 部署KubeEdge的组织：对于在集群中使用KubeEdge的组织来说，了解常见的攻击和可能的弱点是很有用的，这样他们就可以检查和评估自己的配置。• 安全评估员：负责评估KubeEdge及所属Kubernetes集群的安全性。通过了解该威胁模型，让安全评估员可以对系统的安全风险进行更加全面的评估。• KubeEdge的用户及其开发人员：需要了解KubeEdge的更新和攻击，以主动避免未来可能发生的安全风险。外部攻击分析根据STRIDE威胁建模方法对KubeEdge潜在的外部攻击进行分析，对应的数据流图如下。如数据流图所示，当数据流穿越不同的信任级别（区域）时，就存在信任边界，已在图中用红框标出。下面将详细分析KubeEdge系统架构中的信任边界（引用自KubeEdge第三方安全报告）、社区已有的消减措施并给出安全加固建议。威胁一：云端CloudCore组件与EdgeCore组件之间的连接描述：该威胁涉及边缘EdgeCore与云端CloudCore之间的连接。在这个数据流中，较低信任级别组件EdgeCore向较高信任级别组件CloudCore发起访问。由于EdgeCore在系统中拥有独立的权限级别，攻击者控制EdgeCore后，不应该能够对其他边缘节点造成负面影响，例如通过攻击和操控CloudCore来攻击其他节点（该漏洞描述引用自安全评估报告）。影响：攻击者恶意修改CloudCore与EdgeCore组件之间的请求和应答报文，导致通信过程存在仿冒和篡改的威胁风险。消减措施：• CloudCore与EdgeCore之间的通信通过数字签名证书加密和服务端/客户端双向认证的方式保障信息交互的机密性和完整性，安全加密协议使用TLS 1.2，且指定加密算法套件白名单，防止客户端使用不在白名单中的不安全算法进行通信造成安全风险；• 证书默认有效期为一年，过期后失效，防止证书被攻击者利用。用户基于KubeEdge项目已有的证书轮转机制，可以实现证书过期自动更换，保障业务连续性。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 1和2）。威胁二：边缘组件ServiceBus在本机范围内提供HTTP服务描述：边缘组件ServiceBus监听本地local host端口并在本机范围内提供HTTP服务。该数据流中，较低信任级别的用户应用进程向较高信任级别组件ServiceBus发起访问。如果发起攻击，不应该使攻击者能够将影响范围扩大到云端控制面（该漏洞描述引用自安全评估报告）。影响：ServiceBus组件收到的数据往往是不受管理面控制的，攻击者能够对ServiceBus组件发起恶意报文攻击，导致通信过程存在仿冒和篡改的威胁风险。ServiceBus组件异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。消减措施：• ServiceBus组件仅监听本地local host端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；• 服务端接收客户端连接时记录连接访问的日志，可作为审计日志，可以让管理员及时发现攻击的发生，并及时停止ServiceBus服务，阻止攻击继续进行；• ServiceBus服务默认关闭，遵守默认安全的原则。在用户使用文档中已明确提示用户如果开启该服务，则存在上述风险。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4和5）。威胁三：边缘端Device通过MQTT Broker连接到EdgeCore描述：边缘device设备通过MQTT Broker（集成在EventBus组件中）连接到EdgeCore。该数据流中，较低信任级别的用户device设备向较高信任级别组件EdgeCore发起访问（该漏洞描述引用自安全评估报告）。影响：EdgeCore组件收到的数据往往是不受管理面控制的，攻击者能够对MQTT Broker发起恶意报文攻击，存在仿冒和篡改的威胁风险。如果发起攻击导致EventBus组件异常，异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。消减措施：• MQTT Broker仅监听在本机端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；同时，EventBus组件可作为客户端，对接外置第三方MQTT Broker，如果用户使用第三方MQTT Broker，详细的消减措施请参考对应第三方MQTT Broker服务提供厂商的安全文档。• EventBus仅对MQTT Broker中的特定Topic进行处理，用户无法通过该通道对EdgeCore任意访问。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4、5和6）。威胁四：Edged管理和监控Pods及其他K8s资源描述：Edged管理和监控Pods及其他K8s资源。该数据流中，较低信任级别的应用容器与较高信任级别组件EdgeCore之间进行数据交互。如果主动发起连接时，被恶意服务器攻击，不应该使攻击者能够将影响范围扩大到云端控制面（该漏洞描述引用自安全评估报告）。影响：如果Edged访问的CRI插件被攻击者恶意伪造，则存在CRI插件仿冒和篡改的威胁风险，导致本地业务异常。消减措施：• Edged与CRI插件通信时，只在本地访问受信任路径，由管理员控制访问路径，最小化Unix domain sockets文件描述符的权限，避免被仿冒者恶意替换。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3和7）。威胁五：MetaServer在边缘节点提供HTTP服务描述：MetaServer作为边缘“api-server”，对边缘插件提供HTTP服务。该数据流中，较低信任级别的用户应用插件向较高信任级别组件MetaServer发起访问（该漏洞描述引用自安全评估报告）。影响：MetaServer组件收到的数据往往是不受管理面控制的，攻击者能够对MetaServer组件发起恶意报文攻击，导致通信过程存在仿冒和篡改的威胁风险。MetaServer组件异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。消减措施：• MetaServer组件仅监听本地local host端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；• MetaServer服务默认关闭，遵守默认安全的原则。在用户使用文档中已明确提示用户如果开启该服务，则存在上述风险。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4和5）。内部攻击分析对于内部管理员或操作人员，可能的风险主要包括管理员或操作人员错误操作将恶意软件部署至集群中、在高风险场景中执行高风险配置等。消减措施：• KubeEdge用户手册中已提供各个组件的详细功能描述及配置使用指导文档 ，指导系统管理员或操作人员正确操作，减少人为误操作或误配置导致的安全风险。由于KubeEdge的持续迭代，该文档也将持续更新并完善。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4、8和9）。供应链攻击分析攻击可能发生在典型软件供应链的每一个环节，而且在当今环境中，这些类型的攻击越来越公开，破坏性和代价高昂。攻击方向包括源代码完整性、构建完整性和构建产物的可用性。消减措施：• 社区联合安全公司对KubeEdge软件供应链流程已进行SLSA等级评估，并引入SLSA软件供应链安全评估框架，包括对源代码、构建流程、依赖库等进行安全评估，防止针对软件供应链的攻击，从源头上保障软件供应链的安全。值得一提的是，在2023年1月18日发布的v1.13.0版本中，KubeEdge项目已达到SLSA L3等级（包括二进制和容器镜像构件），成为CNCF社区首个达到SLSA L3等级的项目，并加入Sigstore生态系统，实现更高等级的安全标准。• KubeEdge仓库CI/CD流水线中已开启dependence bot第三方依赖库检查功能，及时发现第三方依赖库的安全漏洞并在KubeEdge版本中同步更新，降低被攻击的风险；• KubeEdge security team已具备完整漏洞处理机制，包括漏洞发现、漏洞上报、漏洞分析处理、漏洞披露和发布整个流程，可以及时处理和修复安全漏洞。详细漏洞处理及披露策略请见https://github.com/kubeedge/community/blob/master/security-team/SECURITY.md。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 10和11）。安全加固建议列表Recommendation ID描述1使用安全长度的私钥加密，并加密保存私钥。建议用户生成至少为2048位私钥，且在本地加密存储私钥，存储私钥的文件设置最小化的访问权限，仅属主可读。2使用可信来源的CA证书。从可信的CA获取数字证书，不使用自签名证书。3严格限制边缘节点的本机权限，限制外部用户的用户登录权限，减少非必要的授权。4严格限制边缘节点应用部署的权限，只有系统服务和管理员才能拥有部署特权容器的权限。5在边缘节点部署应用时，严格校验应用镜像的合法性，防止部署恶意应用。6对于接入边缘节点的Device设备进行严格审核，避免非必要设备接入。7严格审查CRI插件的配置，使用CRI对应插件的官方推荐配置。8严格划分系统中各个角色权限，通过RBAC、OPA等方式实现系统角色权限的细粒度控制。9社区发现漏洞后将在最近的3个minor release版本中合入解决，用户可以关注社区security advisory 获取漏洞披露信息，及时跟进并更新KubeEdge版本。10用户使用社区发布的二进制文件前，应该根据社区发布的校验文件进行严格校验，防止二进制被仿冒和篡改。社区release软件包发布地址cid:link_6。11用户或vendors在使用源代码构建过程中，应该参考SLSA软件供应链安全评估框架，对源代码、构建流程、依赖库等进行安全加固。开源安全洞察本章节通过对OpenSSF社区的战略规划、OpenSSF工作组内容及开放源代码软件安全动员10个TOP计划进行介绍，为相关从业人员、开源生态产业提供参考。1) OpenSSF介绍社区工作组为了更好的提升开源软件安全，OpenSSF目前已成立了8个工作组，主要负责开源软件开发最佳实践、软件代码安全、用户、安全工具链、开源项目安全威胁识别、软件供应链完整性、保护关键开源项目、漏洞披露。相关项目1. OpenSSF最佳实践徽章（OpenSSF Best Practices Badge Program）开源软件开发的最佳实践目的是提供开源开发者安全相关行业标准、框架、安全指导、课程、开源安全评估体系、包括工具支持开发人员日常开发过程的软件安全检测。开源项目可以通过OpenSSF最佳实践徽章项目进行最佳实践评估，该项目是自由/开源软件（FLOSS）项目展示其遵循最佳实践的一种方式。可以通过使用这个网站来解释他们如何遵循每个最佳实践，从而自愿地进行自我认证，认证分为通过、银、金三个级别，不需要任何费用。该项目是基于核心基础设施倡议（CII）项目发展而来。2. 积分卡（Scorecards）通过Scorecards积分卡项目可以实现自动化地对开源项目相关安全指标进行评估，以加强项目的安全状况，根据项目的评估结果给出0-10分数，帮助项目maintainer改进项目安全。3. 安全知识框架（Security Knowledge Framework）SKF是一个完全开源的Python-Flask / Angular网络应用程序，它使用许多其他的开源项目来训练你和你的团队通过设计来构建安全的应用程序。其涵盖了整个软件开发生命周期如构建、测试、需求、设计、代码开发、度量、培训等环节。4. 安全开发指南提供安全开发、安全评估的详细指导步骤，以开发者使用视角将上面的项目全部串接起来，已完整覆盖了OpenChain Security Assurance Specification、SLSA、工具如 GitHub's dependabot、GitLab dependency scanning、Scorecards check等。5. 教育与培训课程提供开发人员免费的安全开发课程，完成学习后可以发放证书有效期2年。6. 软件构建供应链级别（SLSA）软件构建的供应链级别SLSA由Google贡献给OpenSSF，是软件供应链完整性的安全标准准则，以帮助企业和开源生态确保软件开发生命周期的安全，ScoreCards是SLSA度量的工具组成部分。7. 令牌分发项目Great Multi-Factor Authentication (MFA) 分发项目。致力于将硬件 MFA 令牌分发给关键的 100+开源软件项目，目标是防止开源软件开发凭据薄弱或受损的供应链攻击。8. 包管理最佳实践提供业界主流的构建框架、包管理器的最佳实践如 maven、gradle、npm、pip、RubyGems，重点介绍其依赖管理、可重复构建、发布、基于包管理的漏洞披露等。当前文档还不完善，只重点介绍了npm，其它的包管理器待建设中。9. C/C++编译选项制定 C/C++场景的编译选项规则，避免潜在的安全风险和被攻击的风险。当前在孵化阶段。10. 开源社区安全教育SIG当前在孵化阶段，主要致力于提供行业标准的安全软件开发相关的培训材料，提供网络和应用程序安全方面的最佳实践辅导开发人员安全地创建、编写、部署和维护软件。OpenSSF安全工具链安全领域涉及面广，规则规范多，开发人员甚至从事资深安全工作的专家人工识别冗余遗漏。安全工具链用于快速识别安全风险，使开发人员专注于功能特性开发。覆盖范围：涵盖整个DevSecOps的各环节工具链，并支撑开源软件开发的最佳实践章节，如：linters(cleanCode), SAST, SCA, DAST, Fuzzers, Hard Coded Secrets Detectors, and SBOM generators。提供方：部分来自公司捐赠，部分来自OpenSSF基金会自主规划，部分在规划阶段待建设。2) 开源软件安全动员计划及目标2022 年 1 月，美国政府专家、 OSS 基金会、相关企业在白宫举行会议讨论，制定如下三个动员计划的总体目标：• 保护 OSS 生产：首先是专注于防止安全缺陷、代码和开源包漏洞• 改进漏洞识别和修复：改进缺陷识别过程、漏洞修复• 缩短补丁响应时间：缩短漏洞披露和修复时间在2022年5月第二届开源软件安全峰会上，Linux基金会、OpenSSF及各行业安全专家，就提高开源软件安全性计划达成共识，将集中在以下10个方向进行投资和安全改善，项目投资1.5亿美元，分为两年规划。备注：动员计划和OpenSSF工作组是相辅相成的，其动员计划的能力会融入到工作组中。投资方向描述安全培训向所有人提供基础安全软件开发培训和认证。风险评估为前 10,000 个（或更多）OSS 组件建立一个公开的、供应商中立的、客观的、基于指标的风险评估仪表板。数字签名加快在软件版本上采用数字签名。内存安全通过替换非内存安全语言来消除大多数漏洞的根本原因。事件响应建立一个由安全专家组成的 OpenSSF 事件响应团队，以协助开源项目加快对新发现漏洞的响应速度。安全扫描通过高级安全工具和专家指导，加快维护人员和专家发现新漏洞的速度。代码审计每年对200+个最关键的OSS组件进行一次第三方代码审查（以及任何必要的补救工作）。数据共享协调全行业的数据共享，以改善研究，帮助确定最关键的开放源码软件组件。SBOMs改进SBOM工具和培训，以推动采用。提升软件供应链安全用更好的供应链安全工具和最佳实践来增强10个关键的开放源码软件构建系统、软件包管理器和分发系统。▎总结本文通过从外部攻击面、内部攻击面及软件供应链三个维度对KubeEdge项目进行安全威胁建模，实现对KubeEdge项目的系统性安全评估，帮助社区maintainer及时发现和修复安全风险。同时，对业界OpenSSF社区开源安全策略及相关项目进行洞察，通过洞察分析可以看出，越来越多的组织、开发人员、研究人员和安全专家将加大投入资源来加强开源安全，并已逐步形成业界开源安全行业的生态产业链，在开源安全上占据标准高地可以为后续的商业扩展提供有力地位。KubeEdge社区结合业界安全理念，将能够推动社区持续巩固和演进项目的安全。▎附录相关链接• 社区漏洞处理机制: cid:link_5• 安全审计报告: cid:link_1• 社区security advisory链接: cid:link_4• KubeEdge威胁模型及安全防护分析（本文档）: cid:link_0• 社区用户文档链接: https://kubeedge.io/en/docs• SLSA软件供应链安全框架: https://slsa.dev/spec/v0.1/#supply-chain-threats• KubeEdge实现SLSA L3分析: https://kubeedge.io/en/blog/reach-slsa-l3/• Release版本发布链接: cid:link_6• 开源软件安全动员计划：https://cta-redirect.hubspot.com/cta/redirect/8112310/3b79d59d-e8d3-4c69-a67b-6b87b325313c• OpenSSF最佳时间徽章：https ://bestpractices.coreinfrastructure.org/en• 最佳实践项目：https://github.com/ossf/wg-best-practices-os-developers添加小助手微信k8s2222，进入云原生交流群

华为云海外首发CCI Serverless容器服务，释放数字生产力在MWC23 巴展期间，华为新产品解决方案发布会在2月27日下午成功举行。在发布会上，华为云全球Marketing与销售服务总裁石冀琳表示：我们希望通过“一切皆服务”的战略，为客户、伙伴和开发者提供稳定、可靠、安全、可持续的云服务。在本次发布会上，华为云海外首发CCI Serverless容器服务正式上线。基于serverless容器架构CCI，客户无需创建和管理服务器节点，即可直接运行容器应用，按需获取、智能运维，让客户只需专注应用开发，无需关注底层资源。具备业务领先的弹性能力，助力客户轻松应对超10倍的突发流量浪涌。CCI Serverless容器具备优势如下：• 聚焦应用免运维1. Serverless无服务器容器使用全新体验2. 客户无需管理服务器或集群• 极致计算性能1. 瑶光统一资源池，提供多种X86、AXD、鲲鹏等类型算力资源2. 全面升级资源拓扑管理能力，保障容器极致算力性能• 智能统筹弹性1. 30秒发放1000容器，满足极速弹性要求2. 支持跨云、跨集群、跨IDC对接的灵活弹性，全场景助力客户业务应对峰值流量    Serverless容器构筑极致性能、高效运维、丰富算力等差异化竞争力，打造大规模高性能云原生Serverless容器资源底座。Source : 华为官网新闻报道KubeEdge 社区 v1.13.0 版本发布，稳定性、安全性大幅提升KubeEdge社区v.1.13.0版本发布。作为2023年最新版本，v.1.13.0性能在稳定性、安全性等方面进大幅提升，其中重大更新如下：• 运行性能提升：对CloudCore 内存使用减少 40%，优化List-watch dynamicController处理，增加云端和边缘之间的list-watch同步机制，增加dynamicController watch gc机制。• 安全性能提升：成为CNCF首个达到软件供应链SLSA L3等级的项目；同时删除边缘节点配置文件 edgecore.yaml 中的 token 字段，消除边缘信息泄露的风险• 对Kuberbetes支持升级至v.1.23.15: 将vendered kubernetes版本升级到v1.23.15，用户现在可以在云端和边缘使用新版本的特性。• 基于 DMI 的 Modbus 映射器：提供基于DMI的Modbus Device Mapper，用于接入Modbus协议设备。• EdgeMes​​h：向边缘隧道模块添加了可配置字段 TunnelLimitConfigedge-tunnel模块的隧道流用于管理隧道的数据流状态。用户可以获得稳定、可配置的隧道流，保证用户应用流量转发的可靠性。KubeEdge云原生边缘计算社区于2022年完成多项关键突破，相继发布《KubeEdge单集群10万边缘节点报告》，《云原生边缘计算威胁模型及安全防护技术白皮书》，并于KubeEdge Summit 2022正式开源分布式协同AI基准测试平台Ianvs。目前项目已完成EdgeMesh高可用架构，KubeEdge on openEuler支持，KubeEdge on openHarmony支持，下一代云原生边缘设备管理框架DMI也将带来更全面的的性能支持与更优的用户体验。欢迎大家测试体验。cid:link_1CNCF持续重视软件供应链安全， KubeEdge成为首个达到SLSA L3等级的项目软件供应链安全持续受到高度关注，CNCF 和OSTIF （Open Source Technology Improvement Fund，开放源码技术改进基金）在过去几年中一直合作，为CNCF 的毕业和孵化项目进行安全审计，保障开源生态系统具有更好的安全性。最新的 OSTIF 报告公布了 2022 年下半年至 2023 年初开展的独立安全审计结果。获得审计通过的项目包含KubeEdge、Argo、Istio、Envoy、CloudEvents等12个项目：审计工作通过创建良好的指导性政策和项目成熟度模型，以及可重复的审计执行流程，以确定风险、威胁媒介并实施工具来改善项目的安全状况。提升项包含：在本次公布的社区中，KubeEdge社区早在2022年7月份，通过完成整个KubeEdge项目的第三方安全审计[2] ，发布《云原生边缘计算安全威胁分析和防护白皮书》，并根据安全威胁模型和安全审计的建议，对KubeEdge软件供应链进行持续安全加固，为本次SLSA L3等级的达成做了充分的准备。在2023年1月18日，社区发布v1.13.0版本，该版本达到SLSA[1] L3等级标准（包括二进制和容器镜像构件），KubeEdge 成为CNCF社区首个达到SLSA L3等级的项目。以下表格展示了KubeEdge在Source、Build、Provenance、Common中的达标情况（Y表示KubeEdge已达标，空格表示SLSA在该等级下未要求）：RequirementL1L2L3L4SourceVersion controlledYYYVerified historyYYRetained indefinitelyYYTwo-person reviewedYBuildScripted buildYYYYBuild serviceYYYBuild as codeYYEphemeral environmentYYIsolatedYYParameterlessYHermeticYProvenanceAvailableYYYTo-doAuthenticatedYYTo-doService generatedYYTo-doNon-falsifiableYTo-doDependencies completeTo-doCommonSecurityYAccessYSuperusersY为什么达到SLSA L3等级对开源项目至关重要软件供应链完整性攻击（对软件包的未经授权的修改）在过去三年中呈上升趋势。SLSA在KubeEdge项目软件供应链安全中发挥着重要作用，基于sigstore社区提供的能力，从源码到发布产物，对软件供应链端到端的整个流程进行签名和校验，确保KubeEdge软件供应链安全。自v1.13.0版本开始， KubeEdge 可以端到端的从源码构建到发布流程进行安全加固，保障用户获取到的二进制或容器镜像产物不被恶意篡改。基于SLSA安全框架，可以潜在地加强软件构件的完整性。SLSA提供端到端的指导原则，可以作为软件的一组防御措施，并防止对组成软件产品的软件包的篡改或任何类型的未经授权的修改。采用SLSA框架可以保护项目软件免受常见的供应链攻击。参考资料[1]  SLSA官网：https://slsa.dev/[2]   KubeEdge项目第三方安全审计：cid:link_0Karmada v1.5 新增多调度组助力成本优化Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。在最新发布的1.5版本中，Karmada 提供了多调度组的能力，利用该能力，用户可以实现将业务优先调度到成本更低的集群，或者在主集群故障时，优先迁移业务到指定的备份集群。本版本其他新增特性：• 提供了多调度器支持能力，默认调度器可以与第三方自定义调度器协同工作，提供更强的定制能力。• 集群差异化配置策略（OverridePolicy/ClusterOverridePolicy）将按照隐式的优先级进行应用。• 内置资源解释器支持聚合StatefulSet/CronJob 状态。Karmada v1.5版本API兼容v1.4版本API，v1.4版本的用户仍然可以平滑升级到v1.5版本Volcano 社区 v1.7.0 版本正式发布，提升云原生调度能力，强化AI、大数据场景适用度北京时间2023年1月9日，Volcano社区v1.7.0版本正式发布。Volcano是业界首个云原生批量计算项目，项目于2019年6月在上海的KubeCon大会上正式宣布开源，并于2020年4月成为CNCF官方项目。2022年4月，Volcano正式晋级为CNCF孵化项目。Volcano社区开源以来，受到众多开发者、合作伙伴和用户的认可和支持。截止目前，累计有490+全球开发者向项目贡献了代码。Volcano v1.7.0版本在主流计算框架支持、通用服务调度能力、队列资源可观测性等方面进行了增强，新增特性列表如下：• Pytorch Job插件功能强化• Ray on Volcano• 增强Volcano对Kubernetes通用服务的调度能力• 支持Volcano的多架构镜像• 优化队列状态信息等本次版本发布后，Volcano可以更好的适用AI、大数据场景，为使用者提供更简洁易用的Ray、Pytorch等工作负载的云原生调度能力。Volcano云原生批量计算项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。社区已吸引2.6万+全球开发者，并获得2.8k Star和670+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书等。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、mxnet、KubeGene、Ray等众多主流计算框架的支持，并构建起完善的上下游生态。ING国际银行基于Volcano开展大数据分析作业，获得Kubernetes更高调度性能在 KubeCon North America 2022， ING荷兰国际集团（International Netherlands Groups）发表了《Efficient Scheduling Of High Performance Batch Computing For Analytics Workloads With Volcano - Krzysztof Adamski & Tinco Boekestijn, ING》主题演讲，重点介绍了云原生批量计算项目Volcano如何在数据管理平台中为大数据分析作业提供高性能调度工作。ING荷兰国际集团（International Netherlands Groups）是一个国际金融服务私营企业，成立于1991年，由荷兰最大的保险公司Nationale-Nederlanden，与荷兰的第三大银行NMB PostBank Group合并而成。ING集团的服务遍及全球40多个国家，核心业务是银行、保险及资产管理等。ING集团的全球职员大约56,000人，顾客5320万人，包括自然人、家庭，企业、政府及其他等，例如基金组织。在银行行业有许多法规和限制，ING布局符合自身产业的DAP平台（Data Analytics Platform），为全球50%的ING员工提供安全的、自助的端到端分析能力，帮助员工在数据平台之上构建并解决业务问题。在本次以Volcano为案例的演讲中，ING 重点指出Volcano对批处理任务调度做了很好的抽象，使其在Kubernetes平台能够获得更高的调度性能，后面ING也会将开发的功能逐步回合社区，比如：DRF Dashboard、在每个节点添加空闲空间、自动队列管理、更多的Prometheus监控指标、Grafana仪表盘更新、kube-state-metrics更新和集群角色限制等。Volcano 2019年由华为云捐献给云原生计算基金会（CNCF），也是 CNCF 首个和唯一的容器批量计算项目，帮助用户将 AI、大数据、HPC等计算密集型的业务从传统的系统快速迁移到云原生平台，加速整个云原生落地的进程。Kurator v0.2.0 发布！助力企业分布式云原生应用升级Kurator是华为云开源的分布式云原生平台，帮助用户构建属于自己的分布式云原生基础设施，助力企业数字化转型。Kurator v0.1 版本通过一键集成 Karmada，Volcano，Istio，Prometheus 等主流开源项目，提供了分布式云原生的统一多集群管理，统一的调度，统一的流量治理以及统一的应用监控能力。在最新发布的 v0.2.0 中，Kurator 新增两大类关键特性，增强了可观测性并新增了集群生命周期管理，具体包括以下重大更新。• 基于Thanos的多集群监控及指标持久化存储• 基于Pixie实时的K8s应用监控• 支持本地数据中心集群生命周期管理• 支持AWS云上自建集群生命周期管理Kurator由此开始提供分布式云原生基础设施的管理。这意味着，从此Kurator可以依托基础设施、Kubernetes集群，更好的管理各种云原生中间件，为用户提供开箱即用的分布式云原生能力。Kurator，一键构建分布式云原Kurator于2022年6月在华为伙伴暨开发者大会上开源，是业界首个开源分布式云原生平台。通过集成业界主流开源技术栈以及良好云原生舰队管理性能，Kurator为用户提供一站式、开箱即用的分布式云原生能力，打造分布式云原生技术底座,助力企业业务跨云跨边、分布式化升级。Istio宣布2023年指导委员会席位，华为占两席2月6日，Istio社区宣布2023年指导委员会（Steering Committee）席位。Istio 指导委员会[1]，由 9 个贡献席位（根据企业对项目的贡献按比例分配）和 4 个选举产生的社区席位组成。每年 2 月，社区都会根据年度商定的指标[4]，查看哪些公司对 Istio 的贡献最大并进行公布。华为云已连续三年获得Istio委员会席位(Steering Committee成员2名,全球仅8家公司13人）；Maintainer 2名，Member 10+名。过去几年，华为云Pull Request 位于全球TOP 3，Contributions TOP 3(1.9w+）。由华为云技术团队撰写并出版的《云原生服务网络Istio：原理、实践、架构与源码解析》一书，是业内最有影响力的服务网络书籍之一。目前，华为云应用服务网格（ASM）也已服务于互联网、汽车、制造、物流、政府等多个行业的近千家客户，满足不同行业客户的业务诉求。华为云将在此过程中积累的丰富经验，转化为代码贡献给Istio社区，极大地推动了Istio技术的成熟和社区的快速发展。同时，华为云还大力投入服务网格的技术布道，通过社区论坛、技术会议、视频直播、专业书籍等各种方式，推动服务网格技术传播和普及。添加小助手微信k8s2222，进入云原生交流群

​63个云原生课程视频，基本上包含了整个云原生学习周期里这些都是你得花心思掌握的。内容比较细，基本上满足实操需求，涉及到容器技术、K8s、监控、运维、存储，以及比较前沿的 istio 等等……适用人群：高校学生、企业中的个人开发者以及互联网从业人员。>>>戳我查看云原生开发者学习路径 在线课程添加小助手微信k8s2222，进入云原生技术交流群 

在边缘计算的浪潮中，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

北京时间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”进入技术交流群

大会介绍：5月27日-28日，GOTC 全球开源技术峰会（（Global Open-source Technology Conference）在上海张江科学会堂成功举办。 GOTC是由上海浦东软件园、开放原子开源基金会、Linux 基金会亚太区和开源中国联合发起的，面向全球开发者的一场盛大开源技术盛宴。 本届大会以“Open Source, Into the Future”为主题，国际开源大咖、专家学者和产业代表齐聚一堂，超 1500 人现场参会， 540 万+人次线上直播观看，全网曝光量达3 亿+( 数据来源：CNCF），共同探讨开源未来，助力开源发展。议题分享：不同角度谈开源及开源人才培养讲师介绍：华为云云原生开源负责人王泽锋议题简介：在“Linux 基金会开源教育及人才培养峰会”分会场，各界大咖从不同角度深入探讨了国内开源教育和人才培养的重要性和挑战。此外，基于华为云在 LFOSSU x 华为云云原生人才培养计划，华为云云原生王者之路训练营，Volcano云原生批量计算公开课，KubeEdge云原生边缘计算公开课等行业人才培养领域的杰出贡献，华为获评“2022年度优秀开源人才培养企业“称号。点击视频观看本次分享精彩回放，添加小助手微信k8s2222回复KubeEdge，进入技术交流群video

大会介绍：5月27日-28日，GOTC 全球开源技术峰会（（Global Open-source Technology Conference）在上海张江科学会堂成功举办。 GOTC是由上海浦东软件园、开放原子开源基金会、Linux 基金会亚太区和开源中国联合发起的，面向全球开发者的一场盛大开源技术盛宴。 本届大会以“Open Source, Into the Future”为主题，国际开源大咖、专家学者和产业代表齐聚一堂，超 1500 人现场参会， 540 万+人次线上直播观看，全网曝光量达3 亿+( 数据来源：CNCF），共同探讨开源未来，助力开源发展。议题分享：云原生边缘智能设备管理框架KubeEdge DMI讲师介绍：华为云云原生团队高级工程师赵然；DaoCloud 边缘计算开源技术专家刘琛林议题简介：边缘设备管理是边缘计算中的一个重要应用场景，面临诸多问题，如边缘设备生命周期管理、边缘设备映射云原生数字孪生模型、轻量级边缘框架、海量边缘设备采集的数据如何进行存储、分发、消费等等。 KubeEdge是基于Kubernetes构建的云原生边缘计算开源平台，已成为CNCF的孵化项目。KubeEdge支持复杂边云网络环境下的云边应用协同，并提供边缘设备管理框架(DMI)，以云原生数字孪生模型的形式支持多种协议的边缘设备管理。 本议题介绍了KubeEdge的设备管理框架DMI。在DMI框架设计下，设备不再是单纯的数据源，而是被抽象为微服务，以云原生的方式为设备数据消费者提供数据服务。DMI框架下的设备数据访问支持多种场景，非常灵活。DMI框架可以为基于KubeEdge的边缘智能设备云原生化管理提供有力支持。 本议题为双人议题，与上海道客网络科技有限公司研发工程师、KubeEdge社区Member刘琛林共同分享。点击视频观看本次分享精彩回放，添加小助手微信k8s2222回复KubeEdge，进入技术交流群video

大会介绍：5月27日-28日，GOTC 全球开源技术峰会（（Global Open-source Technology Conference）在上海张江科学会堂成功举办。 GOTC是由上海浦东软件园、开放原子开源基金会、Linux 基金会亚太区和开源中国联合发起的，面向全球开发者的一场盛大开源技术盛宴。 本届大会以“Open Source, Into the Future”为主题，国际开源大咖、专家学者和产业代表齐聚一堂，超 1500 人现场参会， 540 万+人次线上直播观看，全网曝光量达3 亿+( 数据来源：CNCF），共同探讨开源未来，助力开源发展。议题分享：KubeEdge 车云协同平台创新实践讲师介绍：华为云云原生开源负责人王泽锋议题简介：云原生技术栈为软件定义汽车以及车云协同平台打开了全新的演进路径。基于KubeEdge构建车云协同平台，加速了汽车软件平台的云原生化，实现从FOTA到SOTA的架构升级以及车路协同的架构统一。未来社区将继续围绕开源与业界一起推动云原生技术在汽车领域的探索与实践。点击视频观看本次分享精彩回放，添加小助手微信k8s2222回复KubeEdge，进入技术交流群videovideo

大会介绍：5月27日-28日，GOTC 全球开源技术峰会（（Global Open-source Technology Conference）在上海张江科学会堂成功举办。 GOTC是由上海浦东软件园、开放原子开源基金会、Linux 基金会亚太区和开源中国联合发起的，面向全球开发者的一场盛大开源技术盛宴。 本届大会以“Open Source, Into the Future”为主题，国际开源大咖、专家学者和产业代表齐聚一堂，超 1500 人现场参会， 540 万+人次线上直播观看，全网曝光量达3 亿+( 数据来源：CNCF），共同探讨开源未来，助力开源发展。议题分享：Istio Ambient Mesh Present and Future讲师介绍：华为云云原生团队开源技术专家徐中虎议题简介：在“Cloud Native Summit”云原生分会场，华为云云原生团队开源技术专家， Google Open Source Peer Bonus获得者徐中虎介绍了当前 Istio 社区最热门的新技术Ambient Mesh, 并从功能、安全、资源开销等多方面与Sidecar模式对比，以辨证的角度分析Ambient Mesh对一些典型场景会非常有力，但它的发展距离生产可用，还有一段挺长的距离。点击视频观看本次分享精彩回放，添加小助手微信k8s2222回复Istio，进入技术交流群video