北京时间2024年5月16日，Kmesh 正式进入 CNCF 云原生全景图，位于 Service Mesh 类别下。CNCF Landscape 在云原生实践过程中的每个环节帮助用户了解有哪些具体的软件和产品选择，Kmesh 进入 CNCF Landscape，成为了 CNCF构建云原生服务网格最佳实践中的一环。Kmesh：业界首个内核级Sidecarless流量治理引擎▍eBPF和Sidecarless是服务网格的未来近年来服务网格逐步流行，但sidecar架构在资源开销、升级部署、时延等方面仍存在挑战，如何消减代理开销，构建sidecarless的服务网格已成为业界共识。Kmesh从立项之初，就瞄准网格痛点问题，创新性的提出业内首个内核级sidecarless流量治理引擎，通过eBPF + 可编程内核技术将L4~L7治理下沉OS，治理过程无需经过代理组件，实现服务网格内服务通信路径多跳变一跳，彻底消除代理开销，真正实现网格治理sidecarless化。Kmesh架构图▍Kmesh优势高性能内核中原生支持 L4~L7 流量治理功能，网格内微服务转发时延降低60%，微服务启动性能提升40%；低开销微服务中无需部署sidecar，服务网格数据面开销降低70%；高可用内核流量治理不会截断连接，组件升级、重启完全不影响业务已有连接；零信任网络支持基于内核mTLS构建零信任网络；安全隔离基于eBPF的虚机安全，且具备cgroup级治理隔离；灵活治理模式除了全内核治理形态，Kmesh还支持四七层治理分离架构，内核eBPF和waypoint组件分别处理L4和L7流量，允许用户逐步采用Kmesh，从而实现从无网格->安全L4治理->L7治理的平稳过渡；平滑兼容与Istio无缝集成，支持xDS协议标准。目前同时支持Istio API和Gateway API，可以与现有sidecar协同工作。为什么选择KmeshKmesh首先是一种Sidecarless的网格架构模型，目前Sidecarless模式广受欢迎。无论是Istio社区还是Cilium社区都在在采用这种架构模型，另外广大用户非常认可Sidecarless。与Sidecar相比，Sidecarless没有资源占用的开销，同时解耦应用和代理的生命周期，并且打破一一绑定的关系，部署、维护更加简单。Kmesh创新性的采用eBPF技术在内核态进行流量治理，使得流量的治理随流进行。好处是不会截断业务的连接，大大减少了流量路径上的连接数，进而降低应用访问的时延。在用户态进行流量治理的一个比较大的弊端是组件的升级会导致业务的流量受损，Kmesh通过可编程内核技术，完好的避开了这一点。目前Kmesh这方面具有业界压倒性的优势，我们充分看到了eBPF的无限可能，未来基于eBPF可以进行更多的网络创新。Kmesh还提供了另一种高级的模式，通过四七层分离，提供丰富的L7治理功能。四七层分离能够提供更加细粒度的物理隔离，不同租户，不同命名空间或者不同的服务均可以划分，独享七层代理waypoint。waypoint还可以根据业务流量，进行动态扩缩容，方便提供全托管。我们看到waypoint不同于传统的中心式网关，不存在单点故障。由此，我们坚定的认为未来Sidecarless模式的理想架构，一定是eBPF技术和waypoint组合，既要减少资源消耗，又要降低时延。在节点上通过eBPF进行L4和简单的L7流量治理，至于高级的、复杂的七层协议则转发到waypoint治理。加入社区贡献Kmesh由华为发起， openEuler社区孵化，当前作为独立项目在GitHub托管，为用户提供极致性能的流量治理技术方案。华为是中国最早参与服务网格的厂商，早在2018年华为就开始投入Istio社区，常年在Istio社区贡献保持亚洲第一，并且自首届以来持续拥有社区Steering Committee席位。华为在服务网格领域的探索历程我们希望借助在Istio社区长期的积累，始终以开放中立的态度发展Kmesh，打造Sidecarless服务网格业界标杆方案，服务千行百业，促进服务网格健康有序的发展。Kmesh当前正处于高速发展阶段，我们诚邀广大有志之士加入！Kmesh社区地址：cid:link_3CNCF云原生全景图Cloud Native Computing Foundation，云原生计算基金会（以下简称CNCF）是一个开源软件基金会，它致力于云原生（Cloud Native）技术的普及和可持续发展。云原生技术通过一系列的软件、规范和标准帮助企业和组织，在现代的动态环境（如公共云、私有云和混合云）中构建和运行敏捷的、可扩展的应用程序。CNCF 发布了云原生全景图（CNCF Landscape），旨在帮助企业和开发人员快速了解云原生体系的全貌，帮助用户选择云原生实践中的恰当的软件和工具，因此受到广大开发者和使用者的关注和重视。参考链接[1]CNCF Landscape: cid:link_4[2]Ambient Mesh介绍: cid:link_0[3]华为云ASM: cid:link_1[4]Kmesh快速上手: cid:link_2添加小助手k8s2222回复Kmesh进入技术交流群

 企业软件开发困局随着信息化的进程不断加速，带来的各种业务应用、平台应用等软件资产的复杂度也快速上升。随之而来的信息化基础设施能力与软件工程全生命周期的管理也会变得越来越复杂，数字化转型、云原生、持续交付的口号随之升起。千行百业都在响应数字化转型的号召以提升业务效率、企业竞争力或是市场竞争力。但是企业在转型的过程中却举步维艰。往往原因有以下几点：流程固化，牵一发而动全身：原有的流程已经制定多年，相关人员也已经习惯这套流程。突然的规则转变以及带来的相关风险无人愿意主动承担。部门墙明显，无法快速协同：在金融等行业中，每个部门的成员往往都是统一职责的。如业务部门，只负责市场运营、项目需求管理等；研发部门，只负责开发以及测试；运维部门，只负责平台的运维、基础设施的维护等。一个业务软件的版本迭代，需要从多个部门层层流转，但部门与部门之间的沟通又不彻底，出现问题也容易互相牵扯，最终导致软件需求交付效率的大大下降。严谨的网络环境管理却又松散的制品管理：网络部门严格管理着各个环境之间的网络访问逻辑，一般情况下，开发人员只能访问开发环境；而且开发、测试、准生产以及生产环境之间网络都是不互通的。在没有强有力的政策干预下，可能会出现各个环境都独立一套代码、制品仓库，更糟糕的是，可能不同的软件产品线都独立管理各自的代码、制品仓库。因此在阶段流转时，需要通过传统的拷贝方式去做流转传递，带来了额外的管理成本，也更容易引入人为风险。过多的编外人员带来的各种散乱工具链：在软件研发部门可能存在多方外包人员，而每一方外包人员都有各自熟悉的软件开发工具，代码仓库有些使用Gitlab，有些使用Gitea；制品仓库有些使用nexus，有些使用jforg；甚至构建工具都不能统一，有用Jenkins的，也有本地构建的。这也带来了管理上的巨大麻烦。显而易见的困局，企业在数字化转型过程中面临流程固化、部门墙明显、制品管理松散和工具链混乱等问题，导致软件需求交付效率下降。需要打破原有流程和部门墙，建立统一的管理体系，加强制品管理和工具链整合，以提高软件需求交付效率。破局之法：DevOps面对以上重重现状和困难，我们迎来了曙光——DevOps。DevOps最初诞生于互联网企业。DevOps作为一种文化、哲学和实践的集合，自从诞生以来，就一直在不断地进化和扩展。它的定义以及理念大家都耳熟能详：打破部门墙、紧密合作、自动化、小步快跑、敏捷迭代等等。它是一种文化宣言，提及了方法论，每个企业或者行业都能够结合自身实际情况去操作实施。核心理念：变更的快速响应：DevOps支持需求的快速更改和新功能的快速部署。通过自动化构建和部署流程，开发团队可以快速地将代码从开发环境推送到生产环境。持续反馈：通过持续集成和持续部署，可以确保在开发周期的任何阶段捕获问题，以及在生产过程中立即收集用户反馈，然后快速将这些反馈整合到产品迭代中。跨功能协作：DevOps鼓励开发团队、QA团队和运维团队从需求收集的初期就开始紧密合作，以确保全方位理解和满足用户需求，并从整个软件交付流程中消除障碍。原则优化：DevOps的实践着重于自动化和精益原则，包括尽早消除浪费，确保需求的清晰性和简洁性，以及提供最大的价值。从核心理念就能够看出，DevOps文化实践需要有统一的软件工程工具链，所有相关人员都能够在DevOps平台上执行各自的工作，实现部门之间通力协作和重复流程的全面自动化。上图展示了DevOps的相关角色以及整体工作流程。一个较为完整的DevOps全流程工具链便呼之欲出：从基础设施的管理、项目管理，再到代码管理和持续交付，最后是持续运维。除却文化理念，DevOps的核心是自动化流水线工具，实现了自动化持续交付，而持续交付的核心是持续集成（CI）和持续部署（CD）。CI/CD共同构成了现代软件开发的核心实践，旨在促进软件的快速迭代和高质量交付。其中，持续集成主要关注开发阶段的频繁合并和测试，而持续部署则扩展了这一过程，涵盖了代码从集成到被部署到生产环境的整个流程。两者都是自动化的关键实践，有助于实现DevOps的目标。遵循理论引导并结合实际情况，我们归纳了针对金融等行业的破局三板斧。DevOps专业团队指导，打破固有流程在金融等行业并不缺乏优化现有流程的勇气，只是没有明确的目标以及专业指导。当DevOps的呼声以及发展越来越强大时，国内涌现出了很多专业的DevOps专家咨询团队，他们能够结合企业的实际现状给出最优解，在组织架构不调整的情况下保障以尽可能小的变更达到最大的效果，消除企业顾虑。统一的DevOps工具链平台，打破部门墙，规范研发流程我们发现绝大多数企业都无法做到为每一个项目划分全功能团队（从市场、需求到研发、测试最后到运维），往往都是独立的市场部、研发部和运维部。这天然的形成了沟通与阶段流转之间的部门墙，由于更改现状牵扯太大，我们便通过应用DevOps的理念，建立统一的DevOps工具链平台，对当前项目的全生命周期进行管理。针对每一个原始需求，从需求记录、分析、分配到后续的开发、测试、验证及最终上线，都能被相关人员看到。阶段的流转也能够在相关平台上直接操作和通知，杜绝冗长低效的跨部门流程。我们提倡相关人员使用DevOps平台的同时，梳理最佳实践，进行定期培训，潜移默化的让研发流程变得统一和规范。在严谨的网络环境内搭建统一的核心资产库核心资产库的统一有必要性，各个项目组成员，即使在不同的应用环境下，也不能单独建立。如代码仓库，不能在开发环境和测试环境各有一套。我们需要统一的核心资产库去践行DevOps的理念。该库需要打通从开发到生产环境的网络连接，并通过严格的权限控制，来实现安全合规。行业困局的解决方案为了满足理论支撑，我们基于华为云UCS作为容器平台底座，结合软通动力应用交付平台来实现行业云原生数字化转型的最佳解决方案。华为云UCS（Ubiquitous Cloud Native Service）是业界首个分布式云原生产品，为企业构建云原生业务部署、管理、应用生态的全域一致性体验 ，实现客户在使用云原生应用时，感受不到地域、跨云、流量的限制，让云原生的能力进入企业的每一个业务场景，加速千行百业拥抱云原生。而软通动力应用交付平台是一款持续交付产品，帮助企业快速建立稳定软件发布的内部开发者平台与 DevOps 文化，为开发者提供云原生应用运行环境，开发者通过平台的自助服务能力，进行应用的构建、部署、验证、运维等生命周期管理操作，降低应用开发者使用云原生技术的门槛，提升应用的部署和运行质量。平台支持UCS云原生服务中心快速安装，用户只需要通过页面表单的填写即可快速部署平台，实现开箱即用。客户通过UCS对多方集群执行统一纳管，从而达到对多个集群的统一治理，实现配置管理、容器迁移、策略中心、流量治理和容器智能分析。这在网络环境严苛的金融等行业中是非常便利的。云原生服务中心精选了各种成熟可靠的开源工具，为客户提供了统一便捷的安装体验，其中的多种工具能够和应用交付平台实现集成联动效果，如SonarQube和ArgoCD。他们支持配置对接到应用交付平台的持续集成流水线或安全测试编排中，实现多个工具平台的串联，打破数据孤岛。整体解决方案中，实现DevOps的核心便是华为云UCS提供的容器底座以及应用交付平台提供的集成和自动化能力，两者相辅相成。原本的应用交付平台得到升华。通过UCS的特性，我们可以实现多集群的统一联邦管理，让快速搭建双活、主备等高可用应用部署架构变得轻而易举。这种架构极大地提升了运维能力，使构建发布过程实现全面自动化，从而提高交付质量、缩短交付周期、保持技术路线一致性以及规范资源使用。值得一提的是，UCS云原生服务中心的引入使得企业能够快速安装和使用诸如ArgoCD、SornaQube等热门开源工具平台。这不仅丰富了企业的技术选择，还增强了企业的灵活性，使企业在快速变化的市场环境中始终保持竞争力。将UCS与软通动力应用交付平台相结合，企业将获得一套更高效、更可靠的运维解决方案。这套方案可以全面提高企业的运维能力，降低人工干预成本，提高交付质量，并确保技术路线的一致性。在此基础上，通过UCS云原生服务中心的引入，企业还能够快速接入各类热门开源工具平台，进一步提升企业的灵活性。这套解决方案将助力企业在激烈的市场竞争中脱颖而出，实现业务的持续发展。方案落地实践与价值某资产管理公司成立10年期间累积了不少软件资产，过于陈旧的研发体系以及日益膨胀的原始需求，使得他们迫切的想要进行云原生改造，实践DevOps来得到交付效率上的提升。在入场调研的过程中，我们发现其所面临的困境和金融业企业困境如出一辙：各个环境的割裂、没有统一的代码仓库、阶段流转靠U盘拷贝、散乱的依赖管理、缺失自动化构建能力以及没有统一规范的软件研发流程，全靠各个团队自由发挥。云原生DevOps专家团队面对这种实际场景，针对性的给出了架构设计和迁移改造方案。容器化改造客户原先的系统服务都是虚拟机部署，一个微服务需要单独规划一台4U8G的虚拟机，如此配置不易弹性伸缩且有巨大的资源浪费。专家团队顺势提出容器化改造，并且使用业界首个分布式云原生产品华为云UCS作为容器平台底座，同时给出微服务容器化改造的最佳实践，帮助客户快速迁移。统一代码仓库和制品仓库令人惊讶的是，客户没有统一的代码仓库和制品仓库，多个团队之间的代码资产各自管理。有些使用Git，有些使用SVN，更有甚者就未使用代码仓库。因此在代码从开发环境转换到测试环境、准生产环境时，通过U盘拷贝的形式，制品依赖更是如此。所以改造的下一步是统一必备的软件开发工具。综合考量各种因素后，我们为客户提供了Gitlab代码仓库、SWR镜像仓库以及nexus依赖仓库。统一的DevOps平台有了容器平台、代码仓库、镜像仓库等基础设施和软件开发平台，实践DevOps需要将这些平台结合起来，并提供持续交付的能力。软通动力应用交付平台完美匹配，其灵活的集成管理能力串联了多个研发工具链，给客户提供高效便捷的流水线配置体验。研发流程优化当基础配置全部准备完成后，此时需要流程规范和最佳实践进行指导。华为云UCS专家团队结合资产管理公司的组织架构以及业务结构，为客户量身定制了基于新平台的研发流程。从理论出发结合实际为客户实现云原生数字化转型。经过客户及华为云云原生团队的共同努力，客户业务最终完美的迁移到容器环境中。经过一段时间的学习、适应和磨合，客户按照DevOps的文化理念进行迭代、统一代码和制品仓库以及配置自动化流水线。据效能统计：人力管理成本平均减少70%、构建部署的频率提升十余倍、更改失败率降低、平均交付周期以及资源利用率都有了巨大的优化，顺利打破金融等行业的云原生、数字化转型困局。访问链接，体验华为云分布式云原生UCS：cid:link_0更多云原生技术动向关注容器魔方

KubeEdge社区v1.17.0 版本正式发布。新版本为边缘节点和设备带来了更多的新能力，同时持续在易用性上做了提升。KubeEdge v1.17.0 新增特性：支持边缘 Pods 使用 InClusterConfig 访问 Kube-APIServerMapper 支持流数据上报支持边缘子模块自启动引入 keadm ctl 命令，支持在边缘查询和重启 pod易用性提升：基于 Keadm 的部署能力增强Mapper 框架添加 MySQL 数据库升级 K8s 依赖到 v1.28  新特性概览   ▍支持边缘 Pods 使用 InClusterConfig 访问 Kube-APIServerKubernetes 支持 Pods 使用 InClusterConfig 机制直接访问 Kube-APIServer，然而在边缘场景，边缘 Pods 和 Kube-APIServer 通常不在一个网络环境下，无法直接访问。在1.17.0 新版本中，通过开启 MetaServer 和 DynamicController 模块，边缘 Pods 同样可以使用 InClusterConfig 机制直接访问 Kube-APIServer。该特性在本版本中作为 Alpha 特性发布，如果你需要使用，您需要开启边缘 List-Watch 开关并配置 requireAuthorization的featureGates。在使 keadm init 启动 CloudCore 时，指定 cloudCore.featureGates.requireAuthorization=true 以及 cloudCore.modules.dynamicController.enable=true。启动 EdgeCore 后，按如下修改 edgecore.yaml 后重启 EdgeCore。apiVersion: edgecore.config.kubeedge.io/v1alpha2 kind: EdgeCore featureGates: requireAuthorization: true modules: ... metaManager: metaServer: enable: true更多信息可参考：cid:link_3cid:link_4▍Mapper 支持流数据上报 1.17 版本中，针对当前 Mapper 只能处理离散型的设备数据，无法处理流数据的问题，为 Mapper-Framework 提供视频流数据处理的能力。在新版本中，能够支持 KubeEdge 管理边缘摄像头设备，获取摄像头采集的视频流，并将视频流保存为帧文件或者视频文件，增强 KubeEdge 边缘设备管理能力。边缘摄像头设备管理1.17 版本提供基于 Onvif 协议的内置 Mapper，实现 Onvif 设备驱动功能，能够根据用户配置文件中的定义连接摄像头设备，获取设备的鉴权文件与 RTSP 视频流，将 Onvif 摄像头设备纳管进 KubeEdge 集群。Onvif 设备的一个示例 device-instance 配置文件如下：apiVersion: devices.kubeedge.io/v1beta1 kind: Device metadata: name: onvif-device-01 namespace: default spec: deviceModelRef: name: onvif-model # need to be the same as the model name defined in onvif-model.yaml protocol: protocolName: onvif configData: url: 192.168.168.64:80 # Replace it with the address of your own onvif camera userName: admin # Replace it with the username of your own onvif camera password: /etc/secret/password # Fill in the fields according to your secret.yaml nodeName: edge-node # Replace it with your edge node name properties: - name: getURI visitors: protocolName: onvif configData: url: 192.168.168.64:80 userName: admin password: /etc/secret/password dataType: string视频流数据处理新版本增强 Mapper-Framework 数据面能力，内置流数据处理功能。用户能够在 device-instance 文件中进行配置，将边缘摄像头设备上报的视频流截取保存为视频片段文件以及视频帧文件，流数据处理的 device-instance 文件示例如下：apiVersion: devices.kubeedge.io/v1beta1 kind: Device metadata: name: onvif-device-01 ... properties: - name: saveFrame # Convert video stream into frame visitors: protocolName: onvif configData: format: jpg # Frame file format outputDir: /tmp/case/ # Directory for output frame files frameCount: 30 # Number of output frames frameInterval: 1000000 # Time interval between frames (The unit is nanoseconds) dataType: stream - name: saveVideo # Convert video streams into video clips visitors: protocolName: onvif configData: frameCount: 1000 # The number of frames the video clip contains format: mp4 # Video clip format outputDir: /tmp/case/ # Directory for output video clip videoNum: 2 # Number of video clips dataType: stream更多信息可参考：cid:link_5cid:link_6cid:link_2▍支持边缘子模块自启动由于配置或者可恢复的环境问题，例如进程启动顺序等，导致 EdgeCore 启动失败。例如，当 containerd.socket 没有就绪时，Edged 启动 Kubelet 失败会导致 EdgeCore 直接退出。在新版本中，我们改进了 Beehive 框架，支持边缘子模块重启。用户可以通过启动 moduleRestart featureGates，将 EdgeCore 的子模块设置为自动重启，而不是整个 EdgeCore 退出。该特性在本版本中作为 Alpha 特性发布，如果你需要使用，您需要配置 moduleRestart 的 featureGates。apiVersion: edgecore.config.kubeedge.io/v1alpha2 kind: EdgeCore featureGates: moduleRestart: true 更多信息可参考：cid:link_7cid:link_6▍引入 keadm ctl 命令，支持在边缘查询和重启 pod当边缘节点离线时，我们无法通过 kubectl 查看边缘节点上的 pod，在 1.17 中可以在边缘节点上通过 keadm ctl get/restart pod [flag] 对 pod 进行查询或重启。如果需要使用该特性，您需要开启 metaserver 开关。keadm ctl get pod 的可选参数如下：[root@centos-2 bin]# keadm ctl get pod -h Get pods in edge node Usage: keadm ctl get pod [flags] Flags: -A, --all-namespaces If present, list the requested object(s) across all namespaces. Namespace in current context is ignored even if specified with --namespace -h, --help help for pod -n, --namespace string Specify a namespace (default "default") -o, --output string Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file, custom-columns, custom-columns-file, wide) -l, --selector string Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2)keadm ctl restart pod 的可选参数如下：[root@centos-2 bin]# keadm ctl restart pod -h Restart pods in edge node Usage: keadm ctl restart pod [flags] Flags: -h, --help help for pod -n, --namespace string Specify a namespace (default "default")Demo 演示：[root@centos-2 bin]# alias kectl='keadm ctl' [root@centos-2 bin]# kectl get pod -owide -A NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES default nginx-deployment-58b54fbd94-f5q7p 1/1 Running 1 (20m ago) 22m 10.88.0.2 centos-2 kubeedge edge-eclipse-mosquitto-scvrk 1/1 Running 1 (16m ago) 28m 192.168.94.106 centos-2 [root@centos-2 bin]# kectl restart pod -n kubeedge edge-eclipse-mosquitto-scvrk 393cbcac4b484a4a28eee7dd2d63b33137a10a84d5f6eed6402b9a23efc6aef0 af4059137ced56b365da7e1c43d3ea218e3090ab7644a105651ca4661ddf26f0 [root@centos-2 bin]# kectl get pod -owide -A NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES default nginx-deployment-58b54fbd94-f5q7p 1/1 Running 1 (21m ago) 23m 10.88.0.2 centos-2 kubeedge edge-eclipse-mosquitto-scvrk 1/1 Running 2 (10s ago) 29m 192.168.94.106 centos-2 更多信息可参考：cid:link_8cid:link_9▍易用性提升：基于 Keadm 的部署能力增强将命令 keadm generate 更改为 keadm manifest；[root@centos-2 bin]# keadm --help|grep manifest manifest Checks and generate the manifests. example: [root@centos-1 keepalived]# keadm manifest --advertise-address= --profile version=v1.17.0在 keadm join 添加一个镜像仓库参数: image-repository，以支持自定义镜像仓库；[root@centos-2 bin]# keadm join -h|grep image-repository --image-repository string Use this key to decide which image repository to pull images from example: [root@centos-2 bin]# keadm join --cloudcore-ipport :10000 --kubeedge-version=1.17.0 --remote-runtime-endpoint=unix:///run/cri-dockerd.sock --image-repository my.harbor.cn/kubeedge --token xxxx 将 keadm reset 命令进行三级拆分，拆分成 keadm reset cloud 和 keadm reset edge, keadm reset 仍然被保留，使用时 cloudcore 和 edgecore 都会被卸载，新增的三级命令 keadm reset cloud 和 keadm reset edge 分别只卸载 cloudcore 和 edgecore。[root@centos-2 bin]# keadm reset --help ... Available Commands: cloud Teardowns CloudCore component edge Teardowns EdgeCore component Flags: --force Reset the node without prompting for confirmation -h, --help help for reset --kube-config string Use this key to set kube-config path, eg: $HOME/.kube/config (default "/root/.kube/config") [root@centos-2 bin]# keadm reset cloud --help ... Flags: --force Reset the node without prompting for confirmation -h, --help help for cloud --kube-config string Use this key to set kube-config path, eg: $HOME/.kube/config (default "/root/.kube/config") [root@centos-2 bin]# keadm reset edge --help ... Flags: --force Reset the node without prompting for confirmation -h, --help help for edge更多信息可参考：cid:link_1cid:link_10cid:link_11cid:link_12▍Mapper 框架添加 MySQL 数据库在 1.17 的 Mapper-Framework 中，数据推送模块新增了 MySQL 数据库,如果用户想使用 MySQL 作为某个 property 的 PushMethod，可以在 device instance 的对应 property 下， 通过如下配置即可：apiVersion: devices.kubeedge.io/v1beta1 kind: Device ... spec: properties: - name: xxx ... pushMethod: dbMethod: mysql: mysqlClientConfig: addr: 127.0.0.1:3306 #the url to connect to the mysql database. database: kubeedge #database name userName: root #user name更多信息可参考：cid:link_13▍升级 K8s 依赖到 v1.28新版本将依赖的 Kubernetes 版本升级到 v1.28.6，您可以在云和边缘使用新版本的特性。更多信息可参考：cid:link_14  版本升级注意事项  自 v1.17.0 起，我们推荐在使用 keadm 安装 KubeEdge 时使用 --kubeedge-version= 来指定具体版本，--profile version= 会逐渐废弃。▍致谢感谢 KubeEdge 社区技术指导委员会 (TSC)、各 SIG 成员对 v1.17 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_0 添加社区小助手k8s2222回复KubeEdge进入社区交流群

北京时间2024年5月21日，Volcano社区v1.9.0版本正式发布，此次版本增加了以下新特性：支持弹性队列容量capacity调度支持队列与节点间的亲和调度Volcano支持Kubernetes v1.29GPU共享支持节点打分调度增强scheduler metrics指标新增License合规性检查提升调度稳定性Volcano是业界首个云原生批量计算项目，于2019年6月在上海 KubeCon 正式开源，并在2020年4月成为 CNCF 官方项目。2022年4月，Volcano 正式晋级为CNCF 孵化项目。Volcano 社区开源以来，受到众多开发者、合作伙伴和用户的认可和支持。截至目前，累计有600+全球开发者参与社区贡献。支持弹性队列容量capacity调度Volcano现在使用proportion插件来进行队列管理，用户可以设置队列的guarantee、capability等字段来设置队列的预留资源和容量上限。并通过设置队列的weight值来实现集群内的资源共享，队列按照weight值按比例划分集群资源，但这种队列管理方式存在以下问题：队列划分的资源容量通过权重体现，不够直观。队列内的所有资源使用相同的比例进行划分，不能为队列的每一维资源单独设置容量。基于以上考虑，Volcano实现了新的队列弹性容量管理能力，它支持：用户可以直接为队列设置每一维度资源的容量，而不是设置weigh值来实现。基于deserved的队列弹性容量调度，支持队列的资源共享和回收。比如在AI大模型训练中分别为队列中不同的GPU型号如A100和V100，设置不同的资源容量。同时在集群资源空闲时，队列可以复用其他空闲队列的资源，并在需要时进行资源回收，直到回收到用户为队列设置的资源容量为止，即应得资源量deserved，从而实现弹性容量能力。使用改功能时需要设置队列的deserved字段，为每一维资源设置应得资源量。同时需要在调度配置中打开capacity插件，并关闭proportion插件。apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: demo-queue spec: reclaimable: true deserved: # set the deserved field. cpu: 64 memeory: 128Gi nvidia.com/a100: 40 nvidia.com/v100: 80队列弹性容量调度的完整使用例子，请参考：How to use capacity plugin[1]关于弹性队列容量设计文档，请参考Capacity scheduling Design[2]支持队列与节点间的亲和调度队列通常关联着公司内的部门，而不同部门通常需要使用不同的异构资源类型，比如大模型训练团队需要使用NIVDIA的Tesla GPU，而推荐团队需要使用AMD的GPU，当用户提交作业到队列时，需要根据队列的属性将作业自动调度到对应资源类型的节点上。为此Volcano实现了队列和节点的亲和调度能力，用户只需在队列的affinity字段设置需要亲和的节点标签，Volcano会自动将提交到当前队列的作业调度到队列关联的节点上，用户无需单独设置作业的亲和性，而只需统一设置队列的亲和性，提交到队列的作业都会根据队列与节点的亲和性将作业调度到对应的节点。该特性同时支持硬亲和、软亲和、反亲和调度，使用时需要为节点设置key为volcano.sh/nodegroup-name的标签，然后设置队列的affinity字段，指定硬亲和、软亲和和反亲和的标签值。例如如下的队列设置，表示提交到该队列的作业需要调度到标签值为groupname1和groupname2的节点，并优先调度到标签值为groupname2的节点，同时，作业不能调到到标签值为groupname3和groupname4的节点，当资源不足时则也可以调度到标签值为groupname3的节点上。apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: default spec: reclaimable: true weight: 1 affinity: # added field nodeGroupAffinity: requiredDuringSchedulingIgnoredDuringExecution: - <groupname1> - <groupname2> preferredDuringSchedulingIgnoredDuringExecution: - <groupname1> nodeGroupAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - <groupname3> - <gropuname4> preferredDuringSchedulingIgnoredDuringExecution: - <groupname3>该功能对应的调度插件名为nodegroup，完整使用例子请参考：How to use nodegroup plugin[3]详细设计文档请参考：The nodegroup design[4]GPU共享功能支持节点打分调度GPU共享是Volcano v1.8版本推出的GPU共享与隔离方案，提供GPU共享、设备显存控制能力，以提升AI训练推理场景下GPU资源利用率低的问题。v1.9在该功能基础上新增了对GPU节点打分的策略，从而可以在作业分配时选择最优的节点，进一步提升资源利用率，用户可以设置不同的打分策略。目前支持以下两种策略：Binpack：提供GPU卡粒度的binpack算法，优先把一个节点上的已经分配了资源的GPU卡占满，避免资源碎片和浪费。Spread：优先使用空闲的GPU卡而不是已经分配了资源的共享卡。详细使用文档请参考：How to use gpu sharing[5]Volcano支持Kubernetes v1.29Volcano版本紧跟Kubernetes社区版本节奏，对Kubernetes的每个大的基数版本都进行支持，目前最新支持的版本为v1.29，并运行了完整的UT、E2E用例，保证功能和可靠性。如果您想参与Volcano适配Kubernetes新版本的开发工作，请参考：https://github.com/volcano-sh/volcano/pull/3459 进行社区贡献。增强scheduler metrics指标Volcano使用了client-go客户端和Kubernetes交互，尽管客户端可以设置QPS来避免请求被限流，但是客户端实际使用的QPS到底达到了多少却很难观察到，为了实时观测到客户端请求的频率，Volcano新增了client-go客户端的metrics指标，用户可以通过访问metrics接口，查看GET、POST等请求在每秒钟的请求数量，从而确定每秒钟实际使用的QPS，以此决定是否需要调整客户端设置的QPS。同时client-go的相关指标还包括客户端证书轮转周期统计、每个请求的response size统计等。用户可以使用curl http://$volcano_scheduler_pod_ip:8080/metrics 来获取volcano scheduler的所有详细指标。详细PR见：[feat] Add rest client metrics by Monokaix · Pull Request #3274 · volcano-sh/volcano (github.com)[6]新增License合规性检查为了增强Volcano社区开源license合规治理规范，避免引入传染性开源协议，规避潜在风险，Volcano社区引入了开源license合规检查工具，所谓传染性协议指的是使用了该协议作为开源许可的软件在修改、使用、复制之后生成的衍生作品，也必须以该协议进行开源。开发者提交的PR会引入的三库如果包含了传染性开源协议比如GPL，LGPL等，CI门禁会进行拦截，开发者需要将三方库替换为松自由软件许可协议比如MIT、Apache 2.0，BSD等，以通过开源license合规检查。提升调度稳定性Volcano v1.9.0版本在抢占、调度失败重试、避免内存泄露、安全性增强等方面做了较多优化，具体内容包括：修复极端情况下deployment频繁扩缩容导致的pod无法调度的问题，详见PR：[cherry-pick for release-1.9]fix PodGroup being incorrectly deleted due to frequent creation and deletion of pods by guoqinwill · Pull Request #3376 · volcano-sh/volcano (github.com)[7]修复Pod抢占问题：详见PR：ignore PredicateFn err info for preempt & reclaim scheduler plugin by LivingCcj · Pull Request #3458 · volcano-sh/volcano (github.com)[8]优化Pod调度失败重试机制：详见PR：fix errTask channel memory leak by bibibox · Pull Request #3435 · volcano-sh/volcano (github.com)[9]metrics指标优化：详见PR：Fix queue metrics when there are no jobs in it by Monokaix · Pull Request #3463 · volcano-sh/volcano (github.com)[10]安全性增强：详见PR：Remove list secret in controller ClusterRole by lekaf974 · Pull Request #3449 · volcano-sh/volcano (github.com)[11]致谢贡献者Volcano 1.9.0 版本包含了来自多位社区贡献者的代码提交，在此对各位贡献者表示由衷的感谢：贡献者GitHub ID@daniel-hutao@wuyueandrew@googs1025@7sunarni @flyingfang@LivingCcj@guoqinwill@panoswoo@william-wang@lekaf974@yangqz@lowang-bh@loheagn@hwdef@archlitchi@Lily922@bibibox@Monokaix@belo4ya参考资料：[1] How to use capacity plugin: cid:link_1[2] Capacity scheduling Design: cid:link_3[3] How to use nodegroup plugin: cid:link_0[4] The nodegroup design: cid:link_4[5] How to use gpu sharing: cid:link_2[6] [feat] Add rest client metrics by Monokaix · Pull Request #3274 · volcano-sh/volcano (github.com): cid:link_8[7] [cherry-pick for release-1.9]fix PodGroup being incorrectly deleted due to frequent creation and deletion of pods by guoqinwill · Pull Request #3376 · volcano-sh/volcano (github.com): cid:link_9[8] ignore PredicateFn err info for preempt & reclaim scheduler plugin by LivingCcj · Pull Request #3458 · volcano-sh/volcano (github.com): cid:link_6[9] fix errTask channel memory leak by bibibox · Pull Request #3435 · volcano-sh/volcano (github.com): cid:link_7[10] Fix queue metrics when there are no jobs in it by Monokaix · Pull Request #3463 · volcano-sh/volcano (github.com): cid:link_10[11] Remove list secret in controller ClusterRole by lekaf974 · Pull Request #3449 · volcano-sh/volcano (github.com): cid:link_11

定义OPS（Operations Per Second）和FLOPS（Floating Point Operations Per Second）是用于衡量计算机性能的指标，特别是在评估处理器和图形处理单元（GPU）在执行数学运算时的能力。OPS（Operations Per Second）OPS指的是每秒钟可以执行的操作数，这里的“操作”可以是任何类型的计算，包括整数运算、逻辑运算、浮点运算等。OPS是一个通用的性能指标，可以用来衡量各种类型的处理能力，但它的具体含义可能会根据上下文而变化。例如，在某些情况下，OPS可能特指整数运算速度，而在其他情况下，它可能包括所有类型的计算操作。FLOPS（Floating Point Operations Per Second）FLOPS是专门用来衡量浮点运算性能的指标，它只计算每秒可以执行的浮点运算次数。浮点运算是涉及小数点的数学计算，这在科学计算、图形渲染和深度学习等领域非常重要。FLOPS通常分为以下几种类型：FLOPS（基本浮点运算）：单精度浮点运算（32位）DFLOPS（Double Precision FLOPS）：双精度浮点运算（64位）TFLOPS（TeraFLOPS）：万亿次浮点运算PFLOPS（PetaFLOPS）：千万亿次浮点运算EFLOPS（ExaFLOPS）：百亿亿次浮点运算适用应用场景OPS通用计算：对于不需要高精度浮点运算的应用，如网页浏览、文本处理等，OPS更能反映实际性能。嵌入式系统：在资源有限的嵌入式系统中，OPS可以帮助评估系统的综合处理能力。数据库操作：数据库查询和数据处理通常涉及整数运算和逻辑运算，OPS是一个更全面的性能指标。FLOPS科学计算：气象模拟、分子建模、物理模拟等需要高精度浮点运算的场景。深度学习：神经网络训练和推理过程中需要进行大量的浮点运算，尤其是单精度浮点运算。图形渲染：3D图形渲染中的光线追踪、阴影计算等需要浮点运算来模拟真实世界。总结在实际应用中，选择合适的性能指标取决于具体的应用需求和关注的运算类型。对于需要高精度计算的应用，FLOPS是更重要的指标；而对于一般的日常使用和整数运算密集型的应用，OPS可能更能反映实际性能。

通用算力、智能算力和超算算力是三种不同类型的计算能力，它们在定义、应用、侧重等方面存在明显的区别，但同时也有一定的联系。以下是详细的分析：一、联系这三种算力都是计算能力的体现，它们都是利用计算机硬件和软件资源来执行计算任务的能力。它们都是现代计算技术的重要组成部分，为各种应用提供了强大的计算支持。二、区别定义通用算力：是指计算机系统所能提供的通用计算能力，用于执行各种不同类型的计算任务，包括数据处理、模拟、机器学习和人工智能等。通用算力通常可通过云计算服务提供商获取，用户可以根据自己的需要租用不同规模的通用算力。智能算力：是指处理和分析大量数据、执行复杂计算任务的能力，主要用于人工智能、机器学习和大数据分析等领域。智能算力的核心在于高性能计算(HPC)和云计算，依赖于强大的硬件支持和先进的软件算法。超算算力：是由多台服务器联合成的集群计算系统，可以实现多层次的分布式计算任务，具有可扩展性、分布式处理能力和海量存储能力，是进行大规模计算任务的理想选择。应用通用算力：应用范围非常广泛，无论是科学研究、工程设计、商业分析还是医学诊断，通用算力都可以发挥作用。它的重要性在于提高了计算效率、降低了成本，并且可以应用于广泛的领域。智能算力：主要用于人工智能的训练和推理计算，比如语音、图像和视频的处理等。随着人工智能技术的不断发展，智能算力的需求也在不断增长。超算算力：主要用于尖端科学领域的计算，比如行星模拟、药物分子设计、基因分析等。超算系统具有快速的计算能力，可以通过分布式集群网络系统来解决复杂的计算问题。侧重通用算力：侧重于提供广泛的计算能力，满足各种不同类型的计算需求。智能算力：侧重于处理和分析大量数据，执行复杂计算任务，特别是在人工智能和大数据分析领域。超算算力：侧重于提供高性能的计算能力，解决复杂的科学计算问题，特别是在需要海量存储和分布式处理能力的领域。三、总结总的来说，通用算力、智能算力和超算算力在定义、应用和侧重方面存在明显的区别。通用算力提供广泛的计算能力，智能算力专注于人工智能和大数据分析，而超算算力则提供高性能的计算能力以解决复杂的科学计算问题。这三种算力各有侧重，但都是现代计算技术的重要组成部分，为各种应用提供了强大的计算支持。

在分析通算、智算、超算、云、大模型之间的关系时，首先我们需要明确它们各自的基本概念和特点。基本概念和特点通算：通常指通用的计算能力，没有特定的技术或平台指向，是计算机系统进行各种计算任务的基础。智算：面向AI典型应用场景，通过大规模数据训练模型，实现智能化应用。智算中心主要研究人工智能、机器学习等领域，具备高效的数据存储和管理功能，以及强大的计算能力来支持复杂的数据处理和分析。超算：侧重于科学计算等计算密集型任务，面向科研人员和科学计算场景提供支撑服务。超算中心通常采用并行计算的方式，将任务分配给多个计算节点进行计算，以解决一些需要大量计算资源的问题。云：云计算通过网络按需分配计算资源，主要用于处理数据密集、通讯密集的事务性任务，帮助用户降本增效或提升盈利水平。云数据中心通常由多个物理服务器组成，形成一个虚拟化的计算环境，用户可以根据自己的需求随时申请并使用计算资源。大模型：指具有大规模参数和复杂计算结构的机器学习模型，通常由深度神经网络构建而成，拥有数十亿甚至数千亿个参数。大模型通过训练海量数据来学习复杂的模式和特征，具有更强大的泛化能力，能够处理更加复杂的任务和数据。关联性和相互影响应用场景：通算作为计算能力的基础，支持着所有计算任务，包括智算、超算和云中的任务。智算主要服务于人工智能和机器学习领域，包括大模型的训练和应用。超算则更多地用于科学研究和计算密集型任务，如气象预报、地震模拟等。云提供了一个灵活、可扩展的计算环境，支持各种类型的应用，包括智算和超算任务。大模型作为机器学习的重要工具，依赖于智算中心提供的强大计算能力进行训练和推理。优势：智算和超算提供了强大的计算能力，支持复杂的数据处理和分析任务。云提供了灵活、可扩展的计算资源，降低了用户的IT成本。大模型通过训练海量数据，能够处理复杂的任务和数据，提高模型的表达能力和预测性能。挑战：随着数据量的增长和模型复杂度的提高，对计算能力的需求也在不断增加，这对智算、超算和云都提出了挑战。大模型的训练需要巨大的计算资源和时间，如何有效地利用这些资源并提高训练效率是一个重要的问题。相互影响：智算和超算的发展为云提供了更强大的计算能力支持，使得云能够处理更加复杂和大规模的任务。云的发展为大模型和人工智能应用提供了更加灵活和可扩展的计算环境，促进了这些领域的发展。大模型的训练和应用需要智算和超算中心提供的强大计算能力支持，同时也推动了这些中心的技术进步和发展。总结通算、智算、超算、云、大模型之间存在着密切的联系和相互影响。它们共同构成了现代计算技术的生态系统，推动着人工智能、科学研究和云计算等领域的发展。

▍背景在k8s集群中，容器水平自动伸缩(HPA)，可以根据容器资源的使用量，在设置好的副本范围内，自动扩缩容工作负载副本数(replicas)。HPA是基于指标阈值进行伸缩的，常见的指标有CPU和内存。也可以通过自定义指标，例如QPS、连接数等进行伸缩。但是存在一种场景：基于指标的伸缩存在一定的时延，这类时延主要包含：采集时延(分钟级) 、 判断时延(分钟级) 和伸缩时延(分钟级)。此类分钟级时延，无法适应在短期内极速上涨的业务流量，可能会导致应用CPU飚高，响应时间变长。容器定时水平自动伸缩(CronHPA)是对HPA的一种补充，对于有固定时间段高峰期的业务，可以提前将容器的实例数量扩容完毕，防止业务流量突发造成性能不足，导致业务延迟。而在业务低谷时，触发定时回收资源。在某些业务场景下，存在突发流量的同时，又具有明显的波峰波谷，若同时配置CronHPA和HPA两种策略，可能出现如下情况：在业务高峰到来前，CronHPA定时任务提前扩容业务容器副本，而此时HPA可能会检测到资源使用率很低而触发实例缩容，导致预扩容的策略失效。华为云CCE服务支持联动设置CronHPA策略和HPA策略，通过动态设置HPA的副本范围上下限，来调整业务容器实例数。▍使用示例日常生活中，许多业务场景在流量突发的同时具有明显的波峰波谷，且对响应时延很敏感，例如：1. 网络游戏：X游戏客户，旗下某大型网络游戏，在晚上或周末、节假日等高峰期间，玩家数量会急剧增加，导致游戏服务器的负载瞬间飙升，此时负载副本数若扩容较慢，可能导致网络卡顿，游戏体验显著下降；2. 视频直播：X视频直播APP，在某些大型活动、比赛等直播活动开始时，观众数量会迅速上升，导致服务器负载急剧增加，网络时延也会随之增加，进而导致观看直播的用户体验下降；3. 电商促销：X电商平台，在其促销活动时，通常会引起用户的热情高涨，导致用户访问量大幅增加，服务器负载也会急剧增加，若业务容器扩容不及时，很可能导致用户体验下降，严重的可能导致业务中断；4. 金融交易：X金融交易平台，旗下涉及多款金融产品，均需要实时响应，网络时延对交易效率和准确性有很大影响。在高峰期，交易量会急剧增加，网络时延也会随之增加。以上业务场景都需要高效、稳定的网络支持，对网络时延很敏感。如果业务容器扩容不及时，会导致网络时延过高，用户体验下降，甚至影响业务的正常运营。下面以视频直播服务为例，介绍如何进行弹性伸缩配置。假如每天晚上的8点半到10点有一场热门直播，在此期间，用户的访问量会暴增，随后流量缓慢下降直至到达低谷。为了节约成本，可按照如下配置，在流量高峰到来前，提前扩容业务容器实例数，在流量高峰退去后，根据业务流量，缓慢缩容：1.    在CCE控制台，单击集群名称进入集群。2.    单击左侧导航栏的“工作负载”，在目标工作负载的操作列中单击“更多 > 弹性伸缩”。3.    策略类型选择“HPA+CronHPA策略”，启用HPA策略，并同时启用CronHPA策略。此时CronHPA会定时调整HPA策略的最大和最小实例数。4.    设置HPA策略设置实例范围与系统策略，如下图， HPA会根据当前业务容器的CPU利用率，在1-10范围内动态调节容器的实例数，当CPU利用率大于80%时自动扩容，在CPU利用率低于60%时自动缩容业务容器实例数。5.    设置CronHPA策略设置定时任务，如下图所示策略一：20:00调整HPA策略实例数范围，从1-10变为8-10；策略二：22:30调整HPA策略实例数范围，从8-10变为1-10。6.    重复以上步骤，您可以添加多条策略规则，但策略的触发时间不能相同。7.    设置完成后，单击“创建”按照上述配置完成后，CronHPA会在流量高峰到来前的20:00调整HPA策略实例数范围，从1-10变为8-10，此时， HPA会将业务实例数至少扩容为8，为即将到来的流量高峰做准备。等到流量高峰过去后的22:30调整HPA策略实例数范围，从8-10变为1-10，此时，HPA会根据业务流量情况，缩容业务容器实例数到合适的值，降低用户使用成本。▍CronHPA与HPA联动解析 HPA是用来控制Pod水平伸缩的控制器，HPA周期性检查Pod的资源使用率数据，计算满足HPA资源所配置的目标数值所需的副本数，进而调整目标资源（如Deployment）的replicas字段。CronHPA支持定时调整HPA策略的最大和最小实例数，以此实现与HPA的联动，以满足复杂场景下的工作负载伸缩。由于HPA与CronHPA均作用于同一个deployment对象时存在冲突问题，两个伸缩策略相互独立，后执行的操作会覆盖先执行的操作，导致伸缩效果不符合预期，因此需避免这种情况发生。为避免上述问题，我们通过增强CronHPA，支持将CronHPA规则作用于HPA策略之上，CronHPA仅调整HPA的策略配置，而业务容器的实例数仅由HPA操作，从而实现两种弹性策略的协同工作。参数名中文名解释targetReplicasCronHPA的目标实例数表示CronHPA设定的业务容器实例数minReplicasHPA的最小实例数业务容器的实例数下限maxReplicasHPA的最大实例数业务容器的实例数上限replicas业务容器的预期实例数CronHPA策略生效之前业务容器的实例数▍总结k8s社区提供的HPA策略支持在配置的实例数范围内，根据业务容器的CPU、内存等资源使用率实现自动扩缩容。叠加定时扩容策略CronHPA，期望在业务高峰到来前，先通过CronHPA定时任务提前扩容业务容器副本数，然而此时可能会因HPA检测到资源使用率很低而触发实例缩容，导致预扩容的策略失效。华为云CCE服务通过将HPA与CronHPA组合，实现指标弹性策略与定时弹性策略的有机协同，满足了客户业务复杂的弹性伸缩场景。参考文档：https://kubernetes.io/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/cid:link_0更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

📮滴，学生卡！您已收到来自Volcano社区的开源之夏邀请~Volcano是业界首个云原生批量计算社区，也是 CNCF 首个及唯一孵化级批量计算项目。Volcano主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。社区已吸引5.8万+全球开发者，并获得3.8k+Star 和800+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、博云、京东、小红书、第四范式、bilibili等。🏷️社区地址：https://github.com/volcano-sh/volcano 目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到广泛应用，完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene、Ray 等众多主流计算框架的支持，并构建起完善的上下游生态。Volcano社区已连续4年加入开源之夏，并在今年带来5项课题，欢迎高校同学选报，报名时间4月30日-6月4日。开源之夏是由中国科学院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源软件社区的蓬勃发展，助力开源软件供应链建设。▍Volcano社区开源之夏2024课题课题一：Volcano支持Pod Scheduling Readiness调度项目编号：243ba0503项目难度：基础/Basic项目社区导师：常旭征导师联系邮箱：cxz2536818783@gmail.com项目简述：Pod 一旦创建就被认为已准备好进行调度。在 kube-scheduler 中，它会尽职尽责地寻找节点来放置所有待处理的 Pod。然而，在现实情况下，某些 Pod 可能会长时间处于“缺少必要资源”状态。这些 Pod 实际上以不必要的方式干扰调度程序（以及 Cluster AutoScaler 等下游组件），造成资源浪费等问题。Pod Scheduling Readiness是 kube-sheduler 的一项稳定功能。它通过设置Pod的schedulingGates字段来控制Pod的调度时机。Volcano也应该支持该功能，以增强调度功能，避免无意义的调度，提升调度效率，进行调度准入等。参考：https://kubernetes.io/docs/concepts/scheduling-eviction/pod-scheduling-readiness/项目链接：https://summer-ospp.ac.cn/org/prodetail/243ba0503?list=org&navpage=org课题二：Volcano支持多集群AI任务调度中的队列容量管理能力项目编号：243ba0505项目难度：进阶/Advanced项目社区导师：王龙辉（lowang-bh）导师联系邮箱：lhui_wang@163.com项目简述：随着AI大模型的迅速发展，单个K8s集群由于资源和性能瓶颈，已越来越不能满足大模型AI作业训练的需求，越来越多的用户使用多集群来管理和运行AI作业，Volcano正在支持多集群AI作业的任务调度，这其中涉及到多集群的作业管理、多租户任务公平调度，队列管理等系列需求。多集群编排系统Karmada已逐渐成为业界标准，Volcano需要基于Karmada现有的能力，构建多集群场景下的AI作业调度能力，弥补Karmada调度方面缺失的队列管理等能力，以解决多集群场景下AI作业任务调度、队列管理、多租户配额管理问题。项目链接：https://summer-ospp.ac.cn/org/prodetail/243ba0505?list=org&navpage=org课题三：Volcano支持弹性层级队列管理项目编号：243ba0509项目难度：进阶/Advanced项目社区导师：李鑫导师联系邮箱：hwdefcom@outlook.com项目简述：在云原生AI任务调度场景下，公平调度和资源利用率是用户比较关注的问题，Volcano社区已经构建了弹性队列管理插件capacity，以支持细粒度的资源借入借出和队列管理，提升资源利用率，但在实际场景中，队列通常是层级的，对应公司团队的层级组织架构，为了更加符合实际的队列使用场景，进一步提升AI任务调度的资源利用率，Volcano需要在capacity的基础上支持层级队列管理能力。项目链接：https://summer-ospp.ac.cn/org/prodetail/243ba0509?list=org&navpage=org课题四：云原生批量计算项目Volcano UI & Monitor系统项目编号：243ba0574项目难度：基础/Basic项目社区导师：王雷博导师联系邮箱：wangleibo1@huawei.com项目简述：作为首个云原生批量计算项目Volcano，提供了丰富的功能和优异的性能，帮助用户提升AI和大数据的性能以及提升整体资源利用率，然而对于很多用户来说，Volcano因为缺少前端UI以及监控，整体的使用成本以及学习曲线较高，尤其是对于集群管理员，无法通过UI对队列、作业进行管理以及无法直观的查看资源的总量、余量以及作业的进度等。该项目将设计和实现一套Volcano项目的前端UI，该UI具体包含如下内容：1. 集群资源信息查看2. 队列管理2.1 查看队列 （ reservation, min, max, allocated resource， job数量等）2.2 配置队列（reservation,min, max）3. 工作负载3.1 查看Job状态3.2 配置Job的关键属性4. 配置调度器的调度策略项目链接：https://summer-ospp.ac.cn/org/prodetail/243ba0574?list=org&navpage=org课题五：Volcano 性能基准测试和压力测试项目难度：243ba0576项目难度：进阶/Advanced项目社区导师：汪洋导师联系邮箱：wysea1990@163.com项目简述：Volcano开源项目提供了丰富的作业管理、队列管理、调度策略等功能，目前缺少一套公开的性能测试和压力基准测试。如果有一份性能基准测试报告，它将会帮助大数据用户以及HPC用户快速评估是否可以将他们的业务从传统软件迁移到Kubernetes和Volcano系统。同时也有利于新研发算法的有效性评估。本课题目标是设计和实现一套性能测试的方法以及标准，然后进行充分的性能及压力测试，最终提供一份报告。项目链接：https://summer-ospp.ac.cn/org/prodetail/243ba0576?list=org&navpage=org▍如何报名开源之夏Volcano课题？报名对象本活动面向年满 18 周岁的高校在校学生。暑期即将毕业的学生，只要申请时学生证处在有效期内，就可以报名活动。中国籍学生参与活动时需提供身份证、学生证、教育部学籍在线验证报告（学信网）或在读证明。外籍学生参与活动时需提供护照，同时提供录取通知书、学生卡、在读证明等文件用于证明学生身份。4月30日-6月4日，符合条件的学生可以通过开源之夏官网（https://summer-ospp.ac.cn/）注册、与导师沟通项目并提交项目申请。▶ 与导师建立沟通对Volcano社区开源之夏课题感兴趣的同学，可以通过本文上方导师邮箱或社区宣讲等方式，提前联系导师沟通课题要求，了解与锁定适合自己的项目；▶ 准备项目申请材料提交申请1. 查看学生指南（https://summer-ospp.ac.cn/help/student/）中的【项目申请模板】，并根据要求准备相关材料。2.点击项目主页中的【加入备选】按钮，进入系统个人中心【我的项目】中点击【查看】按钮，上传简历及项目申请书；3. 对所有项目申请书进行优先级排序，若同时被多个项目选中，则根据提交的项目排序，优先中选优先级高的项目；4. 点击【排序并提交】按钮提交全部项目申请。▶ 学生可以收获什么？结识开源界小伙伴和技术大牛获得社区导师的专业指导，与开源项目开发者深度交流丰富项目实践经验，提升项目开发技能为学习方向提供参考，为职业发展积累人脉通过结项考核的学生将获得结项奖金和结项证书（基础难度税前8000元RMB，进阶难度税前12000元RMB），更有机会获选优秀学生▍Volcano社区技术交流与联系添加社区小助手k8s2222回复Volcano开源之夏进入技术交流群

开源之夏介绍开源之夏是由中国科学院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源软件社区的蓬勃发展，助力开源软件供应链建设。开源之夏2024学生报名正在火热开展（4月30日-6月4日），Kmesh内核级云原生流量治理引擎共带来8项课题，欢迎高校同学选报。▍Kmesh社区介绍Kmesh（https://github.com/kmesh-net/kmesh）是集高性能、低开销及安全可靠于一身的内核级云原生流量治理框架，通过将 L4、L7流量治理能力卸载到内核，使得服务转发性能分别提升 50%、60%，底噪开销降低 70%；基于可编程内核 + eBPF实现的高性能流量治理引擎，Kmesh可实现服务网格场景下服务间多跳变一跳的服务访问，相比业界方案性能提升3~5倍。Kmesh 从OS视角，提出了基于可编程内核的服务治理，通过将流量治理能力下沉 OS，大幅提升网格数据面性能，为网格数据面的发展提供了一种全新思路。在早期版本开发过程中，Kmesh得到了openEuler社区的孵化与支持，后续作为独立发展的开源项目，将持续与openEuler紧密协作，为用户提供极致性能的流量治理技术方案。▍Kmesh社区开源之夏2024课题课题1 Kmesh数据面治理可扩展性项目编号：24f1e0358项目难度：进阶项目社区导师：吴长冶（sky）导师联系邮箱：wuchangye@huawei.com项目简述：Kmesh是基于可编程内核 + eBPF实现的高性能流量治理引擎，当前支持xds/workload治理模型；但在实际应用场景下，不同应用可能存在自定义治理规则的诉求，当前Kmesh缺乏较好的治理扩展机制，期望提供黑盒易用、解耦的可扩展机制，方便自定义治理规则的扩展诉求。项目链接：https://summer-ospp.ac.cn/org/prodetail/24f1e0358?list=org&navpage=org课题2 kmesh e2e测试项目编号：24f1e0360项目难度：进阶项目社区导师：姚增增导师联系邮箱：yaozengzeng@huawei.com项目简述：Kmesh是基于可编程内核 + eBPF实现的高性能流量治理引擎。e2e测试能够模拟真实场景下软件系统的完整性和准确性，验证整个系统能否按照预期工作以及不同组件是否能够协同工作。当前期望在Kmesh中引入e2e测试，加入黑盒测试维度，进一步提高项目质量。项目链接：https://summer-ospp.ac.cn/org/prodetail/24f1e0360?list=org&navpage=org课题3 一致性hash负载均衡项目编号：24f1e0362项目难度：进阶项目社区导师：谢颂杨（xsy）导师联系邮箱：xiesongyang@huawei.com项目简述：一致性hash负载均衡一致性hash负载均衡Kmesh是基于可编程内核 + eBPF实现的高性能流量治理引擎；当前支持随机和轮询的负载均衡算法，为了确保请求能够高效且均匀地分发到各个服务实例上，需要基于eBPF进一步扩展一致性hash负载均衡算法。项目链接：https://summer-ospp.ac.cn/org/prodetail/24f1e0362?list=org&navpage=org课题4 Kmesh支持拓扑感知{地域}负载均衡项目编号：24f1e0363项目难度：进阶项目社区导师：孔维斌导师联系邮箱：kongweibin2@huawei.com项目简述：Kmesh是基于可编程内核 + eBPF实现的高性能流量治理引擎；当前支持随机和轮询的负载均衡算法，为了确保请求能够高效且均匀地分发到各个服务实例上，需要基于eBPF进一步扩展拓扑感知{地域}负载均衡算法。项目链接：https://summer-ospp.ac.cn/org/prodetail/24f1e0363?list=org&navpage=org课题5  Kmesh支持限流项目编号：24f1e0365项目难度：进阶项目社区导师：田慕阳（talon）导师联系邮箱：tianmuyang@huawei.com项目简述：Kmesh是基于可编程内核 + eBPF实现的高性能流量治理引擎。在传统的Spring Cloud微服务和较新的Service Mesh微服务架构中，限流机制保证了微服务在突增流量场景下的可用性。当前行业趋势是微服务流量编排正基于eBPF逐渐下沉到内核，期望在Kmesh中引入限流能力。项目链接：https://summer-ospp.ac.cn/org/prodetail/24f1e0365?list=org&navpage=org课题6 Kmesh支持熔断项目编号：24f1e0366项目难度：进阶项目社区导师：张明轶（lec-bit）导师联系邮箱：zhangmingyi5@huawei.com项目简述：Kmesh是基于可编程内核 + eBPF实现的高性能流量治理引擎，当前支持xds/workload治理模型。在当前Kmesh中，对于eBPF程序，缺少UT测试等框架，需要引入UT测试框架保障整体代码质量Kmesh是基于可编程内核 + eBPF实现的高性能流量治理引擎。熔断机制通常用于防止服务之间的故障扩散，保护系统的稳定性，避免大量请求导致系统崩溃或雪崩效应。项目链接：https://summer-ospp.ac.cn/org/prodetail/24f1e0366?list=org&navpage=org课题7  Kmesh性能可视化项目编号：224f1e0367项目难度：进阶项目社区导师：李蔚（weli）导师联系邮箱：1289113577@qq.com项目简述：Kmesh是基于可编程内核 + eBPF实现的高性能流量治理引擎，可实现服务网格场景下服务间多跳变一跳的服务访问，相比业界方案性能提升3~5倍；随着社区特性的不断丰富，如何保障Kmesh性能是当下面临的重要挑战；当前Kmesh的主体功能包括与网格控制面对接（GO代码）、数据面治理转发（eBPF/ko代码），新特性修改容易引入性能劣化问题，同时对于多语言、跨用户态/内核态流程难以做性能基线防护；本课题期望实现一种Kmesh性能看护工具，实现Kmesh规则刷新、数据治理转发等场景的性能可视化观测，保障Kmesh关键性能指标看护。项目链接：https://summer-ospp.ac.cn/org/prodetail/24f1e0367?list=org&navpage=org课题8 Kmesh eBPF UT测试框架项目编号：24f1e0368项目难度：进阶项目社区导师：刘忻（L.X.）导师联系邮箱：liuxin350@huawei.com项目简述：Kmesh是基于可编程内核 + eBPF实现的高性能流量治理引擎，可实现服务网格场景下服务间多跳变一跳的服务访问，相比业界方案性能提升3~5倍；随着社区特性的不断丰富，数据面的eBPF程序越来越多，由于eBPF本身的限制（第三态编码，非用户态也非内核态，运行在内核虚拟机中，有专用的指令集），在Kmesh中通过tail-call、map-in-map等特性实现了较复杂的治理逻辑，这也为数据面质量防护提出了挑战；eBPF作为近年内核新提出的可编程技术，当前生态并不成熟，业界在eBPF测试能力也在做积极的探索（如 Unit Testing eBPF）；本课题期望结合Kmesh项目，开发一个eBPF UT测试框架，保障Kmesh数据面质量。项目链接：https://summer-ospp.ac.cn/org/prodetail/24f1e0368?list=org&navpage=org▍如何报名开源之夏Kmesh课题？报名对象本活动面向年满 18 周岁的高校在校学生。暑期即将毕业的学生，只要申请时学生证处在有效期内，就可以报名活动。中国籍学生参与活动时需提供身份证、学生证、教育部学籍在线验证报告（学信网）或在读证明。外籍学生参与活动时需提供护照，同时提供录取通知书、学生卡、在读证明等文件用于证明学生身份。4月30日-6月4日，符合条件的学生可以通过开源之夏官网（https://summer-ospp.ac.cn/）注册、与导师沟通项目并提交项目申请。与导师建立沟通对Kmesh社区开源之夏课题感兴趣的同学，请提前通过本文上方导师邮箱或社区宣讲等方式，联系导师沟通课题要求，了解与锁定适合自己的项目；准备项目申请材料提交申请1. 查看学生指南（https://summer-ospp.ac.cn/help/student/）中的【项目申请模板】，并根据要求准备相关材料。2.点击项目主页中的【加入备选】按钮，进入系统个人中心【我的项目】中点击【查看】按钮，上传简历及项目申请书；3. 对所有项目申请书进行优先级排序，若同时被多个项目选中，则根据提交的项目排序，优先中选优先级高的项目；4. 点击【排序并提交】按钮提交全部项目申请。学生可以收获什么？结识开源界小伙伴和技术大牛获得社区导师的专业指导，与开源项目开发者深度交流丰富项目实践经验，提升项目开发技能为学习方向提供参考，为职业发展积累人脉通过结项考核的学生将获得结项奖金和结项证书（基础难度税前8000元RMB，进阶难度税前12000元RMB），更有机会获选优秀学生▍Kmesh社区开源之夏课题宣讲会为帮助同学们更好地了解与选定课题，Kmesh社区将于5月16日（周四）下午16:00开展课题宣讲，欢迎同学们关注参与！学生参会链接：https://meeting.huaweicloud.com/welink/#/j/99359226/UIO1rsuCRnKWkeJJAjFfwuIMPKlktW4p1添加社区小助手k8s2222回复Kmesh开源之夏进入社区交流群

▍企业上云现状：上云趋势持续加深，但云上开支存在显著浪费根据Flexer 2024年最新的一项调查显示，当前有超过70%的企业重度使用云服务，而这个数据去年是65%。由此可见，越来越多的企业开始把业务部署在云上。企业在使用云厂商提供的云服务的同时，也在为云服务的花费买单。调查显示，平均大约有30%的云成本支出被认为是无效支出。如何节省云成本支出成为近几年上云企业最关心的Top1问题。▍企业云原生化逐步深入，成本治理依然存在挑战云原生技术当前已经成为很多企业进行数字化转型的主流方式。kubernetes提供的资源共享、资源隔离、弹性调度等能力，本身能够帮助企业提升资源使用率，降低企业IT成本。然而，2021年CNCF《FinOps Kubernetes Report》的调研报告显示，迁移至Kubernetes平台后，68%的受访者表示所在企业计算资源成本有所增加，36%的受访者表示成本飙升超过20%。其背后的原因值得深思。▍云原生时代成本治理面对的挑战云原生时代成本治理有四个矛盾点：业务单元 VS 计费单元：一般云服务（比如ECS）的计费周期比较长，可能是包月或者包年；而云原生容器的生命周期相对比较短暂，容器的弹性伸缩、故障重启等动作，都有可能导致资源的闲置率比较高。容量规划 VS 资源供给：容量规划一般是静态的，一般是按照预算或者规划提前准备容器，而资源供给是业务来驱动。业务的高峰流量冲击，升级扩容等场景，都会对容量规划造成很大的挑战。统一治理 VS 多云部署：现在很多企业使用了不止一朵云，不同的云厂商的账单接口和格式都不一样，不利于企业的多云统一成本治理。成本模型 VS 云原生架构：云厂商的成本模型相对比较简单，一般是按照物理资源来计费，比如ECS服务是以整机的价格来计费。云原生架构以应用为中心，资源的申请细化到CPU/内存等粒度。这就导致云原生场景成本可视化和成本分析比较困难。总结下来，云原生成本治理面临三大挑战：成本洞察：云原生场景如何实现成本可视化，如何快速定位成本问题、识别资源浪费？成本优化：云原生成本优化的手段很多，如何采用合适的成本优化手段来实现收益最大化？成本运营：企业如何构建可持续的成本治理体系与文化？▍华为云云原生FinOps解决方案FinOps 是一门将财务管理原则与云工程和运营相结合的学科，它使组织更好地了解其云支出。 它还能够帮助他们就如何分配和管理云成本做出明智的决策。 FinOps 的目标不是节省资金，而是通过云实现最大化的收入或业务价值。 它有助于组织控制云支出，同时保持支持其业务运营所需的性能、可靠性和安全性级别。FinOps Foundation 将 FinOps 定义为三个阶段：通知、优化和运营。根据每个团队或企业完成 FinOps 的进度，公司可能会同时处于多个阶段。通知（成本洞察）：通知是 FinOps 框架的第一阶段。这一阶段旨在为所有利益相关者提供所需的信息，以便于他们了解情况，从而做出有关云使用的经济高效的明智决策。成本优化：成本优化重点是想方设法节约成本。根据当前使用情况，您的组织可以在哪些方面合理调整资源规模，并从折扣中受益？成本运营：成本运营是 FinOps 框架的最后一个阶段。在这一阶段，组织会根据业务目标持续评估绩效，然后想方设法改进 FinOps 实践。优化工作到位后，组织可以借助自动化来实施策略，在不影响性能的情况下不断调整云资源来控制成本。华为云云原生FinOps解决方案，参照业界FinOps标准与最佳实践，为用户提供云原生成本多维可视化与多种成本优化治理手段，协助客户最大化的收入或业务价值。▍云原生FinOps - 成本洞察华为云云原生FinOps成本洞察，提供如下关键特性：基于标签的资源成本归属支持ECS、EVS等资源关联集群标签，便于集群费用汇总计算基于CBC账单的精准成本计算基于CBC真实账单进行成本分摊计算，精准划分部门成本灵活的成本分摊策略支持集群、命名空间、节点池、应用、自定义等多种维度的成本可视化与成本分摊策略。支持长期的成本数据存储与检索最大支持长达2年的成本分析，支持月度，季度，年度报表及导出。工作负载快速感知，轻松应对快速弹性场景针对应用快速弹性场景，支持分钟级的负载发现与计费能力，让所有成本无一遗漏。云原生成本洞察的实现机制介绍：1、集群物理资源成本 VS 集群逻辑资源成本集群的成本可以从两个角度来计算：集群物理资源成本，包括集群直接或间接关联的资源成本，比如集群管理费、ECS成本、EVS成本等。集群的物理资源成本可以从云成本账单中直观的体现出来。集群逻辑资源成本，从kubernetes资源的角度，集群的成本包括工作负载的成本，再加上集群闲置资源成本和公共开销成本。不难看出，集群物理资源成本=集群逻辑资源成本。2、单位资源（CPU/内存等）成本计算在集群的物理资源成本已知的情况下，如何推导出集群逻辑资源成本（如pod/工作负载），是云原生FinOps成本洞察的关键。这里核心要解决的问题是单位资源成本计算的问题。我们知道，一般的云虚拟机是按照整机的价格去售卖的，不会按照单位CPU或内存售卖。但是容器服务的资源占用是按照单位资源（CPU或内存等）来申请的。所以必须计算出单位资源的成本，才能最终计算出容器服务占用的成本。一般云厂商单位CPU或内存的价格会有一个估算值，我们也可以按照CPU和内存的成本占比来计算单位资源成本。3、云原生资源成本计算从下图我们可以看出，一个Pod的资源使用是随着时间动态波动。有些时刻Pod的资源占用低于资源申请（Request），有些时刻Pod的资源占用大于资源申请（Request）。在计算Pod成本时，我们会定时采样Pod的实际使用值和Request值，并将实际使用值和Request值中的最大值用于Pod的成本计算。这是因为一旦Request值分配给Pod，那么这不是资源会被K8S预留，不会被其他Pod抢占。所有Pod需要为Request部门的资源买单。同理，如果Pod的实际使用量大于Request，那么这个Pod也需要为超出的部分买单。基于以上原理，我们就可以得出Pod的成本计算：将命名空间下所有的Pod成本累加，就可以得出命名空间维度的成本：基于以上计算逻辑，华为云CCE云原生成本治理特性实现了多种维度的集群成本可视化，比如：集群成本可视化命名空间成本可视化节点池成本可视化工作负载成本可视化4、部门成本分摊与成本分析报表很多企业会把一个集群安装命名空间的粒度分配给不同的部门使用。那么如何对各个部门的成本进行可视化分析？从上图可以看出，部门的成本不仅包括部门归属的命名空间的成本，还应该承担一部分公共成本。这部分功能成本包括系统命名空间成本和空闲资源成本。华为云CCE云原生成本治理支持基于部门的成本分摊策略配置，如下图所示：同时，基于部门的成本分摊策略，华为云CCE云原生成本治理提供了月度/季度/年度报表功能，最大支持2年的报表查询与导出。▍云原生FinOps - 成本优化云原生场景如何提升资源利用率？据 Gartner 统计，企业CPU平均使用率不足15%，造成资源利用率低的原因有多种，典型场景有：• 资源配置不合理：部分用户对于自己服务的资源使用情况不了解，申请资源时具有盲目性，通常申请过量资源• 业务波峰波谷：微服务具有明显日级别波峰、波谷特性，用户为保证服务的性能和稳定性按照波峰申请资源• 资源碎片化：不同业务部门资源池独立，无法做到资源共享，容易产生资源碎片。容器化能一定程度上提升资源利用率，但是存在部分问题单纯依赖容器化无法得到有效解决：• 资源过量申请：如果没有有效的资源推荐和监控机制，普遍实践还是是超额申请、积沙成塔造成资源浪费。• 资源池统一：K8s原生调度器缺少组、队列等高阶调度能力；大数据业务存算一体难以利用容器弹性优势。• 应用性能：单纯增加部署密度难以保证服务质量。为了提升集群资源利用率，CCE云原生FinOps解决方案提供了多种优化手段，比如智能应用资源规格推荐、云原生混部、动态超卖等能力。1. 智能应用资源规格推荐为了保障应用性能和可靠性，同时由于缺乏足够的可视化工具，我们总是倾向为应用申请过量的资源。为了解决这一问题，CCE云原生成本治理提供了智能应用资源规格推荐功能。该功能基于应用的历史画像数据，基于机器学习算法，为应用推荐最佳的申请值。2. 华为云云原生混部解决方案华为云CCE云原生混部解决方案基于volcano插件，支持一键部署，为容器业务提供高低优先级混合部署，动态超卖，服务QoS保障等能力。关键能力主要包括：容器业务优先级与资源隔离融合调度应用SLO感知：多类型业务智能混合调度，应用拓扑感知，分时复用，超卖等；资源感知调度：提供CPU NUMA拓扑感知、IO感知、网络感知调度，软硬协同，提升应用性能；集群资源规划：提供队列、公平、优先级、预留、抢占等丰富策略，统一满足高优、低优业务；节点QoS管理：多维度资源隔离、干扰检查、驱逐机制。下面重点介绍动态超卖特性：如何将节点闲置资源再利用，提升资源利用率。动态超卖的核心原理为：将节点Request和实际使用量的差值部分，作为可调度资源，供调度器重新分配，仅供低优任务使用。超卖特性有如下特点：低于作业优先使用超卖资源高优作业预选超卖节点时只能使用其非超卖资源统一调度周期高优作业先于低优作业调度不管是云原生混部还是超卖特性，都可以提升资源利用率。那么如何在提升资源利用率的同时，保障应用性能与服务质量？华为HCE 2.0 OS提供的CPU隔离能力，结合CPU快速抢占、SMT管理控制和离线任务压制指令的负载均衡能力，保障在线业务资源QoS同时，也能让被压制的离线任务指令尽量快速得到响应。根据实验室中模拟在线和离线混部场景(CPU利用率70+%)与单独业务部署在线的场景（CPU利用率30%）进行性能对比，混部场景中在线业务的性能（时延&吞吐）劣化幅度控制在单独部署在线业务性能的5%之内。基本可以认为把混部对性能的影响降低到可以忽略不计。下面我们来看一个客户案例，该客户利用华为云云原生混部解决方案，优化资源配置，最终实现35%的资源利用率提升。该客户的主要痛点包括：应用干扰：大数据与在线语音、推荐等应用争抢资源，e.g. cpu/memory，网络；影响高优任务服务质量。应用资源配置不合理：为了保证调度成功，request设置很小，不能反馈负载资源需求，引发资源冲突应用绑核：部分应用绑核，总体资源利用率低基于客户痛点，我们为客户提供如下解决方案：客户将原来节点OS由CentOS切换至华为云HCE OS；将调度器由原来基于默认调度器切换至Volcano调度器；根据客户业务属性，配置调度优先级、隔离等等策略；通过华为云云原生混部解决方案，最终为客户带来资源利用率提升35%的收益。3. CCE Autopilot：按需付费与灵活规格助力客户节约成本CCE全新推出的Autopilot集群，支持按照应用的实际用量按需付费，相对于CCE集群的优势是Autopilot集群将节点的管理运维完全托管起来，这样您无需提前规划和购买节点资源，从而实现精细化的成本治理。这里我们看两个客户场景：互联网文娱和社交业务，春节假期期间流量是平时的数倍，专项跟踪运维保障，提前预留资源，成本巨大。网约车平台，业务具有典型的早晚高峰特点，传统驾驶模式需要客户手动购买和提前预留资源，资源利用率低。通过Autopilot可以实现成本精细化治理，最终实现整体成本降低与收益最大化。扫码体验华为云CCE获取华为云云原生FinOps方案▼▼▼

开源之夏介绍开源之夏是由中国科学院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源软件社区的蓬勃发展，助力开源软件供应链建设。Kuasar多沙箱容器运行时项目开源之夏2024课题已上线！这个夏天，期待与同学们一起开启多沙箱容器运行时技术之旅。▍Kuasar社区介绍CNCF Kuasar 多沙箱容器运行时项目（https://github.com/kuasar-io/kuasar）于2023年4月在KubeCon + CloudNativeCon Europe上由华为云、中国农业银行以及openEuler社区、WasmEdge社区和Quark Containers社区联合发起，并于2023年12月成为云原生计算基金会（CNCF）官方项目。Kuasar融入了各企业和社区在容器运行时领域的前沿探索、技术积累和生产实践，开源至今受到业界的广泛关注和支持，数十位来自外部企业、高校的开源爱好者参与开发贡献和积极落地应用，Kuasar正以开源创新的姿态促进云原生产业发展。▍Kuasar社区开源之夏2024课题已上线课题一 vmm类型Pod支持使用youki库创建容器项目编号：240110284项目难度：进阶/Advanced项目社区导师：abel-von（华为云）导师联系邮箱：fshb1988@gmail.com项目简述：Kuasar可以创建轻量级虚拟机（vmm）类型的Pod，并在虚拟机内创建容器示例。当前做法是虚机内的vmm-task进程调用runc命令行进行创建，存在一定的性能开销。Youki（containers/youki: A container runtime written in Rust (github.com)）是一个使用rust语言编写的容器运行时，同样遵循OCI规范。本课题希望可以实现在vmm-task进程里调用youki库（注意，是库不是命令行）的接口进行容器生命周期管理。项目链接：https://summer-ospp.ac.cn/org/prodetail/240110284?lang=zh&list=pro课题二 使用tracing库增强组件可观测性项目编号：240110286项目难度：基础/Basic项目社区导师：burning（华为云）导师联系邮箱：burning9699@gmail.com项目简述：追踪（tracing）技术通常被用于业务逻辑执行情况的分析和问题定位，方便开发测试人员了解框架、找出瓶颈、分析问题，Rust也有类似的库：tokio-rs/tracing: Application level tracing for Rust. (github.com) 。本课题期望通过引入该库，实现对vmm-sandboxer和vmm-task请求调用情况的可视化，提高系统可观测性。项目链接：https://summer-ospp.ac.cn/org/prodetail/240110286?lang=zh&list=pro▍开源之夏面向哪些学生？本活动面向年满 18 周岁的高校在校学生。暑期即将毕业的学生，只要申请时学生证处在有效期内，就可以报名活动。中国籍学生参与活动时需提供身份证、学生证、教育部学籍在线验证报告（学信网）或在读证明。外籍学生参与活动时需提供护照，同时提供录取通知书、学生卡、在读证明等文件用于证明学生身份。▍我可以在开源之夏获得什么？结识开源界小伙伴和技术大牛获得社区导师的专业指导，与开源项目开发者深度交流丰富项目实践经验，提升项目开发技能为学习方向提供参考，为职业发展积累人脉通过结项考核的学生将获得结项奖金和结项证书（基础难度税前8000元RMB，进阶难度税前12000元RMB），更有机会获选优秀学生▍学生参与关键时间点4月30日-6月4日期间，学生可以通过开源之夏官网（https://summer-ospp.ac.cn/）注册、与导师沟通项目并提交项目申请。对Kuasar社区开源之夏课题感兴趣的同学，可以通过本文上方导师邮箱，提前联系导师沟通课题需求，找到最适合自己的课题方向，您也可以添加社区小助手微信k8s2222，回复Kuasar进入社区技术交流群或了解社区课题。添加社区小助手微信k8s2222回复Kuasar了解课题申报或进入社区技术交流群学生在开源之夏课题参与期间，通过线上工作的形式完成课题，相关项目结项需要在9月30日前以 PR 的形式提交到Kuasar社区仓库中并完成合并，结项的同学根据项目难度获得结项成果及奖金，并有机会获选主办方优秀学生。▍进一步了解Kuasar作为多沙箱容器运行时项目，Kuasar在保留传统容器运行时功能的基础上，与Containerd社区一起推动新的沙箱接口统一标准，并通过全面Rust化以及优化管理模型框架等手段，进一步降低管理开销，简化调用链路，灵活扩展对业界主流沙箱技术的支持。此外，通过支持多安全沙箱共节点部署，Kuasar可以充分利用节点资源、降本增效，为用户提供更安全高效的沙箱场景解决方案。Kuasar项目全景图南向沙箱方面，Kuasar已支持基于轻量级虚拟化技术的安全容器沙箱（Cloud Hypervisor、Qemu、StratoVirt），基于新兴的WebAssembly沙箱（WasmEdge、Wasmtime），基于进程级虚拟化的App Kernel沙箱（Quark）以及基于内核的原生普通容器沙箱（runC）；北向引擎方面，Kuasar已与Containerd联合构建最新的沙箱接口标准，并共同推动该标准在Containerd v2.0版本的完整实现。此外，轻量级容器引擎iSulad项目也已经完成与Kuasar项目的深度集成，支持在openEuler 23.09创新版本上一键部署。CNCF Kuasar社区期待与同学们一起开启开源之夏2024，这个夏天，来自华为云的大咖导师将与您携手作战，一起推动云原生领域容器运行时技术的探索、创新和发展。

下面开始介绍Neutron的网络结构，对于Nova-network和Quantum本节暂不讨论。首     先需要对Neutron中的3类节点和3种网络进行介绍。(1)3类节点 控制节点实现像、存储、身份认证、前端等服务，运行Nova-compute的调度模块以及Nova api-server。计算节点实现Nova-compute，以及Neutron的一些Agent。网络节点实现Neutron 的一些Agent。注意，由于OpenStack为分布式架构实现，因此Neutron- server 既可以运行在控制节点中，也可以运行在网络节点中。 (2)3种网络 OpenStack内部模块之间的交互发生在管理网络，虚拟机之间的通信发生在数据网络，而External Network/API Network网络是连接外网的，无论是用户调用Openstack API,还是虚拟机与外网间的互通都需要经过这个网络。目前OpenStack通常采用Out-of-Band 方式进行部署，管理网络与另外两个网络是独立的，也不涉及复杂的组网需求，本章后续内容的分析只针对数据网络与External Network/API Network 网络。 Neutron的数据网络支持3种常见的网络类型，包括Flat、VLAN和 Overlay。(1)Flat类型 Flat 类型最为简单，所有的虚拟机共用一个私有IP网段，IP地址在虚拟机启动时完成 网段的网关上进行 NAT。 注入，虚拟机间的通信直接通过HyperVisor中的vBridge/vSwitch进行转发，公网流量在该NAT上使用。(2)VLAN类型     VLAN类型引入了多租户机制，虚拟机可以使用不同的私有IP网段，一个租户可以拥有多个IP网段。虚拟机IP通过DHCP获取。网段内部虚拟机间的通信直接通过 HyperVisor 中的vBridge/vSwitch进行转发，同一租户跨网段通信可以通过vRouter做路由，公网流量在该网段的网关上进行NAT。 (3) Overlay类型 1）Overlay类型利用隧道技术进行隔离和传输，相比于VLAN类型有以下改进。1)租户数量从4096增加到1600万; 2)租户内部的二层通信可以跨越底层的IP网络，虚拟机能够迁移到任意位置;3)一般情况下，不需要对底层网络进行任何额外的配置。

有了这些传输路径做基础，再加上Packet Switching ASIC、CrossPoint和收发器所提供的可编程能力，控制平面能够对光路径进行非常灵活的调度。不过，Plexxi并没有采用纯集中式的控制，其控制平面的架构是层次化的，除了Out-of-Band的Plexxi Control外，还有分布于各个Plexxi Switch本地的Co-Controller。  1.Co-Controller     Co-Controller的作用是实现分布式的基础转发，而并不负责对光路径进行优化。Co- 身就具 Controller 的主要功能包括邻居的发现、Reactive式的二层转发、路径负载均衡、路径监测 供了车 以及快速重路由。下面来具体说一下基础转发的过程，考虑一个多跳传输的场景，A向B发起通信:①当A所在的ToR收到ARPRequest的广播后，会向所有位于相同VLAN的本地端口以及所有的Local Channel(包括east-towards和west-towards两个方向)进行泛洪，并将该数据包上送给Co-Controller,Co-Controller完成MACA的学习，并通过一种私有的协议在交换机间发布该MAC地址。②East-towards方向的过路交换机收到该ARP Request后，同样也会向所有和A位于相同VLAN的本地端口以及所有east-towards方向的Local Channel进行泛洪，不过对于从光口传进来的数据包并不会上报给Co-Controller进行学习，而是通过A所在的ToR所宣告的MAC路由来学习。West-towards方向上同理。该过程一直持续下去，最终B会收到该ARPRequest。③B把 ARP Reply单播出来以后，B所在的 TOR会上报给Co-Controller,Co-Controller会通过散列在多条光路径间进行负载均衡，这些路径包括east-towards 和 west-towards中距离A较近的方向上的Local Channel以及可以直达A所在ToR 的 Express Channel。 2.Plexxi Control 对应地，PlexxiControl只负责对光路径进行优化，也就是说，即使它宕掉了，也不会影响到基本的互通性。PlexxiControl对光路径进行优化的工作流程为:①收集所有交换机中的信息，主要包括Local Channel和ExpressChannel的分配以及MAC的接入位置，并根据上述信息形成网络的全局视图。②将AffinityModel和全局视图输入Algorithmic Fitting Engine中，为Affinity Group间的通信计算出符合AffinityAttributes的光路径，这被称为 FSAT。③完成FSAT 的计算后，剩余的光路径可用于传输那些并没有指定 Affinity的流量. Algorithmic Fitting Engine同样会为这部分流量计算出加权的光路径，这被称为PSAT。实际上可以将 PSAT理解为对于Co-Controller所实现的基础转发的优化。④FSAT和 PSAT是由Plexxi Control 自动生成的，对于用户来说属于一种隐式的路径优化。PlexxiControl 还提供了一种UDT的方式，允许用户显式地指定传输特定流量的光路径。⑤如果现有的光路径不能满足上述的优化需求，那么PlexxiControll还会调整CrossPoint和收发器，以对光路径进行重构。⑥上述步骤都完成后，PlexxiControl会将结果主动地推给交换机，并通过2-phase commit来保证一致性。 以光传输为技术主体来构建数据中心网络，这种思路多见于学术界的研究中，Plexxi将其产品化的做法可以说是革命性的，超越了当时甚至是目前工业界对于数据中心网络的理解。不过，与应用的紧密关联使得Plexxi在网络优化领域形成了独到的优势，吸引了一些有相关需求的用户。同时，光传输所带来的高带宽、低时延和稳定性，也使得Plexxi在 Plexxi已经开始将重心转向了超融合网络架构的构建。    存储的场景中找到了一些机会。超融合的兴起为Plexxi提供了汇聚自身优势的抓手。

PLUMgrid 的技术基石是IOVisor，而要了解IOVisor，就必须先了解eBPF。众所周知，网络协议栈的设计和实现都是分层的，数据包经过协议栈时包头会被逐层剥掉，应用 虚拟 层是看不到L2~L4的头的。如果想要实现vSwitch 或者vRouter，必须要看到L2/L3的 ter, 头，此时通常需要对协议栈进行修改(内核旁路技术除外)，通过在Linux协议栈中插入 vice    hook 点，将数据包从通用的协议栈处理流程中“钩”出来，以对数据包进行自定义的处理。     租户    BPF(BerkeleyPacket Filter，伯克利数据包过滤器)是一种著名的数据包捕获机制，用户可     NS,    以编写自己的 BPF程序，将其hook到协议栈特定的位置，然后将满足某些特征的数据包过     滤出来并送到user space 中进行处理。BPF可以在3个位置做hook,在raw socket处“钩”出来的是完整的有L2头的数据包，在streamsocket处“钩”出来的是以UDP头为起始的数据包，在datagramsocket处“钩”出来的是以TCP头为起始的数据包。比如想获得所有 HTTP 的包，就可以自己写一个BPF程序去匹配80端口，然后将关联到datagram socket 的 hook 点上即可，如图4-110所示。Linux在很早的版本中就提供了对BPF的支持，很多大家耳熟能详的网络程序都是通过BPF来实现的，包括TC、DHCP、nmap、libcap等。 不过由于实现上的原因，BPF能够支持的功能十分有限，比如只有2个寄存器，寄存器是32位的,对数据包进行处理的指令也很少，只能对数据包进行解析和匹配，因此BPF主要用来对数据包进行过滤，难以实现更为复杂的网络处理功能。eBPF( extended BPF) 的提出解决了 BPF的上述问题，主要体现在以下几个方面。 □寄存器资源更为充足，能够提供10+的 64位寄存器。 口指令更为丰富，eBPF程序能够对数据包字段进行改写、移位、交换等操作，因此 eBPF程序能够实现更为复杂L2~L7的 kernel VNF。 支持key/value的数据结构bpf_map，可以通过用户空间将网络表项(如MAC表、路由表、NAT表等)注入内核的eBPF程序中，eBPF程序会据此进行查找与转发。 bpf_map中存有一类特殊的映射关系，记录每个eBPF程序的文件描述符，因此不同的eBPF的内部结构如图4-111所示。eBPF程序间能够实现灵活的跳转，可以非常方便地实现服务链。