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