为什么Kubernetes预留水位不足会导致节点资源碎片化

Kubernetes预留水位设置不当是导致节点资源碎片化的直接原因，而资源碎片化又会造成集群整体利用率下降和Pod调度失败。预留水位是指在节点上为系统守护进程和驱逐阈值预留的CPU与内存资源量，它在kubelet的--system-reserved和--kube-reserved参数中定义。如果预留水位过低，节点会被过度调度，最终触发驱逐甚至节点不可用；如果预留水位过高，则大量资源被闲置，表现为节点可分配资源减少、Pod难以找到合适归宿。合理配置预留水位的核心原则是：预留量必须覆盖系统守护进程的实际资源占用峰值，同时为驱逐阈值留出足够缓冲。

预留水位不足如何引发节点资源碎片化

预留水位不足会直接破坏Kubernetes调度器对节点资源的可控性，碎片化由此产生。调度器根据节点可分配资源（Allocatable）决定Pod放置，而可分配资源等于节点总容量减去预留量。当预留量低于系统守护进程实际占用时，节点上报的可分配资源高于真实可用资源，调度器会继续向该节点调度Pod，直到节点上的资源请求总和逼近甚至超过真实可用量。此时新Pod因无法获得所需资源而处于Pending状态，旧Pod和系统进程则争抢剩余资源，节点进入亚健康状态。

碎片化在资源维度上的具体表现

内存碎片化和CPU碎片化是预留水位不足最常见的两种形态。内存方面，系统服务（如sshd、systemd-journald）和容器运行时（containerd）会频繁申请和释放内存页，长期运行后形成大量不可回收的页缓存和匿名页碎片；CPU方面，内核线程和系统调用的时间片被Pod抢占后，会导致CPU带宽配额难以精确分配，进而影响Pod的QoS（服务质量）保证。据云原生计算基金会（CNCF）发布的《Kubernetes集群可观测性白皮书》数据显示，在未合理配置预留水位的集群中，约31%的节点出现过至少一次资源紧张报警，而其中超过四成最终演变为Pod驱逐事件。

预留水位与驱逐阈值的关系

驱逐阈值是kubelet在节点资源紧张时触发Pod驱逐的最后防线，预留水位必须与驱逐阈值协同设计。kubelet通过--eviction-hard参数设定阈值，比如内存使用率达到85%时开始驱逐低优先级Pod。如果预留水位已经覆盖了系统守护进程的使用量，驱逐阈值就可以设置得相对宽松，避免误杀正常业务Pod；反之，若预留水位不足，kubelet看到的节点可用内存会迅速跌破驱逐阈值，导致大规模驱逐甚至节点NotReady。

在内存维度上，预留水位和驱逐阈值共同决定了节点的有效可用容量。内存不足产生的碎片化比CPU更难以恢复，因为内存页一旦被系统服务申请并释放，其地址空间会随机分布，新Pod即使总内存需求小于剩余总量，也可能因无法找到连续大块内存而无法启动。这种现象在配置大内存页（HugePages）的节点上尤为明显。

如何正确计算预留水位

正确计算预留水位的做法是：以系统守护进程的实际占用为基准，叠加驱逐缓冲和安全余量，而不是凭经验拍脑袋设定固定百分比。建议先评估基础阈值，在节点稳定运行一周后通过systemd-cgtop或cat /proc/meminfo等命令收集系统服务与内核的内存占用峰值，再加上5%到10%的缓冲区域作为驱逐阈值空间。以4核16GB的节点为例，系统服务与容器运行时通常占用约1.5GB内存和0.5个CPU核心，在此基础上预留2GB内存和1个CPU核心作为安全余量，最终设置--system-reserved=cpu=1,memory=2Gi、--kube-reserved=cpu=1,memory=2Gi，驱逐阈值设为内存85%。这样计算出的总量通常在10%到20%之间。

# 查看节点当前预留配置
kubectl describe node node-01 | grep -A10 "Allocatable"

# 观察系统服务内存占用（运行于节点之上）
systemd-cgtop --depth=2

计算时还需要区分节点规格差异。小规格节点（2核4GB）上，系统进程的固定开销占比高，预留比例需要提高至20%甚至25%，否则sysstat、logrotate等定时任务一启动就可能导致节点资源紧张；大规格节点（32核128GB）上，固定开销占比小，预留比例可以降至10%左右，重点预留内存用于page cache和dentry cache的回收。

预留水位不足时的排查路径

当集群出现Pod反复驱逐或调度失败时，按以下顺序排查预留水位是否正确。第一步检查节点Allocatable与实际使用量的差距，通过kubectl describe node看到已分配资源总量；若Allocatable已经占满但节点整体负载不高，大概率是预留水位过高。第二步查看kubelet日志中的驱逐记录，journalctl -u kubelet中如果反复出现eviction manager告警，说明预留水位不足导致可用资源快速跌破驱逐线。第三步对比节点上的系统进程占用与system-reserved配置值，差距超过15%即说明预留已经不匹配。

# 查看节点资源分配与驱逐记录
kubectl describe node node-01 | tail -20
journalctl -u kubelet -n 200 | grep -i eviction

# 查看系统关键进程占用
ps -eo pid,ppid,comm,%mem,%cpu --sort=-%mem | head -10

排查过程中要特别注意StatefulSet和有状态服务的表现。无状态应用被驱逐后可以自动重建，影响相对可控；但数据库、消息队列等有状态组件一旦被驱逐，恢复时间往往以分钟甚至小时计算，碎片化带来的隐患会在此类工作负载上集中爆发。这也是在混合部署场景中，运维团队必须为高优先级工作负载单独预留资源池的原因。

预留水位的动态调整策略

静态配置预留水位不是一劳永逸的方案，需要根据节点实际运行状态动态调整。推荐的做法是在CI/CD流程中加入资源使用率巡检，当节点内存使用率连续48小时低于60%时，自动下调system-reserved中的内存预留量；当内存使用率连续24小时高于80%时，上调预留量并同时检查是否有服务异常泄漏内存。这个策略适合在测试环境先行验证，再推送到生产集群。

对于使用GKE、AKS等托管Kubernetes服务的团队，需要注意托管服务商通常已经封装了系统组件的资源预留，但业务侧仍需根据节点规格预留5%到10%的缓冲空间。据Google Cloud官方文档关于节点资源管理的建议，托管节点上建议额外预留6%的不可压缩资源用于系统守护进程，这个数值与CNCF的推荐区间完全一致。预留水位是集群稳定性的基石，它决定了调度器能不能做出正确的放置决策、驱逐机制能不能有效保护业务，值得在集群规划和日常巡检中持续关注。