2. Istio架构回顾：控制平面与数据平面、Istiod核心组件、Sidecar注入原理、xDS协议简介
2.1 控制平面与数据平面：职责分离
Istio 采用经典的服务网格架构，将网络控制逻辑与数据转发彻底分离。这种设计使得运维人员可以集中管理流量策略、安全规则和可观测性，而无需修改业务代码。
| 平面 | 核心职责 | 关键组件 | 工作模式 |
|---|---|---|---|
| 控制平面 | 策略下发、配置管理、证书签发、服务发现 | Istiod（Pilot、Citadel、Galley 的整合） | 集中式逻辑决策，通过 xDS 协议下发配置 |
| 数据平面 | 流量拦截、协议解析、负载均衡、健康检查、mTLS 加解密 | Envoy Proxy（Sidecar 模式） | 分布式执行，每个 Pod 一个 Sidecar 代理 |
架构要点：控制平面不参与实际业务流量转发，只负责下发动态配置；数据平面完全由 Envoy 代理承载，所有进出 Pod 的流量都会被 Sidecar 拦截并按照控制平面下发的规则处理。
2.2 Istiod：三合一控制平面核心
在 Istio 1.5 之前，控制平面由 Pilot、Citadel、Galley 三个独立组件组成。Istio 1.5 之后，这三个组件被合并为一个单体进程 Istiod，大幅简化了部署和运维复杂度。
| 原组件 | 合并后职责 | 关键能力 |
|---|---|---|
| Pilot | 服务发现 + 流量管理 | 对接 Kubernetes API Server，生成 Envoy 路由、监听器、集群配置 |
| Citadel | 安全证书管理 | 自动签发、轮换 mTLS 证书，支持 SPIFFE 身份体系 |
| Galley | 配置验证与分发 | 校验 Istio CRD（VirtualService、DestinationRule 等），转换为内部模型 |
合并优势：Istiod 将三个组件的配置模型统一管理，减少了组件间 RPC 通信延迟，同时降低了多集群部署时的证书同步复杂度。单进程架构也使得故障排查更加集中。
2.3 Sidecar 注入原理：透明代理的起点
Sidecar 注入是 Istio 将 Envoy 代理自动附加到业务 Pod 的机制。注入方式分为两种：手动注入和自动注入（基于 MutatingWebhook）。
注入流程（自动注入）
- Webhook 拦截：用户通过
kubectl apply创建 Pod 时，Kubernetes API Server 调用 Istio 注册的 MutatingWebhookConfiguration。 - 配置读取：Istiod 根据命名空间标签（
istio-injection=enabled）判断是否需要注入。 - 模板渲染：Istiod 读取
istio-sidecar-injectorConfigMap 中的注入模板，结合 Pod 元数据渲染出 Envoy 容器配置。 - 注入返回：Webhook 返回修改后的 Pod 定义，包含两个容器：业务容器 +
istio-proxy（Envoy）容器。 - Init 容器：同时注入
istio-init容器，负责设置 iptables 规则，将入站和出站流量重定向到 Envoy。
注意：自动注入依赖
istio-ca-root-cert ConfigMap 和 istio-sidecar-injector ConfigMap 的正确配置。如果注入失败，请检查 Webhook 证书是否过期或命名空间标签是否遗漏。
2.4 xDS 协议简介：控制平面与数据平面的通信语言
xDS 是 Envoy 动态配置发现协议的统称，Istio 控制平面通过 xDS 协议将配置下发给所有 Sidecar 代理。xDS 协议基于 gRPC 流式通信，支持增量更新，避免了全量配置推送带来的性能开销。
| 协议类型 | 全称 | 配置内容 | 更新频率 |
|---|---|---|---|
| LDS | Listener Discovery Service | 监听器（端口、协议、过滤器链） | 低（服务端口变化时） |
| RDS | Route Discovery Service | 路由规则（域名匹配、流量拆分、重定向） | 中（VirtualService 变更时） |
| CDS | Cluster Discovery Service | 集群定义（上游服务端点、负载均衡策略） | 中（DestinationRule 变更时） |
| EDS | Endpoint Discovery Service | 端点列表（Pod IP、端口、健康状态） | 高（Pod 扩缩容时） |
| SDS | Secret Discovery Service | TLS 证书、私钥、mTLS 身份 | 低（证书轮换时） |
关键理解：xDS 协议是 Istio 控制平面与数据平面之间的“翻译层”。用户通过 Istio CRD（如 VirtualService）声明意图，Istiod 将其转换为 Envoy 可理解的 xDS 配置，再通过 gRPC 流推送到每个 Sidecar。这种机制保证了配置的实时性和一致性。
xDS 配置下发流程
- 配置变更：用户创建/更新 Istio CRD（如 VirtualService、DestinationRule）。
- 模型转换：Istiod 的 Galley 模块校验 CRD 合法性，Pilot 模块将其转换为 Envoy 内部配置模型。
- 增量计算：Istiod 对比当前配置与已有配置，计算出增量变更（避免全量推送）。
- gRPC 推送：通过 xDS 协议的 gRPC 流，将增量配置推送到所有受影响的 Envoy Sidecar。
- Envoy 热加载：Envoy 接收配置后，在不重启进程的情况下热更新监听器、路由、集群和端点。
性能优势：增量 xDS 推送机制使得 Istio 能够在大规模集群中快速响应 Pod 扩缩容和策略变更。单个 Envoy 实例每秒可以处理数千次 EDS 端点更新，而不会影响现有连接。