数之联简介成都数之联科技股份有限公司成立于2012年，由985&211高校教授领衔，专注于大数据与人工智能技术的研发和应用。公司面向“智能化改造”和“数字化转型”这两大当前企业发展的重要战略方向，提供自主安全可控的人工智能基础设施与软硬一体的高端装备，助力客户提升管理和服务的智慧化水平，实现降本提质增效。▍行业背景在液晶面板生产领域，由于多种因素，产品常出现不良品。为此，关键工艺节点后引入了自动光学检测（AOI）设备，通过光学原理检测常见缺陷。然而，现有 AOI 设备仅识别缺陷有无，需要人工分类和识 别假缺陷，这一过程耗时且影响生产效率。数之联的客户企业，某面板龙头企业，引入自动缺陷分类系统（ADC）以提高判定准确性并减轻劳动强度，使用深度学习技术自动分类 AOI 输出的缺陷图片，并筛除误判，从而提高生产效率。客户企业率先在一个工厂引入 ADC，后续在其他工厂推广，节省人力资源，提高判定效率。尽管如此，由于工艺复杂和供应商差异，现场建设呈现出割裂和分散管理的趋势，给数据共享和运维带来困难。为解决这些问题，客户企业启动了工业智能检测平台的建设，该平台利用人工智能技术，标准化智能检测并提高生产效率和良率。工业智能检测平台工业智能检测平台 将 ADC 作为核心，扩展至模型训练和检测复判，实现“云”（管理+训练）+“边”（推理）+“端”（业务）的一体化方案，旨在通过标准化平台提高生产质量和数据价值。建设范围包括资源共享中心、现地 训练和边侧推理等子平台，将在若干工厂实施。工业智能检测平台架构图项目目标是实现现地 ADC 上线、资源共享和云边端标准化，以减轻运维负荷、提升标准。工业智能检测平台旨在通过规范化和标准化 客户企业 全集团的 ADC 系统，为后续 ADC 建设提供样本和模板，降低成本和周期，提高生 产和质检效率以及产品良率。包含系统管理员、资源配置员等用户角色，并涉及 ADC 推理、模型训练、数据共享等信息流，以及云端协同功能，确保 ADC 的自动缺陷分类生产过程，并提高模型和缺陷图片的 利用率。▍产品与技术实现一、集群管理不同现地可将对应的 K8s 集群注册至中心云系统，中心云系统对多个现地的集群进行管理。集群管理我们选择了 PULL 模式。为了降低 OP 的操作成本，我们在中心云提供了 step-by-step 的注册流程。引导安装 karmada-agent。使用 karmadactl token create 控制面生成 token。引导注册 karmadactl register 。在成员集群中编辑由 karmadactl register 创建的 deploy/karmada-agent 以确保其可以访问该成员集群的 kube-apiserver。二、使用聚合层 API通过 karmada-aggregator 组件提供的集群统一访问能力，我们可以在中心云实现可视化大屏等需要聚合成员集群的数据的功能。通常我们用 Service 来暴露 Java 实现的功能，并用 Java Fabric8 等客户端调用 kubectl get --raw 来实现调用：/apis/cluster.karmada.io/v1alpha1/clusters/%s/proxy/api/v1/namespaces/%s/services/%s/proxy/%s1、集群监控针对在线的集群，中心云系统可对内存、CPU、磁盘、网络流入流出速率、GPU、日志等指标进行监控数据展示，并可切换集群进行数据查看。资源监控中心云可以看到和训练云相同的监控，通过 Karmada 聚合层 API 由集群的 Java 程序对 PromQL 封装后提供给前端页面，以下是一个 Java 查询节点 CPU 利用率的示例：/apis/cluster.karmada.io/v1alpha1/clusters/%s/proxy/api/v1/namespaces/%s/services/%s/proxy/api/v1/query_range?query=node:node_cpu_utilization:avg1m{node='%s'}&start=%s&end=%s&step=%s2、中心云数据下发用户在中心云上传的数据，可自由选择下发至指定现地，包括数据集、标注、算子工程、算子镜像以及模型等。数据发布数据集、算子工程、模型，通常是文件，在完成传输后，会保存到本地或NAS等存储中。标注，通常是结构化数据，在完成传输后，会保存到 DB 中。算子镜像，一般导出为 tar 包，在完成传输后，会推送到当前集群的 harbor 中。中心云除了 Karmada 的控制面以外，也带有自己的业务 K8s 集群，也包括存储，因此可以作为一个中转器。以上均通过 Karmada 的聚合层 API 来调用我们提供的文件上传等 svc。实现了集群和集群之间的调用。3、跨现地训练针对某现地训练资源不足的情况下，可通过申请其他现地资源的方式，进行跨现地训练。该功能实现方式为将 A 现地训练所需要的数据集、标注、算子工程、算子镜像等数据发送至 B 现地，通过 B 现地的资源进行训练。再将训练好的模型返回给 A 现地。跨现地训练原理和中心云数据下发类似，任务所需的数据会直接发送到对应集群，体现了成员集群和成员集群之间的调用关系。4、可视化大屏根据中心云注册的现地，统计不同现地的各类指标数据进行大屏展示。可视化大屏通过 Karmada 聚合层 API，我们在这类大屏中展示实时数据的时候，可以方便地直接调用成员集群的 svc。而无需让所有的数据显示都走大数据的离线分析、实时分析。提供更高的时效性。▍项目管理本项目的团队由我司经验丰富的训练平台产品经理，以及专业的研发工程师和测试工程师 14 名组成。团队从 2023 年 4 月开始工作，直至 2023 年 12 月完成了开发和部署工作。尽管项目在进程中经历了三个大的里程碑，每个阶段都充满了挑战，但团队的每一个成员都坚持不懈，积极应对，展现了我们团队的战斗力、凝聚力和专业能力。考虑到训练平台的用户主要是算法工程师和产线业务人员，他们的使用习惯和知识背景存在显著差异，因此产品经理进行了深入的市场研究和讨论，最终设计出一款既能满足算法工程师的灵活性需求，又能满足产线业务人员追求高效、简洁的系统。为了确保项目的范围、进度、质量和成本可控，我们在关键阶段举行了包括产品设计、开发、测试和部署评审等会议，并定期召开项目会议以及客户沟通会议。系统部署后，我们积极获取用户反馈，解决问题并持续优化系统以满足客户需求。添加社区小助手进入Karmada交流群

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。在最新发布的v1.10版本中，Karmada新增了工作负载重平衡功能：在某些场景下，资源副本的当前分布状态可能不是最优，但调度器为了减少对系统的冲击会尽可能保持调度结果的惰性，不会轻易改变调度结果；此时，用户可以通过新引入的 WorkloadRebalancer API 针对指定的资源手动触发全新的重调度，以在集群间建立最优的副本状态分布。本版本其他新增特性：解除资源模板名称长度不能超过 63 个字符的限制生产环境中的可用性和可靠性增强   新特性概览  Workload Rebalance一般情况下，工作负载类资源一旦被调度，其调度结果通常会保持惰性，不会轻易改变副本分布状态。即使通过修改资源模板中的副本数或 PropagationPolicy 的 Placement 来触发重新调度，系统也只会在必要时进行最小化的调整，以最大程度地减少对系统的影响。然而，在某些情况下，用户可能希望能够主动触发全新的重调度，完全忽略过去的分配结果，并在集群之间建立全新的副本分布状态，例如：在主备集群模式下，由于主集群故障，应用被迁移至备集群，主集群恢复后，应用希望重新迁移至主集群。在应用级别故障迁移场景下，由于集群资源不足，应用从多个集群缩减到单个集群，相应集群资源充足后，应用希望重新分发到多集群以确保高可用性。对于聚合调度策略，由于资源限制，副本最初分布在多个集群中，当单个集群足以容纳所有副本后，应用希望重新聚合到单集群。因此，本版本引入了工作负载重平衡功能，如果当前副本分布状态不是最优，用户可以按需触发全新的重调度。例如，用户想触发 Deployment/foo 的重调度，只需声明下述 WorkloadRebalancer 资源：apiVersion: apps.karmada.io/v1alpha1 kind: WorkloadRebalancer metadata: name: foo-rebalancer spec: workloads: - apiVersion: apps/v1 kind: Deployment name: foo namespace: default然后，调度器将对该 Deployment 进行重调度。1）如果成功，您将看到以下结果:apiVersion: apps.karmada.io/v1alpha1 kind: WorkloadRebalancer metadata: name: foo-rebalancer generation: 1 creationTimestamp: "2024-05-22T11:16:10Z" spec: ... status: finishTime: "2024-05-22T11:16:10Z" observedGeneration: 1 observedWorkloads: - result: Successful workload: apiVersion: apps/v1 kind: Deployment name: foo namespace: default2）如果失败，例如 Deployment/foo 的 ResourceBinding 不存在，您将得到以下结果：apiVersion: apps.karmada.io/v1alpha1 kind: WorkloadRebalancer metadata: name: foo-rebalancer generation: 1 creationTimestamp: "2024-05-22T11:16:10Z" spec: ... status: finishTime: "2024-05-22T11:16:10Z" observedGeneration: 1 observedWorkloads: - reason: ReferencedBindingNotFound result: Failed workload: apiVersion: apps/v1 kind: Deployment name: foo namespace: default有关此功能的详细描述，请参见用户指南：https://karmada.io/zh/docs/next/userguide/scheduling/workload-rebalancer解除资源模板命名长度的限制由于历史设计原因，资源模板的名称被用作 label 的值，从而加速资源的检索。由于 Kubernetes 限制标签 value 值不能超过 63 个字符，导致用户无法将名称长度超过 63 个字符的资源分发至成员集群中去，间接限制了资源模板名称的长度，严重阻碍了用户将工作负载从旧集群迁移到Karmada。Karmada社区从 v1.8 版本起着手消除这一限制，并在 v1.8 和 v1.9 版本中做了充足的准备工作，以确保使用旧版本 Karmada 的用户可以平滑升级到当前新版本，而不用感知这一变化。更多详情请参见 [Umbrella] 在资源中使用 permanent-id 替换 namespace/name标签：cid:link_4生产环境中的可用性和可靠性增强本版本融合了大量生产级用户的反馈，进行了大量功能性增强以及安全性提升，包括：1）功能增强：支持分发 kubernetes.io/service-account-token type的 Secret 资源优化 PropagationPolicy 降低优先级时的优先级抢占逻辑显著减少 karmada-metrics-adapter 组件的内存使用优化了 karmada-webhook 的启动逻辑，消除了偶现的异常报错2）安全增强：将 google.golang.org/protobuf 从 1.31.0 升级到 1.33.0，以解决 CVE-2024-24786 漏洞问题将 Karmada 证书的 RSA 密钥长度从 2048 升级到 3072，提高秘钥安全性将 text/template 库替换为 html/template，增加 HTML 编码等安全保护功能创建文件时由默认授予 0666 权限改为指定授予 0640 权限，提高文件安全性采取必要措施以消除安全扫描工具的误报，如在使用 karmadactl 删除 token 时调整日志打印内容和消除 gosec 警告 G107 等3）生态集成：为 OpenKruise 中的 CloneSet 资源展示 status.labelSelector，以支持该资源的HPA扩缩容特性在 karmadactl 添加成员集群时，新增支持 OIDC 认证模式相信这些努力将使 Karmada 为用户带来更好的体验！致谢贡献者Karmada v1.10 版本包含了来自32位贡献者的356次代码提交，在此对各位贡献者表示由衷的感谢：贡献者GitHub ID:@a7i@Jay179-sudo@veophi@Affan-7@jwcesign@wangxf1987@B1F030@khanhtc1202@warjiang@calvin0327@laihezhao@whitewindmills@chaosi-zju@liangyuanpeng@wzshiming@chaunceyjiang@my-git9@XiShanYongYe-Chang@dzcvxe@RainbowMango@yanfeng1992@Fish-pro@Ray-D-Song@yike21@grosser@rohit-satya@yizhang-zen@guozheng-shen@seanlaii@zhzhuang-zju@hulizhe@stulzq参考链接[1]Release Notes: cid:link_1[2]WorkloadRebalancer 指南: cid:link_0[3]WorkloadRebalancer 示例教程: cid:link_3[4]Karmada 1.10升级文档: cid:link_2更多云原生技术动向关注容器魔方

3月21日，在巴黎举办的云原生顶级峰会KubeCon+CloudNativeCon Europe 2024上 ，华为云首席架构师顾炯炯在 “Cloud Native x AI：以持续开源创新开启智能时代” 的主题演讲中指出，云原生和AI技术的融合，是推动产业深刻变革的关键所在。华为云将持续进行开源创新，与开发者共启智能时代。  ▲华为云首席架构师顾炯炯发表演讲AI对于云原生范式提出关键挑战在过去的几年里，云原生彻底改变了传统的IT系统，催化了互联网和政府服务等领域的数字飞跃。云原生范式带来的新的可能性，例如闪电般的快速销售和基于微服务治理的敏捷应用DevOps，已经深入人心。同时，人工智能的快速发展和广泛采用，包括大规模模型，已经成为行业智能的跳动心脏。根据Epoch 2023年的调研数据，基础模型所需的计算能力每18个月就会增长10倍，是摩尔定理揭示的通用计算能力增长率的5倍。AI带来的新摩尔定律和大规模AI模型的主导地位对云原生范式提出了挑战，顾炯炯总结了其中关键的4点：首先，低GPU/NPU平均利用率导致AI训练和推理的高成本；其次，大模型训练集群频繁的失败率限制了训练效率；第三，大规模模型的复杂配置导致AI开发门槛高；第四，大规模的AI推理部署面临着不可预测的最终用户访问延迟和数据隐私问题的风险。华为云AI创新为开发者迎接挑战提供思路随着AI模型变得越来越大，对计算能力的需求也呈指数级增长。这种需求不仅给云原生技术带来了挑战，也为业界提供了创新机遇。顾炯炯分享了一些华为云在AI创新方面的故事，为开发者解决这些挑战提供了参考。在云原生边缘计算平台KubeEdge的基础上，华为云实现了一个云原生多机器人调度管理平台。用户可以通过自然语言命令在云端输入任务指令，由系统协调边缘的多个机器人共同协作完成复杂任务。为了克服自然语言命令理解、大量机器人高效调度管理以及跨类型机器人访问管理的三个挑战，该系统采用了云端、边缘节点和机器人三个部分的架构，通过大模型执行自然语言命令，并进行流量预测、任务分配和路由规划。这一架构显著提高了机器人平台的灵活性，管理效率提升25%，系统部署周期缩短30%，新机器人的部署时间从月级缩短到天级。中国某顶级内容分享社区，每月活跃用户超过1亿。它的核心服务之一是主页上的推荐功能。推荐模型有近1000亿个参数。训练集群有数千个计算节点。一个训练作业需要数百个参数服务器和worker。因此，该社区对最优拓扑调度、高性能、高吞吐量有着强烈的需求。开源项目Volcano可以更好地支持在Kubernetes上运行的AI/ML工作负载，并提供了一系列作业管理和高级调度策略。Volcano项目引入了拓扑感知调度、装箱、SLA感知调度等算法，帮助社区将整体训练性能提升了20%，运维复杂度也大大降低。Serverless AI引领云原生发展趋势如何高效、稳定地运行AI应用，同时降低运营成本，成为摆在众多企业和开发者面前的一大挑战。为此，华为云总结了云原生AI平台的关键要求，提出了一种全新的云原生AI平台理念——Serverless AI。顾炯炯提到，从开发者的视角来看，Serverless AI致力于智能地推荐并行策略，让复杂的训练和推理任务变得轻而易举。它提供自适应的GPU/NPU自动扩展功能，能够根据工作负载的实时变化动态调整资源分配，确保任务的高效执行。同时，Serverless AI还维护着一个无故障的GPU/NPU集群，让开发者无需担心硬件故障带来的中断风险。更值得一提的是，该平台保持与主流AI框架的兼容性，让开发者能够无缝集成现有的AI工具和模型。对于云服务提供商而言，Serverless AI同样具有深远的意义。它不仅能够提高GPU/NPU的利用率，使训练、推理和开发混合工作负载得以高效运行，还能通过优化能效实现绿色计算，降低能耗成本。此外，Serverless AI平台还能实现跨多个租户的空间和时间GPU/NPU共享，提高资源的复用率。最重要的是，它为训练和推理任务提供了有保证的QoS和SLA，确保了服务质量和稳定性。Serverless AI平台采用了构建在操作系统和虚拟化之上的灵活的资源调度层，将应用程序框架的关键功能封装于应用资源中介层中。顾炯炯现场展示了Serverless AI平台的参考架构。他认为，这种架构设计，使得Serverless AI平台具有了大规模AI资源自动驱动引擎的特点，包括精确了解应用资源利用模式的资源分析，实现异构硬件资源池化的资源共享，基于GPU/NPU虚拟化和负载热迁移的AI训练任务容错能力，以及提高资源利用率的多维度调度和自适应弹性伸缩等优点。分论坛上，华为云技术专家提到，Kubernetes上运行AI/ML工作负载的使用量不断增加，许多公司在分布于数据中心和各种GPU类型的多个 Kubernetes 集群上构建云原生AI平台。使用Karmada和Volcano，可轻松实现多集群的GPU工作负载智能调度、集群故障转移支持，在保障集群内和跨集群的两级调度一致性和效率，并平衡系统整体资源的利用率和不同优先级工作负载的QoS，以应对大规模、异构的GPU环境管理中面临的挑战。Karmada为多云和混合云场景中的多集群应用管理提供即时可用的自动化管理，越来越多的用户在生产环境中使用Karmada构建灵活高效的解决方案。Karmada已于2023年正式升级为CNCF孵化项目，期待与更多伙伴与开发者们共建繁荣社区。Volcano与主流AI/大数据框架实现了无缝集成，有效解决了AI/大数据任务的作业管理，资源分配，资源调度等问题与挑战，为业界提供了分布式作业训练的最佳实践。在大模型日新月异的今天，Volcano将持续发力，解决多集群AI任务调度等难题，助推大模型训练与推理快速发展。“云原生技术的敏捷性和异构AI计算平台的创新性，将是提升AI生产力的关键。” 顾炯炯谈到，未来，华为云将持续致力于开源创新，与业界同仁、伙伴共同开启智能时代的新篇章。更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

12月12日，云原生计算基金会（CNCF）宣布，CNCF技术监督委员会（TOC）已投票通过 Karmada 为正式孵化项目。Karmada 是华为云捐赠的云计算开源技术，是业界首个多云多集群容器编排项目。正式晋升 CNCF 孵化级，也意味着 Karmada 的技术生态受到全球业界广泛认可，在分布式云原生技术领域领域进入了成熟新阶段。作为 CNCF 首个跨云跨集群容器编排引擎，Karmada 由华为云、工商银行、小红书、中国一汽等八家企业联合发起。项目于2021年4月正式开源，2021年9月加入CNCF 成为沙箱项目。Karmada 的贡献者来自世界各地，覆盖全球22个国家和地区的60多家组织，包括华为、DaoCloud、浙江大学、滴滴、腾讯、小红书、新浪、Intel、IBM、Red Hat、Comcast 等公司。截至目前，项目在开源软件项目托管平台 GitHub 已收获超过3600 Star。华为云 CTO 张宇昕表示：华为云长期致力于云原生技术、产业和生态的建设。Karmada源于社区和华为云在多云管理领域的深厚沉淀，为企业提供了从单集群到分布式云架构的平滑演进方案。“作为 Karmada 项目的发起者和主要贡献者之一，华为云将继续与 CNCF 和社区合作，释放无处不在的云原生价值。”“Karmada 开源以来受到了广泛的关注和支持，并帮助越来越多的最终用户在多云环境中高效管理 Kubernetes 集群和分布式应用。”Karmada 社区创始人兼维护者王泽锋表示：“我们很高兴 Karmada 已达到 CNCF 孵化状态，并将继续致力于将其发展成更为完善的国际化社区。”CNCF 技术监督委员会（TOC）委员Nikhita Raghunath 表示：Karmada 填补了Kubernetes 多云和多集群环境中的调度和编排方面的空白，可以为分布式组织提供更好的性能并降低成本。“自从加入 CNCF Sandbox 以来，项目团队一直不懈地努力添加新特性和功能，以融入更广阔的云原生生态。我们期待看到该项目的持续成长。”目前，项目已在华为云、兴业数金、中国移动云、中国联通、携程、vivo、飓风引擎、VIPKID、有赞、网易、快手、之江实验室等20多家企业和单位落地应用，以开源创新促进云原生产业发展，项目全球生态发展迅速。Karmada 的创新优势，也得到了企业用户的高度认可。“Karmada 使我们能够为 Zendesk 的内部工程团队提供多集群架构，同时保持身份验证、配置交付和服务管理的单点访问。”Zendesk 计算团队工程经理 Adam Minasian 说到，“随着 Karmada 项目进入 CNCF 孵化阶段，我们很高兴能够继续与该项目合作。”“Karmada 为企业落地多云战略提供了便捷的基础设施。它基于中立、厂商无关的设计，让用户在极小代价情况下，灵活接入和切换多云和混合云；同时它为客户在微服务跨集群编排、跨集群弹性伸缩，多云化的访问、容灾等场景带来了便利性。”DaoCloud 联合创始人兼首席架构师颜开表示。基于对可持续供应的考虑，以及对业务快速扩展的需求，混合云多云已成为携程集团的技术优选。“Karmada 以其标准的 K8s API 兼容性、关注点分离的原则、活跃的社区，帮助我们构建了混合多云的控制面，降低了架构迁移成本和异构环境的管理复杂性。”携程集团容器与混合云团队总监乐鸿辉表示，携程借助于Karmada 实现的故障隔离架构和多集群 HPA，也帮助公司成功应对旅游业的强劲复苏。“Karmada 简化了多集群环境中的集群与应用的交付和管理，实现跨集群的资源协调，以增强应用程序的可用性和弹性。它确保稳定、高效、可控的应用程序部署和更新。”Shopee 专家工程师李鹤表示。“Karmada 作为开源的多云容器编排平台，为云原生中间件提供了灵活性和可靠的跨平台、跨区域、跨云的资源管理，为中间件同城跨机房高可用提供了基石。”网易资深开发工程师孟祥勇表示。目前，Karmada 社区已累计更新67个版本。晋级 CNCF 孵化项目后，项目进一步规划了社区发展路标，并正在积极添加新功能和特性，如多集群安全、大规模场景应用、多集群可观测性、多集群应用分发、生态融合发展等。作为 CNCF 亚洲唯一创始成员、白金会员，华为云在CNCF贡献量、Kubernetes社区和 Istio 社区的代码贡献量持续多年稳居亚洲第一，已向 CNCF 贡献了业界首个云原生边缘计算项目 KubeEdge、首个云原生批量算力项目 Volcano 等多个重量级云原生开源项目，并持续开源 Kurator、Kappital、Kuasar 等创新项目，与全球云原生社区共同发展。华为云分布式云原生 UCS 基于 Karmada 项目构建全新的应用算力供给模式，解决资源供应，协同全局资源，提供领先的分布式云原生应用服务。Karmada 正式晋级 CNCF 孵化项目，进一步展现了华为云持续践行开源、拥抱开源，与全球开发者共创先进技术的理念，持续助力云上开源创新生态发展。未来，Karmada 将持续探索云原生多云多集群领域技术创新，让基于 Karmada 的多云方案融入更广泛的云原生技术生态。Karmada官网：https://karmada.io/项目地址：cid:link_0Slack地址：https://slack.cncf.io/

作者：华为云云原生团队随着云原生技术在越来越多的企业和组织中的大规模落地，如何高效、可靠地管理大规模资源池以应对不断增长的业务挑战成为了当下云原生技术的关键挑战。在过去的很长一段时间内，不同厂商尝试通过扩展单集群的规模来扩展资源池。然而，Kubernetes社区很早就发布了大规模集群的最佳实践，其中包括几项关键数据：节点数不超过5k，Pod数不超过150k，单个节点的Pod数量不超过110 k等。这侧面说明了支持超大规模的集群不是Kubernetes社区主要努力的方向。同时，以单集群的方式扩展资源池通常需要定制Kubernetes的原生组件，这在增加了架构复杂度的同时也带来了不少弊端：（1）集群运维复杂度急剧增加。（2）与社区演进方向相左，后续的维护成本上升，升级路径不清晰。（3）单集群本质上属于单个故障域，集群故障时将导致无法控制爆炸半径。而多集群技术能在不侵入修改Kubernetes单集群的基础上横向扩展资源池的规模，在扩展资源池的同时降低了企业的运维管理等成本。此外，多集群系统天然支持多故障域，符合多数业务场景，如多地数据中心、CDN就近提供服务等。Karmada作为CNCF首个多云容器编排项目，提供了包括Kubernetes原生API支持、多层级高可用部署、多集群故障迁移、多集群应用自动伸缩、多集群服务发现等关键特性，致力于让用户轻松管理无限可伸缩的资源池，为企业提供从单集群到多云架构的平滑演进方案。随着以Karmada为代表的多集群架构在企业的逐步落地，大规模场景下多集群系统的性能问题往往是用户的核心关注点之一。本文将围绕以下几个问题，结合Karmada社区对大规模场景的思考，揭示Karmada稳定支持100个大规模集群、管理超过50万个节点和200万个Pod背后的原理。（1） 如何衡量一个多集群系统资源池的维度与阈值？（2） 对多集群系统进行大规模环境的压测时，我们需要观测哪些指标？（3） Karmada是如何支撑100个大规模K8s集群并纳管海量应用的？（4） 在Karmada的生产落地过程中，有哪些最佳实践和参数优化手段可以参考？▎多集群系统资源池的维度与阈值当前，业界对于多云资源池的Scalability尚未达成统一标准，为此，Karmada社区结合企业用户的实践，率先对这一问题进行了深入探索。一个多集群系统资源池规模不单指集群数量，实际上它包含很多维度的测量标准，在不考虑其他维度的情况下只考虑集群数量是毫无意义的。在若干因素中，社区按照优先级将其描述为以下三个维度：（1） 集群数量。集群数量是衡量一个多集群系统资源池规模和承载能力最直接且最重要的维度。（2） 资源（API对象）数量。对于多集群系统的控制面来说，存储并不是无限的，在控制面创建的资源对象的数量和总体大小受限于系统控制面的存储，也是制约多集群系统资源池规模的重要维度。这里的资源对象不仅指下发到成员集群的资源模板，而且还包括集群的调度策略、多集群服务等资源。（3） 集群规模。集群规模是衡量一个多集群系统资源池规模不可忽视的维度。一方面，集群数量相等的情况下，单个集群的规模越大，整个多集群系统的资源池越大。另一方面，多集群系统的上层能力依赖系统对集群的资源画像，例如在多集群应用的调度过程中，集群资源是不可或缺的一个因素。综上所述，单集群的规模与整个多集群系统息息相关，但单集群的规模同样不是制约多集群系统的限制因素。用户可以通过优化原生的Kubernetes组件的方式来提升单集群的集群规模，达到扩大整个多集群系统的资源池的目的，但这不是衡量多集群系统性能的关注点。在集群的标准配置中，Node与Pod毫无疑问是其中最重要的两个资源，Node是计算、存储等资源的最小载体，而Pod数量则代表着一个集群的应用承载能力。▎大规模场景下多集群系统的性能指标在多集群系统的大规模落地进程中，如何衡量多集群联邦的服务质量是一个不可避免的问题。在参考了Kubernetes社区的SLI(Service Level Indicator)/SLO(Service Level Objectives)和多集群系统的落地应用后，Karmada社区定义了以下SLI/SLO来衡量大规模场景下多集群联邦的服务质量。API Call LatencyStatusSLISLOOfficial最近5min的单个Object Mutating API P99 时延除聚合API和CRD外，P99 <= 1sOfficial最近5min的non-streaming read-only P99 API时延除聚合API和CRD外P99 :(a) <= 1s if scope=resource (b) <= 30s otherwise (if scope=namespace or scope=cluster)注：API调用时延仍然是衡量基于Kubernetes的多集群系统服务质量的关键指标。Karmada兼容Kubernetes原生API，用户除了使用原生API创建K8s的资源模板外，也可以使用Karmada自有API来创建多集群策略和访问跨集群的资源。Resource Distribution LatencyStatusSLISLOOfficial用户在联邦控制面提交资源模板和下发策略后到资源在成员集群上被创建的P99时延，不考虑控制面与成员集群之间的网络波动P99 <= 2sCluster Registration LatencyStatusSLISLOWIP集群从接入联邦控制面到状态能被控制面正常收集的P99时延，不考虑控制面与成员集群之间的网络波动TBD注：集群注册时延是从集群注册到控制面到集群在联邦侧可用的时延，它反映了控制面接入集群以及管理集群的生命周期的性能。但它在某种程度上取决于控制面如何收集成员集群的状态。因此，我们不会对这个指标进行强制的限制。Resource UsageStatusSLISLOWIP在接入一定数量的集群后集群联邦维持其正常工作所必需的资源使用量TBD注：资源使用量是多集群系统中非常重要的指标，我们希望在纳管海量的集群和资源的同时消耗尽量少的系统资源。但由于不同的多集群系统提供的上层服务不同，因此对于不同的系统，其对资源的要求也会不同。因此，我们不会对这个指标进行强制的限制。▎Karmada百倍集群规模基础设施揭秘Karmada社区在结合对上述两个问题的思考以及用户在落地过程中的反馈后，测试了Karmada同时管理100个5K节点和2w Pod的Kubernetes集群的场景。本文不详细描述具体的测试环境信息与测试过程，而是侧重于对测试结果进行分析在整个测试过程中，API调用时延均符合上述定义的SLI/SLO。图一：只读API（cluster-scope）调用时延图二：只读API(namespace-scope)调用时延图三：只读API(resource-scope)调用时延图四：Mutating API调用时延Karmada在百倍集群规模下，仍能做到快速的API响应，这取决于Karmada独特的多云控制面架构。事实上，Karmada在架构设计之初就采用了关注点分离的设计理念，使用Kubernetes原生API来表达集群联邦资源模板，使用可复用的策略API来表达多集群的管理策略，同时控制面的资源模板作为应用的模板，不会在控制面生成具体的Pod。不同集群的应用在控制面的映射（Work对象）通过命名空间来进行安全隔离。完整的API工作流如下图所示。如此设计，不仅可以让Karmada能够轻松集成Kubernetes的生态, 同时也大大减少了控制面的资源数量和承载压力。基于此，控制面的资源数量不取决于集群的数量，而是取决于多集群应用的数量。此外，Karmada的架构极具简洁性和扩展性。karmada-apiserver作为控制面的入口与kube-apiserver类似，即使是在百倍集群规模下，Karmada仍能保持快速API响应。Karmada支持通过命令行快速接入集群，以及集群的全生命周期管理。Karmada会实时采集集群心跳和状态，其中集群状态包括集群版本、支持的API列表、集群健康状态以及集群资源使用量等。其中，Karmada会基于集群资源使用量对成员集群进行建模，这样调度器可以更好地为应用选择资源足够的目标集群。在这种情况下，集群注册时延与集群的规模息息相关。下表展示了加入一个5,000节点的集群直至它可用所需的时延。你可以通过关闭集群资源建模来使集群注册时延与集群的大小无关，在这种情况下，集群注册时延这个指标将小于2s。Cluster Registration Latency:metricP50(ms)P90(ms)P99(ms)SLOcluster_register535661256904N/AKarmada支持多模式的集群统一接入，在Push模式下，Karmada控制面直连成员集群的kube-apiserver，而在Pull模式下，Karmada将在成员集群中安装agent组件，并委托任务给它。因此Push模式多用于公有云的K8s集群，需要暴露APIServer在公网中，而Pull模式多用于私有云的K8s集群。下表展示了Karmada在不同模式下下发一个应用到成员集群所需的时延。Resource Distribution Latency:MetricP50(ms)P90(ms)P99(ms)SLOcluster_schedule121532N/Aresource_distribution(Push)70689912982000resource_distribution(Pull)6128819892000结论：我们容易得出，不论是Push模式还是Pull模式，Karmada都能高效地将资源下发到成员集群中。在Karmada演进的数个版本中，大规模场景下使用Karmada管理多云应用的资源消耗一直是用户比较关注的问题。Karmada社区做了许多工作来减少Karmada管理大型集群的资源使用量，比如我们优化了Informer的缓存，剔除了资源无关的节点、Pod元数据；减少了控制器内不必要的类型转换等等。相较于1.2版本，当前Karmada在大规模集群场景下减少了85%的内存消耗和32%的CPU消耗。下图展示了不同模式下Karmada控制面的资源消耗情况。Push模式：Pull模式：总的来说，系统消耗的资源在一个可控制面的范围，其中Pull模式在内存使用上有明显的优势，而在其他资源上相差的不大。▎Karmada大规模环境下的最佳实践Karmada支持性能参数的可配置化，用户可以通过调整组件的参数来调整同一时间段内并发处理Karmada内部对象的数量、系统的吞吐量等以优化性能。同时Karmada在不同模式下的性能瓶颈并不相同，以下着重对此进行分析。在Push模式中，控制面的资源消耗主要集中在karmada-controller-manager（约70%），而Karmada控制面基座（etcd/karmada-apiserver）的压力不大。结合karmada-apiserver的qps以及karmada-etcd的请求时延我们可以看出karmada-apiserver的请求量保持在一个较低的水平。在Push模式中，绝大多数的请求来自karmada-controller-manager。因此我们可以通过调整karmada-controller-manager的--concurrent-work-syncs来调整同一时间段并发work的数量来提升应用下发的速度，也可以配置--kube-api-qps和--kube-api-burst这两个参数来控制Karmada控制面的整体流控。在Pull模式中，控制面的资源消耗主要集中在karmada-apiserver，而不是karmada-controller-manager。结合karmada-apiserver的qps以及karmada-etcd的请求时延我们可以看出karmada-apiserver的请求量保持在一个较高的水平。在Pull模式中，每个成员集群的karmada-agent需要维持一条与karmada-apiserver通信的长连接。我们很容易得出：在下发应用至所有集群的过程中请求总量是karmada-agent中配置的N倍(N=#Num of clusters)。因此，在大规模Pull模式集群的场景下，Pull模式在资源下发/状态收集方面有更好的性能，但同时需要考虑控制面的抗压能力以及各个karmada-agent和控制面的整体流控。当前，Karmada提供了集群资源模型的能力来基于集群空闲资源做调度决策。在资源建模的过程中，它会收集所有集群的节点与Pod的信息。这在大规模场景下会有一定的内存消耗。如果用户不使用这个能力，用户可以关闭集群资源建模来进一步减少资源消耗。▎总结根据上述测试结果分析，Karmada可以稳定支持100个大规模集群，管理超过50万个节点和200万个Pod。在Karmada落地进程中，用户可以根据使用场景选择不同的部署模式，通过参数调优等手段来提升整个多集群系统的性能。受限于测试环境和测试工具，上述测试尚未测试到Karmada多集群系统的上限，同时多集群系统的分析理论以及测试方法仍处于方兴未艾的阶段，下一步我们将继续优化多集群系统的测试工具，系统性地整理测试方法，以覆盖更大的规模和更多的典型场景。添加小助手微信k8s2222，进入云原生交流群