1. 课程导论：Envoy Sidecar 升级的背景与挑战，容量规划基线校准的重要性

1.1 为什么 Envoy Sidecar 升级如此频繁？

在云原生微服务架构中，Envoy 作为数据面代理，几乎承载了所有东西向流量的转发、负载均衡、可观测性与安全策略执行。随着 Istio 控制面版本迭代、安全漏洞修复、新协议支持（如 HTTP/3）以及性能优化的持续推出，Envoy Sidecar 的升级已成为 SRE 团队最频繁的运维操作之一。

然而，Envoy Sidecar 并非无状态网关——它持有大量连接池、TLS 会话、动态路由表与集群端点信息。升级过程本质上是 原地替换或滚动重启 一个对延迟和连接状态高度敏感的代理进程。任何未经校准的升级操作，都可能导致以下后果：

• 连接中断：旧 Sidecar 进程退出时，未排空的活跃连接被强制断开。
• 流量雪崩：大量 Sidecar 同时重启，导致控制面配置推送风暴，进而引发全集群超时。
• 资源争抢：升级期间 Sidecar 内存/CPU 峰值超出节点预留，影响同节点其他 Pod。
• 配置不一致：新旧 Sidecar 版本对 xDS 资源的解析差异，导致路由黑洞或熔断误判。

1.2 升级过程中的核心挑战

我们将 Envoy Sidecar 升级面临的主要挑战归纳为以下四个维度：

这些挑战并非孤立存在。例如，资源峰值 会加剧 控制面压力，因为节点资源紧张会导致 Pod 启动变慢，进而延长 xDS 订阅窗口，形成恶性循环。

1.3 容量规划基线校准：从“凭感觉”到“可量化”

大多数团队在升级 Envoy Sidecar 时，依赖的是经验值或默认配置：

• “每次只升级 10% 的 Pod”
• “滚动更新间隔设为 30 秒”
• “Sidecar 内存限制设为 512Mi”

这些经验值在集群规模小、流量平稳时或许有效，但在以下场景中会迅速失效：

• 集群节点规格异构（如 4c8g 与 16c32g 混部）
• 业务流量存在明显的潮汐特征（如白天峰值 vs 夜间低谷）
• Sidecar 版本跨度大（如 1.24 → 1.30，配置模型变更）

容量规划基线校准 的核心目标，是在升级前通过可复现的测量手段，建立一组与当前集群状态、流量特征、Sidecar 版本绑定的量化基线，包括：

1. 单 Pod 升级资源开销基线：新 Sidecar 启动时的 CPU 峰值、内存增量、启动耗时。
2. 连接排空时间基线：从收到 SIGTERM 到所有活跃连接关闭的 P99 耗时。
3. 控制面承载基线：单个 istiod 实例在单位时间内能处理的 xDS 订阅请求上限。
4. 节点余量基线：节点在升级窗口内可安全承受的 Sidecar 并发重启数量。

1.4 基线校准在升级流程中的位置

下图展示了 Envoy Sidecar 升级的完整流程，其中 容量规划基线校准 位于“升级前准备”阶段，是决定升级速率与安全边界的核心输入。

1.5 本课程的学习路径

本课程将围绕以下主线展开，帮助 SRE 团队建立一套可工程化的基线校准方法：