Kubernetes LimitRange 配置指南：解决 Pod 资源默认值与单容器限制

在 Kubernetes 集群的日常运维中，我们常会遇到这样的需求：希望给某个命名空间（Namespace）设置统一的资源“默认值”或“上限”。很多刚接触 K8s 的同学会下意识地寻找类似 Namespace.spec.resources 这样的字段，结果却发现根本不存在。

这是一个非常普遍的误解。在 Kubernetes 里，Namespace 级别并不能直接配置 Pod 的 requests / limits 数值。

Kubernetes 的设计哲学是将“单体限制”与“总量限制”的责任拆分开来：

• LimitRange：负责处理 Pod / Container 级别 的细节（如默认值、单 Pod 上限）。
• ResourceQuota：负责处理 Namespace 级别 的总量（如整个 Namespace 最多能用多少核 CPU）。

本文将深入探讨 LimitRange 的核心用法、配置场景与最佳实践。

一、LimitRange 能解决什么问题？

LimitRange（限制范围）是一个 Namespace 级别的资源对象，但它的作用对象却是该 Namespace 下的 每一个 Pod 或 Container。它主要解决以下三个痛点：

1. 防止“裸奔” Pod：开发人员经常忘记在 Pod YAML 中写 requests 和 limits，导致 Pod 被调度到节点上后无限抢占资源，或者因资源不足被驱逐。LimitRange 可以自动为其补全默认值。
2. 限制单 Pod 规格：防止有人申请一个超大的 Pod（例如 64核 128G），导致节点资源碎片化或影响其他应用调度。
3. 强制规范化：可以强制要求所有 Pod 必须显式声明资源需求，否则拒绝创建，从而推动资源管理的标准化。

二、核心功能详解

1. 自动补全默认值（Defaulting）

这是 LimitRange 最常用的功能。当 Pod 没有配置 requests 或 limits 时，Kubernetes 的 Admission Controller 会根据 LimitRange 的配置自动注入默认值。

apiVersion: v1
kind: LimitRange
metadata:
  name: ns-default-limits
  namespace: demo
spec:
  limits:
  - type: Container
    default:        # 如果没写 limits，默认补这个
      cpu: "1"
      memory: "1Gi"
    defaultRequest: # 如果没写 requests，默认补这个
      cpu: "500m"
      memory: "512Mi"

效果演示：

当你提交一个最简单的、未定义资源的 Pod 容器配置时：

containers:
- name: app
  image: nginx

Kubernetes 最终生成的 Pod 会自动带有如下资源配置：

resources:
  requests:
    cpu: 500m
    memory: 512Mi
  limits:
    cpu: 1
    memory: 1Gi

2. 限制资源范围（Min / Max）

除了补全默认值，LimitRange 还可以严格限制单个 Container 或 Pod 所能申请资源的最小值（min）和最大值（max）。

spec:
  limits:
  - type: Container
    min:
      cpu: "100m"    # 申请不能少于 0.1 核
      memory: "64Mi"
    max:
      cpu: "4"       # 申请不能超过 4 核
      memory: "8Gi"

如果用户提交的 Pod 申请了超出此范围的资源（例如申请了 10 核 CPU），API Server 会直接拒绝该请求，并返回明确的错误信息。

3. 强制要求声明资源

如果你希望实施严格的资源管理政策，要求所有 Pod 必须显式写明资源需求，可以配合 min 属性来实现。

当你设置了 min 属性，且没有设置 default / defaultRequest 时，其逻辑如下：

• 如果用户提交的 Pod 没有写 requests/limits，系统将无法自动补全默认值。
• 此时，空值或不存在的资源配置无法满足 min 所定义的最低要求，因此 Pod 创建会失败，从而实现强制声明的目的。

三、进阶配置示例：强制规范与兜底

在生产环境中，我们通常推荐一种“宽严相济”的配置策略：既提供兜底默认值，又严格限制最大规格。

apiVersion: v1
kind: LimitRange
metadata:
  name: production-limits
  namespace: prod-ns
spec:
  limits:
  - type: Container
    # 1. 限制单容器最大规格，防止资源霸占
    max:
      cpu: "4"
      memory: "8Gi"
    # 2. 限制最小规格，防止无意义的微型容器
    min:
      cpu: "50m"
      memory: "32Mi"
    # 3. 兜底默认值（重要！确保忘记配置时应用仍可运行）
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"

关键点解析

1. default 与 defaultRequest 的区别：
   • default: 对应 limits。如果 Pod 没写 limits，就用这个值。
   • defaultRequest: 对应 requests。如果 Pod 没写 requests，就用这个值。
2. Kubernetes 的默认继承逻辑：
   • 如果用户只在 Pod 中写了 limits 但没写 requests，K8s 会默认让 requests 等于 limits。
   • LimitRange 的注入逻辑是在对象创建（Admission）阶段进行的，不会影响已经运行中的 Pod。

四、小结

LimitRange 是 Kubernetes 资源管理的基石之一，它有效解决了“单点”（单个 Pod/Container）的资源规范问题。通过合理配置 LimitRange，我们可以确保：

• 所有 Pod 都有合理的资源请求，方便调度器做出最优决策。
• 没有“巨型 Pod”破坏节点的稳定性与资源的公平性。
• 开发人员即使偶尔忘记配置资源，应用也能获得一个可运行的默认配置（兜底机制）。

然而，LimitRange 无法限制 整个 Namespace 的资源消耗总和。如果用户在同一个 Namespace 下创建了 1000 个符合 LimitRange 规范的小 Pod，依然可能把集群资源耗尽。

这就需要引入资源管理的另一个关键角色 —— ResourceQuota。它专门用于限制 Namespace 级别的资源总量，与负责单体规范的 LimitRange 相辅相成，共同构成 Kubernetes 完整的资源管控体系。