企业软件开发困局随着信息化的进程不断加速，带来的各种业务应用、平台应用等软件资产的复杂度也快速上升。随之而来的信息化基础设施能力与软件工程全生命周期的管理也会变得越来越复杂，数字化转型、云原生、持续交付的口号随之升起。千行百业都在响应数字化转型的号召以提升业务效率、企业竞争力或是市场竞争力。但是企业在转型的过程中却举步维艰。往往原因有以下几点：流程固化，牵一发而动全身：原有的流程已经制定多年，相关人员也已经习惯这套流程。突然的规则转变以及带来的相关风险无人愿意主动承担。部门墙明显，无法快速协同：在金融等行业中，每个部门的成员往往都是统一职责的。如业务部门，只负责市场运营、项目需求管理等；研发部门，只负责开发以及测试；运维部门，只负责平台的运维、基础设施的维护等。一个业务软件的版本迭代，需要从多个部门层层流转，但部门与部门之间的沟通又不彻底，出现问题也容易互相牵扯，最终导致软件需求交付效率的大大下降。严谨的网络环境管理却又松散的制品管理：网络部门严格管理着各个环境之间的网络访问逻辑，一般情况下，开发人员只能访问开发环境；而且开发、测试、准生产以及生产环境之间网络都是不互通的。在没有强有力的政策干预下，可能会出现各个环境都独立一套代码、制品仓库，更糟糕的是，可能不同的软件产品线都独立管理各自的代码、制品仓库。因此在阶段流转时，需要通过传统的拷贝方式去做流转传递，带来了额外的管理成本，也更容易引入人为风险。过多的编外人员带来的各种散乱工具链：在软件研发部门可能存在多方外包人员，而每一方外包人员都有各自熟悉的软件开发工具，代码仓库有些使用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方案▼▼▼

开源之夏介绍开源之夏是由中国科学院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源软件社区的蓬勃发展，助力开源软件供应链建设。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方案▼▼▼

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进入技术群

更多云原生技术动向关注容器魔方添加小助手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▼▼▼

全球顶级开源组织云原生计算基金会(Cloud Native Computing Foundation，简称 CNCF)正式宣布其2024年技术监督委员会(Technical Oversight Committee，简称CNCF TOC)席位，华为云云原生开源负责人王泽锋，凭借其在CNCF领域长期卓越的贡献成功当选，成为本届 CNCF TOC 11位技术领军人物之一。CNCF致力于云原生技术的普及和可持续发展，汇集世界顶级厂商，发展至今会员单位已超过750+。CNCF技术监督委员会是CNCF的核心决策团队，为云原生社区提供技术领导，决定CNCF社区的技术走向，由董事会、Maintainer以及End User等多个选区投票产生。一直以来，CNCF TOC主要以欧美专家为主，本届选举中，华为云开源专家王泽锋获得CNCF Maintainer广泛支持，凭借Maintainer选区最高票当选新一届CNCF TOC委员（2024-2026任期）。这也标志着其个人及华为在云原生领域的持续贡献获得产业界的高度认可，代表了整个中国本土贡献者在国际舞台上开源影响力的新高度。云原生产业规模和前景巨大，不少技术领域仍然处于窗口期，可谓机遇与挑战并存。王泽锋表示：“中国在全球云原生产业发展中拥有非常明显的优势：巨大的数字经济规模、丰富的应用场景，不断推动技术层面的创新；不少本土科技公司凭借技术实力已在云原生的核心赛道中占据了重要位置。作为CNCF TOC的新任成员，我将致力于更好地联接国内以及国际开源社区，借助CNCF、华为等平台及资源，携手更多企业、开源组织、学术机构及广大开发者一起，共同推动云原生技术发展与产业标准化，赋能千行万业的数字化转型。”王泽锋：协作创新，共建更有生命力的开源社区作为最早来自中国的Kubernetes维护者之一，王泽锋早在2014年基于 Upstream first 的理念，参与 Kubernetes 上游社区贡献，并于2015年成为了国内最早的 Kubernetes maintainer 之一，其主导的 Kubernetes 社区的多个关键特性和子项目的设计研发工作在社区完成开发后被大量企业用户在生产环境中广泛使用；与此同时，他指导了超过30名开发人员成为Kubernetes和其他CNCF项目的业务骨干、核心开发者。2018 年，王泽锋与同事联合创立了业界首个云原生边缘计算项目KubeEdge 开源项目，并捐赠到 CNCF 基金会，通过开放社区的治理模式与业界开发者协作共享。KubeEdge 也因此成为 CNCF 第一个将云原生技术应用到边缘计算的开源项目。时至今日，KubeEdge 在交通、能源、通信、金融、工业制造、CDN、智慧园区等各行各业已经有了更加深广的应用和普惠价值。此外，他还发起了 Volcano云原生批量计算 、Karmada云原生多集群管理 等多个云原生开源项目，填补了云原生技术在相关领域的技术空白。作为CNCF中国大使，王泽锋在KubeCon + CloudNativeCon 程序委员会任职多年，并于 2023 年担任 KubeCon + CloudNativeCon China 联合主席。作为公认的演讲者，王泽锋多次在 KubeCon Europe 和 KubeCon China 上发表Keynote和分论坛议题演讲。此外，王泽锋一直是Kubernetes贡献者峰会的长期支持者，联合规划和组织多场KCS China、KCD，并从2018年开始，联合策划了 “Cloud Native Days China”系列 Meetup、“Cloud Native Lives”等一系列业内活动；与此同时，由他发起的系列云原生技术公共课程，帮助超过百万的中国开发者构筑云原生技术交流平台，学习和采用云原生技术。技术先驱，引领全球云原生生态圈作为CNCF亚洲唯一创始成员、白金成员，华为对 Kubernetes、Istio 等社区核心项目的贡献一直位居全球前列，社区影响力持续多年亚洲第一，加速了云原生技术从起步到成熟的过程；华为拥有10余位CNCF项目核心Maintainer，出版多部云原生领域技术书籍，是全球云原生开源技术的领导者之一。近年来，华为持续开源创新，先后向CNCF捐献业界首个云原生边缘计算项目KubeEdge、首个云原生算力调度引擎Volcano、首个多云容器编排引擎Karmada等重量级云原生项目，在网络、边缘、调度、多云等技术领域形成了相对成熟生态圈，并开源了Kurator、Kappital、Kuasar、Kmesh等创新项目，加速了云原生与边缘计算、AI、大数据等产业的融合。共享开源价值，为行业发展注入源生动力在数字经济快速演进的大背景下，开源作为数智化转型的创新驱动力，不断催生技术突破和业务创新，发挥出愈加凸显的价值。华为与业界分享生产实践经验及创新成果，与国际云原生社区共发展。未来，面向全球的云原生社区工作有何创新？王泽锋提出了他对CNCF TOC的愿景和其独特的价值：促进跨区域新贡献者和现有贡献者之间的经验分享和沟通。建立公共的维护者地图，帮助新加入的贡献者找到周围的维护者以获得支持和帮助，以新一代的维护者增进社区活力，促进项目的可持续性。建立项目导师和项目冠军机制，帮助加快新开源项目向CNCF的申请/引导过程，以及项目在CNCF沙盒和孵化器中的成长。更清晰的项目推进过程和相应的自动化工具，以减少项目维护者和TOC/TAG成员在观察和评估项目健康和项目成熟度方面所花费的时间。云原生+AI，开源加速构建AI基础设施面对AI时代迎面而来的挑战，华为云在云原生领域持续引领，打造多云场景下的AI云原生基础设施，加速构建AI时代最佳云底座。作为全球最早参与CNCF重点项目产品化的企业之一，华为云早在2015年基于Kubernetes、Istio等上游社区，推出了国内最早的商用容器产品，并于2016年发布国内首个公有云容器服务CCE（云容器引擎）。伴随华为云近年来的高速发展，目前华为云已经陆续发布Serverless容器CCI、应用服务网格ASM、智能边缘平台IEF、分布式云原生UCS等多个创新产品，连续七次登顶IDC发布的中国容器市场份额报告，这也是业界对华为云在容器领域一路领先给与的充分肯定。智能浪潮新形势下，华为云结合在云原生领域的领先优势，打造云原生多云融合基础设施，云原生AI基础设施，云原生Serverless基础设施等系列解决方案，陆续升级发布华为云CCE Turbo，华为云CCE Autopilot，Serverless云耀云容器等创新产品。由华为云开源并捐赠至CNCF的孵化级开源项目也在AI云边协同、AI混部调度、多集群算力分配等技术领域加速行业产品应用升级，为行业智能升级攻坚克难，注入源生动力。未来，华为云云原生将持续与全球开发者紧密合作，共同推进云原生技术的创新与发展，积极推动云原生技术在产业领域的深度融合应用，为促进全球数智化经济的繁荣发展贡献力量。更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

作者：本文由华为云客户迷你玩投稿背景迷你玩旗下《迷你世界》是一款国产沙盒创意平台，拥有全球数千万创作者进行去中心化内容创作，通过方块组合自由创造等方式，引导用户在平台上创作虚拟作品。2021《迷你世界》的每月活跃玩家人数已超过一亿。《迷你世界》此前面临的突出问题在于服务端的弹性：迷你世界服务器的规格较大，每个服务器上承载了很多游戏服进程，不同玩家的游戏时间上差异也比较大，为了保障深度玩家的游戏体验，即使只有一个玩家还在进行游戏，对应的游戏服务器也是不会缩容的，这必然会影响服务端整体的资源利用率和运营成本。我们期望通过容器灵活规格来解决《迷你世界》服务端的缩容问题，同时提升整个游戏系统的扩缩容、部署升级效率。挑战云原生技术以其灵活性、可扩展性和可维护性等优势，正在迅速改变企业的 IT 架构。第三方报告显示，2022年已经有超过75%的互联网公司在基于K8s部署生产业务，预期2025年这个数字将超过90%。然而在游戏场景中，k8s的还面临一些局限性。首先，游戏业务天然是有状态的，K8S原生的有状态资源StatefulSet并不擅长处理大量的、复杂的状态管理任务。其次，时延敏感性也是一个问题。在游戏中，时延直接影响到游戏的流畅度和玩家的体验，这就对K8s的容器网络实现提出了更高的要求。同时，安全性也是一个挑战。游戏服中可能包含大量的敏感信息，普通容器的隔离程度与虚拟化相比仍有一定差距。解决方案华为云CCE在网络、容器运行时上进行了增强，再配合社区workload，使能《迷你世界》后端全栈容器化，资源使用量较虚拟化部署环境减少了50+%。整体架构如下：网络方面，华为云CCE Turbo提供了一种更接近虚拟机的容器网络，这种模式下，容器成为和虚拟机等同的“一等公民”。容器网卡集成了虚拟网络的能力，比如通过CRD关联到安全组进行安全加固，更细粒度的IP地址管理等。更重要的是，这种容器网络支持Pod直接关联EIP，用户可以直接通过EIP访问应用。EIP的成本管理上，华为云提供了95计费的共享带宽，以多个EIP共享的带宽为计费单元。我们开发了专门的K8s webhook为不同的pod分配不同的共享带宽，来做到最优的成本控制。有状态应用管理方面：我们使用了OpenKruise社区的CloneSet来管理游戏服pod。CloneSet提供了pod的原地升级能力，可以在不重建pod的情况下对运行中的容器进行更新。我们还深度使用了它的定向缩容能力，通过自定义Hooks判断指定游戏服pod是否有活跃玩家，实现对游戏服缩容的精细化控制。OpenKurise的CRD配合控制器的模式在不同的K8s环境中具有良好的扩展性，只要厂商提供社区一致的API，均可正常部署运行。安全方面，当前我们的使用方式是服务端Pod与节点1:1部署，游戏服pod配置关联指定安全组，通过安全组和虚拟化对游戏服进行双重安全加固。效果《迷你世界》完成全量容器化后，在运维效率、资源成本都有了显著优化资源占用节省50%计算资源根据游戏的实施访问量自动管理，定时弹性伸缩配合指标触发的自动弹性伸缩，再加上定向缩容，资源总是能伸缩至合理水平，保障玩家的游戏体验。迭代效率提升容器化缩短了应用的迭代周期，通过灰度发布，流量治理等保证了业务平滑稳定升级，应用升级从小时级提升至分钟级。迷你玩和华为云在未来将Serverless领域加深合作：华为云容器实例服务CCI具有秒级弹性、按量计费的特性，非常贴合我们的应用场景。此外，华为云CCE提供弹性突发引擎，可以将CCI资源池以虚拟节点的方式接入CCE。基于这项能力，我们仅需将与节点强绑定的部分资源稍作调整即可将应用部署到Serverless容器服务中，进一步提升后端的弹性能力。同时CCI基于安全容器构建，独享内核，具有虚拟机级别的安全保障。下一阶段，我们考虑将部分负载逐步迁移到Serverless容器上。

北京时间2024年1月23日，KubeEdge 发布 1.16.0 版本。新版本新增多个增强功能，在集群升级、集群易用性、边缘设备管理等方面均有大幅提升。KubeEdge v1.16.0 新增特性：集群升级：支持云边组件自动化升级支持边缘节点的镜像预下载支持使用 Keadm 安装 Windows 边缘节点增加多种容器运行时的兼容性测试EdgeApplication 中支持更多 Deployment 对象字段的 Override支持基于 Mapper-Framework 的 Mapper 升级DMI 数据面内置集成 Redis 与 TDEngine 数据库基于 Mapper-Framework 的 USB-Camera Mapper 实现易用性提升：基于 Keadm 的部署能力增强升级 K8s 依赖到 v1.27  新特性概览 ▍集群升级：支持云边组件自动化升级随着 KubeEdge 社区的持续发展，社区版本不断迭代；用户环境版本升级的诉求亟需解决。针对升级步骤难度大，边缘节点重复工作多的问题，v1.16.0 版本的 KubeEdge 支持了云边组件的自动化升级。用户可以通过 Keadm 工具一键化升级云端，并且可以通过创建相应的 Kubernetes API，批量升级边缘节点。云端升级云端升级指令使用了三级命令与边端升级进行了区分，指令提供了让用户使用更便捷的方式来对云端的 KubeEdge 组件进行升级。当前版本升级完成后会打印 ConfigMap 历史配置，如果用户手动修改过 ConfigMap，用户可以选择通过历史配置信息来还原配置文件。我们可以通过 help 参数查看指令的指导信息：keadm upgrade cloud --help Upgrade the cloud components to the desired version, it uses helm to upgrade the installed release of cloudcore chart, which includes all the cloud components Usage: keadm upgrade cloud [flags] Flags: --advertise-address string Please set the same value as when you installed it, this value is only used to generate the configuration and does not regenerate the certificate. eg: 10.10.102.78,10.10.102.79 -d, --dry-run Print the generated k8s resources on the stdout, not actual execute. Always use in debug mode --external-helm-root string Add external helm root path to keadm --force Forced upgrading the cloud components without waiting -h, --help help for cloud --kube-config string Use this key to update kube-config path, eg: $HOME/.kube/config (default "/root/.kube/config") --kubeedge-version string Use this key to set the upgrade image tag --print-final-values Print the final values configuration for debuging --profile string Sets profile on the command line. If '--values' is specified, this is ignored --reuse-values reuse the last release's values and merge in any overrides from the command line via --set and -f. --set stringArray Sets values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --values stringArray specify values in a YAML file (can specify multiple)升级指令样例：keadm upgrade cloud --advertise-address= --kubeedge-version=v1.16.0边端升级v1.16.0版本的KubeEdge支持通过 NodeUpgradeJob 的 Kubernetes API 进行边缘节点的一键化、批量升级。API 支持边缘节点的升级预检查、并发升级、失败阈值、超时处理等功能。对此，KubeEdge 支持了云边任务框架。社区开发者将无需关注任务控制、状态上报等逻辑实现，只需聚焦云边任务功能本身。升级 API 样例：apiVersion: operations.kubeedge.io/v1alpha1 kind: NodeUpgradeJob metadata: name: upgrade-example labels: description: upgrade-label spec: version: "v1.16.0" checkItems: - "cpu" - "mem" - "disk" failureTolerate: "0.3" concurrency: 2 timeoutSeconds: 180 labelSelector: matchLabels: "node-role.kubernetes.io/edge": "" node-role.kubernetes.io/agent: ""兼容测试KubeEdge 社区提供了完备的版本兼容性测试，用户在升级时仅需要保证云边版本差异不超过 2 个版本，就可以避免升级期间云边版本不一致带来的问题。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5330https://github.com/kubeedge/kubeedge/pull/5229https://github.com/kubeedge/kubeedge/pull/5289▍支持边缘节点的镜像预下载新版本引入了镜像预下载新特性，用户可以通过 ImagePrePullJob的 Kubernetes API 提前在边缘节点上加载镜像，该特性支持在批量边缘节点或节点组中预下载多个镜像，帮助减少加载镜像在应用部署或更新过程，尤其是大规模场景中，带来的失败率高、效率低下等问题。镜像预下载API示例：apiVersion: operations.kubeedge.io/v1alpha1 kind: ImagePrePullJob metadata: name: imageprepull-example labels: description:ImagePrePullLabel spec: imagePrePullTemplate： images: - image1 - image2 nodes： - edgenode1 - edgenode2 checkItems: - "disk" failureTolerate: "0.3" concurrency: 2 timeoutSeconds: 180 retryTimes: 1 更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5310https://github.com/kubeedge/kubeedge/pull/5331▍支持使用 Keadm 安装 Windows 边缘节点KubeEdge 1.15.0 版本实现了在 Windows 上运行边缘节点，在新版本中，我们支持使用安装工具 Keadm 直接安装 Windows 边缘节点，操作命令与 Linux 边缘节点相同，简化了边缘节点的安装步骤。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/4968▍增加多种容器运行时的兼容性测试新版本中新增了多种容器运行时的兼容性测试，目前已集成了containerd，docker，isulad 和 cri-o 4种主流容器运行时，保障 KubeEdge 版本发布质量，用户在安装容器运行时过程中也可以参考该PR中的适配安装脚本。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5321▍EdgeApplication 中支持更多 Deployment 对象字段的 Override在新版本中，我们扩展了 EdgeApplication 中的差异化配置项（overriders），主要的扩展有环境变量、命令参数和资源。当您不同区域的节点组环境需要链接不同的中间件时，就可以使用环境变量（env）或者命令参数（command, args）去重写中间件的链接信息。或者当您不同区域的节点资源不一致时，也可以使用资源配置（resources）去重写cpu和内存的配置。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5262https://github.com/kubeedge/kubeedge/pull/5370▍支持基于Mapper-Framework的 Mapper 升级1.16.0 版本中，基于 Mapper 开发框架 Mapper-Framework 构建了 Mapper 组件的升级能力。新框架生成的 Mapper 工程以依赖引用的方式导入原有 Mapper-Framework 的部分功能，在需要升级时，用户能够以升级依赖版本的方式完成，简化 Mapper 升级流程。Mapper-Framework 代码解耦:1.16.0 版本中将 Mapper-Framework 中的代码解耦为用户层和业务层。用户层功能包括设备驱动及与之强相关的部分管理面数据面能力，仍会随 Mapper-Framework 生成在用户 Mapper 工程中，用户可根据实际情况修改。业务层功能包括 Mapper向云端注册、云端下发Device列表等能力，会存放在kubeedge/mapper-framework 子库中。Mapper 升级框架:1.16.0 版本 Mapper-Framework 生成的用户 Mapper 工程通过依赖引用的方式使用 kubeedge/mapper-framework 子库中业务层功能，实现完整的设备管理功能。后续用户能够通过升级依赖版本的方式达到升级 Mapper 的目的，不再需要手动修改大范围代码。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5308https://github.com/kubeedge/kubeedge/pull/5326▍DMI 数据面内置集成 Redis 与TDEngine数据库1.16.0 版本中进一步增强 DMI 数据面中向用户数据库推送数据的能力，增加 Redis 与 TDengine 数据库作为内置数据库。用户能够直接在 device-instance 配置文件中定义相关字段，实现 Mapper 自动向 Redis 与 TDengine 数据库推送设备数据的功能，相关数据库字段定义为：type DBMethodRedis struct { // RedisClientConfig of redis database // +optional RedisClientConfig *RedisClientConfig `json:"redisClientConfig,omitempty"` } type RedisClientConfig struct { // Addr of Redis database // +optional Addr string `json:"addr,omitempty"` // Db of Redis database // +optional DB int `json:"db,omitempty"` // Poolsize of Redis database // +optional Poolsize int `json:"poo lsize,omitempty"` // MinIdleConns of Redis database // +optional MinIdleConns int `json:"minIdleConns,omitempty"` }type DBMethodTDEngine struct { // tdengineClientConfig of tdengine database // +optional TDEngineClientConfig *TDEngineClientConfig `json:"TDEngineClientConfig,omitempty"` } type TDEngineClientConfig struct { // addr of tdEngine database // +optional Addr string `json:"addr,omitempty"` // dbname of tdEngine database // +optional DBName string `json:"dbName,omitempty"` }更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5064▍基于Mapper-Framework的USB-Camera Mapper实现基于KubeEdge 的 Mapper-Framework，新版本提供了 USB-Camera 的 Mapper 样例，该 Mapper 根据 USB 协议的 Camera 开发，用户可根据该样例和 Mapper-Framework 更轻松地开发具体业务相关的 Mapper。在样例中提供了 helm chart 包，用户可以通过修改 usbmapper-chart/values.yaml 部署 UBS-Camera Mapper，主要添加 USB-Camera 的设备文件, nodeName, USB-Camera 的副本数，其余配置修改可根据具体情况而定，通过样例目录中的 Dockerfile 制作 Mapper 镜像。global: replicaCounts: ...... cameraUsbMapper: replicaCount: 2 #USB-Camera的副本数 namespace: default ...... nodeSelectorAndDevPath: mapper: - edgeNode: "edgenode02" #USB-Camera连接的缘节点nodeName devPath: "/dev/video0" #USB-Camera的设备文件 - edgeNode: "edgenode1" devPath: "/dev/video17" ...... USB-Camera Mapper 的部署命令如下：helm install usbmapper-chart ./usbmapper-chart更多信息可参考：https://github.com/kubeedge/mappers-go/pull/122▍易用性提升：基于 Keadm 的部署能力增强添加云边通信协议配置参数在 KubeEdge v1.16.0 中，使用keadm join边缘节点时，支持使用--hub-protocol 配置云边通信协议。目前 KubeEdge 支持 websocket 和 quic 两种通信协议，默认为 websocket 协议。命令示例：keadm join --cloudcore-ipport <云节点ip>:10001 --hub-protocol=quic --kubeedge-version=v1.16.0 --token=xxxxxxxx说明：当--hub-protocol设置为 quic 时，需要将--cloudcore-ipport的端口设置为10001，并需在CloudCore的ConfigMap中打开quic开关，即设置modules.quic.enable为true。操作示例：使用 kubectl edit cm -n kubeedge cloudcore，将 quic 的 enable 属性设置成 true，保存修改后重启 CloudCore的pod。modules： ...... quic: address: 0.0.0.0 enable: true #quic协议开关 maxIncomingStreams: 10000 port: 10001 ......更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5156keadm join 与 CNI 插件解耦在新版本中，keadm join边缘节点时，不需要再提前安装 CNI 插件，已将边缘节点的部署与 CNI 插件解耦。同时该功能已同步到 v1.12 及更高版本，欢迎用户使用新版本或升级老版本。说明：如果部署在边缘节点上的应用程序需要使用容器网络，则在部署完 EdgeCore 后仍然需要安装 CNI 插件。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5196▍升级 K8s 依赖到 v1.27新版本将依赖的 Kubernetes 版本升级到 v1.27.7，您可以在云和边缘使用新版本的特性。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5121  版本升级注意事项  新版本我们使用 DaemonSet 来管理边端的 MQTT 服务 Eclipse Mosquitto 了，我们能够通过云端 Helm Values 配置来设置是否要开启 MQTT 服务。使用 DaemonSet 管理 MQTT 后，我们可以方便的对边端 MQTT 进行统一管理，比如我们可以通过修改 DaemonSet 的配置将边端 MQTT 替换成 EMQX。但是如果您是从老版本升级到最新版本，则需要考虑版本兼容问题，同时使用原本由静态 Pod 管理的 MQTT 和使用新的 DaemonSet 管理的 MQTT 会产生端口冲突。兼容操作步骤参考：1、您可以在云端执行命令，将旧的边缘节点都打上自定义标签kubectl label nodes --selector=node-role.kubernetes.io/edge without-mqtt-daemonset=""2、您可以修改 MQTT DaemonSet 的节点亲和性nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - ... - key: without-mqtt-daemonset operator: Exists3、将节点 MQTT 改为由 DaemonSet 管理# ------ 边端 ------ # 修改/lib/systemd/system/edgecore.service，将环境变量DEPLOY_MQTT_CONTAINER设置成false # 这步可以放在更新EdgeCore前修改，这样就不用重启EdgeCore了 sed -i '/DEPLOY_MQTT_CONTAINER=/s/true/false/' /etc/systemd/system/edgecore.service # 停止EdgeCore systemctl daemon-reload && systemctl stop edgecore # 删除MQTT容器，Containerd可以使用nerdctl替换docker docker ps -a | grep mqtt-kubeedge | awk '{print $1}' | xargs docker rm -f # 启动EdgeCore systemctl start edgecore # ------ 云端 ------ # 删除节点标签 kubectl label nodes without-mqtt-daemonset新版本的 keadm join 命令会隐藏 with-mqtt 参数，并且将默认值设置成 false，如果您还想使用静态 Pod 管理 MQTT，您仍然可以设置参数--with-mqtt来使其生效。with-mqtt 参数在 v1.18 版本中将会被移除。  致谢  感谢 KubeEdge 社区技术指导委员会(TSC)、各 SIG 成员对 v1.16.0 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_0更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群