Karmada 用户组再迎重要新成员，商汤科技[1]正式加入。 作为云原生计算基金会（CNCF）旗下项目，Karmada 致力于为用户提供强大的多集群管理和调度能力，帮助企业在复杂的分布式环境中实现高效的应用部署和管理。 商汤科技的加入将进一步加强 Karmada 社区，为项目的持续创新注入新的活力，标志着社区发展及 Karmada 在多样化生产环境中应用的又一个重要里程碑。   关于商汤科技  商汤科技坚持“AI 基础设施（大装置）-大模型（日日新）-应用”三位一体战略。 商汤大装置作为商汤科技前瞻打造的高效率、低成本、规模化的新一代 AI 基础设施， 以大模型开发、生成、应用为核心，赋能人工智能生产新范式。 通过与大模型迭代的联合调优，打造“最懂大模型的 AI 基础设施”。2022年，作为商汤大装置重要载体的人工智能计算中心（上海临港 AIDC）正式投入运营， 成为亚洲最大人工智能计算中心之一。过去三年， 商汤持续投入建设并自持全国首个 5A 级智算中心上海临港 AIDC， 以及通过运营模式将算力总规模提升至32,000 PFlops（截至2025年12月）。 强大算力可支撑超过 20 多个千亿参数超大模型同时训练， 并支持万亿参数大模型的全生命周期生成。作为行业先行者，商汤大装置已构建起“算力-平台-方案-服务”的端到端系统化能力， 既为商汤日日新大模型的迭代提供了核心动力， 也快速承接了各行业客户的大模型创新需求， 持续赋能 AIGC、具身智能、AI4S、产业智能化等相关领域创新。  关于 Karmada 用户组  Karmada 用户组是一个由在其环境中成功采用 Karmada 的组织和用户组成的社区。作为连接社区与用户的核心纽带，Karmada 用户组致力于打造一个深度融合、开放协作的高价值平台，推动成员间的高效联动与经验共享，助力云原生多云多集群生态系统的蓬勃发展。成为 Karmada 用户组成员具有以下优势：社区认可：作为云原生多集群管理领域的领导者来展示您的组织，在 CNCF 和 Karmada 社区中获得知名度；协作与交流：与其他采用者建立联系，分享最佳实践，并在实际用例和解决方案上进行协作；保持更新：及时接收重要更新通知，包括关键功能、错误修复和安全建议；活动参与：受邀参与 Karmada 相关活动，包括 KubeCon + CloudNativeCon、网络研讨会和聚会；职位发布：有机会在 Karmada 社区支持的职位公告板上发布与 Karmada 相关的职位空缺（暂不可用）；扩展商业机会：与 Karmada 生态系统的其他成员建立潜在的商业联系和合作。您可以在 GitHub 社区仓库中了解更多关于 Karmada 用户组[2] 的信息， 并在 karmada.io/adopters [3] 查看完整的公开的采用者列表。截至目前，Karmada 用户组已吸纳来自全球的 40+ 家机构和组织。更多使用场景及案例研究请查阅：https://karmada.io/adopters   加入 Karmada 用户组   Karmada 用户组对当前正在生产环境中使用 Karmada 的最终用户和供应商开放。这包括：最终用户：在其生产环境中运行 Karmada 的组织；供应商：提供基于 Karmada 的产品或服务，并有客户在生产环境中使用这些产品或服务的公司。您是否在生产环境中使用 Karmada 并有兴趣加入 Karmada 用户组？访问下方 Karmada 用户组申请表单 [4]，提交 issue 申请，即可接收申请进度。手机端可扫描下方二维码快捷填写申请表单。 扫码申请加入用户组更多信息，请访问：[1] 商汤科技: https://www.sensetime.com/[2] Karmada 用户组: cid:link_0[3]Karmada 采用者列表: http://karmada.io/adopters[4]Karmada 用户组申请表单: https://github.com/karmada-io/community/issues/new?template=adopter-group-application.yamlKarmada Adopter Group 欢迎您的加入！期待与您共同创建一个友好而活跃的空间，共享知识、最佳实践和经验，为企业与社区发展缔造更多可能。如需了解更多关于 Karmada Adopter Group 的信息，请联系: Maintainer Mailing Listcncf-karmada-maintainers@lists.cncf.io  Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、滴滴、腾讯、中国电子云等60多家公司的全球贡献者，广泛分布于22个国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：cid:link_1Slack地址：https://slack.cncf.io/（#karmada） 扫码回复“Karmada” 进入技术群 

面对互联网大促，技术团队最为焦虑的莫过于“系统能否扛住”，如何打破“峰值体验差”与“资源成本失控”的魔咒？沙特家电零售巨头 Alsaif Gallery 借助华为云 CCE Autopilot，实现系统时延降低 75%、日常运维负担减少 80%、成本优化 30%。当2025年沙特国庆日销售战绩定格在单日5万订单时，Alsaif Gallery 技术团队感受到的不仅是喜悦，更是一种久违的从容。就在数月前，同样的流量洪峰还意味着紧绷的神经与对系统中断的深深焦虑。如今，这一切已成为历史。运维工作从过去如“黑盒”般不可预测，到如今“智驾”般自动高效，曾经困扰 Alsaif Gallery 许久的“流量峰值用户体验”和“失控的资源成本”两大难题，已不再是平台业务爆发增长的绊脚石。这家沙特家电零售巨头的数字化转型之路，因一次关键的云迁移而彻底提速。业务狂奔，技术绊脚作为沙特前三的家电零售商，Alsaif Gallery线上业务增长迅猛。日均超3万笔订单的电商平台，是其当之无愧的业务核心引擎。然而，这台引擎的基础设施却长期饱受压力。原有云架构的复杂性，让技术团队在每次大促前都如履薄冰。他们面临着三重挑战：排障如“黑盒”：平台故障排查依赖原第三方厂商跨国支持，响应迟缓，排障效率低，并且缺乏全链路观测工具，定位问题如同大海捞针。运维靠“人扛”：中东本地资深的K8s与SRE专家稀缺，导致现有K8s集群只能维持基本运行，无法进行深度性能优化。同时，高度复杂且耦合的系统，运维严重依赖少量核心人员，使得性能瓶颈与运维风险并存。成本“过山车”：面对突发流量，原有基于虚拟机的资源模式扩缩速度慢，人工配置的扩缩策略难以自适应多变的流量。促销时资源“扩不上去”，影响用户体验；促销后资源“缩不下来”，白白浪费成本。对于依赖“斋月”、“白色星期五”等关键销售季的中东零售业而言，这不仅是技术问题，更是直接关乎品牌声誉的业务风险。Alsaif Gallery&华为云：一场始于信任的“无感迁移”面对与旧云服务深度捆绑的复杂架构，Alsaif Gallery对迁移最初持谨慎态度。华为云团队用专业与诚意破除了这层顾虑。这不是简单搬家，而是联创设计。华为云交付团队与架构师提前介入，通过超10次的深度技术交流与业务梳理，将客户“提升系统稳定性、降低运维成本”的核心诉求，转化为一套量身定制的“上云+优化”组合方案。不回避难题，而是逐一攻克。针对容器搬迁、函数改造、安全配置等十余项具体技术挑战，华为云拉通产品专家驻场支持，将迁移风险一一化解。这种直面复杂性的务实态度，赢得了客户的最终信任，决心将核心容器业务迁至华为云CCE Autopilot。系统运维跃迁：从“手动挡”到“智能驾驶”系统整体迁移仅仅花费一个月，但变化效果立竿见影。华为云CCE Autopilot的Serverless能力，为Alsaif Gallery带来了运维模式的根本性变革：全面自动化：节点、操作系统、集群升级全面自动化，让技术团队从繁琐的基础设施维护中解放出来。无缝兼容：100%兼容K8s生态，原有应用平滑迁移，业务0改造。精准弹性：基于真实负载的秒级伸缩，实现所得即所需的理想状态。迁移后，Alsaif Gallery成果直接体现在三个关键指标上：负担锐减：日常运维工作量降低80%，让技术团队得以聚焦创新。成本优化：凭借按需计费与精准弹性，资源利用率提升20%，成本降低30%以上。体验提速：系统时延从120ms大幅降低至30ms以内，用户端操作响应更加流畅。通过此次迁移，让Alsaif Gallery技术专家角色由此转变：从过去疲于奔命的“消防员”，转型成为了驾驭高效引擎、驱动业务增长的“设计师”。持续共建：从云迁移到长期战略合作本次迁移的成功，不是终点，而是Alsaif Gallery与华为云更长远合作的起点。基于建立起的信任，双方合作正向纵深发展：从大数据治理中挖掘零售电商高增长业务，到构建AI知识库提升内部效率，一系列新的数字化规划已提上日程。而华为云在其中的独特价值在于：不仅是技术的提供者，更是深谙本地市场的同行者。在沙特，华为云拥有超过200名本地技术专家，能提供7*24小时无时差响应，并深刻理解区域合规与市场特性，真正做到了“全球能力，本地服务”。云计算新范式：从“资源开销”变成“业务引擎”在沙特“2030愿景”掀起的数字化浪潮中，企业的竞争本质上是效率与敏捷性的竞争。华为云通过CCE Autopilot，为Alsaif Gallery提供的不仅是一个更强大的云平台，更是一套将复杂运维自动化、让运营成本可视可控的系统。这标志着一种全新范式的转变：云计算从“资源开销”变为企业真正的“业务引擎”。当数字基石稳固而智能，企业的增长便只需聚焦于前方更广袤的市场。 

作者：Volcano Maintainers今天，我们激动地向全球开发者和 MLOps 工程师宣布，Volcano 社区迎来了一个新的子项目 Kthena！Kthena 是一个专为 Kubernetes 设计的云原生、高性能 LLM 推理路由和编排、调度系统。它旨在解决在生产环境中大规模编排、部署和服务 LLM 所面临的核心挑战，通过其独特的超节点拓扑感知的亲和性调度，KV Cache 感知的流量调度、Prefill/Decode 分离路由等高级功能，显著提升 GPU/NPU 资源利用率和吞吐，降低推理延迟，赋予企业前所未有的灵活性和控制力。作为 Volcano 的子项目，Kthena 将致力于帮助 Volcano 扩展除 AI 训练之外的边界，打造训推一体的完整解决方案。  LLM 服务化的“最后一公里”困境  大语言模型（LLM）正在以前所未有的速度重塑各行各业，但将其高效、经济地部署在生产环境中，特别是基于 Kubernetes 的云原生平台上，仍然困难重重。开发者们普遍面临以下挑战：1.  资源利用率低：LLM 推理，尤其是其独特的 KV Cache 机制，对 GPU、NPU 显存的占用是动态且巨大的。传统的负载均衡一般采用Round-Robin算法，无法感知这种负载特性，导致 GPU、NPU 资源闲置与请求排队并存，成本高昂。2.  延迟与吞吐量难以兼顾：LLM 推理分为“Prefill”（处理输入提示）和“Decode”（生成 Token）两个阶段，前者是计算密集型，后者是访存密集型。将两者混合调度，常常导致无法针对性优化，影响整体服务的响应速度和吞吐能力。因此PD分离的部署已经成为主流，但如何高效路由和调度，仍是一个难题。3.  多租户与多模型管理复杂：在企业环境中，通常需要同时提供多个不同模型、不同版本或经过 LoRA 微调的模型。如何实现请求的公平调度、优先级管理以及动态路由，是一个复杂的工程难题，业界甚至有些方案将AI网关与大模型一一对应。4.  缺乏K8s原生集成：许多现有的解决方案要么是外部系统，与 Kubernetes 生态割裂；要么过于复杂，无法满足生产级所需的简单易用性和灵活运维。  Kthena：云原生 LLM 推理的智能大脑  为了攻克上述难题，Kthena 应运而生。它并非要取代现有的 LLM 服务框架（如 vLLM, sgLang），而是作为它们上层的智能“交通枢纽”和“调度中心”，深度集成于 Kubernetes 之中。Kthena 架构图Kthena 的核心由两大组件构成：1）Kthena Router：一个独立、高性能面向多模型的router，负责接收所有推理请求，并根据 ModelRoute 规则，智能地将请求分发到后端的 ModelServer。2）Kthena Controller Manager：Kubernetes 控制平面的控制器，它主要包含多种控制器，负责 LLM 工作负载的编排与生命周期管理。它持续调谐并联动多类 CRD（如 ModelBooster、ModelServing、AutoScalingPolicy/AutoScalingPolicyBinding、以及 ModelRoute/ModelServer），将声明式API转化为运行时资源：ModelServing 控制器编排 ServingGroup 与 Prefill/Decode 角色分组；支持网络拓扑亲和调度和Gang调度、滚动升级与故障恢复；基于 AutoScalingPolicy 实现弹性扩缩容。这种架构使得 Kthena 成为连接用户请求与 LLM 模型的高度可编程的桥梁。  核心特性与优势  Kthena 的强大之处在于其专为 LLM 推理场景设计的核心功能：1) 生产级推理编排（ModelServing）LLM工作负载三层架构设计：ModelServing -> ServingGroup -> Role，一个API，支持LLM原生部署、PD分离部署，乃至大EP部署等多种部署形态，简化管理多LWS的负担。例如对于PD分离的大规模部署，可用一个ModelServing表示，根据负载的大小每个ModelServing可以包含任意数目的 ServingGroup（xPyD 分组）， 每个ServingGroup包含多个角色（Prefill Decode，他们通常部署在同一个超节点内以提升推理性能），相同的角色可以等价为一个LeaderWorkerSet，支持TP/PP/EP等多节推理并行计算。原生支持Prefill-Decode分离部署：将计算密集型的 Prefill 实例调度到配备高性能计算卡的节点组，而将访存密集型的 Decode 实例调度到配备高带宽显存的节点组，实现资源的最佳匹配和极致的端到端延迟优化。另可以独立伸缩，动态调整Prefill-Decode的比例，更灵活的应对各种复杂的业务场景（如长短句混合、实时推理等）。多并行范式支持：TP/PP/DP/EP 等并行模式灵活配置，最大化提升资源利用率和SLO内置拓扑感知、Gang 调度支持：Gang调度确保ServingGroup/Role“成组原子化”落地，避免资源浪费；拓扑感知调度通过将Role内的一组Pod调度到网络拓扑更优的节点，提升并行计算的数据传输时延。2) 开箱即用的模型上线（ModelBooster）针对主流的大模型，提供包括PD分离在内的多种部署范式模板，自动生成ModelRoute/ModelServer/ModelServing/Autoscaling等路由策略和生命周期管理资源覆盖通用的部署场景，至于更灵活的编排可通过ModelServing进行细粒度的控制3) 智能、模型感知的路由（Kthena Router）多模型路由：兼容OpenAI API，根据请求头或Body体内容，将流量调度到不同的基础模型。插件化调度算法：提供最少请求、最小时延、KV Cache 感知、Prefix Cache 感知、LoRA 亲和、GPU 利用率感知、公平调度等多种负载均衡算法，满足用户不同业务场景和部署形态的需求LoRA 模型热插拔无中断：感知推理引擎加载的LoRA 适配器，提供无中断的插拔和路由能力丰富的流量治理策略：基于权重的模型路由，金丝雀发布、Token级流控、故障转移·All-in-one实现架构，无需部署Envoy Gateway，原生支持PD分离的流量调度，将多层路由合并成一层，易于维护4) 成本驱动的自动扩缩容（Autoscaler）同构伸缩：支持稳定、突发双模式，按业务指标（CPU/GPU/内存/自定义）精准扩缩异构部署优化：在多推理引擎/异构加速器组合中按“成本-能力”贪心分配，最大化性价比5) 主流推理引擎与异构硬件支持支持多种主流推理引擎vLLM、SGLang、Triton/TGI 等，统一API抽象、标准化指标支持GPU/NPU 等异构混部，配合异构 Autoscaling 实现成本与 SLO 的动态平衡6) 内置流量控制与公平性调度公平调度：支持基于优先级和历史Token消耗的的公平调度，既兼顾用户的优先级，对高优先级用户提供更好的服务，又防止低优先级用户“饿死”流量控制：支持按照用户、模型、token长度进行精细化流量控制。  极致的性能提升  基于 Kthena Router 的调度插件架构，在长系统提示词场景（如 4096 tokens）下，采用“KV Cache 感知 + 最少请求”策略相较随机基线：吞吐可提升约 2.73 倍TTFT 降低约 73.5%端到端时延降低超过 60%短提示词场景差距会随提示词长度收敛，但在多轮对话、模板化生成、前缀高度相似的业务中，KV Cache 感知策略优势显著。实际收益与模型规模、Prompt长短、硬件紧密相关，但“按需组合、按场景选型”已被验证有效。  社区展望 / Call for Contribution  Kthena 在项目规划和发展的初期便得到了部分社区用户单位的关注和支持，但这只是一个开始。我们计划在未来支持更高效的调度算法、更广泛的大模型最佳部署实践，并持续深耕 LLM 推理的大规模部署和性能优化。“ 开源是技术创新的源头活水，也是推动产业标准化的最强引擎。作为Volcano项目的发起单位，华为云很荣幸能够与社区其他伙伴一起推出全新的Kthena分布式推理项目。这不仅是Volcano社区技术演进的重要里程碑，更是华为云在云原生AI领域长期投入与持续创新的有力见证。它将与华为云CCE（云容器引擎）、CCI（云容器实例）等基础设施深度结合，进一步释放包括昇腾（Ascend）在内的多元算力价值，为客户提供极致的算力性价比。我们希望通过Kthena，与全球开发者与伙伴，共建、共享一个开放、繁荣的云原生AI生态，为千行万业的智能化升级构筑最坚实的算力底座。”—— 祁小波，华为云通用计算服务产品部部长“ Kthena进一步巩固了Volcano在智能计算调度领域的领先地位。我们的平台利用Volcano的统一调度与资源池化能力，一站式满足通用计算与智能计算中训练、推理等多类算力需求。这使得算力资源能够在不同场景间灵活流转，有效避免了资源割裂的问题。展望未来，我们期待 Kthena结合Volcano的弹性伸缩能力与Volcano Global的跨集群调度特性，共同推动算力资源利用率进一步提升！”—— 杨磊，中电信人工智能公司 PaaS研发总监“ Volcano 项目自诞生之日起，便始终与社区以及各类 AI 场景深度共建、同频演进，逐步沉淀出一整套面向 AI 工作负载的调度与批处理生态。今天，Kthena 的出现，不仅将这条共建链路进一步拓展到大模型推理领域，把推理这一关键一环真正纳入 Volcano 生态之中，更是在统一编排与智能路由层面，将 Volcano 在调度、弹性伸缩以及多算力适配上的多年实践，凝练成一个令人振奋的里程碑式能力。借助既有的 Kubernetes / Volcano 生态，更多团队可以用更低的成本，获得更智能的调度决策和更高效的算力利用，并在开放协作的基础上持续演进。这不仅为道客解决了在推理场景中遇到的实际问题，也是我们所期待的云原生 AI 形态——一个足够开放、足够智能、值得我们长期投入和深度参与的社区方向。”—— 徐俊杰，DaoCloud 开源团队负责人，Kubernetes 社区指导委员会成员“ 自建大模型推理服务的生产级部署和运维难题，是一个覆盖推理服务全生命周期管理（部署、运维、弹性、故障恢复等），GPU集群稳定性，资源调度效率、推理服务性能提升，推理流量智能调度、AI可观测等领域的系统工程。而这也正是Kthena项目的技术定位。早在Kthena的规划阶段，小红书云原生团队就和Kthena贡献者做了深度的沟通，在推理流量智能调度方向，一起设计了多种流量调度策略和路由实现。未来，双方将继续在AI网关方向合作，结合小红书内部业务经验，一起为社区提供更精细化的AI流量智能调度能力，模型API管理能力，MCP协议支持等多种生产可用能力。”—— 空古(陈华昌)，小红书云原生业务网关负责人“ 在深入调研并试用Kthena这一云原生AI推理平台后，联通云对其展现出的前瞻能力印象深刻。我们尤为看好其与Volcano实现的联合调度特性，其网络拓扑感知与Gang Scheduling功能，能够有效解决大规模分布式模型推理场景下中，关于效率与可靠性的核心诉求，为破解复杂调度难题提供了极具潜力的解决方案。我们相信，Kthena卓越的低延迟、高吞吐与多模型智能路由能力，将为开源社区带来真正具备生产级的AI推理解决方案，助力开发者更高效地构建和管理云原生环境下的智能应用。”—— 卢照旭，联通云智算能力中心团队长“ 开放和协作是构建社区的未来、加速技术创新的核心动力。在CNCF，我们持续致力于推动基础设施向‘AI Native’演进，为整个云原生生态提供标准、中立且可扩展的基础能力。Volcano社区通过孵化Kthena子项目，将其在大规模批量计算和调度上积累的拓扑感知、Gang调度等核心经验，精准地应用到了LLM在线推理这一关键场景。Kthena的价值在于，它提供了一套专为大模型设计、可供业界参考借鉴的云原生调度原语和抽象，这有助于将复杂的LLM推理工作负载，真正以Kubernetes原生的一等公民身份进行高效管理。这不仅是Volcano项目技术演进的重要一步，更是社区生态在解决AI规模化部署挑战中贡献的一份重要实践经验。我们诚挚邀请全球的开发者、研究人员和所有云原生爱好者加入，共同贡献智慧，完善这些关键AI基础设施，加速 AI Native 进程。”—— Kevin Wang，Volcano Maintainer、CNCF TOC 副主席  立即开始探索 Kthena  GitHub 仓库: cid:link_1Volcano 官网: https://kthena.volcano.sh/社区（加入我们的 Slack）: https://cloud-native.slack.com/archives/C011GJDQS0N让我们一起，为 LLM 插上云原生的翅膀，释放 AI 的全部潜能！ Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。 更多云原生技术动向关注容器魔方

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。本系列文章将介绍Karmada的使用教程，本文介绍如何通过 Workload Rebalancer 触发重调度。目标一般情况下，工作负载类资源被调度后，会保持调度结果不变，其副本分布不会轻易发生变化。 现在，假设某些特殊情况下，您想主动触发一次重调度，可以通过使用 WorkloadRebalancer 来实现。因此，本节将指导您如何使用 WorkloadRebalancer 来触发重调度。 前提条件▍Karmada 及多个子集群已安装运行安装命令：git clone cid:link_0cd karmadahack/local-up-karmada.shexport KUBECONFIG=~/.kube/karmada.config:~/.kube/members.config 说明：在开始之前，我们应该至少安装三个 kubernetes 集群，一个用于安装 Karmada 控制平面，另外两个作为成员集群。 为了方便，我们直接使用 hack/local-up-karmada.sh 脚本快速准备上述集群。执行上述命令后，您将看到 Karmada 控制平面和多个成员集群已安装完成。教程▍第一步：创建一个 Deployment首先准备一个名为 foo 的 Deployment，您可以创建一个新文件 deployment.yaml，内容如下：apiVersion: apps/v1kind: Deploymentmetadata: name: foo labels: app: testspec: replicas: 3 selector: matchLabels: app: foo template: metadata: labels: app: foo spec: terminationGracePeriodSeconds: 0 containers: - image: nginx name: foo resources: limits: cpu: 10m memory: 10Mi---apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata: name: default-ppspec: placement: clusterTolerations: - effect: NoExecute key: workload-rebalancer-test operator: Exists tolerationSeconds: 0 clusterAffinity: clusterNames: - member1 - member2 replicaScheduling: replicaDivisionPreference: Weighted replicaSchedulingType: Divided weightPreference: dynamicWeight: AvailableReplicas resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: foo namespace: default然后，运行下述命令来创建这些资源：kubectl --context karmada-apiserver apply -f deployment.yaml您可以通过下述方式来检查该步骤是否成功：$ karmadactl --karmada-context karmada-apiserver get deploy fooNAME CLUSTER READY UP-TO-DATE AVAILABLE AGE ADOPTIONfoo member1 2/2 2 2 20s Yfoo member2 1/1 1 1 20s Y可以看到，2 个副本分发到 member1 集群，1 个副本分发到 member2 集群。 ▍第二步：在 member1 集群添加 NoExecute 污点以模拟集群故障1）运行以下命令将 NoExecute 污点添加到 member1 集群：$ karmadactl --karmada-context=karmada-apiserver taint clusters member1 workload-rebalancer-test:NoExecutecluster/member1 tainted然后，由于集群故障转移，将触发重调度，并且所有副本将被分发到 member2 集群，您可以看到：$ karmadactl --karmada-context karmada-apiserver get deploy fooNAME CLUSTER READY UP-TO-DATE AVAILABLE AGE ADOPTIONfoo member2 3/3 3 3 57s Y2）运行以下命令从 member1 集群中移除上述 NoExecute 污点：$ karmadactl --karmada-context=karmada-apiserver taint clusters member1 workload-rebalancer-test:NoExecute-cluster/member1 untainted移除污点不会导致副本传播变化，因为调度结果是惰性的，所有副本将保持在 member2 集群中不变。 ▍第三步：创建一个 WorkloadRebalancer 来触发重调度为了触发上述资源的重调度，您可以创建一个新文件 workload-rebalancer.yaml，内容如下：apiVersion: apps.karmada.io/v1alpha1kind: WorkloadRebalancermetadata: name: demospec: workloads: - apiVersion: apps/v1 kind: Deployment name: foo namespace: default然后运行以下命令来创建该资源：kubectl --context karmada-apiserver apply -f workload-rebalancer.yaml您将得到 workloadrebalancer.apps.karmada.io/demo created 的结果，这意味着该资源创建成功。 ▍第四步：检查 WorkloadRebalancer 的状态运行以下命令：$ kubectl --context karmada-apiserver get workloadrebalancer demo -o yamlapiVersion: apps.karmada.io/v1alpha1kind: WorkloadRebalancermetadata: creationTimestamp: "2024-05-25T09:49:51Z" generation: 1 name: demospec: workloads: - apiVersion: apps/v1 kind: Deployment name: foo namespace: defaultstatus: finishTime: "2024-05-25T09:49:51Z" observedGeneration: 1 observedWorkloads: - result: Successful workload: apiVersion: apps/v1 kind: Deployment name: foo namespace: default因此，您可以在 workloadrebalancer/demo 的 status.observedWorkloads 字段中观察重调度的结果。 如上述结果所示，deployment/foo 已成功重新调度。 ▍第五步：观察 WorkloadRebalancer 的实际效果您可以观察 deployment/foo 的副本实际分发状态：$ karmadactl --karmada-context karmada-apiserver get deploy fooNAME CLUSTER READY UP-TO-DATE AVAILABLE AGE ADOPTIONfoo member1 2/2 2 2 3m14s Yfoo member2 1/1 1 1 4m37s Y您可以看到重调度已完成，有2个副本迁移回到 member1 集群，而 member2 集群中原有的1个副本保持不变。此外，您可以观察到由 default-scheduler 发出的调度事件，例如：$ kubectl --context karmada-apiserver describe deployment foo...Events: Type Reason Age From Message ---- ------ ---- ---- ------- ... Normal ScheduleBindingSucceed 3m34s (x2 over 4m57s) default-scheduler Binding has been scheduled successfully. Result: {member1:2, member2:1} Normal AggregateStatusSucceed 3m20s (x20 over 4m57s) resource-binding-status-controller Update resourceBinding(default/foo-deployment) with AggregatedStatus successfully. ... ▍第六步：更新并自动清理 WorkloadRebalancer假设您希望 WorkloadRebalancer 能在将来自动清理，您只需编辑资源声明并将 spec.ttlSecondsAfterFinished 字段设置为 300，例如：apiVersion: apps.karmada.io/v1alpha1kind: WorkloadRebalancermetadata: name: demospec: ttlSecondsAfterFinished: 300 workloads: - apiVersion: apps/v1 kind: Deployment name: foo namespace: default在您应用了这个修改后，这个 WorkloadRebalancer 资源将在 300 秒后自动删除。更多Karmada云原生多云容器引擎使用教程与技术交流，欢迎关注Karmada社区公众号或添加社区小助手k8s2222，回复Karmada进群。  Karmada 公众号 Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、滴滴、腾讯、中国电子云等60多家公司的全球贡献者，广泛分布于22个国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：cid:link_0Slack地址：https://slack.cncf.io/（#karmada）

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。本系列文章将介绍Karmada的使用教程，本文介绍如何通过原生 Service 跨集群访问服务。在 Karmada 中，MultiClusterService 可以让用户通过原生 Service 域名（例如 foo.svc）跨集群访问服务，目的是让用户获得如在单个集群中访问服务般访问跨集群服务的流畅体验。📄 本文档提供了这样一个案例：启用 MultiClusterService 来通过原生 Service 跨集群访问服务。前提条件▍Karmada 已安装您可以参考快速入门安装 Karmada，或直接运行 hack/local-up-karmada.sh 脚本，该脚本也用于运行 E2E 测试。▍成员集群网络确保至少已有两个集群加入 Karmada，并且成员集群之间的容器网络已连通。如果您使用 hack/local-up-karmada.sh 脚本部署 Karmada，Karmada 中会有 3 个成员集群，并且集群 member1 和 member2 间的容器网络已连通。您可以使用 Submariner 或其他相关开源项目来连接成员集群之间的网络。📌 注意：为了防止路由冲突，集群中 Pod 和 Service 的 CIDR 必须互不重叠。▍在 karmada-controller-manager 中启用 MultiClusterService要在 karmada-controller-manager 中启用 MultiClusterService 功能，请运行以下命令：kubectl --context karmada-host get deploy karmada-controller-manager -n karmada-system -o yaml | sed '/- --v=4/i \ - --feature-gates=MultiClusterService=true' | kubectl --context karmada-host replace -f -📌 请注意，MultiClusterService 功能默认是禁用的，可以通过 --feature-gates=MultiClusterService=true 参数开启。如果您倾向于更谨慎的方法，请按照以下步骤操作：运行 kubectl --context karmada-host edit deploy karmada-controller-manager -n karmada-system。检查 spec.template.spec.containers[0].command 字段中是否存在 --feature-gates=MultiClusterService=true。如果没有，添加 --feature-gates=MultiClusterService=true 来开启功能。在 member1 集群中部署 Deployment我们需要在 member1 集群中部署 Deployment：apiVersion: apps/v1kind: Deploymentmetadata: name: nginx labels: app: nginxspec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx resources: requests: cpu: 25m memory: 64Mi limits: cpu: 25m memory: 64Mi---apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata: name: nginx-propagationspec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinity: clusterNames: - member1部署完成后，您可以检查创建的 Pod：$ karmadactl get poNAME CLUSTER READY STATUS RESTARTS AGEnginx-5c54b4855f-6sq9s member1 1/1 Running 0 28snginx-5c54b4855f-vp948 member1 1/1 Running 0 28s在 member2 集群中部署 curl Pod让我们在 member2 集群中部署一个 curl Pod：apiVersion: apps/v1kind: Deploymentmetadata: name: curl labels: app: curlspec: replicas: 1 selector: matchLabels: app: curl template: metadata: labels: app: curl spec: containers: - image: curlimages/curl:latest command: ["sleep", "infinity"] name: curl resources: requests: cpu: 25m memory: 64Mi limits: cpu: 25m memory: 64Mi---apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata: name: curl-propagationspec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: curl placement: clusterAffinity: clusterNames: - member2部署完成后，您可以检查创建的 Pod：$ karmadactl get po -C member2NAME CLUSTER READY STATUS RESTARTS AGEcurl-6894f46595-c75rc member2 1/1 Running 0 15s稍后，我们将在此 Pod 中执行 curl 命令。在 Karmada 中部署 MultiClusterService 与 Service现在，我们不使用 PropagationPolicy/ClusterPropagationPolicy，而是利用 MultiClusterService 来分发 Service。要在 Karmada 中启用 MultiClusterService，请部署以下 yaml：apiVersion: v1kind: Servicemetadata: name: nginxspec: ports: - port: 80 targetPort: 80 selector: app: nginx---apiVersion: networking.karmada.io/v1alpha1kind: MultiClusterServicemetadata: name: nginxspec: types: - CrossCluster consumerClusters: - name: member2 providerClusters: - name: member1从 member2 集群访问后端 Pod要从 member2 集群访问 member1 集群中的后端 Pod，请执行以下命令：$ karmadactl exec -C member2 curl-6894f46595-c75rc -it -- sh~ $ curl http://nginx.defaultHello, world!Version: 1.0.0Hostname: nginx-0在此案例中，Pod 仅位于 member1 集群。但是，使用 MultiClusterService，就可以通过原生 Service 域名从 member2 集群实现跨集群访问。更多Karmada云原生多云容器引擎使用教程与技术交流，欢迎关注Karmada社区公众号或添加社区小助手k8s2222，回复Karmada进群。 Karmada 公众号Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、滴滴、腾讯、中国电子云等60多家公司的全球贡献者，广泛分布于22个国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。 Karmada官网：https://karmada.io/项目地址：cid:link_1Slack地址：https://slack.cncf.io/（#karmada）

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。本系列文章将介绍Karmada的使用教程，本文介绍如何使用 CronFederatedHPA 自动伸缩跨集群 Deployment 。在Karmada中，CronFederatedHPA 负责扩展工作负载（如Deployments）的副本或 FederatedHPA 的 minReplicas/maxReplicas。其目的是为了主动扩展业务，以处理突发的负载峰值。本文提供了一个示例，说明如何为跨集群部署 nginx deployment 启用CronFederatedHPA。 前提条件▍Karmada 已安装您可以参考快速入门安装 Karmada，或直接运行 hack/local-up-karmada.sh 脚本，该脚本也用于运行 E2E 测试。 在 member1 和 member2 集群中部署 Deployment我们需要在 member1 和 member2 集群中部署 Deployment（2 个副本）apiVersion: apps/v1kind: Deploymentmetadata: name: nginx labels: app: nginxspec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx resources: requests: cpu: 25m memory: 64Mi limits: cpu: 25m memory: 64Mi---apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata: name: nginx-propagationspec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinity: clusterNames: - member1 - member2 replicaScheduling: replicaDivisionPreference: Weighted replicaSchedulingType: Divided weightPreference: staticWeightList: - targetCluster: clusterNames: - member1 weight: 1 - targetCluster: clusterNames: - member2 weight: 1部署完成后，您可以检查已创建的 pods：$ karmadactl get podsNAME CLUSTER READY STATUS RESTARTS AGEnginx-777bc7b6d7-rmmzv member1 1/1 Running 0 104snginx-777bc7b6d7-9gf7g member2 1/1 Running 0 104s 在 Karmada 控制平面部署 CronFederatedHPA然后，在 Karmada 控制平面中部署 CronFederatedHPA，以扩容 Deployment：apiVersion: autoscaling.karmada.io/v1alpha1kind: CronFederatedHPAmetadata: name: nginx-cronfhpa namespace: defaultspec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx rules: - name: "scale-up" schedule: "*/1 * * * *" targetReplicas: 5 suspend: falsespec.schedule 遵循以下格式：# ┌───────────── minute (0 - 59)# │ ┌───────────── hour (0 - 23)# │ │ ┌───────────── day of the month (1 - 31)# │ │ │ ┌───────────── month (1 - 12)# │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday;# │ │ │ │ │ 7 is also Sunday on some systems)# │ │ │ │ │ OR sun, mon, tue, wed, thu, fri, sat# │ │ │ │ │# * * * * *表达式*/1 * * * *的意思是nginx deployment的副本应该每分钟更新为5个，确保了处理接下来的流量突发流量洪峰。 测试伸缩功能一分钟后，通过CronFederatedHPA将nginx部署的副本扩展到5个。现在让我们检查Pod的数量，以验证是否按预期进行了扩展：$ karmadactl get podsNAME CLUSTER READY STATUS RESTARTS AGEnginx-777bc7b6d7-8v9b4 member2 1/1 Running 0 18snginx-777bc7b6d7-9gf7g member2 1/1 Running 0 8m2snginx-777bc7b6d7-5snhz member1 1/1 Running 0 18snginx-777bc7b6d7-rmmzv member1 1/1 Running 0 8m2snginx-777bc7b6d7-z9kwg member1 1/1 Running 0 18s通过检查 CronFederatedHPA 的状态字段，您可以访问扩展历史记录：$ kubectl --kubeconfig $HOME/.kube/karmada.config --context karmada-apiserver get cronfhpa -oyaml-> # kubectl --kubeconfig $HOME/.kube/karmada.config --context karmada-apiserver get cronfhpa/nginx-cronfhpa -oyamlapiVersion: autoscaling.karmada.io/v1alpha1kind: CronFederatedHPAmetadata: name: nginx-cronfhpa namespace: defaultspec: rules: - failedHistoryLimit: 3 name: scale-up schedule: '*/1 * * * *' successfulHistoryLimit: 3 suspend: false targetReplicas: 5 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginxstatus: executionHistories: - nextExecutionTime: "2023-07-29T03:27:00Z" # 下一次执行时间 ruleName: scale-up successfulExecutions: - appliedReplicas: 5 # CronFederatedHPA将replicas更新为5 executionTime: "2023-07-29T03:26:00Z" # 上一次实际执行时间 scheduleTime: "2023-07-29T03:26:00Z" # 上一次期待执行时间伸缩历史包括成功和失败操作的信息。更多Karmada云原生多云容器引擎使用教程与技术交流，欢迎关注Karmada社区公众号或添加社区小助手k8s2222，回复Karmada进群。 Karmada 公众号 Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、滴滴、腾讯、中国电子云等60多家公司的全球贡献者，广泛分布于22个国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：cid:link_1Slack地址：https://slack.cncf.io/（#karmada）

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。本系列文章将介绍Karmada的使用教程，本文介绍如何通过 Karmada 完成集群平滑迁移及回滚。目标 假设用户安装了一个 Kubernetes 单集群，该集群已经部署了很多资源。用户希望通过 Karmada 将单集群扩展成多集群，并将已部署的资源从原集群迁移到 Karmada。在此背景下，本节将引导您完成：✅ 将应用从单集群迁移到 Karmada。✅ 回滚应用的迁移。前提条件 ▍Karmada 及多个子集群已安装1️⃣ 步骤一: 运行命令git clone cid:link_0cd karmadahack/local-up-karmada.shexport KUBECONFIG=~/.kube/karmada.config:~/.kube/members.config📄 说明：在开始之前，我们应该至少安装三个kubernetes集群，一个用于安装 Karmada 控制平面，另外两个作为成员集群。 为了方便，我们直接使用 hack/local-up-karmada.sh 脚本快速准备上述集群。执行上述命令后，您将看到Karmada控制面和多个成员集群已安装完成。 ▍在成员集群中预置资源为了模拟成员集群中已经存在现有资源，我们将简单的 Deployment 部署到 member1 集群。2️⃣ 步骤二: 编写代码创建新文件 /tmp/deployments.yaml 并写入以下文本：apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deployspec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 803️⃣ 步骤三: 运行命令$ kubectl --context member1 apply -f /tmp/deployments.yamldeployment.apps/nginx-deploy created$ karmadactl --karmada-context karmada-apiserver get deploy --operation-scope=allNAME CLUSTER READY UP-TO-DATE AVAILABLE AGE ADOPTIONnginx-deploy member1 2/2 2 2 15m N您将看到当前 nginx-deploy 部署在 member1 集群，ADOPTION=N 表示它此时不是由 Karmada 管理。指导 ▍将应用迁移到 Karmada为了使教程更简单易懂，假设应用仅由上述一个简单的 Deployment 构成。1️⃣ 步骤一: 运行命令$ kubectl --context karmada-apiserver apply -f /tmp/deployments.yamldeployment.apps/nginx-deploy created$ karmadactl --karmada-context karmada-apiserver get deploy --operation-scope=allNAME CLUSTER READY UP-TO-DATE AVAILABLE AGE ADOPTIONnginx-deploy Karmada 0/2 0 0 7s -nginx-deploy member1 2/2 2 2 16m N您将看到该 Deployment 被部署到 Karmada 控制面，作为 ResourceTemplate， 此时尚无匹配的 PropagationPolicy 对其分发。2️⃣ 步骤二: 编写代码创建新文件/tmp/pp-for-migrating-deployments.yaml 并写入以下文本：apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata: name: migrate-ppspec: conflictResolution: Overwrite placement: clusterAffinity: clusterNames: - member1 resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx-deploy 📄 说明：请注意以下两个字段：spec.conflictResolution: Overwrite：该字段的值必须是 Overwrite。spec.resourceSelectors：筛选要迁移的资源, 你可以自定义 ResourceSelector。3️⃣ 步骤三: 运行命令应用上述 PropagationPolicy 到 Karmada 控制面：$ kubectl --context karmada-apiserver apply -f /tmp/pp-for-migrating-deployments.yamlpropagationpolicy.policy.karmada.io/migrate-pp created4️⃣ 步骤四: 验证$ karmadactl --karmada-context karmada-apiserver get deploy --operation-scope=allNAME CLUSTER READY UP-TO-DATE AVAILABLE AGE ADOPTIONnginx-deploy Karmada 2/2 2 2 34s -nginx-deploy member1 2/2 2 2 16m Y$ karmadactl --karmada-context karmada-apiserver get pods --operation-scope=allNAME CLUSTER READY STATUS RESTARTS AGEnginx-deploy-54b9c68f67-4qjrz member1 1/1 Running 0 16mnginx-deploy-54b9c68f67-f4qpm member1 1/1 Running 0 16m您将看到所有 Deployment 已就绪，并且 member1 集群的 nginx-deploy 成功被 Karmada 接管：AGE=16m 说明该资源是被接管而不是重新创建，相应的 pods 不会发生重启。ADOPTION=Y 表示该资源现在由 Karmada 管理。至此，您已经完成了迁移。 ▍迁移回滚5️⃣ 步骤五: 对 PropagationPolicy 设置 preserveResourcesOnDeletion执行下述命令修改 PropagationPolicy/migrate-pp，设置 spec.preserveResourcesOnDeletion=true$ kubectl --context karmada-apiserver patch pp migrate-pp --type='json' -p '[{"op": "replace", "path": "/spec/preserveResourcesOnDeletion", "value": true}]'propagationpolicy.policy.karmada.io/nginx-pp patched6️⃣ 步骤六：从控制面删除资源模板执行下述命令：$ kubectl --context karmada-apiserver delete -f /tmp/deployments.yamldeployment.apps "nginx-deploy" deleted7️⃣ 步骤七：验证执行下述命令：$ karmadactl --karmada-context karmada-apiserver get deploy --operation-scope=allNAME CLUSTER READY UP-TO-DATE AVAILABLE AGE ADOPTIONnginx-deploy member1 2/2 2 2 17m N您将看到，控制面的资源模板已删除，并且成员集群中的资源依然可以保留，ADOPTION=N 表示该资源当前不是由 Karmada 管理。至此，您已经完成了迁移回滚。更多Karmada云原生多云容器引擎使用教程与技术交流，欢迎关注Karmada社区公众号或添加社区小助手k8s2222，回复Karmada进群。 Karmada 公众号 Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、滴滴、腾讯、中国电子云等60多家公司的全球贡献者，广泛分布于22个国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：cid:link_0Slack地址：https://slack.cncf.io/（#karmada）

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。本系列文章将介绍Karmada的使用教程，本文介绍如何使用 CronFederatedHPA 自动伸缩 FederatedHPA。在Karmada中，CronFederatedHPA用于伸缩工作负载的副本数（任何具有scale子资源的工作负载，如Deployment）或FederatedHPA的 minReplicas/maxReplicas，目的是提前伸缩业务以满足突发的负载峰值。CronFederatedHPA旨在在特定时间内扩展资源。当工作负载仅由CronFederatedHPA直接进行扩展时，在到达指定的时间为止，其副本将保持不变。这意味着直到指定时间之前，它失去了处理更多请求的能力。因此，为了确保工作负载可以提前扩容以满足后续高峰负载和后续实时业务需求，我们建议首先使用CronFederatedHPA来伸缩FederatedHPA。然后，FederatedHPA可以根据其度量标准来伸缩工作负载的规模。📝 本文档将为您提供一个示例，演示如何将 CronFederatedHPA 应用于 FederatedHPA。前提条件▍Karmada 已安装您可以参考 快速入门 安装 Karmada，或直接运行 hack/local-up-karmada.sh 脚本，该脚本也用于运行 E2E 测试。在 member1 和 member2 集群中部署 Deployment我们需要在 member1 和 member2 集群中部署 Deployment（2 个副本）：apiVersion: apps/v1kind: Deploymentmetadata: name: nginx labels: app: nginxspec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx resources: requests: cpu: 25m memory: 64Mi limits: cpu: 25m memory: 64Mi---apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata: name: nginx-propagationspec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinity: clusterNames: - member1 - member2 replicaScheduling: replicaDivisionPreference: Weighted replicaSchedulingType: Divided weightPreference: staticWeightList: - targetCluster: clusterNames: - member1 weight: 1 - targetCluster: clusterNames: - member2 weight: 1部署完成后，您可以检查已创建的 pods：$ karmadactl get podsNAME CLUSTER READY STATUS RESTARTS AGEnginx-777bc7b6d7-cmt6k member1 1/1 Running 0 27mnginx-777bc7b6d7-8lmcg member2 1/1 Running 0 27m在 Karmada 控制平面中部署 FederatedHPA让我们在Karmada控制平面中创建一个FederatedHPA，用来管理跨集群的nginx deployment：apiVersion: autoscaling.karmada.io/v1alpha1kind: FederatedHPAmetadata: name: nginx-fhpaspec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx minReplicas: 1 maxReplicas: 10 behavior: scaleDown: stabilizationWindowSeconds: 10 scaleUp: stabilizationWindowSeconds: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 80FederatedHPA会在平均CPU利用率超过80%时扩容工作负载的副本。相反，如果平均CPU利用率低于80%，则会缩容工作负载的副本数量。在 Karmada 控制平面中部署CronFederatedHPA为了自动伸缩FederatedHPA的minReplicas，让我们在Karmada控制平面中创建CronFederatedHPA：apiVersion: autoscaling.karmada.io/v1alpha1kind: CronFederatedHPAmetadata: name: nginx-cronfhpa namespace: defaultspec: scaleTargetRef: apiVersion: autoscaling.karmada.io/v1alpha1 kind: FederatedHPA name: nginx-fhpa rules: - name: "scale-up" schedule: "*/1 * * * *" targetMinReplicas: 5spec.schedule 遵循以下格式：# ┌───────────── minute (0 - 59)# │ ┌───────────── hour (0 - 23)# │ │ ┌───────────── day of the month (1 - 31)# │ │ │ ┌───────────── month (1 - 12)# │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday;# │ │ │ │ │ 7 is also Sunday on some systems)# │ │ │ │ │ OR sun, mon, tue, wed, thu, fri, sat# │ │ │ │ │# * * * * *表达式 */1 * * * * 表示每分钟将FederatedHPA的minReplicas更新为5。此操作能确保工作负载会被扩容到至少5个副本，以处理突发流量洪峰。测试扩容功能等待一分钟后，FederatedHPA的minReplicas会被CronFederatedHPA更新为5，此操作会触发 nginx deployment 的副本数被扩容为5。检查Pod的数量，看副本是否已扩容：$ karmadactl get poNAME CLUSTER READY STATUS RESTARTS AGEnginx-777bc7b6d7-7vl2r member1 1/1 Running 0 59snginx-777bc7b6d7-cmt6k member1 1/1 Running 0 27mnginx-777bc7b6d7-pc5dk member1 1/1 Running 0 59snginx-777bc7b6d7-8lmcg member2 1/1 Running 0 27mnginx-777bc7b6d7-pghl7 member2 1/1 Running 0 59s如果业务需求需要更多副本，FederatedHPA将根据指标（例如CPU利用率）自动伸缩副本数。通过检查CronFederatedHPA的状态字段，您可以查看伸缩历史记录：apiVersion: autoscaling.karmada.io/v1alpha1kind: CronFederatedHPAmetadata: name: nginx-cronfhpa namespace: defaultspec: rules: - failedHistoryLimit: 3 name: scale-up schedule: '*/1 * * * *' successfulHistoryLimit: 3 suspend: false targetMinReplicas: 5 scaleTargetRef: apiVersion: autoscaling.karmada.io/v1alpha1 kind: FederatedHPA name: nginx-fhpastatus: executionHistories: - nextExecutionTime: "2023-07-29T07:53:00Z" # 下一次执行时间 ruleName: scale-up successfulExecutions: - appliedMinReplicas: 5 # CronFederatedHPA将 minReplicas 更新为5 executionTime: "2023-07-29T07:52:00Z" # 上一次实际执行时间 scheduleTime: "2023-07-29T07:52:00Z" # 上一次期待执行时间伸缩历史包括成功和失败操作的信息。更多Karmada云原生多云容器引擎使用教程与技术交流，欢迎关注Karmada社区公众号或添加社区小助手k8s2222，回复Karmada进群。 Karmada 公众号 Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、滴滴、腾讯、中国电子云等60多家公司的全球贡献者，广泛分布于22个国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。 Karmada官网：https://karmada.io/项目地址：cid:link_1Slack地址：https://slack.cncf.io/（#karmada）

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。本系列文章将介绍Karmada的使用教程，本文介绍如何通过FederatedHPA 基于自定义指标扩缩容。在 Karmada 中，为了自动扩展工作负载以满足需求，FederatedHPA 会跨多个集群扩/缩容工作负载。FederatedHPA 不仅支持 CPU 和内存等资源指标，还支持自定义指标，这有助于扩展 FederatedHPA 的使用场景。本文档将引导您完成这样一个案例：启用 FederatedHPA 利用自定义指标来自动扩缩容跨集群应用。演示案例将执行以下操作：member1 集群中存在一个示例 Deployment 的 Pod。Service 部署在 member1 和 member2 集群。请求多集群 Service 并触发 Pod 的自定义指标（http_requests_total）增长。Pod 副本将在 member1 和 member2 集群中扩容。前提条件▍Karmada 已安装您可以参考快速入门安装 Karmada，或直接运行 hack/local-up-karmada.sh 脚本，该脚本也用于运行 E2E 测试。▍成员集群网络确保至少已有两个集群加入 Karmada，并且成员集群之间的容器网络已连通。如果您使用 hack/local-up-karmada.sh 脚本部署 Karmada，Karmada 中会有 3 个成员集群，并且集群 member1 和 member2 间的容器网络已连通。您可以使用 Submariner 或其他相关开源项目来连接成员集群之间的网络。注意：为了防止路由冲突，集群中 Pod 和 Service 的 CIDR 必须互不重叠。▍ServiceExport 和 ServiceImport 自定义资源已安装我们需要在成员集群中安装 ServiceExport 和 ServiceImport 以启用多集群 Service。在 Karmada 控制平面 上安装了 ServiceExport 和 ServiceImport 后，我们就可以创建 ClusterPropagationPolicy，将以下两个 CRD 分发到成员集群。# propagate ServiceExport CRDapiVersion: policy.karmada.io/v1alpha1kind: ClusterPropagationPolicymetadata: name: serviceexport-policyspec: resourceSelectors: - apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition name: serviceexports.multicluster.x-k8s.io placement: clusterAffinity: clusterNames: - member1 - member2--- # propagate ServiceImport CRDapiVersion: policy.karmada.io/v1alpha1kind: ClusterPropagationPolicymetadata: name: serviceimport-policyspec: resourceSelectors: - apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition name: serviceimports.multicluster.x-k8s.io placement: clusterAffinity: clusterNames: - member1 - member2▍成员集群中已安装 prometheus 和 prometheus-adapter我们需要为成员集群安装 prometheus 和 prometheus-adapter 以提供自定义 metrics API。 可以通过在成员集群中运行以下命令来安装：git clone https://github.com/prometheus-operator/kube-prometheus.gitcd kube-prometheuskubectl apply --server-side -f manifests/setupkubectl wait \ --for condition=Established \ --all CustomResourceDefinition \ --namespace=monitoringkubectl apply -f manifests/我们可以通过下面的命令验证安装：$ kubectl --kubeconfig=/root/.kube/members.config --context=member1 get po -nmonitoringNAME READY STATUS RESTARTS AGEalertmanager-main-0 2/2 Running 0 30halertmanager-main-1 2/2 Running 0 30halertmanager-main-2 2/2 Running 0 30hblackbox-exporter-6bc47b9578-zcbb7 3/3 Running 0 30hgrafana-6b68cd6b-vmw74 1/1 Running 0 30hkube-state-metrics-597db7f85d-2hpfs 3/3 Running 0 30hnode-exporter-q8hdx 2/2 Running 0 30hprometheus-adapter-57d9587488-86ckj 1/1 Running 0 29hprometheus-adapter-57d9587488-zrt29 1/1 Running 0 29hprometheus-k8s-0 2/2 Running 0 30hprometheus-k8s-1 2/2 Running 0 30hprometheus-operator-7d4b94944f-kkwkk 2/2 Running 0 30h▍Karmada 控制平面已安装 karmada-metrics-adapter我们需要在 Karmada 控制平面中安装 karmada-metrics-adapter 以提供 metrics API，通过运行以下命令来安装：hack/deploy-metrics-adapter.sh ${host_cluster_kubeconfig} ${host_cluster_context} ${karmada_apiserver_kubeconfig} ${karmada_apiserver_context_name}如果您使用 hack/local-up-karmada.sh 脚本部署 Karmada，将默认安装 karmada-metrics-adapter。在 member1 和 member2 集群中部署 Deployment我们需要在 member1 和 member2 集群中部署示例 Deployment（1 个副本）和 Service。 apiVersion: apps/v1kind: Deploymentmetadata: name: sample-app labels: app: sample-appspec: replicas: 1 selector: matchLabels: app: sample-app template: metadata: labels: app: sample-app spec: containers: - image: luxas/autoscale-demo:v0.1.2 name: metrics-provider ports: - name: http containerPort: 8080---apiVersion: v1kind: Servicemetadata: labels: app: sample-app name: sample-appspec: ports: - name: http port: 80 protocol: TCP targetPort: 8080 selector: app: sample-app type: ClusterIP---apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata: name: app-propagationspec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: sample-app - apiVersion: v1 kind: Service name: sample-app placement: clusterAffinity: clusterNames: - member1 - member2 replicaScheduling: replicaDivisionPreference: Weighted replicaSchedulingType: Divided weightPreference: staticWeightList: - targetCluster: clusterNames: - member1 weight: 1 - targetCluster: clusterNames: - member2 weight: 1部署完成后，您可以检查 Pod 和 Service 的分发情况：$ karmadactl get pods --operation-scope membersNAME CLUSTER READY STATUS RESTARTS AGEsample-app-9b7d8c9f5-xrnfx member1 1/1 Running 0 111s$ karmadactl get svc --operation-scope membersNAME CLUSTER TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ADOPTIONsample-app member1 ClusterIP 10.11.29.250 <none> 80/TCP 3m53s Y在 member1 和 member2 集群中监控您的应用为了监控您的应用，您需要配置一个指向该应用的 ServiceMonitor。假设您已配置 Prometheus 实例来使用带有 app:sample-app 标签的 ServiceMonitor，那么请创建一个 ServiceMonitor 以通过 Service 监控应用的指标：apiVersion: monitoring.coreos.com/v1kind: ServiceMonitormetadata: name: sample-app labels: app: sample-appspec: selector: matchLabels: app: sample-app endpoints: - port: httpkubectl create -f sample-app.monitor.yaml现在，您应该可以看到自定义指标 (http_requests_total) 出现在 Prometheus 实例中。通过仪表盘找到指标，并确保其含有 Namespace 和 Pod 标签。如果没有，请检查 ServiceMonitor 中的标签与 Prometheus CRD 中的标签是否匹配。在 member1 和 member2 集群中启动您的适配器部署了 prometheus-adapter 之后，为了暴露自定义指标，您需要更新适配器配置。apiVersion: v1kind: ConfigMapmetadata: name: adapter-config namespace: monitoringdata: config.yaml: |- "rules": - "seriesQuery": | {namespace!="",__name__!~"^container_.*"} "resources": "template": "<<.Resource>>" "name": "matches": "^(.*)_total" "as": "" "metricsQuery": | sum by (<<.GroupBy>>) ( irate ( <<.Series>>{<<.LabelMatchers>>}[1m] ) )kubectl apply -f prom-adapter.config.yaml# Restart prom-adapter podskubectl rollout restart deployment prometheus-adapter -n monitoring在 member1 和 member2 集群中注册 metrics API您还需要向 API 聚合器（主 Kubernetes API 服务器的一部分）注册自定义指标 API。为此，您需要创建一个 APIService 资源。apiVersion: apiregistration.k8s.io/v1kind: APIServicemetadata: name: v1beta2.custom.metrics.k8s.iospec: group: custom.metrics.k8s.io groupPriorityMinimum: 100 insecureSkipTLSVerify: true service: name: prometheus-adapter namespace: monitoring version: v1beta2 versionPriority: 100kubectl create -f api-service.yaml该 API 已注册为 custom.metrics.k8s.io/v1beta2，您可以使用以下命令进行验证：kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta2/namespaces/default/pods/*/http_requests?selector=app%3Dsample-app"输出结果类似于：{ "kind": "MetricValueList", "apiVersion": "custom.metrics.k8s.io/v1beta2", "metadata": {}, "items": [ { "describedObject": { "kind": "Pod", "namespace": "default", "name": "sample-app-9b7d8c9f5-9lw6b", "apiVersion": "/v1" }, "metric": { "name": "http_requests", "selector": null }, "timestamp": "2023-06-14T09:09:54Z", "value": "66m" } ]} 如果 karmada-metrics-adapter 安装成功，您也可以在 Karmada 控制平面中使用上述命令进行验证。在 Karmada 控制平面部署 FederatedHPA接下来让我们在 Karmada 控制平面中部署 FederatedHPA。apiVersion: autoscaling.karmada.io/v1alpha1kind: FederatedHPAmetadata: name: sample-appspec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: sample-app minReplicas: 1 maxReplicas: 10 behavior: scaleDown: stabilizationWindowSeconds: 10 scaleUp: stabilizationWindowSeconds: 10 metrics: - type: Pods pods: metric: name: http_requests target: averageValue: 700m type: Value部署完成后，您可以检查 FederatedHPA：NAME REFERENCE-KIND REFERENCE-NAME MINPODS MAXPODS REPLICAS AGEsample-app Deployment sample-app 1 10 1 15d将 Service 导出到 member1 集群正如前文所提到的，我们需要一个多集群 Service 来将请求转发到 member1 和 member2 集群中的 Pod，因此让我们创建这个多集群 Service。在 Karmada 控制平面创建一个 ServiceExport 对象，然后创建一个 PropagationPolicy 将 ServiceExport 对象分发到 member1 和 member2 集群。apiVersion: multicluster.x-k8s.io/v1alpha1kind: ServiceExportmetadata: name: sample-app---apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata: name: serve-export-policyspec: resourceSelectors: - apiVersion: multicluster.x-k8s.io/v1alpha1 kind: ServiceExport name: sample-app placement: clusterAffinity: clusterNames: - member1 - member2在 Karmada 控制平面创建一个 ServiceImport 对象，然后创建一个 PropagationPolicy 将 ServiceImport 对象分发到 member1 集群。apiVersion: multicluster.x-k8s.io/v1alpha1kind: ServiceImportmetadata: name: sample-appspec: type: ClusterSetIP ports: - port: 80 protocol: TCP---apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata: name: serve-import-policyspec: resourceSelectors: - apiVersion: multicluster.x-k8s.io/v1alpha1 kind: ServiceImport name: sample-app placement: clusterAffinity: clusterNames: - member1部署完成后，您可以检查多集群 Service：$ karmadactl get svc --operation-scope membersNAME CLUSTER TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ADOPTIONderived-sample-app member1 ClusterIP 10.11.59.213 <none> 80/TCP 9h Y在 member1 集群中安装 hey http 负载测试工具为了发送 http 请求，这里我们使用 hey。下载 hey 并复制到 kind 集群容器中。wget https://hey-release.s3.us-east-2.amazonaws.com/hey_linux_amd64chmod +x hey_linux_amd64docker cp hey_linux_amd64 member1-control-plane:/usr/local/bin/hey测试扩容首先检查 Pod 的分发情况。$ karmadactl get pods --operation-scope membersNAME CLUSTER READY STATUS RESTARTS AGEsample-app-9b7d8c9f5-xrnfx member1 1/1 Running 0 111s检查多集群 Service ip。$ karmadactl get svc --operation-scope membersNAME CLUSTER TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ADOPTIONderived-sample-app member1 ClusterIP 10.11.59.213 <none> 80/TCP 20m Y使用 hey 请求多集群 Service，以提高 nginx Pod 的自定义指标（http_requests_total）。docker exec member1-control-plane hey -c 1000 -z 1m http://10.11.59.213/metrics等待 15 秒，副本将扩容，然后您可以再次检查 Pod 分发状态。$ karmadactl get po --operation-scope members -l app=sample-appNAME CLUSTER READY STATUS RESTARTS AGEsample-app-9b7d8c9f5-454vz member2 1/1 Running 0 84ssample-app-9b7d8c9f5-7fjhn member2 1/1 Running 0 69ssample-app-9b7d8c9f5-ddf4s member2 1/1 Running 0 69ssample-app-9b7d8c9f5-mxqmh member2 1/1 Running 0 84ssample-app-9b7d8c9f5-qbc2j member2 1/1 Running 0 69ssample-app-9b7d8c9f5-2tgxt member1 1/1 Running 0 69ssample-app-9b7d8c9f5-66n9s member1 1/1 Running 0 69ssample-app-9b7d8c9f5-fbzps member1 1/1 Running 0 84ssample-app-9b7d8c9f5-ldmhz member1 1/1 Running 0 84ssample-app-9b7d8c9f5-xrnfx member1 1/1 Running 0 87m测试缩容1 分钟后，负载测试工具将停止运行，然后您可以看到工作负载在多个集群中缩容。$ karmadactl get pods --operation-scope members -l app=sample-appNAME CLUSTER READY STATUS RESTARTS AGEsample-app-9b7d8c9f5-xrnfx member1 1/1 Running 0 91m更多Karmada云原生多云容器引擎使用教程与技术交流，欢迎关注Karmada社区公众号或添加社区小助手k8s2222，回复Karmada进群。Karmada 公众号 Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、滴滴、腾讯、中国电子云等60多家公司的全球贡献者，广泛分布于22个国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：cid:link_0Slack地址：https://slack.cncf.io/（#karmada）

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。本系列文章将介绍Karmada的使用教程，本文介绍如何使用资源指标跨集群弹性扩缩容。在 Karmada 中，为了自动扩展工作负载以满足需求，FederatedHPA 会跨多个集群扩/缩容工作负载。当负载增加时，如果 Pod 数量低于配置的最大值，FederatedHPA 会扩容工作负载（Deployment、StatefulSet 或其他类似资源）的副本。当负载减少时，如果 Pod 数量高于配置的最小值，FederatedHPA 会缩容工作负载的副本。本文档将引导您完成这样 📝一个案例：启用 FederatedHPA 来自动扩缩容跨集群部署的 nginx。演示案例将执行以下操作： member1 集群中存在一个 Deployment 的 Pod。Service 部署在 member1 和 member2 集群。请求多集群 Service 来提高 Pod 的 CPU 使用率。Pod 副本将在 member1 和 member2 集群中扩容。前提条件▍Karmada 已安装您可以参考快速入门安装 Karmada，或直接运行 hack/local-up-karmada.sh 脚本，该脚本也用于运行 E2E 测试。▍成员集群网络确保至少已有两个集群加入 Karmada，并且成员集群之间的容器网络已连通。如果您使用 hack/local-up-karmada.sh 脚本部署 Karmada，Karmada 中会有 3 个成员集群，并且集群 member1 和 member2 间的容器网络已连通。您可以使用 Submariner 或其他相关开源项目来连接成员集群之间的网络。📌注意：为了防止路由冲突，集群中 Pod 和 Service 的 CIDR 必须互不重叠。▍ServiceExport 和 ServiceImport 自定义资源已安装我们需要在成员集群中安装 ServiceExport 和 ServiceImport 以启用多集群 Service。在 Karmada 控制平面 上安装了 ServiceExport 和 ServiceImport 后，我们就可以创建 ClusterPropagationPolicy，将以下两个 CRD 分发到成员集群。# propagate ServiceExport CRDapiVersion: policy.karmada.io/v1alpha1kind: ClusterPropagationPolicymetadata: name: serviceexport-policyspec: resourceSelectors: - apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition name: serviceexports.multicluster.x-k8s.io placement: clusterAffinity: clusterNames: - member1 - member2--- # propagate ServiceImport CRDapiVersion: policy.karmada.io/v1alpha1kind: ClusterPropagationPolicymetadata: name: serviceimport-policyspec: resourceSelectors: - apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition name: serviceimports.multicluster.x-k8s.io placement: clusterAffinity: clusterNames: - member1 - member2▍成员集群中已安装 metrics-server我们需要为成员集群安装 metrics-server 以提供 metrics API，通过运行以下命令来安装：hack/deploy-k8s-metrics-server.sh ${member_cluster_kubeconfig} ${member_cluster_context_name} 如果您使用 hack/local-up-karmada.sh 脚本部署 Karmada，则可以运行以下命令在三个成员集群中部署 metrics-server：hack/deploy-k8s-metrics-server.sh $HOME/.kube/members.config member1hack/deploy-k8s-metrics-server.sh $HOME/.kube/members.config member2hack/deploy-k8s-metrics-server.sh $HOME/.kube/members.config member3▍Karmada 控制平面已安装 karmada-metrics-adapter我们需要在 Karmada 控制平面中安装 karmada-metrics-adapter 以提供 metrics API，通过运行以下命令来安装：hack/deploy-metrics-adapter.sh ${host_cluster_kubeconfig} ${host_cluster_context} ${karmada_apiserver_kubeconfig} ${karmada_apiserver_context_name}如果您使用 hack/local-up-karmada.sh 脚本部署 Karmada，将默认安装 karmada-metrics-adapter。在 member1 和 member2 集群中部署 Deployment我们需要在 member1 和 member2 集群中部署 Deployment（1 个副本）和 Service。apiVersion: apps/v1kind: Deploymentmetadata: name: nginx labels: app: nginxspec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx resources: requests: cpu: 25m memory: 64Mi limits: cpu: 25m memory: 64Mi---apiVersion: v1kind: Servicemetadata: name: nginx-servicespec: ports: - port: 80 targetPort: 80 selector: app: nginx---apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata: name: nginx-propagationspec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx - apiVersion: v1 kind: Service name: nginx-service placement: clusterAffinity: clusterNames: - member1 - member2 replicaScheduling: replicaDivisionPreference: Weighted replicaSchedulingType: Divided weightPreference: staticWeightList: - targetCluster: clusterNames: - member1 weight: 1 - targetCluster: clusterNames: - member2 weight: 1部署完成后，您可以检查 Pod 和 Service 的分发情况：$ karmadactl get pods --operation-scope membersNAME CLUSTER READY STATUS RESTARTS AGEnginx-777bc7b6d7-mbdn8 member1 1/1 Running 0 9h$ karmadactl get svc --operation-scope membersNAME CLUSTER TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ADOPTIONnginx-service member1 ClusterIP 10.11.216.215 <none> 80/TCP 9h Ynginx-service member2 ClusterIP 10.13.46.61 <none> 80/TCP 9h Y在 Karmada 控制平面部署 FederatedHPA接下来让我们在 Karmada 控制平面中部署 FederatedHPA。apiVersion: autoscaling.karmada.io/v1alpha1kind: FederatedHPAmetadata: name: nginxspec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx minReplicas: 1 maxReplicas: 10 behavior: scaleDown: stabilizationWindowSeconds: 10 scaleUp: stabilizationWindowSeconds: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 10部署完成后，您可以检查 FederatedHPA：$ kubectl --kubeconfig $HOME/.kube/karmada.config --context karmada-apiserver get fhpaNAME REFERENCE-KIND REFERENCE-NAME MINPODS MAXPODS REPLICAS AGEnginx Deployment nginx 1 10 1 9h将 Service 导出到 member1 集群正如前文所提到的，我们需要一个多集群 Service 来将请求转发到 member1 和 member2 集群中的 Pod，因此让我们创建这个多集群 Service。在 Karmada 控制平面创建一个 ServiceExport 对象，然后创建一个 PropagationPolicy 将 ServiceExport 对象分发到 member1 和 member2 集群。apiVersion: multicluster.x-k8s.io/v1alpha1kind: ServiceExportmetadata: name: nginx-service---apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata: name: serve-export-policyspec: resourceSelectors: - apiVersion: multicluster.x-k8s.io/v1alpha1 kind: ServiceExport name: nginx-service placement: clusterAffinity: clusterNames: - member1 - member2在 Karmada 控制平面创建一个 ServiceImport 对象，然后创建一个 PropagationPolicy 将 ServiceImport 对象分发到 member1 集群。apiVersion: multicluster.x-k8s.io/v1alpha1kind: ServiceImportmetadata: name: nginx-servicespec: type: ClusterSetIP ports: - port: 80 protocol: TCP---apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata: name: serve-import-policyspec: resourceSelectors: - apiVersion: multicluster.x-k8s.io/v1alpha1 kind: ServiceImport name: nginx-service placement: clusterAffinity: clusterNames: - member1部署完成后，您可以检查多集群 Service：$ karmadactl get svc --operation-scope membersNAME CLUSTER TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ADOPTIONderived-nginx-service member1 ClusterIP 10.11.59.213 <none> 80/TCP 9h Y在 member1 集群中安装 hey http 负载测试工具为了发送 http 请求，这里我们使用 hey。下载 hey 并复制到 kind 集群容器中。wget https://hey-release.s3.us-east-2.amazonaws.com/hey_linux_amd64chmod +x hey_linux_amd64docker cp hey_linux_amd64 member1-control-plane:/usr/local/bin/hey测试扩容首先检查 Pod 的分发情况。$ karmadactl get pods --operation-scope membersNAME CLUSTER READY STATUS RESTARTS AGEnginx-777bc7b6d7-mbdn8 member1 1/1 Running 0 61m检查多集群 Service ip。$ karmadactl get svc --operation-scope membersNAME CLUSTER TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ADOPTIONderived-nginx-service member1 ClusterIP 10.11.59.213 <none> 80/TCP 20m Y使用 hey 请求多集群 Service，以提高 nginx Pod 的 CPU 使用率。docker exec member1-control-plane hey -c 1000 -z 1m http://10.11.59.213等待 15 秒，副本将扩容，然后您可以再次检查 Pod 分发状态。$ karmadactl get pods --operation-scope members -l app=nginxNAME CLUSTER READY STATUS RESTARTS AGEnginx-777bc7b6d7-c2cfv member1 1/1 Running 0 22snginx-777bc7b6d7-mbdn8 member1 1/1 Running 0 62mnginx-777bc7b6d7-pk2s4 member1 1/1 Running 0 37snginx-777bc7b6d7-tbb4k member1 1/1 Running 0 37snginx-777bc7b6d7-znlj9 member1 1/1 Running 0 22snginx-777bc7b6d7-6n7d9 member2 1/1 Running 0 22snginx-777bc7b6d7-dfbnw member2 1/1 Running 0 22snginx-777bc7b6d7-fsdg2 member2 1/1 Running 0 37snginx-777bc7b6d7-kddhn member2 1/1 Running 0 22snginx-777bc7b6d7-lwn52 member2 1/1 Running 0 37s测试缩容1 分钟后，负载测试工具将停止运行，然后您可以看到工作负载在多个集群中缩容。$ karmadactl get pods --operation-scope members -l app=nginxNAME CLUSTER READY STATUS RESTARTS AGEnginx-777bc7b6d7-mbdn8 member1 1/1 Running 0 64m更多Karmada云原生多云容器引擎使用教程与技术交流，欢迎关注Karmada社区公众号或添加社区小助手k8s2222，回复Karmada进群。 Karmada 公众号 Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、滴滴、腾讯、中国电子云等60多家公司的全球贡献者，广泛分布于22个国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：cid:link_1Slack地址：https://slack.cncf.io/（#karmada） 

 Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。本系列文章将介绍Karmada的使用教程，本文介绍如何通过使用 Karmada-search 来体验多集群检索。本指南将涵盖以下内容：✅ 在 Karmada 控制面上安装 karmada-search 组件✅ 缓存多个集群的 Deployment 资源。✅ 使用 OpenSearch 图形界面检索 Kubernetes 资源。前提条件在安装 karmada-search 之前，您必须先安装 Karmada 控制平面。要启动 Karmada，您可以参考安装概述（https://karmada.io/zh/docs/installation/）。如果您只是想尝试 Karmada，我们建议使用 hack/local-up-karmada.sh 构建开发环境。git clone cid:link_1cd karmadahack/local-up-karmada.sh安装 karmada-search如果您使用 hack/local-up-karmada.sh，那 karmada-search 已经安装好了。如果您通过 Helm 安装 Karmada，可以选择以下任意一种方式进行安装：在 host 模式下安装 karmada-searchhelm upgrade --install karmada -n karmada-system --create-namespace --dependency-update \ --cleanup-on-fail ./charts/karmada \ --set components={"search"}在 component 模式下单独安装 karmada-search为 karmada-search 编辑 values.yaml 文件：installMode: "component"components: [ "search"]...执行下述命令：kubectl config use-context hosthelm install karmada -n karmada-system ./charts/karmada如果您通过 Karmada Operator 安装 Karmada，可以在安装 Karmada 组件时，执行下述命令：kubectl create namespace testkubectl apply -f - <<EOFapiVersion: operator.karmada.io/v1alpha1kind: Karmadametadata: name: karmada-demo namespace: testspec: components: karmadaSearch: {}EOF此外，karmadactl 支持一键安装 karmada-search。karmadactl addons enable karmada-searchkarmadactl addons enable karmada-search有关更多详细信息，您可以参考 karmadactl addons instruction（https://karmada.io/zh/docs/reference/karmadactl/karmadactl-commands/karmadactl_addons）。缓存多个集群的 Deployment 资源在接下来的步骤中，我们将在缓存成员集群的 Deployment 资源。根据示例，我们已经将一个 nginx Deployment 分发到了 member1 和 member2。1️⃣ 创建一个 ResourceRegistry，它将缓存目标集群中的 Deployment 资源。### deployment-search.yamlapiVersion: search.karmada.io/v1alpha1kind: ResourceRegistrymetadata: name: deployment-searchspec: targetCluster: clusterNames: - member1 - member2 resourceSelectors: - apiVersion: apps/v1 kind: Deploymentkubectl --kubeconfig $HOME/.kube/karmada.config --context karmada-apiserver create -f deployment-search.yaml2️⃣ 通过 Kubernetes API 进行测试您可以通过以下命令从 member1 和 member2 获取 deployment 资源。kubectl --kubeconfig $HOME/.kube/karmada.config --context karmada-apiserver get --raw /apis/search.karmada.io/v1alpha1/search/cache/apis/apps/v1/deployments输出类似于（忽略不相关的字段）：{ "kind": "List", "apiVersion": "apps/v1", "metadata": {}, "items": [{ "apiVersion": "apps/v1", "kind": "Deployment", "metadata": { "annotations": { "deployment.kubernetes.io/revision": "1", "kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"apps/v1\",\"kind\":\"Deployment\",\"metadata\":{\"annotations\":{},\"labels\":{\"app\":\"nginx\"},\"name\":\"nginx\",\"namespace\":\"default\"},\"spec\":{\"replicas\":2,\"selector\":{\"matchLabels\":{\"app\":\"nginx\"}},\"template\":{\"metadata\":{\"labels\":{\"app\":\"nginx\"}},\"spec\":{\"containers\":[{\"image\":\"nginx\",\"name\":\"nginx\"}]}}}}\n", "resource.karmada.io/cached-from-cluster": "member1", "resourcebinding.karmada.io/name": "nginx-deployment", "resourcebinding.karmada.io/namespace": "default", "resourcetemplate.karmada.io/uid": "b46d2736-78d8-47db-b589-6e819139ba33" }, "creationTimestamp": "2022-11-18T08:34:28Z", "generation": 1, "labels": { "app": "nginx", "propagationpolicy.karmada.io/name": "nginx-propagation", "propagationpolicy.karmada.io/namespace": "default", "resourcebinding.karmada.io/key": "687f7fb96f", "work.karmada.io/name": "nginx-687f7fb96f", "work.karmada.io/namespace": "karmada-es-member1" } } }, { "apiVersion": "apps/v1", "kind": "Deployment", "metadata": { "annotations": { "deployment.kubernetes.io/revision": "1", "kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"apps/v1\",\"kind\":\"Deployment\",\"metadata\":{\"annotations\":{},\"labels\":{\"app\":\"nginx\"},\"name\":\"nginx\",\"namespace\":\"default\"},\"spec\":{\"replicas\":2,\"selector\":{\"matchLabels\":{\"app\":\"nginx\"}},\"template\":{\"metadata\":{\"labels\":{\"app\":\"nginx\"}},\"spec\":{\"containers\":[{\"image\":\"nginx\",\"name\":\"nginx\"}]}}}}\n", "resource.karmada.io/cached-from-cluster": "member2", "resourcebinding.karmada.io/name": "nginx-deployment", "resourcebinding.karmada.io/namespace": "default", "resourcetemplate.karmada.io/uid": "e785db97-4d17-4871-99be-6d629c556b89" }, "creationTimestamp": "2022-11-21T02:23:26Z", "generation": 1, "labels": { "app": "nginx", "propagationpolicy.karmada.io/name": "nginx-propagation", "propagationpolicy.karmada.io/namespace": "default", "resourcebinding.karmada.io/key": "687f7fb96f", "work.karmada.io/name": "nginx-687f7fb96f", "work.karmada.io/namespace": "karmada-es-member2" } } }]} 使用 OpenSearch 图形界面检索 Kubernetes 资源karmada-search 还支持将缓存资源同步到独立存储服务，如 Elasticsearch 或 OpenSearch。通过利用搜索引擎，您可以按字段和索引执行具有所有所需功能的全文搜索；根据分数对结果进行排名、按字段对结果进行排序，并聚合结果。以下是使用 OpenSearch 以图形界面检索 Kubernetes 资源的示例。1️⃣ 部署 OpenSearch 和 OpenSearch 仪表盘使用以下脚本部署 OpenSearch 和 OpenSearch 仪表盘。./hack/deploy-karmada-opensearch.sh $HOME/.kube/karmada.config karmada-host验证安装结果：kubectl --kubeconfig $HOME/.kube/karmada.config --context karmada-host get po -A输出类似于：NAMESPACE NAME READY STATUS RESTARTS AGEkarmada-system karmada-opensearch-77454fbcf5-7rpvz 1/1 Running 0 155mkarmada-system karmada-opensearch-dashboards-596bf4d9dd-n9429 1/1 Running 0 156m...2️⃣ 更新 ResourceRegistry 与 backendStore### deployment-search.yamlapiVersion: search.karmada.io/v1alpha1kind: ResourceRegistrymetadata: name: deployment-searchspec: backendStore: openSearch: addresses: - http://karmada-opensearch.karmada-system.svc:9200 targetCluster: clusterNames: - member1 - member2 resourceSelectors: - apiVersion: apps/v1 kind: Deploymentkubectl --kubeconfig $HOME/.kube/karmada.config --context karmada-apiserver apply -f deployment-search.yaml3️⃣ 暴露仪表板的服务您需要将 Web 服务暴露到主机端口，以便可以通过 HTTP 访问仪表板。kubectl --kubeconfig $HOME/.kube/karmada.config --context karmada-host port-forward svc/karmada-opensearch-dashboards 5601:5601 -nkarmada-system --address=0.0.0.04️⃣ 访问仪表盘访问 OpenSearch 仪表板（http://NodeIP:5601）：现在 Deployment 的数据已经上传到 OpenSearch 中的 member1 和 member2。您可以利用搜索引擎自己体验多集群检索。更多Karmada云原生多云容器引擎使用教程与技术交流，欢迎关注Karmada社区公众号或添加社区小助手k8s2222，回复Karmada进群。 Karmada 公众号 Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、滴滴、腾讯、中国电子云等60多家公司的全球贡献者，广泛分布于22个国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：cid:link_1Slack地址：https://slack.cncf.io/（#karmada）

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。本系列文章将介绍Karmada的使用教程，本文介绍如何通过 Karmada 分发 CRD。在本节中，我们将引导您完成以下内容：✅ 安装 Karmada 控制平面。✅ 将 CRD 分发到多个集群。✅ 在特定集群中自定义 CRD。启动 Karmada 集群想要启动 Karmada，您可以参考安装概述。如果您只想尝试 Karmada，请使用 hack/local-up-karmada.sh 构建开发环境。git clone cid:link_0cd karmadahack/local-up-karmada.sh分发 CRD下面的步骤指导您如何分发 CRD Guestbook。假设您在 Karmada 仓库的 guestbook 目录下。cd samples/guestbook使用 Karmada 配置设置 KUBECONFIG 环境变量。export KUBECONFIG=${HOME}/.kube/karmada.config1️⃣ 在 Karmada 的控制平面上创建 Guestbook CRDkubectl apply -f guestbooks-crd.yaml 此 CRD 应该被应用到 karmada-apiserver。2️⃣ 创建 ClusterPropagationPolicy，将 Guestbook CRD 分发到 member1kubectl apply -f guestbooks-clusterpropagationpolicy.yaml # guestbooks-clusterpropagationpolicy.yamlapiVersion: policy.karmada.io/v1alpha1kind: ClusterPropagationPolicymetadata: name: example-policyspec: resourceSelectors: - apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition name: guestbooks.webapp.my.domain placement: clusterAffinity: clusterNames: - member1根据 ClusterPropagationPolicy 中定义的规则，此 CRD 将分发到成员集群。📌 注意：在这里我们只能使用 ClusterPropagationPolicy 而不是 PropagationPolicy。 更多详细信息，请参考 FAQ PropagationPolicy and ClusterPropagationPolicy3️⃣ 在 Karmada 控制平面上创建名为 guestbook-sample 的 Guestbook CRkubectl apply -f guestbook.yaml4️⃣ 创建 PropagationPolicy，将 guestbook-sample 分发到 member1kubectl apply -f guestbooks-propagationpolicy.yaml# guestbooks-propagationpolicy.yamlapiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata: name: example-policyspec: resourceSelectors: - apiVersion: webapp.my.domain/v1 kind: Guestbook placement: clusterAffinity: clusterNames: - member15️⃣ 检查 Karmada 中 guestbook-sample 的状态kubectl get guestbook -oyaml输出类似于以下内容：apiVersion: webapp.my.domain/v1kind: Guestbookmetadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"webapp.my.domain/v1","kind":"Guestbook","metadata":{"annotations":{},"name":"guestbook-sample","namespace":"default"},"spec":{"alias":"Name","configMapName":"test","size":2}} creationTimestamp: "2022-11-18T06:56:24Z" generation: 1 labels: propagationpolicy.karmada.io/name: example-policy propagationpolicy.karmada.io/namespace: default name: guestbook-sample namespace: default resourceVersion: "682895" uid: 2f8eda5f-35ab-4ac3-bcd4-affcf36a9341spec: alias: Name configMapName: test size: 2自定义 CRD1️⃣ 创建 OverridePolicy，将覆盖 member1 中 guestbook-sample 的 size 字段。kubectl apply -f guestbooks-overridepolicy.yaml# guestbooks-overridepolicy.yamlapiVersion: policy.karmada.io/v1alpha1kind: OverridePolicymetadata: name: guestbook-samplespec: resourceSelectors: - apiVersion: webapp.my.domain/v1 kind: Guestbook overrideRules: - targetCluster: clusterNames: - member1 overriders: plaintext: - path: /spec/size operator: replace value: 4 - path: /metadata/annotations operator: add value: {"OverridePolicy":"test"}2️⃣ 检查来自成员集群的 guestbook-sample 的 size 字段kubectl --kubeconfig=${HOME}/.kube/members.config config use-context member1kubectl --kubeconfig=${HOME}/.kube/members.config get guestbooks -o yaml如果按预期工作，则 .spec.size 将被覆盖为 4 :apiVersion: webapp.my.domain/v1kind: Guestbookmetadata:annotations:OverridePolicy: testkubectl.kubernetes.io/last-applied-configuration: |{"apiVersion":"webapp.my.domain/v1","kind":"Guestbook","metadata":{"annotations":{},"name":"guestbook-sample","namespace":"default"},"spec":{"alias":"Name","configMapName":"test","size":2}}resourcebinding.karmada.io/name: guestbook-sample-guestbookresourcebinding.karmada.io/namespace: defaultresourcetemplate.karmada.io/uid: 2f8eda5f-35ab-4ac3-bcd4-affcf36a9341creationTimestamp: "2022-11-18T06:56:37Z"generation: 2labels:propagationpolicy.karmada.io/name: example-policypropagationpolicy.karmada.io/namespace: defaultresourcebinding.karmada.io/key: 6849fdbd59work.karmada.io/name: guestbook-sample-6849fdbd59work.karmada.io/namespace: karmada-es-member1name: guestbook-samplenamespace: defaultresourceVersion: "430024"uid: 8818e33d-10bf-4270-b3b9-585977425bc9spec:alias: NameconfigMapName: testsize: 4 更多Karmada云原生多云容器引擎使用教程与技术交流，欢迎关注Karmada社区公众号或添加社区小助手k8s2222，回复Karmada进群。 Karmada 公众号  Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、滴滴、腾讯、中国电子云等60多家公司的全球贡献者，广泛分布于22个国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：cid:link_0Slack地址：https://slack.cncf.io/（#karmada）

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。本系列文章将介绍Karmada的使用教程，本文介绍如何通过 Karmada 分发 Deployment。本指南涵盖了：在名为 host cluster 的 Kubernetes 集群中安装 karmada 控制面组件。将一个成员集群接入到 karmada 控制面。通过使用 karmada 分发应用程序。前提条件Go v1.18+kubectl v1.19+kind v0.14.0+安装 Karmada 控制面1. 克隆此代码仓库到你的机器git clone cid:link_12. 更改到 karmada 目录cd karmada3. 部署并运行 Karmada 控制面运行以下脚本：hack/local-up-karmada.sh该脚本将为你执行以下任务：启动一个 Kubernetes 集群来运行 Karmada 控制面，即 host cluster。根据当前代码库构建 Karmada 控制面组件。在 host cluster 上部署 Karmada 控制面组件。创建成员集群并接入 Karmada。如果一切良好，在脚本输出结束时你将看到以下类似消息：Local Karmada is running.To start using your Karmada environment, run: export KUBECONFIG="$HOME/.kube/karmada.config"Please use 'kubectl config use-context karmada-host/karmada-apiserver' to switch the host and control plane cluster.To manage your member clusters, run: export KUBECONFIG="$HOME/.kube/members.config"Please use 'kubectl config use-context member1/member2/member3' to switch to the different member cluster.Karmada 中有两个上下文环境：karmada-apiserver kubectl config use-context karmada-apiserverkarmada-host kubectl config use-context karmada-hostkarmada-apiserver 是与 Karmada 控制面交互时要使用的 主要 kubeconfig， 而 karmada-host 仅用于调试 Karmada 对 host cluster 的安装。 你可以通过运行 kubectl config view 随时查看所有集群。 要切换集群上下文，请运行 kubectl config use-context [CONTEXT_NAME]Demo 分发应用程序在以下步骤中，我们将通过 Karmada 分发一个 Deployment。1. 在 Karmada 中创建 nginx deployment首先创建名为 nginx 的 deployment：kubectl create -f samples/nginx/deployment.yaml2. 创建将 nginx 分发到成员集群的 PropagationPolicy随后我们需要创建一个策略将 Deployment 分发到成员集群。kubectl create -f samples/nginx/propagationpolicy.yaml3. 从 Karmada 查看 Deployment 状态你可以从 Karmada 查看 Deployment 状态，无需访问成员集群：$ kubectl get deploymentNAME    READY   UP-TO-DATE   AVAILABLE   AGEnginx   2/2     2            2           20s 更多Karmada云原生多云容器引擎使用教程与技术交流，欢迎关注Karmada社区公众号或添加社区小助手k8s2222，回复Karmada进群。Karmada 公众号 Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、滴滴、腾讯、中国电子云等60多家公司的全球贡献者，广泛分布于22个国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：cid:link_1Slack地址：https://slack.cncf.io/（#karmada）

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。Karmada v1.16[1] 版本现已发布，本版本包含下列新增特性：支持多模板工作负载调度使用 Webster 算法增强副本分配驱逐队列速率限制持续的性能优化这些特性使 Karmada 在处理大规模、复杂的多集群场景时更加成熟和可靠。我们鼓励您升级到 v1.16.0，体验这些新功能带来的价值。  新特性概览  ▍支持多模板工作负载调度当前许多AI/大数据应用由多个组件构成，这些组件之间相互协作以完成复杂的计算任务。例如：FlinkDeployment 包含 JobManager 和 TaskManager；SparkApplication 包含 Driver 和 Executor；RayCluster 包含 Head 和 Worker 节点。在 Karmada v1.16.0 中，我们引入了多模板调度，这是一项全新的能力，使得 Karmada 能够将由多个相互关联组件组成的多模版工作负载完整且统一地调度到具有充足资源的单个成员集群中。此功能建立在 v1.15 版本引入的多模板工作负载资源精确感知[2]功能之上，该支持使 Karmada 能够准确理解复杂工作负载的资源拓扑。在 v1.16 中，调度器利用这些信息来：基于 ResourceQuota 限制来估算成员集群可以容纳的完整的多模板工作负载数；利用成员集群中实际节点的可用资源来预测工作负载的可调度性。当前版本为以下多模板工作负载类型提供了内置的资源解释器：FlinkDeployment (flink.apache.org\v1beta1)SparkApplication (sparkoperator.k8s.io\v1beta2)Job (batch.volcano.sh\v1alpha1)MPIJob (kubeflow.org\v2beta1)RayCluster (ray.io/v1)RayJob (ray.io/v1)TFJob (kubeflow.org\v1)PyTorchJob (kubeflow.org\v1)如果您使用的是其他的自定义多模板工作负载，也可以通过扩展 Karmada 的资源解释器来支持它们。让我们举个简单的例子，假设您有一个 FlinkDeployment，其资源配置如下：apiVersion: flink.apache.org/v1beta1 kind: FlinkDeployment metadata:   name: flink-example spec:   jobManager:     replicas: 1     resource:       cpu: 1       memory: "1024m"   taskManager:     replicas: 2     resource:       cpu: 2       memory: "2048m启用多模板调度功能后，Karmada 会：通过资源解释器准确解析出 JobManager 和 TaskManager 的资源需求；评估每个成员集群是否有足够资源容纳完整的 FlinkDeployment（1 个 JobManager + 2 个 TaskManager）；将整个 FlinkDeployment 调度到单个满足条件的集群。此功能的发布标志着 Karmada 在支持AI/大数据应用方面迈出了重要一步——将精准的资源解释、配额感知计算和跨集群调度融合在一个统一的框架中。▍使用 Webster 算法增强副本分配Karmada 支持多种副本调度策略，如 DynamicWeight、Aggregated 和 StaticWeight，用于在成员集群之间分配工作负载的副本。这些策略的核心在于将集群权重转化为实际副本数量的算法。在之前的版本中，副本分配算法存在一定的局限性：非单调性：当总副本数增加时，某些集群可能意外地获得更少的副本；缺乏强幂等性：相同的输入可能产生不同的输出；不公平的余数分配：在具有相同权重的集群之间分配剩余副本时缺乏合理的优先级策略。在当前版本中，我们引入了 Webster 方法（也称为 Sainte-Laguë 方法）来改进跨集群调度期间的副本分配。通过采用 Webster 算法，Karmada 现在实现了：单调副本分配：增加总副本数绝不会导致任何集群丢失副本，确保行为一致且直观。剩余副本的公平处理：在权重相等的集群间分配副本时，优先考虑当前副本数较少的集群。这种“小优先”方式有助于促进均衡部署，更好地满足高可用性（HA）需求。此次更新增强了跨集群工作负载分配的稳定性、公平性和可预测性，使多集群环境中的副本调度更加稳健。▍驱逐队列速率限制在多集群环境中，当集群发生故障时，资源需要从故障集群中驱逐并重新调度到健康的集群。如果多个集群同时或在短时间内相继发生故障，大量的驱逐和重新调度操作可能会使健康集群和控制平面不堪重负，进而导致级联故障。此版本引入了具有速率限制功能的驱逐队列，用于 Karmada 污点管理器。驱逐队列通过可配置的固定速率参数来控制资源驱逐速率，从而增强故障迁移机制。该实现还提供了用于监控驱逐过程的指标，提高了整体系统的可观测性。这个特性在以下场景特别有用：您需要在大规模故障期间防止级联故障，确保系统不会因为过多的驱逐操作而不堪重负。您希望根据不同环境的特性配置驱逐行为。例如，在生产环境中使用较低的驱逐速率，在开发或测试环境中使用较高的速率。您需要监控驱逐队列的性能，包括待处理驱逐的数量、处理延迟以及成功/失败率，以便调整配置和响应运维问题。驱逐队列的核心特性包括：可配置的固定速率限制：通过 --eviction-rate 命令行参数配置每秒驱逐速率。示例：设置每 2 秒最多驱逐 1 个资源：--eviction-rate=0.5。完善的指标支持：提供队列深度、资源类型、处理延迟、成功/失败率等指标，便于监控和故障排查。通过引入速率限制机制，管理员可以更好地控制集群故障迁移期间的资源调度速率，在保障服务稳定性的同时，提升资源调度的灵活性和效率。有关此功能的详细使用方法，请参阅用户指南：配置驱逐速率限制[3]。▍持续的性能优化在此版本中，性能优化团队继续增强 Karmada 的性能，对控制器进行了重大改进。在 release-1.15 中，我们引入了 controller-runtime 优先级队列[4]，它允许基于 controller-runtime 构建的控制器在重启或主从切换后优先处理最新的变更，从而显著减少服务重启和故障转移期间的停机时间。在 release-1.16 中，我们扩展了这一能力。对于不是基于 controller-runtime 构建的控制器（如 detector controller），我们通过为所有使用异步 worker 的控制器启用优先级队列功能，使它们也能享受到这一优化。测试环境包括 5,000 个 Deployments 及其 PropagationPolicy，并在 karmada-controller-manager 组件中启用了 ControllerPriorityQueue 特性开关。在 karmada-controller-manager 组件重启后、工作队列中仍有大量待处理事件的情况下，手动修改一个 Deployment，其更新事件仍能被控制器快速处理并被同步到成员集群。这些测试结果证明，Karmada 控制器的性能在 v1.16 中得到了很大的提升。未来，我们将继续对控制器和调度器进行系统性的性能优化。有关详细的进展和测试报告，请参阅 PR：[Performance] enable asyncPriorityWorker in all controllers[5]。  致谢贡献者  Karmada v1.16 版本包含了来自 30 位贡献者的 263 次代码提交，在此对各位贡献者表示由衷的感谢：贡献者列表：   相关链接[1] Karmada v1.16: cid:link_0[2] 多模板工作负载资源精确感知: https://karmada.io/blog/2025/09/05/karmada-v1.15/karmada-v1.15#precise-resource-awareness-for-multi-template-workloads[3] 用户指南: 配置驱逐速率限制: https://karmada.io/docs/next/userguide/failover/cluster-failover/#configuring-eviction-rate-limiting[4] controller-runtime 优先级队列: cid:link_1[5] [Performance] enable asyncPriorityWorker in all controllers: cid:link_2 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支持多种资源与任务调度策略，有助于提升应用性能和集群整体资源利用率，CPU资源调度、GPU/NPU异构资源调度以及Volcano调度的主要功能。本系列文章将介绍Volcano调度在华为云云容器引擎CCE中的运用。Volcano是一个基于Kubernetes的批处理平台，提供了机器学习、深度学习、生物信息学、基因组学及其他大数据应用所需要而Kubernetes当前缺失的一系列特性，提供了高性能任务调度引擎、高性能异构芯片管理、高性能任务运行管理等通用计算能力。在华为云云容器引擎CCE使用Volcano的调度中，在替换节点池、节点滚动升级等场景，需要使用新节点池替换旧节点池。在这些场景下，为做到业务不感知，可以在业务触发变更时，将业务的Pod软亲和调度到新的节点池上。这种软亲和调度会尽量将新创建的Pod或者重调度的Pod调度到新的节点池，如果新节点池资源不足，或者新节点池无法调度，也要能将Pod调度到旧节点池上。节点池替换、节点滚动升级等场景中，业务不需要也不应该感知，所以不会在业务负载中声明节点亲和配置，而需要在集群调度层面，使用软亲和方式，在业务变更时将Pod尽量调度到新的节点池上。Volcano的目标是在业务负载未配置节点软亲和时，在调度层将业务的Pod软调度到指定节点上。  调度优先级介绍  节点池软亲和调度，是通过节点池上的标签（Label）进行软亲和，具体是通过给每一个节点进行打分的机制来排序筛选最优节点。📝 原则：尽可能把Pod调度到带有相关标签的节点上。🔍 打分公式如下：score = weight * MaxNodeScore * haveLabel参数说明：weight：节点池软亲和plugin的权重。MaxNodeScore：节点最大得分，值为100。haveLabel：节点上是否存在插件中配置的label，如果有，值为1，如果节点上没有，值为0。  前提条件  ✅ 已创建v1.19.16及以上版本的集群，具体操作请参见购买Standard/Turbo集群。✅ 集群中已安装1.11.5及以上版本的Volcano插件，具体操作请参见Volcano调度器。  配置Volcano节点池软亲和调度策略  1、在节点池上配置用于亲和调度的标签。登录CCE控制台，单击集群名称进入集群。在左侧选择“节点管理”，在右侧选择“节点池”页签。单击节点池名称后的“更新”，在弹出的“更新节点池”页面中配置参数，在“K8s标签”中配置对应的标签。示例如下：2、单击左侧导航栏的“配置中心”，切换至“调度配置”页面，选择Volcano调度器找到对应的“专家模式”，单击“开始使用”。3、设置Volcano调度器配置参数，JSON格式的配置示例如下。... "default_scheduler_conf": { "actions": "allocate, backfill, preempt", "tiers": [ { "plugins": [ { "name": "priority" }, { "name": "gang" }, { "name": "conformance" } ] }, { "plugins": [ { "name": "drf" }, { "name": "predicates" }, { "name": "nodeorder" } ] }, { "plugins": [ { "name": "cce-gpu-topology-predicate" }, { "name": "cce-gpu-topology-priority" }, { "name": "cce-gpu" }, { // 开启节点池亲和性调度 "name": "nodepoolaffinity", // 节点池亲和性调度权重及标签设置 "arguments": { "nodepoolaffinity.weight": 10000, "nodepoolaffinity.label": "nodepool=nodepool1" } } ] }, { "plugins": [ { "name": "nodelocalvolume" }, { "name": "nodeemptydirvolume" }, { "name": "nodeCSIscheduling" }, { "name": "networkresource" } ] } ] }, ...4、 完成以上配置后，单击“确定”。 🌍 Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。📌 更多Volcano云原生批量计算 技术应用，请访问社区仓库或官网：1️⃣ Volcano云原生批量计算社区官网：https://volcano.sh2️⃣ Volcano GitHub 仓库: cid:link_53️⃣ Volcano云原生批量计算公开课：cid:link_34️⃣ 华为云云容器引擎CCE：cid:link_4 更多云原生技术动向关注容器魔方