4、LimitRange 详解：资源配额的精细化边界

在 Kubernetes 集群中，ResourceQuota 为命名空间设定了资源总量上限，但无法约束单个 Pod 或容器的资源行为。若某个 Pod 未设置 requests/limits，或某个容器请求了极端资源量，仍可能导致节点资源争抢或调度失败。LimitRange 正是为解决这一粒度问题而生的准入控制机制——它在命名空间级别为每个 Pod 或容器施加默认值、最小/最大约束及比例约束，确保所有工作负载的资源声明落在合理区间内。

4.1 LimitRange 对象定义与核心字段

LimitRange 是一个命名空间级别的资源对象，通过 spec.limits 数组定义多条规则。每条规则由 type（作用目标类型）、max/min（硬边界）、default/defaultRequest（默认值）以及 maxLimitRequestRatio（比例约束）组成。

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-mem-limits
  namespace: production
spec:
  limits:
  - type: Container
    max:
      cpu: "4"
      memory: "8Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "500m"
      memory: "1Gi"
    defaultRequest:
      cpu: "200m"
      memory: "512Mi"
    maxLimitRequestRatio:
      cpu: "4"
      memory: "4"
  - type: Pod
    max:
      cpu: "8"
      memory: "16Gi"

4.2 默认请求/限制设置：自动注入机制

当用户创建的 Pod 中容器未显式设置 resources.requests 或 resources.limits 时，LimitRange 的 default 和 defaultRequest 会自动填充缺失值。注入逻辑遵循以下优先级：

1. 容器已设置 limits 但未设置 requests：requests 继承 defaultRequest；若 defaultRequest 未定义，则 requests 等于 limits。
2. 容器已设置 requests 但未设置 limits：limits 继承 default；若 default 未定义，则 limits 等于 requests。
3. 两者均未设置：requests 取 defaultRequest，limits 取 default。
4. 两者均已设置：不做任何注入，仅校验是否满足 min/max/ratio 约束。

4.3 最小/最大约束：硬边界守卫

min 和 max 定义了容器或 Pod 资源声明的合法区间。任何违反边界的 Pod 创建请求都会被 Admission Controller 拒绝，并返回明确的错误信息。

• min 约束：检查 resources.requests（容器级别）或 Pod 内所有容器 requests 之和（Pod 级别）是否 ≥ 指定值。防止用户设置过低的资源请求导致节点过载。
• max 约束：检查 resources.limits（容器级别）或 Pod 内所有容器 limits 之和（Pod 级别）是否 ≤ 指定值。防止单个 Pod 占用过多资源影响其他工作负载。

4.4 比例约束：limits/requests 比值控制

maxLimitRequestRatio 用于限制容器 limits 与 requests 之间的最大比值。该约束在以下场景中尤为关键：

• CPU 突发场景：允许容器在空闲时使用低 requests，在负载时使用高 limits，但限制突发倍数防止过度抢占。
• 内存 QoS 保障：内存不可压缩，过大的 ratio 可能导致 OOM，建议内存 ratio 不超过 2 或 4。
• 成本控制：防止用户设置极低 requests 却申请极高 limits，规避资源计费或调度公平性问题。

校验公式：limits[resource] / requests[resource] ≤ maxLimitRequestRatio。若容器未设置 requests，则使用 defaultRequest 参与计算；若未设置 limits，则使用 default。

4.5 多规则叠加与冲突处理

一个 LimitRange 对象可包含多条规则，且一个命名空间可存在多个 LimitRange 对象。当多条规则作用于同一资源类型时，Kubernetes 采用以下策略：

• 取最严格值：对于 min，取所有规则中的最大值；对于 max，取所有规则中的最小值。
• 默认值合并：若多个 LimitRange 定义了不同的 default 或 defaultRequest，Kubernetes 会尝试合并；若同一资源类型出现冲突（如两个 default 值不同），则 Pod 创建失败并报错。
• 比例约束取最小比值：多个 maxLimitRequestRatio 同时存在时，取最小的 ratio 值作为最终约束。

4.6 实战：LimitRange 完整配置示例

以下示例展示一个面向微服务生产环境的 LimitRange 配置，涵盖 CPU 和内存的完整约束：

apiVersion: v1
kind: LimitRange
metadata:
  name: production-limits
  namespace: production
spec:
  limits:
  - type: Container
    # 硬边界：每个容器 CPU 100m~4，内存 128Mi~8Gi
    min:
      cpu: "100m"
      memory: "128Mi"
    max:
      cpu: "4"
      memory: "8Gi"
    # 默认值：未设置时自动注入
    default:
      cpu: "500m"
      memory: "1Gi"
    defaultRequest:
      cpu: "200m"
      memory: "512Mi"
    # 比例约束：limits 不得超过 requests 的 4 倍
    maxLimitRequestRatio:
      cpu: "4"
      memory: "4"
  - type: Pod
    # Pod 级别：所有容器 CPU 总和不超过 8，内存总和不超过 16Gi
    max:
      cpu: "8"
      memory: "16Gi"
    min:
      cpu: "200m"
      memory: "256Mi"

应用该 LimitRange 后，以下 Pod 创建行为将被控制：

4.7 常见问题与排查思路

• Pod 创建失败，提示 "exceeded max" 或 "below min"：检查 LimitRange 中对应资源类型的 min/max 值，确认 Pod 声明是否在合法区间内。
• Pod 未自动注入默认值：确认 LimitRange 的 type 是否为 Container（Pod 级别不触发默认值注入），且命名空间正确。
• 多个 LimitRange 冲突导致 Pod 无法创建：使用 kubectl get limitrange -n <ns> -o yaml 查看所有 LimitRange，合并或删除冗余规则。
• 比例约束校验失败：计算容器实际 limits/requests 比值，确保 ≤ maxLimitRequestRatio。注意内存 ratio 建议不超过 2~4。