作者：唐明&王彬丞   引言   随着边缘计算的发展，人工智能在边缘侧的应用日益增多，对计算资源的需求也越来越高，尤其 GPU 算力的需求增长迅速。KubeEdge 作为基于 Kubernetes 的开源边缘计算平台，除提供高效的边缘设备管理和边缘应用容器化服务外，还提供了边云协同 AI 框架 Sedna，助力边缘 AI 发展。然而由于边缘计算环境复杂，将 GPU 资源纳入 KubeEdge 集群管理并让其与边缘 AI 应用协同工作成为重要问题。本篇文章将介绍如何将 GPU 边缘节点接入 KubeEdge 集群并支持边缘 AI 应用使用 GPU 资源，以应对边缘 AI 应用的计算需求。   GPU 运行环境构建   本文实验环境 💭 注：Node 1、Node 2 均为边缘节点，分别使用 Containerd 和 Docker 作为容器运行时进行演示在边缘节点上使用 GPU 需要先构建 GPU 运行环境，主要包括以下几个步骤：1、安装 GPU 驱动首先需要确定边缘节点机器是否有 GPU，可以使用 lspci | grep NVIDIA 命令来检查。根据具体 GPU 型号下载合适的 GPU 驱动并完成安装，安装完成后可以使用 nvidia-smi 命令检查驱动是否安装成功。安装方法可以参考[1]。2、安装容器运行时将 GPU 节点接入 KubeEdge 集群，需要先安装如 Docker、Containerd 之类的容器运行时，具体的安装指南可以参考 KubeEdge官方文档[2]。需要特别注意的是，自 KubeEdge v1.14 版本起，已经移除了对 Dockershim 的支持，不再支持直接使用 Docker 运行时管理边缘容器。如仍需使用 Docker，在安装 Docker 后还需安装 cri-dockerd[3]。3、安装 Nvidia-Container-ToolkitNVIDIA Container Toolkit 是一个专为构建和运行 GPU 容器设计的工具包。它通过一系列的功能和组件，使得在容器环境中充分利用 NVIDIA GPU 资源变得更加简单和高效。由于边缘节点网络连接情况不同，有两种方式安装 NVIDIA Container Toolkit：▷ 边缘节点能直接访问外部网络若边缘节点能直接访问外部网络，推荐按照官方文档，使用 apt、yum 等工具进行安装[4]。▷ 边缘节点无法直接访问外部网络边缘节点若无法直接访问外部网络，则需要在网络可以联通的机器上下载官方离线安装包[5]，将安装包传入边缘节点完成解压。 解压后目录中应该出现如下的文件：root@user:~/release-v1.16.0-rc.1-experimental/packages/ubuntu18.04/amd64# ls libnvidia-container1_1.16.0~rc.1-1_amd64.deb libnvidia-container-tools_1.16.0~rc.1-1_amd64.deb nvidia-container-toolkit-operator-extensions_1.16.0~rc.1-1_amd64.deb libnvidia-container1-dbg_1.16.0~rc.1-1_amd64.deb nvidia-container-toolkit_1.16.0~rc.1-1_amd64.deb libnvidia-container-dev_1.16.0~rc.1-1_amd64.deb nvidia-container-toolkit-base_1.16.0~rc.1-1_amd64.deb在该目录中执行下方的命令完成安装： root@user:~# sudo apt install ./*这里我们提供的案例是基于 Ubuntu 系统的（如果使用 CentOS，可以在链接[5]下载对应的 rpm 包，使用 rpm 命令进行安装）。4、配置容器运行时支持 GPU成功安装 Nvidia-Container-Toolkit 后，可以使用 nvidia-ctk 来配置各个容器运行时支持 GPU：# containerd (node1) root@user:~# sudo nvidia-ctk runtime configure --runtime=containerd --set-as-default # docker (node2) root@user:~# sudo nvidia-ctk runtime configure --runtime=docker --set-as-default5、重启容器运行时重启容器运行时，并且确认是否已经支持 GPU：# containerd (node1) root@user:~# systemctl daemon-reload && systemctl restart containerd # 检查运行时是否已经修改为 nvidia root@user:~# cat /etc/containerd/config.toml |grep nvidia default_runtime_name = "nvidia" [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia] [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia.options] BinaryName = "/usr/bin/nvidia-container-runtime" # docker (node2) root@user:~# systemctl daemon-reload && systemctl restart docker # 检查运行时是否已经修改为 nvidia root@user:~# docker info |grep Runtime Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux nvidia runc Default Runtime: nvidia经过第一部分 GPU运行环境构建的操作，边缘节点已经拥有 GPU 驱动，容器运行时也具备了 GPU 设备的调用能力，接下来需要将边缘节点正式纳管进 KubeEdge 集群。   边缘 GPU 节点纳管   将边缘 GPU 节点纳管至 KubeEdge 集群主要包括以下几个步骤：1、节点接入推荐使用 keadm 工具将边缘节点接入 KubeEdge 集群，接入方式与普通边缘节点一致，详细信息可参考 KubeEdge 官方文档[6]。下面以 Docker 和 Containerd 容器运行时作为边缘 GPU 节点接入示例：# containerd (node1) root@user:~# keadm join --cgroupdriver=cgroupfs \ --cloudcore-ipport="THE-EXPOSED-IP":10000 \ --kubeedge-version=v1.17.0 \ --token="YOUR TOKEN" --remote-runtime-endpoint=unix:///run/containerd/containerd.sock # docker (node2) root@user:~# keadm join --cgroupdriver=systemd \ --cloudcore-ipport="THE-EXPOSED-IP":10000 \ --kubeedge-version=v1.17.0 \ --token="YOUR TOKEN" --remote-runtime-endpoint=unix:///var/run/cri-dockerd.sock运行 systemctl status edgecore 命令确认边缘节点 EdgeCore 是否运行成功：root@user:~# systemctl status edgecore ● edgecore.service Loaded: loaded (/etc/systemd/system/edgecore.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2022-10-26 11:26:59 CST; 6s ago Main PID: 2745865 (edgecore) Tasks: 13 (limit: 4915) CGroup: /system.slice/edgecore.service └─2745865 /usr/local/bin/edgecore2、部署 k8s-device-plugin可以按照下方的 yaml 文件部署 k8s-device-plugin DaemonSetapiVersion: apps/v1 kind: DaemonSet metadata: name: nvidia-device-plugin-daemonset namespace: kube-system spec: revisionHistoryLimit: 10 selector: matchLabels: name: nvidia-device-plugin-ds template: metadata: labels: name: nvidia-device-plugin-ds spec: containers: - env: - name: FAIL_ON_INIT_ERROR value: "false" image: nvcr.io/nvidia/k8s-device-plugin:v0.14.3 imagePullPolicy: IfNotPresent name: nvidia-device-plugin-ctr resources: {} securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /var/lib/kubelet/device-plugins name: device-plugin dnsPolicy: ClusterFirst priorityClassName: system-node-critical restartPolicy: Always schedulerName: default-scheduler securityContext: {} terminationGracePeriodSeconds: 30 tolerations: - effect: NoSchedule key: nvidia.com/gpu operator: Exists volumes: - hostPath: path: /var/lib/kubelet/device-plugins type: "" name: device-plugin检查 k8s-device-plugin 是否成功部署：root@user:~# kubectl get po -n kube-system -owide|grep nvidia nvidia-device-plugin-daemonset-d5nbc 1/1 Running 0 22m 10.88.0.4 nvidia-edge-node <none> <none> nvidia-device-plugin-daemonset-qbwdd 1/1 Running 0 2d6h 10.88.0.2 nano-1iamih8np <none> <none>使用 kubectl describe node 命令验证节点 GPU 信息是否正确上报。root@user:~# kubectl describe node {YOUR EDGENODE NAME} Name: nvidia-edge-node Roles: agent,edge Labels: beta.kubernetes.io/arch=amd64 ... Capacity: cpu: 12 ephemeral-storage: 143075484Ki hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 40917620Ki nvidia.com/gpu: 1 pods: 110 Allocatable: cpu: 12 ephemeral-storage: 131858365837 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 40815220Ki nvidia.com/gpu: 1 pods: 110如果节点信息中出现了 nvidia.com/gpu 资源，说明 device-plugin 正常运行，可以将 GPU 挂载至边缘 GPU 应用容器中。第三部分提供测试应用的部署方法，能够验证 GPU 调用能力。   测试 GPU 资源调用能力  1、部署 GPU 测试应用可以使用下方所示的示例 yaml，部署一个 pytorch 的边缘应用，该应用使用一个 GPU 资源。kind: Deployment apiVersion: apps/v1 metadata: name: test-gpu namespace: default spec: replicas: 1 selector: matchLabels: app: test-gpu template: metadata: labels: app: test-gpu spec: containers: - name: container-1 image: pytorch/pytorch:2.2.0-cuda12.1-cudnn8-devel command: - tail - '-f' - /dev/null resources: limits: nvidia.com/gpu: '1' requests: nvidia.com/gpu: '1' imagePullPolicy: IfNotPresent nodeName: nvidia-edge-node # replace to your GPU edge node name2、验证 GPU 是否成功挂载进入这个应用创建的容器中，调用 pytorch 中的 torch.cuda.is_available() 命令验证 GPU 是否成功挂载。# containerd (node1) root@user:~# crictl ps CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD de1f1e60abc0a 0dd75116a8ce8 2 minutes ago Running container-1 0 6beffb412af3f test-gpu-6bfbdc9449-jfbrl root@user:~# crictl exec -it de1f1e60abc0a /bin/bash root@test-gpu-6bfbdc9449-jfbrl:/workspace# python3 Python 3.10.13 (main, Sep 11 2023, 13:44:35) [GCC 11.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import torch >>> torch.cuda.is_available() True # docker (node2) root@user:~# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES e7e3804626a5 853b58c1dce6 "tail -f /dev/null" 53 seconds ago Up 45 seconds k8s_container-1_test-gpu-arm64-nano-7f8fd7f79f-hzvp5_default_64fb7a90-b0e6-4b46-a34f-8a06b24b9169_0 root@user:~# docker exec -it e7e3804626a5 /bin/bash root@test-gpu-arm64-nano-7f8fd7f79f-hzvp5:/# python3 Python 3.8.10 (default, Nov 14 2022, 12:59:47) [GCC 9.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import torch >>> torch.cuda.is_available() True通过本文的介绍，我们详细探讨了如何将边缘 GPU 节点接入 KubeEdge 集群，并支持边缘应用使用 GPU 资源。将 GPU 资源集成至 KubeEdge 集群中可以大大提升边缘设备的计算能力，推动边缘 AI 技术的发展，助力实现高效的边缘计算解决方案。欢迎大家持续关注 KubeEdge 社区。▍相关链接[1] 安装GPU驱动参考文档：https://www.nvidia.cn/drivers/lookup/[2] KubeEdge容器运行时文档：https://kubeedge.io/docs/setup/prerequisites/runtime[3] cri-dockerd参考文档：https://kubeedge.io/docs/setup/prerequisites/runtime#docker-engine[4] NVIDIA Container Toolkit官方文档：https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html[5] NVIDIA Container Toolkit官方离线安装包：cid:link_1[6] 节点接入参考文档：https://kubeedge.io/docs/setup/install-with-keadm【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_2Slack地址 : 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/

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/更多云原生技术动向关注容器魔方

大家好，我叫我爱吃螺蛳粉，我觉得云主机管理的代码可以这么写：def createsecuritygroup(name): try: request = CreateSecurityGroupRequest() securityGroupbody = CreateSecurityGroupOption( name=name ) request.body = CreateSecurityGroupRequestBody( security_group=securityGroupbody ) response = client.create_security_group(request) print(response) except exceptions.ClientRequestException as e: print(e.status_code) print(e.request_id) print(e.error_code) print(e.error_msg)def getAllSecurityGroups(): try: request = ListSecurityGroupsRequest() response = client.list_security_groups(request) print(response) return response except exceptions.ClientRequestException as e: print(e.status_code) print(e.request_id) print(e.error_code) print(e.error_msg)def getSecurityGroupIdByName(name): allgroup = getAllSecurityGroups() dictdata = allgroup.to_dict()["security_groups"] for data in dictdata: if data['name'] == name: return data['id'] else: return 'None'def deleteSecureGroup(name): try: request = DeleteSecurityGroupRequest() security_group_id = getSecurityGroupIdByName(name) if security_group_id != 'None': request.security_group_id = security_group_id response = client.delete_security_group(request) print(response) else: print('there is no ',name) except exceptions.ClientRequestException as e: print(e.status_code) print(e.request_id) print(e.error_code) print(e.error_msg)def getSecureGroupByName(name): security_group_id = getSecurityGroupIdByName(name) if security_group_id != 'None': try: request = ShowSecurityGroupRequest() request.security_group_id = id response = client.show_security_group(request) print(response) except exceptions.ClientRequestException as e: print(e.status_code) print(e.request_id) print(e.error_code) print(e.error_msg)

# coding: utf-8import argparseimport jsonimport yamlfrom huaweicloudsdkcore.auth.credentials import BasicCredentialsfrom huaweicloudsdkecs.v2.region.ecs_region import EcsRegionfrom huaweicloudsdkcore.exceptions import exceptionsfrom huaweicloudsdkecs.v2 import *def createserver(name,imageid): try: request = CreateServersRequest() rootVolumeServer = PrePaidServerRootVolume( volumetype="SSD" ) listNicsServer = [ PrePaidServerNic( subnet_id="ecf996a0-bf3e-4521-bbfd-3f70963cc23b" ) ] serverbody = PrePaidServer( image_ref=imageid, flavor_ref="ac7.2xlarge.2", name=name, vpcid="518f3932-5828-4da4-8eab-0c8bf2e42dda", nics=listNicsServer, root_volume=rootVolumeServer ) request.body = CreateServersRequestBody( server=serverbody ) response = client.create_servers(request) print(response) except exceptions.ClientRequestException as e: print(e.status_code) print(e.request_id) print(e.error_code) print(e.error_msg)def getserverbyname(name): try: request = ListServersDetailsRequest() request.name = name response = client.list_servers_details(request) print(response) except exceptions.ClientRequestException as e: print(e.status_code) print(e.request_id) print(e.error_code) print(e.error_msg)def getAllServers(): try: request = ListServersDetailsRequest() response = client.list_servers_details(request) print(response) except exceptions.ClientRequestException as e: print(e.status_code) print(e.request_id) print(e.error_code) print(e.error_msg)def getServersIdByName(name): try: request = ListCloudServersRequest() request.name = name response = client.list_cloud_servers(request) print(response.to_dict()['servers']) return response.to_dict()['servers'][0]['id'] except exceptions.ClientRequestException as e: print(e.status_code) print(e.request_id) print(e.error_code) print(e.error_msg)def deleteServer(serverid): try: request = DeleteServersRequest() listServersbody = [ ServerId( id=serverid ) ] request.body = DeleteServersRequestBody( servers=listServersbody ) response = client.delete_servers(request) print(response) except exceptions.ClientRequestException as e: print(e.status_code) print(e.request_id) print(e.error_code) print(e.error_msg)if __name__ == "__main__": # The AK and SK used for authentication are hard-coded or stored in plaintext, which has great security risks. It is recommended that the AK and SK be stored in ciphertext in configuration files or environment variables and decrypted during use to ensure security. # In this example, AK and SK are stored in environment variables for authentication. Before running this example, set environment variables CLOUD_SDK_AK and CLOUD_SDK_SK in the local environment ak = "" sk = "" credentials = BasicCredentials(ak, sk) client = EcsClient.new_builder() \ .with_credentials(credentials) \ .with_region(EcsRegion.value_of("cn-north-9")) \ .build() # createserver('test','6288ab88-3b7c-4320-9554-ad68a53eebb6') # 这里写命令的映射关系，和openstack的provier一样103行之前所有的代码都是从华为云的apiexplorer里找出来的 parser = argparse.ArgumentParser(description='ECS Manager for Huawei Cloud') subparsers = parser.add_subparsers(dest='command') # Create ECS parser_create = subparsers.add_parser('create', help='Create an ECS instance') parser_create.add_argument('-i', '--input', type=json.loads, required=True,help='JSON formatted input for ECS details') # Get ECS by name parser_get = subparsers.add_parser('get', help='Get details of an ECS instance by name') parser_get.add_argument('-n', '--name', type=str, required=True, help='Name of the ECS instance') parser_get.add_argument('-o', '--output', type=str, help='Output file path (JSON format)') # Get all ECS instances parser_getall = subparsers.add_parser('getall', help='Get details of all ECS instances') parser_getall.add_argument('-o', '--output', type=str, help='Output file path (YAML format)') # Delete ECS by name parser_delete = subparsers.add_parser('delete', help='Delete an ECS instance by name') parser_delete.add_argument('-n', '--name', type=str, required=True, help='Name of the ECS instance') args = parser.parse_args() if args.command == 'create': server = createserver(args.input['name'],args.input['image']) if server: server = getserverbyname(args.input['name']) print(json.dumps(server.to_dict(), indent=2)) elif args.command == 'get': server = getserverbyname(args.name) if server: server_info = server.to_dict() if args.output: print('write file') with open(args.output, 'w') as f: json.dump(server_info, f, indent=2) else: print(json.dumps(server_info, indent=2)) else: print(f"ECS instance with name {args.name} not found.") elif args.command == 'getall': print('get all servers') servers = getAllServers() servers_info = [server.to_dict() for server in servers] if args.output: with open(args.output, 'w') as f: yaml.dump(servers_info, f, default_flow_style=False) else: print(yaml.dump(servers_info, default_flow_style=False)) elif args.command == 'delete': id = getserverbyname(args.name) deleteServer(id) else: parser.print_help()以上是华为云主机创建过程，请各位批评指正。我爱吃螺蛳粉

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等代表产品引领全行业智能化发展趋势，为企业数智化转型提供强大动力。融合创新，智领未来。开源社区不仅仅在各自的技术领域中加深探索创新，也在跨社区的应用合作与融合发展中不断拓宽可能性。本次华为云开源开发者论坛云原生分论坛，为用户和开发者们带来了多项目、多领域的行业用户实践经验和技术创新成果分享，而成熟发展的云原生生态系统也正在加速引领各行各业迈向智能未来。更多云原生技术动向关注容器魔方

  2024年11月 FAQ—云计算等其他(问题求助) 总结-2024.11  【云计算】基础设施即服务 (IaaS)：如何在不同地区之间迁移数据？  https://bbs.huaweicloud.com/forum/thread-0217168226632705035-1-1.html   【云计算】基础设施即服务 (IaaS)：如何选择正确的存储类型？  https://bbs.huaweicloud.com/forum/thread-0296168140237186039-1-1.html   【云计算】基础设施即服务 (IaaS)：如何实现容灾备份？  https://bbs.huaweicloud.com/forum/thread-0217168054228372027-1-1.html   【云计算】基础设施即服务 (IaaS)： 虚拟网络与子网的作用是什么？  https://bbs.huaweicloud.com/forum/thread-02109167966489780015-1-1.html   为什么树莓派5b显示禁止连接  https://bbs.huaweicloud.com/forum/thread-0263167878118310014-1-1.html   【云计算】基础设施即服务 (IaaS)： 如何设置自动扩展（Auto Scaling）？  https://bbs.huaweicloud.com/forum/thread-02109167620977883002-1-1.html   【云计算】基础设施即服务 (IaaS): 如何配置负载均衡器？  https://bbs.huaweicloud.com/forum/thread-0231167535045832019-1-1.html   【基础设施即服务 (IaaS)】什么是块存储与对象存储？  https://bbs.huaweicloud.com/forum/thread-02127167449000488011-1-1.html   【基础设施即服务 (IaaS)】怎样管理虚拟机实例？   https://bbs.huaweicloud.com/forum/thread-02127167362518074006-1-1.html    如何选择适合的 IaaS 提供商？  https://bbs.huaweicloud.com/forum/thread-0229167275974648009-1-1.html   aws 已创建 alb ingress 域名 无法访问，如何查看 ingress controller 情况   https://bbs.huaweicloud.com/forum/thread-02127166937116553016-1-1.html   websocat -v --insecure wss://xxxxx 无法连接   https://bbs.huaweicloud.com/forum/thread-0257166935611082018-1-1.html   C#如何实现：Modbus通讯监控暖房温度PID控制  https://bbs.huaweicloud.com/forum/thread-0210166930372240018-1-1.html   美区facebook限制发送好友请求。有人知道怎么解决这个问题吗  https://bbs.huaweicloud.com/forum/thread-02127166870753492014-1-1.html    ansys fluent计算闪退  https://bbs.huaweicloud.com/forum/thread-0266166843768681014-1-1.html   如何在proteus使用sounder设置每次按键时扬声器会有提示声  https://bbs.huaweicloud.com/forum/thread-0231166781739432016-1-1.html   调试无法使用，定义更改  https://bbs.huaweicloud.com/forum/thread-0289166758250387012-1-1.html   脉冲信号有高电平和低电平，那么负脉冲有负电压吗？  https://bbs.huaweicloud.com/forum/thread-0231166699780052012-1-1.html   随机森林模型不同年份影响因素分析  https://bbs.huaweicloud.com/forum/thread-0266166697120887009-1-1.html    提取CMU- Mosei数据集的特征  https://bbs.huaweicloud.com/forum/thread-0266166498654785006-1-1.html   网页拖进ftp资源管理器站点以后打开是浏览器默认界面   https://bbs.huaweicloud.com/forum/thread-0257166412254834002-1-1.html   打开游戏出现这个进不去。求解   https://bbs.huaweicloud.com/forum/thread-02127166326594269013-1-1.html   system x3610支持ESX7.0系统安装吗？IBM system x3610支持ESX7.0系统安装吗？  https://bbs.huaweicloud.com/forum/thread-0216166325288704024-1-1.html   海思Hi3816芯片在开发过程中与单片机有什么不同   https://bbs.huaweicloud.com/forum/thread-0220166268614811015-1-1.html    dolphinschedler部署完成 删除修改无反应  https://bbs.huaweicloud.com/forum/thread-0252166259675728017-1-1.html    如何实现 除法器设计实例－设计目标   https://bbs.huaweicloud.com/forum/thread-0257166259605659022-1-1.html   本地与多个区域云服务器互联互通，如何解决？  https://bbs.huaweicloud.com/forum/thread-0220166259404985012-1-1.html  关于银河麒麟V10服务器操作系统虚拟机中FTP服务器的问题  https://bbs.huaweicloud.com/forum/thread-0216166239065295018-1-1.html    关于sap登录问题解决  https://bbs.huaweicloud.com/forum/thread-0255166238984096020-1-1.html  用友GRP-U8卡片登记簿问题  https://bbs.huaweicloud.com/forum/thread-0257166170273793019-1-1.html   vercel注册时遇到问题  https://bbs.huaweicloud.com/forum/thread-0255166170192717016-1-1.html   facescrub数据集是有什么特点吗？  https://bbs.huaweicloud.com/forum/thread-02127166170118839012-1-1.html    本帖内容会持续刷新维护和新增问答，如您有本类型问题或问题仍无法解决，欢迎留言交流！ 

云计算有哪些可以探讨的未来发展方向？欢迎大佬们在帖子下留言讨论！！！

华为云 如何在不同地区之间迁移数据？

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，报名领票参会！

如何选择正确的存储类型？

华为云如何实现容灾备份？

虚拟网络与子网的作用是什么？

作者：王彬丞、杨志佳、刘家伟随着万物互联时代快速到来，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/

基础设施即服务 (IaaS)： 如何设置自动扩展（Auto Scaling）？

如何配置负载均衡器？