4. 服务网格基础与 Istio 架构：Sidecar 模式、数据平面与控制平面、Istio 核心组件
服务网格（Service Mesh）是云原生微服务通信的基础设施层，它将服务间通信的复杂性从应用代码中剥离，交由独立的代理层处理。本章将深入剖析服务网格的核心模式——Sidecar，以及 Istio 作为主流服务网格实现的分层架构与核心组件。
4.1 Sidecar 模式：非侵入式代理
Sidecar 模式是服务网格的基石。它通过在每一个服务实例旁部署一个代理容器（Sidecar），接管所有进出该实例的网络流量。应用容器无需感知 Sidecar 的存在，也无需修改代码即可获得流量管理、安全、可观测性能力。
核心优势：
- 解耦： 通信逻辑与业务逻辑完全分离。
- 透明： 对应用容器零侵入，升级 Sidecar 无需重启业务。
- 一致性： 所有服务实例获得统一的通信策略。
4.2 数据平面与控制平面
Istio 将服务网格划分为两个逻辑平面，职责清晰，便于管理和扩展。
| 平面 | 职责 | 组件 | 关键特性 |
|---|---|---|---|
| 数据平面 | 处理服务间所有网络通信 | Envoy 代理（Sidecar） | 高性能、低延迟、透明代理 |
| 控制平面 | 配置下发、策略管理、证书签发 | Istiod（Pilot + Citadel + Galley） | 集中管控、动态更新、安全加固 |
关键理解： 数据平面负责“执行”，控制平面负责“决策”。这种分离使得策略变更无需重启任何业务 Pod，控制平面通过 xDS 协议将最新配置推送到所有 Envoy 代理。
4.3 Istio 核心组件详解
Istio 的控制平面由 Istiod 统一提供，它整合了早期版本中的 Pilot、Citadel、Galley 三个独立组件。数据平面则由注入到 Pod 中的 Envoy 代理 构成。
4.3.1 Istiod（控制平面核心）
- Pilot（服务发现与流量管理）： 监听 Kubernetes Service、Endpoint、VirtualService、DestinationRule 等资源，生成 Envoy 可理解的配置（Listener、Cluster、Route），并通过 xDS 协议下发。
- Citadel（安全与证书管理）： 自动为每个服务生成 SPIFFE 兼容的身份证书，管理 mTLS 通信的密钥对，支持证书轮换。
- Galley（配置验证与分发）： 负责验证 Istio 配置的合法性，并将配置转换为内部模型供 Pilot 使用。
4.3.2 Envoy 代理（数据平面核心）
- 高性能 L4/L7 代理： 基于 C++ 编写，支持 HTTP/1.1、HTTP/2、gRPC、TCP 等协议。
- 流量拦截： 通过 iptables 规则透明地劫持 Pod 内所有进出流量。
- 策略执行： 实现熔断、重试、超时、限流、负载均衡等高级流量管理功能。
- 遥测数据采集： 自动生成访问日志、指标（Metrics）和分布式追踪数据。
4.4 核心概念对比
| 概念 | 说明 | 类比 |
|---|---|---|
| Sidecar | 与业务容器同 Pod 部署的代理容器 | 每辆车的专属司机 |
| 数据平面 | 所有 Sidecar 代理的集合，处理实际流量 | 道路上的所有车辆 |
| 控制平面 | 管理数据平面的中央大脑 | 交通指挥中心 |
| Istiod | Istio 控制平面的统一组件 | 指挥中心的总调度台 |
| Envoy | 高性能 L4/L7 代理，Istio 默认 Sidecar | 智能导航 + 行车记录仪 |
常见误区： 服务网格不等于 Istio。Istio 是服务网格的一种实现。Envoy 是数据平面代理，Istiod 是控制平面。不要将 Istiod 与 Istio 整体混淆。
4.5 本章小结
- Sidecar 模式实现了非侵入式的服务通信治理，是服务网格的核心设计模式。
- 数据平面负责高性能流量转发与策略执行，控制平面负责集中配置与安全管理。
- Istio 的控制平面由 Istiod 统一提供，数据平面由 Envoy 代理构成。
- 理解这两个平面和 Sidecar 模式，是后续搭建多集群服务网格集成流水线的基础。