3. 服务网格架构回顾：Istio/Envoy 数据面与控制面交互、Sidecar 代理模式、mTLS 通信原理
在深入网格升级窗口的异常样本分析之前，必须重新建立对服务网格核心架构的共识。Istio 作为最广泛采用的服务网格实现，其架构可清晰划分为控制面（Control Plane）与数据面（Data Plane）两个层次。理解这两者之间的交互机制、Sidecar 代理的注入与流量劫持原理，以及基于 SPIFFE 的 mTLS 通信模型，是后续根因定位的基石。
3.1 控制面与数据面交互模型
Istio 控制面核心组件为 istiod，它整合了 Pilot、Citadel、Galley 三大功能。数据面则由注入到每个 Pod 中的 Envoy 代理构成。控制面通过 xDS 协议（Discovery Service APIs） 向数据面推送动态配置。
关键交互链路： istiod（控制面）通过 gRPC 流式推送 xDS 配置 → Envoy（数据面）接收并热更新路由、监听器、集群、端点及证书。
升级窗口影响： 在网格升级期间，istiod 与 Envoy 之间的 xDS 流可能中断或推送不一致的配置版本，导致 Envoy 持有过期路由或缺失端点，这是产生“流量黑洞”或“503 错误”的典型根因。
3.2 Sidecar 代理模式与流量劫持
Sidecar 模式是服务网格的核心部署形态。Envoy 代理以独立容器形式注入到业务 Pod 中，与业务容器共享网络命名空间。通过 iptables 规则 透明地劫持所有进出流量，业务容器无需感知代理的存在。
| 流量方向 | iptables 链 | 劫持目标 | 典型端口 |
|---|---|---|---|
| 入站（Inbound） | PREROUTING → ISTIO_INBOUND | 重定向到 Envoy 入站端口 | 15006 |
| 出站（Outbound） | OUTPUT → ISTIO_OUTPUT | 重定向到 Envoy 出站端口 | 15001 |
| 管理/监控 | — | Envoy 管理接口 | 15000 |
| 健康检查 | ISTIO_INBOUND 排除 | 绕过代理直通应用 | 应用端口 |
升级风险点： 网格升级过程中，如果 iptables 规则在重启 Envoy 时被重置或未正确应用，会导致流量绕过代理直接到达业务容器，破坏 mTLS 和策略执行，造成安全漏洞或路由错误。
3.3 mTLS 通信原理与 SPIFFE 身份
Istio 中的 mTLS（双向 TLS）不仅加密通信，更重要的是通过 SPIFFE（Secure Production Identity Framework for Everyone） 标准实现工作负载身份认证。每个 Envoy 代理都持有一个由 Citadel 签发的 X.509 证书，其 SAN（Subject Alternative Name）字段包含 SPIFFE 身份标识。
SPIFFE 身份格式：
spiffe://cluster.local/ns/<namespace>/sa/<service-account>mTLS 握手过程中，双方 Envoy 交换证书并验证对方的 SPIFFE ID 是否匹配授权策略（AuthorizationPolicy）。
| 阶段 | 动作 | 涉及组件 | SPIFFE 作用 |
|---|---|---|---|
| 1. 证书签发 | Envoy 启动时通过 SDS 向 istiod 请求证书 | Envoy → istiod (Citadel) | 证书 SAN 中嵌入 SPIFFE ID |
| 2. TLS 握手 | 客户端 Envoy 发起连接，服务端 Envoy 出示证书 | 客户端 Envoy ↔ 服务端 Envoy | 服务端 SPIFFE ID 验证 |
| 3. 客户端证书请求 | 服务端请求客户端证书（双向验证） | 服务端 Envoy → 客户端 Envoy | 客户端 SPIFFE ID 验证 |
| 4. 策略执行 | 验证通过后，根据 SPIFFE ID 执行 RBAC | 服务端 Envoy | 匹配 AuthorizationPolicy 中的 source 字段 |
日志关联要点： 在网格升级窗口的异常样本中，Envoy 的访问日志会记录
spiffe://cluster.local/ns/foo/sa/bar 格式的源/目标身份。当出现“RBAC: access denied”或“TLS error”时，应首先检查日志中的 SPIFFE ID 是否与预期 ServiceAccount 匹配，以及证书序列号是否在证书吊销列表（CRL）中。