这个练习赛当日的maps不能公布文件嘛/ll以及，这个数据是在范围内纯随机吗/ll

AI原生应用引擎可以进行低码应用开发吗？

AI原生应用引擎的优势是哪些？

全球顶级开源组织云原生计算基金会(Cloud Native Computing Foundation，简称 CNCF)正式宣布其2024年技术监督委员会(Technical Oversight Committee，简称CNCF TOC)席位，华为云云原生开源负责人王泽锋，凭借其在CNCF领域长期卓越的贡献成功当选，成为本届 CNCF TOC 11位技术领军人物之一。CNCF致力于云原生技术的普及和可持续发展，汇集世界顶级厂商，发展至今会员单位已超过750+。CNCF技术监督委员会是CNCF的核心决策团队，为云原生社区提供技术领导，决定CNCF社区的技术走向，由董事会、Maintainer以及End User等多个选区投票产生。一直以来，CNCF TOC主要以欧美专家为主，本届选举中，华为云开源专家王泽锋获得CNCF Maintainer广泛支持，凭借Maintainer选区最高票当选新一届CNCF TOC委员（2024-2026任期）。这也标志着其个人及华为在云原生领域的持续贡献获得产业界的高度认可，代表了整个中国本土贡献者在国际舞台上开源影响力的新高度。云原生产业规模和前景巨大，不少技术领域仍然处于窗口期，可谓机遇与挑战并存。王泽锋表示：“中国在全球云原生产业发展中拥有非常明显的优势：巨大的数字经济规模、丰富的应用场景，不断推动技术层面的创新；不少本土科技公司凭借技术实力已在云原生的核心赛道中占据了重要位置。作为CNCF TOC的新任成员，我将致力于更好地联接国内以及国际开源社区，借助CNCF、华为等平台及资源，携手更多企业、开源组织、学术机构及广大开发者一起，共同推动云原生技术发展与产业标准化，赋能千行万业的数字化转型。”王泽锋：协作创新，共建更有生命力的开源社区作为最早来自中国的Kubernetes维护者之一，王泽锋早在2014年基于 Upstream first 的理念，参与 Kubernetes 上游社区贡献，并于2015年成为了国内最早的 Kubernetes maintainer 之一，其主导的 Kubernetes 社区的多个关键特性和子项目的设计研发工作在社区完成开发后被大量企业用户在生产环境中广泛使用；与此同时，他指导了超过30名开发人员成为Kubernetes和其他CNCF项目的业务骨干、核心开发者。2018 年，王泽锋与同事联合创立了业界首个云原生边缘计算项目KubeEdge 开源项目，并捐赠到 CNCF 基金会，通过开放社区的治理模式与业界开发者协作共享。KubeEdge 也因此成为 CNCF 第一个将云原生技术应用到边缘计算的开源项目。时至今日，KubeEdge 在交通、能源、通信、金融、工业制造、CDN、智慧园区等各行各业已经有了更加深广的应用和普惠价值。此外，他还发起了 Volcano云原生批量计算 、Karmada云原生多集群管理 等多个云原生开源项目，填补了云原生技术在相关领域的技术空白。作为CNCF中国大使，王泽锋在KubeCon + CloudNativeCon 程序委员会任职多年，并于 2023 年担任 KubeCon + CloudNativeCon China 联合主席。作为公认的演讲者，王泽锋多次在 KubeCon Europe 和 KubeCon China 上发表Keynote和分论坛议题演讲。此外，王泽锋一直是Kubernetes贡献者峰会的长期支持者，联合规划和组织多场KCS China、KCD，并从2018年开始，联合策划了 “Cloud Native Days China”系列 Meetup、“Cloud Native Lives”等一系列业内活动；与此同时，由他发起的系列云原生技术公共课程，帮助超过百万的中国开发者构筑云原生技术交流平台，学习和采用云原生技术。技术先驱，引领全球云原生生态圈作为CNCF亚洲唯一创始成员、白金成员，华为对 Kubernetes、Istio 等社区核心项目的贡献一直位居全球前列，社区影响力持续多年亚洲第一，加速了云原生技术从起步到成熟的过程；华为拥有10余位CNCF项目核心Maintainer，出版多部云原生领域技术书籍，是全球云原生开源技术的领导者之一。近年来，华为持续开源创新，先后向CNCF捐献业界首个云原生边缘计算项目KubeEdge、首个云原生算力调度引擎Volcano、首个多云容器编排引擎Karmada等重量级云原生项目，在网络、边缘、调度、多云等技术领域形成了相对成熟生态圈，并开源了Kurator、Kappital、Kuasar、Kmesh等创新项目，加速了云原生与边缘计算、AI、大数据等产业的融合。共享开源价值，为行业发展注入源生动力在数字经济快速演进的大背景下，开源作为数智化转型的创新驱动力，不断催生技术突破和业务创新，发挥出愈加凸显的价值。华为与业界分享生产实践经验及创新成果，与国际云原生社区共发展。未来，面向全球的云原生社区工作有何创新？王泽锋提出了他对CNCF TOC的愿景和其独特的价值：促进跨区域新贡献者和现有贡献者之间的经验分享和沟通。建立公共的维护者地图，帮助新加入的贡献者找到周围的维护者以获得支持和帮助，以新一代的维护者增进社区活力，促进项目的可持续性。建立项目导师和项目冠军机制，帮助加快新开源项目向CNCF的申请/引导过程，以及项目在CNCF沙盒和孵化器中的成长。更清晰的项目推进过程和相应的自动化工具，以减少项目维护者和TOC/TAG成员在观察和评估项目健康和项目成熟度方面所花费的时间。云原生+AI，开源加速构建AI基础设施面对AI时代迎面而来的挑战，华为云在云原生领域持续引领，打造多云场景下的AI云原生基础设施，加速构建AI时代最佳云底座。作为全球最早参与CNCF重点项目产品化的企业之一，华为云早在2015年基于Kubernetes、Istio等上游社区，推出了国内最早的商用容器产品，并于2016年发布国内首个公有云容器服务CCE（云容器引擎）。伴随华为云近年来的高速发展，目前华为云已经陆续发布Serverless容器CCI、应用服务网格ASM、智能边缘平台IEF、分布式云原生UCS等多个创新产品，连续七次登顶IDC发布的中国容器市场份额报告，这也是业界对华为云在容器领域一路领先给与的充分肯定。智能浪潮新形势下，华为云结合在云原生领域的领先优势，打造云原生多云融合基础设施，云原生AI基础设施，云原生Serverless基础设施等系列解决方案，陆续升级发布华为云CCE Turbo，华为云CCE Autopilot，Serverless云耀云容器等创新产品。由华为云开源并捐赠至CNCF的孵化级开源项目也在AI云边协同、AI混部调度、多集群算力分配等技术领域加速行业产品应用升级，为行业智能升级攻坚克难，注入源生动力。未来，华为云云原生将持续与全球开发者紧密合作，共同推进云原生技术的创新与发展，积极推动云原生技术在产业领域的深度融合应用，为促进全球数智化经济的繁荣发展贡献力量。更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

作者：本文由华为云客户迷你玩投稿背景迷你玩旗下《迷你世界》是一款国产沙盒创意平台，拥有全球数千万创作者进行去中心化内容创作，通过方块组合自由创造等方式，引导用户在平台上创作虚拟作品。2021《迷你世界》的每月活跃玩家人数已超过一亿。《迷你世界》此前面临的突出问题在于服务端的弹性：迷你世界服务器的规格较大，每个服务器上承载了很多游戏服进程，不同玩家的游戏时间上差异也比较大，为了保障深度玩家的游戏体验，即使只有一个玩家还在进行游戏，对应的游戏服务器也是不会缩容的，这必然会影响服务端整体的资源利用率和运营成本。我们期望通过容器灵活规格来解决《迷你世界》服务端的缩容问题，同时提升整个游戏系统的扩缩容、部署升级效率。挑战云原生技术以其灵活性、可扩展性和可维护性等优势，正在迅速改变企业的 IT 架构。第三方报告显示，2022年已经有超过75%的互联网公司在基于K8s部署生产业务，预期2025年这个数字将超过90%。然而在游戏场景中，k8s的还面临一些局限性。首先，游戏业务天然是有状态的，K8S原生的有状态资源StatefulSet并不擅长处理大量的、复杂的状态管理任务。其次，时延敏感性也是一个问题。在游戏中，时延直接影响到游戏的流畅度和玩家的体验，这就对K8s的容器网络实现提出了更高的要求。同时，安全性也是一个挑战。游戏服中可能包含大量的敏感信息，普通容器的隔离程度与虚拟化相比仍有一定差距。解决方案华为云CCE在网络、容器运行时上进行了增强，再配合社区workload，使能《迷你世界》后端全栈容器化，资源使用量较虚拟化部署环境减少了50+%。整体架构如下：网络方面，华为云CCE Turbo提供了一种更接近虚拟机的容器网络，这种模式下，容器成为和虚拟机等同的“一等公民”。容器网卡集成了虚拟网络的能力，比如通过CRD关联到安全组进行安全加固，更细粒度的IP地址管理等。更重要的是，这种容器网络支持Pod直接关联EIP，用户可以直接通过EIP访问应用。EIP的成本管理上，华为云提供了95计费的共享带宽，以多个EIP共享的带宽为计费单元。我们开发了专门的K8s webhook为不同的pod分配不同的共享带宽，来做到最优的成本控制。有状态应用管理方面：我们使用了OpenKruise社区的CloneSet来管理游戏服pod。CloneSet提供了pod的原地升级能力，可以在不重建pod的情况下对运行中的容器进行更新。我们还深度使用了它的定向缩容能力，通过自定义Hooks判断指定游戏服pod是否有活跃玩家，实现对游戏服缩容的精细化控制。OpenKurise的CRD配合控制器的模式在不同的K8s环境中具有良好的扩展性，只要厂商提供社区一致的API，均可正常部署运行。安全方面，当前我们的使用方式是服务端Pod与节点1:1部署，游戏服pod配置关联指定安全组，通过安全组和虚拟化对游戏服进行双重安全加固。效果《迷你世界》完成全量容器化后，在运维效率、资源成本都有了显著优化资源占用节省50%计算资源根据游戏的实施访问量自动管理，定时弹性伸缩配合指标触发的自动弹性伸缩，再加上定向缩容，资源总是能伸缩至合理水平，保障玩家的游戏体验。迭代效率提升容器化缩短了应用的迭代周期，通过灰度发布，流量治理等保证了业务平滑稳定升级，应用升级从小时级提升至分钟级。迷你玩和华为云在未来将Serverless领域加深合作：华为云容器实例服务CCI具有秒级弹性、按量计费的特性，非常贴合我们的应用场景。此外，华为云CCE提供弹性突发引擎，可以将CCI资源池以虚拟节点的方式接入CCE。基于这项能力，我们仅需将与节点强绑定的部分资源稍作调整即可将应用部署到Serverless容器服务中，进一步提升后端的弹性能力。同时CCI基于安全容器构建，独享内核，具有虚拟机级别的安全保障。下一阶段，我们考虑将部分负载逐步迁移到Serverless容器上。

Kurator 是华为云开源的面向分布式云原生环境的一站式解决方案。它利用 Karmada 作为多集群编排基础，内置集成了Istio、Prometheus、Thanos、Volcano、KubeEdge、Argo 等主流云原生技术。基于此，Kurator 构建了包括集群舰队管理、集群生命周期管理、统一应用分发、流量治理、监控和策略管理在内的分布式云平台管理能力。在最新 0.6.0 版本中，Kurator 为云原生应用增加了 CI/CD 流水线设置与管理功能，简化流水线创建。此外，强化了 0.4.0 版本发布的统一应用分发功能，可以在部署新应用时设置金丝雀（灰度）发布、A/B 测试、蓝绿发布三种渐进式发布策略。新增的流水线特性和渐进式发布功能与统一分发能力结合，实现基于代码仓库的 GitOps 工作流。这有助于快速构建分布式云原生平台，简化应用开发与发布流程。Kurator CI/CD 的结构图如下所示：用户更新代码仓库后，触发 Kurator 流水线，完成代码拉取、检查、编译并构建镜像。其后，用户更新应用部署模板，例如更改应用配置中的镜像信息。Kurator Application Controller 侦测到配置更新，将自动触发已应用的渐进式发布策略，实现应用的自动发布。如此一来，整个软件研发生命周期以代码为中心，实现开发至发布完整流程的自动化，简化运维、部署工作。  流水线  CI/CD 流水线实现源码到发布的自动化过程，包括源码管理、检查、测试等阶段。但由于每个阶段技术需求不同，导致流水线配置和管理难度大。Kurator 参考开源项目 Tekton，通过预定义常用任务模版的方式简化流水线创建操作。用户只需指定任务名称和代码仓库访问凭证即可创建流水线，使用门槛低。对熟悉流水线的高级用户，Kurator 也支持自定义任务。用户可以根据自己需求定制任务内容，满足个性化场景。通过预置任务模板和自定义任务的能力，Kurator 大幅简化了流水线配置和管理的难度。从图中可以看出，在使用流水线时，Kurator 完成了大部分工作。用户只需配置运行环境，选择任务模板即可完成流水线创建，大大减少学习成本。特别是与传统Tekton 相比，Kurator 提供了预定义任务模板，用户只关注任务内容而不再处理具体实现，实现了流水线使用的极致简化。除了简化流水线的创建操作外，Kurator 还考虑到了软件供应链安全，可以在流水线构建镜像时自动为其添加数字签名和源头证明，以防范假冒镜像，保证镜像源头可靠，保证在镜像制作方面的安全性。软件供应链安全指的是保护软件从开发到部署的整个生命周期过程中的安全性。软件供应链安全可以提高软件安全性能和用户信任度，预防恶意代码渗透。签名和证明添加后，镜像将自动上传至仓库。在镜像仓库中可以直接查看镜像签名和证明的详细情况，如图所示。用户可以用签名过程生成的公钥验证镜像签名和源头。这样在生产中,生产者仅需公布签名公钥，就能让用户验证数字签名和来源证明。接下来将展示一个在 Kurator 中创建一个流水线的示例：在流水线定义 spec.tasks 中指定任务名称，即可选择 Kurator 内置的常用任务模板。目前内置的常用任务模板包括:名称任务目标git-clone拉取源码go-test运行go代码单元测试go-lintgo源码静态检查build-and-push-image编译，构建镜像并上传此外，通过 customTask 定义可以发布自定义任务。通过指定 image、command 和 args,实现定制任务需求，如上述示例中自定义任务完成的工作就是打印README.md。更多的示例和细节，请参考: https://kurator.dev/docs/pipeline/  渐进式发布  金丝雀发布、A/B 测试和蓝绿发布都是主流的应用发布策略，可有效减少上线风险。Kurator 0.6.0 在原统一应用分发基础上，增加渐进式发布功能。现在应用可以指定三种渐进式发布策略中的一种策略。同时，可以将具备发布能力的统一分发，与 CI/CD 流水线结合起来，实现基于代码仓库的 GitOps 工作流。▍金丝雀发布金丝雀部署是一种渐进式发布策略。先向少数用户发布新的软件版本进行测试，根据测试结果，决定是否向更多用户推出新版本。旨在最大限度地减少新版本上线后对用户的影响，是一种更安全、更可靠的软件发布策略。参阅以下的操作示例，了解如何使用 Kurator 配置金丝雀发布。通过配置 rollout 中的 workload 字段，可以将金丝雀发布的目标设置为 webapp 命名空间下名为 backend 的应用。发布目标除了支持 deployment 应用之外，还支持 daemonSet应用。流量分析使用 Kurator 内置的请求成功率（request-sueccess-rate）和平均访问时延（request-duration）两个指标作为衡量新版本是否健康的标准。其中通过 thresholdRange 指定阈值。示例中要求请求成功率大99%，平均访问时延小于 500ms，新版本的服务才会被认定为健康。rolloutPolicy.canaryStrategy 配置了每次测试成功后，下次流量递增的比例和最终允许测试版本流量占比的最大值，从而实现渐进式发布新版本。示例中每次递增 10% 的流量流向新版本，最多为 50%。也可以设置 maxWeight 为 55，这样在最后一次测试的时候，只会新增 5% 的流量流向新版本。除了这些配置之外，Kurator 还可以设定完成验证之后，流量以什么样的比例逐步流向新版本。更多细节请参考: https://kurator.dev/docs/fleet-manager/rollout/canary/▍A/B测试A/B 测试为效果测试，是验证应用两版本表现的测试方法。它通过将用户分到不同组，每个组体验不同版本，然后分析每个组用户在使用过程中的各项指标，选择效果较好的版本。A/B 测试也可以先让部分用户试用新版本，收集真实环境下的用户反馈，再决定是否上线新版本。了解如何在 Kurator 配置应用的 A/B 测试，请参考下方操作示例。和金丝雀发布类似，由 workload 指定 A/B 测试的目标。通过 metric 指定测试的指标。A/B 测试和金丝雀发布不同的点在于需要配置 match 中的匹配规则，实现流量分组。上述 match 配置是只有 http 请求头满足使用 FireFox 浏览器或请求的 cookie 中包含 “type=insider” 的情况下，请求才会被转发到新版本。通过对不同请求头的处理达到对用户分组的效果，对不同的版本进行效果测试。除了匹配请求头之外，还能匹配 URI、端口号等。更多细节请参考: https://kurator.dev/docs/fleet-manager/rollout/abtest/▍蓝绿发布蓝绿发布是一种渐进零停机发布方法。它将生产环境分为两个独立运行的蓝绿环境,蓝环境承载当前实际流量，绿环境预部署新版本。新版本通过测试后,只需切换流量到绿环境，就能实现零停机升级。蓝环境备用支持回滚。通过实时扩容，可近乎零停机完成迭代交付，提高发布效率和用户体验。了解如何在 Kurator 配置蓝绿发布的操作示例，请参考下方。蓝绿发布需要配置目标应用、测试指标、迭代次数和容许测试失败的次数，其中测试的迭代次数由 analysisTimes 指定，容许测试失败的次数由 checkFailedTimes指定，除此之外无需配置别的规则。因为蓝绿发布在测试新版本的时候是将全局流量转发到绿环境中进行测试，没有金丝雀发布的渐进式流量递增和 A/B 测试的对用户分组的需求。更多细节请参: https://kurator.dev/docs/fleet-manager/rollout/blue-green/  未来展望  综上所述，通过 CI/CD 流水线和渐进式发布功能，Kurator 实现了从源码到发布的完整流水线自动化，真正提升了开发效率和运维能力，实现开发、配置和发布的应用全流程生命周期管理。此外还大幅简化了采用 CI/CD 流水线和渐进式发布的门槛。随着 Kurator 的不断迭代升级，我们还将继续为流水线添加更多的预定义任务模板，为渐进式发布提供更多的测试指标。欢迎大家试用 Kurator 并提出宝贵的意见与需求。Kurator的门户为：cid:link_0随着功能的逐渐完善，Kurator 将成为用户快速立体掌握云原生技术体系、高效运行分布式应用的强大工具。参考链接Kurator项目地址：cid:link_0CI/CD流水线：https://kurator.dev/docs/pipeline/软件供应链安全：https://kurator.dev/docs/pipeline/chain-security/渐进式发布：https://kurator.dev/docs/fleet-manager/rollout/金丝雀发布：https://kurator.dev/docs/fleet-manager/rollout/canary/A/B测试：https://kurator.dev/docs/fleet-manager/rollout/abtest/蓝绿发布：https://kurator.dev/docs/fleet-manager/rollout/blue-green/更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

rtrtrtrtrtrtrt

Kmesh是业内首个内核级云原生流量治理引擎，通过基础软件创新帮助用户构筑云原生场景下高性能的通信基础设施。Kmesh第一个版本v0.1.0 [1]现已正式发布，用户可以在服务网格环境中使用yaml一键部署，无缝对接Istiod，通过流量治理下沉OS，实现相比 Istio Sidecar 方案转发时延降低50%+，为应用提供极致的转发性能体验。▍Kmesh 介绍Kmesh 基于 eBPF + 可编程内核技术，将流量治理下沉 OS，数据路径上无需经过代理层，实现了一个内核级 sidecarless 网格数据面。Kmesh 关键能力：高性能：内核中原生支持 L4~L7 流量治理功能，治理过程无需经过实体代理组件，网格内服务通信路径从代理架构下的三跳变为一跳，大幅提升网格数据面的转发性能；低开销：Pod 中无需部署 Sidecar 程序，大幅降低网格基础设施的资源开销；安全隔离：基于 eBPF 的运行时安全，并支持 cgroup 级治理隔离；平滑兼容：支持与 Istiod 等支持 XDS 协议的服务网格管控面对接，同时可以与现有 Sidecar 网格协同工作；Kmesh 的主要部件包括：kmesh-controller：负责生命周期管理、XDS 协议对接、观测运维等功能；kmesh-api：接口层，主要包括XDS 转换后的编排 API、观测运维通道等；kmesh-runtime：kernel 中实现的支持 L4~L7 流量编排的运行时；其中7层编排运行时能力依赖对内核的增强；kmesh-orchestration：基于 eBPF 实现 L4~L7 流量编排，如路由、灰度、负载均衡等；kmesh-probe：观测运维探针，提供端到端观测能力；▍Kmesh v0.1.0关键特性一键部署Kmesh社区发布了 Kmesh 的部署镜像[2]，并支持通过 yaml 一键部署 Kmesh[3]；基于namespace使能Kmesh类似Istio，Kmesh支持按namespace使能流量接管范围，如：kubectl label namespace default label istio.io/dataplane-mode=Kmesh无缝连通Istio Sidecar支持在已有sidecar形态的网格环境启用Kmesh，启用后namespace 下新创建的 Pod 流量会自动被 Kmesh 接管，而不再经过 sidecar 代理；自动对接服务网格控制面Kmesh支持与Istiod自动对接，且理论上遵循XDS协议的网格控制面都可以与Kmesh对接，可通过修改yaml中的  MESH_CONTROLLER 环境量指定；TCP/HTTP1.1基础流量治理支持TCP流量转发，支持HTTP1.1头域匹配、路由、灰度等，支持随机、轮询负载均衡算法；兼容运行模式支持根据运行环境的OS内核能力，自适应使能Kmesh特性，在无增强补丁的内核版本上，也能够以兼容模式运行Kmesh；详情参考Release Notes[1]。▍性能测试我们使用 fortio 测试了 Istio（Envoy）、Kmesh 在同等流量治理场景下的表现，同时测试了 K8s 下基于 kubeProxy 的服务通信时延作为基线参考；不同链接数下的时延对比：相同QPS下的CPU开销对比：从测试结果可以看到：Kmesh 的转发时延基本接近K8s原生转发时延，相比 Istio sidecar 模式的转发时延有明显降低；相同 qps 下，Kmesh 的 CPU 开销基本与 k8s 原生 CPU 开销一致，相比 Istio sidecar 模式有明显降低；想要了解详细的 demo 测试细节，可以观看我们的演示视频：videovideovideovideovideo  ▍Kmesh关键技术剖析内核级流量编排运行时微服务通信一般先建立链接，再发送业务报文，如果想要无感的对业务报文做编排处理，通常需要对流量进行劫持，编排完成后再基于调整后的报文继续转发，这也是现在 Proxy 代理的实现；Kmesh 考虑随流完成治理工作，将链路建立时机推迟到业务报文发送阶段，以实现更高的编排处理性能。伪建链pre_connect 流程挂载 bpf prog，若当前访问的目标地址在 xds 的 listener 范围，则调用 bpf_setsockopt 通过 TCP_ULP 将当前 socket 的 tcp proto hook重载到 kmesh_defer 的内核模块实现；延迟建链kmesh_defer 内核模块重写了 connect/send hook（在原生 hook 上做了增强）：服务第一次走到 connect hook 时，会设置 bpf_defer_connect 标记，并不真正触发握手流程；send hook 中，若 sock 上设置了 bpf_defer_connect 标记，则触发connect，此时，会基于扩展的BPF_SOCK_OPS_TCP_DEFER_CONNECT_CB 调用 bpf prog，并在 bpf prog 中完成流量治理，然后基于调整后的通信五元组、报文进行建链和发送；整个治理过程大致如下图所示：XDS规则管理xds 模型是一颗层次化的树型规则表达，且不同版本模型定义可能会有调整，Kmesh 需要将模型信息转换成 eBPF map 存储，同时保持模型规则之间的层次关系；将 xds 模型转换成 eBPF map 数据具体过程：Kmesh 订阅 Istiod 的 xds 模型，并基于 protobuf-c 将 pb 模型转换成 c 数据结构风格；对于顶层模型（ listener 等），Kmesh 定义了知名 map 表与之对应，且value 的数据结构复用 protobuf-c 导出的 c struct；map 更新从顶层的知名 map 表开始，对于记录中的指针成员，xds-adapter 中会创建 inner-map 表来存储指针指向的真实数据区域，并将 inner-map的map fd添加进 map-in-map表中，最后将其在map-in-map表的key（index）作为该指针成员的 value；map-in-map 解决 xds 模型层次化对于 map 记录的 value 成员，如果是指针变量（涉及引用其他数据结构），通过 inner-map 存储指向的数据区域：如果 vaule 成员是基础数据类型（int 等），则直接访问；如果 value 成员是指针类型，则指针存储的 value 是存放真实数据的 inner-map 在 map-in-map 表中的 index（注意：index 是在 kmesh-daemon 的xds-adapter 模块中更新 bpf map 时配合写入）；访问时，先基于 index 找到 inner-map的map fd，再去 inner-map 表中查找真正数据，对于多级指针成员，则重复该过程，直到指针信息全部被剥离。流量治理编排实现xds 的治理规则复杂，层层匹配，超过了单个 eBPF 程序的复杂度限制；Kmesh 基于 eBPF Tail Calls 特性，将治理过程拆分成多个独立的 eBPF progs，具备较好的扩展性；▍展望Kmesh 是一种基于eBPF+可编程内核实现的高性能流量治理引擎，与业界方案相比，具有更高的转发性能和更低的资源开销；在无增强补丁的内核版本上，可以以兼容模式运行Kmesh，如果想要使用Kmesh完整的治理能力，当前 openEuler 23.03[4]版本已经原生支持，除此之外的其他操作系统需要基于增强的 patch 构建[5]。Kmesh 正在逐步完善，成为一个更受欢迎的流量治理引擎还有很多工作要做，欢迎大家试用 Kmesh v0.1.0 版本，并持续关注 Kmesh 社区，也期待您的共同参与。参考链接[1] Kmesh v0.1.0：cid:link_2[2] Kmesh的部署镜像：cid:link_3[3] 一键部署Kmesh：cid:link_1[4] openEuler 23.03版本：https://repo.openeuler.org/openEuler-23.03/[5] 基于增强的patch构建：cid:link_0[6] Kmesh社区地址：cid:link_4更多云原生技术动向关注容器魔方添加小助手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进入技术群

12月27日，由中国信息通信研究院、中国通信标准化协会主办的2023系统稳定性与精益软件工程大会在北京隆重举行，在云服务稳定性保障技术专场暨稳定性保障实验室年会上，华为云aPaaS应用平台AppStage运维中心专家受邀发表了“云原生时代如何构建应用稳定性”的演讲，分享了华为云应用平台AppStage运维中心在如何应对云原生应用运维挑战及保障应用稳定性上做出的探索和实践。云原生时代应用运维模式从传统的以资源管理为核心，升级为以应用管理为核心，原有运维方式面临着多方面的挑战：业务软件快速迭代、运维工具林立、业务快速发展与应用高稳定性要求存在矛盾。为应对云原生时代运维挑战而生的华为云应用平台AppStage运维中心，围绕云原生的业务场景，构建了4大能力：一是，基于智能运维AIOps，实现无人值守变更。通过Everything as a Code (XaC)声明，华为云应用平台AppStage运维中心将变更的评审、执行和验证等步骤自动化，避免人因失误，缩短变更过程中的步骤和操作时间，实现无人值守变更，帮助企业提升了运维效率；二是，通过端、管、边、云的联动监控，实现故障生命周期智能化管理。华为云应用平台AppStage运维中心通过端、管、边、云的联动监控，让指标、日志、调用链全栈可观测，打通了数据孤岛。在端侧告警后，通过AI异常检测算法及AI根因诊断等能力，实现1分钟发现、5分钟定位、10分钟恢复，大大降低了故障恢复时间，提升了业务质量；三是，通过混沌工程故障注入，充分验证应用可靠性。华为云应用平台AppStage运维中心支持80多种故障注入方式，预定义了50多种故障演练场景，通过模拟各种故障、全自动化演练，主动给应用“打疫苗”，使业务对故障具备免疫能力，提升了业务的稳定性；四是，FinOps运维成本可视化，帮助企业降本增效。华为云应用平台AppStage运维中心通过将AIOps的灰度评估、告警归并、异常检测、故障根因诊断等能力，嵌入运维的各个活动中，将以前的被动运维转为主动运维，帮助企业优化资源利用，实现降本增效。华为云应用平台AppStage运维中心将华为内部沉淀多年的构建、管理、使用和维护大规模云原生应用的经验构建到平台上来，通过平台化的开放，让更多的能力、经验共享出来，实现向产业‘经验即服务’的能力复制。以往需要大量工作的可靠性、韧性、安全等基础的工程能力，都通过平台提供，让企业可以聚焦于业务代码。未来，华为云希望通过应用平台AppStage运维中心帮助更多企业降低应用维护和使用云原生应用的门槛，实现应用维护智能化，为企业应用稳定性保驾护航。目前，华为云应用平台AppStage正在火热公测中，欢迎前往华为云官网，点击“产品-开天aPaaS-应用平台AppStage”体验使用。

12月16日-17日，以“一切为了开发者”为主题的开放原子开发者大会在无锡举办。会上，由开放原子开源基金会主导，华为、浪潮、DaoCloud、谐云、青云、飓风引擎以及OpenSDV开源联盟、openEuler社区、OpenCloudOS社区等成员单位共同发起建设的AtomHub可信镜像中心正式开放公测。AtomHub秉承共建、共治、共享的理念，旨在为开源组织和开发者提供中立、开放共建的可信开源容器镜像中心。AtomHub可信镜像中心正式公测平台地址：https://atomhub.openatom.cn/▍背景容器技术是云原生生态的基石，随着云原生技术在千行百业大规模落地和快速发展，容器镜像已经成为云原生应用分发的关键形态。开源容器镜像安全可靠的传播和分享，对云原生技术生态的繁荣有巨大促进作用。由于Docker Hub等镜像仓库的不稳定性和不可控性，以及一些政策和法规的限制，开发者们使用这些镜像仓库时也面临着种种问题和困难。网络不稳定：包括Docker Hub在内的多数容器镜像托管平台，服务器都位于海外，国内用户在访问时经常会遇到网络延迟和丢包的问题，导致镜像的上传和拉取频繁超时或请求失败。镜像拉取被限流：以Docker Hub为例，匿名用户6小时内只能拉取镜像100次，而注册登录的免费用户每6小时也只能拉取镜像200次，严重影响了镜像构建和应用部署的效率。缺失中立平台：国内用户缺失中立的镜像分享平台，构建镜像上传到Docker Hub再从国内下载受限制，影响容器镜像在中国的分享和传播。▍AtomHub定位鉴于上述原因，打造一个中立、开放共建的可信开源容器镜像中心，成为了当前亟待解决的问题。AtomHub项目——开源容器镜像中心由此发起，旨在为开发者提供来源真实、生态开放、平台中立、安全可信的新一代开源容器镜像中心。▍AtomHub架构AtomHub将采用镜像评级机制，确保镜像质量和安全性。官方镜像是由AtomHub官方发布的镜像，具有最高度可靠性和安全性，涵盖各种流行的操作系统、编程语言、数据库、中间件和应用程序；认证社区镜像由经过认证的开源社区发布，符合社区的质量标准和安全规范；认证厂商镜像则由经过认证的软件厂商发布，具有较高可靠性和专业性。与此同时，AtomHub还支持开发者自行构建和发布镜像，以满足个性化的需求。AtomHub将基于国产操作系统和软件打造自主可信根镜像、可信全链路构建系统，支持安全漏洞扫描和内容合规检测，及时发现和修复镜像漏洞和安全风险，确保镜像层层安全可信，重建可持续容器镜像供应链。AtomHub计划采用高性能镜像存储后端、多云CDN同步、冷热数据自动转储分流等关键技术，打造百万级并发规模容器镜像分发平台，为用户提供稳定可靠的镜像下载服务。▍AtomHub五大战略规划安全性：AtomHub将提供一套完善的安全机制，包括镜像签名、漏洞扫描和内容合规检测等功能，确保镜像安全可靠。高性能：AtomHub将采用高性能存储引擎和多云CDN加速，为您提供高速的镜像拉取和推送体验。易用性：AtomHub将会提供用户友好的Web界面，支持关键词搜索、分类浏览和镜像智能推荐，方便用户快速找到和下载所需镜像。兼容性：AtomHub采用OCI标准，兼容Docker Hub生态，可以无缝对接您现有的容器编排和持续集成/持续部署（CI/CD）工具。开放性：AtomHub将完全开源，打造一个开放、中立、透明的容器镜像共享平台，允许所有爱好者共同参与项目的开发、维护和使用。AtomHub作为一个新兴的开源容器镜像中心项目，对中国本土云原生技术和开源生态良性循环有巨大促进作用，我们欢迎所有对开源和容器技术感兴趣的开发者们加入我们的社区，一起打造安全可靠、高效便捷的容器镜像中心！AtomHub可信镜像中心平台地址https://atomhub.openatom.cn/首批提供160+款基础软件容器镜像，包含操作系统，编程语言，主流中间件等，欢迎体验！更多镜像陆续增加中

12月16日-17日，以“一切为了开发者”为主题的开放原子开发者大会在江苏无锡举办。秉持“共建、共治、共享”原则，聚焦大模型、云原生、前端、自动驾驶、物联网、开源治理与开发者运营等多领域内容，大会汇聚百万开发者生态，集聚政、产、学、研、用、金、创、投等各方力量，云集全球技术专家和行业大咖，持续推动软件生态蓬勃发展。华为云重磅参会开幕式、云原生分论坛、展区等多个环节，共同推进开源与云原生产业发展。▍开放原子云社区正式成立开幕式上，开放原子开源基金会理事长孙文龙与北京航空航天大学、华为技术有限公司、阿里巴巴集团控股有限公司、深圳市腾讯计算机系统有限公司、招商银行股份有限公司、京东科技信息技术有限公司代表共同启动成立开放原子云社区。▲开放原子云社区成立仪式北京航空航天大学的胡春明教授当选担任开放原子云社区主席，华为技术有限公司王泽锋，阿里巴巴集团控股有限公司丁宇，深圳市腾讯计算机系统有限公司邹辉，招商银行股份有限公司罗文江分别当选开放原子云社区副主席。开放原子云社区的成立，将通过凝聚云原生产学研用各方力量，共同推动我国云产业高质量发展。未来，该社区将围绕云原生技术路线图及生态全景规划、发掘孵化优质项目形成完整技术栈、培育壮大国内云原生开源生态、积极开展人才培养和国际合作等方面，推动云计算行业迈入“云上价值挖掘”的新阶段，重塑云计算产业价值链。▍AtomHub可信镜像中心正式公测由开放原子开源基金会牵头，开放原子云社区多家成员单位共同建设的AtomHub可信镜像中心在本次大会上正式开放公测。▲ AtomHub可信镜像中心正式公测AtomHub可信镜像中心由开放原子开源基金会牵头，华为、浪潮、DaoCloud、谐云、青云、飓风引擎以及OpenSDV开源联盟、openEuler社区、OpenCloudOS社区等成员单位共同发起，秉承共建、共治、共享的理念，旨在为开源组织和开发者提供中立、开放共建的可信开源容器镜像中心。▲ AtomHub可信镜像中心首批共建单位&社区▍云原生技术前沿落地实践论坛大会的“云原生技术前沿落地实践论坛”由CNCF基金会大使、技术监督委员会贡献者及多个项目创始人王泽锋担任出品，复旦大学计算机科学技术学院副院长、教授、博士生导师彭鑫，网易资深云原生专家侯诗军，腾讯云容器技术专家孟凡杰，蚂蚁集团高级研发工程师王思远，蚂蚁集团算法专家徐剑，华为云云原生团队开源技术专家徐中虎，开源项目 Serverless Devs 联合发起人、项目负责人袁坤，通明智云产品总监单雷，DaoCloud大容器团队技术负责人张潇，DaoCloud大容器团队开发工程师涂立海分别带来议题分享。云原生论坛议题聚焦云原生架构的创新与演进、云原生中间件的稳定性与可靠性、云原生的智能化运维与告警、云原生的FinOps实践、云原生Serverless架构与研发体验等多领域，为参会者提供全面视角和实践分享。▲云原生技术前沿落地实践论坛嘉宾合影在《融入未来：分布式云原生架构演进》的主题演讲中，华为云云原生团队核心成员、开源技术专家徐中虎分享了分布式云原生的发展历史与挑战，分布式云原生架构的演进，华为云Kurator项目在分布式云原生领域的创新。Kurator源于华为云在分布式云原生架构演进过程中多年探索，借助Kurator快速构建分布式云原生平台，可以帮助用户快速构建、部署、监控分布式云原生应用。▲华为云云原生团队核心成员、开源技术专家徐中虎▍Kurator分布式云原生开源社区展区Kurator是一款打造统一分布式云原生基础设施的开源套件。项目整合Karmada、KubeEdge、Volcano、Kubernetes、Istio、Promethus等业界主流开源技术栈，提供多云、多集群统一编排，统一调度，统一流量治理，边云协同，统一监控运维等核心能力，助力企业业务跨云跨边，分布式化升级。社区地址：cid:link_0▲Kurator分布式云原生开源社区随着云原生产业的不断发展，如何从战略全局去规划软件产业高质量发展，充分发挥开源生产方式的作用，是加快推进新型工业化发展的一大命题。社会各界都在整个过程中发挥着环环相扣的力量，而各行各业的开发者和使用者是数字时代创造知识、沉淀知识的主力军，开发者活力是软件产业繁荣发展最直接、最生动的体现。大会倡议，深化交流互鉴，聚焦产业亟需，增添发展动力，加强国际合作，做好服务保障。希望社会各界关注开源、拥抱开源、支持开源，深刻认识开源价值，为开发者提供服务，特别是在资产评估、价值认定、集成创新方面予以重点支持。也希望广大开发者和使用者能积极贡献智慧与力量，以时代责任应对共同挑战，以实干担当开创美好未来。更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

"Kubernetes运维确实复杂，这不仅需要深入理解各种概念、原理和最佳实践，还需要对集群的健康状态、资源利用率、容器的稳定性等多个方面进行风险评估。当集群出现故障时，我们通常需要花费大量时间来分析各种日志和监控信息，以找出问题的根本原因。"一位IT公司运维总监如此说道。近年来，越来越多的公司转向了基于Kubernetes的云原生架构。随着微服务和云原生架构的变得越来越复杂，我们也收到不少客户反馈在生产中进行监控和故障排除变得越来越困难。虽然CCE云原生可观测平台提供了监控、告警、日志等功能，能够让用户更加方便的定位问题，但是同样也无形中提高了运维人员的技术门槛。为了让运维和开发人员能够从繁重的故障定位排查中解脱出来，CCE服务提供了集群健康诊断能力。CCE集群健康诊断集合了容器运维专家的经验，为您提供了集群级别的健康诊断最佳实践。可对集群健康状况进行全面检查，帮助您及时发现集群故障与潜在风险，并给出对应的修复建议供您参考。▎开箱即用：免开通零依赖，一键健康诊断集群健康诊断功能作为CCE内置健康专家系统，可以在不依赖任何插件和其他服务的情况下独立运行。用户无需繁琐的开通与配置流程，就可以一键触发集群健康诊断。图1 一键健康诊断▎定时巡检：无人值守，持续守护集群健康在主动运维场景，比如集群升级前后或业务重保期间，用户可随时主动触发健康诊断来保障业务的顺利运行。另一方面，在日常运维中，我们无法一直盯屏保障，为了将客户从这种低级的劳动中解放出来，健康诊断支持定时巡检功能，只需要简单的配置定时任务，健康诊断任务就可以在后台守护您的集群健康，并将检查结果定时存档，方便随时回溯复盘。图2 健康检查结果▎多维诊断：丰富的诊断项，集群全方位体检CCE集群健康诊断提炼了运维专家提供的高频故障案例，覆盖了集群/核心插件/节点/工作负载/外部依赖等多种维度的健康检查，并且所有的诊断项都给出了风险评级、影响风险、以及修复建议。集群维度：包括集群运维能力检查，安全组配置检查，集群资源规划检查等诊断项。图3 集群维度诊断项核心插件维度：覆盖监控、日志、coredns、存储等核心插件的健康检查。图4 核心插件维度诊断项节点维度：包括节点资源负载情况和节点状态诊断。图5 节点维度诊断项工作负载维度：包括工作负载配置检查，Pod资源负载检查，Pod状态诊断等。图6 工作负载维度诊断项外部依赖维度：主要包括ECS和云硬盘等资源配额检查。图7 外部依赖维度诊断项▎智能分析：智能健康评级，专业修复建议CCE集群健康诊断会针对故障和潜在风险，给出风险等级并提供修复建议。风险等级按照紧急程度分为高风险和低风险两种：高风险：说明该诊断项会危及到集群或应用稳定性，可能造成业务损失，需要尽快修复。低风险：说明该诊断项不符合云原生最佳实践，存在潜在的风险，但是不会马上对业务造成重大影响，建议修复。在每一次健康诊断完成之后，所有的诊断结果会被汇总分析，并给出最终的集群健康评分，该评分反映了集群的整体健康状况。健康评分较低的集群往往存在较大的故障风险，需要引起集群管理员的高度重视。图8 健康风险等级评估▎案例分析：一次安全组误操作导致的业务故障CCE作为通用的容器平台，安全组规则的设置适用于通用场景。集群在创建时将会自动为Master节点和Node节点分别创建一个安全组。如果用户不小心误操作了默认安全组中的规则，可能会导致节点网络不通等问题，而且这种问题往往比较难以排除，需要花费较多的时间才能定位到安全组的原因，影响业务恢复速度。这种情况我们可以通过健康中心的巡检功能来进行故障诊断。例如修改一个集群的默认安全组规则，将Master与Node通信规则，从允许改为拒绝。图9 修改安全组规则以上操作会导致集群部分功能异常，如网络不通出现无法执行kubectl命令的问题。这种问题往往难以排查，会消耗用户大量的时间来寻找根因。此时如果用户在CCE健康中心执行一次健康巡检，会发现安全组高风险巡检项提示：图10 安全组异常提示通过诊断详情可以直接定位异常安全组，便于进行针对性修复：图11 定位异常安全组整个故障诊断流程方便快捷，可以大幅减低故障排查时间，帮助客户业务更稳定的运行在CCE集群上。▎结语CCE集群健康诊断功能，集成沉淀了大量的专家运维经验，目标是为客户提供更加智能、快捷的运维能力。当前该能力依然在快速迭代，后续我们会增加巡检结果通知、风险评估阈值调整以及更丰富的诊断项等能力，为大家带来更智能、更可靠稳定的云原生系统。服务体验请访问cid:link_0云容器引擎 CCE

北京时间12月20日，云原生计算基金会（CNCF）正式接纳多沙箱容器运行时项目 Kuasar（cid:link_0）。Kuasar的加入，极大地推动了云原生领域容器运行时技术的探索、创新和发展。作为CNCF首个多沙箱容器运行时项目，Kuasar于2023年4月在KubeCon + CloudNativeCon Europe上由华为云、中国农业银行以及openEuler社区、WasmEdge社区和Quark Containers社区联合发起。Kuasar融入了各企业和社区在容器运行时领域的前沿探索、技术积累和生产实践，开源至今受到业界的广泛关注和支持，已收获900多个GitHub Star和70多个Fork，数十位来自外部企业、高校的开源爱好者参与开发贡献和积极落地应用，Kuasar正以开源创新的姿态促进云原生产业发展。“WebAssembly正在快速成为云原生技术栈的一个关键部分，Kuasar深度集成了高性能、轻量级的WasmEdge沙箱，Kuasar的加入使得WebAssembly生态和CNCF生态联系更加紧密，未来WasmEdge和Kuasar将共同推动在大模型、边缘计算和函数计算等领域的发展。”—— WasmEdge项目创始人  Michael Yuan“openEuler社区在Kuasar项目发布之初就率先完成与Kuasar多沙箱生态的对接，推出基于iSulad + Kuasar + StratoVirt的极速轻量安全容器解决方案。未来openEuler社区将继续深化与CNCF社区项目的合作，为用户提供更轻量、更安全、更多样的容器化底座。”—— openEuler技术委员会主席  胡欣蔚“Kuasar项目融入了华为云在容器运行时领域多年的积累，结合了社区合作伙伴的实践经验。成为CNCF官方项目，表明了Kuasar社区开放治理的决心，致力于为企业和开发者提供厂商中立、多方协作的开放环境，促进各种沙箱技术的商用成熟，为用户带来极致体验。”—— CNCF官方大使  华为云云原生开源团队负责人  王泽锋“云原生场景多样化促进了多种沙箱技术的蓬勃发展，沙箱技术接入北向生态成为普遍需求，Kuasar推动了Containerd中沙箱技术标准的统一，提供了多种沙箱技术实现，为CNCF的容器运行时板块注入了新鲜活力。”——  CNCF官方大使  Containerd社区维护者  蔡威▍Kuasar项目介绍为了满足企业在云原生场景下的诉求，业界出现了多种沙箱容器隔离技术。然而，应用云原生的沙箱技术仍面临挑战。一方面，各类云原生场景对沙箱提出更高要求，单一沙箱无法同时满足用户云上业务对安全隔离、极速低噪、标准通用等多个维度的要求，企业面临云原生业务场景全覆盖问题；另一方面，支持多类沙箱带来运维压力显著上升，当前业界沙箱技术对接容器运行时的实现缺乏统一开发框架，因此关键日志、重要事件、沙箱管理逻辑等均存在差异，新引入沙箱的同时运维压力陡增。Kuasar在保留传统容器运行时功能的基础上，与Containerd社区一起推动新的沙箱接口统一标准，并通过全面Rust化以及优化管理模型框架等手段，进一步降低管理开销，简化调用链路，灵活扩展对业界主流沙箱技术的支持。此外，通过支持多安全沙箱共节点部署，Kuasar可以充分利用节点资源、降本增效，为用户提供更安全高效的沙箱场景解决方案。▲ Kuasar项目全景图南向沙箱方面，Kuasar已支持基于轻量级虚拟化技术的安全容器沙箱（Cloud Hypervisor、Qemu、StratoVirt），基于新兴的WebAssembly沙箱（WasmEdge、Wasmtime），基于进程级虚拟化的App Kernel沙箱（Quark）以及基于内核的原生普通容器沙箱（runC）；北向引擎方面，Kuasar已与Containerd联合构建最新的沙箱接口标准，并共同推动该标准在Containerd v2.0版本的完整实现。此外，轻量级容器引擎iSulad项目也已经完成与Kuasar项目的深度集成，支持在openEuler 23.09创新版本上一键部署。▍未来可期此次CNCF正式将Kuasar接纳为官方项目，将极大促进Kuasar上下游社区生态构建及合作。Kuasar将持续探索云原生容器运行时领域技术创新，在企业数字化、云原生转型过程中发挥作用，让基于Kuasar的多沙箱容器运行时方案融入更广泛的云原生技术生态。作为CNCF亚洲唯一创始成员、白金会员，华为云在CNCF贡献量、Kubernetes社区和Istio社区的代码贡献量持续多年稳居亚洲第一，已向CNCF贡献了业界首个云原生边缘计算项目KubeEdge、首个云原生批量算力项目Volcano、首个多云容器编排项目Karmada等多个重量级云原生开源项目，并持续开源Kurator、Kappital、Kmesh等创新项目，与全球云原生社区共同发展。Kuasar社区技术交流地址Kuasar官网：https://kuasar.io项目地址：cid:link_0Twitter: https://twitter.com/Kuasar_io添加社区小助手回复“Kuasar”进入技术交流群