3、滚动升级基础概念：滚动升级策略、蓝绿部署与金砂雀发布的区别，为何选择滚动升级
在 Prometheus 辅助节点（Sidecar/Agent）的运维生命周期中，版本升级是最频繁且风险最高的操作之一。选择错误的升级策略可能导致指标采集中断、告警风暴甚至历史数据丢失。本节将系统对比三种主流升级策略，并解释为何滚动升级更适合 Prometheus 辅助节点的容量规划场景。
3.1 三种升级策略核心对比
| 维度 | 滚动升级 (Rolling Update) | 蓝绿部署 (Blue/Green) | 金丝雀发布 (Canary Release) |
|---|---|---|---|
| 资源占用 | 低（无需额外副本） | 高（需双倍资源） | 中（需少量额外副本） |
| 回滚速度 | 慢（逐节点回滚） | 快（流量切换） | 中（逐步回退） |
| 流量切换粒度 | 节点级 | 全量级 | 百分比级 |
| 数据一致性风险 | 低（单节点影响） | 低（全量切换） | 中（混合版本共存） |
| 适用场景 | 无状态/轻状态服务 | 关键业务全量验证 | 新功能灰度验证 |
容量规划视角： 滚动升级在资源消耗上最符合容量规划基线构建的需求——它不需要预留双倍资源池，可以在现有容量预算内完成版本迭代，避免因升级导致资源超分。
3.2 为何选择滚动升级
Prometheus 辅助节点具有以下特征，使得滚动升级成为最匹配的策略：
- 无状态采集代理： 辅助节点不存储历史数据，仅负责抓取和转发，单节点故障不会导致数据永久丢失。
- 水平扩展架构： 采集任务通过服务发现均匀分布，滚动升级期间部分节点离线不影响整体采集覆盖率。
- 资源预算固定： 容量规划基线要求资源利用率在升级期间不突破阈值，滚动升级的增量资源需求几乎为零。
- 回滚可控： 若升级后指标异常，只需回滚单个节点，不影响其他正常节点。
避坑提示： 如果辅助节点启用了本地 WAL（Write-Ahead Log）缓存或本地时序数据库，滚动升级前必须确保数据已 flush 到下游存储，否则升级期间可能丢失最近 1-2 个采集周期的指标数据。
3.3 滚动升级流程与容量基线关系
下图展示了滚动升级过程中节点状态变化与容量基线的对应关系：
3.4 滚动升级的容量基线约束
在 Prometheus 辅助节点滚动升级过程中，容量规划基线需要关注以下三个核心约束：
- 并发离线数约束： 同时升级的节点数不能超过集群冗余度。例如，若采集任务副本数为 3，则最多允许 1 个节点同时离线。
- 资源峰值约束： 升级期间剩余节点需要承接离线节点的采集任务，CPU 和内存使用率不得超过基线阈值的 120%。
- 时间窗口约束： 单节点升级（下线→替换→验证→恢复）必须在 Prometheus 默认 scrape_interval（通常 15s-30s）的整数倍内完成，避免采集周期错位。
实践建议： 在构建容量规划基线时，建议将滚动升级的“并发数”作为可调参数纳入基线模型。初始值设为 1，后续根据实际资源余量和升级耗时动态调整。每次升级前自动计算当前集群冗余度，确保升级操作不突破基线红线。