1. Istio网格架构概述：数据平面与控制平面组件、Envoy代理原理、Sidecar注入机制
1.1 控制平面与数据平面
Istio 服务网格采用经典的控制平面/数据平面分离架构。控制平面统一管理配置与策略，数据平面负责承载实际业务流量。两者通过 xDS 协议（Discovery Service）进行配置下发与状态同步。
| 平面 | 核心组件 | 主要职责 |
|---|---|---|
| 控制平面 | istiod（Pilot、Citadel、Galley 合并） | 服务发现、证书签发、配置管理与分发、策略下发 |
| 数据平面 | Envoy 代理（Sidecar 模式） | 流量拦截、负载均衡、熔断、遥测数据采集 |
关键理解：控制平面不参与业务数据路径，只负责下发动态配置；数据平面以 Sidecar 方式注入每个 Pod，拦截所有进出流量。
1.2 Envoy 代理核心原理
Envoy 是 Istio 数据平面的基石，以 Sidecar 模式运行在每个业务 Pod 中。它基于 L4/L7 过滤器链实现流量处理，核心能力包括：
- 流量拦截：通过 iptables 规则将 Pod 的入站和出站流量全部重定向到 Envoy 端口（15006 入站 / 15001 出站）。
- 动态配置：通过 xDS 协议从 istiod 拉取监听器（Listener）、路由（Route）、集群（Cluster）、端点（Endpoint）配置。
- 七层处理：支持 HTTP/1.1、HTTP/2、gRPC、TCP 等协议，内置熔断、重试、超时、流量镜像等高级功能。
- 遥测生成：自动生成 TCP 指标、HTTP 指标、访问日志和分布式追踪 span，输出到 Prometheus、Grafana、Jaeger 等后端。
排查要点：Envoy 的
--log-level debug 模式可以输出 xDS 交互细节，是定位配置未生效或路由错误的常用手段。
1.3 Sidecar 注入机制
Sidecar 注入有两种方式：自动注入（推荐）和手动注入。自动注入依赖 Kubernetes 的 MutatingAdmissionWebhook，在 Pod 创建时由 istiod 动态修改 Pod 定义。
| 注入方式 | 触发时机 | 配置方式 | 适用场景 |
|---|---|---|---|
| 自动注入 | Pod 创建时（Admission Webhook） | Namespace 添加 istio-injection=enabled 标签 |
生产环境，大规模集群 |
| 手动注入 | 通过 istioctl kube-inject 命令 |
修改 Deployment YAML 后重新 apply | 调试、CI/CD 管道中预注入 |
自动注入的完整流程如下：
- 用户创建 Pod（通过 Deployment / StatefulSet 等控制器）。
- API Server 将 Pod 创建请求发送给 istiod 注册的 MutatingWebhook。
- istiod 检查 Namespace 标签
istio-injection: enabled或 Pod 注解sidecar.istio.io/inject: "true"。 - istiod 将
istio-proxy容器（Envoy）以及istio-init初始化容器注入到 Pod spec 中。 istio-init容器负责配置 iptables 规则，完成后退出。- Pod 启动后，业务容器与 Envoy 容器共享网络命名空间，所有流量经过 Envoy。
常见故障场景：如果 Pod 启动后 Envoy 未正常工作，首先检查 Namespace 是否已打上
istio-injection=enabled 标签，以及 Webhook 配置是否被其他准入控制器覆盖。使用 kubectl describe pod <pod-name> 查看 Events 中是否有注入失败记录。
1.4 本章小结
- Istio 架构分为控制平面（istiod）和数据平面（Envoy Sidecar），两者通过 xDS 协议通信。
- Envoy 作为高性能代理，负责流量拦截、七层路由、负载均衡和遥测数据生成。
- Sidecar 自动注入依赖 Kubernetes MutatingWebhook，在 Pod 创建时动态添加 istio-proxy 和 istio-init 容器。
- 理解这些基础组件是后续排查网格拓扑异常和 Prometheus 数据聚合问题的前提。