2. 资源争抢问题全景：蓝绿发布中资源争抢的典型场景、CPU/内存/网络IO争抢的表现形式
2.1 资源争抢的本质与触发条件
蓝绿发布的核心风险在于：新旧两套完整服务栈在切换窗口期内共存于同一集群。当集群资源预留不足或HPA配置过于激进时，两套Pod集合会同时竞争有限的CPU、内存和网络带宽，导致服务质量（SLO）急剧下降。
关键认知： 资源争抢不是“资源不够”的简单问题，而是“瞬时双倍负载叠加”与“调度器/内核资源隔离失效”共同作用的结果。MTTR复盘的首要任务就是区分这两种根因。
2.2 CPU资源争抢：表现形式与诊断指标
CPU争抢是蓝绿发布中最常见、最容易被误判的资源瓶颈。当新旧Pod同时运行且总CPU请求超过节点可分配量时，CFS（Completely Fair Scheduler）配额机制会强制限流，导致所有Pod的CPU节流（Throttling）显著上升。
| 表现维度 | 正常状态 | 争抢状态 | 关键观测指标 |
|---|---|---|---|
| CPU Throttling | < 1% 时间片被节流 | > 10% 时间片被节流 | container_cpu_cfs_throttled_seconds_total |
| 请求延迟 | P99 < 100ms | P99 > 500ms，出现毛刺 | 应用侧P99延迟 + CPU使用率曲线 |
| 节点负载 | 节点CPU利用率 40-60% | 节点CPU利用率 > 85%，持续抖动 | node_cpu_seconds_total 模式: system + user 双高 |
| 调度延迟 | runqueue 深度 < 2 | runqueue 深度 > 5，上下文切换激增 | node_procs_running + node_context_switches_total |
MTTR复盘要点： 在蓝绿发布切换后的前5分钟，如果观察到
container_cpu_cfs_throttled_seconds_total 出现阶梯式跃升且与Pod启动时间对齐，即可判定为CPU资源争抢。此时应优先检查 节点可分配CPU总量 vs 两套Pod的CPU Request总和。
2.3 内存资源争抢：OOM与Swap的连锁反应
内存争抢比CPU争抢更具破坏性，因为它直接导致OOM Kill或内存回收（kswapd）引发的全局性能抖动。在蓝绿发布场景中，新旧Pod同时加载缓存、建立连接池，内存使用量往往在短时间内翻倍。
- OOM Kill 直接表现： Pod被内核强制终止，Kubernetes Event中出现
OOMKilling事件。被kill的Pod不一定是资源使用最高的，而是内核根据oom_score选中的“牺牲品”。 - kswapd 间接表现： 节点内存压力触发内核回收页缓存，导致所有Pod的I/O延迟飙升（即使它们本身不直接做磁盘I/O）。表现为
node_vmstat_pswpin/pswpout非零。 - HPA误判风险： 内存使用率上升触发HPA扩容，但新Pod启动后进一步加剧内存争抢，形成“扩容-更争抢-再扩容”的正反馈循环。
| 内存争抢阶段 | 典型指标 | 对业务的影响 | 诊断命令/查询 |
|---|---|---|---|
| 内存压力上升 | 节点内存利用率 > 80% | 延迟轻微上升，GC频率增加 | kubectl top nodes |
| kswapd 活跃 | node_vmstat_pswpin > 0 |
磁盘I/O突增，P99延迟翻倍 | cat /proc/meminfo | grep -i swap |
| OOM Kill 发生 | Pod 重启计数 +1 | 部分请求失败（5xx），连接断开 | kubectl describe pod <pod> 查看 Last State |
常见误区： 很多团队在复盘时只关注“哪个Pod被OOM Kill了”，却忽略了 kswapd 导致的全局性能劣化。实际上，kswapd 造成的“无差别攻击”往往比单个Pod的OOM影响范围更广，因为它会拖慢节点上所有Pod的I/O路径。
2.4 网络IO资源争抢：带宽与连接数的双重瓶颈
网络IO争抢在蓝绿发布中容易被忽视，但它的影响往往最直接——用户请求的延迟和错误率会立刻上升。网络争抢分为两个层面：带宽争抢（吞吐量）和 连接数争抢（并发连接/端口耗尽）。
2.4.1 带宽争抢的典型表现
- TCP重传率飙升： 正常 < 0.5%，争抢时 > 5%。可通过
node_netstat_Tcp_RetransSegs观测。 - 吞吐量下降： 虽然链路利用率高，但有效吞吐量（Goodput）反而下降，因为大量带宽被重传消耗。
- 尾部延迟恶化： 大包请求（如文件上传、大JSON响应）受影响最严重，P99延迟可能从200ms飙升至2s以上。
2.4.2 连接数争抢的典型表现
- conntrack 表溢出： 内核日志出现
nf_conntrack: table full, dropping packet。新连接被直接丢弃，导致客户端收到“Connection refused”或超时。 - 端口耗尽： 节点作为NAT网关时，
net.ipv4.ip_local_port_range范围内的端口被占满，无法发起新出站连接。 - 连接建立失败率上升： 应用层表现为“上游连接失败”或“连接池获取超时”。
MTTR复盘关键数据源： 在蓝绿发布复盘时，务必拉取以下三个时间序列做对齐分析：
①
②
③
将这三个指标与发布切换时间点对齐，可以快速定位网络争抢的根因是带宽还是连接数。
①
node_netstat_Tcp_RetransSegs（TCP重传）②
node_nf_conntrack_entries（连接跟踪表使用量）③
container_network_receive_bytes_total / transmit_bytes_total（Pod级带宽使用）将这三个指标与发布切换时间点对齐，可以快速定位网络争抢的根因是带宽还是连接数。
2.5 资源争抢的连锁效应与故障传播路径
三种资源争抢很少独立发生，它们通常会形成一条故障传播链：
- CPU争抢 → 应用处理能力下降 → 请求排队 → 内存中积压请求对象 → 内存使用率上升
- 内存争抢 → kswapd 回收页缓存 → 磁盘I/O增加 → 网络数据包处理延迟 → TCP重传增加
- 网络争抢 → 重传和超时 → 客户端重试 → 更多连接建立 → conntrack 表溢出 → 新连接被丢弃
这条传播路径意味着：复盘时不能只看“最终表现”（比如Pod OOM Kill），而要从时间轴上找到第一个偏离基线的指标。通常CPU Throttling是第一个信号，其次是内存压力，最后才是网络丢包。
| 故障阶段 | 时间窗口（典型值） | 首要观测指标 | 次要影响指标 |
|---|---|---|---|
| CPU争抢起始 | 切换后 0-2 min | CPU Throttling 跃升 | 请求延迟开始上升 |
| 内存压力累积 | 切换后 2-5 min | 节点内存利用率 > 85% | GC暂停时间增加 |
| 网络IO劣化 | 切换后 5-10 min | TCP重传率 > 3% | 错误率（5xx）上升 |
| 系统级雪崩 | 切换后 10-15 min | OOM Kill / conntrack 溢出 | 部分Pod CrashLoopBackOff |
复盘口径建议： 在MTTR复盘报告中，将上述四个阶段的时间窗口与实际的监控曲线叠加，标注出“第一个偏离基线的时间点”。这个时间点就是 资源争抢的真正起点，也是HPA参数优化和资源预留策略改进的关键依据。