4. 升级过程中的资源竞争问题：节点资源不足导致Pod驱逐、调度失败、服务抖动
在 Deployment 滚动升级过程中，新老 Pod 会短暂共存。如果集群节点资源已处于高水位运行，这种“新旧交替”的叠加状态极易引发资源竞争，进而导致 Pod 驱逐、调度失败和服务抖动。本章从资源画像视角拆解这一问题的根因与典型表现。
4.1 资源竞争的三类典型场景
根据生产环境故障案例统计，升级期间的资源竞争主要出现在以下三类场景：
| 场景 | 触发条件 | 直接后果 | 影响范围 |
|---|---|---|---|
| CPU 突发争抢 | 新 Pod 启动时 CPU 峰值超过预留，与老 Pod 争抢时间片 | 应用响应延迟飙升，健康检查超时 | 同节点所有 Pod |
| 内存超配触发 OOM | 新 Pod 初始化内存分配 + 老 Pod 未完全释放，超过节点可分配内存 | Pod 被 OOMKiller 驱逐，部分请求中断 | 被驱逐 Pod 及其依赖服务 |
| 磁盘/网络 IO 抢占 | 新 Pod 拉取镜像、写日志、初始化缓存，与老 Pod 争抢 IO 带宽 | 节点磁盘压力高，Pod 读写延迟增大 | 同节点共享存储卷的 Pod |
关键洞察： 资源竞争的本质是“瞬时需求 > 节点剩余容量”。资源画像的核心任务就是量化这个“瞬时缺口”，并设计预留策略来填补它。
4.2 从 Pod 驱逐到服务抖动的连锁反应
一次资源竞争事件往往不是孤立发生的，它会沿着以下链路传导：
- 节点资源耗尽 — kubelet 触发驱逐机制，按 QoS 优先级驱逐 Pod。
- 被驱逐 Pod 进入 Pending 状态 — 调度器尝试在其他节点重建，但目标节点可能同样资源紧张。
- 调度失败 — 所有节点均无法满足 Pod 的 resource.requests，Pod 卡在 Pending。
- 服务副本数下降 — 被驱逐的 Pod 未及时重建，Service 后端端点减少。
- 流量重分发 — 剩余 Pod 承担更多请求，负载升高，延迟增加。
- 健康检查失败 — 过载 Pod 响应变慢，ReadinessProbe 失败，被从 Service 摘除。
- 雪崩效应 — 更多 Pod 被摘除，服务容量持续下降，最终导致部分请求超时或 5xx。
生产案例： 某在线交易系统在升级时，因节点内存仅剩 200Mi，新 Pod 启动时分配 512Mi 内存，触发 OOMKill 驱逐了 3 个老 Pod。调度器尝试重建时发现集群剩余内存碎片化严重，2 个 Pod 持续 Pending 超过 5 分钟，导致交易接口成功率从 99.95% 骤降至 97.2%。
4.3 资源竞争的核心根因：临时资源缺口
下图展示了升级过程中“新老 Pod 共存”阶段的资源占用变化，以及临时资源缺口如何形成：
4.4 资源竞争的关键影响因素
以下因素会放大或缩小临时资源缺口的严重程度：
| 因素 | 影响方向 | 说明 |
|---|---|---|
| 节点资源利用率 | 正相关 | 利用率越高，剩余缓冲空间越小，缺口越容易触发 |
| Pod 资源预留（requests） | 正相关 | requests 设置越大，新 Pod 启动时申请的“名义资源”越多 |
| Pod 实际使用（limits） | 正相关 | 老 Pod 实际使用接近 limits 时，释放速度慢，共存期更长 |
| 滚动升级策略（maxSurge / maxUnavailable） | 调节因子 | maxSurge 越大，同时存在的新 Pod 越多，叠加资源需求越大 |
| Pod 启动时间 | 正相关 | 启动越慢（镜像拉取、初始化），新旧共存窗口越长 |
| 节点资源碎片化 | 加剧 | 即使总量足够，碎片化也可能导致调度器无法找到连续资源块 |
4.5 资源竞争问题的诊断方法
当升级过程中出现 Pod 驱逐或调度失败时，建议按以下步骤快速定位根因：
- 检查节点事件 —
kubectl describe node <node-name>查看 Eviction 和 DiskPressure 事件。 - 查看被驱逐 Pod 的日志 — 确认 OOMKill 或节点资源不足（NodeHasDiskPressure）原因。
- 分析节点资源快照 — 使用
kubectl top node和kubectl describe node对比升级前后的资源水位。 - 计算临时资源缺口 — 公式：
缺口 = (新 Pod requests × maxSurge) + 老 Pod 实际使用 - 节点剩余可分配。 - 检查调度器日志 — 确认是否有
0/8 nodes are available及具体的 Insufficient cpu/memory 信息。
常见误区： 很多团队只关注节点“总量”是否足够，忽略了“瞬时叠加”效应。即使节点总利用率只有 60%，如果 maxSurge=2 且新 Pod requests 较大，叠加后仍可能超过 100%。资源画像必须考虑“时间窗口内的峰值叠加”，而非简单的静态容量规划。
4.6 资源竞争与资源画像的关联
资源竞争问题直接暴露了现有资源预留策略的不足。从资源画像视角看，核心矛盾在于：
- 静态预留（requests） 无法反映升级期间的动态叠加需求。
- 节点剩余容量 是“瞬时快照”，而非“时间窗口内的可用容量”。
- 驱逐与调度失败 是资源画像失准的最终表现。