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

2. Kubernetes 资源模型基础：Pod、Deployment、ReplicaSet 的资源请求与限制

在 Kubernetes 集群中，资源管理是保障应用稳定性和集群效率的核心机制。对于 eBPF 节点池容量规划而言，理解 Pod、Deployment 和 ReplicaSet 的资源模型是计算节点承载能力的前提。本章将系统梳理这三层抽象的资源请求（Requests）与限制（Limits）机制，并揭示它们如何共同决定节点池的容量边界。

2.1 资源请求与限制的核心概念

Kubernetes 通过 Requests 和 Limits 两个维度管理容器的 CPU 和内存资源：

属性	含义	调度影响	运行时行为
Requests	容器保证能获得的最小资源量	调度器依据节点剩余可分配资源 ≥ 所有 Pod Requests 之和来决策	Kubelet 保证容器至少获得 Requests 指定的资源
Limits	容器允许使用的资源上限	不影响调度决策（除非启用 Guaranteed QoS）	CPU 限流（CFS quota），内存超限触发 OOM Kill

  容量规划关键原则： 节点池的“可调度容量”由所有已运行 Pod 的 Requests 之和决定，而非 Limits。Limits 仅控制突发行为，超配场景下节点可能因 Limits 总和超过节点容量而出现资源争抢。

2.2 Pod 级别的资源声明

Pod 是 Kubernetes 最小的调度单元，资源声明定义在 spec.containers[].resources 字段中。一个 Pod 的总资源需求是其所有容器资源请求的累加值。

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo-pod
spec:
  containers:
  - name: app
    image: nginx:1.25
    resources:
      requests:
        memory: "256Mi"
        cpu: "500m"
      limits:
        memory: "512Mi"
        cpu: "1000m"
  - name: sidecar
    image: fluentd:v1.16
    resources:
      requests:
        memory: "128Mi"
        cpu: "100m"
      limits:
        memory: "256Mi"
        cpu: "200m"

该 Pod 的总资源请求为：CPU 600m（500m + 100m），内存 384Mi（256Mi + 128Mi）。调度器在节点选择时，会检查节点剩余可分配资源是否 ≥ 600m CPU 和 384Mi 内存。

2.3 Deployment 与 ReplicaSet 的资源继承

Deployment 通过管理 ReplicaSet 来维护期望的 Pod 副本数。资源声明定义在 Deployment 的 PodTemplate 中，ReplicaSet 自动继承该模板，最终每个 Pod 都使用相同的资源规格。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        resources:
          requests:
            cpu: "250m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "256Mi"

该 Deployment 的 资源需求总量 为：

CPU Requests：3 × 250m = 750m
内存 Requests：3 × 128Mi = 384Mi
CPU Limits：3 × 500m = 1500m
内存 Limits：3 × 256Mi = 768Mi

容量规划要点： 当使用 HPA（Horizontal Pod Autoscaler）时，Deployment 的副本数会动态变化。节点池容量规划必须考虑 HPA 的最大副本数场景，即 maxReplicas × perPodRequests 作为预留容量上限。

2.4 资源模型与 QoS 等级

Requests 和 Limits 的组合方式决定了 Pod 的 QoS（服务质量）等级，直接影响节点过载时的驱逐优先级：

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

eBPF 节点池容量规划警示： 如果节点池中混合部署了不同 QoS 等级的 Pod，在内存压力下 BestEffort 和 Burstable Pod 会先被驱逐。容量规划时建议为关键 eBPF 监控组件（如 Cilium Agent、Falco）设置 Guaranteed QoS，确保它们在资源争抢时不被驱逐。

2.5 资源模型与节点容量计算

节点池的容量规划公式如下：

节点可调度容量 = 节点总容量 - kube-reserved - system-reserved - eviction-threshold

节点池可用容量 = Σ(节点可调度容量) - 已分配 Requests 总和

最大可调度 Pod 数 = min(
    floor(节点可调度CPU / 单Pod CPU Requests),
    floor(节点可调度内存 / 单Pod 内存 Requests),
    节点最大Pod数限制（默认110）
)

以下 SVG 图展示了从 Deployment 到节点资源消耗的完整链路：

2.6 资源超配与节点池容量风险

在生产环境中，运维人员常通过 资源超配（Overcommitment）提高节点利用率，即 Limits 总和超过节点容量。这种做法在 eBPF 节点池中需要特别谨慎：

超配策略	CPU 超配效果	内存超配风险	eBPF 场景建议
Requests = Limits（无超配）	无 CPU 争抢，性能稳定	无 OOM 风险	eBPF 数据面组件（Cilium、Falco）
Requests < Limits（CPU 超配）	CPU 限流，延迟增加	内存超限可能 OOM	非实时 eBPF 分析任务
仅设置 Requests（无 Limits）	可突发使用空闲 CPU	内存无上限，节点 OOM 风险高	不推荐用于 eBPF 节点池

  eBPF 节点池容量规划最佳实践： 对于运行 eBPF 数据面组件（如 Cilium CNI、Falco 安全监控）的节点，建议设置 Requests == Limits（Guaranteed QoS），避免因 CPU 限流导致数据包处理延迟，或因内存超限导致监控进程被 OOM Kill。

2.7 资源模型在节点池容量规划中的实际应用

基于上述资源模型，节点池容量规划可归纳为以下步骤：

确定 Pod 资源基线： 通过压力测试获取每个 Deployment 中 Pod 的稳定资源消耗，设置合理的 Requests 值（通常为 P99 或 P95 使用量）。
计算 Deployment 资源需求： DeploymentRequests = replicas × perPodRequests，考虑 HPA 最大副本数。
汇总节点池总需求： 所有 Deployment 的资源需求之和 + 系统预留（kube-system 组件）+ 缓冲余量（通常 20%~30%）。
选择节点规格： 根据总需求选择节点实例类型，确保单节点可调度容量 ≥ 最大单个 Pod 的 Requests，避免 Pod 因节点资源不足而无法调度。
验证调度可行性： 使用 kube-scheduler 的模拟调度或 descheduler 工具验证节点池能否承载目标工作负载。

以下 SVG 图展示了节点池容量规划的资源聚合流程：

2.8 常见资源模型配置错误与排查

典型错误 1： 只设置 Limits 不设置 Requests。调度器会默认 Requests = Limits，导致节点资源被过度预留，实际利用率低下。
典型错误 2： 所有容器使用相同的资源规格，未考虑 sidecar 容器的资源消耗，导致 Pod 实际需求被低估。
典型错误 3： 忽略 Init 容器的资源请求。Init 容器执行期间也会占用节点资源，其 Requests 同样计入节点容量计算。

排查命令示例：

# 查看节点资源分配情况
kubectl describe node <node-name> | grep -A 10 "Allocated resources"

# 查看 Pod 实际资源使用量（用于校准 Requests）
kubectl top pod -n <namespace>

# 查看 Deployment 的 HPA 配置
kubectl get hpa -n <namespace> -o yaml