2. Istio 架构深度解析：控制平面与数据平面的组件职责与交互流程
Istio 服务网格的架构遵循经典的控制平面/数据平面分离模式。数据平面由一组高性能 Sidecar 代理（Envoy）组成，负责处理所有进出服务的流量；控制平面则负责统一管理、配置和下发策略，是整个网格的“大脑”。本章将深入剖析各核心组件的职责及其交互机制，为后续的安全策略集成奠定基础。
2.1 架构总览：控制平面与数据平面的边界
在 Istio 1.5 版本之后，控制平面组件被整合为单一的 istiod 单体服务，但其内部逻辑仍可划分为 Pilot、Citadel、Galley 等核心模块。数据平面则始终由 Envoy 代理构成。下图展示了两个平面的逻辑边界与核心交互关系。
版本说明： 在 Istio 1.5+ 中，Pilot、Citadel、Galley 等功能被整合进单一的
istiod 进程，但逻辑职责保持不变。Mixer 组件在 1.5 版本后已被废弃，其策略执行能力被集成到 Envoy 的 Wasm 扩展和遥测插件中。
2.2 控制平面核心组件职责
控制平面是 Istio 的决策中心，负责将用户定义的高级流量规则和安全策略，转换为 Envoy 能够理解的低级配置。下表总结了四个核心组件的职责对比：
| 组件 | 核心职责 | 关键协议/接口 | 安全相关性 |
|---|---|---|---|
| Pilot | 服务发现、流量管理规则转换、xDS 配置下发 | xDS (LDS, RDS, CDS, EDS) | 路由规则中的 RBAC 过滤、重试策略 |
| Citadel | CA 证书管理、身份签发、密钥生成与轮换 | SDS (Secret Discovery Service) | mTLS 双向认证、SPIFFE 身份 |
| Galley | 配置 ingestion、验证、转换与分发 | MCP (Mesh Configuration Protocol) | 配置合规性校验、防止非法策略注入 |
| Mixer (历史) | 策略检查（鉴权、限流）与遥测报告 | Check/Report gRPC | 已被 Envoy 内联的 Wasm 和 Stats 插件替代 |
2.3 数据平面：Envoy Proxy 的深度角色
Envoy 是 Istio 数据平面的唯一代理，以 Sidecar 模式注入到每个 Pod 中。它并非简单的流量转发器，而是一个功能完备的 L7 代理和可编程执行平台。
- 流量拦截与转发： 通过 iptables 规则透明地劫持 Pod 的入站和出站流量，所有通信都必须经过 Envoy。
- 协议支持： 原生支持 HTTP/1.1、HTTP/2、gRPC、TCP 以及 MongoDB、Redis 等协议的解析和路由。
- 安全执行点： 执行 mTLS 握手、证书验证、RBAC 鉴权、OPA 策略检查（通过 Wasm 扩展）。
- 可观测性： 自动生成详细的访问日志、分布式追踪 span 和 Prometheus 指标。
2.4 组件交互流程：从配置下发到流量处理
理解组件间的交互流程，是诊断网格问题和设计安全策略的关键。下图以一次完整的服务间调用为例，展示了配置下发和运行时流量的完整路径。
2.5 关键交互协议详解
控制平面与数据平面之间的通信依赖于一组标准化的发现协议，统称为 xDS。理解这些协议是进行安全策略调优的基础。
- LDS (Listener Discovery Service)： 告诉 Envoy 在哪些端口上监听，以及如何处理入站流量（例如，是否要求 mTLS）。
- RDS (Route Discovery Service)： 定义虚拟主机和路由规则，包括流量镜像、重试、超时以及 RBAC 过滤器 的配置。
- CDS (Cluster Discovery Service)： 定义上游服务集群，包括连接池设置、负载均衡策略和 TLS 上下文。
- EDS (Endpoint Discovery Service)： 动态发现服务实例的 IP 地址和端口，用于负载均衡。
- SDS (Secret Discovery Service)： 专门用于分发 TLS 证书和私钥，由 Citadel 驱动，实现证书的自动轮换，无需重启 Envoy。
安全实践要点：
- 通过 PeerAuthentication 资源控制 mTLS 模式（STRICT/PERMISSIVE/DISABLE），该配置最终由 Pilot 转换为 Envoy 的 TLS 上下文。
- 通过 AuthorizationPolicy 资源定义 RBAC 规则，Pilot 会将其编译为 Envoy 的 RBAC 过滤器配置，并通过 RDS 下发。
- OPA 策略通常以 Wasm 插件的形式注入 Envoy，在请求处理的生命周期中执行细粒度的策略检查。
2.6 组件职责与安全策略的映射关系
在后续章节中，我们将深入探讨 OPA 和 RBAC 的集成。在此之前，明确每个组件在安全策略生命周期中的角色至关重要：
| 安全策略阶段 | 负责组件 | 具体动作 |
|---|---|---|
| 策略定义 | 用户 / Galley | 编写 YAML (AuthorizationPolicy, PeerAuthentication)，Galley 进行 schema 校验 |
| 策略转换 | Pilot | 将高级 RBAC 规则转换为 Envoy RBAC 过滤器配置 |
| 身份签发 | Citadel | 为每个服务 Pod 签发 SPIFFE 格式的 X.509 证书 |
| 策略下发 | Pilot / Citadel | 通过 xDS 下发路由和 RBAC 配置；通过 SDS 下发证书 |
| 策略执行 | Envoy (数据平面) | 在请求路径上执行 mTLS 握手、RBAC 鉴权、OPA Wasm 策略检查 |
通过上述架构解析，我们可以清晰地看到：Istio 的安全能力并非由单一组件提供，而是由控制平面的策略编排能力与数据平面的高性能执行能力共同构成。这种分离架构使得安全策略的更新可以独立于应用部署，实现了安全运维的集中化和自动化。