3. 升级场景分类：原地升级、滚动升级、蓝绿升级、金丝雀发布对容量的影响
Envoy Sidecar 升级策略的选择直接决定了升级期间代理实例的可用性、流量迁移路径以及集群整体的资源消耗峰值。不同的升级模式对容量规划基线的冲击差异显著，若未提前校准，极易引发连接耗尽、内存超限或请求超时雪崩。
3.1 四种升级模式的核心差异
| 升级模式 | 实例替换方式 | 流量中断窗口 | 资源峰值倍数 | 回滚复杂度 |
|---|---|---|---|---|
| 原地升级 | 同一 Pod 内直接重启 Envoy 进程 | 毫秒～秒级（取决于热重启） | 1.0x（无额外副本） | 低（回退旧版本二进制） |
| 滚动升级 | 按批次逐步替换旧 Pod | 批次间无中断，单 Pod 秒级 | 1.0x～1.25x（取决于 maxSurge） | 中（需回滚 Deployment） |
| 蓝绿升级 | 完整部署新版本集群后切换流量 | 切换瞬间（DNS/负载均衡生效） | 2.0x（蓝绿两套同时运行） | 高（切换回旧集群） |
| 金丝雀发布 | 小比例新版本实例逐步承接流量 | 无中断（灰度流量比例控制） | 1.1x～1.5x（取决于金丝雀比例） | 低（缩容金丝雀即可） |
容量规划基线校准要点： 原地升级关注单实例重启期间的连接耗尽与内存抖动；滚动升级需校准 maxSurge 与 maxUnavailable 对集群总容量的叠加效应；蓝绿升级必须预留 2 倍资源池；金丝雀发布则需精确计算灰度比例下的连接数分布与内存增量。
3.2 原地升级（In-Place Upgrade）
原地升级直接对运行中的 Envoy 进程执行热重启（Hot Restart），新进程启动后通过共享内存继承旧进程的监听套接字与连接状态。此模式对容量规划的影响最小，但存在两个关键风险：
- 内存双倍峰值： 热重启期间新旧两个 Envoy 进程短暂共存（通常 1～3 秒），内存消耗为正常值的 1.8～2.2 倍。若原实例已处于 70% 内存水位，双进程叠加可能触发 OOM。
- 连接耗尽窗口： 旧进程在移交连接后进入 draining 状态，若上游端点响应缓慢，draining 超时（默认 5 秒）内未完成的请求将被强制断开。
3.3 滚动升级（Rolling Upgrade）
滚动升级通过 Kubernetes Deployment 的 maxSurge 和 maxUnavailable 参数控制升级节奏。容量规划需重点校准以下参数组合：
关键公式： 滚动升级期间集群最大并发实例数 = 期望副本数 × (1 + maxSurge)。若期望副本数为 10，maxSurge=25%，则最大并发实例数为 12.5（向上取整为 13），资源需求增加 30%。
- maxSurge 决定资源峰值： 每多一个 surge 实例，集群总内存和 CPU 消耗就增加一份。建议 maxSurge 不超过 25%，避免资源池过度膨胀。
- maxUnavailable 决定流量迁移速度： 允许同时不可用的实例比例越高，流量迁移到剩余实例的集中度越大。若 maxUnavailable=25%，剩余 75% 实例需承载 100% 流量，单实例 QPS 上升 33%。
- 连接迁移风暴： 每批旧 Pod 被驱逐时，其上的长连接会同时断开并重连到剩余 Pod，可能引发瞬时连接数激增。
3.4 蓝绿升级（Blue-Green Deployment）
蓝绿升级同时运行两套完整的 Envoy 集群（蓝色旧版、绿色新版），通过负载均衡器一次性切换流量。容量规划的核心挑战在于资源翻倍：
- 资源需求翻倍： 升级期间集群总实例数为正常值的 2 倍。若原集群使用 100 个 Pod，蓝绿期间需 200 个 Pod 的资源配额。
- 流量切换瞬间冲击： 切换瞬间所有流量涌入绿色集群，若绿色集群未提前预热连接池和缓存，可能触发瞬时超时。
- 回滚成本： 若切换后发现问题，需将流量切回蓝色集群。蓝色集群在此期间必须保持完整运行状态，不能提前缩容。
容量规划陷阱： 蓝绿升级期间，Kubernetes 集群的节点资源利用率可能从 60% 飙升至 120%（超卖场景），导致节点压力过大触发 Pod 驱逐。建议提前通过 Cluster Autoscaler 扩容节点池，或预留 30% 节点资源缓冲。
3.5 金丝雀发布（Canary Release）
金丝雀发布通过 Service Mesh 的流量路由规则（如 Istio VirtualService 权重路由）将小比例流量导向新版 Envoy 实例。容量规划需精确计算灰度比例下的资源增量：
| 金丝雀比例 | 新增实例数（基准 100 Pod） | 总资源增量 | 单实例连接数变化 |
|---|---|---|---|
| 5% | 5 个新 Pod | +5% | 旧实例连接数减少 5%，新实例连接数 = 旧实例 × 5% |
| 10% | 10 个新 Pod | +10% | 旧实例连接数减少 10%，新实例连接数 = 旧实例 × 10% |
| 20% | 20 个新 Pod | +20% | 旧实例连接数减少 20%，新实例连接数 = 旧实例 × 20% |
| 50% | 50 个新 Pod | +50% | 新旧实例连接数均分，各占 50% |
容量规划基线校准： 金丝雀发布的总资源消耗 = 基准资源 × (1 + 金丝雀比例)。建议金丝雀比例不超过 20%，避免资源浪费。同时需监控新实例的连接数分布是否均匀，防止流量路由策略导致部分实例过载。
3.6 升级模式选择矩阵
| 评估维度 | 原地升级 | 滚动升级 | 蓝绿升级 | 金丝雀发布 |
|---|---|---|---|---|
| 资源消耗 | 低（无额外副本） | 中（maxSurge 控制） | 高（2 倍资源） | 低～中（按比例） |
| 流量中断风险 | 中（热重启窗口） | 低（批次切换） | 低（瞬间切换） | 极低（灰度控制） |
| 回滚速度 | 快（秒级） | 中（分钟级） | 快（秒级） | 快（秒级） |
| 容量规划复杂度 | 低 | 中 | 高 | 中 |
| 适用场景 | 低流量、非关键服务 | 中等流量、常规发布 | 高流量、关键服务 | 新版本验证、A/B 测试 |
选择升级模式时，需结合集群资源水位、服务 SLA 要求以及回滚能力综合决策。容量规划基线应针对所选模式提前校准，确保升级期间不触发资源瓶颈或服务降级。