2. 服务网格基础：Istio架构核心组件
Istio 是目前最成熟的服务网格实现之一，其架构清晰地划分为数据平面与控制平面。理解这两大平面及其核心组件，是后续将 OPA 策略集成到流量拓扑安全测试中的前提。
2.1 数据平面与控制平面
服务网格的核心思想是将网络通信的复杂性从业务容器中剥离，下沉为基础设施层。Istio 通过以下两个平面实现这一目标：
| 平面 | 职责 | 核心组件 | 关键特征 |
|---|---|---|---|
| 数据平面 | 处理所有服务间通信、负载均衡、健康检查、流量路由、安全策略执行 | Envoy 代理（Sidecar） | 高性能、无状态、与业务容器同生命周期 |
| 控制平面 | 管理并配置数据平面，下发路由规则、安全策略、遥测配置 | Pilot、Mixer（已弃用）、Citadel、Galley | 有状态、集中式、负责策略解析与分发 |
架构演进提示： 自 Istio 1.5 起，Mixer 的功能被合并到 Envoy 代理中，控制平面组件也整合为单一的
istiod 进程。但理解原始四组件的职责，对于掌握 OPA 策略集成点（特别是 Mixer 时代的适配器模型）仍有重要参考价值。
2.2 核心组件详解
2.2.1 Pilot — 流量管理与服务发现
Pilot 是控制平面的“交通指挥官”，负责将高级别的路由规则（如 VirtualService、DestinationRule）转换为 Envoy 可理解的 xDS 协议配置，并下发到每个 Sidecar 代理。
- 服务发现： 对接平台（Kubernetes、Consul 等）的服务注册中心，获取可用服务端点列表。
- 流量规则转换： 将用户定义的 YAML 规则（权重路由、超时、重试、熔断）翻译为 Envoy 的 Listener、Cluster、Route 配置。
- 配置分发： 通过 gRPC 流推送 xDS 配置，确保数据平面实时生效。
2.2.2 Mixer — 策略与遥测（已弃用，但概念重要）
Mixer 曾是 Istio 的策略决策点和遥测收集中心。虽然已被移除，但其适配器模型是 OPA 作为外部策略引擎集成到服务网格的经典参考架构。
- 前置检查： 每次服务间调用前，Envoy 向 Mixer 发送 Check 请求，询问是否允许该请求。
- 报告： 调用完成后，Envoy 向 Mixer 发送 Report，用于日志、监控和计费。
- 适配器： Mixer 通过插件式适配器对接后端系统（如 OPA、Prometheus、Stackdriver）。
OPA 集成关键点： 在 Mixer 时代，OPA 作为 Mixer 的 Authorization 适配器 运行。Envoy 的每次请求都会触发 Mixer 调用 OPA 的
/v1/data API，基于 OPA 策略做出允许/拒绝决策。虽然 Mixer 已弃用，但这种“外部策略注入”的思想在 Istio 1.5+ 的 Envoy 外部授权过滤器 中得以延续。
2.2.3 Citadel — 安全与证书管理
Citadel 是 Istio 的安全基石，负责服务身份管理和证书签发。它实现了服务网格内的 mTLS（双向 TLS）通信。
- 身份管理： 为每个服务实例（Pod）分配 SPIFFE 兼容的身份标识。
- 证书签发： 自动生成、分发和轮换 X.509 证书，无需人工干预。
- 密钥存储： 通过 Kubernetes Secret 或 SDS（Secret Discovery Service）安全分发私钥。
2.2.4 Galley — 配置验证与分发
Galley 是控制平面的“配置网关”，负责验证、处理和分发用户提交的 Istio 配置。
- 配置验证： 对用户提交的 YAML 进行语法和语义校验，防止错误配置下发到数据平面。
- 配置转换： 将平台相关的配置（如 Kubernetes CRD）转换为 Istio 内部统一的配置模型。
- 配置分发： 将验证后的配置传递给 Pilot 等下游组件。
2.3 架构总览图
下图展示了 Istio 1.5 之前版本的经典架构，清晰呈现了数据平面与控制平面的交互关系，以及 OPA 作为外部策略引擎的集成位置。
2.4 组件职责对比
| 组件 | 核心职责 | 与 OPA 集成关联 | 当前状态 |
|---|---|---|---|
| Pilot | 服务发现、流量规则转换与 xDS 下发 | 低 — 主要负责路由，不直接参与策略决策 | 核心组件，持续演进 |
| Mixer | 策略检查（Check）与遥测报告（Report） | 高 — 经典 OPA 集成点，通过适配器调用 OPA | 已弃用（Istio 1.5+） |
| Citadel | 服务身份管理、证书签发与 mTLS | 中 — 提供身份上下文，OPA 策略可基于身份做决策 | 核心组件，持续演进 |
| Galley | 配置验证、转换与分发 | 低 — 确保策略配置格式正确，不参与运行时决策 | 已合并至 istiod |
2.5 现代 Istio 架构（istiod）
自 Istio 1.5 起，控制平面组件合并为单一的 istiod 进程，简化了部署和运维。但上述四组件的逻辑职责仍然保留在 istiod 内部。
OPA 集成方式演进：
- Mixer 时代： OPA 作为 Mixer 适配器，通过 gRPC 接口接收 Check 请求。
- istiod 时代： OPA 通过 Envoy 的 外部授权过滤器（ExtAuthz） 集成。Envoy 在转发请求前，向 OPA 发送 gRPC 或 HTTP 检查请求，OPA 返回允许/拒绝决策。
下图展示了现代 Istio 架构中 OPA 通过 Envoy 外部授权过滤器集成的简化流程：
2.6 本章小结
- Istio 架构分为数据平面（Envoy Sidecar）和控制平面（Pilot、Mixer、Citadel、Galley / istiod）。
- Pilot 负责流量管理，Citadel 负责安全身份，Galley 负责配置验证，Mixer（已弃用）曾是 OPA 集成的关键组件。
- 现代 Istio 中，OPA 通过 Envoy 的外部授权过滤器实现策略注入，这是本课程后续实验的核心架构模式。
- 理解这些组件的职责，有助于在流量拓扑安全测试中精准定位策略执行点。