使用 CCE 需要关注哪些配额限制？

 CCE 集群升级时，ELB Ingress 与 ELB 配置不一致如何处理？

集群如何解冻操作，有大佬知道吗

处于非运行状态（例如冻结、不可用状态）中的集群，如何清除残留资源?

 弹性云服务器基于虚拟化技术构建，单实例可视为一台虚拟机，但其本质是具备弹性伸缩、按需付费特性的云服务，远超传统虚拟机范畴。弹性云服务器共担模型：云平台保障底层基础设施和虚拟化层安全；用户则需负责操作系统加固、应用安全、防火墙（安全组）配置及数据加密。平台本身提供安全基础，但最终安全性高度依赖用户的安全运维实践。因此，它既是安全的，也存在风险，安全与否主要取决于用户自身的配置与管理水平。  一、弹性云服务器是虚拟机吗？要回答这个问题，我们需要从技术和演进两个层面来理解。1. 从技术实现上看：是的，但非传统意义上的虚拟机弹性云服务器在Hypervisor（虚拟机监视器）之上创建和运行。Hypervisor是一种将物理服务器硬件（CPU、内存、存储、网卡）进行虚拟化，并抽象为多个独立、隔离的虚拟硬件环境的软件层。每个云服务器实例都运行在这样一个虚拟化的硬件环境中，拥有自己的操作系统（Guest OS）。从这个角度看，单台弹性云服务器的诞生方式与传统VMware、Hyper-V创建的虚拟机（VM）在技术原理上同源。2. 从演进与赋能上看：不是，它是云时代的革命性产品尽管技术同源，但将云服务器简单等同于传统虚拟机是片面且过时的。二者的核心差异在于“弹性”与“管理”模式：资源形态：传统虚拟机资源固定（如分配4核8G，则长期独占该资源），而云服务器的资源是池化、弹性可伸缩的。您可以随时按需升降配CPU、内存，甚至无需重启，这是传统虚拟机难以企及的。获取方式：传统虚拟机需自行部署硬件和虚拟化软件，耗时数天甚至数周。云服务器则通过Web控制台或API秒级交付，即刻可用。运维模式：传统虚拟机需要用户自己维护底层的物理服务器、Hypervisor和虚拟化网络。而云服务器由云厂商负责所有底层基础设施的维护、冗余和稳定性，用户**专注于实例内部的应用，实现了运维的极大简化。结论：弹性云服务器基于虚拟化技术，但其价值远超越传统虚拟机。它是集成了计算、网络、存储的云服务单元，其“弹性”、“按需”和“自助服务”的特性，是传统虚拟机概念在云计算时代的一次质的飞跃。二、安全性全景透视：从技术栈到管理闭环🔍 常见担忧溯源用户对安全性的焦虑主要集中于三点：① 多租户环境下的数据隔离风险；② 网络攻击面的扩大；③ 服务商自身的可靠性。事实上，主流云厂商已构建起多层防护体系，但这些措施往往因技术门槛而被忽视。🛡️ 六大安全防线拆解硬件级隔离采用Intel VT-d/AMD-Vi等芯片级虚拟化技术，确保不同租户的计算资源完全隔离，即使同一物理机上的其他用户遭受攻击，也不会影响您的业务。网络边界防护VPC（虚拟私有云）划分独立网络空间，配合安全组规则精细控制入站/出站流量；NAT网关隐藏内网IP，防止公网直接暴露；Web应用防火墙（WAF）拦截SQL注入、XSS等常见攻击。数据加密全链路覆盖传输层强制TLS加密，存储层支持国密算法SM4/RSA双重加密；密钥管理系统（KMS）实现敏感数据的权限分级管控。身份与访问管理（IAM）多因素认证（MFA）替代弱密码；细粒度的角色权限分配，限制高危操作；操作日志全程审计，异常行为实时告警。灾难恢复体系跨可用区的数据冗余备份，RPO接近零；快照功能可快速回滚至任意时间点；冷备数据中心应对区域性灾害。合规与审计通过ISO 27001、等保三级等认证，定期接受第三方渗透测试，并提供完整的合规报告。⚠️ 警惕隐性风险尽管云服务商提供了完善的基础设施，但最终安全仍取决于用户的配置策略。例如：未及时修补系统漏洞、过度开放端口权限、弱密码策略等，均可能导致安全事件。建议遵循“最小权限原则”，仅开放必要端口，并启用自动化补丁更新。三、如何选择可靠的弹性云服务？📊 决策checklist 💡 实操建议压力测试先行：模拟真实业务负载，验证弹性扩缩容的稳定性；混合云过渡：将非核心业务迁移至云端，逐步建立信任；持续监控：利用云平台的监控工具，设置CPU/内存/带宽的使用阈值告警。总结弹性云服务器是虚拟机吗？它是虚拟化技术的产物，但更是超越了传统虚拟机概念的、具备弹性伸缩能力的云计算服务单元。安全吗？云平台提供的底层基础设施本身是高度安全的。但最终的安全性取决于用户如何管理和配置自己的云服务器。云服务器提供了构建安全环境的基础工具和能力，但“安全”更像是一个需要用户持续维护的状态，而非一个一劳永逸的属性。因此，选择一家技术雄厚、运维规范的云平台是基础，而用户自身具备良好的安全意识和运维习惯，才是保障弹性云服务器安全最坚固的防线。

Karmada[1] 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。Karmada v1.15 [2] 版本现已发布，本版本包含下列新增特性：多模板工作负载的资源精确感知集群级故障迁移功能增强结构化日志Karmada 控制器和调度器性能显著提升  新特性概览  ▍多模板工作负载的资源精确感知Karmada 利用资源解释器获取工作负载的副本数和资源请求，并据此计算工作负载所需资源总量，从而实现资源感知调度，联邦配额管理等高阶能力。这种机制在传统的单模板工作负载中表现良好。然而，许多AI大数据应用的工作负载  CRD（如 FlinkDeployments，PyTorchJob 和 RayJob 等）包含多个 Pod 模板或组件，每个组件都有独特的资源需求。由于资源解释器仅能处理单个模板的资源请求，无法准确反映不同模板间的差异，导致多模板工作负载的资源计算不够精确。在这个版本中，Karmada 强化了对多模板工作负载的资源感知能力，通过扩展资源解释器，Karmada 现在可以获取同一工作负载不同模板的副本数和资源请求，确保数据的精确性。这一改进也为多模板工作负载的联邦配额管理提供了更加可靠和精细的数据支持。假设你部署了一个 FlinkDeployment，其资源相关配置如下:spec:  jobManager:    replicas: 1    resource:      cpu: 1      memory: 1024m  taskManager:    replicas: 1    resource:      cpu: 2      memory: 2048m通过 ResourceBinding，你可以查看资源解释器解析出的 FlinkDeployment 各个模板的副本数以及资源请求。spec:  components:  - name: jobmanager    replicaRequirements:      resourceRequest:        cpu: "1"        memory: "1.024"    replicas: 1  - name: taskmanager    replicaRequirements:      resourceRequest:        cpu: "2"        memory: "2.048"    replicas: 1此时，FederatedResourceQuota 计算的 FlinkDeployment 占用的资源量为： status:     overallUsed:       cpu: "3"       memory: 3072m注意：该特性目前处于 Alpha 阶段，需要启用 MultiplePodTemplatesScheduling 特性开关才能使用。随着多模板工作负载在云原生环境中的广泛应用，Karmada 致力于对其提供更强有力的支持。在接下来的版本中，我们将基于此功能进一步加强对多模板工作负载的调度支持，提供更加细粒度的资源感知调度——敬请期待更多更新！更多有关此功能的资料请参考：多 Pod 模板支持[3]▍集群级故障迁移功能增强在之前的版本中，Karmada 提供了基本的集群级故障迁移能力，能够通过自定义的故障条件触发集群级别的应用迁移。为了满足有状态应用在集群故障迁移过程中保留其运行状态的需求，Karmada 在 v1.15 版本支持了集群故障迁移的应用状态中继机制。对于大数据处理应用（例如 Flink），利用此能力可以从故障前的 checkpoint 重新启动，无缝恢复到重启前的数据处理状态，从而避免数据重复处理。社区在 PropagationPolicy/ClusterPropagationPolicy API 中的 .spec.failover.cluster 下引入了一个新的 StatePreservation 字段， 用于定义有状态应用在故障迁移期间保留和恢复状态数据的策略。结合此策略，当应用从一个故障集群迁移到另一个集群时，能够从原始资源配置中提取关键数据。状态保留策略 StatePreservation 包含了一系列 StatePreservationRule 配置，通过 JSONPath 来指定需要保留的状态数据片段，并利用关联的 AliasLabelName 将数据传递到迁移后的集群。以 Flink 应用为例，在 Flink 应用中，jobID 是一个唯一的标识符，用于区分和管理不同的 Flink 作业（jobs）。当集群发生故障时，Flink 应用可以利用 jobID 来恢复故障前作业的状态，从故障点处继续执行。具体的配置和步骤如下：apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata:  name: foospec:  #...  failover:    cluster:      purgeMode: Directly      statePreservation:        rules:          - aliasLabelName: application.karmada.io/cluster-failover-jobid           jsonPath: "{ .jobStatus.jobID }"迁移前，Karmada 控制器将按照用户配置的路径提取 job ID。迁移时，Karmada 控制器将提取的 job ID 以 label 的形式注入到 Flink 应用配置中，比如 application.karmada.io/cluster-failover-jobid : <jobID>。运行在成员集群的 Kyverno 拦截 Flink 应用创建请求，并根据 jobID  获取该 job 的 checkpoint 数据存储路径，比如  /<shared-path>/<job-namespace>/<jobId>/checkpoints/xxx，然后配置 initialSavepointPath 指示从save point 启动。Flink 应用根据 initialSavepointPath 下的 checkpoint 数据启动，从而继承迁移前保存的最终状态。该能力广泛适用于能够基于某个 save point 启动的有状态应用程序，这些应用均可参考上述流程实现集群级故障迁移的状态中继。注意：该特性目前处于 Alpha 阶段，需要启用 StatefulFailoverInjection 特性开关才能使用。功能约束：应用必须限定在单个集群中运行；迁移清理策略（PurgeMode）限定为 Directly，即需要确保故障应用在旧集群上删除之后再在新集群中恢复应用，确保数据一致性。▍结构化日志日志是系统运行过程中记录事件、状态和行为的关键工具，广泛用于故障排查、性能监控和安全审计。Karmada 组件提供丰富的运行日志，帮助用户快速定位问题并回溯执行场景。在先前版本中，Karmada 仅支持非结构化的文本日志，难以被高效解析与查询，限制了其在现代化观测体系中的集成能力。Karmada 在 1.15 版本引入了结构化日志支持，可通过 --logging-format=json 启动参数配置 JSON 格式输出。结构化日志示例如下：{  "ts":“日志时间戳”,  "logger":"cluster_status_controller",  "level": "info",  "msg":"Syncing cluster status",  "clusterName":"member1"}结构化日志的引入显著提升了日志的可用性与可观测性：高效集成：可无缝对接 Elastic、Loki、Splunk 等主流日志系统，无需依赖复杂的正则表达式或日志解析器。高效查询：结构化字段支持快速检索与分析，显著提升故障排查效率。可观察性增强：关键上下文信息（如集群名、日志级别）以结构化字段呈现，便于跨组件、跨时间关联事件，实现精准问题定位。可维护性提升：结构化日志使开发者和运维人员在系统演进过程中更易于维护、解析和调整日志格式，保障日志体系的长期稳定与一致性。▍Karmada 控制器和调度器性能显著提升在本次版本中，Karmada 性能优化团队继续致力于提升 Karmada 关键组件的性能，在控制器和调度器方面取得了显著进展。控制器方面，通过引入优先级队列，控制器能够在重启或切主后优先响应用户触发的资源变更，从而显著缩短服务重启和故障切换过程中的停机时间。测试环境包含 5,000 个 Deployment、2,500 个 Policy 以及 5,000 个 ResourceBinding。在控制器重启且工作队列中仍有大量待处理事件的情况下，更新 Deployment 和 Policy。测试结果显示，控制器能够立即响应并优先处理这些更新事件，验证了该优化的有效性。注意：该特性目前处于 Alpha 阶段，需要启用 ControllerPriorityQueue 特性开关才能使用。调度器方面，通过减少调度过程中的冗余计算，降低远程调用请求次数，Karmada 调度器的调度效率得到了显著提升。测试记录了在开启精确调度组件 karmada-scheduler-estimator 情况下，调度 5,000 个 ResourceBinding 所用的时间，结果如下：调度器吞吐量 QPS 从约 15 提升至约 22，性能提升达 46%；gRPC 请求次数从约 10,000 次减少至约 5,000 次，降幅达 50%。这些测试证明，在 1.15 版本中，Karmada 控制器和调度器的性能得到了极大提升。未来，我们将继续对控制器和调度器进行系统性的性能优化。相关的详细测试报告，请参考 [Performance] Overview of performance improvements for v1.15[4]   致谢贡献者  Karmada v1.15 版本包含了来自 39 位贡献者的 269 次代码提交，在此对各位贡献者表示由衷的感谢：贡献者列表： 参考资料[1] Karmada: https://karmada.io/[2] Karmada v1.15: https://github.com/karmada-io/karmada/releases/tag/v1.15.0[3] 多 Pod 模板支持: https://github.com/karmada-io/karmada/tree/master/docs/proposals/scheduling/multi-podtemplate-support[4] [Performance] Overview of performance improvements for v1.15: https://github.com/karmada-io/karmada/issues/6516 Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada 官网：https://karmada.io/GitHub 地址：https://github.com/karmada-io/karmadaSlack 地址：https://slack.cncf.io/（#karmada） 添加社区小助手k8s2222回复Karmada进入技术交流群 

华为云CCE智能助手是依托盘古大模型与DeepSeek等领先LLM技术构建的全栈AI驱动的智能服务助手，贯穿智能问答、智能推荐、智能诊断、智能优化等全流程容器使用场景，辅助您提升运维和管理效率。当前已支持智能问答、智能诊断与恢复等能力。  云容器引擎CCE服务意见反馈链接直达：cid:link_0 

云计算BU通用计算服务产品部 2026届应届生招聘➯ 部门介绍在云计算的浪潮中，我们在Kubernetes等云原生技术领域有10余年的技术积累。我们致力于成为技术创新先锋，通过云原生容器化技术，为企业数字化转型提供强大动力。让云无处不在，让智能无所不及，共建智能世界云底座。品牌引领：连续5年云容器软件市场份额国内TOP1，Gartner容器管理魔力象限领导者，Omdia评价产品战略与执行全球第一，业务遍布国内外互联网、金融、政企等多个领域。技术创新：云原生基金会国内唯一初始成员，全球首位CNCF技术监督委员会华人副主席，CNCF基础设施技术负责人，CNCF工作负载技术负责人。主导开源 KubeEdge、Volcano、Karmada、Kuasar、Kmesh等多个云原生开源项目。华为云容器与Serverless团队持续构建AI基础设施，加大在云原生 AI、Serverless架构、多云和混合云战略、云边端协同、函数计算等领域的战略投入，以技术革新为驱动，打造业界领先的云原生解决方案。团队基于云原生技术构建大规模训推一体AI基础设施，助力华为云内外部在汽车、互联网、金融等领域的多个客户实现AI创新。热忱欢迎优秀学子加入我们!  更多云原生技术动向关注容器魔方  【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_3 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

超融合（Hyper-Converged Infrastructure, HCI）与虚拟化（Virtualization）是现代数据中心转型的两大支柱技术，但二者在架构设计、功能定位和技术目标上存在本质差异。本文通过拆解两者的技术架构、核心组件及典型应用场景，揭示其互补而非替代的关系，并提供基于业务需求的选型策略。文章聚焦资源调度效率、运维复杂度、扩展性和TCO（总体拥有成本）等关键维度，为企业IT架构规划提供决策依据。 超融合和虚拟化的五大区别对比 1. 引言：概念澄清与常见误区许多用户将超融合视为“高级版的虚拟化”，实则不然。虚拟化的核心是通过软件层抽象物理资源（CPU、内存、存储、网络），实现资源的池化分配和动态调度；而超融合则是将计算、存储、网络三大资源深度融合于同一平台，并通过统一管理平面实现自动化运维。简而言之：虚拟化解决的是“资源孤立”问题（将多台物理机虚拟化为资源池）；超融合解决的是“复杂集成”问题（将分布式资源整合为统一的基础设施）。这种本质差异决定了两者适用于不同的业务场景和技术阶段。2. 技术架构对比：分层解耦VS深度融合维度传统虚拟化超融合架构设计分层架构（计算→存储→网络独立部署）分布式架构（计算/存储/网络融合部署）核心组件vSphere/ESXi（计算）、SAN/NAS（存储）、独立交换机（网络）标准化x86服务器+分布式存储+软件定义网络（SDN）资源调度集中式控制器（如vCenter）分布式调度（每节点自主管理资源）存储模式外部共享存储（FC/iSCSI）本地磁盘直连+分布式存储算法扩展方式纵向扩展（增加单台主机配置）横向扩展（增加节点数量）管理界面多套独立管理系统（计算/存储/网络）统一管理平台（单一界面控制所有资源）关键技术差异点：✅ 虚拟化依赖外部存储：传统虚拟化方案需外接SAN/NAS存储，导致存储成为性能瓶颈和单点故障风险；✅ 超融合内置分布式存储：采用Ceph、GlusterFS等开源存储技术，利用本地SSD/HDD构建冗余存储池，消除外部存储依赖；✅ 网络架构革新：超融合通常集成SDN（软件定义网络），支持VXLAN隧道和策略驱动的网络配置，而传统虚拟化多依赖静态VLAN划分。3. 核心能力对比：从功能到性能① 灵活性与快速部署指标虚拟化超融合新虚拟机上线时间分钟级（需手动分配资源）秒级（自助式门户一键部署）跨集群迁移复杂（需复制镜像至新存储阵列）无缝（基于分布式存储自动同步）混合云支持有限（需第三方工具对接）原生支持（统一API对接公有云）② 性能表现场景虚拟化超融合随机I/O密集型受限于外部存储延迟（约5ms）本地存储响应（<1ms）顺序读写吞吐量受SAN带宽限制（约2GB/s）分布式聚合带宽（可达数十GB/s）网络转发性能依赖物理交换机背板带宽SDN软交换灵活调度③ 运维复杂度任务虚拟化超融合故障排查需跨团队协作（计算+存储+网络）统一日志与告警系统补丁升级多组件独立升级（易出错配）滚动升级（最小化业务中断）容量规划需单独评估计算/存储/网络需求按节点整体扩容4. 典型应用场景对比业务类型适用方案原因说明小型企业IT基础架构超融合一站式部署，降低初期采购和维护成本大型数据库集群虚拟化+高性能存储专用存储设备保障事务一致性和低延迟开发测试环境超融合快速克隆模板，支持多样化操作系统灾备中心建设虚拟化+异地复制成熟可靠的存储级容灾方案VDI桌面虚拟化超融合分布式存储支持海量非结构化数据大数据实时分析虚拟化+高速存储裸金属性能满足MPP数据库需求5. 选型决策矩阵判断条件优先选择虚拟化优先选择超融合现有IT团队经验丰富✅（延续现有运维体系）⚠️（需学习新技术栈）业务对存储性能敏感❌（外部存储延迟高）✅（本地存储低延迟）预算有限且需快速上线⚠️（多设备采购成本高）✅（标准化硬件堆叠）需要混合云能力⚠️（集成复杂度高）✅（原生多云管理接口）已有高端存储设备✅（利旧现有投资）⚠️（重复建设存储系统）合规要求严格的行业✅（成熟审计案例）⚠️（新兴技术需验证）6. 未来趋势：融合共生的技术演进当前技术发展呈现两大趋势：🔹 虚拟化向轻量化演进：Kubernetes容器化逐步取代传统虚拟机，降低启动时间和资源开销；🔹 超融合向智能化升级：引入AI运维（AIOps）实现预测性维护，结合边缘计算拓展分布式场景。未来的混合架构可能是：底层采用超融合提供标准化资源池，上层运行虚拟化/容器化应用，形成“稳态+敏态”共存的弹性架构。结论：根据业务阶段选择最优解企业发展阶段推荐方案核心价值初创期/中小型企业超融合快速部署、低成本、简单运维成长期/大型企业虚拟化+超融合混合部署关键业务保障+创新业务敏捷成熟期/集团企业虚拟化为主+超融合补充稳定性优先+局部敏捷迭代最终建议：新建数据中心：优先考虑超融合，简化架构并加速数字化进程；存量系统改造：保留核心业务在虚拟化环境，新增业务逐步迁移至超融合；混合云战略：采用超融合作为私有云底座，无缝对接公有云资源。

华为云师资培训系列直播间抽奖公布如下：华为云师资培训——《云计算》课程直播抽奖公布序号姓名直播活动场次抽奖类型轮次本轮奖品中奖人账号1鲍*泓华为云师资培训——《云计算》课程口令抽奖1HDC定制雨伞b43***c2朱*星华为云师资培训——《云计算》课程口令抽奖1HDC定制雨伞233***a3涂*明华为云师资培训——《云计算》课程口令抽奖1HDC定制雨伞57a***64秦*煜华为云师资培训——《云计算》课程口令抽奖2HDC定制T恤d53***15鄂*龙华为云师资培训——《云计算》课程口令抽奖2HDC定制T恤3d4***96张*华为云师资培训——《云计算》课程在线时长抽奖3华为耳机8b2***d　华为云师资培训——《软件工程》课程直播抽奖公布序号姓名直播活动场次抽奖类型轮次本轮奖品中奖人账号1钟*山华为云师资培训——《软件工程》课程口令抽奖1HDC定制雨伞238***32孙*峰华为云师资培训——《软件工程》课程口令抽奖1HDC定制雨伞8af***93逄*勒华为云师资培训——《软件工程》课程口令抽奖1HDC定制雨伞650***a4　华为云师资培训——《软件工程》课程口令抽奖2HDC定制T恤fe9***75吴*伟华为云师资培训——《软件工程》课程口令抽奖2HDC定制T恤3e6***e6邱*志华为云师资培训——《软件工程》课程在线时长抽奖3华为耳机c3d***3　华为云师资培训——《大数据》课程直播抽奖公布序号姓名直播活动场次抽奖类型轮次本轮奖品中奖人账号1祝*哲华为云师资培训——《大数据》课程口令抽奖1HDC定制雨伞10a***82陈*华为云师资培训——《大数据》课程口令抽奖1HDC定制雨伞b3b***c3彭*和华为云师资培训——《大数据》课程口令抽奖1HDC定制雨伞3c7***d4小*华为云师资培训——《大数据》课程口令抽奖2HDC定制T恤512***95李*华为云师资培训——《大数据》课程口令抽奖2HDC定制T恤521***a6戴*华为云师资培训——《大数据》课程在线时长抽奖3华为耳机b38***1*未填写收件信息的视为自动放弃。

8月6日，Gartner正式发布2025《容器管理魔力象限》报告，华为云进入领导者象限。根据Gartner Peer Insight客户评价系统最新数据，华为云容器获得全球客户认可得分4.7分，在参评厂商中排名第一。我们相信，此次入选得益于华为云对云原生2.0的深入践行和战略投入，在业界率先发布CCE Turbo、CCE Autopilot、云容器实例CCI以及分布式云原生服务UCS等多款创新性容器产品，为用户提供可在公有云、分布式云、混合云、边缘运行大规模可扩展容器负载的最佳云原生基础设施。 华为云在新云原生应用、存量应用容器化、AI容器、边缘应用以及混合云应用等所有用例中均具有竞争力，尤其是在AI容器领域表现尤为突出。华为云积极参与开源，引领云原生技术生态，为82个云原生计算基金会（CNCF）项目做出贡献，贡献数量排名第二。华为云参与并捐赠给CNCF的开源项目包括KubeEdge、Volcano、Karmada、Kmesh和Kuasar等，已被全球企业广泛采用。华为云提供业界最完整的容器产品矩阵，覆盖公有云、分布式云、混合云、边缘等场景，已广泛应用到互联网、金融、制造、交通、电力、汽车等行业，释放无处不在的云原生价值。与此同时，华为云容器服务积极全球化布局，云原生算力爆发性增长，受到全球用户广泛认可，持续帮助客户取得商业成功。面向AI时代，云原生2.0全面智能化升级，华为云构建智能驱动的全新一代AI-Native云原生基础设施。Cloud for AI方面，CCE智算集群作为CloudMatrix384 超节点的云原生基础设施，可提供大规模超节点拓扑感知调度、PD分离扩缩容、AI负载感知的弹性伸缩以及容器极速启动等能力，大幅加速AI训练和推理，提升AI任务运行效率。与此同时，AI技术也在重塑云服务体验，华为云践行AI for Cloud，全新发布CCE Doer，以AI Agent方式嵌入容器使用全流程，贯穿智能问答、智能推荐、智能诊断等业务流程，支持200+关键异常场景诊断，根因定位准确率超过80%，实现容器集群管理自动化与智能化。云原生加速向Serverless演进，华为云提供Serverless Kubernetes集群CCE Autopilot和Serverless容器实例CCI两款Serverless容器产品，帮助用户专注于构建应用程序，助力企业加速业务创新。全新发布的通用型（轻享）、鲲鹏通用型两种高性价比Serverless容器算力，性价比最高可提升40%，是企业应对10倍潮汐业务的最优弹性方案。在未来，华为云将继续秉持携手创新、成就共享的理念，深耕云原生领域，帮助全球企业重塑业务模式，加快重塑千行万业，为建设包容、普惠、有韧性的数字世界注入新动力。来源：Gartner, Magic Quadrant for Container Management, 6 August 2025免责声明：Gartner 并未在其研究报告中支持任何供应商、产品或服务，也并未建议科技用户只选择该等获最高评分或其它称号的供应商。Gartner 的研究报告含有 Gartner 研究与顾问组织的意见，且该意见不应被视作事实陈述。就该研究报告而言，Gartner 放弃做出所有明示或默示的保证，包括任何有关适销性或某一特定用途适用性的保证。GARTNER 和MAGIC QUADRANT是 Gartner, Inc. 和/或其关联公司在美国和国际上的商标，并在获得许可的情况下在此使用。保留所有权利。 更多云原生技术动向关注容器魔方  【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_3 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

LFX Mentorship 计划，由 Linux Foundation 组织，从19年开始为 CNCF 各个开源社区中的开发人员持续提供带薪实习和指导。往年已获20k+申请，发起1500+课题，毕业超千名实习生，发放超过320万美金报酬。2025年秋季申请时间为 7月31日-8月12日，远程实习将从9月8日开始为期三个月。参与到 LFX Mentorship 计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为$3000美金，约合￥20000人民币）。 今年 KubeEdge 社区在 LFX Mentorship 计划中准备了多个课题，感兴趣的读者可于8月12日前点击阅读全文，或到官方平台申请：https://mentorship.lfx.linuxfoundation.org/  KubeEdge社区介绍  KubeEdge 社区已经连续5年参与 LFX Mentorship 计划，过去已为学员提供30+个项目。KubeEdge 是业界首个云原生边缘计算框架、云原生计算基金会内部唯一毕业级边缘计算开源项目。在 GitHub 获得 8.2k+Stars和2.3k+Fork，吸引了全球来自35+国家的120+贡献组织及1800+开发者。近年来，KubeEdge 社区持续开拓创新，完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同 AI 框架 Sedna 及业界首个边云协同终身学习范式、开源业界首个分布式协同 AI 基准测试 Ianvs。在 LFX Mentorship 2025秋季计划，KubeEdge 期待再次和计算机领域新生力量一起，开拓数字未来。   面向对象  秋季计划申请者需在2025年8月12日前在 LFX 官网完成 Mentee 注册及项目申请。若被接收作为 Mentee，您将能在开源社区经验丰富、积极贡献的 Mentor 指导下为开源项目做出贡献。依据官方规定[1]，对 Mentee 的申请者有以下要求:计划开始时至少年满18周岁所在单位和组织不禁止该实习未参加另外的 Linux Mentorship 计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)并非社区中高于最低限度贡献成员（如Maintainer、Recurring Contributor）满足具体所属项目中提及的其它前置需求  课题参与方式  根据官方安排 [2]，LFX Mentorship 2025年秋季活动流程如下：Mentee 注册与项目申请 7月31日-8月12日申请者评审及人事工作 8月13日-8月26日实习启动及任务发放 9月8日中期考核及首次津贴支付 10月14日结项考核、实习生报告提交，最终津贴支付批准 11月25日 活动结束 11月28日申请者需要在8月12日前完成 Mentee 注册和项目申请，流程详见 [3]：https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply实习申请结果预计将在8月27日通知到申请人。主线开发日期为2025年9月8日 – 11月28日，全程线上协作，无需线下参与。结项需要在2025年9月28日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。  KubeEdge课题   最后，向各位申请者推荐 CNCF KubeEdge 社区下列课题：▍KubeEdge: Deep Integration with AMD Edge Nodes (2025 Term 3)课题描述：AMD 芯片凭借其强大的 x86 架构、卓越的计算性能和先进的 NPU，在工业自动化、车载系统和高性能边缘计算等领域展现出显著潜力。将 AMD 强大的通用和异构计算能力引入 KubeEdge 生态系统，对于处理日益复杂和延迟敏感的边缘 AI 应用至关重要。然而，KubeEdge 与 AMD 高性能边缘平台之间的深度集成、性能优化和最佳实践，特别是它们内置的 NPU 和其他硬件加速单元，仍需系统性的探索和验证。本项目旨在建立 KubeEdge 与 AMD 边缘节点之间的完整链接，从硬件部署到 NPU 加速构建一个综合的边缘计算解决方案，从而极大丰富 KubeEdge 的硬件生态系统。预计输出件：支持 KubeEdge 边缘节点运行在 AMD 芯片上，并成功部署边缘应用通过 KubeEdge 调度和管理 AMD NPU 资源，以实现边缘 AI 推理应用的性能加速实现节点、应用和 NPU 的监控和指标收集使用 KubeEdge 实现从云到 AMD 边缘节点的完整平台设置、配置和管理完成硬件兼容性测试，并输出技术文档或博客前置技能：KubeEdge, Go, Linux, Hardware Integration, AI/ML课题导师：Hongbing Zhang (@HongbingZhang)hongbing.zhang@daocloud.ioShelley Bao (@Shelley-BaoYue)baoyue2@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/15043686-0866-4d5a-9016-3a6cbfd448fcGithub Issue：https://github.com/kubeedge/kubeedge/issues/6429▍KubeEdge: Device Anomaly Detection Framework (2025 Term 3)课题描述：当前的 KubeEdge 平台使用三种状态来表示设备状态：期望状态、观察到的期望状态和报告状态。平台上显示的设备状态完全依赖于 Mapper，该组件负责从设备端收集和报告数据。然而，由于 Mapper 实现的局限性、物理设备故障、网络延迟以及潜在的网络攻击，平台上显示的设备状态可能无法准确反映设备的实际状态。在 KubeEdge 平台中，如果应用程序依赖于设备状态进行决策，那么状态表示的不一致可能导致不良后果。因此，本项目旨在为 KubeEdge 设计一个设备状态异常检测框架。通过探索设备状态之间的因果关系，该框架将建立轻量级的异常检测能力，并提供一个全面的工具链，包括数据收集、模型训练、实时异常检测和结果可视化。预计输出件：通用的设备异常检测框架，支持用户自定义的检测算法完整的技术设计文档，包括模型选择、训练流程，以及训练和在线检测组件的详细架构图机器学习模型及相应的异常检测算法，能够捕捉设备状态之间的因果关系，并使用标准框架进行训练和测试集成到 KubeEdge 设备状态报告工作流程中的在线异常检测模块，通过模型推理钩子实现实时分析前置技能：KubeEdge,  IoT，Machine Learning课题导师：Liwei Shen (@meixiezichuan)shenliwei@fudan.edu.cnElias Wang (@wbc6080)wangbincheng4@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/8cf4ff37-e638-4b73-a5a1-521806ac8db1Github Issue：https://github.com/kubeedge/kubeedge/issues/6312▍KubeEdge: Deploy Small Language Models & OPEA Integration (2025 Term 3)课题描述：KubeEdge 作为一个基于 Kubernetes 生态系统构建的本地边缘计算平台，提供了可靠的云边通信、边缘自治和物联网设备集成等能力。然而，其在边缘支持智能模型的能力尚未在实际场景中得到系统验证和实践。本研究旨在探讨使用 KubeEdge 在边缘节点上部署和运行小语言模型的可行性和性能。预计输出件：验证 KubeEdge 在边缘的模型部署能力。在边缘节点上部署和测试 vLLM 和 llama.cpp 等模型引擎，并提供实际示例和详细文档，以便部署小型语言模型探索 KubeEdge 与 OPEA 平台之间的集成方案。将 KubeEdge 与 OPEA 的模型注册中心和工作流调度器连接，以支持从云到边缘节点的自动化模型分发和部署前置技能：KubeEdge, LLM, Golang, Python课题导师：Hongbing Zhang (@HongbingZhang)hongbing.zhang@daocloud.ioElias Wang (@wbc6080)wangbincheng4@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/2e9d0538-0941-4f10-8c52-9afd6294e16eGithub Issue：https://github.com/kubeedge/kubeedge/issues/6428▍KubeEdge: Comprehensive Example Restoration for Ianvs (2025 Term 3)课题描述：Ianvs 是 KubeEdge SIG AI 的分布式基准测试工具包，随着越来越多的贡献者参与，目前已有 25 个示例，且数量仍在增加。然而，由于依赖关系的演变和验证机制的影响，KubeEdge Ianvs 面临着日益突出的可用性问题。随着合作社区 Python 版本、第三方库和 Ianvs 特性的改进，部分历史示例无法执行。这导致用户报告的问题增多、贡献者时感困惑、未经测试 PR 影响特性功能、过时文档与实际能力不符等。如果不进行干预，这些示例可能会对边缘 AI 开发者，尤其是新手，带来开发阻碍。因此，我们尝试通过优化示例来提升 Ianvs 的可用性。预计输出件：发现和修复示例中的错误，包括依赖清单、License 扫描和运行时配置文档优化，包括重新设计教程，提供可复现的逐步指南，并发布面向开发者的调试手册，以应对常见故障构建一个 CI 流水线，使用 GitHub Actions 测试多个 Python 版本下的示例，关键的 Ianvs/Upstream 更新，并阻止破坏经过验证示例的 PR前置技能：Python, Benchmark, KubeEdge-Ianvs, AI/ML课题导师：Zimu Zheng (@MooreZheng)zimu.zheng@huawei.comShijing Hu (@hsj576)sjhu21@m.fudan.edu.cn课题链接：https://mentorship.lfx.linuxfoundation.org/project/82d71e63-2e1e-48d6-8c93-91c9e8bf8d5dGithub Issue：https://github.com/kubeedge/ianvs/issues/230▍KubeEdge: Industrial Benchmark Dataset for Ianvs (2025 Term 3)课题描述：随着工业制造通过机器人技术、自适应生产线和智能测试系统的进步加速数字化转型，云边协作已成为在复杂操作环境中部署具身智能的关键推动力。现代工业对具身智能的要求不仅限于基本任务执行，还扩展到多模态感知与决策集成、动态环境适应和分布式设备编排。现有的基准测试框架在评估工业环境中固有的场景特定具身属性方面存在局限。本项目利用 KubeEdge-Ianvs 协作 AI 框架，整合领域特定的测试数据集、仿真环境和定量指标，以建立一个认证的工业级评估基础设施，用于具身智能系统。预计输出件：通过对现有资源/示例进行系统分类和重组，开发一个工业级具身智能数据集部署基准算法并引入指标，以在 KubeEdge-Ianvs 中建立性能基准前置技能：Python, Benchmark, Dataset, Embodied Intelligence课题导师：Zimu Zheng (@MooreZheng)zimu.zheng@huawei.comMengzhuo Chen (@IcyFeather233)icyfeather@foxmail.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/c066ac53-5435-4057-a84c-0e0be62e8b65Github Issue：https://github.com/kubeedge/ianvs/issues/197 如果对课题内容有任何问题，欢迎在 GitHub 仓库提交 Issue 或者添加社区小助手微信向社区提问。扫码回复“KubeEdge” 进入技术群 今年秋季，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: https://github.com/cncf/mentoring/blob/main/programs/lfx-mentorship/2025/03-Sep-Nov/README.md[3] LFX Mentorship - Mentee Application Guideline: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply 【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：https://connect.huaweicloud.com/courses/learn/course-v1:HuaweiX+CBUCNXNX022+Self-paced/aboutKubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : https://github.com/kubeedge/kubeedgeSlack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

 随着云计算进入多云时代，企业逐渐采用混合云或多云架构以提升灵活性、降低供应商依赖风险并优化成本。然而，这一趋势也带来了新的挑战——跨云平台的数据迁移。无论是将本地数据中心迁移至公有云、私有云，还是在不同公有云之间迁移，数据作为核心资产，其迁移过程直接影响业务连续性、数据完整性和安全性。本文将从技术视角出发，结合实战经验，解析跨云数据迁移的关键要素：工具选型、架构设计与避坑策略，助您构建高效、安全的迁移方案。  一、云数据迁移工具对比：如何选择最适合的工具？在跨云迁移中，工具的选择决定了迁移的效率与质量。以下是几类主流工具的对比分析，供参考：选型建议：小规模测试：优先选择轻量化工具快速验证可行性；大规模生产环境：采用组合方案（如数据库专用工具+对象存储工具）；实时同步需求：选择支持CDC技术的工具，并提前测试冲突解决机制。二、架构设计：跨云迁移的核心逻辑与关键步骤成功的跨云迁移离不开科学的架构设计。以下是分阶段实施的关键步骤：  1. 评估与规划阶段数据普查：绘制数据拓扑图，标注所有数据源（数据库、文件服务器、SaaS应用）、数据量及增长趋势；业务影响分析：明确关键业务的RTO（恢复时间目标）和RPO（恢复点目标），例如电商大促期间需保证毫秒级延迟；迁移策略制定：根据数据敏感性和实时性要求，选择“停机窗口冷迁移”“增量同步热迁移”或“双写模式”。2. 高可用性设计冗余链路：在源端和目标端部署代理节点，避免单点故障；数据校验机制：迁移前后计算文件哈希值（MD5/SHA-256）、数据库记录数比对；回滚方案：保留源端快照，并在目标端预置回滚脚本，确保紧急情况下可快速回退。3. 混合云管理架构统一监控平面：通过Prometheus/Grafana等工具监控跨云数据传输速度、错误率、资源占用；权限隔离：基于RBAC模型限制操作员权限，避免越权访问敏感数据；日志审计：记录所有迁移操作日志，满足合规性要求（如GDPR、HIPAA）。4. 性能优化策略压缩算法：使用LZ4、Zstandard等无损压缩算法减少网络传输量；并发控制：根据带宽动态调整线程数，避免拥塞；缓存机制：对频繁访问的数据块进行本地缓存，加速重复传输。三、避坑指南：跨云迁移的常见陷阱与解决方案即使拥有最佳工具和架构，仍需警惕以下潜在风险：  四、实战案例：某电商平台的跨云迁移实践背景：某电商平台因业务扩张需将部分业务从A云迁移至B云，涉及MySQL数据库（5TB）、Redis缓存（1TB）和OSS文件存储（500TB）。实施步骤：评估阶段：通过工具扫描发现大量历史订单表存在外键约束，直接迁移可能导致锁表；方案设计：采用“数据库专用工具+对象存储工具”组合，对订单表进行分片迁移，并启用CDC实时同步；测试验证：在沙箱环境中模拟大促流量，发现Redis集群因跨云延迟导致响应变慢，遂调整为本地缓存+异步同步；正式迁移：选择业务低峰期（凌晨2-4点），分三批次完成迁移，全程耗时6小时，停机时间控制在30分钟内；优化迭代：迁移后通过监控发现B云的磁盘IOPS不足，扩容后性能提升40%。五、结语：工具+架构+经验=成功迁移跨云数据迁移是一项系统工程，工具的选择仅是起点，科学的架构设计和丰富的实战经验才是成功的关键。建议企业在迁移前组建跨部门团队（IT、业务、法务），制定详细的《迁移应急预案》，并预留足够的缓冲时间应对突发状况。未来，随着AI驱动的智能迁移助手兴起，自动化程度将进一步提升，但人类专家对业务逻辑的理解始终是保障迁移质量的核心要素。希望本文能为您的跨云迁移之路提供实用参考！

数字化转型浪潮下，企业面临着公有云弹性扩展与私有云数据控制权的矛盾命题。根据Gartner预测，到2025年将有超过85%的企业采用混合云架构，其中存储系统的融合能力成为关键瓶颈。本文从技术演进视角拆解分布式混合云存储的五大主流架构，揭示不同场景下的最优解法，助您突破传统架构的性能边界与成本桎梏。  一、混合云存储的核心矛盾与设计原则当前企业面临三大核心挑战：1. 数据爆炸性增长：AI训练数据量年增3倍，传统集中式存储难以线性扩展；2. 合规与成本博弈：金融行业监管要求核心数据本地化，但互联网业务需全球低延迟访问；3. 异构工作负载：OLTP事务处理、视频流媒体、冷备份归档等不同IO特征并存。优秀的混合云存储架构应满足：无缝数据流动：支持跨云/边/端的数据迁移与同步；智能分层治理：自动匹配数据生命周期与存储介质；统一管理平面：可视化全局资源调度与策略配置；弹性计费模型：按需使用公有云资源，避免过度预置硬件。二、五大主流分布式混合云存储架构深度剖析1. 联邦式架构（Federated Architecture）技术特征逻辑统一，物理分散：通过元数据服务整合多数据中心存储池；强一致性协议：采用Raft/Paxos算法保证跨站点数据一致；智能路由引擎：基于地理围栏、SLA要求自动选择存储节点。典型场景跨国金融机构：满足各国数据驻留法规，同时提供全球统一命名空间；医疗影像平台：三级医院本地存储DICOM文件，区域中心汇总科研数据。优势与局限  2. 分层式架构（Tiered Architecture）技术特征热/温/冷三级存储：SSD→HDD→磁带库自动分级；机器学习驱动迁移：基于访问频率预测数据冷热程度；缓存预热机制：提前加载高频访问数据至边缘节点。典型场景视频直播平台：实时流媒体存SSD，历史回放转HDD，长期存档归磁带；基因组学研究：原始测序数据存高性能存储，比对结果转低成本归档。优势与局限 3. 对称式双活架构（Active-Active Architecture） 技术特征双向同步复制：主备站点均可独立承接业务流量；仲裁节点机制：引入第三个节点解决脑裂问题；动态负载均衡：根据请求来源自动分配读写流量。典型场景证券交易平台：上海/深圳数据中心互为灾备，保障交易连续性；工业互联网：工厂本地存储生产数据，云端进行大数据分析。优势与局限  4. 边缘协同架构（Edge-Coordinated Architecture）技术特征三级存储拓扑：边缘节点→区域中心→中央云；断网续传能力：网络中断时本地暂存，恢复后同步；轻量化元数据：仅同步必要目录结构，减少带宽消耗。典型场景智慧零售：门店POS机离线收银，联网后批量同步销售数据；车联网：车载终端存储行驶日志，夜间停车时上传至云端。优势与局限  5. 容器化存储网格（Containerized Storage Grid）技术特征Kubernetes CSI集成：存储卷随容器自动漂移；微服务化存储组件：对象网关、元数据服务均容器化部署；声明式API驱动：通过CRD定义存储策略与拓扑关系。典型场景DevOps流水线：构建产物自动存入临时存储，测试完成后转正式库；Serverless函数计算：临时存储中间结果，执行完毕自动清理。优势与局限  三、架构选型决策矩阵  四、未来演进趋势1. 存算分离深化：存储层专注数据管理，计算层聚焦AI推理；2. 量子安全增强：抗量子加密算法嵌入存储层，保护长期冷数据；3. 碳感知存储：根据数据中心PUE动态调整数据存放位置；4. 三维空间扩展：除地理分布外，增加芯片级/机房级冗余维度。结语分布式混合云存储的本质是“数据的精准投放”——在正确的时间、正确的地点、以正确的形式保存数据。企业应根据业务特性构建动态演进的存储体系：对于毫秒级响应的核心交易，采用双活架构；对于PB级非结构化数据，选择分层存储；对于边缘侧设备，部署协同式存储网格。唯有打破“一刀切”的架构思维，才能在数字经济时代掌握数据主权与业务创新的平衡点。

Karmada 社区非常高兴地宣布中科类脑正式加入Karmada 用户组[1]（Karmada Adopter Group），成为该开源社区的重要成员。作为云原生计算基金会（CNCF）旗下的开源项目，Karmada 致力于为用户提供强大的多集群管理和调度能力，帮助企业在复杂的分布式环境中实现高效的应用部署和管理。中科类脑的加入将进一步丰富 Karmada 社区的生态，并为项目的持续创新注入新的动力。  关 于 中 科 类 脑 合肥中科类脑智能技术有限公司[2]成立于2017年，是一家专注于类脑智能技术研发与应用的国家高新技术企业、国家级专精特新“小巨人”企业。公司在机器视觉大模型、小样本学习、因果视觉与因果推理、稳定学习、类脑博弈优化决策等多个人工智能前沿技术领域处于行业先进地位，广泛应用于算力基础设施、智慧能源和算电碳协同发展三大业务领域。中科类脑秉承“推动前沿智能技术落地，助力产业数智升级”的使命，持续推出创新的智能化产品及解决方案，力求打造垂直领域人工智能应用的深度闭环。公司致力于成为全球领先的能源智能服务企业，致力于成为全球AI生态建设者。  关于Karmada用户组  作为连接社区与用户的核心纽带，Karmada 用户组致力于打造一个深度融合、开放协作的高价值平台，推动成员间的高效联动与经验共享。通过技术支持、活动共创及最佳实践交流，Karmada 用户组将持续赋能用户在多云管理领域的能力提升，助力云原生多云多集群生态系统的蓬勃发展。其主要目标和功能包括：分享知识：促进 Karmada 用户之间的经验、挑战和解决方案交流促进协作：提供一个用户可以协作、分享想法并解决共同问题的平台支持用户：提供资源、教程和指导，帮助用户有效利用 Karmada收集反馈：倾听用户声音，以指导 Karmada 未来的发展方向社区活动组织：通过定期 meetup、网络研讨会和其他活动，增强社区参与度截至目前，Karmada 用户组已吸纳来自全球的35+家机构和组织。更多使用场景及案例研究请查阅：https://karmada.io/adopters    欢迎加入用户组   任何在生产环境中使用 Karmada 的公司，其开发者均可申请加入 Karmada 用户组。无论您是最终用户还是云厂商，我们都欢迎您的加入。最终用户：指在其内部 IT 基础设施中直接部署和使用 Karmada 进行多云或多集群管理的企业或组织。这些公司利用 Karmada 作为关键技术底座来管理和优化算力资源。供应商：指那些将 Karmada 集成到他们的产品或服务中，以提供给其他企业或组织使用的公司。加入 Karmada 用户组，您可以与面临类似挑战的同行建立联系并分享 Karmada 实践经验，一同探索多云多集群生态，包括但不限于以下内容：社区技术支持：包括且不限于方案评估、日常运维、问题定位、版本升级等社区支持公司知名度提升：您的公司和团队将获得全球范围内更多的曝光机会技术影响力构建：邀请共建技术演讲，包括 KubeCon 等海内外业界大会，Karmada 社区伙伴举办的线上、线下系列会议保持信息同步：及时接收重要信息更新，包括新版本的关键特性、重要 Bug 修复、安全风险等内容，确保您的项目能够第一时间受益于新的改进和增强。顶尖人才招募：利用社区渠道招聘宣传，全球范围内精准招募优秀人才拓展商业机会：与 Karmada 生态系统其他成员建立潜在的商业联系和合作当前，加入 Karmada 用户组对社区贡献没有硬性要求，我们鼓励成员积极参与社区活动，分享经验与见解。然而，请注意，未来可能会要求成员对 Karmada 社区做出一定的贡献，以维持其用户组成员身份。这种贡献可以包括但不限于代码提交、文档编写、问题修复、使用案例分享等。访问下方 Karmada 用户组申请表单 [3]，提交 issue 申请，即可接收申请进度。手机端可扫描下方二维码快捷填写申请表单。 扫码申请加入用户组 更多信息，请访问：[1] Karmada Adopter Group 详细信息，请查阅: https://github.com/karmada-io/community/tree/main/adopter-group[2] 中科类脑: http://www.leinao.ai/[3] Karmada Adopter Group 申请加入表单地址: https://github.com/karmada-io/community/issues/new?template=adopter-group-application.yaml Karmada Adopter Group 欢迎您的加入！期待与您共同创建一个友好而活跃的空间，共享知识、最佳实践和经验，为企业与社区发展缔造更多可能。如需了解更多关于Karmada Adopter Group的信息，请联系:Maintainer Mailing Listcncf-karmada-maintainers@lists.cncf.io Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada 官网：https://karmada.io/GitHub 地址：https://github.com/karmada-io/karmadaSlack 地址：https://slack.cncf.io/（#karmada）添加社区小助手k8s2222回复Karmada进入技术交流群