kubernetes资源配额核心是三层控制：resourcequota限制命名空间总量（如requests.memory: 20gi），limitrange设置容器默认值与边界（如min/max cpu/memory），pod级必须显式声明requests/limits才能调度和运行，三者协同生效。
在 Kubernetes 中配置容器资源配额限制，核心是分层控制：先用 ResourceQuota 管 Namespace 总量，再靠 LimitRange 设默认值和边界，最后在 Pod 或 Deployment 中明确写 requests 和 limits。三者配合才能真正落地生效。
Namespace 级总量控制：ResourceQuota
它像给一个部门划预算总额，限制整个命名空间能用的 CPU、内存、Pod 数等总和。
- 必须指定
namespace，作用范围仅限该空间内所有对象 - 常见字段包括：
requests.cpu、requests.memory、limits.cpu、limits.memory、pods、services等 - 一旦超出配额，新 Pod 创建会被拒绝（报错类似
exceeded quota），但已运行的 Pod 不受影响 - 示例中设
requests.memory: 20Gi，表示该命名空间所有 Pod 的 memory requests 总和不能超过 20Gi
容器级默认与边界：LimitRange
它不设总量，而是为该命名空间下“没显式声明资源”的容器自动补默认值，并强制限制其上下限。
- 类型
type: Container表示规则应用于每个容器；也可设PersistentVolumeClaim -
min和max定义单个容器允许的最小/最大资源（如cpu: 200m/memory: 4Gi） -
default和defaultRequest会在容器未定义limits或requests时自动注入 - 若容器声明的
requests小于min，或limits超过max，创建会失败
Pod 级精准声明：requests 与 limits
这是最终执行层，写在容器 spec 里，直接决定调度行为和运行时约束。
-
requests是调度依据：Kubernetes 只会把 Pod 调度到剩余allocatable资源 ≥ 该值的节点上 -
limits是运行上限：CPU 超限会被节流（throttled），内存超限则触发 OOMKilled - CPU 单位用
m（毫核），如500m = 0.5 核；内存单位常用Mi（MiB）、Gi（GiB） - 建议对关键服务设
requests == limits，避免资源争抢，也便于 HPA 准确评估
配置顺序与依赖关系
实际生效依赖明确的先后逻辑：
- 先创建 Namespace，再在其内部署
ResourceQuota和LimitRange -
LimitRange的default值只影响未声明limits的容器；defaultRequest影响未声明requests的容器 -
ResourceQuota统计的是所有 Pod 的requests和limits总和，所以它依赖容器实际声明的值，或被LimitRange自动补全后的值 - 如果两者冲突（比如 LimitRange 设了 max.cpu=1，但 ResourceQuota 允许 namespace 总共用 10 核），以更严格的为准
