2. Kubernetes 资源模型:Pod 资源请求与限制、QoS 等级、资源配额(ResourceQuota)、LimitRange

Kubernetes 的资源模型是集群容量规划与成本优化的基石。理解 Pod 的资源声明、服务质量等级以及命名空间级别的资源管控机制,是 SRE 实现精细化资源调度、避免资源争抢、控制基础设施成本的前提。本章将深入剖析这四个核心概念及其在成本优化中的实际应用。

2.1 Pod 资源请求(Requests)与限制(Limits)

每个 Pod 中的容器都可以声明两类资源参数:Requests(请求量)和 Limits(上限)。这两者决定了 Pod 被调度时的资源保证以及运行时的资源使用边界。

参数 语义 调度影响 运行时影响 成本含义
Requests 容器保证能获得的最小资源量 调度器依据 Node 剩余可分配资源(Allocatable - Requests)决定 Pod 放置位置 CPU 按权重分配;内存不足时优先驱逐超出 Requests 的 Pod 集群实际预留的资源量,是成本核算的基准
Limits 容器允许使用的最大资源量 不影响调度决策 CPU 通过 CFS 配额限制;内存超过 Limits 触发 OOM Kill 控制突发资源消耗,防止单个 Pod 影响邻居
成本优化要点: 在成本模型中,Requests 是集群实际“预留”并计费的核心指标。过度设置 Requests 会导致资源碎片和浪费;设置过低则可能引发调度失败或稳定性风险。建议基于历史百分位(如 P95/P99)设定 Requests,并配合 Vertical Pod Autoscaler(VPA)动态调整。

2.2 QoS 等级:资源保障与驱逐优先级

Kubernetes 根据 Pod 中所有容器的 Requests 与 Limits 配置组合,自动为 Pod 分配一个 QoS(服务质量)等级。该等级决定了当节点资源紧张时,哪些 Pod 会被优先驱逐。

Pod QoS 等级判定流程与驱逐优先级 容器配置组合 Guaranteed Requests == Limits Burstable 至少一个容器 Requests < Limits BestEffort 未设置 Requests / Limits 驱逐优先级(从低到高):Guaranteed → Burstable → BestEffort 说明: • Guaranteed Pod 在资源争抢时最后被驱逐,适合数据库、关键中间件。 • BestEffort Pod 最先被驱逐,适合批处理、非关键任务,可有效利用碎片资源。
成本与稳定性权衡: 将非关键工作负载设置为 BestEffort 或低 Burstable 等级,可以充分利用集群碎片资源,提升整体资源利用率,降低单位 Pod 成本。但必须配合 PodDisruptionBudget 和合理的驱逐策略,避免大规模驱逐影响业务。

2.3 资源配额(ResourceQuota)

ResourceQuota 是命名空间级别的资源总量限制机制,用于防止单个团队或项目过度消耗集群资源,是实现多租户成本隔离与治理的核心工具。

2.3.1 核心配额类型

配额类型 作用范围 示例 成本控制价值
计算资源 所有 Pod 的 requests.cpu / requests.memory / limits.cpu / limits.memory 总和 requests.cpu: "100" 直接限制命名空间可预留的 CPU/内存总量,是成本预算的硬边界
存储资源 所有 PVC 的 requests.storage 总和 requests.storage: "500Gi" 控制持久化存储成本,防止无限制申请云盘
对象数量 Pod、Service、ConfigMap 等资源对象的最大数量 count/pods: "200" 防止 API Server 压力过大,间接控制管理成本

2.3.2 ResourceQuota 配置示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "40"          # 总 CPU 请求不超过 40 核
    requests.memory: "80Gi"     # 总内存请求不超过 80 Gi
    limits.cpu: "80"            # 总 CPU 上限不超过 80 核
    limits.memory: "160Gi"      # 总内存上限不超过 160 Gi
    requests.storage: "500Gi"   # 总存储请求不超过 500 Gi
    count/pods: "200"           # Pod 数量不超过 200 个
    count/services: "20"        # Service 数量不超过 20 个
成本优化实践: 在成本治理中,建议为每个业务命名空间设置 requests.cpu 和 requests.memory 配额,并定期监控配额使用率。当使用率接近 80% 时触发告警,提前进行扩容或优化。这相当于为每个团队设定了“资源预算上限”,避免成本失控。

2.4 LimitRange:默认资源与边界约束

LimitRange 在命名空间级别为 Pod 和容器设置默认的 Requests/Limits 以及最小/最大约束。它解决了两个关键问题:

  • 默认值注入: 为未显式声明资源的 Pod 自动设置默认 Requests/Limits,避免产生 BestEffort Pod 导致的资源不可控。
  • 边界约束: 限制单个容器能申请的最大或最小资源,防止异常配置导致资源浪费或调度失败。

2.4.1 LimitRange 配置示例

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: team-a
spec:
  limits:
  - max:                         # 单个容器资源上限
      cpu: "4"
      memory: "8Gi"
    min:                         # 单个容器资源下限
      cpu: "100m"
      memory: "128Mi"
    default:                     # 未设置 Limits 时的默认值
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:              # 未设置 Requests 时的默认值
      cpu: "200m"
      memory: "256Mi"
    type: Container

2.5 四者协同:资源管控全景图

Requests/Limits、QoS、ResourceQuota、LimitRange 共同构成了 Kubernetes 资源管控的完整体系。它们在不同层级发挥作用,相互配合实现资源保障、隔离与成本控制。

Kubernetes 资源管控四层模型 第1层:LimitRange(命名空间级默认与边界) 为未声明资源的 Pod 注入默认值,约束单容器资源上下限 第2层:Requests & Limits(Pod 级资源声明) 定义每个容器的资源保证量(Requests)与使用上限(Limits) 第3层:QoS 等级(自动推导的驱逐优先级) 根据 Requests/Limits 组合自动判定,决定节点资源争抢时的驱逐顺序 第4层:ResourceQuota(命名空间级总量硬限制) 限制命名空间内所有 Pod 的资源总和,实现多租户资源预算与成本隔离 成本优化关键: 通过 LimitRange 设置合理默认值 → 精确声明 Requests/Limits → 利用 QoS 等级差异化保障 → 用 ResourceQuota 锁定预算上限。

2.6 成本优化最佳实践

  1. 精细化 Requests 设置: 基于历史监控数据(如 Prometheus 容器资源使用率),使用 VPA 或自定义算法为每个工作负载设置合理的 Requests,避免过度预留。
  2. 差异化 QoS 策略: 关键业务使用 Guaranteed 等级保障稳定性;离线任务、批处理作业使用 BestEffort 等级利用碎片资源,提升整体集群利用率。
  3. ResourceQuota 预算管理: 为每个命名空间设置基于 Requests 的资源配额,并定期生成配额使用率报告,识别资源浪费或超预算的团队。
  4. LimitRange 默认值治理: 强制所有命名空间配置 LimitRange,确保未声明资源的 Pod 不会意外成为 BestEffort,避免资源不可控。
  5. 定期审计与调整: 每月分析集群资源利用率与配额使用情况,识别 Requests 远高于实际使用的工作负载,推动优化调整。
核心结论: Kubernetes 资源模型不是简单的配置项,而是 SRE 进行容量规划与成本优化的第一性原理。Requests 决定预留成本,QoS 决定稳定性成本,ResourceQuota 决定预算上限,LimitRange 决定默认行为。四者协同,才能构建一个既稳定又经济的云原生基础设施。