📚 课程目录第4章容量规划基础

4. 容量规划基础：资源类型、资源请求与限制、服务质量等级

在 Kubernetes 与云原生架构中，容量规划的核心是对计算节点与工作负载的资源模型进行精确建模。本章聚焦三大基础模块：资源类型（CPU、内存、存储、网络）、资源请求与限制（Requests & Limits）以及服务质量（QoS）等级。理解这三者是后续进行 Deployment 水位评估、集群扩缩容策略制定的前提。

4.1 核心资源类型与可压缩性

Kubernetes 将资源分为可压缩资源与不可压缩资源两类，这一分类直接影响调度决策与过载行为。

资源类型	单位	可压缩性	过载行为	容量规划关注点
CPU	cores / millicores (m)	可压缩	限流（Throttling），进程不终止	CPU 时间片分配、突发负载容忍度
内存	bytes (Mi, Gi)	不可压缩	OOM Kill，Pod 被驱逐	内存泄漏保护、Swap 策略
临时存储	bytes (Mi, Gi)	不可压缩	Pod 驱逐、节点压力	日志、容器层写放大
网络带宽	bps / pps	部分可压缩	丢包、延迟增加	CNI 插件带宽限制、NUMA 亲和性

容量规划提示： 内存和存储是“硬边界”，一旦超限直接导致 Pod 重启或驱逐；CPU 超限仅表现为性能下降。因此，在设置水位线时，内存的预留缓冲比例通常应高于 CPU。

4.2 资源请求（Requests）与限制（Limits）

Requests 用于调度决策，Limits 用于运行时压制。两者组合形成四种经典配置模式，直接影响集群的资源利用率和稳定性。

4.2.1 配置模式对比

模式	Requests	Limits	调度行为	运行时行为	适用场景
Guaranteed	等于 Limits	等于 Requests	严格按 Requests 调度	无突发能力，受 Limits 硬限制	数据库、关键中间件
Burstable	小于 Limits	大于 Requests	按 Requests 调度	可突发至 Limits，受 CPU Throttle	微服务、Web 应用
BestEffort	未设置	未设置	无调度保证	无限制，节点压力时优先驱逐	批处理、非生产任务
仅设置 Limits	默认等于 Limits	显式设置	按 Limits 调度（浪费资源）	同 Guaranteed	不推荐，易造成碎片

4.2.2 典型 Deployment 配置示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  template:
    spec:
      containers:
      - name: app
        image: order-service:1.0
        resources:
          requests:
            cpu: "500m"        # 0.5 核
            memory: "512Mi"
          limits:
            cpu: "1000m"       # 1 核
            memory: "1Gi"

常见误区： 将 Requests 设置得过高会导致节点资源碎片化，降低装箱率；将 Limits 设置得过低且无突发余量，会导致频繁 CPU Throttling，引发接口延迟抖动。建议通过压测获取 P99 资源使用基线，再按 1.2~1.5 倍设置 Requests。

4.3 服务质量（QoS）等级与驱逐优先级

Kubernetes 根据 Pod 的 Requests/Limits 配置自动划分 QoS 等级。当节点出现内存压力时，kubelet 按 QoS 等级从低到高逐级驱逐 Pod。

4.3.1 三级 QoS 模型

4.3.2 驱逐顺序与水位线关系

kubelet 基于 eviction-hard 与 eviction-soft 阈值触发驱逐，驱逐顺序严格按 QoS 等级执行：

BestEffort Pod 最先被驱逐
Burstable Pod 按内存使用率与 Requests 的偏差排序，偏差越大越先被驱逐
Guaranteed Pod 最后被驱逐，仅当节点内存耗尽且无更低 QoS Pod 可驱逐时

  容量规划策略： 核心业务应使用 Guaranteed QoS，确保在节点压力下不被驱逐；离线任务或批处理作业使用 BestEffort，利用闲置资源运行，节点压力时自动让出资源。

4.4 资源模型与容量规划的关系

在服务目录平台中，每个 Deployment 的 资源画像 由以下公式决定：

节点可调度资源 = 节点总容量 - 系统预留 - kubelet 预留 - eviction 阈值
Pod 资源占用 = sum(所有容器 Requests)
节点水位 = (已分配 Requests / 节点可调度资源) × 100%

当节点水位超过 80% 时，建议触发扩容或 Pod 重调度，避免突发流量导致节点过载。

4.4.1 资源类型与容量规划矩阵

资源类型	规划指标	推荐水位上限	监控指标	扩缩容触发条件
CPU	CPU Requests 分配率	80%	container_cpu_usage_seconds_total	连续 5 分钟 > 85%
内存	内存 Requests 分配率	75%	container_memory_working_set_bytes	连续 3 分钟 > 80%
临时存储	节点磁盘使用率	70%	node_filesystem_avail_bytes	低于 20% 可用空间
网络	Pod 网络带宽使用率	60%	container_network_transmit_bytes_total	接近 CNI 限制上限

4.5 本章小结

资源类型 决定了过载后的行为：CPU 限流，内存/存储驱逐。
Requests & Limits 是调度与运行时压制的双重边界，合理配置可提升集群装箱率 20%~40%。
QoS 等级 是节点压力下的保护优先级，核心服务必须配置为 Guaranteed。
在服务目录平台中，水位评估 应基于 Requests 分配率而非实际使用率，因为调度决策依赖 Requests。