中文
资源配额管理
管理员配置平台级和项目级的计算资源配额，防止资源争用
资源配额管理
资源配额系统允许管理员控制平台的 CPU、内存、GPU 和容器实例等计算资源总量上限，防止单个项目或用户占用过多资源影响其他用户。
概述
资源配额分为两个层级：
- 全局配额：限制所有项目合计可使用的资源总量
- 项目配额：限制单个项目可使用的资源量（默认从全局配额派生）
当项目尝试启用或启动容器时，系统会检查配额余额。如果资源不足，请求会被拒绝并返回明确的瓶颈提示。
管理员配置
入口：管理 → 资源配额（/workspace/admin/resource-quotas）
设置标签页
| 配置项 | 说明 |
|---|---|
| 配额状态 | 启用或禁用配额管控 |
| 最大 CPU 核心数 | 所有容器合计可使用的 CPU 核心总数 |
| 最大内存（MB） | 所有容器合计可使用的内存总量 |
| 持久化容器数上限 | 同时运行的持久化容器数量上限 |
| 临时容器数上限 | 同时运行的临时 Agent 容器数量上限 |
| GPU 数量上限 | 所有容器合计可使用的 GPU 设备总数 |
默认值根据宿主机硬件自动计算（通常为宿主机 CPU 的 80% 和内存的 75%）。
运行中容器标签页
分页展示当前所有运行中容器的信息：
- 所属项目名称
- 容器镜像
- CPU、内存、GPU 资源分配量
- 最后活跃时间
拒绝记录标签页
记录资源配额不足导致的拒绝事件，帮助管理员分析瓶颈：
- 拒绝时间和原因
- 瓶颈资源类型
- 受影响的项目
资源租约机制
系统使用 资源租约（Lease） 模型管理资源分配：
- 容器启用/启动时获取对应资源的租约
- 容器停止/禁用时释放租约
- 租约按资源类型（CPU、内存、GPU、容器实例）分别计量
- 租约操作带有并发锁，防止竞态条件
等待资源与自动唤醒
当容器因配额不足无法启动时：
- 容器进入
waiting_for_resources状态 - 工作台顶部状态指示器显示琥珀色提示，说明具体瓶颈资源
- 当其他容器停止或配额增加时，系统自动重试等待中的容器（资源唤醒）
- 等待中的 Agent 票据也会在资源释放后被自动唤醒执行
主机重启后的状态同步
如果宿主机重启：
- 系统自动检测所有容器启用项目的实际容器状态
- 仍在运行的容器重新获取资源租约
- 已丢失的容器标记为停止状态
- 容器状态与资源租约保持一致
状态同步也会覆盖 Kubernetes 运行后端：
- 项目持久化容器对应的 Pod / Job 丢失后会被标记为停止或错误
- 已停止、已禁用或已完成的运行会释放对应租约
- 资源控制器会按配置周期检查异常状态，减少人工清理
项目级配额
项目设置中的容器面板也可以查看和调整项目级资源限制：
- manager 和 owner 可以调整项目维度的 CPU、内存和 GPU 上限
- 项目配额不能超过全局配额
- 适合在多项目环境下为不同项目分配合理的资源比例
与存储配额的区别
本页管理的是运行时计算资源，例如 CPU、内存、GPU、持久化容器数和临时 Agent 容器数。
项目文件空间属于存储配额，当前在启用 PROJECT_STORAGE_QUOTA=juicefs 的部署中由 JuiceFS 管理：
- 项目列表和项目设置可显示存储已用量与上限
- 本地工作区上传超出存储配额时会返回“项目存储配额已超限”
- 存储配额不会增加可运行容器数量；运行容器仍受本页的资源配额约束
典型场景
场景 1：多项目共享有限资源
- 管理员根据服务器配置设置全局配额
- 为高优先级项目分配更大的项目配额
- 低优先级项目受配额限制，不会影响核心项目
场景 2：防止单项目资源垄断
- 设置合理的项目配额上限
- 单个项目无法启动超过配额的容器
- 其他项目始终有资源可用