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

2. K8s资源模型基础：Pod、Node、Namespace、ResourceQuota、LimitRange的核心概念与关系

在Kubernetes集群中，资源管理是一切成本分摊与容量规划的基石。理解Pod、Node、Namespace、ResourceQuota、LimitRange这五个核心对象的定义及其相互关系，是后续进行资源碎片整理和成本核算的前提。本章将逐一拆解这些概念，并揭示它们如何协同工作，构成K8s的资源管控体系。

2.1 核心资源对象定义

对象	层级	核心职责	成本分摊视角
Pod	工作负载	最小调度单元，包含一个或多个容器，共享网络/存储	资源消耗的直接计量单位（CPU/内存/存储请求）
Node	基础设施	集群中的物理机或虚拟机，提供计算资源池	成本产生的物理载体（实例单价 × 数量）
Namespace	逻辑隔离	虚拟集群分区，用于多租户、环境隔离	成本归集与分摊的边界（部门/项目/环境）
ResourceQuota	策略	限制Namespace级别的总资源上限（CPU/内存/PVC等）	防止资源滥用，保障成本预算不超支
LimitRange	策略	约束单个Pod/容器的资源默认值与边界（min/max/default）	规范Pod规格，减少资源碎片与浪费

关键认知： Pod是成本消耗的“原子”，Node是成本产生的“源头”，Namespace是成本分摊的“账本”，ResourceQuota和LimitRange则是控制成本的“阀门”。

2.2 资源模型关系图

下图展示了五个核心对象在K8s集群中的层级关系与交互逻辑。从底层的Node资源池，到顶层的Namespace策略管控，形成了一个完整的资源治理闭环。

2.3 资源请求与限制（Requests & Limits）

Pod的资源声明是成本分摊的核心依据。每个容器都可以设置CPU和内存的requests（预留值）和limits（上限值）。

Requests：调度器依据此值选择Node，确保Node剩余资源 ≥ Pod总requests。这是成本分摊的“承诺消耗”。
Limits：kubelet依据此值对容器进行资源限制（CPU throttling / OOM kill）。这是成本分摊的“最大消耗”。

  成本分摊原则： 实际成本分摊通常基于 requests 而非 limits，因为 requests 决定了资源预留量，是集群容量规划的真实依据。limits 仅用于防止突发流量导致节点过载。

2.4 资源配额与默认值策略

ResourceQuota和LimitRange是Namespace级别的策略工具，直接决定了资源分配的规范性与可控性。

2.4.1 ResourceQuota 示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-team-quota
  namespace: dev
spec:
  hard:
    requests.cpu: "10"        # 该Namespace下所有Pod的CPU requests总和不超过10核
    requests.memory: "20Gi"   # 内存requests总和不超过20Gi
    limits.cpu: "20"          # CPU limits总和不超过20核
    limits.memory: "40Gi"     # 内存limits总和不超过40Gi
    persistentvolumeclaims: "5"  # PVC数量不超过5个
    pods: "50"                # Pod数量不超过50个

2.4.2 LimitRange 示例

apiVersion: v1
kind: LimitRange
metadata:
  name: dev-container-limits
  namespace: dev
spec:
  limits:
  - max:                      # 单个容器资源上限
      cpu: "2"
      memory: "4Gi"
    min:                      # 单个容器资源下限
      cpu: "0.1"
      memory: "128Mi"
    default:                  # 未设置limits时的默认值
      cpu: "0.5"
      memory: "512Mi"
    defaultRequest:           # 未设置requests时的默认值
      cpu: "0.25"
      memory: "256Mi"
    type: Container

常见陷阱： 如果Namespace同时设置了ResourceQuota和LimitRange，但Pod未设置requests/limits，LimitRange会自动注入默认值，然后ResourceQuota会校验总量。若默认值导致总量超限，Pod将无法创建。因此，先配置LimitRange，再配置ResourceQuota是推荐顺序。

2.5 资源碎片产生的根源

理解资源模型后，可以清晰定位碎片产生的三个主要原因：

原因	描述	影响
Pod规格不匹配	Pod requests远小于Node单核/单内存单元，导致Node上剩余资源无法组合成新的Pod	Node资源利用率低，但无法调度更多Pod
LimitRange缺失	未设置默认requests，部分Pod未声明资源，调度器按0处理，实际运行时却占用大量资源	节点过载风险增加，成本分摊失真
ResourceQuota过松	Namespace配额远大于实际需求，导致Pod分散部署，无法形成资源聚合	Node数量增加，整体成本上升

2.6 资源模型与成本分摊的映射关系

在成本分摊实践中，资源模型提供了清晰的映射路径：

Node成本（如云服务器实例费用）是集群总成本。
Pod requests 是资源消耗的权重因子。
Namespace 是成本归集账户。
分摊公式：Namespace成本 = 集群总成本 × (Namespace内所有Pod requests总和 / 集群所有Pod requests总和)。

进阶思考： 对于DaemonSet（如日志采集、监控Agent）等系统组件，其Pod通常分布在所有Node上，成本应作为“集群基础设施开销”单独分摊，而非计入业务Namespace。这需要在资源模型中通过标签（labels）或专用Namespace进行区分。