3. 资源画像概念：什么是资源画像（Resource Profiling）？静态画像与动态画像的区别
资源画像（Resource Profiling）是指通过采集、分析和建模工作负载在运行时的资源使用行为，形成一组能够表征其资源需求特征的多维标签或模型。在 Kubernetes 与 Cilium 结合的云原生环境中，资源画像的目标是回答一个核心问题：“这个 Pod 到底需要多少 CPU、内存、网络带宽和 I/O？”
传统的资源分配方式往往依赖开发者的经验值或压力测试的峰值快照，而资源画像则通过持续观测和统计建模，提供更精确、更动态的资源需求描述。它是实现 Pod 级容量规划校准的数据基础。
3.1 资源画像的核心要素
一个完整的资源画像通常包含以下四个维度：
| 维度 | 描述 | 典型指标 |
|---|---|---|
| CPU 画像 | 描述 Pod 对 CPU 时间片的需求模式 | CPU 使用率（均值/P99）、节流率、突发频率 |
| 内存画像 | 描述 Pod 对物理内存和虚拟内存的占用模式 | RSS、Working Set、Page Fault 频率、OOM 风险 |
| 网络画像 | 描述 Pod 的网络吞吐、连接数和延迟特征 | 带宽吞吐量、TCP 连接数、丢包率、RTT |
| 存储/I/O 画像 | 描述 Pod 对磁盘读写和文件系统操作的依赖 | IOPS、吞吐量、I/O 延迟、inode 使用 |
关键认知：资源画像不是一次性的“快照”，而是一个随时间演进的动态模型。在 Cilium eBPF 的加持下，网络和系统调用维度的画像可以做到纳秒级精度，这是传统 cAdvisor 或 metrics-server 无法比拟的。
3.2 静态画像 vs 动态画像
根据数据采集方式和模型更新策略，资源画像可分为静态画像和动态画像两大类。两者的核心区别在于：画像是否随工作负载的实际运行状态自适应调整。
| 对比维度 | 静态画像 | 动态画像 |
|---|---|---|
| 数据来源 | 离线分析、基准测试、历史日志 | 实时 eBPF 采集、Prometheus 指标、Kubernetes Metrics API |
| 更新频率 | 按版本/发布周期更新（天/周级） | 持续更新（秒/分级） |
| 模型精度 | 粗粒度，通常取峰值或均值 | 细粒度，支持分位数、时间序列、突发模式 |
| 对突发流量的响应 | 滞后，无法感知瞬时抖动 | 实时感知，可触发 HPA 或资源校准 |
| 典型应用场景 | 容量规划初稿、资源配额基线 | Pod 级动态调整、Cilium 网络策略优化 |
| 局限性 | 容易过度配置或配置不足 | 需要持续的计算和存储开销 |
实践要点：在 Cilium eBPF 联动场景中，我们通常采用“静态基线 + 动态校准”的混合策略。静态画像提供初始的 request/limit 建议，动态画像则通过 eBPF 实时追踪系统调用、网络包和内存分配，持续修正画像模型，最终输出 Pod 级的容量规划校准建议。
3.3 静态画像与动态画像的对比流程
下面的 SVG 图展示了静态画像与动态画像在数据流和决策链路上的核心差异：
3.4 为什么动态画像更适合 Cilium eBPF 联动？
Cilium 基于 eBPF 的数据面能够以极低的开销捕获每个 Pod 的：
- 系统调用级行为：通过 tracepoint 和 kprobe 追踪 open/read/write/send/recv 等调用频率和延迟。
- 网络流级特征：通过 XDP 和 TC hook 捕获每个数据包的源/目的 IP、端口、协议、大小、时间戳。
- 内存分配模式：通过 cgroup 级别的 memory 事件追踪 Page Cache 命中率、OOM 触发频率。
这些细粒度的观测数据天然适合构建动态画像模型。静态画像无法利用这些实时信号，因此只能提供“一刀切”的基线建议，而动态画像可以做到：
- 按需校准：当 eBPF 检测到某个 Pod 的网络突发流量超过历史 P95 阈值时，动态画像自动触发一次资源校准。
- 趋势预测：基于时间序列分析，预测未来 1 小时/24 小时的资源需求变化。
- 异常检测：当画像模型发现资源使用模式偏离基线时，发出告警并建议调整。
常见误区：不要认为动态画像可以完全替代静态画像。静态画像在以下场景仍然不可或缺：新服务上线无历史数据时、合规审计需要固定基线时、以及作为动态画像的“安”防止模型漂移。最佳实践是两者结合，静态提供下限，动态提供弹性。
3.5 资源画像在容量规划中的角色
在《Cilium eBPF 与资源画像联动的 Pod 级容量规划校准》课程体系中，资源画像处于数据采集与建模层，是连接 eBPF 原始观测与容量规划决策的桥梁。下图展示了资源画像在整个架构中的位置：