4. Deployment 水位定义：实际资源使用量 / 节点可分配资源量；水位阈值与健康区间
在 Kubernetes 集群中，Deployment 水位 是衡量节点资源紧张程度的核心指标。它反映了运行在节点上的 Pod（由 Deployment 管理）实际消耗的资源与节点可分配资源之间的比例关系。准确理解并监控这一水位，是保障集群稳定性和资源利用率的前提。
4.1 水位计算公式
Deployment 水位的计算基于节点维度的资源视图，其核心公式如下：
Deployment 水位 = (节点上所有 Deployment 管理的 Pod 实际资源使用量之和) / (节点可分配资源量)其中：
- 实际资源使用量：通过 eBPF 或 cAdvisor 采集的 Pod 实时 CPU（核·秒）和内存（字节）消耗。eBPF 可提供更细粒度的、去除了内核缓存抖动的“真实使用量”。
- 节点可分配资源量：
Node.Status.Allocatable，即节点总容量减去系统预留（kube-reserved）和驱逐阈值（eviction-hard）后的资源。这是调度器判断能否调度新 Pod 的依据。
关键区别： 水位计算使用的是 实际使用量，而非 Pod 的
requests 或 limits。requests 是调度时的静态承诺，而实际使用量才是动态负载的真实反映。eBPF 的优势在于能精确捕获后者，避免因“超卖”导致的水位误判。
4.2 水位阈值与健康区间
为了将水位量化为可操作的运维动作，我们定义了三个关键阈值，将水位划分为四个健康区间。下表总结了各区间对应的状态与建议操作：
| 区间名称 | 水位范围 | 状态描述 | 建议操作 |
|---|---|---|---|
| 安全区 | 0% ~ 60% | 资源充裕，系统运行平稳 | 常规监控，可考虑适当降低副本数以节省成本 |
| 关注区 | 60% ~ 80% | 资源开始紧张，存在突发风险 | 检查 Pod 资源规格是否合理，评估是否需要扩容 |
| 警戒区 | 80% ~ 90% | 高负载运行，节点压力显著 | 触发预置告警，准备执行 Pod 驱逐或节点扩容 |
| 危险区 | 90% ~ 100% | 接近资源上限，系统不稳定风险极高 | 立即介入，强制驱逐低优先级 Pod 或手动扩容节点 |
注意： 上述阈值是通用推荐值。实际生产环境中，应根据业务容忍度、节点规格（如是否使用 Burstable 实例）以及 eBPF 采集的抖动幅度进行调整。例如，对于延迟敏感型服务，建议将警戒线下调至 70%。
4.3 水位与资源维度的关系图
下图展示了 Deployment 水位在节点资源模型中的位置，以及它与 capacity、allocatable、requests 和实际使用量之间的关系：
4.4 水位计算示例
假设一个节点具有以下配置：
- 节点总 CPU：8 核
- 系统预留：1 核
- 节点可分配 CPU：7 核
- 节点上 Deployment Pod 实际使用 CPU：5.6 核
则 CPU 水位计算如下：
CPU 水位 = 5.6 核 / 7 核 = 80%根据上表，该节点处于 警戒区。此时应检查 Pod 的 CPU 使用模式，确认是否存在突发峰值，并评估是否需要增加节点或调整 Pod 的 resource limits。
4.5 水位监控的 eBPF 优势
传统基于 cAdvisor 的水位监控存在两个主要缺陷：
- 采样延迟：cAdvisor 默认 15s 采样一次，无法捕捉毫秒级突发。
- 统计口径偏差：cAdvisor 报告的内存使用量包含内核缓存（如 page cache），这部分在内存压力下可被回收，并非真正的“使用中”内存。
eBPF 通过在内核态挂载 tracepoint 或 kprobe，能够：
- 以微秒级精度采集 CPU 调度和内存分配事件。
- 区分“匿名页”与“文件页”，剔除可回收缓存，得到更真实的 工作集大小（Working Set Size, WSS）。
这使得基于 eBPF 的 Deployment 水位能够更早、更准确地反映节点压力，避免因缓存抖动导致的误告警。
实践要点： 在配置水位告警时，建议将 eBPF 采集的 WSS 作为内存水位的分子，而非 cAdvisor 的 RSS（常驻内存集）。这能有效减少因文件缓存波动引发的“假阳性”告警。