2. Istio基础回顾：Istio架构、控制平面与数据平面、Envoy sidecar原理
在深入API弃用检测与Sidecar升级工程之前，必须牢固掌握Istio的核心架构。Istio本质上是一个服务网格（Service Mesh）平台，它将流量管理、安全策略和可观测性从业务代码中剥离，下沉至基础设施层。其架构清晰划分为控制平面（Control Plane）与数据平面（Data Plane），两者通过xDS协议协同工作。
2.1 Istio整体架构概览
下图展示了Istio的核心组件及其交互关系。控制平面负责策略下发与配置管理，数据平面由注入到每个Pod中的Envoy Sidecar代理组成，负责拦截并处理所有进出容器的网络流量。
核心要点：控制平面（istiod）不参与业务数据路径，它只负责“告诉”数据平面该怎么做。所有业务流量均通过数据平面的Envoy Sidecar代理转发，实现了对业务代码的完全无侵入。
2.2 控制平面（istiod）详解
Istio 1.5+版本将原有的多个控制平面组件（Pilot、Mixer、Citadel、Galley）整合为单一的二进制文件——istiod。这简化了部署与运维，但核心职责保持不变。
| 组件 | 核心职责 | 关键能力 |
|---|---|---|
| Pilot | 服务发现与流量管理 | 从注册中心（K8s API Server、Consul等）获取服务信息；将用户定义的VirtualService、DestinationRule转换为Envoy可理解的xDS配置（LDS、RDS、CDS、EDS）。 |
| Citadel | 安全与证书管理 | 自动生成、分发和轮换密钥与证书；支持mTLS（双向TLS）身份认证；为服务间通信提供加密通道。 |
| Galley | 配置验证与分发 | 作为配置处理的“守门人”，负责验证Istio CRD（Custom Resource Definition）的合法性，并将有效配置传递给Pilot和Citadel。 |
运维提示：在Sidecar升级工程中，控制平面的稳定性至关重要。升级istiod版本前，务必验证其与现有Envoy Sidecar版本的xDS API兼容性。通常建议先升级控制平面，再逐步滚动升级数据平面。
2.3 数据平面与Envoy Sidecar原理
数据平面由一组与业务容器一同部署的Envoy Sidecar代理组成。Envoy是一个高性能、开源的L7代理与通信总线，由Lyft开发并捐赠给CNCF。Istio选择Envoy作为其数据平面核心，主要基于其强大的扩展能力和丰富的内置过滤器。
2.3.1 Envoy Sidecar的注入与拦截机制
Sidecar的注入通常通过Mutating Webhook Admission Controller自动完成。当Pod创建时，istiod会修改Pod的Spec，注入一个包含Envoy容器的init容器和sidecar容器。
- Init容器（istio-init）： 负责设置iptables规则，将进出Pod的流量重定向到Envoy Sidecar的端口（默认15006入站，15001出站）。
- Sidecar容器（istio-proxy）： 运行Envoy进程，根据从控制平面获取的动态配置处理所有流量。
流量劫持的路径如下：
- 入站流量： 外部请求到达Pod网络 → iptables规则拦截 → 转发至Envoy入站监听器（15006） → Envoy执行路由、鉴权、负载均衡等策略 → 转发至业务容器端口。
- 出站流量： 业务容器发起对外请求 → iptables规则拦截 → 转发至Envoy出站监听器（15001） → Envoy根据目标服务查找路由规则 → 选择目标实例并建立连接（通常使用mTLS）。
2.3.2 Envoy的核心配置模型（xDS）
Envoy通过一组被称为xDS（Discovery Service）的API从控制平面动态获取配置。理解xDS是进行Sidecar升级和故障排查的基础。
| API简称 | 全称 | 作用 |
|---|---|---|
| LDS | Listener Discovery Service | 定义Envoy监听的端口和协议（如15006、15001），以及如何过滤入站流量。 |
| RDS | Route Discovery Service | 定义HTTP路由规则，包括域名匹配、路径转发、重定向、重试等。 |
| CDS | Cluster Discovery Service | 定义上游服务集群（Cluster），包括连接池大小、健康检查策略、负载均衡算法等。 |
| EDS | Endpoint Discovery Service | 动态提供集群中的具体端点（Pod IP + Port）列表，用于负载均衡。 |
| SDS | Secret Discovery Service | 动态分发TLS证书和私钥，用于mTLS通信。 |
升级风险提示：在Sidecar升级过程中，如果新版本的Envoy不再支持旧版本的xDS API（例如，某个字段被废弃），控制平面下发的配置可能被Envoy拒绝或忽略，导致流量中断。因此，升级前必须查阅Envoy的变更日志（Changelog），特别是关于xDS API的Breaking Changes。
2.4 控制平面与数据平面的交互流程
理解两者如何协同工作，是诊断网格问题的基础。一个典型的配置下发流程如下：
- 用户操作： 运维人员通过
kubectl apply创建或更新一个VirtualService资源。 - 配置验证： Galley组件接收到CRD变更事件，对配置进行语法和语义校验。
- 配置转换： Pilot组件将校验后的Istio CRD转换为Envoy特定的xDS配置（如RDS路由表）。
- 配置下发： Pilot通过gRPC流（Streaming）将xDS配置推送到所有相关的Envoy Sidecar。
- 热加载： Envoy Sidecar接收到新配置后，在不重启进程的情况下，热加载新的监听器、路由和集群配置。
- 流量生效： 后续进入Envoy的流量将按照新的路由规则进行转发。
工程启示： 在API弃用检测场景中，我们可以利用控制平面的这个能力。当检测到某个API版本被弃用时，通过动态更新VirtualService或DestinationRule，将流量从旧版本服务实例平滑迁移到新版本，而无需重启任何Pod。这正是“自动化”与“零宕机”升级的基础。