2. 服务网格基础:Istio 架构核心组件与数据/控制平面分离原理

在深入 Helm 校验之前,必须先理解 Istio 的架构基石。Istio 将服务网格拆分为数据平面和控制平面,这种分离设计是流量拓扑可观测性与安全策略生效的前提。本章聚焦四个核心组件——Pilot、Mixer、Citadel、Envoy,并阐明它们如何协同工作。

2.1 数据平面与控制平面分离原理

传统微服务架构中,每个服务实例需要自行处理重试、超时、熔断、TLS 等逻辑,导致代码侵入性强、升级困难。Istio 通过Sidecar 代理模式将流量管理从业务代码中剥离,形成两个独立的平面:

  • 数据平面:由一组智能代理(Envoy)组成,负责拦截、转发、观测所有进出服务的流量。代理与业务容器同 Pod 部署,对业务代码完全透明。
  • 控制平面:由 Pilot、Mixer、Citadel 等组件构成,负责下发配置、策略、安全证书给数据平面,自身不参与业务流量转发。
关键设计原则:控制平面故障不应影响已建立的连接。Envoy 本地缓存了最新的配置和证书,即使控制平面短暂不可用,数据平面仍能按最后已知规则继续转发流量。
Istio 数据平面与控制平面分离架构 Istio 数据平面与控制平面分离架构 控制平面(Control Plane) Pilot Mixer Citadel Galley / API 数据平面(Data Plane) Pod A 业务容器 Envoy Sidecar 代理 Pod B 业务容器 Envoy Sidecar 代理 Pod C 业务 Envoy Sidecar 代理 控制平面通过 xDS 协议下发配置和证书;数据平面 Envoy 之间直接转发业务流量,不经过控制平面

2.2 核心组件详解

2.2.1 Envoy —— 数据平面的基石

Envoy 是 Istio 数据平面的唯一代理,以 Sidecar 模式注入每个 Pod。它使用 C++ 编写,具备高性能和丰富的流量控制能力:

  • 流量拦截:通过 iptables 规则透明劫持 Pod 内所有入站和出站流量。
  • 协议支持:原生支持 HTTP/1.1、HTTP/2、gRPC、TCP 等协议,并可扩展。
  • 负载均衡:内置加权轮询、最少请求、一致性哈希等算法。
  • 熔断与重试:可配置连接池大小、异常检测、超时和重试策略。
  • 可观测性:自动生成访问日志、分布式追踪(Jaeger/Zipkin)和 Prometheus 指标。
Helm 校验关联:Envoy 的配置由控制平面通过 xDS 协议动态下发。Helm 发布包中若包含 EnvoyFilter 自定义资源,校验其语法和版本兼容性是保证数据平面稳定的关键。

2.2.2 Pilot —— 流量管理的指挥官

Pilot 是控制平面的核心,负责将高级路由规则转换为 Envoy 可理解的 xDS 配置。主要职责包括:

功能模块 说明 对应 xDS 协议
服务发现 对接 Kubernetes API Server,监听 Service/Endpoint 变化 LDS(Listener)、EDS(Endpoint)
路由规则 解析 VirtualService、DestinationRule CRD,生成路由配置 RDS(Route)
集群管理 定义上游集群的连接池、熔断、负载均衡策略 CDS(Cluster)
配置分发 通过 gRPC 流将配置推送到所有 Envoy 实例 ADS(Aggregated Discovery Service)

2.2.3 Mixer —— 策略与遥测引擎(已弃用,但理解其设计仍有价值)

Mixer 最初负责策略检查和遥测报告。在 Istio 1.5+ 版本中,其功能已逐步内迁到 Envoy 代理中(通过 Wasm 插件和 Telemetry API),但理解其原始设计有助于阅读旧版 Helm Chart:

  • 前置检查:在请求转发前,向 Mixer 查询是否允许该请求(白名单、速率限制等)。
  • 后置报告:请求完成后,将日志和指标上报给 Mixer,再由 Mixer 转发给后端(Prometheus、Stackdriver 等)。
版本注意:如果你使用的 Istio 版本 >= 1.5,Helm Chart 中可能不再包含 Mixer 组件。校验发布包时需根据 Istio 版本判断 Mixer 相关资源是否应存在。

2.2.4 Citadel —— 安全与证书管理

Citadel 负责服务网格内的身份认证和证书管理,是实现 mTLS(双向 TLS)的基础:

  • 证书签发:为每个 Service Account 签发 SPIFFE 标准的 X.509 证书。
  • 证书轮换:自动管理证书生命周期,定期轮换私钥和证书。
  • 身份注入:通过 Sidecar Injector 将证书和密钥注入 Pod。

Citadel 的存在使得网格内所有流量默认可以启用加密,无需修改业务代码。

2.3 组件协作流程

以下时序图展示了一次典型请求中,各组件如何协作:

Istio 组件协作流程 Istio 组件协作流程(一次请求的生命周期) 客户端 客户端 Envoy Pilot 服务端 Envoy 服务端 1 发起请求 2 查询 Pilot 获取路由 3 转发请求(含 mTLS) 4 转发到业务容器 5 返回响应 6 响应回传 7 响应返回客户端 所有 Envoy 之间的通信均经过 mTLS 加密;Pilot 仅在启动和配置变更时参与

2.4 组件职责对比

组件 所属平面 核心职责 Helm 校验关注点
Envoy 数据平面 流量代理、协议转换、可观测性 Sidecar 注入配置、EnvoyFilter 资源
Pilot 控制平面 服务发现、路由下发、xDS 配置 Pilot 镜像版本、资源限制、ConfigMap
Mixer 控制平面 策略检查、遥测报告(旧版) 版本兼容性、是否已弃用
Citadel 控制平面 证书签发、身份管理、mTLS 证书轮换周期、CA 配置

2.5 本章小结

  • Istio 通过数据平面(Envoy)与控制平面(Pilot、Mixer、Citadel)的分离,实现了流量管理与业务代码的解耦。
  • Pilot 是流量规则的翻译器,将 CRD 转化为 Envoy 可执行的 xDS 配置。
  • Citadel 提供网格内的身份与证书管理,是 mTLS 安全通信的基础。
  • 理解这些组件的职责和协作关系,是后续校验 Helm 发布包中相关资源定义正确性的前提。