云原生集群管理容器编排任务调度【免费下载链接】mesosApache Mesos项目地址https://gitcode.com/gh_mirrors/meso/mesos点击查看免费下载本篇围绕 Apache Mesos 的 Quota配额功能展开在多个用户或团队共享同一个集群时运维人员如何按 role 维度为每个角色设置资源用量上限limit、如何通过 v1 API 更新与查询配额、配额消耗量是如何计算的以及配额在 master 内部registry 持久化、allocator 生效、offer 回收的完整执行链路。读完本文你不仅能直接复制可用的UPDATE_QUOTA/GET_QUOTA操作命令还能从源码层面理解限额的校验规则、force 标志的作用边界与 failover 恢复行为。Quota 解决什么问题当多个用户共享一个 Mesos 集群时运维方往往希望限制每个用户最多能用多少资源。Quota 正是为此设计的它允许 operator 以per-role按角色的粒度设置资源上限。Mesos 中的 role 天然适合作为租户边界——框架framework在注册时声明所订阅的 role其分配到的资源都会计入该 role从而形成清晰的配额归属。配额的核心数据模型由 include/mesos/quota/quota.proto 定义其中关键消息是message QuotaConfig { required string role 1; mapstring, Value.Scalar guarantees 2; // 已废弃的配额保证 mapstring, Value.Scalar limits 3; // 资源上限 }在 src/master/quota.cpp 中Quota结构体把QuotaConfig转换为内存中的guaranteesResourceQuantities与limitsResourceLimits两个集合对旧版 API 的QuotaInfo/QuotaRequestguarantee 会同时被当作 limit 处理源码注释明确写着 For legacyQuotaInfo, guarantee also acts as limit这正是后文Deprecated: Quota Guarantees一节的由来。支持配额的资源类型支持Quota 的资源cpusmemdiskgpus任何类型为SCALAR的自定义资源不支持Quota 的资源ports任何类型为RANGES或SET的自定义资源这一约束在请求校验逻辑中有对应实现src/master/quota.cpp 中的validation::quotaInfo会对每个资源检查resource.type() ! Value::SCALAR时直接报错 QuotaInfo must not include non-scalar resources并拒绝携带ReservationInfo、DiskInfo、RevocableInfo等资源字段。设置配额UPDATE_QUOTA 调用默认情况下每个 role 都没有资源限制。要为单个或多个 role 修改资源限制使用 v1 API 的UPDATE_QUOTA调用。注意该调用是原子性的all-or-nothing如果请求中某一个 role 的配额更新无效或未获授权整个请求都不会生效。完整示例curl --request POST \ --url http://master-ip:master-port/api/v1/ \ --header Content-Type: application/json \ --data { type: UPDATE_QUOTA, update_quota: { force: false, quota_configs: [ { role: dev, limits: { cpus: { value: 10 }, mem: { value: 2048 }, disk: { value: 4096 } } }, { role: test, limits: { cpus: { value: 1 }, mem: { value: 256 }, disk: { value: 512 } } } ] } }请求参数说明字段类型说明typestring固定为UPDATE_QUOTAupdate_quota.forcebool是否强制覆盖。默认falseupdate_quota.quota_configs[]array一批 role 的配额配置整体原子生效quota_configs[].rolestring目标 role 名必须存在于 role 白名单若配置了--roles且不支持嵌套 role如eng/prodquota_configs[].limitsmap资源上限键为资源名cpus、mem、disk、gpus或自定义 SCALAR 资源值为{ value: number }quota_configs[].guaranteesmap旧版保证语义已废弃新配置只应设置limits关于force标志的两点行为与 docs/quota.md 保持一致如果 role当前已消耗的配额超过了所设 limit请求会被拒绝将force设为true可以绕过该检查。master 会尝试回收rescind足够的 outstanding offers确保该 role 不会超过其 limit。源码中的校验链路UPDATE_QUOTA的完整处理在 src/master/quota_handler.cpp 的Master::QuotaHandler::update中校验顺序如下role 白名单检查master-isWhitelistedRole(config.role())不在白名单中的 role 直接返回 400is not on the roles whitelist。嵌套 role 拒绝role 名包含/时返回 Updating quota on nested role ... is not supported yet。配置合法性校验src/master/quota.cpp 中的validate(const QuotaConfig)包含几个容易踩坑的硬限制标量值必须非负且有限mem、disk的上限为1 Exabyte以 MB 为基准单位其他资源如 cpus、自定义资源的上限为1 万亿1 trillion——这是为了避免Value::Scalar底层定点逻辑在约 9.2e15 附近发生溢出若同时设置了guarantees和limits必须满足guarantees limits。当前消耗检查通过RoleResourceBreakdown(master, role).consumedQuota()计算 role 当前消耗若limits不包含该消耗量且未提供force返回 400 并提示 use force flag to bypass this check。配额树QuotaTree层级校验与集群容量超卖overcommit检查所有 role 的 guarantees 总和不能超过集群已注册 agent 的标量资源总量同样可被force覆盖。授权检查逐个 config 调用 authorizer 的UPDATE_QUOTA_WITH_CONFIG动作任一未授权则整个请求返回 403 Forbidden——这就是all-or-nothing在权限层面的体现。校验全部通过后_update会将配额写入 registry见下文持久化一节更新 master 内存态master-quotas并调用master-allocator-updateQuota(...)让分配器立即生效。配额如何持久化配额的持久化走的是 master 的 registry 事务机制。src/master/quota.hpp 定义了UpdateQuota这个RegistryOperation其头文件注释解释了关键设计决策不对 quota registry 操作施加任何约束quota 请求是否合法由 master 与 allocator 判断因此perform()从不返回Error。UpdateQuota::perform的实现src/master/quota.cpp先把整批QuotaConfig再校验一遍防御性检查逐个 role 在 registry 的quota_configs中查找如果新配额等于DEFAULT_QUOTA即空配置等同于删除配额则删除该 role 的条目否则更新或插入顺带清理旧版quotasQuotaInfo字段中同 role 的遗留条目保证新老实态不冲突若 registry 中还存在任何配额则在 registry 的minimum_capabilities中追加QUOTA_V2能力标记否则移除该标记——这保证了 HA 集群中旧版本 master 在 failback 时能正确拒绝不支持的配置。查看配额Web UIWeb UI 的Roles标签页会展示所有已知 role 的资源核算信息其中就包括已配置的配额quota与配额消耗quota consumption。APIGET_QUOTA 返回配额配置$ curl --request POST \ --url http://master-ip:master-port/api/v1/ \ --header Content-Type: application/json \ --header Accept: application/json \ --data { type: GET_QUOTA }响应{ type: GET_QUOTA, get_quota: { status: { infos: [ { configs : [ { role: dev, limits: { cpus: { value: 10.0 }, mem: { value: 2048.0 }, disk: { value: 4096.0 } } }, { role: test, limits: { cpus: { value: 1.0 }, mem: { value: 256.0 }, disk: { value: 512.0 } } } ] } ] } } }从源码看GET_QUOTA的响应由 src/master/quota_handler.cpp 中_status组装它先快照当前master-quotas避免响应构建期间配额被并发修改再对每个 role 逐个执行authorizeGetQuota授权检查action 为GET_QUOTA未被授权的 role 会从结果中过滤掉。返回体同时填充了旧版QuotaInfo仅含 guarantee用于向后兼容和新版QuotaConfig含 guarantees 与 limits两个视图。/roles端点同时查看配额与消耗$ curl http://master-ip:master-port/roles响应示例{ roles: [ { name: dev, weight: 1.0, quota: { role: dev, limit: { cpus: 10.0, mem: 2048.0, disk: 4096.0 }, consumed: { cpus: 2.0, mem: 1024.0, disk: 2048.0 } }, allocated: { cpus: 2.0, mem: 1024.0, disk: 2048.0 }, offered: {}, reserved: { cpus: 2.0, mem: 1024.0, disk: 2048.0 }, frameworks: [] } ] }Quota Consumption消耗量到底包含什么文档给出的口径是一个 role 的配额消耗 其 allocations reservations。也就是说即使 reservation 尚未被分配它同样计入配额消耗而被 offer 出去但尚未接受分配的资源offered不计入配额消耗。这个口径在 src/master/master.cpp 的Master::RoleResourceBreakdown::consumedQuota中有直接实现ResourceQuantities Master::RoleResourceBreakdown::consumedQuota() const { ResourceQuantities unallocatedReservation; foreachvalue (Slave* slave, master-slaves.registered) { ResourceQuantities totalReservation ResourceQuantities::fromResources( slave-totalResources.reservedToRoleSubtree(role)); ResourceQuantities usedReservation; foreachvalue (const Resources r, slave-usedResources) { usedReservation ResourceQuantities::fromResources( r.reservedToRoleSubtree(role)); } unallocatedReservation totalReservation - usedReservation; } return allocated() unallocatedReservation; }实现逻辑与文档描述一一对应先对每个 agent 计算总 reservation − 已使用的 reservation得到未分配的部分再加上allocated()该 role 子树下所有 framework 的已用资源即为消耗总量。offered()、allocated()、reserved()三个分解函数也在同一位置src/master/master.cpp实现正是/roles端点输出中同名字段的来源。此外配额消耗还会沿 role 树的祖先节点向上聚合——src/master/allocator/mesos/hierarchical.cpp 中RoleTree每次 track/untrack 分配与 reservation 时都会调用applyToRoleAndAncestors更新每一层的消耗并同步指标。Metrics文档列出的配额相关指标键allocator/mesos/quota/roles/role/resources/resource/guaranteeallocator/mesos/quota/roles/role/resources/resource/limit配额消耗指标将经由 MESOS-9123 提供。从当前仓库源码看消耗指标实际上已经有对应实现src/master/allocator/mesos/metrics.hpp 中定义了QuotaMetrics quotaConsumed {/consumed}Metrics::updateConsumed负责写入src/master/allocator/mesos/metrics.cpp 的updateQuota还会为设置了配额的 role 注册allocator/mesos/quota/roles/role/resources/name/offered_or_allocated的 PullGauge。另外有一个实现细节值得注意当 role 配额被重置为DEFAULT_QUOTA即删除配额时updateQuota会提前返回不再发布 offered_or_allocated 指标以保持与旧版行为一致。指标命名注释中也给出了官方示例Quota metrics should have a suffix in singular. (Example of a name: allocator/mesos/quota/roles/roleA/resources/cpu/limit.)Deprecated: Quota Guarantees已废弃的配额保证Mesos 1.9 之前配额 API 只暴露 guarantees配额保证保证某个 role 最少有若干资源可用同时设置 guarantee 也会隐式地设置一个 limit。1.9 起limit 作为独立概念直接暴露即本文前述的limits字段guarantees 则被废弃。废弃的核心理由与 Mesos 向optimistic offer model乐观 offer 模型演进直接相关见 JIRA MESOS-1607其目标是改善多 role / 多 scheduler 场景下的可扩展性强制保证 quota guarantee 要求 Mesos预留hold back足够资源来满足所有尚未满足的 guarantee——这在传统分配模型下是可行的而乐观 offer 模型下扣下资源留白的做法不再可行limit 在这种模型下依然简单可执行但 guarantee 将需要一套复杂的 effective limit 传播机制因此 limit 基于优先级的抢占priority based preemption 的组合会是更简单、更契合未来模型的方向。guarantee 在 Mesos 1.9 中仍然可用但已标记为废弃旧版 guarantee 用法可参考 Apache Mesos 1.8.0 发布版中的 docs/quota.md本仓库文档指向的版本分支此处不给出外链。从源码可以印证 guarantee 仍被完整保留的现状QuotaConfig消息中guarantees字段与limits并列存在QuotaTree::validatesrc/master/quota_handler.cpp至今仍校验父 role 的 guarantee 必须包含其所有子 role guarantee 之和的层级关系_update流程里也会为 guarantee 单独执行一轮 offer 回收。实现细节与边界条件嵌套 role 暂不支持配额对eng/prod这类嵌套 role 设置配额目前不支持update入口会直接返回 Updating quota on nested role ... is not supported yet源码中标注待 MESOS-7402 修复后移除该检查。Failover 期间 allocator 的暂停与恢复Master failover 后为了正确执行配额限制allocator 会被暂停直到满足以下两个条件之一才重新发放 offer至少80%的 agent 重新注册或10 分钟超时。这两个参数在默认值层面与源码完全对应include/mesos/allocator/allocator.hpp 中constexpr Duration DEFAULT_ALLOCATOR_RECOVERY_TIMEOUT Minutes(10); constexpr double DEFAULT_ALLOCATOR_AGENT_RECOVERY_FACTOR 0.80;并且它们已通过 master 的启动 flag 暴露为可配置项src/master/flags.cpp--allocator_agent_recovery_factor领导者选举后allocator 开始发放 offer 所需的已重新注册 agent 的最低比例--allocator_recovery_timeout领导者重选后开始发放 offer 前最多等待的时间。在 src/master/allocator/mesos/hierarchical.cpp 的恢复流程中可以看到具体机制expectedAgentCount _expectedAgentCount * options.agentRecoveryFactor随后pause()暂停分配并delay(options.recoveryTimeout, self(), Self::resume)注册超时恢复每有一个 agent 重新注册便计数一次达到expectedAgentCount即恢复。若集群内没有任何预期 agent则直接跳过恢复等待。默认 role*现在受支持配额已支持默认的*role对应 JIRA MESOS-3938。配额的强制执行best-effort 的 offer 回收文档提到master 会尝试回收足够的 offer 以确保 role 不超过 limit。这一行为的完整实现位于 src/master/quota_handler.cpp 的_update中值得理解其设计取舍配额先行registry 事务提交后先更新master-quotas并 dispatchupdateQuota到 allocator再执行回收。注释明确解释了顺序若先回收再设配额回收出来的资源可能在updateQuota生效前被重新分配出去master 与 allocator 之间存在消息竞态。限额回收计算该 role 的consumedQuota() offered()遍历所有 framework 的 outstanding offers对分配给该 role 子树的 offer 逐个rescindOffer直到consumedAndOffered落回 limit 之内。保证回收针对 guarantee悲观地假设 allocator 中看似可用的资源都会消失贪婪地回收其他 role 子树之外的 offer直到rescinded consumedAndOffered覆盖该 role 的全部 guarantees。源码注释坦承这是一项best-effort工作精确追踪 consumed/offered 的边界代价很高且 master 与 allocator 之间存在竞态可能多收也可能少收配额的意义在于收敛一个瞬时状态——资源持续流动后配额最终会被强制执行。注释同时指出未来若 Mesos 全面转向乐观 offer 模型MESOS-1607配额强制将移到准入控制admission control阶段完成offer 回收将不再必要。另外MesosAllocator对updateQuota的调用src/master/allocator/mesos/allocator.hpp是通过process::dispatch异步派发到 allocator 进程处理的HierarchicalAllocatorProcess::updateQuota会更新roleTree并同步刷新指标、记录日志src/master/allocator/mesos/hierarchical.cpp随后触发新一轮分配使新的限额立即作用于后续 offer 的生成。小结能力入口关键点设置/修改/删除配额v1 APIUPDATE_QUOTA原子生效force可越过已超消耗与超卖检查删除配额 提交空QuotaConfig查询配额配置v1 APIGET_QUOTA逐 role 授权过滤同时返回旧版infos与新版configs查询配额消耗/rolesHTTP 端点consumed allocated 未分配 reservationoffered 不计入监控指标/metricsallocator/mesos/quota/roles/role/resources/resource/{guarantee,limit,consumed,offered_or_allocated}Failover 恢复--allocator_agent_recovery_factor/--allocator_recovery_timeout默认 80% agent 重注册或 10 分钟超时后恢复发放 offer配合 src/master/quota.cpp、src/master/quota_handler.cpp 与 include/mesos/quota/quota.proto 这三个文件可以完整追溯一条UPDATE_QUOTA请求从 HTTP 入口、参数校验、registry 事务到 allocator 生效的全链路本文所有实现级结论均可在仓库中直接查证。赞分享云原生集群管理容器编排任务调度【免费下载链接】mesosApache Mesos项目地址https://gitcode.com/gh_mirrors/meso/mesos点击查看免费下载相关推荐Apache Mesos 配额Quota实战指南基于角色Role的资源限额配置、查询与原理Apache Mesos 配额Quota实战指南基于角色Role的资源限额配置、查询与原理 当多个用户或团队共享同一个 Mesos 集群时某个角色集群管理任务调度后端Apache Mesos 1.9.0 发布解读Agent 排空、Quota 限额与 TLS 安全机制升级Apache Mesos 1.9.0 发布解读Agent 排空、Quota 限额与 TLS 安全机制升级 导读 本文基于 Apache Mesos 1.9.0集群管理任务调度后端终极NES游戏模拟器配置指南FCEUX完整使用教程终极NES游戏模拟器配置指南FCEUX完整使用教程 你是否怀念童年时期的红白机游戏想要在电脑上重温《超级马里奥》、《塞尔达传说》等经典NES游戏FCEUX游戏开发开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
