3. Istio 架构与核心组件：控制平面与数据平面详解
Istio 采用经典的控制平面/数据平面架构，将流量管理与安全策略从业务代码中解耦。理解这一架构是构建生产级 K8s 发布流水线的基础。本章将深入剖析控制平面的三大核心组件（Pilot、Mixer、Citadel）以及数据平面的唯一代理 Envoy，并阐明它们如何协同工作。
3.1 整体架构概览
Istio 服务网格的逻辑架构分为两个平面：
- 数据平面（Data Plane）：由一组与业务容器同 Pod 部署的 Envoy 代理组成，负责拦截、转发、观测所有进出服务的流量。
- 控制平面（Control Plane）：统一管理数据平面中的 Envoy 代理，下发配置、分发证书、收集遥测数据。
下图展示了 Istio 1.5+ 版本（整合为 istiod 单体）后的核心组件关系：
版本说明：Istio 1.5 之后，Pilot、Citadel、Galley 等组件合并为单一的 istiod 进程，简化了部署与运维。Mixer 的核心功能（遥测与策略）被移入 Envoy 插件（Wasm）或通过外部适配器实现，不再作为独立组件运行。
3.2 控制平面核心组件
3.2.1 Pilot — 服务发现与配置下发
Pilot 是控制平面的“大脑”，负责将高级路由规则（VirtualService、DestinationRule）转换为 Envoy 可理解的 xDS 协议配置，并实时推送给数据平面。
| 功能维度 | 详细说明 | 对应 xDS 接口 |
|---|---|---|
| 服务发现 | 对接 K8s API Server、Consul、Eureka 等注册中心，维护服务端点列表 | EDS（端点发现） |
| 监听器管理 | 为每个 Envoy 生成入站/出站监听器，配置端口、协议、过滤器链 | LDS（监听器发现） |
| 路由规则 | 解析 VirtualService 中的权重路由、请求匹配、故障注入等规则 | RDS（路由发现） |
| 集群管理 | 定义上游服务集群的连接池、负载均衡策略、熔断设置 | CDS（集群发现） |
| Secret 分发 | 将 Citadel 签发的 TLS 证书通过 SDS 接口推送给 Envoy | SDS（Secret 发现） |
关键机制：Pilot 通过 gRPC 流式推送 将配置变更实时推送到所有 Envoy，无需重启 Pod。在发布流水线中，修改 VirtualService 的权重后，Pilot 会在秒级内完成配置更新。
3.2.2 Citadel — 安全与证书管理
Citadel 是 Istio 的安全基石，负责管理服务间 mTLS 通信所需的证书与密钥。在 K8s 发布流水线中，Citadel 确保新版本 Pod 注入后能立即获得合法身份，实现零信任网络。
- 证书签发：为每个 ServiceAccount 签发 SPIFFE 格式的 X.509 证书，绑定服务身份。
- 密钥轮换：默认每 24 小时自动轮换证书，降低私钥泄露风险。
- 身份认证：验证请求方证书，确保只有合法服务可以访问目标服务。
- 授权策略：与 AuthorizationPolicy 配合，实现基于身份的细粒度访问控制。
3.2.3 Mixer（历史组件与演进）
在 Istio 1.5 之前，Mixer 负责策略检查（Check）和遥测报告（Report）。当前版本中，其功能已被重构：
| 原 Mixer 功能 | 当前实现方式 | 对发布流水线的影响 |
|---|---|---|
| 速率限制、黑白名单 | Envoy 本地限流过滤器 + 全局限流（RateLimitService） | 减少一次远程调用，降低延迟 |
| 访问日志、指标收集 | Envoy 直接输出到 stdout / 对接 Prometheus、Stackdriver | 简化架构，提升可观测性实时性 |
| 属性生成与转换 | Envoy 内置属性处理 + Wasm 插件扩展 | 支持自定义逻辑，无需额外组件 |
3.3 数据平面核心组件：Envoy Proxy
Envoy 是 Istio 数据平面的唯一代理，以 Sidecar 模式与业务容器同 Pod 运行。它通过 iptables 规则透明地劫持所有进出 Pod 的流量，实现无侵入的流量管理。
3.3.1 Envoy 核心架构
Envoy 内部采用多层过滤器链架构，每个网络连接经过 L4/L7 过滤器处理后转发：
3.3.2 Envoy 在发布流水线中的关键能力
| 能力 | 实现机制 | 发布场景应用 |
|---|---|---|
| 流量劫持 | Pod 启动时注入 iptables 规则，将 inbound/outbound 流量重定向到 Envoy 的 15001/15006 端口 | 无需修改业务代码即可实现灰度发布、蓝绿部署 |
| 负载均衡 | 支持轮询、最少连接、随机、一致性哈希等算法，支持权重分配 | 金丝雀发布中按权重（如 5% → 50% → 100%）逐步切换流量 |
| 熔断与重试 | 配置连接池大小、最大请求数、熔断阈值；支持超时重试、幂等重试 | 新版本出现异常时自动熔断，防止故障扩散 |
| 指标与追踪 | 自动生成 TCP/HTTP 指标（请求数、延迟、错误码），支持分布式追踪（Jaeger/Zipkin） | 实时监控发布过程中的错误率、P99 延迟，快速回滚 |
| mTLS 通信 | 通过 SDS 获取 Citadel 签发的证书，自动加密服务间通信 | 确保新旧版本 Pod 之间的通信安全，满足合规要求 |
3.4 组件协作流程：一次完整的请求
当 Pod A 中的业务容器需要调用 Pod B 的服务时，Istio 组件按以下流程协作：
- 流量劫持：Pod A 的 iptables 规则将出站请求重定向到本地 Envoy（Sidecar）。
- 策略检查：Envoy 根据 Pilot 下发的 LDS/RDS 配置，匹配目标服务的路由规则（如权重、Header 匹配）。
- 证书获取：Envoy 通过 SDS 向 Citadel（或 istiod 内的 SDS 服务）请求 Pod B 的证书，建立 mTLS 连接。
- 负载均衡：Envoy 根据 CDS 配置，从端点列表中选择一个健康的 Pod B 实例。
- 请求转发：Envoy 将请求转发到 Pod B 的 Envoy（入站监听器），后者再转发给 Pod B 的业务容器。
- 遥测收集：两个 Envoy 分别记录请求指标（延迟、状态码），通过标准协议输出到 Prometheus 或日志系统。
常见误区：很多初学者认为 Istio 的流量管理需要修改 K8s Service。实际上，Istio 通过 VirtualService 和 DestinationRule 在 Envoy 层面实现路由，K8s Service 仅作为稳定的 DNS 入口。发布流水线中，你只需要调整 CRD 配置，无需重建 Service。
3.5 组件对比总结
| 组件 | 所属平面 | 核心职责 | 对外接口/协议 | 发布流水线中的角色 |
|---|---|---|---|---|
| Pilot | 控制平面 | 服务发现、配置下发 | xDS (gRPC 流) | 路由规则变更的“发布引擎” |
| Citadel | 控制平面 | 证书签发、身份管理 | CA API / SDS | 保障新版本 Pod 的安全身份 |
| Envoy | 数据平面 | 流量代理、策略执行 | xDS (客户端) | 灰度、熔断、观测的执行者 |
| Mixer (旧) | 控制平面 | 策略/遥测（已移除） | gRPC / Check/Report | 历史参考，新项目无需关注 |