3. 节点资源画像概念:什么是资源画像?静态画像与动态画像的区别

节点资源画像(Node Resource Profiling)是容量规划的基础数据建模过程,它通过采集、分析和建模节点上各类资源(CPU、内存、磁盘、网络)的实际使用模式,生成一个能够反映节点资源消耗特征的结构化描述。这个描述不是简单的瞬时快照,而是对节点在特定时间窗口内资源行为的抽象表达。

3.1 资源画像的核心定义

在 Kubernetes 集群中,资源画像回答三个关键问题:

  • 节点实际消耗了多少资源?——区别于 Request/Limit 的声明值,关注真实利用率。
  • 资源消耗的模式是什么?——周期性波动、突发峰值、持续高负载还是空闲震荡。
  • 剩余可调度容量有多少?——考虑安全缓冲后的真实可用余量。
核心公式: 节点可调度容量 = 节点总容量 − 系统预留 − 已分配资源 − 动态波动缓冲 − 误差预算

资源画像的输出通常包含以下维度:

维度 描述 典型指标
CPU 画像 CPU 使用率的时间序列分布 P50/P95/P99 利用率、核·秒消耗
内存画像 内存占用趋势与驻留特征 RSS、Working Set、Page Cache 占比
磁盘 I/O 画像 读写吞吐量与 IOPS 模式 iowait%、磁盘延迟、队列深度
网络画像 带宽使用与连接数特征 入/出带宽、TCP 连接数、重传率

3.2 静态画像 vs 动态画像

根据数据采集方式和建模时间窗口的不同,资源画像分为静态画像和动态画像两种范式。两者的核心差异在于是否考虑资源消耗的时间维度和波动特征。

一句话区分: 静态画像回答"节点最多能装多少",动态画像回答"节点实际用了多少、怎么用的、还剩多少安全余量"。

3.2.1 静态画像(Static Profiling)

静态画像基于节点规格和静态配置计算资源容量,不依赖历史监控数据。它通常用于初始容量评估和硬件选型阶段。

  • 数据来源: 节点规格(CPU 核数、内存大小)、系统预留配置(kube-reserved、system-reserved)、Pod 的 Request 总和。
  • 计算方式: 可分配资源 = 总容量 − 系统预留 − Σ(Request)。
  • 优点: 计算简单、无需历史数据、适合新集群规划。
  • 缺点: 忽略实际使用模式,无法反映突发、空闲、周期波动;容易高估或低估真实容量。

3.2.2 动态画像(Dynamic Profiling)

动态画像基于节点在连续时间窗口内的真实监控数据,通过统计分析和时序建模生成资源消耗的概率分布。它是误差预算台账的核心数据源。

  • 数据来源: Prometheus/cAdvisor 采集的节点利用率时序数据(通常 30~90 天窗口)。
  • 计算方式: 对利用率序列做分位数统计(P50/P95/P99)、波动性分析(标准差、变异系数)、周期性检测(日/周模式)。
  • 优点: 反映真实负载特征,支持容量预测和风险量化。
  • 缺点: 依赖监控基础设施,需要足够长的历史数据,计算复杂度较高。

3.3 静态画像与动态画像的对比

对比维度 静态画像 动态画像
数据基础 节点规格 + 静态配置 历史监控时序数据
时间维度 无(瞬时快照) 有(时间窗口 + 分位数)
波动感知 不感知 感知峰值、谷值、周期性
误差预算 无法计算 可量化(波动缓冲 + 风险余量)
适用场景 硬件选型、初始规划 日常容量管理、扩缩容决策
更新频率 低(节点规格不变则不更新) 高(每日/每周自动重算)

3.4 两种画像的协作关系

在实际容量规划中,静态画像和动态画像并非二选一,而是形成分层协作关系:

  1. 静态画像提供容量上限的硬约束(天花板)。
  2. 动态画像在硬约束内刻画实际使用模式与波动区间。
  3. 误差预算在动态画像的基础上,叠加安全缓冲和风险容忍度,形成可操作的调度边界。
常见误区: 只做静态画像会导致"看起来还有 30% 容量,实际一调度就 OOM";只做动态画像而忽略静态上限,则可能过度承诺导致节点过载。两者必须结合使用。

3.5 资源画像概念关系图

下图展示了静态画像、动态画像与误差预算之间的数据流和决策链路:

节点资源画像概念关系图 静态画像 节点规格 + 静态配置 可分配容量 = 总容量 − 预留 − Σ(Request) 动态画像 历史监控时序数据 P50/P95/P99 利用率 + 波动分析 误差预算台账 波动缓冲 + 风险余量 + 安全边界 可调度容量 = 动态基线 − 误差预算 提供容量上限约束 提供波动基线 容量规划决策 扩缩容 / 调度策略 / 预算分配 静态画像:硬约束天花板 动态画像:真实使用模式

3.6 实际案例:从静态到动态的演进

假设一个 8C16G 的节点,系统预留 0.5C1G,已调度 Pod 的 Request 总和为 5C10G:

  • 静态画像结果: 可分配 = 8 − 0.5 − 5 = 2.5C;16 − 1 − 10 = 5G。结论:剩余 2.5C5G。
  • 动态画像结果(30 天数据): CPU P95 利用率 85%(6.8C),内存 P95 利用率 78%(12.5G)。实际剩余远小于静态计算值。
  • 误差预算介入: 动态基线 6.8C + 波动缓冲 0.5C = 7.3C 已占用,剩余安全余量仅 0.7C,而非静态的 2.5C。
关键启示: 静态画像给出的是"理论剩余",动态画像揭示的是"实际剩余",误差预算则定义了"安全剩余"。三者逐层收敛,最终形成可执行的容量边界。