我们非常高兴地宣布 Kmesh v0.5.0 的发布。首先，感谢我们的贡献者在过去两个月中的辛勤工作。在 v0.5.0 版本中，我们进行了许多重要的增强，包括命令行工具 kmeshctl、更全面的端到端测试覆盖、底层 eBPF 信息的可视化改进、可观测性增强、完整的重启支持、CNI 安装程序的改进以及 XDP 程序中的 RBAC 支持。此外，在本次发布周期中，我们修复了许多关键的 Bugs，重构了部分关键代码，并增加了更多测试覆盖，使 Kmesh 更加稳定和健壮。  Kmesh背景回顾  尽管以 Istio 为代表的服务网格在过去几年得到了广泛的关注并取得了显著的知名度，但 Istio 社区曾经重点推广的 Sidecar 模式在资源开销和数据链路延迟等方面会对工作负载产生显著影响，因此用户在选择落地方案时仍然相对谨慎。此外，Sidecar 模式的一个主要缺点是其与业务容器的生命周期强绑定，无法独立进行升级。为了解决这些问题，Kmesh 创新性地提出了基于内核的无 Sidecar 流量治理方案，将流量治理下沉至内核层面。当前Kmesh支持“Kernel-Native”和“Dual-Engine”两种模式。对于“Kernel-Native”模式，由于 eBPF 技术非常适合四层流量治理，并且结合可编程内核模块，可以实现七层流量编排。Kmesh 最初完全依赖 eBPF 和内核模块来实现 L4-L7 的治理。Kmesh 采用随流治理策略，不会在服务通信过程中增加额外的连接跳数，与 Sidecar 模式相比，服务之间的通信连接数从三条减少至一条。“Kernel-Native”模式的架构图如下：同时，为了增强七层协议的治理能力，今年 Kmesh 引入了一种新的治理模式——“Dual-Engine”模式，利用 eBPF 将流量转发到 kmesh-waypoint 进行高级的七层协议治理。这是一种更灵活的分层治理模型，能够按需满足不同用户的多样化需求。  Kmesh 0.5版本关键特性解析  Kmesh重启时的零停机时间现在，Kmesh 可以在重启后优雅地重新加载 eBPF Map 和程序，且不需要在重启后重新注册命名空间或特定 Pod。这意味着在重启期间，流量不会中断，这对用户来说是一个巨大的好处。在 kmesh-daemon 重启后，eBPF Map 配置将自动更新为最新状态。如上图所示通过将 eBPF程序 pin 在内核目录上，kmesh 关闭后 eBPF 依然可以正常对流量进行治理，保证 kmesh 重启过程中服务不中断。在 kmesh 重启后，将 bpf_map 中存放的 config 与最新获取的 config 作对比，将 bpf_map 中的 config 更新至最新。在 v0.4.0 版本中，Kmesh 重启后需要重新启动所有由 Kmesh 管理的 Pod，以便重新管理，因为该管理是由 CNI 插件触发的。现在这一过程已在 kmesh-daemon 中完成，因此 Pod 不需要重新启动即可重新管理。可观测性增强现在，Kmesh 支持 L4 访问日志，使用户能够清晰地可视化 Kmesh 管理的流量。请注意，访问日志默认未启用。您可以通过修改 Kmesh 中  spec.containers.args 的 --enable-accesslog 参数来启用访问日志功能。我们还将支持使用 kmeshctl 动态启用访问日志。访问日志的示例如下：accesslog: 2024-09-14 08:19:26.552709932 +0000 UTC src.addr=10.244.0.17:51842, src.workload=prometheus-5fb7f6f8d8-h9cts, src.namespace=istio-system, dst.addr=10.244.0.13:9080, dst.service=productpage.echo-1-27855.svc.cluster.local, dst.workload=productpage-v1-8499c849b9-bz9t9, dst.namespace=echo-1-27855, direction=INBOUND, sent_bytes=5, received_bytes=292, duration=2.733902ms其中各个字段的含义为：同时，为 Kmesh 适配的 Grafana 插件也已添加，以便更好地可视化各维度的监控指标。此外，可观测性方面的一些关键问题已得到修复，有效提高了其准确性和稳定性。将授权执行下沉到XDP程序中在 v0.3.0 版本中，Kmesh 已支持 L4 RBAC，但之前的解决方案是在用户空间中进行 RBAC，这在性能和功能上存在一些问题。现在我们已将其下沉到 XDP eBPF 中，这项功能将真正可用。目前，鉴权规则已转移到 eBPF Map中，这使得能够完全在 eBPF 程序中执行授权。当授权结果为拒绝时，XDP 程序会直接丢弃请求数据包，从而使客户端能够检测到连接失败。下沉到 XDP 程序的关键是使用了 eBPF 的 tail-call 机制，将不同的匹配规则通过 tail-call 串联起来，遵循了原先在用户空间进行鉴权的逻辑。如上图所示，集群内配置的鉴权规则通过消息订阅机制，被写入 eBPF Map。Pod 上入方向的流量在建链时，会在 XDP 程序中进行鉴权规则匹配，如果鉴权结果为拒绝，则包被丢弃；如果鉴权结果为允许，则流量将通过协议栈发送到对应的 App 进程。更好的调试能力我们新增了命令行工具 kmeshctl！现在，您无需进入相应的 Kmesh 守护进程 Pod 来调整 Kmesh 守护进程的日志级别或转储配置。您可以直接使用 kmeshctl：# 调整 kmesh-daemon 日志级别（例如，debug | error | info） kmeshctl log kmesh-6ct4h --set default:debug # 转储配置 kmeshctl dump kmesh-6ct4h workload未来将为 kmeshctl 添加更多功能，以便用户更好地管理和调试 Kmesh。更好的底层BPF Map可视化之前我们有接口 /debug/config_dump/ads 和 /debug/config_dump/workload 来输出 Kmesh 守护进程中缓存的配置内容。由于各种原因，Kmesh 守护进程缓存中的配置与实际的 eBPF 可能并不完全一致。如果我们能获取阅读友好的 eBPF 信息，将更有助于我们进行故障排查。现在，我们可以通过接口 /debug/bpf/* 获取这些信息。这些信息也将被集成到 kmeshctl 中，方便查看，并且可以进一步扩展，以判断底层 eBPF 是否与 Kmesh 守护进程中的配置同步。# Get eBPF info in dual-engine mode kubectl exec -ti -n kmesh-system kmesh-6ct4h -- curl 127.0.0.1:15200/debug/config_dump/bpf/workload # Get eBPF info in kernel-native mode kubectl exec -ti -n kmesh-system kmesh-6ct4h -- curl 127.0.0.1:15200/debug/config_dump/bpf/ads改进CNI安装程序由于 CNI 安装程序是 Kmesh 守护进程，如果 kmesh-daemon 意外崩溃或机器突然断电，CNI 将无法卸载 CNI 配置。如果 kubeconfig 的 token 过期，则 kmesh-daemon 异常退出后，任何 Pod 都无法成功启动。因此，我们采取了以下两种方法来解决此问题：在 start_kmesh.sh 的末尾清理 CNI 配置。在CNI安装程序中添加一个单独的Go协程，一旦token文件被修改，更新 kubeconfig 文件。这可以确保 kubeconfig 文件不容易过期。支持HostNetwork工作负载现在，对于 Kmesh 双引擎模式，我们支持通过 HostNetwork Pods 访问服务。性能提升在双引擎模式中，我们通过使用本地缓存来优化工作负载和服务响应处理期间的 BPF Map更新，避免了对 BPF Map的循环遍历。关键Bug修复我们还修复了一些重大 Bug：通过不删除前端Map，防止在工作负载资源更新期间失去流量控制。来自命名空间 waypoint 的流量将再次重定向到 waypoint，避免了死循环。现在我们跳过了来自 waypoint 的流量管理。修复了当 waypoint 处理非 HTTP TCP流量时，会意外返回HTTP/1.1 400 Bad Request 的问题。#681  致谢贡献者  Kmesh v0.5.0 版本包含了来自14 位贡献者的 567 次代码提交，在此对各位贡献者表示由衷的感谢： @hzxuzhonghu @LiZhenCheng9527 @nlgwcy @YaoZengzeng@supercharge-xsy@Okabe-Rintarou-0@lec-bit@weli-l@noobwei@kwb0523@tacslon@zirain@yuanqijing@SpongeBob0318我们始终以开放中立的态度发展 Kmesh，持续打造 Sidecarless 服务网格业界标杆方案，服务千行百业，促进服务网格健康有序的发展。Kmesh 当前正处于高速发展阶段，我们诚邀广大有志之士加入！参考链接Kmesh Release v0.5.0: cid:link_3Kmesh GitHub: cid:link_5Kmesh Website: https://kmesh.net/【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_4 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

北京时间2024年9月19日，Volcano社区v1.10.0版本[1]正式发布（Branch：release-1.10[2]），此次版本增加了以下新特性：新增队列优先级设置策略支持细粒度的GPU资源共享与回收支持Pod Scheduling Readiness调度支持Sidecar container调度增强vcctl命令行工具功能Volcano支持Kubernetes v1.30增强Volcano安全性优化Volcano性能提升GPU监控功能优化helm chart包安装升级流程▶ 新增队列优先级设置策略  在传统的大数据处理场景下，用户可以直接设置队列优先级来控制作业的调度顺序，为了更好的帮助用户从Hadoop/Yarn迁移到云原生平台，Volcano也支持了在队列层面直接设置优先级，降低大数据用户的迁移成本，提升用户体验和资源利用效率。队列是Volcano中的一种基本资源，不同队列有着优先级区分，在默认情况下，队列的优先级是由队列的share值决定的，share值是由队列中已分配的资源量除以队列的总容量计算得到的，不需要用户手动配置，share值越小，则代表队列中已分配的资源比例越小，即队列越不饱和，需要优先分配资源，因此队列的share越小，队列的优先级越高，在分配资源时会优先分配给share较小的队列，以保证资源分配的公平性。但是在生产环境尤其是大数据处理场景下，用户更希望可以直接设置队列的优先级，从而能更直观的知道不同队列的优先级顺序，由于share值是实时计算得到的，因此会根据队列分配资源的饱和程度而实时变化，为了更加直观的表示队列优先级同时支持用户自行配置，Volcano在share值的基础上为队列新增了priority字段，支持用户配置队列优先级，priority越高则表示队列优先级越高，会优先分配资源给高优先级的队列，并且在回收队列资源时会优先回收低优先级队列内的作业。队列优先级定义：type QueueSpec struct { ... // Priority define the priority of queue. Higher values are prioritized for scheduling and considered later during reclamation. // +optional Priority int32 `json:"priority,omitempty" protobuf:"bytes,10,opt,name=priority"` }同时为了兼容share值的使用方式，Volcano在计算队列优先级时也会考虑share值，默认情况下用户不设置队列优先级或者队列的优先级相等时，Volcano会再比较队列的share值，此时share越小队列优先级越高。用户可以根据实际场景选择设置不同的优先级策略，即priority和share两种方式。关于队列优先级设计文档，请参考：Queue Priority[3]▶ 支持细粒度的GPU资源共享与回收Volcano在v1.9版本发布了弹性队列容量capacity调度功能，用户可以直接为队列设置每一维度资源的容量，同时支持基于deserved的队列弹性容量调度，实现了更加细粒度的队列资源共享和回收机制。弹性队列容量capacity调度的设计文档请参考：Capacity scheduling Design[4]使用指导请参考：Capacity Plugin User Guide[5]为队列配置每一维度deserved使用样例：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在v1.10版本中，Volcano在弹性队列容量capacity的基础上，支持了上报不同型号的GPU资源，NVIDIA默认的Device Plugin在上报GPU资源时无法区分GPU型号，统一上报为nvidia.com/gpu，AI训推任务无法根据业务特点选择不同型号的GPU，比如A100、T4等型号的GPU，为了解决这一问题，以满足不同类型的AI任务需求，Volcano在Device Plugin层面支持上报不同型号的GPU资源到节点，配合capacity插件实现更加细粒度的GPU资源共享和回收。关于Device Plugin上报不同型号GPU的实现和使用指导，请参考：GPU Resource Naming[6]注意：capacity在v1.10.0版本中作为了默认的队列管理插件，capacity与proportion插件互相冲突，当升级到v1.10.0后，你需要再设置队列的deserved字段，以保证队列功能正常工作，具体的使用说明请参考：Capacity Plugin User Guide[7]capacity插件根据用户指定的队列deserved值来划分集群资源，而proportion插件则根据队列权重动态划分集群资源，用户可以根据实际场景选择使用capacity或者proportion插件进行队列管理。proportion插件的介绍请参考：proportion plugin[8]▶ 支持Pod Scheduling Readiness调度Pod 一旦创建就被认为已准备好进行调度，在 Kube-scheduler 中，它会尽力寻找合适的节点来放置所有Pending的 Pod。然而，在现实情况下，某些 Pod 可能会长时间处于“缺少必要资源”状态，这些 Pod 实际上以不必要的方式干扰调度程序（以及 Cluster AutoScaler 等下游组件）的决策和运行，造成资源浪费等问题。Pod Scheduling Readiness是 Kube-sheduler 的一项新增功能，在Kubernetes v.1.30版本GA，成为了一个稳定特性，它通过设置Pod的schedulingGates字段来控制Pod的调度时机。pod-scheduling-gates-diagram在前面的版本中，Volcano已集成了K8s默认调度器的所有算法，全面涵盖了Kube-scheduler的原生调度功能。因此，Volcano能够无缝替代Kube-scheduler，作为云原生平台下的统一调度器，支持微服务和AI/大数据工作负载的统一调度。在最新发布的v1.10版本中，Volcano更是引入了Pod Scheduling Readiness调度能力，进一步满足了用户在多样化场景下的调度需求。关于Pod Scheduling Readiness特性的文档，请参考：Pod Scheduling Readiness | Kubernetes[9]Volcano支持Pod Scheduling Readiness调度的设计文档，请参考：Proposal for Support of Pod Scheduling Readiness by ykcai-daniel · Pull Request #3581 · volcano-sh/volcano (github.com)[10]▶ 支持Sidecar container调度Sidecar container是一种相对于业务容器而言的辅助容器，通常用来辅助业务容器的运行，比如收集业务容器日志、监控、初始化网络等。在Kubernetes v1.28之前，Sidecar container只是一种概念，并没有单独的API来标识一个容器是否是Sidecar container，Sidecar容器和业务容器处于同等地位，有着相同的生命周期，Kubelet会并发启动所有Sidecar容器和业务容器，这样带来的问题是Sidecar容器可能会在业务容器启动之后才启动，并且在业务容器结束之前先结束，而我们期望的是Sidecar容器先于业务容器启动，并在业务容器结束之后再结束，这样就能保证Sidecar容器收集的日志，监控等信息是完整的。Kubernetes v1.28在API层面支持了Sidecar container，并对init container、Sidecar container、业务container做了统一的生命周期管理，同时调整了Pod的request/limit资源计算方式，该特性在v1.29成为Beta特性。该特性在设计阶段经历了漫长的讨论时间，特性本身并不复杂，主要的考虑点在于兼容旧的使用方式，如果定义一个除了init container、业务容器之外的新的容器类型，会对API有较大的破坏性，同时周边组件适配该特性的话会有较多的侵入式修改，带来很多额外开销，因此Kubernetes社区并没有引入新的容器类型来支持Sidecar container，而是直接复用了init container，通过设置init container的restartPolicy为Always来标识Sidecar container，完美的解决了API兼容性问题和Sidecar容器的生命周期问题。在调度层面，该特性的影响在于Pod申请的request资源计算方式有所变化，因为Sidecar container作为一种特殊的init container是持久运行的，需要将Sidecar container的request值累加到业务容器的request值上，因此需要重新计算init container、Sidecar container和业务容器的资源request值。Volcano调度器在新版本更改了Sidecar container的资源计算方式，支持了Sidecar container的调度，用户可以使用Volcano调度Sidecar container。关于Sidecar container的详细信息，请参考：Sidecar Containers | Kubernetes[11]▶ 增强vcctl命令行工具功能vcctl是操作Volcano内置CRD资源的一个命令行工具，可以方便的用来查看/删除/暂停/恢复vcjob资源，并支持查看/删除/开启/关闭/更新queue资源。Volcano在新版本对vcctl做了功能增强，新增以下功能：支持创建/删除/查看/描述jobflow和jobtemplate资源支持查询指定队列里的vcjob支持通过queue和vcjob过滤查询Podvcctl的详细指导文档，请参考：vcctl Command Line Enhancement[12]▶ Volcano支持Kubernetes v1.30Volcano版本紧跟Kubernetes社区版本节奏，对Kubernetes的每个大版本都进行支持，目前最新支持的版本为v1.30，并运行了完整的UT、E2E用例，保证功能和可靠性。如果您想参与Volcano适配Kubernetes新版本的开发工作，请参考：adapt-k8s-todo[13] 进行社区贡献。▶ 增强Volcano安全性Volcano一直都很重视开源软件供应链的安全，在license合规、安全漏洞披露和修复、仓库分支保护、CI检查等方面遵循OpenSSF定义的规范，Volcano近期在Github Action加入了新的workflow，它会在代码合入时运行OpenSSF安全性检查，并实时更新软件安全评分，持续提升软件安全性。同时Volcano对各个组件的RBAC权限进行了收缩，只保留必要的权限，避免了潜在的越权风险，提升了系统的安全性。相关PR参见：Added the scorecard github action and its badge by harshitasao · Pull Request #3655 · volcano-sh/volcano[14]Shrink permissions of vc scheduler & controller by Monokaix · Pull Request #3545 · volcano-sh/volcano (github.com)[15]Add pre-install&pre-upgrade hook for admission-init job by Monokaix · Pull Request #3504 · volcano-sh/volcano (github.com)[16]▶ 优化Volcano性能在大规模场景下，Volcano做了很多性能优化的工作，主要包括：优化vcjob更新策略，降低vcjob的更新和同步频次，降低API Server压力，提升提交任务的QPSvc controller新增controller gate开关，用户可以选择关闭不需要的controller，减低内存占用和CPU负载所有的controller使用共享的informer，减少内存占用▶ 提升GPU监控功能新版本的Volcano针对GPU监控指标做了优化和增强，修复了GPU监控不精确的问题，并在GPU的算力和显存监控指标上新增了节点信息，方便用户更加直观的查看每个节点上每一张GPU的算力、显存的总量和已分配量。详细PR参见：Update volcano-vgpu monitoring system by archlitchi · Pull Request #3620 · volcano-sh/volcano (github.com)[17]▶ 优化helm chart包安装升级流程Volcano针对helm chart的安装、升级流程进行了优化，并支持安装helm chart包设置更多自定义参数，主要包括：利用helm的hook机制，在安装成功Volcano之后，自动删除volcano-admission-init这一job，避免后续使用helm upgrade升级失败的问题，相关PR参见：Add pre-install&pre-upgrade hook for admission-init job by Monokaix · Pull Request #3504 · volcano-sh/volcano (github.com)[18]每次安装成功后更新Volcano admission需要的secret文件，避免在不指定helm包名情况下，重复安装卸载volcano导致volcano admission处理失败的问题，详细PR参见：Update volcano-admission secret when it already exists by Monokaix · Pull Request #3653 · volcano-sh/volcano (github.com)[19]支持为helm包中的资源对象设置通用label，相关PR参见：Add common labels for chart objects by Aakcht · Pull Request #3511 · volcano-sh/volcano (github.com)[20]支持通过helm为Volcano组件设置日志等级，相关PR参见：Expose volcano components (controller, scheduler, etc.) log level control to the helm chat values by chenshiwei-io · Pull Request #3656 · volcano-sh/volcano (github.com)[21]支持通过helm设置Volcano组件的镜像代理仓库，相关PR参见：add image registry for helm by calvin0327 · Pull Request #3436 · volcano-sh/volcano (github.com)[22]支持通过helm设置容器级别的securityContext，相关PR参加：feat: Add securityContext support at container level in helm chart templates by lekaf974 · Pull Request #3704 · volcano-sh/volcano (github.com)[23]致谢贡献者Volcano 1.10.0 版本包含了来自36位社区贡献者的上百次代码提交，在此对各位贡献者表示由衷的感谢：贡献者GitHub ID@googs1025@WulixuanS@SataQiu@guoqinwill@lowang-bh@shruti2522@lukasboettcher@wangyysde@bibibox@Wang-Kai@y-ykcir@lekaf974@yeahdongcn@Monokaix@Aakcht@yxxhero@babugeet@liuyuanchun11@MichaelXcc@william-wang@lengrongfu@xieyanker@lx1036@archlitchi@hwdef@wangyang0616@microyahoo@snappyyouth@harshitasao@chenshiwei-io@TaiPark@Aakcht@ykcai-daniel@lekaf974@JesseStutler@belo4ya参考资料[1] v1.10.0版本: cid:link_6[2] Branch：release-1.10: cid:link_7[3] Queue Priority: cid:link_3[4] Capacity scheduling Design: cid:link_2[5] Capacity Plugin User Guide: cid:link_1[6] GPU Resource Naming: cid:link_5[7] Capacity Plugin User Guide: cid:link_1[8] proportion plugin: https://volcano.sh/en/docs/plugins/#proportion[9] Pod Scheduling Readiness | Kubernetes: https://kubernetes.io/docs/concepts/scheduling-eviction/pod-scheduling-readiness/[10] Proposal for Support of Pod Scheduling Readiness by ykcai-daniel · Pull Request #3581 · volcano-sh/volcano (github.com): cid:link_10[11] Sidecar Containers | Kubernetes: https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/[12] vcctl Command Line Enhancement: cid:link_0[13] adapt-k8s-todo: cid:link_4[14] Added the scorecard github action and its badge by harshitasao · Pull Request #3655 · volcano-sh/volcano: cid:link_11[15] Shrink permissions of vc scheduler & controller by Monokaix · Pull Request #3545 · volcano-sh/volcano (github.com): cid:link_12[16] Add pre-install&pre-upgrade hook for admission-init job by Monokaix · Pull Request #3504 · volcano-sh/volcano (github.com): cid:link_13[17] Update volcano-vgpu monitoring system by archlitchi · Pull Request #3620 · volcano-sh/volcano (github.com): cid:link_9[18] Add pre-install&pre-upgrade hook for admission-init job by Monokaix · Pull Request #3504 · volcano-sh/volcano (github.com): cid:link_13[19] Update volcano-admission secret when it already exists by Monokaix · Pull Request #3653 · volcano-sh/volcano (github.com): cid:link_14[20] Add common labels for chart objects by Aakcht · Pull Request #3511 · volcano-sh/volcano (github.com): cid:link_15[21] Expose volcano components (controller, scheduler, etc.) log level control to the helm chat values by chenshiwei-io · Pull Request #3656 · volcano-sh/volcano (github.com): cid:link_16[22] add image registry for helm by calvin0327 · Pull Request #3436 · volcano-sh/volcano (github.com): cid:link_17[23] feat: Add securityContext support at container level in helm chart templates by lekaf974 · Pull Request #3704 · volcano-sh/volcano (github.com): cid:link_18【更多Volcano干货推荐】Volcano云原生批量计算公开课Volcano云原生批量计算公开课Volcano云原生批量计算公开课由CNCF首个批量计算社区Volcano核心贡献者开发，通过理论学习+实践操作，帮助学习者由浅入深了解批量计算原理和生产场景应用，晋升批量计算达人！点击免费学习Volcano云原生批量计算公开课社区介绍：Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene、Ray 等众多主流计算框架的支持，并构建起完善的上下游生态。Volcano官网：https://volcano.shGitHub: cid:link_19每周例会： https://zoom.us/j/91804791393

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。本版本包含下列新增特性：支持联邦应用跨集群滚动升级，使用户版本发布流程更加灵活可控karmadactl 新增了多项运维能力，提供独特的多集群运维体验为联邦工作负载提供标准化 generation 语义，使 CD 执行一步到位Karmada Operator 支持自定义 CRD 下载策略，使离线部署更灵活新特性概览▍联邦应用跨集群滚动升级在最新发布的 v1.11 版本[1] 中，Karmada 新增了联邦应用跨集群滚动升级特性。这一特性特别适用于那些部署在多个集群上的应用，使得用户在发布应用新版本时能够采用更加灵活和可控的滚动升级策略。用户可以精细地控制升级流程，确保每个集群在升级过程中都能够平滑过渡，减少对生产环境的影响。这一特性不仅提升了用户体验，也为复杂的多集群管理提供了更多的灵活性和可靠性。下面通过一个示例来演示如何对联邦应用进行滚动升级：假定用户已经通过 PropagationPolicy 将 Deployment 应用分发到三个成员集群中：ClusterA、ClusterB、ClusterC：apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx-propagation spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinity: clusterNames: - ClusterA - ClusterB - ClusterC此时 Deployment 版本为 v1，为了将 Deployment 资源版本升级至 v2，用户可以依次执行下列步骤。首先，用户通过配置 PropagationPolicy 策略，暂时停止向 ClusterA 和 ClusterB 分发资源，从而应用的变更将只发生在 ClusterC：apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx-propagation spec: #... suspension: dispatchingOnClusters: clusterNames: - ClusterA - ClusterB然后更新 PropagationPolicy 资源，允许系统向 ClusterB 集群同步新版本资源：suspension: dispatchingOnClusters: clusterNames: - ClusterA最后删除 PropagationPolicy 资源中的 suspension 字段，允许系统向 ClusterA 集群同步新版本资源：从上述示例中我们可以看到，利用联邦应用跨集群滚动发布能力，新版本应用可以做到按集群粒度滚动升级，并且可以做到精准控制。此外，该特性还能应用于其他场景：作为开发者，当 Karmada 控制平面与成员集群争夺资源控制权时，会出现资源被频繁更新的情况。暂停将资源同步到成员集群的过程将有助于快速定位问题。▍karmadactl 能力增强和运维体验提升在本版本中，Karmada 社区致力于增强 Karmadactl 的能力，以便提供更好的多集群运维体验，进而摆脱用户对 kubectl 的依赖。更丰富的命令集Karmadactl 支持更丰富的命令集，如 create、patch、delete、label、annotate、edit、attach、top node、api-resources 以及 explain，这些命令允许用户对 Karmada 控制面或成员集群上的资源执行更多操作。更丰富的功能Karmadactl 引入了 --operation-scope 参数来控制命令的操作范围。有了这个新参数，get、describe、exec 和 explain 等命令可以灵活切换集群视角对 Karmada 控制面或成员集群的资源进行操作。更详细的命令输出信息karmadactl get cluster 命令的输出现在增加了 cluster 对象的 Zones、Region、Provider、API-Endpoint 和 Proxy-URL 信息。通过这些能力增强，karmadactl 的操作和运维体验得到了提升。karmadactl 的新功能和更多详细信息可以通过使用 karmadactl --help 获得。▍联邦工作负载标准化 generation 语义在本版本中，Karmada 将联邦层面的工作负载 generation 语义进行了标准化。这一更新为发布系统提供了可靠的参考，增强了跨集群部署的精确度。通过标准化 generation 语义，Karmada 简化了发布流程，并确保一致性地跟踪工作负载状态，使得跨多个集群管理和监控应用程序变得更加容易。标准化细节为，当且仅当工作负载分发至所有成员集群中的资源状态满足 status.observedGeneration >= metadata.generation 时，联邦层面的工作负载状态中的 observedGeneration 值才会被设置为其本身 .metadata.generation 值，这确保了每个成员集群中相应的控制器均已完成了对该工作负载的处理。此举将联邦层面的 generation 语义同kubernetes 集群的 generation 语义进行了统一，使用户能够更便捷的将单集群业务迁移至多集群业务。本版本已完成下列资源适配：GroupVersion: apps/v1 Kind: Deployment, DaemonSet, StatefulSetGroupVersion: apps.kruise.io/v1alpha1 Kind: CloneSet, DaemonSetGroupVersion: apps.kruise.io/v1beta1 Kind: StatefulSetGroupVersion: helm.toolkit.fluxcd.io/v2beta1 Kind: HelmReleaseGroupVersion: kustomize.toolkit.fluxcd.io/v1 Kind: KustomizationGroupVersion: source.toolkit.fluxcd.io/v1 Kind: GitRepositoryGroupVersion: source.toolkit.fluxcd.io/v1beta2 Kind: Bucket, HelmChart, HelmRepository, OCIRepository如有您有更多资源（包括CRD）需要适配，可以向 Karmada 社区进行反馈，也可以使用 Resource Interpreter进行扩展。▍Karmada Operator 支持自定义 CRD 下载策略CRD（Custom Resource Definition，自定义资源定义）资源是 Karmada Operator 用于配置新的 Karmada 实例的关键前提资源。这些 CRD 资源包含了 Karmada 系统的关键 API 定义，例如，PropagationPolicy，ResourceBinding，Work 等。在 v 1.11 版本中，Karmada Operator 支持用户自定义 CRD 下载策略。利用这个功能，用户可以指定 CRD 资源的下载路径，并定义更多的下载策略，为用户提供了更灵活的离线部署方式。有关该特性的详细描述，可以参考提案：Custom CRD Download Strategy Support for Karmada Operator[2] 。致谢贡献者Karmada v1.11 版本包含了来自 36 位贡献者的 223 次代码提交，在此对各位贡献者表示由衷的感谢：贡献者列表：@08AHAD@a7i@aditya7302@Affan-7@Akash-Singh04@anujagrawal699@B1F030@chaosi-zju@dzcvxe@grosser@guozheng-shen@hulizhe@iawia002@mohamedawnallah@mszacillo@NishantBansal2003@jabellard@khanhtc1202@liangyuanpeng@qinguoyi@RainbowMango@rxy0210@seanlaii@spiritNO1@tiansuo114@varshith257@veophi@wangxf1987@whitewindmills@xiaoloongfang@XiShanYongYe-Chang@xovoxy@yash@yike21@zhy76@zhzhuang-zju参考资料[1] Karmada v1.11: cid:link_4[2] 提案：Custom CRD Download Strategy Support for Karmada Operator: cid:link_0【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_5 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

扫码进入容器活动专场

8月21日-23日，由云原生计算基金会（CNCF）和 Linux 基金会联合主办的KubeCon + CloudNativeCon + Open Source Summit + Al_dev China 2024 大会在中国香港盛大召开。会上，多位Kuasar社区Maintainer分享了关于云原生容器运行时与大模型等领域前沿技术的案例实践与经验思考。KubeCon China 2024 主题演讲Kuasar[1]于2023年4月在KubeCon Europe上由华为云联合多家企业和社区发起，12月正式成为CNCF首个多沙箱容器运行时项目。Kuasar基于 Rust 语言实现，提供基于 MicroVM/App Kernel/WebAssembly / runC类型的沙箱容器，融入了各企业和社区在容器运行时领域的前沿探索、技术积累和生产实践，开源至今受到业界的广泛关注和支持，已收获1200多个GitHub Star和85个Fork，数十位来自外部企业、高校的开源爱好者参与开发贡献和积极落地应用。▍使用Kuasar和WasmEdge在Kubernetes上部署大语言模型Kuasar 社区 Maintainer Burning Zhang（华为云），携手WasmEdge社区创始成员Vivian Hu（Second State）带来了主论坛演讲《使用Kuasar和WasmEdge在Kubernetes上部署大语言模型》。《使用Kuasar和WasmEdge在Kubernetes上部署大语言模型》大语言模型（LLM）是强大的人工智能工具，能够理解并生成自然语言。然而，传统运行LLM的方法面临着诸多挑战，包括复杂的软件包安装、GPU设备兼容性问题、不灵活的扩展性、有限的资源监控和统计，以及存在安全漏洞。云原生人工智能（CLOUD NATIVE ARTIFICIAL INTELLIGENCE）白皮书[2]指出：“WASM is a platform-independent, efficient CN approach to inference.”“WASM 是一种高效、平台无关的云原生推理方法。” 云原生人工智能（CLOUD NATIVE ARTIFICIAL INTELLIGENCE）白皮书WasmEdge 提供了一种基于 WebAssembly 运行时的解决方案，使得开发快速、灵活、资源高效且安全的 LLM 应用程序成为可能。Kuasar 作为容器运行时，无缝集成了 WebAssembly 运行时，使应用程序能够在 Kubernetes 集群上顺利运行。在Kubernetes中集成LLM借助 Kuasar 和 WasmEdge 在 Kubernetes 集群中运行大模型负载的实践，成功解决了大模型应用开发和部署的两个关键痛点问题。首先，通过 WebAssembly 技术，解决了传统技术在跨平台兼容性和复杂依赖性方面的挑战。开发者不再需要为不同 CPU 架构之间的编译与运行问题头疼，也无需为不同 GPU 驱动版本的兼容性以及 Python/PyTorch 复杂的依赖包问题而烦恼。WebAssembly 提供了一个统一的运行环境，使得跨平台的应用开发和部署变得更加简洁和高效。另一方面，Kubernetes 集群本身为 LLM 负载程序提供了强大的容器编排能力，极大地简化了大模型的开发和部署过程。打包与部署：通过将大模型打包成容器镜像，能够轻松实现应用在集群任意节点上的批量部署，显著提高了部署效率。资源管理：Kubernetes 提供了精细的资源申请和管理机制，可以为每个应用合理规划异构资源的申请和限制，确保在划定的 QoS 范围内进行高效调度。弹性伸缩：Kubernetes 可以快速实现弹性伸缩，既能保证服务质量，又能最大化资源利用率。可观测性：借助 Kubernetes 的可观测性能力，能够更好地监控负载，收集性能数据，并记录日志，为优化和故障排除提供数据支持。服务发现与负载均衡：Kubernetes 提供了服务发现和负载均衡功能，使得应用程序间的交互和联网更加顺畅。灰度发布：支持灰度发布，使大模型的版本迭代和更新过程更加平滑，降低了新版本上线的风险。通过这些能力，Kubernetes 不仅简化了大模型应用的部署和管理，还大幅提升了其运行效率和稳定性，加速云原生技术与 AI 生态的深度融合与发展。▍基于Containerd的Sandbox API构建容器运行时华为云云原生团队，Kuasar社区Maintainer Abel Feng和来自DaoCloud的Containerd  Committer 蔡威共同分享了《如何基于Containerd的Sandbox API构建容器运行时》。《如何基于Containerd的Sandbox API构建容器运行时》随着不同类型的隔离技术（如沙箱）的引入，容器现在更多地是一组API规范，而不是单一技术。目前Containerd社区已经社区围绕Sandbox概念衍生出一套新的数据结构和管理接口Sandbox API, 以便轻松集成不同类型的沙箱技术，使其成为容器运行时。Containerd中的Sandbox 和Container基于Sandbox API接口实现，Kuasar 结合了华为云多年生产业务实践以及对沙箱技术发展的思考，在保留传统容器运行时功能的基础上，通过全面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创新版本上一键部署。Kuasar各 sandbox架构图应用场景方面，Kuasar 在轻量级安全容器、公有云远程沙箱以及基于 WebAssembly的 LLM 推理场景下展现了其巨大的架构优势。通过 Kuasar，用户能够在轻量级虚拟机中实现高效、安全的资源隔离与管理，甚至可以将远程的IaaS的虚拟机作为沙箱进行灵活管理。此外，在运行 LLM 推理任务时，Kuasar 的架构能够充分利用 WebAssembly技术，实现高效的资源利用和跨平台兼容性，为 AI 应用提供了基础架构支持。目前，Kuasar社区已经发布v1.0.0版本[3]，这是该项目的一个重要里程碑。此次发布的版本标志着 Kuasar 的 Cloud Hypervisor 沙箱容器已经达到了稳定和成熟的阶段，可为开发者和企业用户提供了更为安全的云原生容器化部署，以提升容器的安全性和隔离性。用户可通过小规模测试，验证其在实际场景中的表现。▍总 结在本届 KubeCon 大会上，Kuasar社区联合WasmEdge社区分享了对大模型应用在云原生场景的部署，加速AI在云原生领域的落地，和Containerd社区展示了应用最新的Sandbox API构建多沙箱容器运行时的可能，以及Kuasar 社区在这方面的应用案例和探索，旨在帮助开发者和企业用户更好地容器化上云。大会期间带来的新版本v1.0.0性能更加成熟，欢迎大家体验。展望未来，Kuasar 将继续致力于云原生多沙箱容器领域的深入研发，深入挖掘和满足更多用户场景的需求，不断优化和扩展技术栈，为用户提供更加全面、成熟和高效的解决方案。相关链接：[1]Kuasar多沙箱容器运行时: cid:link_1[2]云原生人工智能白皮书: https://www.cncf.io/wp-content/uploads/2024/03/cloud_native_ai24_031424a-2.pdf[3]Kuasar v1.0.0 版本: cid:link_0更多云原生技术动向关注容器魔方

华为云云原生容器团队致力于成为技术创新先锋，通过云原生容器化技术，为企业数字化转型提供强大动力，让云无处不在，让智能无所不及，共建智能世界云底座。云原生产业方面，我们连续4年位居云容器软件市场份额国内TOP 1，深入理解不同行业需求，先后在云容器引擎、Serverless、边缘计算、分布式云等多个场景推出成熟的云服务，在互联网、金融、政企等多个领域打下良好口碑。云原生技术方面，我们是CNCF国内唯一初始成员，拥有本土唯一CNCF TOC席位和多个CNCF项目技术委员会/治理委员会成员及核心Maintainer，先后主导开源了KubeEdge、Volcano、Karmada、Kuasar等多个CNCF项目，是全球云原生开源技术的领导者之一。 岗位描述 云原生产品架构师 / 研发工程师负责华为云云原生产品及服务的系统设计、代码研发、技术攻关及关键技术预研等，保障云容器服务的持续稳定运行，构建产品技术竞争力，提升产品的市场竞争力和客户价值。云原生开源架构师 / 研发工程师参与云原生开源项目需求分析，洞察业界趋势，用户场景挖掘，构筑高可靠、高性能的开源项目竞争力参与云原生开源项目的代码开发、维护，构建最活跃的开源社区参与云原生开源项目的社区治理与生态建设，打造社区生态参加业界会议，布道宣传开源生态，打造云原生项目的技术品牌和影响力任职要求 本科及以上学历，计算机或相关专业，5年以上软件或行业相关工作经验。了解云计算常用技术，如云原生、容器化、虚拟化、AI、容器引擎、服务治理等技术和架构，熟悉云服务的部署、监控和维护，能够处理常见的故障和问题。具备较强的技术架构设计和方案设计能力，良好的沟通和团队协作能力，能够与客户和合作伙伴进行有效的交流和合作。具备良好的自我学习和创新意识，能够跟踪最新的技术发展趋势，不断提高自己的技术水平和创新能力拥有CNCF社区贡献，熟悉CNCF项目（如Volcano、Kubeflow、KubeEdge、confidential-containers、kepler、OpenTelemetry等项目）优先简历投递 华为云云容器团队社招HC，北京、杭州、深圳、上海均有岗位，欢迎感兴趣的朋友联系。联系方式：手机/微信：15191581137邮箱：chengtenglang@huawei.com

8月21日-23日，由云原生计算基金会（CNCF）和 Linux 基金会联合主办的KubeCon + CloudNativeCon + Open Source Summit + Al_dev China 2024 大会在中国香港盛大召开。会上，华为云云原生开源负责人，CNCF TOC王泽锋，蔚来汽车战略新业务数字系统架构师蒋旭辉联合发表“云原生技术加速电动汽车创新”主题演讲，深入探讨云原生解决方案在革新EV领域中的转变影响和未来前景。KubeCon China 2024 主题演讲作为一家全球化的智能电动汽车公司，蔚来致力于提供高性能的智能电动汽车与极致用户体验，坚持核心技术的正向研发，建立了由12个领域的技术栈构成的“蔚来技术全栈”。硬件基础决定软件形态，随着车载算力的不断增强，车端软件数量也在爆发式的增长。车端作为其团队重点，在新的行业变革中也产生了新的需求和挑战。E/E架构与SDV趋势下车端软件开发挑战根据博世2019年提出的整车电子电器架构的演进图，当前的新能源汽车有一部分已经达到了3.0时代，即区域控制器和车载电脑；在向车云计算的演进过程中，部分功能已在实现车云协同。基于3.0架构，汽车行业有一个比较热门的话题，是软件定义汽车。软件定义汽车实际是SOA架构和中央计算E/E架构的合体。其中的核心就是中央计算单元。当前的中央计算单元已经融合核座舱、网联、智驾的能力，软件平台的重要性更加突出。在规划中央计算单元的规划定义阶段，将云端的能力当成整体平台的一部分，实现车云的一体化设计。行业趋势 – SDV蔚来数字系统团队，主要聚焦于整个平台中的智能网联和工具链的部分。在智能网联的研发环节，面临的行业环境变化有：敏捷开发敏捷交付需求：软件研发周期变短，汽车换代时间由以前的8年左右现在提速到1年多。随着软件比重的增加，交付后版本更新成为一个必须项。硬件平台异构，开发人员很并行开发难度高。研发与测试管理成本提升：汽车软件除了一些硬件的差异化配置外，软件也开始出现差异化。为了实现软件的千人千面，需要平台提供定向推送的能力，管理复杂。传统的汽车厂商作为集成商，更多的是做整车的功能测试。随着汽车厂商的软件自研能力提高，软件测试项目的内容和复杂度也大幅提高，这些变化带来了测试成本的挑战。跨领域团队协作愈发频繁：中央计算单元集成的功能递增，车和云之间，自动驾驶、网联、座舱等团队的交叉协作越来越密切。汽车软件的开发也在引入互联网的模式，由传统的V模型，转变到V模型与敏捷开发混合。技术生态双重优势云原生助力车端软件平台构建对于当前车企研发所面临的问题，王泽锋提到，构建车端软件平台，云原生从技术维度和生态维度均具备明显优势。技术层面，云原生提供便捷的软件依赖管理，灵活的编排部署策略，技术栈开放，灵活可定制；生态层面，成熟的云原生生态为企业提供了丰富的选择，厂商基于标准接口提供服务，互操作性强且开源为主，拥有丰富的标准软件生态，与此同时，云原生行业人才系统成熟，这为车企提供了众多方案选择与研发力量后盾。CNCF TOC 华为云云原生开源负责人 王泽锋如何基于云原生技术构建车端软件平台？将云原生技术栈应用到车的领域，也面临着以下挑战：1. 算力稀缺：车端算力成本比云数据中心、消费电子高出很多；2. 海量边缘节点接入：汽车的接入数量级在数十万到数百万之间，对于平台的管理规模本身就是巨大的挑战；3. 运行环境差异：汽车的网络环境稳定性差（经常处于地下室、隧道等无网络环境），本身的高速移动也会表现为网络的高延迟高丢包现象。以KubeEdge为核心构建蔚来整套车云协同平台蒋旭辉提到，经过大量调研和选型工作后，我们发现KubeEdge能够很好地解决这些挑战，因此我们选择使用KubeEdge作为平台的核心，以Kubernetes + KubeEdge为技术底座，构建了整套车云协同平台。在实车端应用的容器化后，蔚来在车上引入了KubeEdge，将车端的容器应用也纳入到API-Server统一管理。KubeEdge在给车端带来容器应用编排能力的同时，自身占用资源较少，并且启动非常迅速，可以满足汽车软件的使用场景需求。借助KubeEdge的离线自治能力，在弱网/断网环境下，平台也可以实现车端软件的稳定运行和故障恢复。蔚来汽车战略新业务数字系统架构师 蒋旭辉KubeEdge架构优势作为专为云边协同开发的平台，KubeEdge兼顾各种边缘场景的特殊性：使用K8s作为控制面，并将KubeEdge的额外功能也通过K8s API提供，最大限度地帮助用户融合云数据中心与边缘的生态；针对边缘环境受限的场景，KubeEdge在完成自身轻量化的基础上支持用户自定义功能裁剪，以满足不同的资源需求。并且KubeEdge提供了节点级元数据持久化，支持边缘离线自治；KubeEdge双向多路复用的云边消息通道，替代原本的节点与控制面之间链接，实现对于APIserver连接数的放大，并且引入全时段可靠增量同步的机制应对弱网环境挑战。KubeEdge设计理念在车上引入KubeEdge，将车端的容器应用也纳入到API-Server统一管理，在给车端带来容器应用编排能力的同时，KubeEdge自身占用资源较少，并且启动非常迅速，可以满足汽车软件的使用场景需求。借助KubeEdge的离线自治能力，在弱网/断网环境下，也可以实现车端软件的稳定运行和故障恢复，蒋旭辉在演讲中表示。▍突破APIserver连接数限制，实现超大规模边缘汽车管理在量产车型大规模接入的场景中，需要实现高出传统云数据中心几个数量级的节点管理规模，并且应对节点联接的潮汐效应问题。在KubeEdge的云边通信机制中，配合车端的持久化存储，我们实现了全时段的增量同步机制，可以有效降低车辆启动和断联恢复时的网络冲击，以及状态同步过程中持续开销。通过云边消息通道的双向多路复用机制，KubeEdge可以突破APIserver的连接数限制，实现超大规模的边缘汽车管理。蔚来基于KubeEdge构建车云协同平台架构KubeEdge使用K8s作为控制面，将车的Node、Pod等资源对象的管理实现为K8s原生的API，屏蔽了车端与云端资源的管理差异。业务系统可以很方便地管理车上的容器应用，而不需要感知应用在不同环境应该如何部署。▍场景实际落地, 开发速度、软件质量提升,有效降低使用成本新能源汽车电池健康安全数据分析新能源汽车电池安全一直是用户比较关心的重点，蔚来在电池安全和电池健康方面也一直投入了大量的精力去实现更优的体验，除了电池本身的技术演进外，还运用大数据和人工智能算法来预测和分析电池健康程度，从而优化电池策略，提高电池寿命。场景1 数据分析-电池健康安全检测在具体的工程侧，由于成本和网络的限制，数据分析团队需要进行车和云端结合的算法来达到最佳效果。边缘算法部署在车端，进行特征提取等计算，云端进行时间序列分析等。基于此场景，蔚来数字系统团队创新使用云原生技术，在算法开发阶段，算法开发同事使用容器化的方式进行边缘算法的开发。统一使用容器打包镜像，通过K8s，使云端的算法和车端的算法同步部署。在工程车辆验证阶段，算法团队只需切换依赖的基础镜像，就可以将边缘计算的容器应用快速小批量地部署到工程车辆，进行算法的验证。验证通过后，整个算法主体部分开发完成，算法团队只需根据目标车型替换对应的量产基础镜像，即可完成量产包的制作，无需关心车端的运行环境、系统版本等细节问题。引入云原生能力构建车端软件测试管理平台蔚来在开发阶段使用云原生技术以外，在软件测试阶段也引入云原生的能力。以往的的测试台架资源主要为离线的人工管理方式，不能充分利用台架资源。实车、台架本身具备较大的差异，各测试阶段和测试环境比较孤立，难以覆盖组合场景的测试需求。场景二 功能软件测试引入云原生能力后，Virtual car、台架和实车通过接入到K8s的统一监控和管理，可以更合理地安排测试任务，从而提高测试资源的利用率。蔚来团队同时创新性地将Testcase也进行了容器化，通过基于K8s Job的调度机制，可以更灵活地进行让我们的测试用例在不同测试环境上交叉执行，覆盖更多的场景。通过以上的两种场景应用，实现效能提升：开发速度提升：平台提供了统一的容器化环境依赖管理和部署方式，降低了开发门槛，提高了效率；软件质量提升：平台提供了多环境多节点的统一管理，可以支持规模的自动化测试并行执行；使用成本方面：平台学习门槛低，灵活的发布策略使得整个平台的台架等硬件环境可以更高效合理地被分配和使用。车载硬件和算力的提升带来了车端软件新的发展，在车云协同的当下，智能汽车领域更需要更新的平台技术，来支撑汽车软件的持续演进。蔚来汽车基于Kubernetes + KubeEdge开发云原生车云协同平台，并且首次搭载于量产车型，这是云原生生态领域中一次全新的尝试，为车企带来开发交付效率、团队协作等方面的巨大提升。也相信云原生技术将持续推进整个车端软件的研发创新与深入应用，助力汽车行业迎来更广阔的未来。更多云原生技术动向关注容器魔方

8 月 21 日至 23 日，由云原生计算基金会（CNCF）和 Linux 基金会联合主办的KubeCon + CloudNativeCon + Open Source Summit + Al_dev China 2024 大会将在中国香港隆重举行。作为三大重量级会议组成的综合盛会，本届大会汇集全球顶尖开发者、行业领袖和技术专家，共同探讨云原生、开源及 AI 等领域的最新进展、核心技术及最佳实践。Linux 基金会执行董事 Jim Zemlin、Linux 与 Git 的创始人 Linus Torvalds、CNCF 首席技术官 Chris Aniszczyk、CNCF 执行董事 Priyanka Sharma、LF AI & Data 基金会执行董事 Ibrahim Haddad、Linux 基金会研究员 Greg Kroah-Hartman 等 200 多位国际演讲嘉宾将亲临现场，分享各自领域的深刻见解和宝贵经验。Volcano云原生批量计算社区将在本届大会上带来多个技术演讲、圆桌分享等精彩议程。Volcano 是业界首个云原生批量计算引擎，项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到广泛应用，完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene、Ray 等众多主流计算框架的支持，并构建起完善的上下游生态。社区生产环境落地用户超过50+，吸引了900+全球TOP级企业贡献者。聚焦云原生与AI的参会者们，和这么高纯度“云原生AI”属性的Volcano来一场淋漓尽致的现场探讨准没错！Volcano社区技术专家在本届大会上的精彩分享如下：扫码添加社区小助手回复Volcano进交流群

8 月 21 日至 23 日，由 Linux 基金会、云原生计算基金会 (CNCF）联合主办的 KubeCon + CloudNativeCon + Open Source Summit + Al_dev China 2024 将于中国香港盛大召开。作为 Linux 基金会旗下云原生与开源顶级盛会，大会汇聚全球顶尖技术专家与前沿企业。Linux 基金会执行董事 Jim Zemlin、Linux & Git 创始人 Linus Torvalds、CNCF 首席技术官 Chris Aniszczyk 等世界级巨擘及 200 多位国际演讲嘉宾将莅临现场，分享他们在各自领域的独到见解和实践经验。华为云一直是云原生领域的领导者和践行者，对 Kubernetes、Istio 等项目的贡献一直位居全球前列，先后主导开源了业界首个智能边缘计算项目 KubeEdge、业界首个云原生 AI 调度引擎 Volcano、业界首个云原生多云容器编排引擎 Karmada 等多个 CNCF 项目，并持续带来了 Kuasar、Kmesh、openGemini 等项目创新，拥有在任CNCF 技术监督委员会 TOC 成员，多个 CNCF 项目技术委员会，治理委员会成员及核心Maintainer 席位，是全球云原生开源技术的领导者之一。持续引领全行业智能化发展趋势，华为在云原生 Al 基础设施、Serverless 架构、多云和混合云战略、云边端协同等领域均有领先的商用级产品，以技术革新为驱动，打造业界领先的云原生解决方案，连续八次中国容器软件市场份额 TOP1，为企业数智化转型提供强大动力。本次大会上，华为将带来 3 场 Keynote 主题演讲，20+ 场技术分享，交流云原生 AI、智能边缘、多云容器、容器沙箱、AI 调度、数据库、流量治理等领域的前沿技术与解决方案，期待与您探讨云原生 x AI 的无限可能！关注容器魔方获取更多华为云参会动态

8 月 21 日至 23 日，由 云原生计算基金会 (CNCF）和Linux 基金会联合主办的 KubeCon + CloudNativeCon + Open Source Summit + Al_dev China 2024 将于中国香港盛大召开。本次大会汇聚全球顶尖开发者、行业领袖和技术专家，共同探讨云原生、开源及 AI 等领域的最新进展、核心技术及最佳实践。KubeEdge云原生边缘计算社区将在本次大会上带来Keynote、分论坛等精彩演讲，赋能多领域、多场景边云协同AI智算，敬请期待！大会期间，KubeEdge技术专家也将在CNCF 项目展区（展位号：T7），与您零距离畅聊技术与应用（详见下方展台时间表），KubeEdge邀您共聚KubeCon + CloudNativeCon + Open Source Summit + Al_dev China 2024！扫码回复“Mentorship”进入技术交流群

dge 1.18.0 版本现已正式发布。新版本在稳定性、安全性等方面有了显著的提升，同时持续在易用性等方面做了增强。KubeEdge v1.18.0 新增特性：RouterManager 支持高可用CloudCore 云边通道鉴权增强支持设备状态上报keadm 能力增强封装 Token，CA 和证书操作，提高扩展性升级 K8s 依赖到 v1.29  新特性概览  ▍RouterManager支持高可用针对 CloudCore 采用高可用部署时，RouterManager 无法准确路由的问题，在新版本中，对 RouterManager 在高可用部署时做了优化与增强，云端发往边缘的自定义消息将会被路由到对应 EdgeNode 所连接的 CloudCore中，并正确下发到对应的 EdgeNode。同时考虑了边界情况，在转发过程中，如果 EdgeNode重连到其他 CloudCore 时，消息将会被重新转发到正确的 CloudCore 中。更多信息可参考：cid:link_1cid:link_2▍CloudCore云边通道鉴权增强 CloudCore 作为连接边缘节点和 Kube-APIServer 的桥梁，需要限制边缘节点对集群资源的访问权限。在新版本中，我们对云边通道的安全性进行了增强，CloudHub 会识别消息发送方并校验其是否有足够的权限，从而限制边缘节点操作其他节点的资源。v1.18.0 目前已支持 node authorization 模式。该特性引入了如下配置参数，在新版本中默认关闭，开启如下开关即可启用该特性。apiVersion: v1 data: cloudcore.yaml: ... modules： cloudhub: authorization: // optional, default false, toggle authoration enable: true // optional, default to false, do authorization but always allow all the requests debug: false // required, an authorizer chain authorizers: // node authorization mode - node: ebable：true ... 为了安全启用此特性，可以先开启 debug。当鉴权失败时，CloudCore 只记录日志，但请求仍会正常处理。更多信息可参考：cid:link_3cid:link_4▍支持设备状态上报 设备有其自身的状态，比如在线、离线、异常等。1.18.0版本支持了设备状态上报的能力。该特性在 Mapper-Framework 已经默认实现，用户基于 Mapper-Framework 生成自己需要的 mapper，即可使用。状态上报成功后，可通过 device 的资源查看结果：apiVersion: devices.kubeedge.io/v1beta1 kind: Device ... spec: status: lastOnlineTime: "2024-07-30T17:55:49Z" state: ok twins: - observedDesired: ....更多信息可参考：cid:link_5cid:link_6cid:link_7▍Keadm能力增强 在旧版本中，使用 keadm join 安装 EdgeCore 只能指定部分参数的配置。在最新版本中，我们对 EdgeCore 的配置流程进行了显著优化。现在，您无需等待节点接入完成,手动编辑 edgecore.yaml 配置文件，再重启 EdgeCore。通过在 keadm join 命令中使用新增的 --set 参数，您可以在节点加入时直接设置配置，就像使用 Helm 配置 values.yaml 一样便捷。这一改进大大简化了配置管理过程，提高了效率。下列指令是一个开启 MetaServer 的样例：keadm join --set modules.metaManager.enable=true,modules.metaManager.metaServer.enable=true,modules.metaManager.remoteQueryTimeout=32更多信息可参考：cid:link_8https://github.com/kubeedge/kubeedge/pull/5564 ▍封装Token，CA和证书操作，提高扩展性在本版本中，我们对 Token 和 Certificate 的处理进行了彻底的整理和优化。原先分散在代码各处的处理逻辑现在已被集中管理，显著降低了维护成本。Token 处理已被集成到一个统一的工具包中，而 Certificate 的处理则通过接口抽象化，不仅支持自建 CA 流程，还适配了通过 Kubernetes CSR 申请 Certificate 的流程。此外，我们的设计允许未来轻松扩展以支持更多类型的私钥和客户自定义的 Certificate。此次重构不仅提升了 Token 和 Certificate 业务代码的可读性和可维护性，而且保持了对外接口的完全向下兼容性，确保了现有系统的无缝升级。更多信息可参考：cid:link_9cid:link_10▍升级K8s依赖到v1.29新版本将依赖的 Kubernetes 版本升级到 v1.29.6，您可以在云和边缘使用新版本的特性。更多信息可参考：cid:link_11▍致谢感谢 KubeEdge 社区技术指导委员会(TSC)、各 SIG 成员对 v1.18.0 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_0扫码回复“Mentorship”进入技术交流群

KubeEdge在管理边缘设备必须通过mapper吗

KubeEdge是否对边缘侧异常断电场景有优化？ 

LFX Mentorship计划，由Linux Foundation组织，从19年开始为CNCF各个开源社区中的开发人员持续提供带薪实习和指导。往年已获10w+申请，发起800+课题，毕业600+实习生，发放超过230万美金报酬。2024年秋季申请时间为7月31日-8月13日，远程实习将从 9 月 3 日开始为期三个月。参与到LFX Mentorship计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为$3000美金，约合￥20000人民币）。今年KubeEdge社区在LFX Mentorship计划中准备了多个课题，感兴趣的读者可于8月13日前到官方平台申请:https://mentorship.lfx.linuxfoundation.org/  KubeEdge社区介绍  KubeEdge社区已经连续4年参与LFX Mentorship计划，过去已为学员提供20+个项目。KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目。在GitHub获得7.6k+Stars和2.1k+Fork，吸引了全球来自30+国家的100+贡献组织及16万+开发者。近年来，KubeEdge社区持续开拓创新，完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式、开源业界首个分布式协同AI基准测试Ianvs。在LFX Mentorship 2024秋季计划，KubeEdge期待再次和计算机领域新生力量一起，开拓数字未来。  面向对象  秋季计划申请者需在2024年8月13日前在LFX官网完成Mentee注册及项目申请。若被接收作为Mentee，您将能在开源社区经验丰富、积极贡献的Mentor指导下为开源项目做出贡献。依据官方规定[1]，对Mentee的申请者有以下要求:计划开始时至少年满18周岁所在单位和组织不禁止该实习未参加另外的Linux Mentorship计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)并非社区中高于最低限度贡献成员（如Maintainer、Recurring Contributor）满足具体所属项目中提及的其它前置需求  课题参与方式  根据官方安排 [2]，LFX Mentorship 2024年秋季活动流程如下：Mentee注册与项目申请 July 31 - Aug 13, 5:00 PM PDT申请者评审及人事工作 Aug 14 - 27, 5:00 PM PDT实习启动及任务发放 Sept 9 (Week 1)中期考核及首次津贴支付 Oct 15 (Week 6)结项考核、实习生报告提交，最终津贴支付批准 Nov 26, 5:00 PM PST (Week 12)活动结束 Nov 29申请者需要在8月13日前完成Mentee注册和项目申请，流程详见[3]：https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply实习申请结果预计将在 9 月 3 日通知到申请人。主线开发日期为2024年9月9日 – 11月26日，全程线上协作，无需线下参与。结项需要在2024年11月26日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。  KubeEdge课题  最后，向各位申请者推荐CNCF KubeEdge社区下列课题：▍KubeEdge: Decouple the node cooperation ability and batch management ability of the edgeapplication课题描述：EdgeApplication可以通过节点组来override应用的配置(如副本数、镜像、命令和环境)，同时节点组内的 pod 流量是闭环的(由 EdgeApplication 管理的Deployment共享一个 Service)。但是在实际场景中，需要批量操作的节点范围与需要相互协作的节点范围并不一致。因此我们需要有一种解决方案来解耦 EdgeApplication 的节点协作能力和批量管理能力。预计输出件：需求方案实现EdgeApplication可以被节点组或者指定lable的节点override解决流量闭环 前置技能：Golang, Kubernetes, KubeEdge课题导师：WillardHu | wei.hu@daocloud.ioElias Wang | wangbincheng4@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/89fe7f6c-052b-4597-9ba3-c016858b1835Github Issue：cid:link_1▍KubeEdge: Elastic Inference for Deep Learning Models Using KubeEdge课题描述：人工智能的快速发展使得深度学习模型在各个领域得到广泛应用。然而，模型推理任务所需资源可能会显著波动，尤其是在高峰期，可能会给系统的计算能力带来挑战。为了应对这种不同的负载需求，我们提出了一种利用 KubeEdge 和 Pod 水平自动扩缩(HPA) 实现推理任务动态扩缩的弹性推理解决方案。通过利用 KubeEdge，我们可以在不同的边缘设备和云资源之间分配推理任务，实现资源利用和任务处理的效率。预计输出件：基于 KubeEdge 实现弹性扩缩 AI 推理示例基于 KubeEdge 和 Sedna 实现联合推理任务的弹性扩缩的开发和输出示例输出Blog前置技能：KubeEdge，Sedna部署及管理Kubernetes的经验，包括配置及调优HPA机制开发与调优深度学习模型的知识Go与Python的编程经验课题导师：ming tang  | ming.tang@daocloud.ioShelley Bao | baoyue2@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/1f58cbe5-fe3a-4d0f-9875-b1725ecac223Github Issue：cid:link_2▍KubeEdge: Multimodal Large Model Joint Learning Algorithm: Reproduction Based on KubeEdge-Ianvs课题描述：KubeEdge-Ianvs目前主要专注于单数据模态的云边协同学习(训练和推理)。然而，诸如自动驾驶汽车等边缘设备通常会捕捉包括GPS、LIDAR和摄像头数据在内的多模态数据。单一模态的学习已经无法满足边缘设备的精确推理需求。因此，该项目旨在将主流的多模态大模型联合学习算法整合到KubeEdge-Ianvs的云边协同学习中，提供多模态学习能力。预计输出件：使用 KubeEdge-Ianvs 在边缘部署多模态大语言模型的基准测试套件修改和调整现有的边-云数据收集接口，以满足多模态数据收集的需求基于 Ianvs 实现一个多模态大语言模型 (MLLM) 基准测试套件复制主流的多模态联合学习(训练和推理)算法，并将其集成到 Ianvs 单任务学习中(可选) 在 Ianvs 的至少一种高级范式(终身学习、增量学习、联邦学习等)中测试多模态联合学习的有效性。前置技能：TensorFlow/Pytorch, LLMs, KubeEdge-Ianvs课题导师：Chuang Hu | hchuchuang@gmail.com)Zimu Zheng | zimu.zheng@huawei.com)课题链接：https://mentorship.lfx.linuxfoundation.org/project/d5d315c7-aaee-46ee-895e-a0f9e6ffed4bGithub Issue：cid:link_4▍KubeEdge: Cloud-edge collaborative speculative decoding for LLM based on KubeEdge-Ianvs课题描述：大语言模型(LLM)的自回归解码模式决定了它只能串行解码，这限制了其推理速度。可以使用推测式解码技术结合草稿模型并行解码LLM，从而在不损失准确性的情况下提高LLM的推理速度。然而，LLM的推测式解码技术并没有考虑在云边协同环境中的应用。本项目旨在基于开源的云边协同分布式机器学习平台KubeEdge-Ianvs实现云边协作推测式解码，进一步提高云边环境下LLM的推理速度。预计输出件：基于 KubeEdge-Ianvs 实现一个云边协同推测解码的示例。(可选) 提出一种更加高效的云边协同推测解码算法。前置技能：KubeEdge-Ianvs, LLM, Pytorch, Python课题导师：Shijing Hu | sjhu21@m.fudan.edu.cnZimu Zheng | zimu.zheng@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/bfa8251f-a975-4e07-8e7a-915df3518551Github Issue：cid:link_5▍KubeEdge: Integrate KubeEdge, Sedna, and Volcano for Efficient Task Scheduling课题描述：KubeEdge 和 Sedna 已经实现了云边协同训练和协同推理的能力。我们旨在与更多社区进行探索和合作，提供更强的 AI 能力。本项目旨在通过在KubeEdge与Sedna的云边协同框架内集成 Volcano实现高性能调度，从而推动分布式 AI 和边缘计算的发展。预计输出件：使用 KubeEdge 和 Sedna 成功部署训练任务，并提供example。在 Sedna 中集成 Volcano 实现高性能的训练任务调度。（可选）在 KubeEdge 中成功部署 Kubeflow，并完成训练任务的部署，输出一篇Blog前置技能：KubeEdge, KubeEdge-Sedna, Volcano课题导师：Shelley Bao | baoyue2@huawei.comFisher Xu | fisherxu1@gmail.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/49fa6dab-9cb5-4889-bbeb-66c4a5545f8fGithub Issue：cid:link_3如果对课题内容有任何问题，欢迎在GitHub仓库提交Issue或者添加社区小助手微信向社区提问。今年秋季，KubeEdge社区期待在 LFX Mentorship 见到您！Reference[1] LFX Mentorship - Application Requirement: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/am-i-eligible [2] LFX Mentorship - Program Readme: cid:link_0[3] LFX Mentorship - Mentee Application Guideline: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply扫码回复“Mentorship”进入技术交流群

华为云云原生团队欢迎你的加入！