概述

在 Kubernetes（K8s）的集群世界里，资源就像是一块有限的“大蛋糕”。如果没有合理的分配机制，某个失控的微服务可能会瞬间“吃光”所有的 CPU 和内存，导致整个集群雪崩，关键业务随之瘫痪。资源限制与配额管理就是 K8s 里的“资源大管家”，它从应用和命名空间两个维度，确保每个服务都能公平、稳定地获取资源。本文将带你从零开始，彻底搞懂 K8s 中 ResourceQuota 与 LimitRange 的核心概念与配置避坑指南。

什么是资源限制与配额管理

在 K8s 中，资源管理主要依赖两个核心机制，它们各司其职又相互补充：

1. ResourceQuota（资源配额）：作用于 Namespace（命名空间）级别。它就像是给某个部门设定了“总预算”，严格限制该命名空间内所有 Pod 的 CPU/内存总和，以及 Pod、Service 等对象的总数量。
2. LimitRange（限制范围）：作用于 Pod 或 Container 级别。它就像是给每个员工设定了“报销上限和下限”，为容器提供默认的资源请求（Requests）和限制（Limits），并强制执行最小/最大资源边界，防止“裸奔”的容器。

主要作用

在实际的生产环境中，如果不做资源限制，通常会面临以下致命问题：

1. 防止“资源贪吃蛇”：某个未设置 Limits 的 Node.js 服务在流量暴增时，可能会瞬间申请几十 GB 内存，直接把所在节点拖挂，导致同节点的其他业务全部宕机。
2. 保障多租户公平：在共享集群中，开发团队和测试团队需要隔离。ResourceQuota 可以防止测试环境的随意部署抢占生产环境的资源。
3. 保障调度稳定性：如果容器没有设置 Requests，K8s 调度器将无法准确判断节点是否还有剩余资源，导致过度配置（Overcommit）或调度失败。

核心概念与配置

要落地资源管理，必须掌握 ResourceQuota 和 LimitRange 的核心 YAML 配置结构：

1. ResourceQuota（总预算控制）
   用于限制命名空间的聚合资源消耗。
   规范写法：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev
spec:
  hard:
    requests.cpu: "10"      # 命名空间内所有 Pod 的 CPU 请求总和不超过 10 核
    requests.memory: "20Gi" # 内存请求总和不超过 20Gi
    limits.cpu: "20"        # 内存限制总和不超过 20 核
    pods: "50"              # 最多只能创建 50 个 Pod

2. LimitRange（单容器约束）
   用于注入默认值并限制单个容器的资源边界。
   规范写法：

apiVersion: v1
kind: LimitRange
metadata:
  name: dev-limit-range
  namespace: dev
spec:
  limits:
    - type: Container
      default:        # 未指定 limits 时的默认上限
        cpu: "500m"
        memory: "512Mi"
      defaultRequest: # 未指定 requests 时的默认请求值
        cpu: "200m"
        memory: "256Mi"
      max:            # 允许配置的最大值
        cpu: "2"
        memory: "2Gi"
      min:            # 允许配置的最小值
        cpu: "100m"
        memory: "128Mi"

原理解析

这两者的底层控制逻辑是拦截与校验：

1. ResourceQuota 的准入控制：当你在该命名空间下创建新 Pod 时，配额准入控制器会计算新 Pod 的 Requests/Limits 加上当前已使用的资源总量。如果超出了 hard 设定的上限，API Server 会直接拒绝创建，并返回 exceeded quota 错误。
2. LimitRange 的自动注入与校验：当你提交一个没有写 resources 的 Pod 时，LimitRange 控制器会自动将 defaultRequest 和 default 的值注入到容器中。同时，它会检查你手动填写的资源值，如果低于 min 或高于 max，同样会拒绝创建。

最佳实践

掌握了基础配置后，遵循以下最佳实践能让你的集群更加健康：

1. Quota 与 LimitRange 必须配套使用：如果只设了 Quota 没设 LimitRange，用户创建 Pod 时不写 Requests，会导致 Quota 无法正确计算已用资源；如果只设了 LimitRange 没设 Quota，用户可能会创建成百上千个符合规范的 Pod，依然会耗尽集群资源。
2. 结合 HPA 实现弹性伸缩：给 Pod 设置合理的 Requests 和 Limits 后，结合 HPA（水平自动扩缩容），可以让应用在配额允许的范围内，根据 CPU/内存使用率自动增减副本数，而不是无限抢占资源。
3. 合理设置 Requests 与 Limits 的比例：通常建议 Limits 设置为 Requests 的 2 到 4 倍。Requests 决定了调度的基准，Limits 决定了突发流量的天花板。

常见问题

在实际操作中，新手往往容易遇到以下几个典型问题：

1. Pod 创建被拒绝，提示超出配额：解决办法是使用 kubectl describe resourcequota <name> -n <namespace> 查看当前已用资源和硬限制，清理无用 Pod 或申请扩大 Quota。
2. LimitRange 导致应用 OOMKilled：LimitRange 注入的默认内存上限过小，应用一启动就超出限制被杀。解决办法是根据业务实际需求，在 LimitRange 中调大 default (Limits) 的值，或者在 Pod 中显式指定资源。
3. 调度器无法找到合适节点：虽然集群总资源充足，但 Pod 的 Requests 设置过大，导致没有任何单个节点能满足其调度需求。解决办法是合理拆分大应用，或调整集群节点的规格。

总结

资源限制与配额管理是 Kubernetes 保障系统稳定性的基石。通过本文的学习，你应该已经掌握了 ResourceQuota（控总量）与 LimitRange（控单体）的区别、核心配置方法以及联动使用的最佳实践。在实际生产环境中，切记“先定边界，再给预算”，让每个应用都在安全可控的范围内运行，才能真正发挥 K8s 弹性和高可用的优势。