2024年12月18日，由中国科学技术协会科学技术传播中心、中国计算机学会、中国通信学会、中国科学院软件研究所联合主办，CSDN 承办的开源创新榜评选活动圆满落幕。KubeEdge 作为业界首个云原生边缘计算项目以及 CNCF 唯一正式毕业的边缘计算开源项目，以其卓越的创新性、贡献度和影响力，从200多个竞争项目中脱颖而出，荣获2024开源创新榜优秀开源项目之首。2024开源创新榜评选活动由王怀民院士担任评委会主任，带领全国各学会、大学、科研院所、企业、开源基金会、行业联盟等近20位开源专家，面向中国开源行业领域，遴选具有创新性、贡献度和影响力的开源项目、社区、应用场景与开源事件，进一步激励更多企业和开发者参与开源生态建设，推动开源技术繁荣和发展。  KubeEdge 于2018年11月正式开源，2019年作为首个云原生边缘项目被接受为 CNCF Sandbox 项目，在2020年9月晋升为孵化项目，并于2024年10月从 CNCF 正式毕业，是第三个由中国企业开源的毕业项目。KubeEdge 项目致力于将 Kubernetes 的容器化应用编排能力无缝扩展至边缘主机，为边缘计算提供强大的基础设施支持。它基于 Kubernetes 构建，不仅覆盖了云端与边缘端之间的网络连接、应用部署和元数据同步，还通过高效的架构设计，显著提升了边缘计算场景中的可靠性与性能。目前，KubeEdge 将云原生生态扩展到了数据中心之外的更多场景和行业，广泛应用于 CDN、智能交通、智慧能源、智慧零售、智慧园区、智能汽车、航空航天、智能物流、金融、化工、电力、区块链等各领域，完成了业界最大规模云原生边云协同高速公路收费站管理项目、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生智慧零售管理、业界首个云原生金融管理等行业代表项目。基于云原生边缘计算领域的独特优势，KubeEdge 得到了伙伴和用户的高度认可。此次荣获“优秀开源项目”奖项，既是对 KubeEdge 技术实力的高度认可，也彰显了社区在合作精神、开放性和追求卓越方面的努力与成就。这一荣誉离不开每一位社区成员的辛勤付出和无私奉献。未来，KubeEdge 社区将保持开放治理模式和协作理念，进一步改善用户体验，提供更可靠和稳定的服务。我们也诚邀更多的开发者和用户加入 KubeEdge 社区，共同探索边缘计算的未来，共创辉煌。   【更多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/

12月27日，“The Future of KubeEdge” KubeEdge 毕业主题研讨会在上海成功举办。来自上海开源信息技术协会、华为云、DaoCloud、Intel、南京腾优科技、FatCoupon Technology、中碳普惠云、复旦大学、上海对外经贸大学、上海工程技术大学等多家机构、企业、高校代表及贡献者出席，就 KubeEdge 毕业后的社区规划展开深入研讨，持续聚力技术与运营协同创新，助力云原生边缘计算产业升级发展。  回顾 KubeEdge 的发展历程，从 2018 年 11 月正式开源，2019 年作为首个云原生边缘项目被接受为 CNCF Sandbox 项目， 2020 年 9 月晋升为孵化项目，并于2024年成功毕业，成为CNCF首个毕业级云原生边缘计算项目，一路走来，社区持续开源创新，将云原生生态扩展到了数据中心之外的更多场景和行业，为业内带来了多个行业首发应用，广泛覆盖 CDN、智能交通、智慧能源、智慧零售、智慧园区、汽车、航空航天、智能物流、金融、化工、电力、区块链等领域。 ▲ KubeEdge 项目里程碑 会上，KubeEdge 联合创始人，华为云云原生开源负责人王泽锋介绍了全球云原生开源生态与运作模式，并分享了 KubeEdge 发展历程中的核心技术与典型案例。CNCF 毕业项目是国际开源生态的领军者，KubeEdge 从 CNCF 毕业已迈入了成熟新阶段。基于在云原生边缘计算领域的独特优势，KubeEdge 期待在未来为整个云原生生态系统缔造更广阔的可能性。 ▲ KubeEdge联合创始人，华为云云原生开源负责人王泽锋 KubeEdge TSC，DaoCloud 首席运营官张红兵在会上分享了 KubeEdge 长期以来的社区治理及运营策略。通过系统化建立社区治理架构，严格执行高效的开发者协同机制，开展深度的工程化验证，社区有序促进技术持续创新与升级。与此同时，社区也通过开发者实训、公开课、峰会、研讨会等系列形式，为社区开发者们构建多元化的学习、参与和成长路径，打造社区活跃生态。 ▲ KubeEdge TSC，DaoCloud 首席运营官张红兵 毕业是社区的里程碑，同时也对技术创新和运营发展提出了更高的要求。在小组讨论环节，各位代表集思广益，从企业、高校、开发者各个视角，就社区未来发展深入探讨，涵盖 Scalability、Node、Device-IoT、AI、Netwoking、Security、UI、Cluster-Lifecycle、Testing、EdgeSite、Release、Docs、Robotics 等多个 SIG 的技术创新方向，持续升级社区运营治理，促进 KubeEdge 与产业发展生态融合。 未来，KubeEdge 社区将保持开放治理模式和协作理念，进一步升级用户体验，提供更可靠和稳定的服务。社区成功毕业离不开每一位社区伙伴、用户与开发者的协作与贡献，期待与您携手共建，加速社区生态协同发展，共同引领云原生边缘计算迈向产业应用新高度。

 OSI七层参考模型：开放式系统互联 OSI/RM  ISO—国际公有化组织 --分层以各司其职  分层作用：降低层次间的关联性，上层都在下层的基础上提供增值服务  七层：应用层-表示层-会话层-传输层-网络层-数据链路层-物理层  应用层---应用程序  表示层---抽象语言转化为二进制  会话层---建立维护和断开一次链接（主机和服务器间建立的会话通讯）  传输层：端到端的传输，应用到应用间的传输，区分进程和服务。  端口号：16位二进制构成0-65535，真正使用的是1-1023端口号（称为知名端口号，著名端口号）  HTTP协议（超文本传输，可传输图片、声音等）：TCP 80端口（Dport） web访问需要用到的协议  HTTPS协议（“S”: SSL安全协议，比HTTP更安全）：443端口（Dport）  访问网站流程：sport：x  Dport：443  发送                Sport：443  Dport：x  回复  网络层  数据链路层：介质访问控制层（MAC）+逻辑链路控制层（LLC）  物理层：一串电流  协议簇：     PCU—协议数据单元（命名）  应用层—数据报文  传输层—数据段  网络层—数据包  数据链路层—数据帧（掉帧即为该层数据丢失）  物理层—比特流  封装：从应用层开始到数据链路层结束，物理层为电流不需要封装。    解封装：把封装的协议包层层解开得到数据。   应用层：        传输层：TCP协议 UDP协议  TCP与UDP协议的区别：  TCP优点：  1.TCP是面向连接的协议，UDP是无连接的协议---TCP的三次握手 2.TCP是可靠的传输层协议，UDP是一种“尽力而为”的协议，排序，确认，重传，流控 3.TCP可以进行分段，UDP不能进行数据分段（数据分段：对大型数据传输中将其分成多个小数据多次传送，“大而化小”降低影响） 4.TCP可以进行流量控制（在某一时间点控制发送或接受数据包数量），而UDP不能  UDP优点：  1.TCP传输速率慢，而UDP传输速率快，TCP（参数多）资源占用比较大，而UDP资源占用小 Sum：即时通讯类会采用UDP，文件、邮件这一类对可靠性要求较高的数据采用TCP进行传输  最小长度（无选项）：5*4=20字节   UDP：   校验和：校验数据完整性，在发送 TCP 数据段时，由发送端计算校验和，当到达目的地时又进行一次检验和计算。如果两次校验和一致，说明数据是正确的，否则将认为数据被破坏，接收端将丢弃该数据。  伪头部校验—除了校验自身协议头部内容外，还会校验部分IP协议的内容  可变长头部---首部长度：标注TCP头部大小  FIN—发送端完成位，提出断开连接一方要把FIN置为1表示断开连接  SYN—同步序号位，TCP建立时要设置该值为1  URG—紧急标志位  ACK—确认标志位（为1表示确认号）  PSH—推送  TCP的三次握手：      1.发送一个SYN包，并等待确认，标志位为SYN=1，表示请求建立连接；序号为Seq = x（x 一般取随机数）；  2.接收到发来的SYN包后，对该包进行确认后结束，并返回一段 TCP 报文。标志位为SYN和 ACK，表示确认客户端的报文 Seq 序号有效，能正常接收A发送的数据，并同意创建新连接； 序号为 Seq = y；确认号为 Ackn（ack）= x + 1，表示收到序号 Seq 并将其值加 1 作为自己确认号 Ack 的值（询问下一个数据包）。  3.接收到发送的 SYN + ACK 包后，明确了数据传输是正常的，并返回最后一段报文。标志位为 ACK，表示确认收到同意连接的信号；序号为 Seq = x + 1，表示收到确认号 Ack，并将其值作为自己的序号值；确认号为 Ack= y + 1，表示收到服务器端序号 seq，并将其值加 1 作为自己的确认号 Ack 的值。  四次挥手：   流控：滑动窗口机制  发送时Ack=1、2、3、4，win=4（发几个就是几）  接收时Ack=5，win=4（收几个就是几）  下一次发送时win会增大，随后会跟随用户网速逐渐减小/增大  网络层：IP协议   MTU—最大传输单元：1500字节  默认携带的最大数据量—1500-20（tcp）-20（ip）=1460字节  MSS—最大段长度1480  生存时间—每经过一个路由器的转发，这个TTL的值会减一  协议：标注上层协议类型，  数据链路层：以太网协议（以太网二型帧）     1byte=1字节=8位二进制  类型：标注上层协议类型，解封装时重要的参数  FCS：校验和（校验数据完整性的参数）运用SRC循环冗余算法 ————————————————                              版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                          原文链接：https://blog.csdn.net/2301_80943978/article/details/135197036 

 一、云计算的基本概念 定义与内涵 云计算是一种基于互联网的计算模式，通过网络将大量的计算资源（如服务器、存储、应用软件、服务等）进行整合，以服务的形式提供给用户。 它实现了资源的虚拟化，使得用户无需直接管理和维护物理硬件设施，就能按需获取和使用计算能力，就像使用水电等公共资源一样便捷。 云计算涵盖了基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）等多种服务层次，满足不同用户的多样化需求。 核心技术支撑 虚拟化技术是云计算的基石，它将物理资源抽象为虚拟资源，提高资源利用率和灵活性，例如可在一台物理服务器上运行多个虚拟机，每个虚拟机都能独立运行操作系统和应用程序。 分布式存储技术通过将数据分散存储在多个节点上，确保数据的可靠性和高可用性，同时具备良好的扩展性，可轻松应对数据量的快速增长。 弹性计算技术能够根据用户的实际需求，快速自动地调整计算资源的分配，如在业务高峰期自动增加服务器实例，业务低谷期回收资源，节省成本。 与传统计算模式对比 传统计算模式下，企业需要自行购买、部署和维护硬件设备及软件系统，前期投资大、建设周期长；而云计算采用按需付费模式，降低了前期成本和运维成本，企业可将更多资金投入到核心业务创新中。 传统模式的资源利用率低，大量硬件资源可能处于闲置状态；云计算通过资源池化和动态分配，显著提高了资源利用率，减少资源浪费。 在应对业务快速变化和突发需求方面，传统计算模式的扩展能力有限且速度慢；云计算能够迅速提供所需资源，快速响应市场变化，增强企业竞争力。 服务模式详解 IaaS 为用户提供基础的计算、存储和网络等基础设施资源，用户可自行安装和管理操作系统、中间件和应用程序，具有高度的灵活性和控制权，如亚马逊的 EC2、阿里云的 ECS 等。 PaaS 提供了应用程序开发和部署的平台，包括操作系统、编程语言运行环境、数据库等，用户专注于应用开发，无需关心底层基础设施的管理和维护，如 Heroku、谷歌的 App Engine 等。 SaaS 则是直接向用户提供完整的软件应用，用户通过浏览器或客户端即可使用，无需进行本地安装和维护，如办公软件 Office 365、客户关系管理系统 Salesforce 等。 部署模型差异 公有云由第三方云服务提供商拥有和运营，面向公众开放，资源共享程度高，成本相对较低，适合中小企业和对成本敏感、需求灵活多变的用户，但在数据安全性和隐私方面可能存在一定风险。 私有云专为单个企业或组织构建，部署在企业内部数据中心或托管在第三方，数据安全性和隐私性强，可根据企业特定需求进行定制化配置，但建设和维护成本较高，适用于对安全性和合规性要求严格的大型企业。 混合云结合了公有云和私有云的优势，企业可将敏感数据和关键业务放在私有云，非关键业务或临时性业务需求放在公有云，实现资源的灵活调配和优化利用，兼具安全性和成本效益，是许多企业的理想选择。 二、云计算的关键特性 按需自助服务 用户能够通过云服务提供商的自助平台，根据自身业务需求，随时自主地获取所需的计算资源，如服务器实例、存储空间、网络带宽等，无需人工干预。 这种自助服务模式打破了传统 IT 资源获取的繁琐流程，大大缩短了资源交付时间，用户可以在几分钟甚至几秒钟内完成资源的申请和部署，快速响应业务变化。 同时，用户可以根据业务量的变化，灵活地调整资源的配置，如增加或减少 CPU 核心数、内存大小等，真正实现资源的按需使用，避免资源闲置和浪费，降低成本。 广泛的网络访问 云计算服务通过互联网进行访问，用户可以使用各种终端设备（如笔记本电脑、智能手机、平板电脑等），在任何有网络连接的地方，随时随地访问和使用云服务。 这种便捷的网络访问方式，打破了地域和时间的限制，使得企业员工能够远程办公、协同工作，提高工作效率和灵活性，促进了企业的全球化业务拓展和创新。 云服务提供商通过采用先进的网络技术（如内容分发网络 CDN、高速光纤网络等），确保用户在不同地区和网络环境下都能获得稳定、高速的服务体验，保障业务的连续性和可靠性。 资源池化 云计算将计算资源（如服务器、存储设备、网络带宽等）进行集中整合，形成一个庞大的资源池，通过虚拟化技术对资源进行抽象和分配，实现资源的共享和复用。 资源池化使得云服务提供商能够根据用户的需求，动态地分配和管理资源，提高资源利用率和灵活性，降低运营成本，同时也能够快速响应用户的资源请求，提供高效的服务。 为了确保资源池的高效运行和资源的合理分配，云服务提供商采用了先进的资源调度算法和管理系统，对资源的使用情况进行实时监控和优化，保障各个用户的服务质量和性能。 快速弹性扩展 云计算能够根据用户业务量的变化，快速自动地调整资源的分配和配置，实现弹性扩展和收缩。在业务高峰期，云服务提供商可以迅速为用户提供更多的计算资源，以满足业务需求；在业务低谷期，则回收闲置资源，降低成本。 这种快速弹性扩展能力，使得企业能够轻松应对突发的业务流量增长、季节性业务高峰等情况，无需提前过度投资硬件设备，提高了企业的应变能力和竞争力。 云服务提供商通过自动化的资源管理系统和弹性伸缩策略，实现了资源的快速调配和优化，确保在资源扩展和收缩过程中，业务的连续性和稳定性不受影响，用户体验不受损害。 可计量的服务 云计算采用了精确的计量技术，对用户使用的各种计算资源（如 CPU 时间、内存使用量、存储容量、网络流量等）进行实时监测和计量，并按照使用量向用户收取费用。 这种可计量的服务模式，使得用户能够清楚地了解自己的资源使用情况和费用支出，便于进行成本控制和预算管理，避免了传统 IT 模式下资源使用的不透明和成本超支问题。 云服务提供商通过提供详细的计费报告和资源使用分析工具，帮助用户优化资源配置，提高资源利用率，降低成本，同时也为用户提供了更多的选择和灵活性，用户可以根据自己的业务需求和预算，选择合适的资源套餐和计费方式。 三、云计算的主要优势 成本效益显著 降低硬件采购成本，企业无需购买昂贵的服务器、存储设备等硬件设施，避免了硬件设备的折旧和更新换代成本，只需根据实际使用情况向云服务提供商支付相应的费用，节省了大量的前期投资。 减少运维人力成本，云服务提供商负责基础设施的管理和维护，企业无需配备专业的 IT 运维团队，降低了人力成本和培训成本，同时也减少了因运维失误导致的业务风险和损失。 提高资源利用率，云计算通过资源池化和弹性扩展技术，实现了资源的动态分配和共享复用，避免了传统 IT 模式下资源闲置浪费的问题，提高了资源利用率，进一步降低了单位资源的使用成本。 按需付费模式使企业能够根据业务发展情况灵活调整资源使用量和费用支出，避免了资源过度配置或不足的情况，实现成本的精准控制，提高了企业的资金使用效率。 云服务提供商通常具有规模经济优势，能够通过大规模采购硬件设备、优化数据中心运营等方式降低成本，并将部分成本优势传递给用户，使得用户能够以更低的价格获得高质量的 IT 服务。 强大的灵活性与可扩展性 云计算支持多种服务模式（IaaS、PaaS、SaaS）和部署模型（公有云、私有云、混合云），企业可以根据自身业务需求和技术能力，选择最适合的云计算方案，实现个性化的 IT 架构搭建和应用部署。 能够快速响应业务变化，企业在业务增长或业务需求发生变化时，可以通过云服务提供商的自助平台或自动化工具，轻松地增加或减少计算资源、扩展或收缩应用系统的规模，无需进行复杂的硬件设备升级和系统架构调整。 支持新型业务模式和创新应用的快速开发与部署，企业可以利用云计算平台提供的丰富的开发工具、API 接口和应用组件，快速搭建和上线新的业务应用，缩短产品上市时间，抢占市场先机，促进企业的业务创新和发展。 可以方便地与现有 IT 系统进行集成和整合，企业在采用云计算的过程中，可以通过云平台提供的各种集成工具和接口，将云计算服务与企业内部的传统 IT 系统（如企业资源规划 ERP、客户关系管理 CRM 等）进行无缝对接，实现数据和业务流程的互联互通，保护企业的现有 IT 投资。 云服务提供商不断推出新的服务和功能，企业可以根据自身业务发展需求，及时选用这些新的服务和功能，不断优化和提升自身的 IT 能力和业务竞争力，无需担心技术过时和淘汰的问题。 提升业务敏捷性 加速应用开发和部署周期，云计算平台提供了丰富的开发工具、预配置的应用环境和自动化的部署流程，开发团队可以专注于业务逻辑的实现，无需花费大量时间搭建和配置开发环境，大大缩短了应用开发和上线的时间，提高了企业的创新速度。 促进团队协作和沟通效率，基于云计算的办公软件和协作平台，使得企业员工可以随时随地进行文档协作、项目管理、在线会议等工作，打破了时间和空间的限制，提高了团队的协作效率和沟通效果，加速了业务决策和执行的速度。 快速响应市场变化和客户需求，企业可以利用云计算的弹性扩展和快速部署能力，及时调整业务策略和产品功能，快速推出满足市场变化和客户需求的新产品和新服务，提高客户满意度和市场占有率。 支持企业进行业务创新和试验，云计算的低成本和灵活性使得企业可以尝试一些新的业务模式、技术应用和营销手段，无需承担过高的风险和成本，如果试验成功则可以快速推广和扩大规模，如果失败则可以及时停止，避免了对企业核心业务的影响，降低了企业的创新风险。 提升企业的整体运营效率，云计算通过整合企业的 IT 资源、优化业务流程和提高团队协作效率，使得企业的各项业务能够更加顺畅地运行，减少了业务流程中的瓶颈和延误，提高了企业的生产效率和运营效益，增强了企业的市场竞争力。 数据安全性与可靠性保障 云服务提供商采用了多层次的数据安全防护措施，包括数据加密技术，对用户数据在传输和存储过程中进行加密处理，防止数据被窃取和篡改；访问控制机制，通过身份认证、授权管理等手段，确保只有合法用户能够访问相应的数据和资源，防止数据泄露和非法访问。 具备高可靠性的数据备份和恢复策略，云服务提供商通常会在多个地理位置的数据中心对用户数据进行备份，以防止因硬件故障、自然灾害、人为错误等原因导致的数据丢失，并能够在数据发生丢失或损坏时，快速地进行数据恢复，保障业务的连续性。 提供安全的网络环境，云服务提供商通过部署防火墙、入侵检测系统、DDoS 攻击防护等网络安全设备和技术，对云平台进行实时监控和防护，防止网络攻击和恶意流量对用户数据和应用的影响，确保云平台的网络安全稳定。 符合严格的安全标准和法规合规要求，许多云服务提供商通过了国际和国内的各种安全认证（如 ISO 27001、SOC 2 等），并遵循相关的法律法规（如 GDPR、CCPA 等），保障用户数据的安全性和隐私性，企业在使用云计算服务时，可以借助云服务提供商的专业安全能力，满足自身业务的安全合规需求。 云服务提供商拥有专业的安全团队和应急响应机制，能够及时发现和处理安全漏洞和安全事件，对安全威胁进行快速响应和处置，降低安全事件对用户业务的影响，为用户提供可靠的安全保障。 促进全球协作与业务拓展 打破地域限制，云计算使得企业员工、合作伙伴和客户可以在全球范围内通过互联网访问和使用企业的应用系统和数据资源，实现了全球范围内的信息共享和业务协作，促进了企业的国际化业务拓展和跨国团队合作。 便于企业在全球范围内快速部署业务应用和服务，企业可以利用云服务提供商在全球各地的数据中心和网络节点，将业务应用快速部署到目标市场，降低了跨国业务运营的技术门槛和成本，提高了企业的市场响应速度和业务拓展能力。 支持多语言和多地区的业务运营需求，云服务提供商的平台和应用通常具备多语言支持能力，企业可以根据不同地区和国家的语言文化特点，定制化开发和部署本地化的业务应用，满足当地用户的需求，提高企业的全球市场适应性和竞争力。 促进全球供应链的协同管理，通过云计算平台，企业可以与全球各地的供应商、合作伙伴进行实时的信息交互和业务协同，实现供应链的可视化管理和优化，提高供应链的效率和灵活性，降低供应链成本，增强企业在全球供应链中的竞争力。 有利于企业开展全球化的市场营销和客户服务，企业可以利用云计算平台的大数据分析能力和营销自动化工具，对全球市场和客户进行精准的市场分析和营销推广，提供个性化的客户服务，提高客户满意度和忠诚度，拓展全球客户市场。 四、云计算的应用领域 企业资源规划（ERP）与办公自动化 基于云计算的 ERP 系统，企业无需在本地部署复杂的硬件和软件设施，只需通过浏览器登录云平台，即可随时随地访问和管理企业的财务、采购、生产、销售、人力资源等核心业务流程，实现企业资源的集中化管理和协同运作。 办公自动化软件（如文档编辑、电子表格、演示文稿等）在云端的应用，使得企业员工可以在线协作编辑文档、实时共享文件资料、进行远程会议和沟通交流，提高了办公效率和团队协作能力，降低了企业的办公成本和沟通成本。 云 ERP 系统和办公自动化软件的集成应用，实现了企业业务流程和办公流程的无缝对接，数据的实时共享和交互，减少了人工数据录入和传递的错误，提高了数据的准确性和及时性，为企业的决策提供了更加准确的数据支持。 云服务提供商可以根据企业的行业特点和业务需求，为企业提供定制化的 ERP 和办公自动化解决方案，满足不同企业的个性化需求，同时还能够快速响应企业业务变化和升级需求，通过在线更新和升级软件功能，保持企业 IT 系统的先进性和适应性。 利用云计算的大数据分析功能，企业可以对 ERP 系统和办公自动化软件中产生的大量数据进行深入挖掘和分析，发现潜在的业务问题和市场机会，优化业务流程和决策制定，提高企业的运营管理水平和市场竞争力。 客户关系管理（CRM） 云 CRM 系统帮助企业集中管理客户信息，包括客户基本资料、购买历史、沟通记录等，实现客户信息的统一存储和共享，方便企业各部门随时了解客户情况，提供更加个性化的客户服务，提高客户满意度和忠诚度。 支持销售团队的日常工作，如客户线索管理、销售机会跟进、销售预测等，通过云计算的移动性和实时性，销售人员可以在外出拜访客户时，通过手机或平板电脑随时随地访问 CRM 系统，更新客户信息和销售进展，及时获取上级的指导和支持，提高销售效率和业绩。 提供市场营销自动化功能，企业可以利用云 CRM 系统进行市场活动策划、目标客户群体细分、营销邮件发送等活动，并对营销活动的效果进行实时跟踪和分析，优化营销策略和投资回报率，精准地获取潜在客户，促进企业业务增长。 云 CRM 系统的社交化功能，使得企业能够整合社交媒体平台上的客户数据和互动信息，深入了解客户的社交行为和需求偏好，更好地进行客户关系维护和品牌推广，拓展客户市场和业务渠道。 通过与其他企业应用系统（如 ERP、客服系统等）的集成，云 CRM 系统实现了企业前后端业务流程的无缝衔接，数据的双向流通和共享，提高了企业整体的运营效率和客户响应速度，为客户提供更加连贯和优质的服务体验。 电子商务与在线零售 云计算为电子商务平台提供了强大的计算能力和存储资源，支持海量商品信息的存储和管理、高并发的用户访问和交易处理，确保平台在促销活动、节假日等高峰时期的稳定运行，提升用户购物体验。 利用云计算的弹性扩展能力，电子商务企业可以根据业务量的变化，快速调整服务器资源和带宽资源，灵活应对业务增长和流量波动，避免因资源不足导致的网站卡顿、交易失败等问题，同时也降低了企业的硬件采购和运维成本。 云平台提供的大数据分析服务，帮助电子商务企业深入了解消费者的购物行为、偏好和需求，进行精准的商品推荐、个性化营销和价格优化，提高客户的购买转化率和复购率，增加企业的销售额和利润。 电子商务企业可以借助云计算的全球网络覆盖和多地区部署能力，快速将业务拓展到全球市场，为不同地区的消费者提供本地化的购物体验，包括语言支持、货币结算、物流配送等，降低跨国业务运营的技术门槛和成本，提升企业的国际竞争力。 云平台还支持电子商务企业与各类第三方支付机构、物流配送公司等进行深度集成，实现支付流程的安全便捷和物流信息的实时跟踪，确保订单的顺利交付和客户的满意度。同时，利用云计算的人工智能和机器学习技术，能够对交易数据进行实时监测和分析，及时发现并防范欺诈行为，保障企业和消费者的权益，为电子商务业务的健康发展提供坚实的技术保障。  五、云计算面临的挑战与应对策略 1.数据安全与隐私问题 挑战：用户数据集中存放在云服务提供商的数据中心，面临数据泄露、篡改、丢失等风险。云服务提供商可能因技术漏洞、内部人员违规操作或遭受外部攻击，导致用户敏感信息曝光，引发严重的隐私危机，影响用户对云计算的信任。 应对策略：云服务提供商应加强数据加密技术的应用，在数据传输和存储过程中采用高强度的加密算法，确保数据的机密性。建立严格的访问控制机制，基于用户身份、角色和权限进行精细的访问管理，防止未经授权的访问。同时，定期进行安全审计和漏洞扫描，及时发现并修复潜在的安全隐患。企业用户在选择云服务提供商时，应重点考察其安全防护措施和安全认证情况，签订详细的安全协议，明确双方的数据安全责任。 网络延迟与性能优化 挑战：对于一些对实时性要求较高的应用（如在线游戏、视频直播、金融交易等），云计算可能会因网络延迟问题影响用户体验。数据传输距离、网络拥塞、云服务提供商的网络架构等因素都可能导致数据传输速度变慢，响应时间延长，降低应用的性能和可用性。 应对策略：云服务提供商可以通过优化数据中心的分布，在全球各地建立更多的边缘数据中心，将计算资源靠近用户，减少数据传输距离，降低网络延迟。采用内容分发网络（CDN）技术，将常用的数据和内容缓存到离用户更近的节点，加速数据的传输和访问。此外，不断升级网络基础设施，提高网络带宽和传输速度，采用先进的网络优化算法，对网络流量进行智能调度和管理，确保关键应用的网络性能。 服务可靠性与中断风险 挑战：尽管云服务提供商通常具备高可靠性的架构设计，但仍可能因硬件故障、软件漏洞、自然灾害、电力中断等原因导致服务中断。服务中断不仅会影响企业的正常业务运营，还可能造成经济损失和声誉损害，尤其对于那些依赖云计算的关键业务系统来说，风险更为突出。 应对策略：云服务提供商应构建冗余的硬件架构和备份系统，采用分布式存储和多副本技术，确保数据的持久性和可用性。建立完善的灾难恢复计划，定期进行灾难恢复演练，确保在发生故障或灾难时能够快速切换到备用系统，保障服务的连续性。同时，向用户提供透明的服务状态监控信息和故障通知机制，让用户及时了解服务的运行情况，并采取相应的应对措施。企业用户也可以通过采用多云策略，将业务分布在多个云服务提供商上，降低因单一云平台故障而导致的业务中断风险。 供应商锁定问题 挑战：企业在使用云计算服务过程中，可能会因依赖特定云服务提供商的技术架构、接口和工具，而面临供应商锁定的困境。当企业想要更换云服务提供商或采用混合云策略时，可能会遇到数据迁移困难、应用兼容性问题、成本过高等障碍，限制了企业的灵活性和选择空间。 应对策略：企业在选择云服务提供商时，应优先考虑采用开放标准和开源技术的平台，确保数据和应用的可移植性。在应用开发过程中，遵循行业最佳实践和通用的架构设计原则，减少对特定云服务提供商专有技术的依赖。同时，定期评估云服务提供商的服务质量和成本效益，与供应商保持良好的沟通和合作关系，争取在合同中明确数据迁移和服务退出的条款和条件，以便在必要时能够顺利切换供应商或调整云计算策略。 法律法规与合规性风险 挑战：云计算的跨地域特性使得企业在使用云服务时，需要面对不同国家和地区复杂多变的法律法规和合规要求。例如，数据隐私保护法规、行业监管规定、税收政策等方面的差异，可能导致企业在数据存储、处理和传输过程中面临合规风险，一旦违反相关法律法规，企业可能会面临巨额罚款、法律诉讼等严重后果。 应对策略：云服务提供商应密切关注全球各地的法律法规变化，建立合规管理体系，确保自身的服务符合相关法规要求，并向用户提供合规性保障和指导。企业用户在使用云计算服务前，应充分了解所在行业和业务涉及地区的法律法规，对云服务提供商的合规能力进行评估，选择能够满足自身合规需求的供应商。同时，企业应加强内部的合规管理和培训，建立健全的数据治理机制，确保在云计算环境下的数据处理活动合法合规。 六、云计算的未来发展趋势 混合云与多云架构的普及 随着企业对云计算应用的深入，单一的公有云或私有云架构难以完全满足企业复杂的业务需求和安全要求。未来，混合云将成为主流趋势，企业会更加灵活地将核心业务和敏感数据部署在私有云，而将非关键业务和弹性需求放在公有云，实现资源的最优配置和业务的敏捷性。 多云策略也将得到更广泛的应用，企业通过与多个云服务提供商合作，利用不同云平台的优势，避免供应商锁定，提高业务的可靠性和灵活性。同时，云管理平台和工具将不断发展，帮助企业更方便地管理和协调多个云环境，实现无缝的跨云资源调度和应用部署。 人工智能与云计算的深度融合 人工智能技术（如机器学习、深度学习、自然语言处理等）将与云计算紧密结合，云平台将为人工智能应用提供强大的计算能力和海量的数据存储，加速人工智能模型的训练和推理过程。 基于云计算的人工智能服务将更加普及，企业无需自行搭建复杂的人工智能基础设施，即可通过云服务轻松应用人工智能技术，实现智能客服、智能营销、智能预测等功能，提升业务的智能化水平和竞争力。 人工智能还将用于优化云计算资源的管理和调度，通过智能算法实现自动的资源分配、性能优化和故障预测，提高云计算平台的运营效率和可靠性。 边缘计算与云计算的协同发展 随着物联网设备的大量增加和对实时性要求较高的应用场景（如工业自动化、智能交通、远程医疗等）的出现，边缘计算将与云计算相辅相成。边缘计算将计算和数据存储靠近数据源或用户端，减少数据传输延迟，提高响应速度，而云计算则负责处理大规模的数据汇总、分析和复杂的业务逻辑。 未来，云服务提供商将构建更加完善的边缘计算架构，实现边缘节点与云中心的高效协同，提供统一的管理和调度平台，让企业能够更加灵活地在边缘和云端部署应用，满足不同场景下的业务需求。 无服务器计算的兴起 无服务器计算（Serverless Computing）将逐渐成为云计算的重要组成部分，开发人员无需关心服务器的配置和管理，只需专注于编写代码和业务逻辑。云服务提供商将根据应用的实际运行情况自动分配和管理计算资源，实现真正的按需计费，进一步降低企业的运营成本和开发门槛。 无服务器架构将在事件驱动型应用、微服务架构等领域得到广泛应用，加速应用的开发和部署速度，提高资源利用率，使得企业能够更加敏捷地响应市场变化和用户需求。 绿色云计算的发展 随着全球对环境保护和可持续发展的关注度不断提高，绿色云计算将成为未来的重要发展方向。云服务提供商将致力于降低数据中心的能耗，采用更加高效的服务器硬件、冷却技术和能源管理系统，提高能源利用效率。 同时，通过优化数据中心的选址和布局，利用可再生能源（如太阳能、风能等）为数据中心供电，减少对传统能源的依赖，降低碳排放，实现云计算产业的绿色发展，为企业和社会创造更大的环境价值。 七、企业如何成功应用云计算 明确业务需求与目标 企业在采用云计算之前，应深入分析自身的业务需求和目标，确定哪些业务流程和应用适合迁移到云端，以及期望通过云计算实现什么样的业务价值，如降低成本、提高效率、加速创新、拓展市场等。 对企业现有的 IT 基础设施和应用系统进行全面评估，了解其技术架构、性能瓶颈、数据存储和管理方式等情况，以便更好地规划云计算的应用场景和迁移策略，确保云计算的应用能够与企业的整体业务战略相契合。 选择合适的云服务提供商 根据企业的业务需求、预算、安全要求和合规性标准，选择具有良好声誉、可靠技术实力和丰富行业经验的云服务提供商。评估云服务提供商的服务质量，包括可用性、性能、可靠性、安全性等方面，参考其客户评价和行业口碑。 考虑云服务提供商的服务范围和产品特点，是否能够提供满足企业需求的各种云计算服务模式（IaaS、PaaS、SaaS）和部署模型（公有云、私有云、混合云），以及其是否具备灵活的定价策略和良好的客户支持服务，确保在使用云计算过程中能够得到及时的技术支持和问题解决。 制定详细的迁移计划与策略 在进行应用和数据迁移到云端之前，制定详细的迁移计划，包括迁移的顺序、时间表、风险评估和应对措施等。对于复杂的应用系统，建议采用渐进式迁移策略，先迁移非关键业务或相对独立的模块，积累经验后再逐步迁移核心业务系统，降低迁移风险。 在迁移过程中，充分考虑数据的完整性和一致性，进行数据备份和验证，确保数据在迁移前后的准确性和可用性。同时，对应用进行必要的优化和适配，以充分利用云计算的优势，如弹性扩展、性能优化等，提高应用在云端的运行效率和稳定性。 加强安全与风险管理 建立完善的云计算安全管理体系，包括数据安全、网络安全、应用安全和身份管理等方面。制定严格的数据访问控制策略，对敏感数据进行加密存储和传输，定期进行安全审计和漏洞扫描，及时发现和解决潜在的安全问题。 加强对云服务提供商的安全监督和评估，确保其安全措施符合企业的要求和行业标准。同时，制定应对安全事件的应急预案，提高企业在面对安全威胁时的应急响应能力和恢复能力，降低安全风险对企业业务的影响。 培养云计算专业人才 云计算的应用需要企业具备一定的专业技术人才，包括云计算架构师、管理员、开发人员等。企业应加强对内部员工的云计算培训，提高员工对云计算技术的理解和应用能力，使其能够熟练掌握云计算平台的管理和开发工具，适应云计算环境下的工作方式和业务流程。 吸引外部云计算专业人才加入企业，充实企业的技术团队，为企业的云计算应用提供技术支持和创新动力。同时，鼓励员工参与云计算相关的行业交流和认证考试，不断提升员工的专业水平和综合素质，推动企业云计算应用的深入发展。 ————————————————                              你敢抄袭？自己写，要做个好孩子哦！！！                          原文链接：https://blog.csdn.net/hjxxlsx/article/details/144506771 

容器的介绍容器化技术，它是一种虚拟化技术，用于在计算机系统中隔离和运行应用程序。容器将应用程序及其所有依赖项打包到一个独立的、可移植的环境中，使其能够在不同的计算机或操作系统上运行。容器的特点：隔离性、轻量级、可移植性、弹性伸缩、生态系统。目前最流行的容器化技术是Docker，它提供了一个开放的平台，用于构建、分发和运行容器。除了Docker，还有其他容器化技术，如Kubernetes、Podman、Containerd等。容器的精髓在于镜像，而docker是容器镜像标准的制定者，因此，学习容器是绕不开docker的。Docker是一个开源的引擎，可以轻松的为任何应用创建一个轻量级的、可移植的、自给自足的容器Docker的技术架构Docker 客户端（Client）： Docker 客户端是用户与 Docker 交互的命令行工具或图形界面工具。用户可以使用 Docker 客户端发送命令和指令，例如构建镜像、创建容器、启动容器等。Docker 客户端与 Docker 主机进行通信，通过 API 接口或者 Docker 配置文件进行交互。常见的 Docker 客户端包括 Docker CLI（命令行界面）和 Docker Dashboard（图形用户界面）。Docker 主机（Docker Host）： Docker 主机是安装和运行 Docker 引擎的物理或虚拟机器。它负责管理容器的创建、启动、停止和销毁等生命周期操作。Docker 主机上运行着 Docker 引擎，它接收来自 Docker 客户端的指令，并执行相应的操作。Docker 主机上可以同时运行多个容器，并提供了资源隔离、网络管理和存储管理等功能。镜像仓库（Registry）： 镜像仓库是用于存储和分发 Docker 镜像的中央仓库。镜像仓库允许用户上传、下载和共享镜像。当用户在 Docker 主机上创建镜像时，可以选择将镜像推送到镜像仓库中，以便其他人可以使用这个镜像。Docker Hub 是官方提供的公共镜像仓库，用户可以从中获取各种常用的镜像。除了 Docker Hub，还有一些私有和第三方的镜像仓库可供选择，例如 Harbor、Azure Container Registry 等。在整个架构中，Docker 客户端与 Docker 主机通过 API 接口进行通信，Docker 主机负责管理容器的运行和资源隔离。镜像仓库则是存储和分享镜像的中央仓库，用户可以从中拉取镜像或将自己创建的镜像推送至其中。这样，Docker 技术架构实现了应用程序的打包、分发和部署，提供了一种便捷、可移植和可扩展的容器化环境。容器的工作机制（Docker）Docker 客户端（Docker Client）：Docker 客户端是用户与 Docker 交互的命令行工具或 GUI 工具。它向 Docker 引擎发送指令，如拉取镜像、创建容器、启动容器等。Docker 引擎（Docker Engine）：Docker 引擎是 Docker 的核心组件，负责管理容器的生命周期，包括创建、启动、停止、删除等操作。它还提供了一组 API 接口和命令行工具，供用户与 Docker 进行交互。容器（Container）：容器是从容器镜像创建的运行实例。它是一个独立的、隔离的执行环境，其中应用程序可以在其中运行。容器具有自己的文件系统、网络和进程空间，但与主机系统是隔离的。Docker 客户端和 Docker 引擎是分离的两个组件，Docker 客户端发送指令给 Docker 引擎，Docker 引擎执行指令并管理容器的生命周期。容器则是从容器镜像创建的运行实例，它具有隔离性、资源管理和网络管理等特性，使得应用程序可以在一个独立且可移植的环境中运行。容器的关键技术 - NamespaceNamespace是Linux内核对系统资源进行隔离和虚拟化的特性，这些系统资源包括：PID ：PID 命名空间提供了进程 ID 的隔离。User：User 命名空间提供了用户和用户组的隔离。UTS：UTS 命名空间提供了主机名和域名的隔离。IPC：IPC 命名空间提供了进程间通信（IPC）资源的隔离，如共享内存、信号量和消息队列等。Net：Net 命名空间提供了网络资源的隔离，包括网络接口、IP 地址、路由表和网络命名空间等。Mnt：Mnt 命名空间提供了文件系统挂载点的隔离。Namespace隔离说明以交互模式启动一个centos容器，并在其中运行/bin/bash程序。执行ps命令查看到“/bin/bash”是PID=1的进程，即docker将其隔离于宿主机中的其他进程[root@localhost ~]# docker run -it centos /bin/bash [root@24b87937f13d /]# ps axf PID TTY STAT TIME COMMAND 1 pts/0 Ss 0:00 /bin/bash 14 pts/0 R+ 0:00 ps axf打开另一个终端，使用docker inspect查看容器进程在宿主机上的真实PID。实际上，该容器上运行的”/bin/bash”在宿主机上是PID=96745的进程[root@localhost ~]# docker inspect 24b87937f13d | grep Pid "Pid": 96745, "PidMode": "", "PidsLimit": 0,容器的关键技术 - CgroupCgroups：Linux Control Group作用：限制一个进程组对系统资源的使用上限，包括CPU、内存、Block I/O等Cgroups还能设置进程优先级，对进程进行挂起和恢复等操作原理：将一组进程放在一个Cgroup中，通过给这个Cgroup分配指定的可用资源，达到控制这一组进程可用资源的目的实现：在Linux中，Cgroups以文件和目录的方式组织在操作系统的/sys/fs/Cgroup路径下。该路径中所有的资源种类均可被Cgroup限制Docker环境搭建操作系统内存处理器硬盘网络Centos 8 Stream4 GB150GBNAT1）安装基础软件包[root@docker ~]# yum install -y vim net-tools bash-completion yum-utils # 或者退出重新登录，为了自动补全 [root@docker ~]# bash 2）下载docker-ce repo文件[root@docker ~]# yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo [root@docker ~]# cd /etc/yum.repos.d/ [root@docker yum.repos.d]# ls CentOS-Stream-AppStream.repo CentOS-Stream-BaseOS.repo CentOS-Stream-Debuginfo.repo CentOS-Stream-Extras-common.repo CentOS-Stream-Extras.repo CentOS-Stream-HighAvailability.repo CentOS-Stream-Media.repo CentOS-Stream-NFV.repo CentOS-Stream-PowerTools.repo CentOS-Stream-RealTime.repo CentOS-Stream-ResilientStorage.repo CentOS-Stream-Sources.repo docker-ce.repo3）安装# 查看docker版本 [root@docker ~]# yum list docker-ce --showduplicates | sort -r # 默认安装最新版 [root@docker ~]# yum install -y docker-ce # 安装指定版本 [root@docker ~]# yum install -y docker-ce-20.10.22 docker-ce-cli-20.10.224）启动# 查看docker版本 [root@docker ~]# docker -v Docker version 24.0.6, build ed223bc #开启docker服务、开机自启、查看状态 [root@docker ~]# systemctl enable docker.service Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /usr/lib/systemd/system/docker.service. [root@docker ~]# systemctl start docker.service [root@docker ~]# systemctl status docker.service ● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; > Active: active (running) since Sun 2023-09-17 17:20:23 CST; 5s ago Docs: https://docs.docker.com Main PID: 12240 (dockerd) Tasks: 7 Memory: 28.4M CGroup: /system.slice/docker.service └─12240 /usr/bin/dockerd -H fd:// --containerd=/run/conta> Sep 17 17:20:22 docker systemd[1]: Starting Docker Application Conta> Sep 17 17:20:22 docker dockerd[12240]: time="2023-09-17T17:20:22.760> Sep 17 17:20:22 docker dockerd[12240]: time="2023-09-17T17:20:22.770> Sep 17 17:20:23 docker dockerd[12240]: time="2023-09-17T17:20:23.159> Sep 17 17:20:23 docker dockerd[12240]: time="2023-09-17T17:20:23.241> Sep 17 17:20:23 docker dockerd[12240]: time="2023-09-17T17:20:23.250> Sep 17 17:20:23 docker dockerd[12240]: time="2023-09-17T17:20:23.250> Sep 17 17:20:23 docker dockerd[12240]: time="2023-09-17T17:20:23.263> Sep 17 17:20:23 docker systemd[1]: Started Docker Application Contai>5）配置镜像加速器以阿里云镜像加速器为例[root@docker ~]# mkdir -p /etc/docker [root@docker ~]# tee /etc/docker/daemon.json <<-'EOF' { "registry-mirrors": ["https://as5wzlk8.mirror.aliyuncs.com"] } EOF { "registry-mirrors": ["https://as5wzlk8.mirror.aliyuncs.com"] } [root@docker ~]# cat /etc/docker/daemon.json { "registry-mirrors": ["https://as5wzlk8.mirror.aliyuncs.com"] } # 重新加载配置文件 [root@docker ~]# systemctl daemon-reload # 重新启动docker服务 [root@docker ~]# systemctl restart docker.service # 标准的完整名称 服务器 仓库/分类 镜像 版本 registry.cn-hangzhou.aliyuncs.com/cloudcs/centos:latest # 版本默认情况下，如果不指定，那么默认为 latestDocker基本操作# 镜像的下载 [root@docker ~]# docker pull mysql # 镜像重命名 [root@docker ~]# docker tag mysql:latest mysql:666 # 镜像的删除 [root@docker ~]# docker rmi mysql:latest # 镜像历史信息 [root@docker ~]# docker history mysql:latest # 镜像保存 [root@docker ~]# docker save mysql alpine > /tmp/all.tar # 镜像导入 [root@docker ~]# docker load -i /tmp/all.tar尝试运行一个容器[root@docker ~]# docker run -tid --name d1 --restart always alpine 44936d56248d3c9657e502168ea91098b2caa69a065a7d712dd4d3048b3f508d # 查看正在运行容器 [root@docker ~]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 44936d56248d alpine "/bin/sh" 26 seconds ago Up 25 seconds d1 # 进入容器 [root@docker ~]# docker exec -ti d1 /bin/sh / # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 8: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0 valid_lft forever preferred_lft forever / # exit感谢您阅读本文。我希望它能给您带来新的思考和启发，并为您的未来带来积极的影响。如果小伙伴们有任何问题或想法，请在下方留言，我会很乐意与您交流。谢谢各位小伙伴的支持。

作者：王彬丞&杨志佳&刘家伟针对新版本 Device-IoT 领域的更新，我们计划推出一系列的文章对这些特性进行详细的介绍，大致的文章大纲为：基于物模型的设备管理 API 设计与实现DMI 数据面能力设计与实现Mapper 开发框架 Mapper-Framework 设计与实现如何使用 Mapper 完成视频流数据处理如何使用 Mapper 实现设备数据写入如何从头开发一个 Mapper（以 modbus 为例） 在上一篇文章中，我们为适应用户对边缘设备管理的需求，设计实现了基于物模型的设备管理 API。在此基础上，我们完善了 DMI 数据面的能力，提供边缘端处理设备数据的多种方式，让 KubeEdge 能够更灵活、标准化的管理边缘设备。本篇文章是系列文章的第二篇，将详细介绍v1.15.0版本在 DMI 数据面的一些工作。DMI 数据面能力支持 在1.12版本中，KubeEdge 设计了设备管理框架——DMI。DMI 框架提供了统一的设备管理相关接口，设备应用开发者和使用者可以通过实现 DMI 中的标准化接口完成设备管理，让边缘设备以微服务的形式提供服务，更加贴合云原生。➤ DMI 的架构图如下图所示：DMI 框架中一个重要的特性是设备管理面与设备数据面解耦。设备管理面基于 Device CRD 承载设备本身的生命周期管理，如图中黄色线条；设备数据面则让设备数据通过微服务的方式向数据消费者应用提供，拥有多种数据推送方式，如图中蓝色线条。DMI 设备管理面数据主要包括设备的元数据、设备属性、配置、生命周期等，其特点是相对比较稳定，创建后信息更新较少，这类数据会通过云边通道进行传递。设备数据面数据则主要为设备传感器采集到的设备数据，相比于管理面数据来说数据量较大，若通过云边通道传输可能会造成通道阻塞，影响集群正常功能。v1.15.0版本中 DMI 数据面功能得到完善，通过数据面能以多样化的方式推送设备数据，相比通过云边通道传输数据更加合理。  DMI 数据面能力支持 ➤ DMI 数据面系统架构如下图所示：在v1.15.0版本更新后，DMI 数据面支持如图中四种方式处理推送设备数据：1、推送至用户应用。按照 v1beta1 版本的 Device Instance API 定义，用户能够在 Device Instance 配置文件中配置 pushMethod 字段，以 HTTP 或者 MQTT 的方式定时将设备数据推送到用户应用中。2、推送至用户数据库。最新版本的 KubeEdge DMI 内置 InfluxDB、Redis、TDengine、MySQL 数据库的数据推送方式，用户能够在 Device Instance 配置文件中 dbMethod 字段设置相应数据库的参数，将设备数据定时传入数据库。3、推送至云端。用户能够设置 Device Instance 配置文件中 reportToCloud 字段决定是否将设备数据推送至云端。4、用户能够通过 Mapper 提供的 RESTful API 主动拉取设备数据。以下是一个使用 DMI 数据面能力处理设备数据的 Device Instance 配置文件示例：apiVersion: devices.kubeedge.io/v1beta1 kind:Device ... spec: properties: -name:temp collectCycle:10000 # The frequency of reporting data to the cloud. once every 10 seconds reportCycle:10000 # The frequency of data push to user applications or databases. reportToCloud:true # Device data will be reported to cloud desired: value:"100" 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 dbMethod: influxdb2: # define the influx database config to push device data to user database influxdb2ClientConfig: url:http://127.0.0.1:8086 org:test-org bucket:test-bucket influxdb2DataConfig: measurement:stat tag: unit:temperature fieldKey: devicetest在示例文件中，用户可以通过 reportToCloud 字段定义 Mapper 是否将设备数据推送至云端；此外，pushmethod.mqtt 字段定义了 Mapper 向用户应用推送的配置信息，示例中表示 Mapper 会定时以 MQTT 协议的方式向 127.0.0.1:1883 地址的用户应用推送设备数据；pushmethod.dbMethod 字段定义了 Mapper 向用户数据库推送的配置信息，示例中表示 Mapper 会定时向 127.0.0.1:8086 地址的 InfluxDB 数据库推送设备数据。基于 DMI 数据面的能力，用户只需在 Device Instance 配置文件中定义相关字段，即可使用多种方式处理采集到的设备数据，有效降低了云边通道阻塞的风险。DMI 提供的功能接口最终是由设备管理插件 Mapper 来承载的。Mapper 北向需要实现 DMI 管理接口向 KubeEdge 完成自身的注册以及设备管理。对于用户来说，独立对接 DMI 接口实现自定义的 Mapper 使用门槛依然较高，因此我们在v1.15.0版本中推出 Mapper 开发框架 Mapper Framework，能够使用简单的命令自动生成一个 Mapper 工程供用户使用，有效降低用户上手的难度。在本系列的下一篇文章中，我们会对 Mapper Framework 的架构与使用方法进行详细介绍。【更多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/

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。Karmada v1.12版本[1]现已发布，本版本包含下列新增特性：应用级故障迁移功能增强（新增状态中继机制，适用于大数据处理程序高可用场景，如 Flink）单集群应用迁移能力增强（适用于单集群存量应用迁移）Karmada Operator 高可用部署能力支持OverridePolicy 支持局部修改结构化字段值新特性概览▶  应用级故障迁移功能增强在之前的版本中，Karmada 提供了基本的应用级故障迁移能力，能够通过应用的健康状态或自定义的故障等条件触发应用迁移。为了满足有状态应用在故障迁移过程中保留其运行状态的需求，Karmada 在 v1.12 版本新增了应用状态中继机制。对于大数据处理应用（例如 Flink），利用此能力可以从故障前的 checkpoint 重新启动，无缝恢复到重启前的数据处理状态，从而避免数据重复处理。社区在PropagationPolicy/ClusterPropagationPolicy API 中的.spec.failover.application 下引入了一个新的StatePreservation 字段， 用于定义有状态应用在故障迁移期间保留和恢复状态数据的策略。结合此策略，当应用从一个故障集群迁移到另一个集群时，能够从原始资源配置中提取关键数据。状态保留策略StatePreservation 包含了一系列StatePreservationRule 配置，通过 JSONPath 来指定需要保留的状态数据片段，并利用关联的 AliasLabelName 将数据传递到迁移后的集群。以 Flink 应用为例，在 Flink 应用中，jobID 是一个唯一的标识符，用于区分和管理不同的 Flink 作业（jobs）。每个 Flink 作业在提交到 Flink 集群时都会被分配一个jobID。当作业发生故障时，Flink 应用可以利用jobID 来恢复故障前作业的状态，从故障点处继续执行。具体的配置和步骤如下：apiVersion: policy.karmada.io/v1alpha1 kind:PropagationPolicy metadata: name:foo spec: #... failover: application: decisionConditions: tolerationSeconds:60 purgeMode:Immediately statePreservation: rules: -aliasLabelName:application.karmada.io/failover-jobid jsonPath:"{ .jobStatus.jobID }"迁移前，Karmada 控制器将按照用户配置的路径提取 job ID。迁移时，Karmada 控制器将提取的 job ID 以 label 的形式注入到 Flink 应用配置中，比如application.karmada.io/failover-jobid : <jobID>。运行在成员集群的 Kyverno 拦截 Flink 应用创建请求，并根据jobID  获取该 job 的 checkpoint 数据存储路径，比如  /<shared-path>/<job-namespace>/<jobId>/checkpoints/xxx，然后配置initialSavepointPath 指示从save point 启动。Flink 应用根据initialSavepointPath 下的 checkpoint 数据启动，从而继承迁移前保存的最终状态。该能力基于 FlinkDeployment 打造，但广泛适用于能够基于某个 save point 启动的有状态应用程序，这些应用均可参考上述流程实现故障迁移的状态中继。此功能需要启用 StatefulFailoverInjection 特性开关。StatefulFailoverInjection 目前处于 Alpha 阶段，默认情况下是关闭的。功能约束：应用必须限定在单个集群中运行；迁移清理策略（PurgeMode）限定为Immediately，即故障应用需立即删除然后再创建新应用，确保数据一致性。▶  单集群应用迁移能力增强在用户将业务从单集群迁移至多集群的过程中，如果资源已经被迁移到 Karmada 控制面，那么当控制面中的资源模板被删除时，成员集群中的资源也会随之删除。但在某些场景，用户希望能够保留成员集群中的资源。例如，作为管理员，在工作负载迁移过程中可能遇到意外情况（如云平台无法发布应用程序或 Pod 异常）， 需要回滚机制立刻恢复到迁移之前的状态，以便快速止损。在 v1.12 版本，社区在PropagationPolicy/ClusterPropagationPolicy API 中引入了PreserveResourcesOnDeletion 字段，用于定义当控制面中的资源模板被删除时成员集群上资源的保留行为，如果设置为true，则成员集群上的资源将被保留。结合此字段，一旦用户在迁移过程中发现异常，可以快速执行回滚操作并保留成员集群中原有的资源，整个迁移回滚过程更加安全可控。使用该字段请注意以下两点：该配置对所有成员集群统一生效，不会仅针对部分集群进行选择性控制。当 Policy 被删除时，资源模板及已分发的成员集群资源将保持不变，除非被显式删除。以 PropagationPolicy 为例，用户在删除 Karmada 控制面资源模板时，可以配置如下 PropagationPolicy 来保留成员集群的资源：apiVersion: policy.karmada.io/v1alpha1 kind:PropagationPolicy metadata: name:nginx-pp spec: conflictResolution:Overwrite preserveResourcesOnDeletion:true# 资源模板删除后，成员集群资源依然保留 placement: clusterAffinity: clusterNames: -member1 resourceSelectors: -apiVersion:apps/v1 kind:Deployment name:nginx -apiVersion:v1 kind:Service name:nginx-svc更多有关安全回滚迁移的资料请参考：迁移操作如何回滚[2] 。▶  Karmada Operator 高可用部署能力支持作为社区维护的安装工具，Karmada-operator 可以用来部署和管理多个 Karmada 实例。为了更好地支持高可用部署方案，karmada-operator 在本版本实施了一系列针对性的改进和优化措施，包括：引入了对自定义 CA 证书的支持；支持连接外部 etcd；可通过 Secret 指定外部 etcd 客户端的凭据；可为 Karmada 组件指定卷和卷挂载；对外暴露 APISever 服务，用于服务发现。这些增强使得 karmada-operator 能够跨多个管理集群部署一个高度可用的 Karmada 控制平面，这些集群可以跨越不同的数据中心，从而满足故障恢复的诉求。上图是通过 Karmada-operator 构建的生产级高可用架构，在这个架构中，Karmada-operator 跨不同地理位置的数据中心部署多个 Karmada 控制面，并将它们连接到同一个外部 etcd 集群。这种设置不仅确保了跨数据中心的数据一致性，还简化了数据管理和维护工作。此外，借助 Karmada-operator 提供的 APIServer 服务暴露能力，结合 Ingress 对外提供统一的服务访问。同时，利用可配置的CA证书机制，保障了 Karmada 实例与外部服务间通信的安全性。此架构显著增强了系统对单个数据中心故障的抵御能力，最大限度地减少了因数据中心故障导致的服务中断风险，保证了业务连续性和用户体验的稳定性，符合严格的灾难恢复标准。▶  OverridePolicy 支持局部修改结构化字段值OverridePolicy 允许用户针对特定集群自定义资源的覆盖策略，确保资源可以在不同环境中灵活适配和优化。Kubernetes 资源如 Secrets 和 ConfigMaps 常常会用到结构化的字段值，如 ConfigMaps 的.data 利用 YAML 格式的结构化数据承载配置信息。在实际应用中，存在只需要修改其部分字段的情况，而且，当原始的结构化字段值复杂且内容繁多时，使用全覆盖将会大大增大 OverridePolicy 的配置难度。为了解决这一问题，并提高 OverridePolicy 在此类场景中的易用性，Karmada 引入了FieldOverrider 特性。FieldOverrider 支持对 JSON 和 YAML 格式的结构化字段值进行局部修改，即只添加或替换或删除所需的字段。这种方式简化了配置过程，提高了效率，同时减少了出错的可能性，使得资源管理更加直观和便捷。通过FieldOverrider，用户可以对结构化字段值进行更精细化地处理，适应多变的应用环境需求。下面以 ConfigMap 为例，用户可通过FieldOverrider 部分覆盖 ConfigMap 的.data 字段来实现集群间的差异化配置。# example-configmap apiVersion: v1 kind: ConfigMap metadata: name: example-configmap data: config.yaml: | app: database: port: 5432 ip: 127.0.0.1 name: example zone: zone1# example-overridepolicy apiVersion:policy.karmada.io/v1alpha1 kind:OverridePolicy metadata: name:example spec: resourceSelectors: -apiVersion:v1 kind:ConfigMap name:example-configmap overrideRules: -overriders: fieldOverrider: -fieldPath:/data/config.yaml yaml: -subPath:/app/database/port operator:replace# 支持add、remove和replace操作 value:"3306" targetCluster: clusterNames: -member1经过以上配置，集群 member1 中的 ConfigMap 将更新为：# example-configmap in member1 apiVersion: v1 kind: ConfigMap metadata: name: myconfigmap data: config.yaml: | app: database: port: 3306 # 更新了port ip: 127.0.0.1 name: example zone: zone1更多FieldOverrider 的用法请参考：FieldOverrider 使用指南[3]▶ 致谢贡献者Karmada v1.12 版本包含了来自 33 位贡献者的 253 次代码提交，在此对各位贡献者表示由衷的感谢：贡献者列表：@a7i@ahorine@anujagrawal699@B1f030@chaosi-zju@CharlesQQ@chaunceyjiang@husnialhamdani@iawia002@ipsum-0320@jabellard@jklaw90@KhalilSantana@LavredisG@liangyuanpeng@LivingCcj@MAVRICK-1@mohamedawnallah@mszacillo@RainbowMango@SataQiu@seanlaii@sophiefeifeifeiya@tiansuo114@wangxf1987@whitewindmills@wulemao@XiShanYongYe-Chang@xovoxy@yanfeng1992@yelshall@zach593@zhzhuang-zju参考资料[1]Karmada v1.12版本:cid:link_5[2]迁移操作如何回滚:cid:link_0[3]FieldOverrider 使用指南:cid:link_4【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_6 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

作者：唐明&王彬丞   引言   随着边缘计算的发展，人工智能在边缘侧的应用日益增多，对计算资源的需求也越来越高，尤其 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/更多云原生技术动向关注容器魔方

 create_block_store.py  # coding: utf-8  import os from huaweicloudsdkcore.auth.credentials import BasicCredentials from huaweicloudsdkevs.v2.region.evs_region import EvsRegion from huaweicloudsdkcore.exceptions import exceptions from huaweicloudsdkevs.v2 import *  if __name__ == "__main__":     # 从环境变量中获取 AK 和 SK     ak = "79FWNEEYJ5FPOIMQVCHZ"     sk = "n6MRBpTarQvjBrRmKH1vE6W3o093BQ4PmKc5Ci7U"      if not ak or not sk:         print("请先设置环境变量 CLOUD_SDK_AK 和 CLOUD_SDK_SK")         exit(1)      credentials = BasicCredentials(ak, sk)      client = EvsClient.new_builder() \         .with_credentials(credentials) \         .with_region(EvsRegion.value_of("cn-north-4")) \         .build()      try:         # 列出所有卷         request = ListVolumesRequest()         response = client.list_volumes(request)          # 查找名为 chinaskills_volume 的卷         volume_id_to_delete = None         for volume in response.volumes:             if volume.name == "chinaskills_volume":                 volume_id_to_delete = volume.id                 print(f"找到卷: {volume.name}，ID: {volume.id}")                 break          # 如果找到对应的卷 ID，则删除该卷         if volume_id_to_delete:             delete_request = DeleteVolumeRequest(volume_id_to_delete)             client.delete_volume(delete_request)             print(f"卷 {volume_id_to_delete} 已删除")         else:             print("未找到名为 chinaskills_volume 的卷，无需删除")          request = CreateVolumeRequest()          listMetadataVolume = {             "__system__cmkid": "4f765277-a00e-4c3a-81f8-2cbaa0856e18",             "__system__encrypted]": "1"         }         volumebody = CreateVolumeOption(             availability_zone="cn-north-4a",             metadata=listMetadataVolume,             multiattach=True,             name="chinaskills_volume",             size=100,             volume_type="SSD"         )         request.body = CreateVolumeRequestBody(             volume=volumebody         )         response = client.create_volume(request)         print(response)     except exceptions.ClientRequestException as e:         print(f"HTTP状态码: {e.status_code}")         print(f"请求ID: {e.request_id}")         print(f"错误码: {e.error_code}")         print(f"错误信息: {e.error_msg}")   ---------------------------------------------------------------------------------------------------------------- create_keypair.py  # coding: utf-8  from huaweicloudsdkcore.auth.credentials import BasicCredentials from huaweicloudsdkkps.v3.region.kps_region import KpsRegion from huaweicloudsdkcore.exceptions import exceptions from huaweicloudsdkkps.v3 import *  credentials = BasicCredentials("79FWNEEYJ5FPOIMQVCHZ", "n6MRBpTarQvjBrRmKH1vE6W3o093BQ4PmKc5Ci7U") \  client = KpsClient.new_builder() \         .with_credentials(credentials) \         .with_region(KpsRegion.value_of("cn-north-4")) \         .build()  def create_key(name):     request = ListKeypairsRequest()     response = client.list_keypairs(request).to_json_object()     for i in response['keypairs']:         if i['keypair']['name']  == name:             request = DeleteKeypairRequest()             request.keypair_name = name             response = client.delete_keypair(request)      try:         request = CreateKeypairRequest()         encryptionKeyProtection = Encryption(             type="default"         )         keyProtectionKeypair = KeyProtection(             encryption=encryptionKeyProtection         )         keypairbody = CreateKeypairAction(             name=name,             key_protection=keyProtectionKeypair         )         request.body = CreateKeypairRequestBody(             keypair=keypairbody         )         response = client.create_keypair(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__":     create_key('chinaskills_keypair') ---------------------------------------------------------------------------------------------------------------- ecs_manager.py  import os import json import time import argparse from huaweicloudsdkcore.auth.credentials import BasicCredentials from huaweicloudsdkecs.v2.region.ecs_region import EcsRegion from huaweicloudsdkecs.v2 import *  ak = "79FWNEEYJ5FPOIMQVCHZ" sk = "n6MRBpTarQvjBrRmKH1vE6W3o093BQ4PmKc5Ci7U"  cloud_vpc_id = "b3833f32-f263-4094-b31a-d9ef1d4c5828" cloud_subnet_id = "8e2a2942-29d7-4e83-92a9-c3eb631e5bba"  credentials = BasicCredentials(ak, sk)  client = EcsClient.new_builder() \     .with_credentials(credentials) \     .with_region(EcsRegion.value_of("cn-north-4")) \     .build()  def create_ecs(name, image_id):     request = CreatePostPaidServersRequest()     rootVolumeServer = PostPaidServerRootVolume(volumetype="SSD")     listNicsServer = [PostPaidServerNic(subnet_id=cloud_subnet_id)]     serverbody = PostPaidServer(         flavor_ref="c7.large.2",         image_ref=image_id,         name=name,         nics=listNicsServer,         root_volume=rootVolumeServer,         vpcid=cloud_vpc_id     )     request.body = CreatePostPaidServersRequestBody(server=serverbody)     response = client.create_post_paid_servers(request)     print(response.to_dict())  def get(name, output_file=None):     max_retries = 5     wait_time = 5      for _ in range(max_retries):         request = ListServersDetailsRequest()         response = client.list_servers_details(request)         servers = response.to_dict().get('servers', [])          for server in servers:             if server['name'] == name:                 print(f"服务器名称: {server['name']}, 服务器ID: {server['id']}")                  server_dict = server.to_dict() if hasattr(server, 'to_dict') else dict(server)                  if output_file:                     try:                         with open(output_file, 'w') as f:                             json.dump(server_dict, f, indent=4, default=str)                         print(f"服务器信息已保存到 {output_file}")                     except Exception as e:                         print(f"保存文件时发生错误: {e}")                 return          print(f"未找到名称为 {name} 的服务器，等待 {wait_time} 秒后重试...")         time.sleep(wait_time)      print(f"未能找到名称为 {name} 的服务器，已达到最大重试次数。")  def getall(output_file=None):     request = ListServersDetailsRequest()     response = client.list_servers_details(request)     servers = response.to_dict().get('servers', [])      serializable_servers = []      for server in servers:         server_dict = server.to_dict() if hasattr(server, 'to_dict') else dict(server)         serializable_servers.append(server_dict)      if output_file:         try:             with open(output_file, 'w') as f:                 json.dump(serializable_servers, f, indent=4, default=str)             print(f"所有服务器信息已保存到 {output_file}")         except Exception as e:             print(f"保存文件时发生错误: {e}")     else:         print(serializable_servers)  def delete(name):     request = ListServersDetailsRequest()     response = client.list_servers_details(request)     servers = response.to_dict().get('servers', [])      for server in servers:         if server['name'] == name:             print(f"服务器名称: {server['name']}, 服务器ID: {server['id']}")             request = DeleteServersRequest()             listServersbody = [ServerId(id=server['id'])]             request.body = DeleteServersRequestBody(servers=listServersbody)             response = client.delete_servers(request)             print(response)             return      print(f"没有找到名称为 {name} 的服务器。")  if __name__ == "__main__":     parser = argparse.ArgumentParser(description="ECS 云主机管理")     subparsers = parser.add_subparsers(dest="command")      create_parser = subparsers.add_parser("create")     create_parser.add_argument("-i", "--input", required=True, help="云主机名称和镜像 ID，JSON 格式")      get_parser = subparsers.add_parser("get")     get_parser.add_argument("-n", "--name", required=True, help="指定要查询的云主机名称")     get_parser.add_argument("-o", "--output", help="输出文件名，格式为 JSON")      getall_parser = subparsers.add_parser("getall")     getall_parser.add_argument("-o", "--output", help="输出文件名，格式为 JSON")      delete_parser = subparsers.add_parser("delete")     delete_parser.add_argument("-n", "--name", required=True, help="指定要删除的云主机名称")      args = parser.parse_args()      if args.command == "create":         input_data = json.loads(args.input)         create_ecs(input_data['name'], input_data['imagename'])     elif args.command == "get":         get(args.name, args.output)     elif args.command == "getall":         getall(args.output)     elif args.command == "delete":         delete(args.name) ---------------------------------------------------------------------------------------------------------------------------------- Huawei_centos7.9_ID.txt  02a17486-1214-4e42-8da7-7d200cac585e ---------------------------------------------------------------------------------------------------------------------------------  main.py  #!/usr/bin/env python3 # -*- coding: utf-8 -*- # @author YWLBTWTK # @date 2023/9/18 from fastapi import FastAPI import uvicorn from huaweicloudsdkcore.auth.credentials import BasicCredentials from huaweicloudsdkvpc.v2.region.vpc_region import VpcRegion from huaweicloudsdkcore.exceptions import exceptions from huaweicloudsdkvpc.v2 import *  app = FastAPI() ak = "79FWNEEYJ5FPOIMQVCHZ" sk = "n6MRBpTarQvjBrRmKH1vE6W3o093BQ4PmKc5Ci7U" g_region = "cn-north-4"  def api_list_vpc(name):     credentials = BasicCredentials(ak, sk)     client = VpcClient.new_builder() \         .with_credentials(credentials) \         .with_region(VpcRegion.value_of(g_region)) \         .build()      try:         request = ListVpcsRequest()         response = list(map(lambda x: {'name': x['name'], 'id': x['id']}, client.list_vpcs(request).to_dict()['vpcs']))         for i in response:             if i['name'] == name:                 print(i['id'])                 return i['id']         return None     except Exception:         return None  @app.post('/cloud_vpc/create_vpc') def api_create_vpc(data: dict):     credentials = BasicCredentials(ak, sk)     client = VpcClient.new_builder() \         .with_credentials(credentials) \         .with_region(VpcRegion.value_of(g_region)) \         .build()     try:         request = CreateVpcRequest()         vpcbody = CreateVpcOption(             cidr=data['cidr'],             name=data['name']         )         request.body = CreateVpcRequestBody(             vpc=vpcbody         )         response = client.create_vpc(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)         return e     except Exception as e:         return e  @app.get('/cloud_vpc/vpc/{vpc_name}') def api_get_vpc(vpc_name: str):     credentials = BasicCredentials(ak, sk)     client = VpcClient.new_builder() \         .with_credentials(credentials) \         .with_region(VpcRegion.value_of(g_region)) \         .build()     try:         request = ShowVpcRequest()         request.vpc_id = api_list_vpc(vpc_name)         response = client.show_vpc(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)         return e     except Exception as e:         return e  @app.get('/cloud_vpc/vpc') def api_get_list_vpc():     credentials = BasicCredentials(ak, sk)     client = VpcClient.new_builder() \         .with_credentials(credentials) \         .with_region(VpcRegion.value_of(g_region)) \         .build()     try:         request = ListVpcsRequest()         response = client.list_vpcs(request).to_dict()         print(response)         return response     except Exception as e:         return e  @app.put('/cloud_vpc/update_vpc') def api_update_vpc(data: dict):     credentials = BasicCredentials(ak, sk)     client = VpcClient.new_builder() \         .with_credentials(credentials) \         .with_region(VpcRegion.value_of(g_region)) \         .build()     try:         request = UpdateVpcRequest()         request.vpc_id = api_list_vpc(data['old_name'])         vpcbody = UpdateVpcOption(             name=data['new_name']         )         request.body = UpdateVpcRequestBody(             vpc=vpcbody         )         response = client.update_vpc(request)         print(response)         return response.to_dict()     except Exception as e:         return e  @app.delete('/cloud_vpc/delete_vpc') def api_delete_vpc(data: dict):     credentials = BasicCredentials(ak, sk)     client = VpcClient.new_builder() \         .with_credentials(credentials) \         .with_region(VpcRegion.value_of(g_region)) \         .build()      try:         request = DeleteVpcRequest()         request.vpc_id = api_list_vpc(data['vpc_name'])         response = client.delete_vpc(request)         print(response)         return response.to_dict()     except Exception as e:         return e  if __name__ == '__main__':     uvicorn.run(app='main:app', host='0.0.0.0', port=7045, reload=True) ------------------------------------------------------------------------------------------------------------------------------------------  python3.txt  #!/bin/bash rm -rf /etc/yum.repos.d/* cat << EOF > /etc/yum.repos.d/centos.repo [os] name=Qcloud centos os - \$basearch baseurl=http://mirrors.cloud.tencent.com/centos/\$releasever/os/\$basearch/ enabled=1 gpgcheck=1 gpgkey=http://mirrors.cloud.tencent.com/centos/RPM-GPG-KEY-CentOS-7  [updates] name=Qcloud centos updates - \$basearch baseurl=http://mirrors.cloud.tencent.com/centos/\$releasever/updates/\$basearch/ enabled=1 gpgcheck=1 gpgkey=http://mirrors.cloud.tencent.com/centos/RPM-GPG-KEY-CentOS-7  [extras] name=Qcloud centos extras - \$basearch baseurl=http://mirrors.cloud.tencent.com/centos/\$releasever/extras/\$basearch/ enabled=1 gpgcheck=1 gpgkey=http://mirrors.cloud.tencent.com/centos/RPM-GPG-KEY-CentOS-7  [epel] name=EPEL for redhat/centos \$releasever - \$basearch baseurl=http://mirrors.cloud.tencent.com/epel/\$releasever/\$basearch/ failovermethod=priority enabled=1 gpgcheck=1 gpgkey=http://mirrors.cloud.tencent.com/epel/RPM-GPG-KEY-EPEL-7 EOF yum install python3 -y pip3 install -i https://mirrors.cloud.tencent.com/pypi/simple --upgrade pip pip3 config set global.index-url https://mirrors.cloud.tencent.com/pypi/simple pip3  install huaweicloudsdkcore huaweicloudsdkecs huaweicloudsdkvpc  huaweicloudsdkswr  huaweicloudsdkcce  huaweicloudsdkrds huaweicloudsdkims uvicorn fastapi ----------------------------------------------------------------------------------------------------------------------------------  date.yaml  apiVersion: batch/v1 kind: CronJob metadata:   name: date   namespace: default spec:   schedule: "* * * * *"   jobTemplate:     spec:       template:         spec:           containers:           - name: hello             image: busybox             command:               - "sh"               - "-c"               - "date"           restartPolicy: OnFailure ----------------------------------------------------------------------------------------------------------------------  nginx.yaml  apiVersion: v1 kind: Pod metadata:   name: lifecycle-demo   namespace: default spec:   containers:   - name: nginx-container     image: nginx:latest     lifecycle:       postStart:         exec:           command: ["sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]       preStop:         exec:           command: ["sh", "-c", "nginx -s quit; while killall -0 nginx; do sleep 1; done"]     ports:     - containerPort: 80 ---------------------------------------------------------------------------------------------------------------------  kubeedge-master.sh  #!/bin/bash  master_ip="139.9.74.141"  wget https://216-216.obs.cn-south-1.myhuaweicloud.com/kubernetes_kubeedge.tar.gz  echo -e "139.9.74.141 master\n192.168.216.79 edge-node1\n192.168.216.80 edge-node2" >> /etc/hosts  tar -zxvf kubernetes_kubeedge.tar.gz -C /opt/  kubectl patch daemonset kube-proxy -n kube-system -p '{"spec": {"template": {"spec": {"affinity": {"nodeAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": {"nodeSelectorTerms": [{"matchExpressions": [{"key": "node-role.kubernetes.io/edge", "operator": "DoesNotExist"}]}]}}}}}}}' kubectl patch daemonset kube-flannel-ds -n kube-system -p '{"spec": {"template": {"spec": {"affinity": {"nodeAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": {"nodeSelectorTerms": [{"matchExpressions": [{"key": "node-role.kubernetes.io/edge", "operator": "DoesNotExist"}]}]}}}}}}}'  mv /opt/kubeedge/keadm /usr/bin/keadm  cd /opt/k8simage/ bash load.sh  cd /opt/kubeedge docker load  -i cloudcore.tar docker load -i installation.tar docker load -i mosquitto.tar docker load -i pause.tar  tar -zxvf /opt/kubeedge/kubeedge-1.11.1.tar.gz # tar -xzvf /opt/kubeedge/kubeedge-v1.11.1-linux-amd64.tar.gz mkdir /etc/kubeedge/ cp -rvf /opt/kubeedge/kubeedge-v1.11.1-linux-amd64.tar.gz  /etc/kubeedge/ cp -rvf /opt/kubeedge/kubeedge-1.11.1/build/crds/   /etc/kubeedge/ cp -rvf /opt/kubeedge/kubeedge-1.11.1/vendor/k8s.io/kubernetes/pkg/kubelet/checkpointmanager/checksum /etc/kubeedge/ cp /opt/kubeedge/kubeedge-1.11.1/build/tools/* /etc/kubeedge/  cd /etc/kubeedge/ pwd sleep 5 keadm deprecated init --advertise-address=$master_ip --kubeedge-version=1.11.1 # ss -ntpl netstat  -ntpl |grep cloudcore sleep 5  sed -i '/cloudStream:/ {N; s/enable: false/enable: true/}' /etc/kubeedge/config/cloudcore.yaml sed -i '/router:/,+2 s/enable: false/enable: true/' /etc/kubeedge/config/cloudcore.yaml kill -9 $(ps aux | grep cloudcore | awk 'NR==1{print $2}') cp /etc/kubeedge/cloudcore.service /etc/systemd/system/cloudcore.service chmod +x /etc/systemd/system/cloudcore.service systemctl daemon-reload systemctl start cloudcore systemctl enable cloudcore.service sleep 3  export CLOUDCOREIPS=$master_ip cd /etc/kubeedge/ ./certgen.sh stream  iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X  sleep 5 keadm gettoken ------------------------------------------------------------------------------------------------------------------------------------------- kubeedge-node.sh  #!/bin/bash  token="" master_ip="139.9.74.141" centos=http://192.168.216.10:81/centos7.9/  echo -e "139.9.74.141 master\n192.168.216.79 edge-node1\n192.168.216.80 edge-node2" >> /etc/hosts  tar -zxvf kubernetes_kubeedge.tar.gz -C /opt/  rm -rf /etc/yum.repos.d/* cat >> /etc/yum.repos.d/local.repo << EOF [local] name=local baseurl=file:///opt/yum enabled=1 gpgcheck=0 [centos] name=local baseurl=$centos enabled=1 gpgcheck=0 EOF  yum -y install docker-ce systemctl restart docker docker --version  mv /opt/kubeedge/keadm /usr/bin/keadm cd /opt/k8simage/ bash load.sh  cd /opt/kubeedge docker load  -i cloudcore.tar docker load -i installation.tar docker load -i mosquitto.tar docker load -i pause.tar  keadm join --cloudcore-ipport=$master_ip:10000 --token=$token  sed -i '/edgeStream:/ {N; s/enable: false/enable: true/}' /etc/kubeedge/config/edgecore.yaml sed -i '/serviceBus:/ {N; s/enable: false/enable: true/}' /etc/kubeedge/config/edgecore.yaml  systemctl restart edgecore systemctl status edgecore ------------------------------------------------------------------------------------------------------------------------------------- node.sh  #!/bin/bash HOST_IP="192.168.216.15" SQL1="192.168.216.16"  rm -rf /etc/yum.repos.d/* cat << EOF > /etc/yum.repos.d/centos.repo [os] name=Qcloud centos os - \$basearch baseurl=http://mirrors.cloud.tencent.com/centos/\$releasever/os/\$basearch/ enabled=1 gpgcheck=1 gpgkey=http://mirrors.cloud.tencent.com/centos/RPM-GPG-KEY-CentOS-7  [updates] name=Qcloud centos updates - \$basearch baseurl=http://mirrors.cloud.tencent.com/centos/\$releasever/updates/\$basearch/ enabled=1 gpgcheck=1 gpgkey=http://mirrors.cloud.tencent.com/centos/RPM-GPG-KEY-CentOS-7  [extras] name=Qcloud centos extras - \$basearch baseurl=http://mirrors.cloud.tencent.com/centos/\$releasever/extras/\$basearch/ enabled=1 gpgcheck=1 gpgkey=http://mirrors.cloud.tencent.com/centos/RPM-GPG-KEY-CentOS-7  [epel] name=EPEL for redhat/centos \$releasever - \$basearch baseurl=http://mirrors.cloud.tencent.com/epel/\$releasever/\$basearch/ failovermethod=priority enabled=1 gpgcheck=1 gpgkey=http://mirrors.cloud.tencent.com/epel/RPM-GPG-KEY-EPEL-7 EOF tar -zxvf node-v12.16.1-linux-x64.tar.gz echo "export PATH=/usr/local/node/bin:$PATH"  >> /etc/profile mv node-v12.16.1-linux-x64 /usr/local/node source /etc/profile yum install -y gcc-c++ make yum install -y GraphicsMagick  # 配置 npm source /etc/profile npm config set registry http://registry.npm.taobao.org/ npm config set electron_mirror http://npm.taobao.org/mirrors/electron/  # 解压 Rocket.Chat 安装包 tar -zxvf rocket.chat-3.2.2.tgz  # 进入服务器程序目录并安装依赖 cd bundle/programs/server npm install  # 移动安装包到 /opt/Rocket.Chat 目录 mv /root/bundle /opt/Rocket.Chat  # 创建 Rocketchat 用户并设置权限 useradd -M rocketchat && usermod -L rocketchat chown -R rocketchat:rocketchat /opt/Rocket.Chat  # 创建 systemd 服务配置文件 cat >> /lib/systemd/system/rocketchat.service << EOF [Unit] Description=The Rocket.Chat server After=network.target remote-fs.target nss-lookup.target nginx.service mongod.service [Service] ExecStart=/usr/local/node/bin/node  /opt/Rocket.Chat/main.js StandardOutput=syslog StandardError=syslog SyslogIdentifier=rocketchat User=rocketchat Environment=MONGO_URL=mongodb://$SQL1:27017/rocketchat?replicaSet=cloud MONGO_OPLOG_URL=mongodb://$SQL1:27017/local?replicaSet=cloud ROOT_URL=http://$HOST_IP:3000/ PORT=3000 [Install] WantedBy=multi-user.target EOF  # 启动 Rocket.Chat 服务并检查状态 systemctl restart rocketchat sleep 15 systemctl status rocketchat  ----------------------------------------------------------------------------------------------------------------------------------------------------------- sql-1.1.sh  #!/bin/bash rm -rf /etc/yum.repos.d/* cat << EOF > /etc/yum.repos.d/centos.repo [os] name=Qcloud centos os - \$basearch baseurl=http://mirrors.cloud.tencent.com/centos/\$releasever/os/\$basearch/ enabled=1 gpgcheck=1 gpgkey=http://mirrors.cloud.tencent.com/centos/RPM-GPG-KEY-CentOS-7  [updates] name=Qcloud centos updates - \$basearch baseurl=http://mirrors.cloud.tencent.com/centos/\$releasever/updates/\$basearch/ enabled=1 gpgcheck=1 gpgkey=http://mirrors.cloud.tencent.com/centos/RPM-GPG-KEY-CentOS-7  [extras] name=Qcloud centos extras - \$basearch baseurl=http://mirrors.cloud.tencent.com/centos/\$releasever/extras/\$basearch/ enabled=1 gpgcheck=1 gpgkey=http://mirrors.cloud.tencent.com/centos/RPM-GPG-KEY-CentOS-7  [epel] name=EPEL for redhat/centos \$releasever - \$basearch baseurl=http://mirrors.cloud.tencent.com/epel/\$releasever/\$basearch/ failovermethod=priority enabled=1 gpgcheck=1 gpgkey=http://mirrors.cloud.tencent.com/epel/RPM-GPG-KEY-EPEL-7 EOF  yum -y install vsftpd echo "anon_root=/opt" >> /etc/vsftpd/vsftpd.conf systemctl restart vsftpd  tar -xvf yum.tar.gz -C /opt  cat >> /etc/yum.repos.d/ftp.repo  << EOF [local] name=local baseurl=file:///opt/yum enabled=1 gpgcheck=0 EOF yum install mongodb-org -y rm -rf /etc/mongod.conf cat >> /etc/mongod.conf  << EOF # mongod.conf  # for documentation of all options, see: #   http://docs.mongodb.org/manual/reference/configuration-options/  # where to write logging data. systemLog:   destination: file   logAppend: true   path: /var/log/mongodb/mongod.log  # Where and how to store data. storage:   dbPath: /var/lib/mongo   journal:     enabled: true  # how the process runs processManagement:   fork: true  # fork and run in background   pidFilePath: /var/run/mongodb/mongod.pid  # location of pidfile   timeZoneInfo: /usr/share/zoneinfo  # network interfaces net:   port: 27017   bindIp: 0.0.0.0  # Enter 0.0.0.0,:: to bind to all IPv4 and IPv6 addresses or, alternatively, use the net.bindIpAll setting.  #security:  #operationProfiling:  replication:   replSetName: cloud  #sharding:  ## Enterprise-Only Options  #auditLog:  #snmp: EOF systemctl restart mongod.service systemctl status mongod.service ------------------------------------------------------------------------------------------------------------------------------------ sql-1.2.sh  #!/bin/bash SQL1_IP="192.168.216.16" SQL2_IP="192.168.216.17" SQL3_IP="192.168.216.18"  mongo --host "$SQL1_IP" --port 27017 --eval "rs.initiate({   _id: 'cloud',   members: [     { _id: 0, host: '$SQL1_IP' },     { _id: 1, host: '$SQL2_IP' },     { _id: 2, host: '$SQL3_IP' }   ] });" ------------------------------------------------------------------------------------------------------------------------------------ sql-2.sh  #!/bin/bash SQL1_ip="192.168.216.16"  rm -rf /etc/yum.repos.d/* cat >> /etc/yum.repos.d/ftp.repo  << EOF [local] name=local baseurl=ftp://$SQL1_ip/yum enabled=1 gpgcheck=0 EOF yum install mongodb-org -y rm -rf /etc/mongod.conf cat >> /etc/mongod.conf  << EOF # mongod.conf  # for documentation of all options, see: #   http://docs.mongodb.org/manual/reference/configuration-options/  # where to write logging data. systemLog:   destination: file   logAppend: true   path: /var/log/mongodb/mongod.log  # Where and how to store data. storage:   dbPath: /var/lib/mongo   journal:     enabled: true  # how the process runs processManagement:   fork: true  # fork and run in background   pidFilePath: /var/run/mongodb/mongod.pid  # location of pidfile   timeZoneInfo: /usr/share/zoneinfo  # network interfaces net:   port: 27017   bindIp: 0.0.0.0  # Enter 0.0.0.0,:: to bind to all IPv4 and IPv6 addresses or, alternatively, use the net.bindIpAll setting.  #security:  #operationProfiling:  replication:   replSetName: cloud  #sharding:  ## Enterprise-Only Options  #auditLog:  #snmp: EOF systemctl restart mongod.service systemctl status mongod.service ---------------------------------------------------------------------------------------------------------------------------------- delete-test.txt  #!/bin/bash  # 删除 WordPress 实例 helm uninstall wordpress  # 删除 PV 资源 kubectl delete pvc data-wordpress-mariadb-0 kubectl delete -f wordpress-pv.yaml kubectl delete -f mariadb-pv.yaml  # 删除 ChartMuseum 的 Service 和 Deployment kubectl delete -f chartmuseum-service.yaml kubectl delete -f chartmuseum-deployment.yaml  rm -rf /mnt/data/wordpress rm -rf /mnt/data/mariadb  # 删除命名空间 kubectl delete namespace chartmuseum rm -rf chartmuseum-deployment.yaml chartmuseum-service.yaml linux-amd64 mariadb-pv.yaml wordpress wordpress-pv.yaml ----------------------------------------------------------------------------------------------------------------------------------------- wordpress.sh  #!/bin/bash  # 安装 Helm tar -zxvf helm-v3.3.0-linux-amd64.tar.gz mv linux-amd64/helm /usr/bin  # 创建 ChartMuseum 命名空间 kubectl create namespace chartmuseum  # 部署 ChartMuseum 的 YAML 文件 cat <<EOF > chartmuseum-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata:   name: chartmuseum   namespace: chartmuseum spec:   replicas: 1   selector:     matchLabels:       app: chartmuseum   template:     metadata:       labels:         app: chartmuseum     spec:       containers:         - name: chartmuseum           image: registry.cn-hangzhou.aliyuncs.com/starsleap/chartmuseum:latest           ports:             - containerPort: 8080           volumeMounts:             - name: chart-storage               mountPath: /charts           env:             - name: STORAGE               value: local             - name: STORAGE_LOCAL_ROOTDIR               value: /charts       volumes:         - name: chart-storage           hostPath:             path: /data/charts             type: DirectoryOrCreate EOF  cat <<EOF > chartmuseum-service.yaml apiVersion: v1 kind: Service metadata:   name: chartmuseum   namespace: chartmuseum spec:   type: ClusterIP   selector:     app: chartmuseum   ports:     - protocol: TCP       port: 8080       targetPort: 8080 EOF  # 应用 ChartMuseum 的配置 kubectl apply -f chartmuseum-deployment.yaml kubectl apply -f chartmuseum-service.yaml  # 解压 WordPress chart tar -zxvf wordpress-13.0.23.tgz  # 修改 values.yaml，将命名空间改为 chartmuseum，并更改 service 类型 sed -i 's/type: LoadBalancer/type: NodePort/' wordpress/values.yaml  # 创建 WordPress 和 MariaDB 的 PV 目录及设置权限 mkdir -p /mnt/data/wordpress chmod 777 /mnt/data/wordpress mkdir -p /mnt/data/mariadb chmod 777 /mnt/data/mariadb  # 创建 WordPress 和 MariaDB 的 PV YAML 文件 cat <<EOF > wordpress-pv.yaml apiVersion: v1 kind: PersistentVolume metadata:   name: wordpress-pv spec:   capacity:     storage: 10Gi   accessModes:     - ReadWriteOnce   persistentVolumeReclaimPolicy: Retain   storageClassName: ""   hostPath:     path: "/mnt/data/wordpress" EOF  cat <<EOF > mariadb-pv.yaml apiVersion: v1 kind: PersistentVolume metadata:   name: mariadb-pv spec:   capacity:     storage: 8Gi   accessModes:     - ReadWriteOnce   persistentVolumeReclaimPolicy: Retain   storageClassName: ""   hostPath:     path: "/mnt/data/mariadb" EOF  # 应用 PV 的配置 kubectl apply -f wordpress-pv.yaml kubectl apply -f mariadb-pv.yaml  # 安装 WordPress 到 chartmuseum 命名空间 helm install wordpress ./wordpress  # 获取 WordPress 服务的 NodePort 和 IP export NODE_PORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports[0].nodePort}" services wordpress) export NODE_IP=$(kubectl get nodes --namespace default -o jsonpath="{.items[0].status.addresses[0].address}") echo "WordPress URL: http://$NODE_IP:$NODE_PORT/" sleep 55 kubectl port-forward --namespace default service/wordpress $(kubectl get --namespace default -o jsonpath="{.spec.ports[0].nodePort}" services wordpress):80 & curl -L 127.0.0.1:$(kubectl get --namespace default -o jsonpath="{.spec.ports[0].nodePort}" services wordpress)/wp-admin ---------------------------------------------------------------------------------------------------------------------------------------------------------------- 1.txt  helm install mariadb-test mariadb-7.3.14.tgz \   --set mariadb.rootPassword="chinaskill" \   --set service.type=ClusterIP \   --set replication.enabled=false --------------------------------------------------------------------------------------------------------------------------------------------------------------------- 

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

云服务器的性能直接影响业务系统的运行效率和用户体验。请问，如何评估和优化云服务器的性能以满足业务需求？

容器技术为云计算带来了轻量级、可移植和高效的应用部署方式。请问，容器技术在云计算中有哪些应用场景？如何优化容器性能以提高系统效率？