LimitRange 是干什么的
LimitRange 是命名空间级的资源约束对象，做两件事：为没有声明 resources 的容器补上默认的 requests 与 limits，以及限制单个容器、Pod 或 PVC 的用量上下限与请求限制比例。它的核心价值在于把「默认值」集中管理，防止命名空间里出现大量既没有 requests 又没有 limits 的容器——那类容器会让调度失去计算依据，也让扩缩容与容量评估失去基础。
基本信息
| 作用范围 | 单个命名空间，对象需建在目标命名空间内 |
|---|---|
| 可约束类型 | Container、Pod、PVC |
| 默认值字段 | default（补 limits）、defaultRequest（补 requests） |
| 限制字段 | max、min、maxLimitRequestRatio |
| 生效时机 | 对象创建与更新时由准入控制器注入 |
为命名空间设默认资源
为命名空间设默认资源
apiVersion: v1
kind: LimitRange
metadata:
name: default-limits
namespace: prod
spec:
limits:
- type: Container
default:
cpu: 500m
memory: 512Mi
defaultRequest:
cpu: 100m
memory: 128Mi
max:
cpu: '4'
memory: 4Gi
maxLimitRequestRatio:
cpu: '10' # 限制超卖倍数，避免 requests 与 limits 差距过大验证注入结果
验证注入结果
kubectl describe limitrange default-limits -n prod # 查看声明与默认值
kubectl get pod web-x -n prod -o jsonpath='{.spec.containers[0].resources}' # 看容器实际拿到的值
kubectl get pod web-x -n prod -o jsonpath='{.spec.containers[0].resources.requests}' # 确认 requests 被补上
kubectl get events -n prod --field-selector reason=FailedCreate # 超出上下限时创建会被拒典型使用场景
- 新命名空间基线：业务团队接入时先给默认资源，避免大量无 requests 的容器流入集群
- 防止资源失控：用 max 拦住明显写错的清单，例如把内存写成 400Gi
- 避免超卖过度：用 maxLimitRequestRatio 限制 requests 与 limits 的差距，减少节点争抢
- PVC 容量约束：对命名空间内申请的存储容量设置上下限，防止误申请超大卷
- 配合 HPA：容器必须有 requests 才能算使用率，默认注入能保证这一前提不被破坏
字段读法
| 字段 | 作用 | 设置建议 |
|---|---|---|
| default | 未写 limits 时补齐的上限 | 按业务常规峰值设置，不宜过大 |
| defaultRequest | 未写 requests 时补齐的请求量 | 不写时 requests 会等于 limits，弹性下降 |
| max | 单容器或单 Pod 的上限 | 过大失去保护意义，过小会拒绝正常扩容 |
| min | 下限，防止写 0 或极小值 | 结合最小可用资源评估 |
| maxLimitRequestRatio | limits 与 requests 的比例上限 | 在线服务宜控制在较小倍数 |
默认值只在对象创建（以及部分更新场景）时注入，不会修改已运行的 Pod。调整 LimitRange 后，存量工作负载要重建才会带上新默认值。
只写 default 不写 defaultRequest 时，被注入的 requests 会等于 limits，容器在 QoS 分类上偏向 Guaranteed，扩展弹性下降。希望保持弹性时两者都要写，并让 requests 明显小于 limits。