2. Istio 架构深度解析：控制平面与数据平面
Istio 作为服务网格的事实标准，其架构清晰地划分为控制平面（Control Plane）与数据平面（Data Plane）。理解这两个平面的组件职责与交互流程，是掌握 Istio 策略执行与审计日志配置的基础。控制平面负责统一管理和配置，而数据平面负责执行实际的流量转发与策略实施。
2.1 控制平面核心组件
控制平面由四个关键组件构成：Pilot、Mixer（已弃用但概念重要）、Citadel 和 Galley。在最新版本中，Mixer 的功能已被 Envoy 原生扩展和 WebAssembly 替代，但其策略与遥测的抽象模型仍被沿用。
| 组件 | 核心职责 | 关键能力 |
|---|---|---|
| Pilot | 服务发现与流量管理 | 将高级路由规则（VirtualService、DestinationRule）转换为 Envoy 的 xDS 配置（Listener、Cluster、Route、Endpoint）。 |
| Mixer（概念层） | 策略检查与遥测报告 | 提供 Check（访问控制、配额）和 Report（日志、监控）两阶段模型。当前功能由 Envoy 原生插件和 WASM 扩展实现。 |
| Citadel | 安全证书管理 | 自动生成、分发和轮换 X.509 证书，实现 mTLS 身份认证与通信加密。 |
| Galley | 配置验证与分发 | 作为配置处理的前端，负责验证、转换和分发用户配置（如 YAML 文件）到其他控制平面组件。 |
架构演进提示： 自 Istio 1.5 起，控制平面组件合并为单一的
istiod 进程。但内部职责划分依然遵循 Pilot、Citadel、Galley 的架构逻辑，理解独立组件有助于排查复杂问题。
2.2 数据平面核心组件：Envoy Proxy
数据平面由部署在每个服务 Pod 中的 Envoy Proxy 边车容器组成。Envoy 是高性能的 L4/L7 代理，负责所有进出 Pod 的流量拦截与转发。
- 流量拦截： 通过 iptables 规则透明地劫持入站（Inbound）和出站（Outbound）流量。
- 协议支持： 原生支持 HTTP/1.1、HTTP/2、gRPC、TCP 等协议，具备丰富的 L7 路由能力。
- 策略执行： 执行来自控制平面的访问控制、速率限制、重试、超时等策略。
- 遥测生成： 生成详细的访问日志、指标（Metrics）和分布式追踪数据。
- 安全通信： 基于 Citadel 下发的证书，自动建立 mTLS 连接。
2.3 控制平面与数据平面的交互流程
交互流程的核心是 xDS 协议（Discovery Service）。Pilot 作为 xDS 服务器，Envoy 作为 xDS 客户端，通过 gRPC 流式订阅配置更新。
- 配置下发： 用户通过
kubectl apply提交 Istio 资源（如 VirtualService）。Galley 验证配置后，将其传递给 Pilot。 - 配置转换： Pilot 将 Istio 资源转换为 Envoy 可理解的 xDS 配置（LDS、RDS、CDS、EDS）。
- 配置推送： Pilot 通过 gRPC 流将配置推送到所有连接的 Envoy 实例。
- 策略执行： Envoy 根据最新配置处理流量。当需要执行外部策略（如 OPA 策略检查）时，Envoy 通过 ExtAuthz 或 WASM 扩展调用外部策略引擎。
- 证书轮换： Citadel 通过 SDS（Secret Discovery Service）协议自动向 Envoy 推送更新的证书，无需重启 Pod。
关键交互点： 在 OPA 策略引擎集成场景中，Envoy 的 ExtAuthz 过滤器 是核心交互点。Envoy 将每个请求的元数据发送给 OPA，OPA 返回 allow/deny 决策，Envoy 根据决策执行放行或拒绝。
2.4 组件交互流程详解
以下是一个完整的请求生命周期，展示组件如何协同工作：
| 步骤 | 发起组件 | 接收组件 | 交互内容 |
|---|---|---|---|
| 1 | 用户 (kubectl) | Galley | 提交 Istio 配置 YAML |
| 2 | Galley | Pilot | 验证后的配置数据 |
| 3 | Pilot | Envoy (所有) | 推送 xDS 配置（路由、集群、监听器） |
| 4 | Citadel | Envoy (所有) | 通过 SDS 推送证书与密钥 |
| 5 | App A | Envoy A (出站) | 发起对 Service B 的 HTTP/gRPC 请求 |
| 6 | Envoy A | Envoy B (入站) | 基于 mTLS 转发请求，携带身份信息 |
| 7 | Envoy B | App B | 将请求转发给业务容器 |
| 8 | Envoy A/B | 遥测后端 | 生成访问日志、指标和追踪数据 |
安全注意事项： 在步骤 6 中，如果启用了严格的 mTLS 模式，Envoy A 必须持有由 Citadel 签发的有效证书，且 Envoy B 会验证该证书的 SAN（Subject Alternative Name）是否匹配 Service A 的 ServiceAccount。任何证书不匹配都会导致连接被拒绝。
2.5 关键设计原则与最佳实践
- 关注点分离： 控制平面只负责“告诉”数据平面做什么，不参与数据路径。数据平面只负责“执行”，不存储持久状态。
- 最终一致性： xDS 配置采用最终一致性模型。Envoy 会持续监听配置更新，确保所有实例最终达到一致状态。
- 安全最小化： 控制平面组件应部署在独立的命名空间（如
istio-system），并配置严格的 RBAC 和网络策略。 - 可观测性优先： 在集成 OPA 策略引擎时，务必在 Envoy 的访问日志中记录策略决策结果（allow/deny）和决策原因，以便审计。
审计日志配置要点： 在 Envoy 的
access_log 配置中，通过 %DYNAMIC_METADATA(envoy.filters.http.ext_authz:decision)% 可以提取 OPA 的决策结果。结合请求的源 IP、目标服务、请求路径等信息，即可构建完整的审计日志记录。