📚 课程目录第2章 K8s资源模型与配额基础

2. K8s 资源模型与配额基础：Pod、Container 资源请求与限制、ResourceQuota 对象、LimitRange 对象、命名空间资源隔离

2.1 核心资源抽象：从 Container 到 Pod

Kubernetes 的资源调度与隔离，始于对每个工作负载粒度的精确描述。系统将资源管理的原子单位定义为 Container，而 Pod 则作为一组共享网络和存储的 Container 的调度单元。理解这两层资源声明，是后续所有配额与调优的基石。

2.1.1 Container 资源声明：Requests 与 Limits

每个 Container 在 Spec 中必须（或强烈建议）声明两类资源参数：

Requests（请求量）：调度器用于节点选择的“保证量”。Kubelet 会确保节点上所有 Pod 的 Requests 总和不超过节点可分配容量。
Limits（上限量）：运行时 Cgroups 施加的硬限制。当进程试图使用超过 Limits 的 CPU 时会被节流；超过内存 Limits 时可能触发 OOM Kill。

  关键原则：Requests ≤ Limits。当只设置 Limits 时，Requests 默认等于 Limits；当只设置 Requests 时，Limits 默认为无上限（可能引发资源争抢）。

以下是一个典型的 Container 资源声明示例：

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

2.1.2 Pod 级别的资源聚合

Pod 的资源请求与限制，是其内部所有 Container 对应字段的 累加和。调度器、ResourceQuota 以及节点压力驱逐均以 Pod 级别聚合值为判断依据。

资源维度	Pod Requests 计算方式	Pod Limits 计算方式
CPU	所有 Container CPU Requests 之和	所有 Container CPU Limits 之和
Memory	所有 Container Memory Requests 之和	所有 Container Memory Limits 之和
Ephemeral Storage	所有 Container Ephemeral Storage Requests 之和	所有 Container Ephemeral Storage Limits 之和

容量调优视角：过度声明 Requests 会导致节点资源碎片化，降低装箱率；过度声明 Limits 则可能造成资源浪费或突发 OOM。建议基于历史监控数据（P99 使用量）设定 Requests，并保留 20%-50% 的 Limits 余量。

2.2 命名空间级资源管控：ResourceQuota

ResourceQuota 是 Kubernetes 在命名空间级别实施资源总量控制的策略对象。它限制了命名空间内所有 Pod（及其他资源）的资源消耗总和，防止单个租户或团队耗尽集群资源。

2.2.1 ResourceQuota 核心字段

一个 ResourceQuota 可以同时限制 计算资源（CPU、内存）、存储资源（PVC 容量）和 对象数量（Pod、Service、ConfigMap 等）。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    persistentvolumeclaims: "10"
    pods: "20"
    configmaps: "30"

2.2.2 资源配额作用域（Scope）

ResourceQuota 支持通过 scopes 字段对特定类型的 Pod 进行差异化限制，常见作用域包括：

作用域名称	匹配条件	典型用途
`BestEffort`	Pod 内所有 Container 均未设置 Requests 和 Limits	限制低优先级批处理任务
`NotBestEffort`	Pod 中至少有一个 Container 设置了 Requests 或 Limits	保障型工作负载的配额独立管控
`Terminating`	Pod 设置了 `activeDeadlineSeconds`	限制 CI/CD 构建任务的总资源
`NotTerminating`	Pod 未设置 `activeDeadlineSeconds`	常驻服务（Deployment/StatefulSet）的配额

常见陷阱：当命名空间同时存在多个 ResourceQuota 对象时，Kubernetes 会应用所有 Quota 的 交集约束（即最严格的组合）。务必确保不同 Quota 之间没有冲突的硬限制，否则 Pod 创建可能被意外拒绝。

2.3 细粒度约束：LimitRange

ResourceQuota 控制的是“总量”，而 LimitRange 控制的是“个体”。LimitRange 在命名空间级别为 Pod 或 Container 设置默认的 Requests/Limits，以及最小/最大约束。

2.3.1 LimitRange 的典型配置

apiVersion: v1
kind: LimitRange
metadata:
  name: container-limits
  namespace: team-a
spec:
  limits:
  - max:
      cpu: "2"
      memory: "2Gi"
    min:
      cpu: "100m"
      memory: "128Mi"
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    type: Container

2.3.2 LimitRange 与 ResourceQuota 的协同关系

两者共同构成命名空间资源治理的“双保险”：

LimitRange 确保每个 Pod/Container 的资源声明在合理范围内，防止单个 Pod 声明过大或过小。
ResourceQuota 确保命名空间内所有 Pod 的资源总和不超过预算。

  最佳实践：先部署 LimitRange 设定默认值和边界，再部署 ResourceQuota 设定总量上限。这样即使用户未显式声明资源，系统也会自动注入默认值，避免 Quota 校验失败。

2.4 命名空间资源隔离机制

Kubernetes 通过命名空间实现逻辑上的资源隔离，但物理资源（CPU、内存、磁盘）在默认情况下是共享的。真正的隔离需要结合以下三层机制：

配额隔离（ResourceQuota）：防止一个命名空间耗尽集群资源，影响其他命名空间。
网络隔离（NetworkPolicy）：控制命名空间之间以及命名空间内部的流量。
运行时隔离（RuntimeClass / NodeSelector）：通过节点亲和性或专用运行时，将敏感工作负载调度到独占节点。

以下 SVG 图展示了命名空间资源隔离的完整架构：

2.5 资源模型与配额校准实战要点

在容量调优项目中，资源模型与配额的校准通常遵循以下步骤：

步骤	操作内容	关键输出
1. 基线采集	通过 Prometheus 或 Metrics Server 采集每个 Pod 的 CPU/Memory 实际使用量（P50/P95/P99）	每个工作负载的资源使用画像
2. Requests 校准	将 Container Requests 设置为 P95 使用量 × 安全系数（通常 1.1~1.3）	新的 Pod Spec 资源声明
3. Limits 设定	Limits 设置为 Requests 的 1.5~2 倍，防止突发流量导致 OOM	Limits 与 Requests 比例策略
4. LimitRange 部署	为每个命名空间创建 LimitRange，设定默认值和边界	LimitRange YAML 清单
5. ResourceQuota 部署	根据团队预算和集群总容量，设定命名空间配额	ResourceQuota YAML 清单
6. 持续验证	监控 Quota 使用率，设置告警（使用率 > 80%）	Grafana 仪表盘 + Alertmanager 规则

校准口诀：“Requests 保调度，Limits 防失控；LimitRange 定规矩，ResourceQuota 管总量；先采基线再调参，持续观测不放松。”

通过以上资源模型与配额基础的建设，平台团队能够实现从“粗放式资源分配”到“精细化容量管理”的转变，为后续的节点自动扩缩容、成本分摊和 SLA 保障奠定数据基础。