fluent-bit插件是否可以自定义配置？以及具体怎么进行操作

CCI的云原生cloudbursting有哪些计费方式？如何降低管理维护成本？

如何安装和配置Virtual Kubelet？具体操作流程是什么

如何降低CCI Pod与用户集群之间的带宽压力？

如果CCI Pod需要与其他Pod进行通信，需要如何配置和操作？

求助，华为云的CCE和Volcano插件，能一键部署并优化成本吗？

FinOps 支持cce集群是否包含所有类型集群，现在集群版本包含CCE Standard、CCE Turbo、CCE Autopilot。CCE Autopilot版本兼容性如何？

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

北京时间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开源之夏进入社区交流群