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开发云原生车云协同平台，并且首次搭载于量产车型，这是云原生生态领域中一次全新的尝试，为车企带来开发交付效率、团队协作等方面的巨大提升。也相信云原生技术将持续推进整个车端软件的研发创新与深入应用，助力汽车行业迎来更广阔的未来。更多云原生技术动向关注容器魔方

中奖结果公示感谢各位小伙伴参与本次活动，欢迎关注华为云DTSE Tech Talk 技术直播更多活动~本次活动获奖名单如下（部分视频号抽奖用户无账号名）：账号名 奖项名称 奖品名称 wangziying007优质提问HDC定制双肩包mitenkilee优质提问HDC定制双肩包xiaozhongy官网抽奖开发者定制短袖T恤Crazy926官网抽奖开发者定制短袖T恤视频号抽奖开发者定制短袖Polo衫视频号抽奖华为云云宝手办-盲盒款视频号抽奖开发者定制折叠雨伞

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

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

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

物联网与边缘算力飞速发展，如何实现边云协同AI，让AI赋能边侧各行各业？今天16:30，华为云专家直播交流云原生边缘计算核心技术与创新布局，为你轻松匹配多行业、多场景智能化升级的云边端协同解决方案！▍直播主题边云协同新场景，KubeEdge架构设计与边缘AI实践探索▍直播时间2024.07.24（周三） 16:30-18:00▍直播简介本期直播我们将解读业界首个云原生边缘计算框架KubeEdge的架构设计，如何实现边云协同AI，将AI能力无缝下沉至边缘，让AI赋能边侧各行各业，构建智能、高效、自治的边缘计算新时代，共同探索智能边缘的无限可能！▍讲师介绍 - EliasCNCF KubeEdge社区核心成员，华为云云原生团队研发工程师，在云原生边缘计算、云原生调度、物联网等领域有深入的研究和实践经验，目前负责KubeEdge社区设计开发及生态构建，主导基于KubeEdge的云原生边缘设备管理等开发工作，保持KubeEdge技术创新和竞争力。▍直播福利：福利1：互动有礼官网直播间发口令“华为云 DTSE”抽华为云定制T恤。福利2：有奖提问直播过程中提问，评选优质问题送华为云定制双肩包。更多福利：加入微信交流群直播期间扫码入群，解锁更多隐藏福利哦~扫码观看直播

近日我们很高兴的宣布 Kmesh 发布了 v0.4.0 版本。感谢社区的贡献者在两个多月的时间里做出了巨大的努力，使得 Kmesh 取得功能完整度、稳定性、可靠性的多重提升。当前 Kmesh 相较业界其他方案已经具备显著的资源开销小和低延时等优势，后续我们会继续在核心功能和大规模稳定性等方面重点投入，争取尽快达到 GA（生产可用）。▍Kmesh 背景回顾尽管服务网格已经在过去几年持续曝光，获得了很大的知名度，但是 Sidecar 模式在资源开销、数据链路时延等方面对工作负载产生了很大的影响。所以用户在落地选型时，还是比较谨慎。除此之外，Sidecar 模式还有一个比较大的缺点是 Sidecar 与业务容器生命周期完全绑定，无法做到独立升级。因此 Kmesh 创新性的提出基于内核的 Sidecarless 的流量治理方案，将流量治理下沉到内核以解决 Sidecar 模式用户关心的一些问题。eBPF 技术非常适合四层的流量治理，加上可编程内核模块可以进行七层的流量编排。Kmesh 最早完全通过 eBPF 和内核模块进行 L4-L7 的治理。Kmesh 采用随流治理的策略，不会额外增加服务通信过程中的连接跳数，相比 Sidecar 模式，服务之间的通信连接数从三条减少到一条。为了丰富七层协议的治理能力，今年 Kmesh 增加了一种新的治理模式 Workload：远端流量治理，利用 ebpf 将流量转发到 kmesh-waypoint，进行高级的七层协议治理，这是一种更加灵活的分层治理模型，能够按需满足不同用户的需求。目前 Kmesh 基于 Istio 控制面，提供了新的服务网格数据面引擎，详细的架构如下：▍Kmesh v0.4版本关键特性解析IPv6支持以前 Kmesh 只支持采用 IPv4 通信的服务治理，但是当前 Kubernetes 集群已经默认支持双栈集群，我们不能假设服务只采用 IPv4 协议通信，因此在 0.4 版本中我们适配了 IPv6 的协议特征，支持了 IPv6 的服务治理。值得注意的是：即使在 IPv4 集群中，Java 应用在通信时，默认采用 IPv6 地址族进行通信，所以如果需要采用 Kmesh 对 Java 服务进行治理，请一定要升级 Kmesh 0.4 版本。IPv6 目前只在 Workload 模式下完整支持。请期待下一个版本中，Kmesh 本地模式（流量治理完全下沉内核）也将完全支持 IPv6 协议族。细粒度的流量治理v0.4 版本，除了按照 Namespace 进行服务的纳管以外，我们还支持了按照 pod 粒度进行流量的纳管治理。一定程度上增加了灵活性，满足了客户只针对一个命名空间下的特定工作负载进行治理的需求。特定 Pod 纳管kubectl label pod istio.io/dataplane-mode=kmesh -n {namespace}整个 Namespace 纳管kubectl label ns istio.io/dataplane-mode=kmeshKmesh 通过检查 Pod 及 Namespace 上面标签，在不同的组件中进行 Pod 的纳管。场景一：Pod 创建时已经打上了标签，那么 kmesh 通过 Kmesh-cni 在容器网络初始化的时候通知 kmesh eBPF 程序进行纳管，保证工作负载启动之前完成纳管，不会遗漏任何数据包的治理。场景二：在 pod 启动之后，再为 Pod 打上 istio.io/dataplane-mode：kmesh标签，那么 Kmesh-daemon 会监听 Pod 事件，检查到标签更新后，通知 kmesh ebpf 程序进行纳管。场景三：去掉 istio.io/dataplane-mode：kmesh 标签，允许 Pod 不被 Kmesh 纳管。这种纳管方式更加灵活，也方便了用户在发现服务访问故障之后，快速进行故障隔离，定位定界。支持集群外部服务治理在服务网格中，我们可以通过 ServiceEntry 定义网格外部服务，一般为 DNS 类型。apiVersion: networking.istio.io/v1kind: ServiceEntrymetadata: name: external-svc spec: hosts: - news.google.com location: MESH_EXTERNAL ports: - number: 80 name: http protocol: HTTP resolution: DNS对于这种服务，控制面为其生成 STRICT_DNS 类型的 Cluster, endpoint 地址为域名。eBPF 程序不能进行 DNS 解析，因此不能根据域名进行 DNAT。在 Kmesh 0.4 版本中，我们新增了 DNS 解析模块，在用户态首先进行 DNS 解析，然后重写 Cluster 将域名替换成IP地址，再刷新给 eBPF 程序进行 DNAT。典型工作原理如图所示：DNS 类型服务的治理，大大拓展了 Kmesh 服务治理的范畴，由 Kubernets 集群，扩展到外部服务。基于 eBPF 的轻量化可观测可观测性是服务网格中很重要的基础能力，对于了解数据面通信的状态具有重大意义，可以基于监控进行告警。Kmesh 采用了分层观测架构，在治理数据面，内核中存在大量可用于观测的指标数据，Kmesh 通过 eBPF 以极低的代价将这些微观、细粒度指标收集起来，并支持链路级、Pod 级等多维度信息采集；并通过 ringbuf map 上报给 kmesh-daemon 组件，daemon 中根据实时订阅的观测数据，再组织加工成用户可理解的可观测信息。当前 Kmesh 已支持以下四种监控指标，每一种指标都通过标签标识源和目的应用，用户还可以配置 Prometheus 进行采集。kmesh_tcp_connections_opened_totalkmesh_tcp_connections_closed_totalkmesh_tcp_received_bytes_totalkmesh_tcp_sent_bytes_total接下来，社区将继续丰富metrics、access log等观测的采集，并完善与Prometheus、Grafana 等观测平台的对接。在线日志级别调整动态日志级别调整对于故障诊断具有很大的帮助，早期的版本，如果要分析 bpf 数据面的问题，获取更详细的定位日志，你需要修改代码并重新构建镜像，整个过程非常低效；新版本中被彻底改善，我们支持了在线日志级别调整，用户通过 Kmesh 运维命令，可实时调整用户态 Kmesh-daemon 和 bpf 程序的日志级别。使用样例如下：#Adjust kmesh-daemon log level (e.g., debug | error | info)kubectl exec -ti -n kmesh-system kmesh-6ct4h -- kmesh-daemon log --set default:debug#Adjust kmesh eBPF data plane log levelkubectl exec -ti -n kmesh-system kmesh-6ct4h -- kmesh-daemon log --set bpf:debug除了新特性的加入，v0.4 版本在可维护性、大规模性能、可测试性等方面也做出了诸多改进。▍大规模集群支持生产环境中，根据部署业务的不同，集群规模可大可小，对于 Kmesh 来说，大规模集群更能展现 Kmesh 架构的优势，经过评估，Kmesh 需要支持 5000 服务，10万 pod 级的集群管理，以满足绝大多数生产使用诉求。对于远端模式，Kmesh 修改了 bpf map 的创建模式，支持按需申请 bpf map 中的记录，这样我们可以很容易的支持大规模集群，且不引入冗余的内存开销；对于本地模式， bpf map 更新慢的问题一直困扰着我们，原本刷新一条规则需要几十甚至上百毫秒，0.4 版本，我们优化了 map-in-map 的初始化逻辑，通过空间换时间的策略，消除了 map-in-map 的刷新耗时，将规则的刷新降低到 ms 以内，这为后续支持大规模奠定了坚实的基础。▍E2E测试Kmesh 当前正处于快速膨胀的成长期，新特性正源源不断的加入到 Kmesh 中，如何保障社区的整体质量，确保 Kmesh 平稳有序的向前发展是社区面临的重要挑战；虽然社区已经有 UT test 做功能防护，但我们还缺少黑盒视角、集群级的功能防护；为此社区引入了 E2E 测试框架，并将其部署在 PR 门禁中，这样，每个新 PR 提交时，就可以及时检查新提交对于已有功能的影响，这对于 Kmesh 非常有用，当前 E2E 测试框架已经部署上线，并增加了部分测试用例，后续将不断丰富测试集，也欢迎社区的小伙伴们共同完善Kmesh测试防护网。详细的运行E2E测试请参考cid:link_2en/docs/developer/e2e-guide/▍加入社区贡献我们希望借助在 Istio 社区长期的积累，始终以开放中立的态度发展 Kmesh，打造 Sidecarless 服务网格业界标杆方案，服务千行百业，促进服务网格健康有序的发展。Kmesh 当前正处于高速发展阶段，我们诚邀广大有志之士加入！参考链接[1] Kmesh Website：cid:link_2[2] Kmesh Release v0.4.0：cid:link_1[3] 可观测性设计：cid:link_0添加小助手k8s2222回复Kmesh进入技术交流群

▍背景通常情况下，K8s集群的容器网络平面和外部网络是隔离的，外部网络无法直接访问到集群内部的容器业务，如何为容器提供并管理统一的外部流量入口?社区提供的常见方式是使用Nodeport Service，Loadbalancer Service，Ingress等K8s资源对象来暴露集群内部的容器原生应用。Service对象提供了四层负载均衡能力，Ingress对象则提供了面向应用层访问（HTTP/HTTPS等）的七层负载均衡能力。而随着云原生架构在企业内的普遍落地，容器作为云原生微服务应用的载体，需要面对更多挑战，如面对微服务的复杂组网，业务请求在云服务之间转发往往需要做源地址转换而导致流量分发损耗；游戏类、电商抢购类等业务在短时间内会进行频繁扩缩容，必须应对高并发的网络流量；网关入口流量应对互联网的安全攻击，如灰产、异常流量，需提供流量安全防护能力；此外，支持更加复杂的路由规则配置、多种应用层协议（HTTP、HTTPS、GRPC等）、应用蓝绿发布、流量可观测性等七层高级转发能力也逐渐成为了云原生应用的普遍诉求。Ingress Nginx，Ingress Kong，Traefik等开源社区方案虽然提供了丰富的七层流量治理功能， 但对于关键生产业务上云，企业在选择Ingress方案时,除了考虑功能性,还需要充分权衡安全性、可维护性和可靠性等方面的需求，以找到最佳平衡点。专业的云服务提供商提供托管的Ingress解决方案，能够较好的应对这些挑战。华为云CCE服务提供了基于应用型负载均衡ELB（Elastic Load Balance）的全托管免运维的企业级 Ingress 流量治理，让用户轻松应对云原生应用流量管理。▍ELB Ingress 介绍在K8s集群中，容器网络平面通常是独立于集群主机网络的一个隔离的网络平面，工作负载在滚动升级或者重新调度后容器的地址会有变化，这就带来一个问题：如何实现某组Pod的服务发现，并提供固定的外部访问入口？Service和Ingress对象就是K8s中实现集群内外应用统一访问入口的一种机制。K8s社区对集群外部的流量暴露提供了三种方式：Nodeport Service、Loadbalancer Service、Ingress，前两者Service对象主要提供集群四层流量入口，Ingres对象提供七层流量治理能力。两者相互配合，共同实现K8s集群应用的对外访问机制。如下图一所示，客户端通过Ingress管理的负载均衡器，访问Ingress申明的路由，由负载均衡器将流量经过后端Service导入至后端容器。ELB Ingress是华为云CCE服务提供的七层流量治理功能，基于社区标准Ingress API实现，提供高可用、高性能、高安全、多协议的全托管免运维负载均衡能力。同时具备弹性能力，在流量突发时支持快速扩展计算资源，支持千万级并发连接，百万级新建连接，是云原生应用流量治理的理想选择。▍ELB Ingress工作原理ELB Ingress部署于CCE集群的master节点上，与ELB实例对接，可将Ingress申明的容器后端地址、转发策略、路由等信息配置至ELB实例，并且支持动态更新。图二是基于Nodeport中转的ELB Ingress工作流图，CCE Standard集群使用该方案的原理如下：用户为集群创建Ingress资源，在Ingress中配置流量访问规则，如负载均衡器实例、URL路由、SSL证书等监听信息，以及访问的后端Service等，控制器通过标签选择器选中工作负载，将工作负载所在节点和Nodeport端口挂载至负载均衡器实例的后端；Ingress Controller监听到Ingress资源发生变化时，会根据其中定义的流量访问规则，在ELB侧重新配置监听器以及后端服务器路由;用户通过ELB访问应用程序，流量根据ELB中配置的转发策略转发到对应的Node节点，再经过Nodeport二次转发访问到关联的工作负载(Nodeport转发机制参见k8s官方文档说明)。该方案中流量经过节点、IPTables/IPVS规则多次转发，网络性能存在损耗。在大流量场景下，网络转发效率、网络连通速度的挑战尤为突出。为此，我们推出了基于CCE Turbo集群的网络加速方案：容器直接使用VPC网络实现直通容器的ELB Ingress，将原有的“容器网络 + 虚拟机网络“两层模型简化为一层。如图三所示，集群中的Pod IP直接从VPC中分配，支持北向ELB直通容器，外部流量可以不经过节点端口转发直接访问集群中的Pod，达到流量分发零损耗的效果。▍ELB Ingress流量治理核心优势ELB Ingress基于原生Kubernetes Ingress，通过声明式API指定Ingress的路由、对接的后端服务，或者通过Annotation配置监听侧的高级选项，由系统保证最终一致性。ELB Ingress为开发者和运维人员提供了极大的开发灵活性和维护便利性，其核心优势包括：高吞吐、高可用、高弹性ELB Ingress搭配独享型ELB实例，最高支持2千万并发连接；通过完善的健康检查机制，保障业务实时在线，支持多可用区的同城双活容灾，无缝实时切换；弹性规格ELB实例支持根据流量负载自动弹性扩缩实例规格，适用于业务用量波动较大的场景，例如游戏、视频等行业，能满足瞬时流量同时成本最小化。高安全性ELB Ingress提供了端到端的全链路安全策略，如下图四是外部流量经过ELB访问CCE Turbo集群的简单示例：在访问端可配置接入WAF引擎检测并拦截恶意攻击流量，而正常流量转发至后端云服务器。通过Ingress的Annotation配置可轻松为ELB实例配置自定义安全策略，例如设置黑白名单，双向认证等。从ELB转发至后端也支持HTTPS加密信道，进一步增强整体安全性。可移植性完全兼容社区Ingress语义，从开源Nginx Ingress等方案迁移过来仅需改造annotation即可轻松适配。可观测性云监控可以按时间轴查看ELB的网络流量和访问日志，动态分析并告警潜在风险；云审计可以实时监控ELB资源更新日志，针对风险动作实时告警，动态监控云上资源安全；Ingress Controller也支持丰富的普罗监控指标，如接口调用时延，reload次数等。免维护性ELB Ingress组件运行在集群的Master节点，用户无需关注运维问题，组件在集群升级时会自动更新，且对业务无感。▍ELB Ingress流量治理核心功能在社区基础功能之上，华为云ELB Ingress在负载均衡、路由规则、流量控制、安全性和可观测性等方面都有较大增强，满足了更复杂的生产环境需求。下面介绍ELB Ingress流量治理核心功能：灰度发布灰度发布是业界常用的版本升级平滑过渡的一种方式。在版本升级时，先让部分用户使用新版本，其他用户继续使用老版本。待新版本稳定后，再逐步扩大新版本的使用范围，直到所有用户流量都迁移到新版本上。这样可以最大限度地控制新版本发布带来的业务风险，降低故障影响范围，同时支持快速回滚。我们提供了基于Header/Cookie/Weight的灰度发布策略，前两种策略通过将用户分成若干组，在不同的时间段内逐步引入新版本，最终扩大新版本的影响范围；基于Weight的策略则是通过控制新版本的权重，在不同时间段内逐步增加新版本的流量比例，直到完全替代旧版本。高级转发策略随着云原生应用组网的日益复杂，传统的基于路由转发的七层流量治理已经难以满足需求。我们提供的高级转发策略可以很好地解决传统方案面临的局限性：基于请求头的负载均衡：根据客户端请求头的不同值，将请求分配到不同的后端服务器。HTTP重定向到HTTPS：系统自动将HTTP监听器流量转发至HTTPS监听，提升网站安全性，防止内容篡改等。URL重定向和重写：支持将URL永久或临时映射到另一个URL。同时，支持正则表达式匹配和实现不同路径的重写规则。慢启动在应用滚动升级时，ELB Ingress会自动更新负载均衡器后端，并且根据后端容器实例副本数自动设置后端权重。但是，在后端健康检查通过后的上线过程中，可能面临流量突增，导致后端容器的CPU或内存资源瞬间高负荷，从而影响业务稳定性。在开启慢启动模式后，系统可以在指定时间内，逐步将流量导入到目标容器后端。这样可以缓解业务容器突增的流量压力，保护系统免受过度负载的影响，实现优雅过渡。▍小结华为云CCE服务的ELB Ingress基于华为云应用型负载均衡ELB（Elastic Load Balance）提供强大的Ingress流量管理能力，兼容Nginx Ingress，具备处理复杂业务路由和证书自动发现的能力，支持HTTP、HTTPS和GRPC等协议，满足在云原生应用场景下对超强弹性和大规模七层流量处理能力的需求。后续我们还将发布系列文章，详细介绍基于ELB Ingress的流量管理最佳实践，欢迎各位读者继续关注。相关链接：华为云云容器引擎CCE服务路由概述：cid:link_3Ingress官方文档：cid:link_24步快速使用云容器引擎01注册账号，并登录CCE控制台点击注册帐号，并授予IAM用户相应的权限。登录CCE控制台帐号无需授权即可拥有所有权限，由帐号创建的IAM子用户需要授予相应的权限才能使用CCE，具体请参见权限管理。02 创建集群如果您需要创建普通Kubernetes集群，请参见快速创建Kubernetes集群。03 部署工作负载通过镜像或编排模板创建工作负载（应用）。· 创建无状态工作负载（Nginx）· 部署有依赖关系的WordPress和MySQL04 生命周期管理查看部署后工作负载的状态和日志信息，对工作负载进行相应的升级、伸缩和监控等。具体请参见管理工作负载和任务