3. 灾备场景分析：主备集群切换、跨AZ故障转移、冷备集群启动时的镜像拉取瓶颈
在Kubernetes集群灾备体系中，镜像拉取速度直接决定业务恢复时间。本章聚焦三种典型灾备场景，分析镜像拉取瓶颈的成因与影响，为后续参数调优提供场景依据。
3.1 主备集群切换场景
主集群发生不可逆故障（如控制平面损坏、数据中心级中断）时，需将流量切换至备用集群。备用集群通常保持与主集群相同的Deployment配置，但镜像缓存状态差异巨大。
| 对比维度 | 主集群（故障前） | 备用集群（切换前） |
|---|---|---|
| 镜像缓存 | 已预热，节点本地缓存完整 | 可能为空或仅缓存基础镜像 |
| Pod运行状态 | 运行中，镜像已就绪 | 无Pod运行，镜像未拉取 |
| 拉取触发时机 | Deployment创建时 | 切换命令下发后，批量触发 |
| 并发拉取压力 | 低（逐步创建） | 高（数百Pod同时拉取） |
关键瓶颈：备用集群在切换瞬间产生“镜像拉取风暴”，大量Pod同时执行
kubelet拉取操作，导致镜像仓库带宽耗尽、节点磁盘I/O饱和、容器运行时锁竞争加剧。
3.2 跨AZ故障转移场景
云原生环境下，集群通常跨多个可用区（Availability Zone）部署。当单个AZ发生故障时，Pod需要迁移到其他健康AZ。此场景下镜像拉取瓶颈呈现“局部化”特征。
- AZ内节点镜像差异：不同AZ可能使用不同的节点池，镜像缓存策略不一致，导致故障AZ的Pod迁移后，目标AZ节点需要重新拉取镜像。
- 网络延迟与带宽限制：跨AZ拉取镜像时，流量经过AZ间网络链路，延迟增加（通常2-5ms），带宽受限于AZ间互联带宽（常见1-10Gbps）。
- 镜像仓库就近性：若镜像仓库仅部署在单一AZ，跨AZ拉取将产生额外的网络跳数和出口费用。
实践建议：在跨AZ部署时，优先使用
nodeSelector或topologySpreadConstraints将Pod均匀分布，并配合imagePullPolicy: IfNotPresent减少不必要的拉取。同时考虑在每个AZ部署镜像缓存代理（如Harbor的P2P分发）。
| AZ状态 | 镜像拉取延迟（典型值） | Pod启动时间影响 | 优化方向 |
|---|---|---|---|
| 同AZ拉取 | 100-300ms | 低（<5s） | 节点本地缓存 |
| 跨AZ拉取（同区域） | 500-1500ms | 中（5-15s） | AZ级镜像缓存 |
| 跨AZ拉取（跨区域） | 2000-5000ms | 高（15-60s） | 全局镜像分发 |
3.3 冷备集群启动时的镜像拉取瓶颈
冷备集群长期处于空闲状态，节点上无任何Pod运行，镜像缓存完全过期或不存在。当灾难发生需要激活冷备集群时，所有Deployment的Pod将同时启动，产生极端的镜像拉取压力。
风险提示：冷备集群启动时，若镜像拉取策略配置不当（如
imagePullPolicy: Always），即使镜像层未变化也会触发全量拉取，导致启动时间从分钟级延长到小时级。这是灾备演练中最常见的失败原因之一。
3.3.1 冷备启动的四个阶段
- 调度阶段：kube-scheduler将Pod分配到节点，此时镜像尚未开始拉取。
- 镜像拉取阶段：kubelet根据
imagePullPolicy决定是否拉取，所有节点同时向镜像仓库发起请求。 - 容器创建阶段：镜像拉取完成后，容器运行时创建并启动容器。
- 就绪检查阶段：Pod进入Running状态，等待就绪探针通过。
其中，镜像拉取阶段是冷备启动的瓶颈，通常占总启动时间的70%-90%。
3.4 三种场景瓶颈对比总结
| 场景 | 触发条件 | 并发拉取规模 | 主要瓶颈点 | 恢复时间目标（RTO）影响 |
|---|---|---|---|---|
| 主备集群切换 | 主集群故障 | 高（全量Pod） | 仓库带宽、节点磁盘I/O | 分钟级→小时级 |
| 跨AZ故障转移 | 单AZ故障 | 中（故障AZ的Pod） | AZ间网络延迟、镜像缓存缺失 | 分钟级 |
| 冷备集群启动 | 灾难激活 | 极高（全量Pod同时启动） | 仓库带宽、节点并发拉取能力 | 小时级 |
核心结论：三种灾备场景的镜像拉取瓶颈本质相同——并发拉取请求超过镜像仓库和节点网络的承载能力。但冷备集群启动的冲击最为剧烈，因为所有Pod的拉取时间窗口完全重叠。后续章节将围绕
imagePullPolicy、prePull策略、kubelet并发参数等展开调优，以缓解上述瓶颈。