CNCF Karmada 多集群调度怎样按命名空间隔离资源配额

Karmada 可以用命名空间内的 FederatedResourceQuota 管理跨集群配额：spec.overall 表达命名空间的联邦总额，spec.staticAssignments 表达指定成员集群的本地 ResourceQuota。若要在控制面阻止超出总额的工作负载继续调度，还需要启用对应的联邦配额执行能力。配额不是调度位置规则，也不是CPU物理独占。

官方地址：https://karmada.io/

本文依据 Karmada v1.19 官方文档解释能力与落地顺序，是项目功能解读，不把既有能力包装成刚发布的新闻。以下团队、额度及状态判断均为教学场景，没有执行真实集群操作。

先把租户边界落到命名空间

假设订单团队和报表团队共用两个成员集群。若两个团队的工作负载都放在同一个命名空间，仅增加一个联邦配额对象，不能按团队自动拆开账本。应先把租户归属设计清楚，例如订单使用 orders-team，报表使用 reports-team，再分别建立对应的配额。

配额对象的 metadata.namespace 决定它约束哪个命名空间；对象名称只是标识，起名为“orders”不会自动筛选带订单标签的应用。跨成员集群的同名命名空间需要保持一致的业务归属。

从治理角度看，平台还要明确谁能创建工作负载、谁能调整额度、谁负责处理超额。配额解决资源计量限制，访问权限与网络访问边界仍需要各自的机制，不能用一个额度对象替代全部租户隔离设计。

区分联邦总量与成员集群硬限制

联邦总量回答“这个命名空间跨集群可以使用多少”；静态分配回答“某个成员集群内的同名命名空间设多少硬限制”。两者可以同时出现，却不能互相替代。

官方API特别说明，调度器当前不使用 staticAssignments 来作调度决策。因此，不能假定某集群本地额度满后，调度器一定会依据这个字段自动将副本搬到另一个集群。

未列出的集群，或静态分配为空时，不会由该字段创建相应的 ResourceQuota。这不等于“额度为零”，也不代表那里没有其他已有配额。

按两层需求安排落地顺序

先确定命名空间和资源计量口径，再决定需要哪一种约束。若需求是集中维护各成员的本地限制，使用静态分配；若需求是防止团队在联邦层过量提交，应同时评估控制面配额执行。

v1.19 用户指南将 FederatedQuotaEnforcement 标为 Alpha、默认关闭。启用前应依据实际部署版本及组件的功能门控说明配置，不能因为API对象可以创建，就推断控制面已经执行总额限制。

可以用一个额度规划表帮助沟通。比如订单团队总额拟定为12核，成员 east 拟定4核，成员 west 拟定8核；这只是管理员主动设计的静态份额。4加8等于12是此场景的规划选择，不表示系统会自动算出这两个成员的比例。

当使用控制面执行时，还要保证平台能正确识别工作负载的资源需求。新类型或多组件工作负载应按自身解释与支持能力接入，不能把普通 Deployment 的处理方式无条件推广到所有自定义资源。

扩容失败时看哪一层配额

排查时先回答“失败发生在哪一层”。若联邦额度已不足，关注控制面执行和命名空间总账；若工作负载已到达成员集群但Pod无法创建，关注成员命名空间的本地硬限制和事件。若额度尚有余量而Pod仍不能运行，则还需看实际节点容量及工作负载的放置条件。

状态信息也应分层阅读：status.overall 与 status.overallUsed 用于了解联邦额度及观察用量；status.aggregatedStatus 提供成员层面的 hard 和 used。状态值需要结合来源与更新情况解释，不是CPU瞬时利用率曲线。

一个容易遇到的情况是：全局预算还有余量，east 的本地份额却用尽了。此时只提高 overall 不会自动提高 east 的本地 ResourceQuota。需要确定是调整成员份额、调整放置策略，还是释放已有资源。

上线与调整时保留哪些约定

建议为每个团队记录命名空间、总体额度、成员份额、资源需求填写规则以及调整负责人。扩容或故障迁移之前，把目标成员的剩余额度也列入容量计划；“总量够”不能保证目标位置能够接收全部工作负载。

只创建命名空间就有配额吗？没有。命名空间是归属边界，具体额度还需要对应资源对象和执行机制。

静态份额是否自动借用其他集群的余额？不能这样理解。静态分配表达指定成员的硬限制，调整需要明确的管理动作。

配额是否保证分到独占CPU？不是。资源额度、节点可用性以及运行时独占策略是不同层面的事情。

参考：Karmada 联邦资源配额指南；FederatedResourceQuota API；Kubernetes 资源配额说明。