📚 课程目录第2章 Prometheus基础回顾

2. Kubernetes 资源模型基础：Pod 资源请求与限制、QoS 类别、LimitRange 与 ResourceQuota 对象

在 Kubernetes 集群中，资源管理是保障应用稳定性与集群公平性的基石。本章将深入剖析 Pod 级别的资源声明机制、服务质量分类策略，以及命名空间级别的配额控制手段。理解这些概念是后续利用 Prometheus 进行资源瓶颈诊断的前提。

2.1 Pod 资源请求与限制

每个容器在 Pod 定义中都可以声明两类资源参数：requests（请求量）和 limits（上限）。Kubernetes 调度器依据 requests 选择节点，kubelet 则依据 limits 对容器进行资源约束。

参数	语义	调度影响	运行时行为
requests	容器保证能获得的最小资源量	调度器按节点剩余可分配资源 ≥ sum(requests) 筛选节点	kubelet 保证该容器至少能使用 requests 量级的资源
limits	容器允许使用的资源上限	不影响调度决策（除非与 requests 相等）	CPU 通过 CFS 配额限制；内存超过 limits 时容器可能被 OOM Kill

最佳实践：生产环境中建议将 requests 设置为基于历史百分位的稳定基线值，limits 设置为突发峰值上限。两者差值越大，节点超卖比例越高，但 QoS 降级风险也越大。

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "500m"
      limits:
        memory: "512Mi"
        cpu: "1000m"

2.2 QoS 类别：服务质量分级

Kubernetes 根据 Pod 内所有容器的 requests 与 limits 配置组合，自动为每个 Pod 分配一个 QoS 类别。该类别决定了节点资源紧张时 Pod 被驱逐的优先级。

QoS 类别	判定条件	驱逐优先级	典型场景
Guaranteed	所有容器 requests == limits（CPU 和内存均相等）	最低（最后被驱逐）	数据库、关键中间件
Burstable	至少一个容器 requests < limits，且所有容器都设置了 requests	中等	Web 服务、微服务
BestEffort	所有容器均未设置 requests 和 limits	最高（最先被驱逐）	批处理、非关键任务

注意：BestEffort Pod 在节点内存压力下会被立即终止，且不保证任何资源。生产集群应避免运行 BestEffort 工作负载，除非明确接受其不可靠性。

2.3 LimitRange：容器级别的默认值与约束

LimitRange 是命名空间级别的资源策略对象，用于为未显式设置 requests/limits 的 Pod 或容器注入默认值，并强制约束资源范围。

默认值注入：当 Pod 未设置 requests 或 limits 时，LimitRange 自动填充默认值。
范围约束：限制单个容器的最小/最大 requests 和 limits，防止异常配置。
比例约束：强制 limits 与 requests 的最大比值（如 maxLimitRequestRatio）。

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-mem-limits
  namespace: production
spec:
  limits:
  - max:
      cpu: "2"
      memory: "2Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "250m"
      memory: "256Mi"
    maxLimitRequestRatio:
      cpu: 4
      memory: 2
    type: Container

关键指标：在 Prometheus 中可通过 kube_limitrange 指标监控 LimitRange 配置，但更常见的是通过 kube_pod_container_resource_requests 和 kube_pod_container_resource_limits 验证实际生效值。

2.4 ResourceQuota：命名空间级别的资源配额

ResourceQuota 为命名空间设置聚合资源上限，防止单个团队或应用耗尽集群资源。配额可以针对计算资源（CPU/内存）、存储资源（PVC 容量/数量）以及对象数量（Pod/Service/ConfigMap 等）。

配额维度	示例字段	作用范围
计算资源	`requests.cpu`, `limits.memory`	命名空间内所有 Pod 的聚合值
存储资源	`requests.storage`, `persistentvolumeclaims`	PVC 总量与数量
对象数量	`count/pods`, `count/services`	命名空间内各类资源对象数量

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    persistentvolumeclaims: "10"
    count/pods: "50"

常见陷阱：ResourceQuota 仅对创建时生效，不会回收已存在的超配额资源。若命名空间已存在 60 个 Pod，再创建 count/pods: "50" 的配额不会驱逐已有 Pod，但会阻止新 Pod 创建。建议在创建命名空间时即绑定配额。

2.5 资源模型与 Prometheus 监控的关联

理解资源模型后，SRE 可以通过 Prometheus 采集以下关键指标进行瓶颈诊断：

资源使用率 vs 请求量：container_cpu_usage_seconds_total / kube_pod_container_resource_requests_cpu_cores 可计算 CPU 使用率与请求量的比值，识别资源浪费或不足。
配额饱和度：通过 kube_resourcequota 指标监控命名空间配额使用百分比，提前预警配额耗尽。
OOM 事件：container_oom_events_total 直接反映容器因超出内存 limits 被杀死的事件，是 QoS 降级的重要信号。
驱逐事件：kube_pod_status_reason 标记为 Evicted 的 Pod 数量，反映节点资源压力。

诊断示例：当 kube_resourcequota{resource="requests.cpu"} 的 usage/hard 比值超过 0.85 时，应触发告警并评估是否需要扩容命名空间配额或优化 Pod 资源请求。