📚 课程目录第2章 Istio整体架构

2. Istio 整体架构：数据平面与控制平面的分离

Istio 作为云原生服务网格的事实标准，其架构设计遵循了数据平面（Data Plane）与控制平面（Control Plane）分离的核心原则。这种分离式架构使得流量转发与策略决策解耦，运维人员可以独立升级、扩缩容控制面组件，而无需中断业务流量。

2.1 架构总览：两大平面的职责划分

数据平面由一组与业务容器同生命周期运行的 Sidecar 代理（Envoy）组成，负责处理所有进出服务的网络流量；控制平面则统一管理代理的配置下发、安全证书签发、遥测数据聚合与策略执行。下表从多个维度对比了两者的差异：

维度	数据平面（Data Plane）	控制平面（Control Plane）
核心组件	Envoy Proxy（Sidecar）	Pilot、Mixer、Citadel、Galley
主要职责	拦截并转发流量、执行负载均衡、健康检查、熔断	配置下发、策略管理、证书签发、配置验证
流量路径	处于业务容器与网络之间，直接处理请求	不参与业务数据路径，仅通过 gRPC 与代理通信
扩缩容方式	随业务 Pod 自动扩缩（DaemonSet 或 Sidecar 注入）	独立 Deployment，可按集群规模调整副本数
故障影响范围	影响单个 Pod 的流量转发能力	影响新配置下发与策略更新，已有流量不受影响

  架构要点：控制平面故障不会导致正在运行的业务流量中断，Envoy 代理会缓存最后一次有效的配置继续工作。这是分离式架构带来的关键韧性优势。

2.2 数据平面核心：Envoy 代理

Envoy 是 Istio 数据平面的唯一代理实现，以 Sidecar 模式注入到每个业务 Pod 中。它使用 L4/L7 过滤器链 机制处理流量，支持 HTTP/1.1、HTTP/2、gRPC、TCP 等多种协议。

流量拦截：通过 iptables 规则将入站和出站流量透明地重定向到 Envoy 端口。
动态配置：通过 xDS 协议（CDS、EDS、LDS、RDS、SDS）从 Pilot 拉取最新的路由、监听器、集群和端点信息。
可观测性：自动生成详细的访问日志、分布式追踪 span 和 Prometheus 指标。
安全通信：与 Citadel 集成，自动获取 mTLS 证书，实现服务间加密通信。

# Envoy 动态配置的 xDS 协议族
- LDS (Listener Discovery Service)   → 监听器配置
- RDS (Route Discovery Service)      → 路由规则
- CDS (Cluster Discovery Service)    → 上游集群定义
- EDS (Endpoint Discovery Service)   → 集群端点列表
- SDS (Secret Discovery Service)     → TLS 证书与密钥

2.3 控制平面组件详解

Istio 1.5+ 版本将控制平面组件整合为单一的 istiod 二进制，但在逻辑上仍然保留了四个核心功能模块：Pilot、Mixer、Citadel、Galley。理解每个模块的职责有助于排查配置问题和规划生产部署。

2.3.1 Pilot — 配置下发与流量管理

Pilot 是控制平面的“大脑”，负责将 Istio 的流量管理规则（VirtualService、DestinationRule、Gateway 等 CRD）转换为 Envoy 可理解的 xDS 配置，并通过 gRPC 流推送到所有 Sidecar 代理。

服务发现：对接 Kubernetes API Server，实时监听 Service、Pod、Endpoint 的变化。
配置转换：将用户定义的流量规则编译为 Envoy 的 RouteConfiguration、ClusterConfiguration 等。
一致性保证：使用版本号机制确保每个 Envoy 实例的配置最终一致。

2.3.2 Mixer — 策略与遥测（已弃用，但理解其设计仍有价值）

在 Istio 1.5 之前，Mixer 负责策略检查（如速率限制、RBAC）和遥测报告。从 1.5 开始，Mixer 的功能被逐步内联到 Envoy 代理中，以降低延迟和运维复杂度。但在旧版本集群中，Mixer 仍然是控制平面的重要组成部分。

Check：在请求到达目标服务前，向 Mixer 发送检查请求，判断是否允许通过。
Report：请求结束后，将日志和指标数据上报给 Mixer，再由 Mixer 转发给后端（如 Prometheus、Stackdriver）。

注意：从 Istio 1.8 开始，Mixer 已被完全移除。新项目应直接使用 Envoy 原生 Wasm 扩展或 Telemetry API 实现策略与遥测，不再部署 Mixer 组件。

2.3.3 Citadel — 安全证书管理

Citadel 负责管理服务网格内的身份与证书。它为每个服务颁发基于 SPIFFE（Secure Production Identity Framework for Everyone）标准的 X.509 证书，并自动进行证书轮换。

身份生成：根据 Kubernetes ServiceAccount 生成 SPIFFE ID。
证书签发：内置 CA（Certificate Authority），为每个 Envoy 代理签发短期证书（默认 24 小时）。
自动轮换：证书过期前自动通过 SDS 协议下发新证书，无需重启 Pod。

2.3.4 Galley — 配置验证与分发

Galley 是控制平面的配置处理网关，负责验证、处理和分发用户提交的 Istio CRD 配置。它充当了 Kubernetes API Server 与 Pilot 之间的中间层。

配置验证：使用 Webhook 机制拦截 Istio CRD 的创建/更新请求，进行语法和语义校验。
格式转换：将用户定义的 CRD 转换为 Pilot 内部使用的统一配置模型。
配置分发：将验证通过的配置推送给 Pilot 和其他控制面组件。

2.4 Istio 整体架构关系图

下图展示了控制平面各组件与数据平面 Envoy 代理之间的交互关系：

2.5 组件通信流程示例

当用户创建一个 VirtualService 并提交到 Kubernetes 集群时，Istio 控制平面各组件按以下顺序协同工作：

Galley 通过 ValidatingWebhook 拦截 CRD 请求，校验配置合法性。
校验通过后，Galley 将配置转换为内部模型并推送给 Pilot。
Pilot 结合服务发现信息，将 VirtualService 编译为 Envoy 的 RouteConfiguration 和 ClusterConfiguration。
Pilot 通过 gRPC 流将 xDS 配置推送到所有相关的 Envoy Sidecar。
同时，Citadel 持续为每个 Envoy 维护 mTLS 证书，确保通信加密。
Envoy 代理根据最新配置开始路由流量，并自动生成追踪和指标数据。

生产建议：在生产环境中，建议将 istiod 的副本数设置为 2 或 3，并配置 PodAntiAffinity 确保跨可用区部署。同时开启 Galley 的配置验证 Webhook，避免错误配置导致全局流量中断。

2.6 组件版本演进与选型建议

组件	Istio 1.4 及之前	Istio 1.5 ~ 1.7	Istio 1.8+	当前推荐
Pilot	独立 Deployment	合并入 istiod	合并入 istiod	使用 istiod
Mixer	独立 Deployment	独立但可选	已移除	使用 Envoy Wasm / Telemetry API
Citadel	独立 Deployment	合并入 istiod	合并入 istiod	使用 istiod
Galley	独立 Deployment	合并入 istiod	合并入 istiod	使用 istiod

从 Istio 1.5 开始，官方将 Pilot、Citadel、Galley 合并为单一的 istiod 部署，大幅降低了运维复杂度。Mixer 在 1.8 中被彻底移除，其策略与遥测能力由 Envoy 原生扩展和 Telemetry API 替代。对于新项目，应直接使用 Istio 1.8+ 版本，并采用 istiod 一体化部署模式。