2. Istio 基础回顾：架构、核心组件与 Envoy 代理原理
在深入流量拓扑漂移告警的复测流程之前，必须牢固掌握 Istio 服务网格的基础架构。本章将系统回顾 Istio 的控制面与数据面分离设计、三大核心组件的职责，以及 Envoy 代理作为数据面核心的工作机制。这些知识是后续理解流量拓扑采集、告警规则推导和复测验证的基石。
2.1 Istio 整体架构：控制面与数据面
Istio 采用经典的控制面/数据面分离架构。数据面由注入到每个 Pod 中的 Envoy 代理组成，负责拦截并处理所有进出容器的流量；控制面则统一管理代理的配置下发、策略执行和证书分发。
架构要点： 数据面代理（Envoy）通过 xDS 协议从控制面拉取动态配置，实现无中断的流量路由、负载均衡、熔断和可观测性。
2.2 核心组件详解
Istio 控制面自 v1.5 起合并为单一的 istiod 二进制，但内部仍保留 Pilot、Citadel、Mixer 三大逻辑组件。理解每个组件的原始职责，有助于排查配置下发和证书相关问题。
| 组件 | 核心职责 | 关键协议/接口 | 与流量拓扑的关系 |
|---|---|---|---|
| Pilot | 服务发现、流量管理规则转换、xDS 配置下发 | ADS/EDS/CDS/LDS/RDS | 直接决定 Envoy 的路由规则和端点列表，是拓扑数据的来源 |
| Citadel | 证书签发、密钥管理、身份认证（mTLS） | SPIFFE、K8s CSR | 影响服务间通信的加密和身份标识，拓扑中体现为信任关系 |
| Mixer | 访问策略、遥测数据收集（v1.5 前独立部署） | Check/Report | 历史版本中影响流量策略，当前功能已内化到 Envoy 和 Pilot |
实践提示： 在流量拓扑漂移告警复测中，Pilot 下发的 EDS（端点发现服务）配置是最关键的检查点。如果 Envoy 的端点列表与预期不符，拓扑漂移几乎必然发生。
2.3 Envoy 代理原理
Envoy 是 Istio 数据面的核心，以 sidecar 模式注入到每个 Pod 中。它通过 iptables 规则透明地劫持所有进出容器的流量，并基于从 Pilot 获取的动态配置执行路由、负载均衡、熔断和可观测性操作。
2.3.1 Envoy 核心工作流程
- 流量劫持： Init 容器设置 iptables 规则，将入站和出站流量重定向到 Envoy 的监听端口（默认 15001/15006）。
- 配置获取： Envoy 启动后通过 xDS 协议向 Pilot 发起 ADS 请求，获取监听器（LDS）、路由（RDS）、集群（CDS）、端点（EDS）和密钥（SDS）配置。
- 请求处理： 当应用发出请求时，Envoy 根据路由规则选择目标集群，再通过负载均衡算法选择一个端点，建立连接并转发请求。
- 可观测性： Envoy 自动生成访问日志、分布式追踪和指标（如请求数、延迟、错误率），上报给 Prometheus 或 Jaeger。
2.3.2 Envoy 关键配置与拓扑漂移的关联
在流量拓扑漂移告警复测中，Envoy 的 EDS 配置 是最核心的检测对象。当 Pilot 下发的端点列表与 Kubernetes Service 的 Endpoints 对象不一致时，就会产生拓扑漂移。常见的漂移场景包括：
- 端点缺失： 新扩容的 Pod 未及时出现在 Envoy 的 EDS 中，导致流量无法到达。
- 端点残留： 已终止的 Pod 仍存在于 Envoy 的 EDS 中，导致请求被路由到不存在的 Pod。
- 路由规则错误： VirtualService 或 DestinationRule 配置错误，导致流量被路由到错误的集群或子集。
复测关注点： 在复测流程中，需要对比
istioctl proxy-config endpoints <pod> 的输出与 kubectl get endpoints <service> 的结果。任何差异都意味着拓扑漂移，需要进一步排查 Pilot 的配置下发链路。