4.1 LimitRange 基础：作用、默认请求/限制、最小/最大约束

在 Kubernetes 多租户或团队共享集群的场景中，如果没有对 Namespace 内的 Pod 资源进行约束，个别“超规格”容器可能耗尽节点资源，导致其他正常 Pod 被驱逐或无法调度。LimitRange 正是 Namespace 级别的资源策略工具，它通过声明式配置，为 Namespace 内所有 Pod 或容器设定资源使用的“下限”与“上限”，并自动注入默认的 request 与 limit。

4.1.1 LimitRange 的核心作用

4.1.2 默认请求/限制的注入机制

当 Pod 中某个容器未指定 resources.requests 或 resources.limits 时，LimitRange 会根据 default 和 defaultRequest 字段自动补全。注入规则如下：

• default：容器的 limits 默认值（若容器未定义 limits）。
• defaultRequest：容器的 requests 默认值（若容器未定义 requests）。
• 如果只设置了 default 而未设置 defaultRequest，则 requests 会继承 default 的值（即 request = limit）。
• 如果只设置了 defaultRequest 而未设置 default，则 limits 不会被自动注入，但 Pod 仍需通过准入检查。

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-mem-defaults
  namespace: team-budget
spec:
  limits:
  - type: Container
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    min:
      cpu: "100m"
      memory: "128Mi"
    max:
      cpu: "2"
      memory: "4Gi"
    maxLimitRequestRatio:
      cpu: "3"

4.1.3 最小/最大约束的准入控制

LimitRange 的 min 和 max 字段在 Pod 创建或更新时由 LimitRanger 准入控制器 强制执行。如果 Pod 中任意容器的资源声明违反约束，API Server 会直接拒绝请求，并返回明确的错误信息。

4.1.4 LimitRange 资源约束流程

下图展示了 LimitRange 在 Pod 创建时的完整处理流程，包括默认值注入与约束校验：

4.1.5 多类型 LimitRange 与作用域

LimitRange 支持按 type 区分作用域，常见类型包括：

4.1.6 常见问题与避坑

• LimitRange 不限制 InitContainer： InitContainer 的资源声明不受 LimitRange 约束，需单独通过 ResourceQuota 或 Pod 安全策略管理。
• 默认值覆盖顺序： 如果 Pod 中部分容器指定了 request 但未指定 limit，LimitRange 只注入 limit 默认值，不会覆盖已显式设置的 request。
• 更新已有 LimitRange： 修改 LimitRange 后，仅对新创建的 Pod 生效，已运行的 Pod 不受影响。如需强制更新，需重建 Pod。
• 与 ResourceQuota 的协作： LimitRange 控制“单个 Pod 的规格”，ResourceQuota 控制“Namespace 的总量”。两者配合使用可实现精细化的资源预算管理。