北京时间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进入技术群

Kurator 是华为云开源的面向分布式云原生环境的一站式解决方案。它利用 Karmada 作为多集群编排基础，内置集成了Istio、Prometheus、Thanos、Volcano、KubeEdge、Argo 等主流云原生技术。基于此，Kurator 构建了包括集群舰队管理、集群生命周期管理、统一应用分发、流量治理、监控和策略管理在内的分布式云平台管理能力。在最新 0.6.0 版本中，Kurator 为云原生应用增加了 CI/CD 流水线设置与管理功能，简化流水线创建。此外，强化了 0.4.0 版本发布的统一应用分发功能，可以在部署新应用时设置金丝雀（灰度）发布、A/B 测试、蓝绿发布三种渐进式发布策略。新增的流水线特性和渐进式发布功能与统一分发能力结合，实现基于代码仓库的 GitOps 工作流。这有助于快速构建分布式云原生平台，简化应用开发与发布流程。Kurator CI/CD 的结构图如下所示：用户更新代码仓库后，触发 Kurator 流水线，完成代码拉取、检查、编译并构建镜像。其后，用户更新应用部署模板，例如更改应用配置中的镜像信息。Kurator Application Controller 侦测到配置更新，将自动触发已应用的渐进式发布策略，实现应用的自动发布。如此一来，整个软件研发生命周期以代码为中心，实现开发至发布完整流程的自动化，简化运维、部署工作。  流水线  CI/CD 流水线实现源码到发布的自动化过程，包括源码管理、检查、测试等阶段。但由于每个阶段技术需求不同，导致流水线配置和管理难度大。Kurator 参考开源项目 Tekton，通过预定义常用任务模版的方式简化流水线创建操作。用户只需指定任务名称和代码仓库访问凭证即可创建流水线，使用门槛低。对熟悉流水线的高级用户，Kurator 也支持自定义任务。用户可以根据自己需求定制任务内容，满足个性化场景。通过预置任务模板和自定义任务的能力，Kurator 大幅简化了流水线配置和管理的难度。从图中可以看出，在使用流水线时，Kurator 完成了大部分工作。用户只需配置运行环境，选择任务模板即可完成流水线创建，大大减少学习成本。特别是与传统Tekton 相比，Kurator 提供了预定义任务模板，用户只关注任务内容而不再处理具体实现，实现了流水线使用的极致简化。除了简化流水线的创建操作外，Kurator 还考虑到了软件供应链安全，可以在流水线构建镜像时自动为其添加数字签名和源头证明，以防范假冒镜像，保证镜像源头可靠，保证在镜像制作方面的安全性。软件供应链安全指的是保护软件从开发到部署的整个生命周期过程中的安全性。软件供应链安全可以提高软件安全性能和用户信任度，预防恶意代码渗透。签名和证明添加后，镜像将自动上传至仓库。在镜像仓库中可以直接查看镜像签名和证明的详细情况，如图所示。用户可以用签名过程生成的公钥验证镜像签名和源头。这样在生产中,生产者仅需公布签名公钥，就能让用户验证数字签名和来源证明。接下来将展示一个在 Kurator 中创建一个流水线的示例：在流水线定义 spec.tasks 中指定任务名称，即可选择 Kurator 内置的常用任务模板。目前内置的常用任务模板包括:名称任务目标git-clone拉取源码go-test运行go代码单元测试go-lintgo源码静态检查build-and-push-image编译，构建镜像并上传此外，通过 customTask 定义可以发布自定义任务。通过指定 image、command 和 args,实现定制任务需求，如上述示例中自定义任务完成的工作就是打印README.md。更多的示例和细节，请参考: https://kurator.dev/docs/pipeline/  渐进式发布  金丝雀发布、A/B 测试和蓝绿发布都是主流的应用发布策略，可有效减少上线风险。Kurator 0.6.0 在原统一应用分发基础上，增加渐进式发布功能。现在应用可以指定三种渐进式发布策略中的一种策略。同时，可以将具备发布能力的统一分发，与 CI/CD 流水线结合起来，实现基于代码仓库的 GitOps 工作流。▍金丝雀发布金丝雀部署是一种渐进式发布策略。先向少数用户发布新的软件版本进行测试，根据测试结果，决定是否向更多用户推出新版本。旨在最大限度地减少新版本上线后对用户的影响，是一种更安全、更可靠的软件发布策略。参阅以下的操作示例，了解如何使用 Kurator 配置金丝雀发布。通过配置 rollout 中的 workload 字段，可以将金丝雀发布的目标设置为 webapp 命名空间下名为 backend 的应用。发布目标除了支持 deployment 应用之外，还支持 daemonSet应用。流量分析使用 Kurator 内置的请求成功率（request-sueccess-rate）和平均访问时延（request-duration）两个指标作为衡量新版本是否健康的标准。其中通过 thresholdRange 指定阈值。示例中要求请求成功率大99%，平均访问时延小于 500ms，新版本的服务才会被认定为健康。rolloutPolicy.canaryStrategy 配置了每次测试成功后，下次流量递增的比例和最终允许测试版本流量占比的最大值，从而实现渐进式发布新版本。示例中每次递增 10% 的流量流向新版本，最多为 50%。也可以设置 maxWeight 为 55，这样在最后一次测试的时候，只会新增 5% 的流量流向新版本。除了这些配置之外，Kurator 还可以设定完成验证之后，流量以什么样的比例逐步流向新版本。更多细节请参考: https://kurator.dev/docs/fleet-manager/rollout/canary/▍A/B测试A/B 测试为效果测试，是验证应用两版本表现的测试方法。它通过将用户分到不同组，每个组体验不同版本，然后分析每个组用户在使用过程中的各项指标，选择效果较好的版本。A/B 测试也可以先让部分用户试用新版本，收集真实环境下的用户反馈，再决定是否上线新版本。了解如何在 Kurator 配置应用的 A/B 测试，请参考下方操作示例。和金丝雀发布类似，由 workload 指定 A/B 测试的目标。通过 metric 指定测试的指标。A/B 测试和金丝雀发布不同的点在于需要配置 match 中的匹配规则，实现流量分组。上述 match 配置是只有 http 请求头满足使用 FireFox 浏览器或请求的 cookie 中包含 “type=insider” 的情况下，请求才会被转发到新版本。通过对不同请求头的处理达到对用户分组的效果，对不同的版本进行效果测试。除了匹配请求头之外，还能匹配 URI、端口号等。更多细节请参考: https://kurator.dev/docs/fleet-manager/rollout/abtest/▍蓝绿发布蓝绿发布是一种渐进零停机发布方法。它将生产环境分为两个独立运行的蓝绿环境,蓝环境承载当前实际流量，绿环境预部署新版本。新版本通过测试后,只需切换流量到绿环境，就能实现零停机升级。蓝环境备用支持回滚。通过实时扩容，可近乎零停机完成迭代交付，提高发布效率和用户体验。了解如何在 Kurator 配置蓝绿发布的操作示例，请参考下方。蓝绿发布需要配置目标应用、测试指标、迭代次数和容许测试失败的次数，其中测试的迭代次数由 analysisTimes 指定，容许测试失败的次数由 checkFailedTimes指定，除此之外无需配置别的规则。因为蓝绿发布在测试新版本的时候是将全局流量转发到绿环境中进行测试，没有金丝雀发布的渐进式流量递增和 A/B 测试的对用户分组的需求。更多细节请参: https://kurator.dev/docs/fleet-manager/rollout/blue-green/  未来展望  综上所述，通过 CI/CD 流水线和渐进式发布功能，Kurator 实现了从源码到发布的完整流水线自动化，真正提升了开发效率和运维能力，实现开发、配置和发布的应用全流程生命周期管理。此外还大幅简化了采用 CI/CD 流水线和渐进式发布的门槛。随着 Kurator 的不断迭代升级，我们还将继续为流水线添加更多的预定义任务模板，为渐进式发布提供更多的测试指标。欢迎大家试用 Kurator 并提出宝贵的意见与需求。Kurator的门户为：cid:link_0随着功能的逐渐完善，Kurator 将成为用户快速立体掌握云原生技术体系、高效运行分布式应用的强大工具。参考链接Kurator项目地址：cid:link_0CI/CD流水线：https://kurator.dev/docs/pipeline/软件供应链安全：https://kurator.dev/docs/pipeline/chain-security/渐进式发布：https://kurator.dev/docs/fleet-manager/rollout/金丝雀发布：https://kurator.dev/docs/fleet-manager/rollout/canary/A/B测试：https://kurator.dev/docs/fleet-manager/rollout/abtest/蓝绿发布：https://kurator.dev/docs/fleet-manager/rollout/blue-green/更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

源代码是企业最宝贵的资产之一，随着软件规模的不断扩大，企业管理庞大的源代码成为一个重大挑战。为了保持企业员工持续稳定地开展软件开发活动，一个好用的代码管理平台变得尤为重要。代码管理工具是软件开发的基础，能够帮助团队协作更加高效，自动化交付更加流畅。因此，选择一款优秀的代码管理平台能够有效提升团队协作效率和自动化交付效率，从而更好地满足企业的软件开发需求。本期 【云享问答】 通过这10个问题，带你全方位了解华为云CodeArts Repo代码托管带来的开发体验。💬 1、什么是代码托管？代码托管服务有什么优势？ 代码托管服务是基于Git的在线代码托管服务，具有安全高效、跨地域协同开发、代码浏览方便、集成工具、易于管理、易于合作、共享代码等优势。💬 2、开发者在选择代码托管服务时要注意哪些因素？ 选择代码托管服务时，需考虑多方面因素。首先要确保服务有足够的安全性和隐私性，防止代码泄露或损失。其次，性能和稳定性也至关重要，以确保代码的快速访问和修改。同时，成本、可扩展性也是选择的关键因素。另外，用户界面是否友好易用，集成工具是否丰富，也是开发者关注的重点。除此之外，良好的支持、活跃的社区以及符合项目需求和法律规定的政策和规定，也都为选择代码托管服务提供了重要参考。💬 3、华为云CodeArts Repo 与DevOps有什么不同？CodeArts Repo有哪些特性？华为云CodeArts Repo与DevOps的不同之处在于它们的目标和作用范围。DevOps是一种开发模式，强调开发人员和运维人员之间的紧密协作，以快速、高效地交付高质量的软件。而华为云CodeArts Repo是一种具体的工具，主要用于代码管理和协同开发，以支持DevOps实践。CodeArts Repo是华为云基于自主研发内核的一款代码管理工具，提供全方位的代码托管服务，沉淀了华为多年内部代码管理经验，助力企业高效协同开发与项目管理。其拥有六大特性，确保代码安全稳定高效开发，支持多种开发场景，提升代码质量并传递开发经验。通过质量门禁确保入库代码质量，双向可追溯记录代码来龙去脉，内置多种模板确保开发规范有序。💬 4、华为云代码托管的工作模式是什么？代码托管（CodeArts Repo）采用Git Flow作为基础工作模式。Git-Flow提供了一组建议，通过严格执行这些建议的规则，帮助中小型研发团队，能够更好的规范自己的开发工作。并行开发：各个特性与修复bug，可以并行；团队协作：多人开发过程中，大家都能够理解其他人的当前工作；灵活调整：通过hotfix分支，支持各种紧急修复的情况；master分支：最为稳定，功能比较完整，随时可发布的代码；develop分支：用于平时开发的主分支，并一直存在，永远是功能最新最全的分支，包含所有要发布到下一个release的代码，主要用于合并其他分支；feature分支：用于开发新的功能的分支，一旦开发完成，通过测试，合并回develop分支进入下一个release；release分支：用于发布准备的专门分支；hotfix分支：用于修复线上代码的bug 。💬 5、在开发者应用的过程中，CodeArts Repo对开发环境和版本的要求如何？  CodeArts Repo对开发环境和版本的要求，主要有三个方面：1、浏览器兼容：建议使用Chrome和Microsoft Edge，同时也支持IE10+、Firefox和Safari。2、分辨率：推荐1920*1080或更高。3、单个仓库规格：页面单文件上传≤10MB本地单文件推送≤200MB在线修改代码保存行数≤5000行仓库总容量≤2GB。  💬 6、CodeArts Repo适合哪些类型的企业和人群使用？CodeArts Repo主要适合开发人员、运维人员、项目管理人员和高校师生等人群使用。对于开发人员，它提供了代码托管、版本控制和代码检视等功能；对于运维人员，它确保了代码的安全和稳定性；对于项目管理人员，它支持多组织协同和权限控制；对于高校师生，它提供了完整的教学环境和丰富的代码仓库模板。💬 7、开发者在应用代码托管服务时，如何防止软件代码被他人Copy？  处理方法1：主要依赖于软件和监控手段来防止代码泄露封闭USB接口和蓝牙接口，防止外部数据传输；安装特殊软件，监控并限制上传行为；监控特定文件的上传，需注意防止文件改名、压缩、混淆后上传；监控上传到特定网站，需防止上传到未知网络服务、邮件地址、自建服务器；监控电脑操作并记录，但这种方式只能在代码泄露后作为证据，不能事前防范。处理方法2：采取更严格的硬件和访问控制  禁止个人笔记本和不明来源的IP地址，确保只有授权设备能访问；企业全面采用华为云的云电脑（云桌面）进行开发，确保代码只存储在云端；限制只有云桌面可以访问软件开发生产线帐户，其他IP地址不允许访问；所有代码只存储在云端，无法拷贝到外部，确保代码不被泄露。    💬 8、CodeArts Repo有哪些安全特性？在代码托管（CodeArts Repo）产品层面具有以下安全特性：基于角色与权限的细粒度授权：在CodeArts Repo层面，提供针对代码访问的，更加细粒度的授权模型；不可抵赖性：我们提供代码仓库的完整访问日志，供用户审计；数据加密：用户的代码在CodeArts Repo中，是以加密方式存储的。  💬 9、CodeArts Repo如何确保代码安全？CodeArts Repo通过安全管理，合并请求和提交规则管理确保代码安全：合并请求和提交规则管理，保证代码上传质量；部署密钥和IP白名单，控制代码上传下载权限；在代码仓库中显示代码的界面增加水印，降低代码资产泄露风险，保证代码安全；审计日志，动态保证可追踪性；锁定仓库，保证版本确定性，防止未经授权的代码提交。💬 10、在应用的过程中，CodeArts Repo是如何解决较为严重的IO负载问题的？可以通过规避大量的上传和下载来解决，解决方式如下： 1、识别已经上传过的，不进行二次上传操作，减少上传次数。2、读写分离，规避频繁上传下载。3、Hash分片存储。更多关于CodeArts Repo的功能，可进入产品官网免费开通基础版使用