6.8.6 limit (LimitRange) Pod/Container 默认资源限制案例

简介

1. 什么是 LimitRange？

LimitRange（资源范围限制）是 Kubernetes 的 命名空间级资源，用于为 Pod 或 Container 设置默认资源请求（requests）与默认资源限制（limits），并对资源的最小/最大值、比例等进行约束。

• 核心作用：
  1. 为未显式设置 resources.requests/limits的容器自动填充默认值，避免“无限制”运行。
  2. 防止单个容器申请/使用过多资源（通过 max/min限制上下界）。
  3. 统一命名空间内资源使用规范，降低因配置遗漏导致的稳定性风险。
• 适用范围：仅对所在 Namespace 内的 Pod/Container 生效，不影响其他 Namespace。

2. 与 ResourceQuota 的区别

工作原理

1. 默认值注入
   • 当 Pod/Container 未设置 resources.requests时，若 LimitRange 定义了 defaultRequest，则自动填充。
   • 当 Pod/Container 未设置 resources.limits时，若 LimitRange 定义了 default，则自动填充。
2. 范围校验
   • 若设置了 min/max，API Server 会在创建 Pod 时校验 requests与 limits是否在范围内，超范围则拒绝。
3. 比例约束（可选）
   • 通过 maxLimitRequestRatio限制 limits/requests的最大比例（防止 limits 远大于 requests 造成资源浪费或调度失衡）。

配置语法

apiVersion: v1
kind: LimitRange
metadata:
  name: <limitrange-name>
  namespace: <namespace>
spec:
  limits:
  - type: <Container|Pods|PersistentVolumeClaim>   # 作用对象类型
    default:        # 默认 limits（未设置 limits 时注入）
      cpu: "500m"
      memory: "512Mi"
    defaultRequest: # 默认 requests（未设置 requests 时注入）
      cpu: "100m"
      memory: "128Mi"
    min:            # 最小 requests/limits
      cpu: "50m"
      memory: "64Mi"
    max:            # 最大 requests/limits
      cpu: "4"
      memory: "8Gi"
    maxLimitRequestRatio:  # limits 相对于 requests 的最大比例
      cpu: 10
      memory: 4

• type：

  • Container：对容器生效（最常用）。
  • Pod：对整个 Pod 的所有容器资源总和生效。
  • PersistentVolumeClaim：对 PVC 的存储请求大小生效。

• 创建未指定资源的 Pod 时会自动带上这些默认值，防止“裸跑”容器抢占资源。

  Requests（请求）：容器启动时向 K8s 申请的最小资源量（CPU/内存）。调度器会根据 Requests 选择有足够资源的节点，确保容器至少获得该资源。

  Limits（限制）：容器能使用的最大资源量（CPU/内存）。若容器超出 Limits，会被 K8s 限制（CPU 被 throttling，内存可能被 OOMKill）。

  注意事项：

  requests ≤ limits必须成立：K8s 要求容器的 requests不能大于 limits（否则调度失败）。因此，defaultRequest的值应 ≤ default的值（示例中 100m ≤ 500m、128Mi ≤ 512Mi），否则会导致冲突。

  优先级：用户显式设置 > LimitRange 默认值：无论用户设置 requests还是 limits，都会覆盖 defaultRequest或 default。

  作用范围：LimitRange 是命名空间级资源：每个 Namespace 可定义自己的 LimitRange，仅对当前 Namespace 内的 Pod/容器生效。

  内存与 CPU 的差异： CPU 是“可压缩资源”：超出 limits时，容器不会被杀死，仅会被 throttling（限制 CPU 时间片）。 内存是“不可压缩资源”：超出 limits时，容器会被 OOMKill（Out Of Memory Kill），并可能触发 Pod 重启。

案例1：设置默认 CPU/内存 Request 与 Limit（Container 级）

场景

在 dev命名空间，防止开发者提交的 Pod 忘记设置 resources，统一注入：

• 默认 requests：CPU 100m、内存 128Mi
• 默认 limits：CPU 500m、内存 512Mi

YAML 配置（ limitrange-default-resources.yaml ）

apiVersion: v1
kind: LimitRange
metadata:
  name: dev-default-limits
  namespace: dev
spec:
  limits:
  - type: Container
    default:        # 默认 limits
      cpu: "500m"
      memory: "512Mi"
    defaultRequest: # 默认 requests
      cpu: "100m"
      memory: "128Mi"
    min:            # 最小资源（低于此值拒绝）
      cpu: "50m"
      memory: "64Mi"
    max:            # 最大资源（高于此值拒绝）
      cpu: "2"
      memory: "4Gi"

创建与验证

kubectl apply -f limitrange-default-resources.yaml
kubectl describe limitrange dev-default-limits -n dev

效果：

• 若在 dev命名空间创建未设置 resources的 Pod：

  resources:
    requests: {cpu: "100m", memory: "128Mi"}   # 来自 defaultRequest
    limits:   {cpu: "500m", memory: "512Mi"}   # 来自 default
  

• 若设置的值小于 min或大于 max，Pod 创建失败（Forbidden）。

案例2：Pod 级总资源限制

场景

限制 test命名空间内每个 Pod 的所有容器 CPU 总请求不超过 2 核、内存总请求不超过 4Gi。

YAML 配置（ limitrange-pod-total.yaml ）

apiVersion: v1
kind: LimitRange
metadata:
  name: test-pod-limits
  namespace: test
spec:
  limits:
  - type: Pod
    max:
      cpu: "2"
      memory: "4Gi"
    min:
      cpu: "100m"
      memory: "128Mi"

效果：

• 若 Pod 有多个容器，它们的 requests总和不得超过 max设定值。

案例3：PVC 存储请求限制

场景

限制 storage-ns命名空间内 PVC 的存储请求范围：最小 1Gi，最大 100Gi。

YAML 配置（ limitrange-pvc.yaml ）

apiVersion: v1
kind: LimitRange
metadata:
  name: storage-pvc-limits
  namespace: storage-ns
spec:
  limits:
  - type: PersistentVolumeClaim
    min:
      storage: "1Gi"
    max:
      storage: "100Gi"

效果：

• 创建 PVC 时，若 resources.requests.storage小于 1Gi 或大于 100Gi，将被拒绝。

生产最佳实践

1. 所有 Namespace 都应配置 LimitRange
   • 防止忘记设置 resources的 Pod 进入集群，避免资源争抢或 OOM。
2. 合理设置 defaultRequest 与 default
   • defaultRequest应接近应用实际最低需求（参考压测 P95 使用量）。
   • default应留有适当缓冲（如 memory 比实际使用高 20%-30%）。
3. min/max 防止极端配置
   • min避免过小导致容器无法正常运行（如 Java 应用堆内存不足）。
   • max避免单容器占用过多资源影响同节点其他 Pod。
4. 与 ResourceQuota 配合使用
   • 先通过 LimitRange 保证单容器资源合规，再通过 ResourceQuota 控制 Namespace 总量。
5. 定期 Review 与调整
   • 随应用负载变化调整默认值与范围，避免限制过严或过松。