以前好像有看到过，但是最近在产品列表里找不到了，集成数据库，云函数的一体化产品。

北京时间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

▍背景在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方案▼▼▼

随着云计算和微服务的兴起，容器化技术已经成为现代软件开发和部署的核心。本文将详细介绍容器化技术的概念、优势、主流工具以及最佳实践，帮助读者全面理解并应用这一技术。一、什么是容器化技术？容器化技术是一种轻量级的虚拟化技术，它允许开发者将应用程序及其依赖项打包到一个可移植的容器中。这个容器包含了应用程序运行所需的所有环境，使得应用程序可以在任何支持容器技术的平台上无缝运行。与传统的虚拟化技术相比，容器化技术更加轻量级，因为它只包含应用程序及其依赖项，而不包括完整的操作系统。这使得容器在启动和停止时更加快速，同时占用更少的资源。二、容器化技术的优势可移植性：容器化技术使得应用程序可以在不同的操作系统和平台上运行，无需担心环境差异。快速部署：容器化应用程序可以快速启动和停止，非常适合云计算环境和微服务架构。资源利用率高：由于容器共享底层操作系统资源，因此可以提高资源的利用率，降低硬件成本。易于管理和维护：容器化技术提供了标准化的应用程序打包和部署方式，使得应用程序的管理和维护更加简单。三、主流容器化工具Docker：Docker是目前最流行的容器化工具，它提供了丰富的功能和强大的生态系统，使得开发者可以轻松地创建、部署和管理容器。Kubernetes：Kubernetes是一个开源的容器编排系统，它可以帮助开发者自动化部署、扩展和管理容器化应用程序。四、容器化最佳实践保持容器轻量级：尽量将应用程序及其依赖项打包到一个容器中，避免将多个应用程序或服务打包到一个容器中。使用版本控制：对容器镜像进行版本控制，以便跟踪和管理不同版本的容器。安全性考虑：确保容器镜像的安全性，避免引入潜在的安全漏洞。同时，限制容器的权限，防止潜在的安全风险。持续集成和持续部署（CI/CD）：结合CI/CD工具，实现自动化构建、测试和部署容器化应用程序，提高开发效率。监控和日志收集：对容器化应用程序进行监控和日志收集，以便及时发现和解决问题。五、总结容器化技术为现代软件开发和部署带来了诸多优势，它提高了应用程序的可移植性、快速部署能力、资源利用率以及管理和维护的便捷性。掌握并应用容器化技术，将使开发者在构建高效、稳定、安全的软件系统方面更具竞争力。随着技术的不断发展，容器化技术将继续完善和优化，为未来的软件开发和部署提供更多可能性。我们期待看到更多创新性的应用和实践，共同推动容器化技术的发展。

开源之夏介绍开源之夏是由中国科学院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源软件社区的蓬勃发展，助力开源软件供应链建设。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，这个夏天，来自华为云的大咖导师将与您携手作战，一起推动云原生领域容器运行时技术的探索、创新和发展。

还在对集群成本评估感到束手无策？还在担心不合理的K8s集群资源浪费？华为云云原生全新上线云原生FinOps成本治理中心，为用户提供多维度集群成本可视化，结合智能规格推荐、混部、超卖等成本优化手段，助力客户降本增效。 4月24日（周三）16:30-18:00，华为云云原生DTSE技术布道师 Roc老师将带来《华为云云原生FinOps解决方案，为您释放云原生最大价值》直播分享。华为云云原生FinOps解决方案通过可视化的成本洞察和成本优化，帮助用户精细用云以提升单位成本的资源利用率，实现降本增效目标，本期直播通过云原生上云现状分析及华为云FinOps方案及实践解析，系统化解析华为云云原生一系列云原生FinOps技术 ，为企业与用户提供企业上云成本管理的最优路径。▍直播精彩看点企业上云现状与云原生FinOps优势华为云云原生FinOps解决方案云原生FinOps成本展示与成本分析云原生FinOps成本优化华为云CCE云原生成本治理功能演示▍直播观看平台华为云官网 华为云开发者联盟视频号、CSDN、B站、虎牙、微博华为云视频号、快手、B站、虎牙、微博▍看直播 赢定制礼品 福利1 | 专家坐堂有奖： 即日起-4月25日，在指定论坛贴提问，评选优质问题送华为云定制POLO衫。 福利2 | 互动有礼： 官网直播间发口令“华为云 DTSE”抽华为云定制雨伞。福利3 | 有奖提问：直播过程中提问，评选优质问题送华为云定制长袖卫衣。扫码体验华为云CCE获取华为云云原生FinOps方案▼▼▼

中奖结果公示感谢各位小伙伴参与本次活动，欢迎关注华为云DTSE Tech Talk 技术直播更多活动~本次活动获奖名单如下：请于4月30日下班前在此问卷中反馈您的中奖邮寄信息~直播简介【直播主题】华为云云原生FinOps解决方案，为您释放云原生最大价值【直播时间】2024年4月24日 16:30-18:00【直播专家】Roc 华为云云原生DTSE技术布道师【直播简介】还在对CCE集群成本评估感到束手无策？还在担心不合理的K8s集群资源申请和过度浪费？华为云容器服务CCE全新上线云原生FinOps中心，为用户提供多维度集群成本可视化，结合智能规格推荐、混部、超卖等成本优化手段，助力客户降本增效，释放云原生最大价值。观看直播：cid:link_1活动介绍【互动方式】直播前您可以在本帖留下您疑惑的问题，专家会在直播时为您解答。直播后您可以继续在本帖留言，与专家互动交流。我们会在全部活动结束后对参与互动的用户进行评选。【活动时间】即日起—2024年4月25日【奖励说明】评奖规则：活动1：直播期间在直播间提出与直播内容相关的问题，对专家评选为优质问题的开发者进行奖励。奖品：华为云定制长袖卫衣活动2：在本帖提出与直播内容相关的问题，由专家在所有互动贴中选出最优问题贴的开发者进行奖励。奖品：华为云定制POLO衫更多直播活动直播互动有礼：官网直播间发口令“华为云 DTSE”抽华为云定制雨伞等好礼。【注意事项】1、所有参与活动的问题，如发现为复用他人内容或直播间中重复内容，则取消获奖资格。2、为保证您顺利领取活动奖品，请您在活动公示奖项后2个工作日内私信提前填写奖品收货信息，如您没有填写，视为自动放弃奖励。3、活动奖项公示时间截止2024年4月30日，如未反馈邮寄信息视为弃奖。本次活动奖品将于奖项公示后30个工作日内统一发出，请您耐心等待。4、活动期间同类子活动每个ID（同一姓名/电话/收货地址）只能获奖一次，若重复则中奖资格顺延至下一位合格开发者，仅一次顺延。5、如活动奖品出现没有库存的情况，华为云工作人员将会替换等价值的奖品，获奖者不同意此规则视为放弃奖品。6、其他事宜请参考【华为云社区常规活动规则】。

3月21日，在巴黎举办的云原生顶级峰会KubeCon+CloudNativeCon Europe 2024上 ，华为云首席架构师顾炯炯在 “Cloud Native x AI：以持续开源创新开启智能时代” 的主题演讲中指出，云原生和AI技术的融合，是推动产业深刻变革的关键所在。华为云将持续进行开源创新，与开发者共启智能时代。  ▲华为云首席架构师顾炯炯发表演讲AI对于云原生范式提出关键挑战在过去的几年里，云原生彻底改变了传统的IT系统，催化了互联网和政府服务等领域的数字飞跃。云原生范式带来的新的可能性，例如闪电般的快速销售和基于微服务治理的敏捷应用DevOps，已经深入人心。同时，人工智能的快速发展和广泛采用，包括大规模模型，已经成为行业智能的跳动心脏。根据Epoch 2023年的调研数据，基础模型所需的计算能力每18个月就会增长10倍，是摩尔定理揭示的通用计算能力增长率的5倍。AI带来的新摩尔定律和大规模AI模型的主导地位对云原生范式提出了挑战，顾炯炯总结了其中关键的4点：首先，低GPU/NPU平均利用率导致AI训练和推理的高成本；其次，大模型训练集群频繁的失败率限制了训练效率；第三，大规模模型的复杂配置导致AI开发门槛高；第四，大规模的AI推理部署面临着不可预测的最终用户访问延迟和数据隐私问题的风险。华为云AI创新为开发者迎接挑战提供思路随着AI模型变得越来越大，对计算能力的需求也呈指数级增长。这种需求不仅给云原生技术带来了挑战，也为业界提供了创新机遇。顾炯炯分享了一些华为云在AI创新方面的故事，为开发者解决这些挑战提供了参考。在云原生边缘计算平台KubeEdge的基础上，华为云实现了一个云原生多机器人调度管理平台。用户可以通过自然语言命令在云端输入任务指令，由系统协调边缘的多个机器人共同协作完成复杂任务。为了克服自然语言命令理解、大量机器人高效调度管理以及跨类型机器人访问管理的三个挑战，该系统采用了云端、边缘节点和机器人三个部分的架构，通过大模型执行自然语言命令，并进行流量预测、任务分配和路由规划。这一架构显著提高了机器人平台的灵活性，管理效率提升25%，系统部署周期缩短30%，新机器人的部署时间从月级缩短到天级。中国某顶级内容分享社区，每月活跃用户超过1亿。它的核心服务之一是主页上的推荐功能。推荐模型有近1000亿个参数。训练集群有数千个计算节点。一个训练作业需要数百个参数服务器和worker。因此，该社区对最优拓扑调度、高性能、高吞吐量有着强烈的需求。开源项目Volcano可以更好地支持在Kubernetes上运行的AI/ML工作负载，并提供了一系列作业管理和高级调度策略。Volcano项目引入了拓扑感知调度、装箱、SLA感知调度等算法，帮助社区将整体训练性能提升了20%，运维复杂度也大大降低。Serverless AI引领云原生发展趋势如何高效、稳定地运行AI应用，同时降低运营成本，成为摆在众多企业和开发者面前的一大挑战。为此，华为云总结了云原生AI平台的关键要求，提出了一种全新的云原生AI平台理念——Serverless AI。顾炯炯提到，从开发者的视角来看，Serverless AI致力于智能地推荐并行策略，让复杂的训练和推理任务变得轻而易举。它提供自适应的GPU/NPU自动扩展功能，能够根据工作负载的实时变化动态调整资源分配，确保任务的高效执行。同时，Serverless AI还维护着一个无故障的GPU/NPU集群，让开发者无需担心硬件故障带来的中断风险。更值得一提的是，该平台保持与主流AI框架的兼容性，让开发者能够无缝集成现有的AI工具和模型。对于云服务提供商而言，Serverless AI同样具有深远的意义。它不仅能够提高GPU/NPU的利用率，使训练、推理和开发混合工作负载得以高效运行，还能通过优化能效实现绿色计算，降低能耗成本。此外，Serverless AI平台还能实现跨多个租户的空间和时间GPU/NPU共享，提高资源的复用率。最重要的是，它为训练和推理任务提供了有保证的QoS和SLA，确保了服务质量和稳定性。Serverless AI平台采用了构建在操作系统和虚拟化之上的灵活的资源调度层，将应用程序框架的关键功能封装于应用资源中介层中。顾炯炯现场展示了Serverless AI平台的参考架构。他认为，这种架构设计，使得Serverless AI平台具有了大规模AI资源自动驱动引擎的特点，包括精确了解应用资源利用模式的资源分析，实现异构硬件资源池化的资源共享，基于GPU/NPU虚拟化和负载热迁移的AI训练任务容错能力，以及提高资源利用率的多维度调度和自适应弹性伸缩等优点。分论坛上，华为云技术专家提到，Kubernetes上运行AI/ML工作负载的使用量不断增加，许多公司在分布于数据中心和各种GPU类型的多个 Kubernetes 集群上构建云原生AI平台。使用Karmada和Volcano，可轻松实现多集群的GPU工作负载智能调度、集群故障转移支持，在保障集群内和跨集群的两级调度一致性和效率，并平衡系统整体资源的利用率和不同优先级工作负载的QoS，以应对大规模、异构的GPU环境管理中面临的挑战。Karmada为多云和混合云场景中的多集群应用管理提供即时可用的自动化管理，越来越多的用户在生产环境中使用Karmada构建灵活高效的解决方案。Karmada已于2023年正式升级为CNCF孵化项目，期待与更多伙伴与开发者们共建繁荣社区。Volcano与主流AI/大数据框架实现了无缝集成，有效解决了AI/大数据任务的作业管理，资源分配，资源调度等问题与挑战，为业界提供了分布式作业训练的最佳实践。在大模型日新月异的今天，Volcano将持续发力，解决多集群AI任务调度等难题，助推大模型训练与推理快速发展。“云原生技术的敏捷性和异构AI计算平台的创新性，将是提升AI生产力的关键。” 顾炯炯谈到，未来，华为云将持续致力于开源创新，与业界同仁、伙伴共同开启智能时代的新篇章。更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

还在为K8s集群繁琐的资源管理投入大量的运维时间和人力？还在担心K8s集群节点伸缩不够及时或者不合理导致成本浪费？华为云Serverless K8s服务 CCE Autopilot通过资源全托管的方式让基础设施免运维，为用户节省运维成本，通过高效精准的弹性灵活应对业务的平峰和洪峰，为用户节省资源成本。3月13日16:30 -18:00，华为云云原生DTSE技术布道师颜栎将带来《CCE Autopilot：华为云容器全面进入“自动驾驶”时代 》直播分享。本期直播将聚焦企业集群运维痛点提供Serverless最新方案，系统化介绍华为云CCE Autopilot带来的全新集群服务体验。使用华为云CCE Autopilot进行集群节点全托管，无需配置和运维基础设施，帮你自动部署、扩展和管理容器化应用程序，高效构建业务，运维效率提升90%。华为云CCE Autopilot，应运而生的Serverless K8s服务资源设施全托管，节点免运维，降低运维成本，让用户聚焦业务创新；资源精益管理，通过FinOps提供成本治理能力，提升资源利用率，降低资源成本；业界领先弹性速度，4,000Pod/30s，高效弹，精准弹，灵活应对业务洪峰和平峰，实现稳敏双修；面向不同场景提供通用负载、SMB（中长尾）负载、AI负载、Batch负载的场景化调优能力；直播观看平台华为云官网 华为云开发者联盟视频号、CSDN、B站、虎牙、微博华为云视频号、快手、B站、虎牙、微博▍本期直播精彩看点CCE Autopilot，提供业务运行最优的云原生基础设施：1. 集群节点全面托管，基础设施自动升级。2.故障实时监测与自愈，漏洞自动修复。集群管理“无极变速”：1. 集群规格自动调整，取消规格档位限制。2. 资源使用“无级变速”，算力资源灵活规格档位，去Flavor化。智能弹性，动态感知业务特征，自动预测触发弹性华为云CCE Autopilot提供Serverless服务体验的同时，保留了用户对资源的可见性满足了部分客户对资源灵活管理的需求。此外，CCE Autopilot完全兼容K8s接口，及时跟随K8s社区动态，用户可以从普通的K8s集群平滑迁移到CCE Autopilot，立即省去节点运维投入。扫描下方二维码体验华为云CCE Autopilot▼▼▼